Notifications
Clear all
Topic starter
02/08/2026 11:39 am
TL;DR: Non-production environment context and framework protections account for 47.5% of all memories in Semgrep’s analysis of thousands of platform memories, underscoring how often generic SAST rules miss codebase-specific reality. The real governance problem is not scanner coverage, but the lack of durable context that lets security teams separate exploitable findings from noise.
NHIMG editorial — based on content published by Semgrep: why false positives in SAST need codebase-specific context
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.
Questions worth separating out
Q: How should security teams reduce repetitive false positives in SAST programs?
A: Start by encoding the context your scanner cannot infer reliably.
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.
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.
Practitioner guidance
- 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.
- Encode framework protections as governed context Document middleware, decorators, ORM query builders, and output-encoding controls that already handle specific vulnerability classes.
- Treat memories as policy artifacts Route memory creation and approval through a controlled workflow so analyst judgment becomes reusable security policy.
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
👉 Read Semgrep’s analysis of SAST false positives and codebase context →
SAST false positives and codebase context: what teams should fix first?
Explore further
02/08/2026 12:51 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Why false positives in SAST need codebase-specific context
