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 script, passing otheroptions=" g rules config txt" this will write the rules file to the mapped local directory c \temp\rules docker run v c \temp\rules\ /zap/wrk/\ rw it rm soosio/dast clientid=\<soos clientid> apikey=\<soos apikey> projectname="\<project name>" scanmode=fullscan otheroptions=" g rules config txt" \<target url> 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 10003 warn (vulnerable js library (powered by retire js) passive/release) 10009 ignore (in page banner information leak passive/beta) 10010 warn (cookie no httponly flag passive/release) referencing a modified rules config txt file execute the soos dast script, passing otheroptions=" c rules config txt" ensure that the rules config txt file exists in the mapped local directory c \temp\rules docker run v c \temp\rules\ /zap/wrk/\ rw it rm soosio/dast clientid=\<soos clientid> apikey=\<soos apikey> projectname="\<project name>" scanmode=fullscan otheroptions=" c rules config txt" \<target url> 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 docker run v c \temp\rules\ /zap/wrk/\ rw it rm soosio/dast clientid=\<soos clientid> apikey=\<soos apikey> projectname="\<project name>" scanmode=fullscan disablerules="10021,10096,40025" \<target url> 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