Notifications
Clear all
Topic starter
20/08/2026 5:52 pm
TL;DR: Modern application vulnerability scanning is being reshaped by 40,009 new CVEs since 2024, a 38% year-on-year increase, alongside AI-generated code that has become a major blind spot for AppSec teams, according to Cycode. The practical shift is from counting findings to proving exploitability, correlating code-to-runtime context, and reducing remediation drag before attackers exploit the gap.
NHIMG editorial — based on content published by Cycode: Application Vulnerability Scanning: Tools and Guide
By the numbers:
- 108 new vulnerabilities are being revealed every day., ry day.
- Security teams are wasting 30% to 40% of their time triaging false positives instead of remediating real risks.
- The average mean time to remediation for high and critical application vulnerabilities now sits at 74.3 days.
Questions worth separating out
A: Prioritise by exploitability, exposure, and business impact, not by severity alone.
Q: Why do AI-generated code and secrets create identity risk for AppSec teams?
A: Because generated code can introduce tokens, keys, and certificates into workflows faster than review processes can catch them.
Q: What breaks when application scanning tools are managed as separate point products?
A: Separate tools create duplicated findings, inconsistent severity scoring, and slower ownership decisions.
Practitioner guidance
- Prioritise by reachable exploitability Use runtime context, internet exposure, and data sensitivity to rank findings above generic severity scores.
- Correlate code, dependency, and secrets findings Merge SAST, SCA, DAST, and secrets alerts into a single remediation record when they touch the same service or release.
- Gate AI-generated code with the same controls as human code Apply policy checks, secret scanning, dependency validation, and review thresholds to generated code before merge.
What's in the full article
Cycode's full article covers the operational detail this post intentionally leaves for the source:
- Detailed breakdown of SAST, DAST, SCA, secrets scanning, and IaC scanning trade-offs across the SDLC
- Per-tool feature comparison for commercial scanners, including scan depth, integration models, and deployment considerations
- Application vulnerability management guidance for teams deciding how to balance speed, false positives, and remediation workflow design
- Cycode's platform-specific discussion of context intelligence, exploitability scoring, and AI-assisted remediation workflows
👉 Read Cycode's guide to application vulnerability scanning tools and methods →
Application vulnerability scanning: what practitioners need to fix now?
Explore further
20/08/2026 6:31 pm
Exploitability, not discovery, is now the real control boundary. The article correctly points to a problem AppSec teams have faced for years: finding vulnerabilities is easier than deciding which ones matter. In practice, raw scan counts create backlog, while runtime context determines whether a weakness is reachable, privileged, or merely theoretical. That makes prioritisation the decisive governance step, especially when application risk intersects with secrets and service access. Practitioners should treat exploitability as the control objective, not a secondary scoring enhancement.
A question worth separating out:
Q: How do you know if application security scanning is actually working?
A: Look for shorter time to remediation, lower false positive rates, and findings that consistently map to fixed issues in release pipelines. If alerts keep recurring with no ownership changes, the scanner is producing visibility without governance. Working scanning changes behaviour, not just dashboards.
👉 Read our full editorial: Application vulnerability scanning now depends on exploitability context
