Why false positives in SAST need codebase-specific context

At a glance

What this is: This analysis shows that most SAST tuning work is really about teaching scanners codebase context, with non-production paths and framework protections making up nearly half of all memories.

Why it matters: It matters because IAM, AppSec, and platform teams need to govern what is actually reachable and production-relevant, not just what matches a generic pattern.

By the numbers:

• Non-production environment memories account for 25.6% of all memories written.
• Framework protection memories account for 21.9% of all memories written.
• Together, these two categories represent nearly half (47.5%) of all the context security teams are adding to their SAST scanners.

👉 Read Semgrep’s analysis of SAST false positives and codebase context

Context

Static application security testing becomes noisy when it cannot distinguish production-relevant code from code that only exists for development, testing, or framework-managed safety. In practice, the governance gap is not simply rule quality. It is the absence of durable context about where code runs, which controls already exist, and which findings are genuinely exploitable in the deployed environment.

That context problem intersects with identity governance when code paths, service accounts, secrets, and authentication controls are embedded in application logic. Security teams end up teaching scanners what the system already knows about trust boundaries, which is a sign that policy and runtime reality are still too loosely connected. The article’s starting position is typical for mature AppSec programmes, but it also reflects a broader operational challenge across identity-aware security tooling.

Key questions

Q: How should security teams reduce repetitive false positives in SAST programs?

A: Start by encoding the context your scanner cannot infer reliably. Focus first on non-production code paths, then on framework protections such as authentication middleware, ORM query builders, and output encoding. Treat each memory as governed detection policy, not a one-off dismissal, so the same decision is applied consistently across future scans.

Q: Why do generic scanners struggle with code that is safe in one environment but not another?

A: Generic scanners do not know whether a file is deployed, whether a route is protected, or whether a control is enforced upstream. They match patterns, not organisational intent. Without explicit context, they will flag test fixtures, development scripts, and framework-managed controls as if they were production risks.

Q: What do AppSec teams get wrong about false-positive management?

A: They often treat suppression as a review task instead of a knowledge-management task. That leads to repeated manual decisions, inconsistent handling across teams, and lower trust in the scanner. Durable context should be authored once, approved once, and reused wherever the same pattern appears.

Q: How do you know if scanner tuning is actually improving security signal quality?

A: Look for fewer repeated dismissals of the same pattern, faster triage of genuinely risky findings, and higher developer confidence in the tool’s output. If the team still re-evaluates the same findings in every pull request, tuning has not become governed context. It has only shifted the workload.

Technical breakdown

Why generic SAST rules produce repetitive false positives

A generic SAST engine matches source code against vulnerability patterns, but it cannot infer business context on its own. It sees a hardcoded credential, a SQL query, or an unauthenticated route and flags the pattern unless told otherwise. That is why code location, execution environment, framework behaviour, and compensating controls matter. The scanner is not wrong in a vacuum. It is incomplete because it lacks the organisational knowledge that determines whether a pattern is exploitable, test-only, or already mitigated.

Practical implication: teams need a repeatable way to encode environment and framework context into scanner logic instead of handling the same false positives by hand.

How codebase memories change scanner behaviour

A memory is durable triage knowledge expressed in natural language so the scanner can reuse it across future findings. In effect, it converts a one-off analyst decision into a policy artifact. If a directory is always test-only, or a middleware layer always validates JWTs, the scanner can suppress findings that would otherwise require manual review. The key mechanism is not auto-remediation. It is institutional memory applied at scan time, which reduces repetitive review without removing human control over the rule itself.

Practical implication: security teams should treat memories as governed detection policy and review them with the same change discipline as code or rulesets.

Why environment and framework context dominate the noise profile

The article shows that most repeated false positives cluster around two patterns. Non-production context tells the scanner which files, directories, or repositories are never deployed. Framework protection context tells it which risks are already handled by middleware, decorators, or query builders. These are not edge cases. They are the routine decisions AppSec teams make during triage. When those decisions are not captured centrally, the organisation pays for them repeatedly in developer time, triage latency, and lower trust in the scanner itself.

Practical implication: start with non-production paths and framework protections, because those are the highest-yield categories for reducing noise at scale.

NHI Mgmt Group analysis

Codebase-specific context is now a control plane problem, not just a tuning problem. When scanners cannot distinguish deployed code from test scaffolding or framework-managed safety, teams are really missing policy context. That makes detection quality dependent on human memory instead of governed rules. For AppSec leaders, the lesson is that context must be managed as a first-class security control, not an informal reviewer habit.

False-positive reduction is an identity-adjacent governance issue whenever secrets, authentication, or service trust are embedded in application logic. The scanner may be looking at code, but the underlying question is whether a credential, route, or data flow is actually trusted in production. That brings the problem close to IAM and NHI governance, because service accounts, API keys, and auth middleware are often the controls being encoded in these memories. The practical conclusion is that AppSec and identity teams should align on what constitutes trustworthy runtime context.

Non-production noise and framework protection are the core of a new category we can call context-aware detection debt. This debt accumulates when organisations rely on generic rules to interpret code that only makes sense inside a specific operational model. The more codebases adopt custom middleware, internal decorators, and environment-specific branches, the more expensive unmanaged detection debt becomes. Practitioners should view memory authoring as debt reduction, not scanner decoration.

Developer trust is the hidden control objective behind memory systems. When developers repeatedly see findings they know are not real, they stop engaging with the tool as a decision aid. That is a governance failure because the organisation loses both signal quality and reviewer confidence. The right benchmark is not how many findings a scanner can produce, but how reliably it can preserve attention on findings that matter.

What this signals

Context-aware detection debt will become a larger operating issue as codebases accumulate more framework layers, internal decorators, and environment-specific logic. Security programmes that do not centralise that context will keep paying the same triage cost in every release cycle. That makes policy authoring a measurable control outcome, not a documentation exercise.

The identity overlap is real whenever scanners are judging routes, tokens, secrets, or service-authenticated flows. Teams should align AppSec memory governance with IAM and NHI ownership so the same trust boundary is not interpreted differently by different control planes. For broader control alignment, NIST CSF 2.0 and NIST SP 800-53 Rev 5 remain useful reference points for access, audit, and monitoring discipline.

The practical signal to watch is whether recurring findings disappear because the code changed or because the policy context improved. If the latter, the organisation is maturing its detection model; if not, it is only suppressing noise. That distinction matters for both developer trust and audit readiness.

For practitioners

• Prioritise non-production path memories Identify directories, repositories, scripts, and modules that never ship to production, then write memories that exclude findings in those locations from routine triage. Start with local tooling, CI helpers, and decommissioned infrastructure code, because those are the fastest sources of repetitive noise.
• Encode framework protections as governed context Document middleware, decorators, ORM query builders, and output-encoding controls that already handle specific vulnerability classes. Keep each memory narrow enough to reflect one compensating control, and review it when the framework version or routing logic changes.
• Treat memories as policy artifacts Route memory creation and approval through a controlled workflow so analyst judgment becomes reusable security policy. That reduces ad hoc suppression and gives AppSec, platform, and engineering teams a common standard for what counts as an acceptable exception.
• Measure trust, not just suppression volume Track how many findings are dismissed, how quickly recurring patterns are resolved, and whether developers stop reopening the same issues. If scanner confidence improves while manual review volume falls, the memory model is working; if not, the ruleset is masking unresolved context gaps.

Key takeaways

• SAST quality improves when teams encode codebase context, not when they simply add more rules.
• Non-production paths and framework protections account for nearly half of the memories in Semgrep’s analysis, showing where noise reduction work should start.
• Memories are a governance mechanism for reusable triage knowledge, and they matter most when identity, secrets, and application trust boundaries meet in code.

Key terms

• Static Application Security Testing: Static Application Security Testing is a method for finding security flaws by examining code, binaries, or configuration without executing the application. It is strongest when used early in development, where teams can fix issues before deployment and prevent avoidable defects from reaching production.
• False Positive: A false positive is a scanner result that looks like a secret but is not actually sensitive. In secret governance, false positives matter because they consume analyst time, weaken trust in alerts, and can delay response to the findings that truly change exposure and access risk.
• Compensating Control: A compensating control is a measure that reduces risk when the ideal fix, such as immediate patching or redesign, is not possible. In OT, compensating controls often include session recording, access restriction, and tighter monitoring. They do not eliminate the underlying issue, but they narrow exposure until safer remediation can happen.

What's in the full report

Semgrep's full analysis covers the operational detail this post intentionally leaves for the source:

• Memories distribution by goal, including the full taxonomy of nine additional context categories beyond the top two
• Guidance on how authored memories and auto-suggested memories differ in review flow and admin approval
• Remediation at Scale report findings on remediation rates, time-to-fix distributions, and feature effectiveness across hundreds of organisations
• OWASP category breakdowns and ecosystem-specific SCA recommendations that support implementation planning

👉 Semgrep’s full post covers the memory taxonomy, triage workflow, and remediation analysis in more detail

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. Explore the course if your programme needs a stronger operating model for secrets, workload identity, and access governance.