Notifications
Clear all
Topic starter
02/08/2026 12:27 pm
TL;DR: Customizable SAST policies can improve developer trust and fix rates by letting AppSec teams tune which findings are surfaced, blocked, or monitored, and by refining rules to match internal safeguards, according to Semgrep. The operational lesson is that false-positive control, not raw scan volume, determines whether shift-left AppSec is actually adopted.
NHIMG editorial — based on content published by Semgrep: customisable SAST policies and developer trust in application security
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
Questions worth separating out
Q: How should security teams implement SAST policy tuning without overwhelming developers?
A: Begin with broad monitoring, then promote only well understood rules into developer comments and build blocking.
Q: Why do false positives slow down appsec and DevSecOps programmes?
A: False positives slow programmes because engineers stop trusting findings that do not reliably predict real risk.
Q: What breaks when SAST rules cannot reflect internal safeguards?
A: The scanner keeps flagging patterns that are actually safe in the local codebase, which means developers receive inaccurate warnings and AppSec teams spend time on manual verification.
Practitioner guidance
- Map findings to confidence tiers Start with monitor mode for broad rules, then move only high-confidence, high-impact detections into comment or block mode.
- Customise noisy rules with repository-specific sanitizers Where a safe internal library or helper function already validates a risky input, encode that safeguard in the rule instead of forcing manual triage on every finding.
- Use fix rate as a release-quality metric Track fixed findings divided by surfaced findings for each rule and repository, then retire or retune rules that stay low even after contextual tuning.
What's in the full article
Semgrep's full article covers the operational detail this post intentionally leaves for the source:
- How to implement Monitor, Comment, and Block modes across a real SAST workflow
- Rule-level customisation examples for reducing false positives in specific code paths
- Developer-facing fix guidance and contextual remediation patterns tied to findings
- The workflow for validating a rule before escalating it from review to enforcement
👉 Read Semgrep's analysis of customizable SAST policies and developer trust →
SAST policy tuning and false positives: what AppSec teams need now?
Explore further
02/08/2026 1:26 pm
Customisable security policy is the real scaling constraint in AppSec. The problem is not whether SAST can find issues. The problem is whether the findings can be shaped into a workflow developers will actually use. Once a team has to choose between surfacing everything and surfacing nothing, the security control becomes operationally brittle. The practitioner lesson is that policy granularity is a governance requirement, not a comfort feature.
A question worth separating out:
Q: How do teams know whether a SAST rule is actually helping?
A: Look at fix rate, not just finding volume. A useful rule produces issues that developers understand, trust, and resolve at a healthy rate. If fixes stall or findings are routinely dismissed, the rule needs retuning, additional context, or removal from the developer-facing workflow.
👉 Read our full editorial: Customizable SAST policies are becoming the AppSec trust test
