Vulnerability Scanning: Automated Detection as Compliance Evidence

The Detection Gap

A well-meaning developer adds a popular open-source library to your project. The library has 50,000 stars on GitHub. It looks trustworthy. But it has a zero-day vulnerability disclosed three days later. Without vulnerability scanning, you don't know this vulnerability exists in your codebase. Without a scanning process, you might never know—until an attacker exploits it.

This is the detection gap. Vulnerabilities exist in your code, and you have no mechanism to find them. You're hoping no one else finds them first.

Types of Vulnerability Scanning

Different scanning types catch different issues:

SAST (Static Application Security Testing)

Scans your source code for insecure patterns. SQL injection, hardcoded secrets, unsafe crypto usage. Works without running your code. Catches issues during development.

SCA (Software Composition Analysis)

Scans your dependencies. npm packages, Python packages, Maven libraries. Matches them against known vulnerability databases. Tells you if you're using a package with a disclosed CVE.

DAST (Dynamic Application Security Testing)

Runs your application and sends it malicious input. Tries common attack vectors. Tests authentication, authorization, injection attacks. Catches issues that only appear when the code runs.

Container Scanning

Scans Docker images before deployment. Checks for vulnerable base images, vulnerable system libraries. Prevents known vulnerabilities from reaching production.

Integration Points

Mature vulnerability scanning is woven throughout your workflow:

• Pre-commit: Catch secrets before they're committed to the repo.
• Pull request: Run SAST and SCA on every PR. Flag vulnerabilities before merge.
• Pipeline: Run full scanning suite. Block merge if vulnerabilities are found.
• Production: Continuous scanning of deployed images and dependencies. Alert if a new CVE affects running code.

Enforcement Is Key

A vulnerability scanner that runs but doesn't block merges is just reporting. It doesn't prevent vulnerabilities from reaching production. High-maturity scanning enforces policies: if a critical CVE is found, the PR cannot merge. If a Dockerfile uses a vulnerable base image, it cannot be deployed.

How Concordance Scores It

Concordance queries your scanning tools (GitHub Advanced Security, GitLab SAST, Snyk, Dependabot, Aqua, etc.) and measures:

• Is SAST enabled? Does it run on every PR?
• Is SCA/dependency scanning enabled?
• Is container scanning enabled before deployment?
• Are failing scans blocking merges or just reporting?
• What's your vulnerability backlog? (Found but unresolved.)
• How quickly are vulnerabilities resolved after discovery?

A team with comprehensive scanning at all integration points, blocking on critical vulnerabilities, and a low backlog scores high. A team with no scanning, or scanning that reports but doesn't enforce, scores low.

CRA Relevance: Mandatory for Vulnerability Disclosure

The CRA requires the ability to disclose vulnerabilities. But you can only disclose vulnerabilities you know about. Automated vulnerability scanning is how you know. It's how you fulfill the "secure-by-design" requirement. It's how you can honestly say you have a vulnerability management process.

When a CRA auditor asks "How do you identify vulnerabilities in your code?", you point to your SAST. When they ask "How do you manage open-source dependencies?", you point to your SCA. When they ask "How do you prevent vulnerable code from reaching production?", you show them your scanning gates in the pipeline.

Without automated scanning, you're managing vulnerability disclosure by luck. With it, you have a process.