Excluding DAST Scan Rules

excluding specific dast rules so they do not run is a great way to tailor your dast scans so that only the rules that apply to your specific web application instance and/or technology stack are run for instance, it might not make sense to run sql injection rules if you don't use sql to exclude rules you'll need to understand and reference the rules using the zap rule id the full list of rules including their ids can be found on the zap site rules listed as ' active ' are run for full and api scans, those listed as ' passive ' are run for baseline scans alternatively, if following the rule config txt approach below, the generated rules file will contain the full set of rule ids for your scan mode along with a basic description excluding using a rules config txt file generating and editing a rules config txt file is an easy way to ignore specific rules from being reported works across all dast scan modes docid\ in46me9k 6otbmok9hids ( baseline , fullscan , and apiscan ) the file contains a sort description of each rule, making it easier to track down specific rules the file can be added to source control, maintaining a full version history of any ignored rules the rules that are ignored will still be run but the results will not be reported as web vulnerability (dast) issues docid\ l ty1xqcyiasbno p8r5a , therefore the overall execution time of the dast scan will not be reduced generating a baseline rules config txt file execute the soos dast cli, passing otheroptions=" g rules config txt" this will write the rules file to the mapped local directory c \temp\rules soos recommends running as the zap user (1000 1000) but this user will need rwx access to the mount in the example below if you can't do that, you may run without the u parameter and have the container run as root but this is not recommended unless absolutely necessary the rules file will be generated for the specified scanmode , meaning the list of rules will differ when generating a rules file for fullscan, baseline , or apiscan once the file has been generated, open it in a text editor and set any rules to ignore that you don't want results reported for make sure to maintain the tabs separating each column referencing a modified rules config txt file execute the soos dast cli, passing otheroptions=" c rules config txt" ensure that the rules config txt file exists in the mapped local directory c \temp\rules any ignored rules which find issues will still show results in the cli output (since they are still run), but the results will be marked as ignored the results of ignored rules will not create issues in soos excluding rules using disablerules cli argument the disablerules parameter can be used to specify a list of comma separated rule ids that should not be run unlike ignoring rules with the rules file approach above, disabling rules will ensure they are not run at all use this option to improve performance of long running dast scans by completely excluding certain rules from being executed the disablerules cli argument my not disable certain rules, especially alpha/beta rules example due to the way zap disables rules, when using disablerules the rule will still appear as if it's run, displaying pass name of rule \[ruleid] in the cli output, however the rule will not actually be run and will not create issues in soos improving long running dast scan performance the maximum timeout for soos dast scans is 180 minutes any scan that does not complete within that timeframe will return an ' incomplete ' status depending on the size of the site being scanned, active scans may exceed this time limit due to the complexity of the rules being run it is recommended to use the disablerules parameter to omit any rules that are not necessary, for example any rules that do not match the technology being used additional techniques for improving scan performance can be found under adjusting scan times docid\ vizjose7ku 8zlrqxt2br and fine tuning dast results docid 22fdcyodmriwignkidphm vulnerabilities identified during unfiltered scans will be moved to the 'resolved' issues list if subsequent scans use disablerules to omit the rule associated with any previously discovered vulnerability