Check the diff for ignore comments, scanner configuration changes, excluded paths, lowered severity thresholds and removed checks. If the finding closed because the scanner was told to look away, the code is unchanged and the risk remains. Ask for a real fix or a documented exception.
How the shortcut happens
Given a goal like "make this warning go away", a tool can satisfy it in two ways: change the code, or change what the scanner sees. The second is faster and sometimes looks tidy. OWASP's guidance on secure coding with AI describes a close cousin in tests, where agents get CI green by deleting failing tests or weakening assertions. The same incentive exists with scanners and quality gates.
This is a review pattern to watch for, not an accusation about any tool.
Where suppression hides
| Place | What it looks like |
|---|---|
| Inline in code | A comment or annotation telling the scanner to skip a line or rule |
| Scanner configuration | A rule disabled, a path added to an exclude list |
| Policy or gate settings | A severity threshold raised, a required check removed |
| Pipeline | A step marked as allowed to fail, or removed |
| Dependency settings | An override or ignore entry for an advisory |
Any of these in a pull request titled as a security fix needs a clear reason.
How to check in two minutes
- Search the diff for words such as ignore, skip, disable, exclude, suppress and allow failure, and for the names of your scanner's own markers.
- Look at changes to configuration files and pipeline definitions even if the task did not mention them. OWASP lists CI configuration and build files among the files that deserve heightened scrutiny.
- Compare scanner results with and without the config change. If the finding comes back, the code was not fixed.
- Ask the author, human or tool, why each configuration change is needed.
Legitimate exceptions exist
Sometimes a finding really is a false positive, or the risk is accepted for a period. That is fine when it is done openly: a named owner, a reason, an expiry date, and approval from someone with authority. Statuses such as false positive, accepted risk and will not fix are a normal part of triage. See finding statuses in SAST.
The difference between an exception and a silent suppression is who decided and whether it was recorded.
Make it harder to do quietly
- Use CODEOWNERS so scanner and pipeline configuration need security approval.
- Require a justification field for any suppression.
- Expire suppressions automatically and report on how many are open.
- Add a check that fails when new suppression markers appear in a pull request.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how each finding is tied to a location in the code, then think about what would change in the report if the code stayed the same but the rule was switched off.
Safeguard policies and gates can be set so a pull request is held on required checks, and changes to those settings can be reviewed like code. Autonomous remediation is off by default.
Quick check
Is adding a suppression ever the right fix?
Yes for a confirmed false positive or a time limited accepted risk, if it is documented with an owner and an expiry. Not as a way to get a build green.
Sources
Last reviewed: 19 October 2026.
