Notifications
Clear all
Topic starter
01/08/2026 8:53 pm
TL;DR: Legacy SAST is slow, noisy, and often valued as a compliance checkbox rather than a risk-reduction control, while modern AppSec should focus on secure-by-default libraries and lightweight enforcement, according to Semgrep. That shift matters because finding every bug is impossible, but reducing whole vulnerability classes is achievable.
NHIMG editorial — based on content published by Semgrep: why AppSec is shifting from bug finding to secure defaults
Questions worth separating out
Q: How should AppSec teams reduce dependence on noisy static analysis tools?
A: They should use static analysis as one control in a broader prevention strategy, not as the whole programme.
Q: When does bug finding stop being the highest-value AppSec investment?
A: It stops being the highest-value investment when teams spend more time tuning, triaging, and explaining findings than reducing exposure.
Q: What do security teams get wrong about secure defaults?
A: They often treat secure defaults as a developer convenience rather than a control strategy.
Practitioner guidance
- Audit where your AppSec tool is acting as a report generator Identify scanners that produce large result sets but do not change developer behaviour, then separate compliance reporting from control enforcement.
- Shift prevention into shared libraries and framework defaults Prioritise secure encoding, safe data-access patterns, approved auth libraries, and hardened secret-handling modules so developers inherit safer behaviour by default.
- Embed policy checks in CI and code paths Use lightweight enforcement to catch prohibited patterns before merge, rather than depending on periodic expert review.
What's in the full article
Semgrep's full post covers the operational detail this post intentionally leaves for the source:
- How the team evaluates static analysis usability against consultant and AppSec workflows.
- Examples of secure-default patterns in frameworks, libraries, authentication, and secret management.
- The product direction behind lightweight enforcement and custom rule development.
- Why the team sees bug eradication by class as a more practical goal than exhaustive bug finding.
👉 Read Semgrep's analysis of why AppSec is shifting from bug finding to secure defaults →
AppSec bug finding vs secure defaults: what should teams prioritise?
Explore further
01/08/2026 9:02 pm
Bug-finding-first AppSec has hit a governance ceiling: when controls require expert tuning, long scan cycles, and heavy triage, they cease to function as reliable security mechanisms and become compliance theatre. This is especially visible in application security programmes that measure output volume instead of reduction in exposed risk. The operational lesson is that control design must fit developer velocity, or it will be bypassed in practice.
A question worth separating out:
Q: How can organisations measure whether AppSec controls are working?
A: They should look for fewer repeat vulnerabilities, lower false-positive burden, faster developer adoption, and measurable reduction in high-risk bug classes. A healthy AppSec programme changes the shape of risk, not just the number of alerts. If findings remain high but exposure does not fall, the control model is not scaling.
👉 Read our full editorial: AppSec is shifting from bug finding to secure defaults
