Customizable SAST policies are becoming the AppSec trust test

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Semgrep's blog post: Customizable SAST policies determine whether AppSec findings are trusted, acted on, or ignored.

Why it matters: It matters because AppSec teams need policy controls and rule-level tuning to reduce noise, preserve developer trust, and make security findings operationally usable.

Context

Customizable SAST is about governance as much as detection. The core issue is not whether a scanner can find issues, but whether security teams can control when findings reach developers, how much context they carry, and whether the rule logic matches the codebase.

When findings are noisy or poorly explained, developers learn to distrust the control rather than the code issue. That makes policy tuning, rule transparency, and remediation context part of the security operating model, not an optional product feature.

Key questions

Q: What should AppSec teams do first when SAST findings overwhelm review capacity?

A: Start by filtering findings through reachability and runtime context before they reach a human. That turns triage into a prioritisation control, not a manual sorting exercise. Once you know which issues are actually exploitable, you can reserve engineering time for the findings that change real risk instead of just adding backlog.

Q: Why do false positives make SAST less effective at scale?

A: False positives consume analyst time, slow down merges, and train developers to distrust security output. Over time, the scanner stops functioning as a control because teams stop treating its alerts as urgent. Precision and reachability are therefore governance requirements, not quality-of-life features.

Q: How can teams tell whether their SAST programme is actually working?

A: Look for reduced false-positive churn, faster remediation on high-confidence issues, and consistent developer adoption across repos and teams. If engineers ignore findings, suppress everything by default, or route issues outside the normal delivery process, the programme is not working. Effective SAST changes behaviour, not just dashboards.

Q: How should teams balance detection coverage and developer friction in AppSec?

A: Treat coverage and friction as a trade-off that must be managed through policy granularity. Broad surfacing can increase visibility, but it also raises the chance of overload when findings are low-confidence or context poor. The better approach is to tune rule behaviour so high-value findings reach developers and low-value ones stay under security review.

Technical breakdown

Rule behavior controls the developer experience

SAST engines use rules, queries, or detectors to match code patterns and taint flows. If every finding is surfaced in the same way, the tool collapses very different risk levels into a single workflow, which creates friction and weakens trust. Policy layers such as monitor, comment, and block separate signal from escalation, so teams can treat low-confidence findings as telemetry and high-confidence findings as enforcement. The critical point is that policy is not just presentation. It shapes how developers perceive accuracy, relevance, and urgency.

Practical implication: Use rule-level policy states to control escalation instead of flooding developers with every finding.

Rule customization reduces false positives at the source

False positives often come from the scanner not understanding local safeguards, internal wrappers, or repository-specific control logic. In practice, a rule can flag a risky data flow even when an application already validates the input through an approved function, because the engine lacks that project context. Custom sanitizers, exclusions, or rule refinements let teams encode those safeguards directly into detection logic. That changes triage from repeated manual suppression to a more durable control definition. The result is not only less noise, but a better fit between the detection model and the application architecture.

Practical implication: Tune rules to recognise real internal safeguards so teams stop relitigating the same false positives.

Fix quality matters more than finding volume

A finding is only useful if developers can understand why it matters and what to change. When security output lacks clear reasoning or remediation guidance, even accurate alerts become workflow interruptions rather than fixes. That is why fix rate is a better operational signal than raw scan count: it measures whether the issues being surfaced are actually actionable in the developer workflow. In AppSec programmes, the unit of value is not discovery alone, but successful correction with minimal context switching.

Practical implication: Measure whether surfaced findings are being fixed, not just whether they are being found.

Threat narrative

Attacker objective: The attacker objective is to hide meaningful software risk inside an overloaded and distrusted scanning process.

1. Entry occurs when weak or noisy SAST policies push low-value findings into developer workflows and create alert fatigue.
2. Escalation happens when repeated false positives cause teams to ignore or de-prioritise findings that would otherwise receive attention.
3. Impact is a degraded AppSec control plane in which real issues are harder to trust, triage, and fix at the pace development requires.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Customizable SAST policy is now a governance test, not a tooling preference. AppSec teams are no longer just choosing a scanner, they are deciding whether detection output can be made operational enough for developers to trust. The ability to tune monitor, comment, and block behavior at the rule level determines whether security is embedded into delivery or sidelined as noise. Practitioners should treat policy design as part of the security operating model.

False-positive control is the real trust boundary. The article’s central insight is that teams lose credibility when findings arrive without local context, clear reasoning, or an explainable fix path. That aligns with wider application security practice: controls that cannot be understood will be bypassed, even when they are technically accurate. Practitioners should optimise for precision, not just breadth of coverage.

Rule transparency creates a better feedback loop than manual triage alone. When teams can inspect and adjust the rule logic, they can align SAST behaviour with internal safeguards instead of repeatedly suppressing the same alert. That matters for both developer experience and control durability, because the detection model improves rather than the backlog merely shrinking. Practitioners should use rule visibility to convert repeated exceptions into codified logic.

Fix rate is the right performance metric for shift-left AppSec. Scan counts and alert volumes tell you how much the tool sees, not whether the organisation can act on it. A useful SAST programme proves that findings lead to correction inside the developer workflow, with minimal interruption and maximum clarity. Practitioners should measure whether findings are being fixed, not whether they are merely being generated.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: NHI Lifecycle Management Guide

What this signals

Policy granularity is becoming a control requirement for modern AppSec. Teams that cannot separate monitor, comment, and block states at the rule level will struggle to align security signal with development velocity. The operational question is no longer whether SAST can find issues, but whether the findings can be governed without eroding trust.

Developer trust is a security outcome, not a soft metric. When findings are explainable and tied to clear remediation, teams are more likely to engage with them instead of bypassing them. That makes explainability part of the control surface, especially where code scanning sits directly inside the delivery workflow.

For practitioners

• Define rule-level escalation policies Start with monitor mode for new or uncertain rules, move validated rules to comment mode, and reserve block mode for findings that are both accurate and operationally urgent.
• Encode internal safeguards into rules Adjust custom sanitizers, exceptions, or rule logic so the scanner recognises approved validation paths and other repository-specific controls before flagging a finding.
• Measure fix rate by rule Track whether surfaced findings are actually getting fixed, then disable or retune rules whose alert quality drops below an actionable threshold.
• Preserve remediation context in findings Make sure developers see why an issue was flagged and what change is expected, so the finding reduces cognitive load instead of adding triage work.

Key takeaways

• Customizable SAST policies determine whether scanning becomes a trusted control or a source of workflow friction.
• Rule-level tuning helps AppSec teams reduce false positives, preserve context, and surface the right findings to the right audience.
• Fix rate is a stronger signal of AppSec value than raw alert volume because it shows whether developers can act on what they see.

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.
• Fix Rate: Fix rate is the proportion of surfaced findings that are actually resolved by developers. It is a practical measure of whether a security control is producing issues that are understandable, relevant, and actionable enough to influence real remediation behaviour.
• Rule Customization: Rule customization is the practice of tailoring security detections to the specific code, libraries, and workflows used by a team. It lets organisations encode local risk conditions and safer patterns so findings are more relevant, more trusted, and easier to remediate in practice.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity in a way that maps security controls to operational decision-making. It is a useful next step for practitioners who need to connect identity governance to broader security programmes.