Run Instance Scan on a five-year-old production instance and you will get four thousand findings. The team will glance at the count, despair, and ignore it forever. The trick is curation — the default suite is too broad to ever ship a remediation plan from.
Why the default suite produces noise
The shipped checks include style nags, deprecation warnings for APIs you do not use, and best-practice rules from a release you have not yet adopted. About 70% of findings on a mature instance are not actionable.
Build three suites, not one
- Critical — security, ACL bypass risk, hard-coded credentials
- Upgrade-blocker — deprecated API usage that will break next release
- Quality — style, maintainability, performance smells
Run Critical weekly and treat findings as P2 incidents. Run Upgrade-blocker before every clone. Run Quality monthly and route to the owning teams as backlog items.
Custom checks for your patterns
Every instance has internal patterns that the default suite cannot know about. Write custom checks for:
// Example custom check: detect unrestricted Script Include cross-scope access
var ScopedAccessCheck = Class.create();
ScopedAccessCheck.prototype = {
process: function() {
var gr = new GlideRecord('sys_script_include');
gr.addQuery('access', 'public');
gr.addQuery('client_callable', false);
gr.addQuery('sys_scope.scope', 'STARTSWITH', 'x_');
gr.query();
var findings = [];
while (gr.next()) {
findings.push({
record: gr.getUniqueValue(),
message: 'Public scoped Script Include with no client-callable use case'
});
}
return findings;
},
type: 'ScopedAccessCheck'
};
Five focused custom checks beat 50 generic ones every time.
Suppress findings deliberately
A finding you decide not to fix gets a documented suppression — never a deletion. The suppression record carries a reason, an approver, and a review date.
Table: u_scan_suppression
Columns:
finding_check_id
target_sys_id
reason (text)
approver (user)
review_date (date)
ticket_link (url)
The review date is the gate that prevents suppression-as-forever-amnesty.
Make scan part of the deploy pipeline
Wire Instance Scan into the update set promotion process. Critical findings introduced by an update set block promotion. Anyone arguing should publish a written exception.
The metric that matters
Track Critical findings count over time. The number should drift down. If it is flat or up, your team is producing the same patterns you are trying to eliminate, and the scan suite is just documenting the problem.
What to do this week
Build the Critical suite if you do not have one. Limit it to fewer than 20 checks. Run it. The results will be uncomfortable and exactly what your security team has been waiting for.