Traditional SAST and DAST programs create friction because they often depend on buildable code, heavy processing, and large scan outputs that developers must interpret without context. In monolithic environments, scans can take hours and produce thousands of alerts, most of them false positives. That combination makes security feel disconnected from delivery and pushes teams to postpone or ignore findings.
Why This Matters for Security Teams
Traditional SAST and DAST programs create friction when they are introduced as large, centralised checkpoints instead of as controls that fit delivery cadence. Security teams then inherit noisy findings, slow feedback, and a mismatch between what developers can fix quickly and what scanners report. That gap matters because it turns security into a queue, not a decision point, which reduces trust in the program and weakens remediation discipline.
From an operating-model perspective, this is not just a tooling issue. It affects vulnerability prioritisation, exception handling, release governance, and how product teams perceive risk ownership. A program that generates too much unreconciled output often causes teams to suppress alerts, narrow scan scope, or treat evidence as compliance artefact rather than actionable security data. The most effective programs align findings to application criticality, deployment stage, and business impact, which is consistent with the NIST Cybersecurity Framework 2.0 emphasis on risk-informed control execution. In practice, many security teams encounter the failure of SAST and DAST only after release bottlenecks, developer fatigue, and backlog growth have already become normalised.
How It Works in Practice
SAST and DAST are intended to support secure software development, but friction appears when they are used without regard to code structure, delivery model, or test environment quality. SAST often depends on source access, language support, and rules that can over-report patterns that are safe in context. DAST depends on a reachable application and stable test data, which means it can miss issues in ephemeral environments or create long delays when authentication, state, or business logic is complex. In both cases, the technical signal can be sound while the operational experience is poor.
Current guidance suggests making the pipeline more selective and contextual. That usually means:
- Scoping scans to components that actually changed, rather than scanning everything every time.
- Tuning rules by language, framework, and application tier so that known-safe patterns do not flood teams.
- Using severity, exploitability, and asset criticality together, not severity alone.
- Pairing scanner output with runtime evidence, code ownership, and remediation deadlines.
- Separating release-blocking issues from backlog issues so delivery is not held hostage by low-value noise.
Security leaders also need a review loop that measures whether findings led to code changes, configuration fixes, or compensating controls. Without that loop, the organisation learns only that scans ran, not that risk fell. For threat modelling and control mapping, teams often complement application scanning with the NIST Cybersecurity Framework 2.0 to keep findings tied to governance and response decisions. These controls tend to break down when applications are highly dynamic, authentication is federated across many services, and test environments cannot reproduce production behaviour because the scanner sees a moving target rather than a stable application.
Common Variations and Edge Cases
Tighter scanning coverage often increases developer overhead, requiring organisations to balance detection depth against delivery speed and maintenance effort. That tradeoff becomes sharper in monoliths, legacy stacks, and hybrid environments where build pipelines are inconsistent and application behaviour is difficult to reproduce. In those settings, a strict scan-everything model often creates more friction than insight.
There is no universal standard for how many false positives is acceptable, but best practice is evolving toward risk-based thresholds and ownership models. Teams with mature DevSecOps programmes often treat scanner output as one input to triage, not as a verdict. That approach works better when the security team can distinguish exploitable defects from theoretical findings, and when developers can see which issues block release versus which can be deferred.
Identity and access patterns can also change the picture. If an application relies on service accounts, secrets, or privileged automation, SAST and DAST may miss the operational risk unless those identities are included in the review. That is where the security question shifts from code scanning alone to broader control design, including secrets governance and privileged access monitoring. Friction falls when the program is tuned to how software is actually delivered, not how a scanner assumes it is built.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Risk-informed control selection fits noisy SAST and DAST programs. |
Set scan thresholds and remediation priorities using business risk, not raw alert volume.
Related resources from NHI Mgmt Group
- Why do university access programs create so much identity friction?
- Why do traditional application security workflows create friction in modern DevSecOps environments?
- Why do unmanaged or inconsistently managed devices create so much risk for compliance and security programs?
- Why do traditional AST-based analysis frameworks create more friction for application security teams?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
