How Often Should You Actually Scan Your Code? A Practical Guide for a Growing Company

The average codebase now ships with 581 known vulnerabilities, up 107% from 280 the year before, and most sit in dependencies, not proprietary code. AI pushed code volume up another order of magnitude: 27% of production code is now AI-generated, with 48% carrying at least one security vulnerability.

Attack surface moved from the code to the components we import and the pipelines that build them. It requires regular scanning for all types of triggers, configured to match code velocity.

Mapping below covers OWASP Top 10 coverage per scan type, cadence, SDLC position.

 

SAST on every commit

Static analysis runs on source code. Catches the issues from OWASP Top 10: injections, broken access control, crypto missteps, insecure configurations, error handling that fails open. Modern SAST extends to IaC, Container images, API configurations, ML pipeline code. Runs without executing the code, so it can run anywhere, including the developer's IDE.

Trigger: every commit. Results show up before code review.
Leverage: catching a SQL injection while the developer is still thinking about the code takes two minutes to fix. Catching it three weeks later is a half-day context switch plus the cost of the fix. IBM Cost of a Data Breach and internal DevOps research put the gap at 30x to 100x between fixing in development versus production.

A SAST tool that takes two hours to scan won't run on every commit. Developers route around it with incremental scanning (analyze only what’s changed), IDE integration, false positive rates low enough that developers don't learn to ignore output. DerScanner SAST integrates with IntelliJ IDEA, Eclipse, Visual Studio, Visual Studio Code.

 

SCA on every pull request, full scan weekly

SCA examines dependencies the code pulls in: direct (declared in package.json or requirements.txt) and transitive. 

Trigger: every PR that touches a dependency manifest, plus a weekly full scan of all production services. PR scan catches new vulnerabilities before merge. Weekly scan catches dependencies that were safe when adopted but became vulnerable later as new CVEs are disclosed against versions you're still running.

What separates useful SCA from noise is reachability analysis. Does the code actually call a vulnerable function, or is it dead code in a library you happen to import? Without reachability it’s just a CVE list. With reachability this list becomes a prioritized one with exploitable risks. 

DerScanner SCA does reachability plus Supply Chain checks (typosquatting detection, MavenGate monitoring, starjacking analysis, dependency health scoring) for the supply chain patterns pure CVE matching misses.

 

 

DAST on every staging deployment

DAST runs against a running application, probing endpoints with malicious inputs. Catches what static analysis can't see: runtime configuration errors, auth and session flaws, business logic vulnerabilities, the gap between what the code says and what the deployed system does.

Trigger: every staging deployment before promotion to production. Don't run DAST in production. Fuzzing and malformed requests can cause real outages.

Coverage: A01 Broken Access Control (still #1), A02 Security Misconfiguration (now #2), A10 Mishandling of Exceptional Conditions, where DAST is particularly effective because it can trigger the error states exception-handling vulnerabilities depend on.

 

 

SBOM per release

SBOM is a structured inventory of every component in a release: direct and transitive dependencies, version numbers, license info, vulnerability state at release time. Not a scan in the same sense, it's an artifact produced by the build.

Trigger: every release. 

Required for compliance: EU Cyber Resilience Act mandates SBOMs for products with digital elements; PCI DSS 4.0.1 requires component inventory; enterprise procurement asks for SBOMs as part of due diligence. 

Incident response: when the next Log4Shell-class vulnerability drops, the first question is “are we using it?” An SBOM gives an answer in minutes instead of days.

 

 

The decision matrix

 

What to do when scans fail? SAST blocks merge for high-severity issues, SCA blocks merge for known-exploitable CVEs, DAST blocks promotion to production for critical findings, SBOM is informational.

 

What scales and what not

 

The cadence above scales to roughly 200 engineers and a dozen services without structural change. What breaks at that scale is triage capacity. The security engineer who reviewed every finding at 60 people can't at 200.

What doesn't scale: four scan types with disconnected point tools. The integration tax (context switching, duplicate findings, manual correlation) becomes the work itself.

Start with the four scan types on the four triggers. Get the cadence right. Tune false positives until developers stop ignoring output. You’re flawless.

DerScanner provides SAST, DAST, SCA with reachability, MAST, Binary Analysis, AI-assisted triage in a single platform. CI/CD: Jenkins, TeamCity, Azure DevOps, GitLab CI. IDE: IntelliJ IDEA, Eclipse, Visual Studio. Request a PoC.