Notifications
Clear all
Topic starter
02/08/2026 9:47 am
TL;DR: Application security testing still breaks down when SAST, DAST, SCA and runtime checks are run as isolated tools, creating duplicated alerts, missing context and slow remediation, according to OXSecurity. The operational shift is toward integrated AST that pushes exploitability-aware findings into developer workflows and enforces policy across the SDLC.
NHIMG editorial — based on content published by OXSecurity: Application security testing across the SDLC
By the numbers:
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: How should security teams implement SAST across many repositories without creating alert fatigue?
A: Start by tuning rules to the delivery workflow, then route findings into pull requests or IDEs where developers already work.
Q: Why do application security findings often fail to get remediated?
A: They usually fail because the finding arrives without ownership, runtime context or a workflow path developers actually use.
Q: What do security teams get wrong about shift-left AST?
A: They often assume earlier scanning is enough, when the real value comes from fast, contextual feedback and enforcement.
Practitioner guidance
- Implement PR-gated diff-aware scanning Run SAST and secrets checks only on changed code in pull requests, then block merge on high-severity findings so remediation happens before the defect reaches CI.
- Correlate findings to one asset and owner Deduplicate SAST, DAST and SCA outputs against the same repository, service and team so the same defect does not create multiple tickets.
- Extend testing into staging and runtime Use DAST, IAST or RASP in staging and production-like environments to confirm whether auth flows, routing and business logic are actually reachable.
What's in the full article
OXSecurity's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step AST tooling comparisons across SAST, DAST, IAST, MAST and SCA for different maturity stages
- Implementation examples for GitHub Actions, GitLab CI and staging-based runtime testing workflows
- Practical guidance on deduplication, ownership mapping and exploitability scoring inside developer workflows
- The source’s control-mapping discussion for linking findings to compliance and delivery processes
👉 Read OXSecurity's guide to operationalising application security testing across the SDLC →
SAST, DAST and SCA silos: what AppSec teams need to fix?
Explore further
02/08/2026 12:39 pm
Siloed AST creates governance debt, not just operational noise. When SAST, DAST, SCA and runtime testing produce disconnected outputs, the organisation does not have a security testing programme, it has a collection of partial control signals. That fragmentation makes ownership ambiguous and hides exploitability behind duplicate alerts. The practical conclusion is that AST maturity is a workflow problem before it is a tooling problem.
A question worth separating out:
Q: What should organisations do when a secret is found in a pipeline?
A: They should invalidate the credential, review the pipeline account that used it, and check for other copies in logs, artifacts, and environment variables before the old value can be reused. If the secret still works anywhere, the exposure is still active.
👉 Read our full editorial: Application security testing fails when tools stay siloed
