Summary
In a previous article, How to implement the instance scan process, I described how the Instance Scan process can be implemented to maintain and improve your platform. This article describes a solution making muting a finding more efficient. It does contain customizations to baseline scripts. They are deliberate customizations to make it easier to maintain the findings and the associated scan task records when findings are muted.
This solution is now described.
Mute findings
In the baseline you will find UI actions to mute and unmute scan findings. I find that the functionality for muting findings is quite limited. When doing so, you can only select from 3 options that are not particularly clear:
- Not applicable
- Risky change
- Not priority
Also, it is not possible to provide an explanation of the reason that was selected.
Finally, after muting a choice you should open the associated scan task record to resolve it manually.
We decided to adjust this solution in the following ways:
- Use more appropriate choices
- You need to add an explanation on why the finding was muted
- The associated scan task record is automatically resolved using the explanation provided
Solution
The solution consists of the following adjustments. They have been captured in an update set that has been added as an attachment to this article.
- Adjust the baseline choices that can be selected
- Adjust UI Action “Mute” to add a mandatory text field
- Create field “Reason explanation” in the “Mute rule” table to store the explanation from the previous step
- Adjust script include “ScanMuteRule” to write the explanation to this field, and to resolve the scan task record
1. Adjust the baseline choices that can be selected
The choices that are presented are records from the “Mute Reason” table (scan_mute_rule_reason). So, you can simply adjust these choices by navigating to this table and adjusting the “Mute reason” field of the records.
Figure 1: Mute reason records from the baseline
2. Adjust UI Action "Mute" to add a mandatory text field
This UI action uses UI page “select_mute_reason”. To add a mandatory text field, the HTML section and client script section of this page need to be adjusted.
HTML Code Added
The following lines of code were added to the HTML section of this page
.
Figure 2: Additional HTML code for UI page "select_mute_reason"
The label is taken from UI message “mute_reason_expl”: “Explanation”
Client script Adjustments
In the client script, an additional check has been created to validate that a reason was supplied. If the explanation field is empty, the user is alerted and directed back to the modal.
If an explanation has been provided, this is passed to the script include on the server side as parameter “sysparm_muteresasonexpl”.
Figure 3: Additional client script code for UI page "select_mute_reason"
Pop-up
These modifications will result in the following pop-up when selecting the Mute button.
Figure 4: New "Select Mute Reason" pop-up window
3. Create field “Reason explanation” in the “Mute rule” table to store the explanation
When muting a finding, a mute rule is created in the scan_mute_rule table. This record has references to the associated check, the source table and the source script for which the finding was muted. We created an additional string field, “Reason explanation” (u_reason_explanation) to store the explanation provided via the UI page. The field has also been added to the default form and list layout of this table.
4. Adjust script include “ScanMuteRule”
Script include “ScanMuteRule “ has been adjusted to do 2 things.
1. Add the explanation to the new field
This has been done by passing the content of “sysparm_mutereasonexpl” as a parameter to the “_mute” function. In the “_mute” function, lines 35 and 41 have been added, to fill the new field with the explanation:
“gr.u_reason_explanation = mutereasonexplanation;”
Figure 5: Additional lines in the "_mute" function
2. Resolve the associated scan task record
Function “_resolvescantask” has been added to the script to resolve the scan task record automatically. The function is called in line 19 after the finding has been muted.
Figure 6: Calling the new “_resolvescantask” function
The new function can be found in lines 49-57:
Figure 7: the “_resolvescantask” function
Conclusion
In conclusion, the enhancements introduced in this solution streamline the instance scan process by improving the clarity and functionality of muting findings. The ability to provide detailed explanations for muted findings not only adds transparency but also simplifies future analysis and auditing. Furthermore, the automated resolution of associated scan tasks eliminates manual intervention, enhancing efficiency and reducing the risk of oversight.
