Scanning alone won't satisfy NIS2, the Cyber Resilience Act (CRA) or BSI C5. How to set up vulnerability management the right way with SBOM, VEX & ASPM.
Driven by regulations such as NIS2 and the Cyber Resilience Act (CRA), more and more companies are starting to systematically scan their systems for security vulnerabilities. Getting started looks easy: there is a suitable scanner for almost every part of the tech stack—from open-source tools like Trivy, Syft or Dependency-Track to commercial solutions like Snyk or SonarQube—and most of them plug into existing CI/CD pipelines in no time.
But as so often, the devil is in the details. Simply scanning code and containers comes nowhere near meeting today's NIS2 requirements or the obligations of the Cyber Resilience Act.
Every major security standard—whether NIS2 (in particular Art. 21 on security in software development), Germany's BSI IT-Grundschutz (module CON.8), ISO 27001 or a BSI C5 attestation, Germany's cloud security standard—demands far more than finding bugs once. They require continuous, end-to-end vulnerability management. And that is exactly what puts organizations under enormous pressure: suddenly, installing a scanner is no longer enough. Engineering, compliance, product management and executive leadership have to work in close lockstep so that, when it counts, risks are assessed quickly and fixed on time.
In practice, however, many companies that are only just building this process end up with the opposite: instead of clear workflows, they get an unmanageable data backlog. To make sure that doesn't happen to you, we walk through the three most common mistakes in vulnerability management—and how to avoid them.
1. Confusing vulnerability scanning with real vulnerability management
A CVE scanner or a static application security testing (SAST) tool answers exactly one question: which known vulnerabilities can be detected in this system right now? For vulnerability management that actually works—let alone for an audit—that snapshot is not enough.
A simple thought experiment: a company scans its applications every Monday and gets a report with 100 findings each time. How is its application security doing? Impossible to say. It could be the same 100 legacy issues for months on end. Or 80 problems may have been fixed while new releases introduced 80 new ones. Without a clean history, you are completely in the dark.
In modern software landscapes, this gets complicated fast. Separate tools usually run side by side for container security, software composition analysis (SCA) and first-party application code. Their results overlap, use different naming and produce raw data that first has to be mapped to the right services and teams.
On top of that, vulnerability data changes. A bug first appears as a GitHub Security Advisory (GHSA), receives an official CVE ID days later, and a week after that its severity or the affected versions change. If you don't merge this information automatically, you will quickly drown in duplicates and stale tickets.
SBOM and software supply chain: worthless without history
The difference between a vulnerability itself and its concrete occurrence also tends to get lost. If the same vulnerable library sits in five different microservices, that is technically a single vulnerability—but in practice it is five distinct risks, each with its own release cycle and its own exposure.
This becomes especially clear in the software supply chain. Today's applications consist mostly of external frameworks, which in turn pull in dozens of transitive dependencies. A machine-readable SBOM (Software Bill of Materials), as required by the Cyber Resilience Act—for example in CycloneDX or SPDX format—does provide important transparency into the components you ship. But a static SBOM is out of date the moment the next commit runs through the pipeline.
So the problem is rarely the scanners themselves. Tools like Trivy, Grype or Dependency-Track do excellent groundwork. Things only start to grind when their results are viewed in isolation and copied together into spreadsheets by hand. What companies need is not a pile of disconnected findings, but a continuous history across the entire lifecycle of an application.
2. Prioritizing without application context and reachability analysis
Once several scanners deliver results on a regular basis, the inevitable question follows: where do we start? The classic approach is to sort by technical severity (CVSS score): “Critical” first, then “High”, everything else later.
That looks logical on paper, but it misses reality. A vulnerability's theoretical CVSS score says little about the actual risk to a specific application.
A well-known example is npm audit. By default, the tool also checks development dependencies—packages that are only needed locally for tests or the build process. If the dependency scanner reports a critical vulnerability there, it is usually irrelevant for the production system, because that code is never shipped to production at all. Conversely, a vulnerability with a medium score in a publicly reachable API endpoint can be a wide-open door for attackers.
Even when a vulnerable package is running live in production, that does not mean it is exploitable. This is where reachability analysis comes in: is the vulnerable function actually called in your own code? Does external user input reach that point unfiltered? A pure dependency scanner cannot see this. That takes context about the application code, the execution paths and the runtime environment.
Security always competes with the product roadmap
One point is easily overlooked when implementing NIS2 or introducing DevSecOps processes: fixing vulnerabilities costs development time. And development time is scarce.
Engineering teams and product managers make trade-offs every day: do we build the new feature, solve the performance problem or pull the security update forward? Not every finding justifies abandoning the current sprint.
Meaningful prioritization therefore has to account not only for technical risk and exploitability, but also for the real remediation effort and regulatory deadlines. An overdue issue that a five-minute version bump can resolve should, when in doubt, take precedence over a theoretically critical vulnerability that is not even reachable in your architecture but would require rebuilding half the system to fix.
Without this differentiation, the backlog fills up with hundreds of “critical” tickets. The result is alert fatigue: when everything is top priority, nothing is a priority anymore. Teams keep pushing security tasks down the road—not out of indifference, but because they lack a reliable basis for deciding where their time is actually well spent.
3. Not measuring reliable metrics for management and auditors
How does executive leadership actually know that its vulnerability management measures are working? While almost every other business function is run on clear KPIs, security reporting is often reduced to a single number: the total of open findings by severity.
On its own, that number is close to worthless for steering the program and for compliance evidence.
Imagine a company where 100 new findings come in every week. If the teams ship 120 fixes in the same period, they are steadily reducing technical risk. If they close only ten, the backlog grows relentlessly—even though the weekly scan report looks almost identical at first glance.
What matters is not the raw count, but the dynamics: how quickly are problems resolved, and which risks remain open?
The metrics that really count for NIS2, CRA and C5:2026
A key metric is Mean Time to Remediation (MTTR), the average time from detection to fix. But here, too, it pays to look closely: a good average can easily hide the fact that many simple vulnerabilities are closed quickly while highly critical issues stay open for months. MTTR should therefore always be broken down by risk class and complemented by the age of open findings.
Beyond that, modern regulations demand hard evidence of your processes:
- Meeting CRA reporting obligations: Since September 2026, the Cyber Resilience Act's reporting obligations apply to actively exploited vulnerabilities—including a 24-hour deadline for the early warning and 72 hours for the detailed notification. Without a clear view of which component sits in which product and whether it is actually exploitable, these deadlines are almost impossible to meet.
- VEX (Vulnerability Exploitability eXchange) & documented decisions: Not every vulnerability in an SBOM requires an immediate software update. Sometimes the vulnerable code is not reachable, the risk is mitigated by other controls, or it is deliberately accepted. Standardized formats such as VEX, combined with clean status tracking, let you document these decisions in a way customers and auditors can follow.
- Real deployment status for BSI C5 & audits: The updated BSI C5:2026 criteria catalog in particular places much more weight on rigorous patch, vulnerability and container management. A closed developer ticket in Jira is not sufficient evidence here—what matters is that the fix has demonstrably been rolled out to every production environment.
Only this end-to-end tracking creates the data foundation for auditors and your own management. Without this transparency, you can neither prove in an audit that the process is actually lived nor judge internally whether additional security investments are really paying off.
Conclusion: compliance and security need processes, not just scanners
Vulnerability scanners are the indispensable foundation of application security, but on their own they deliver only raw data. Real security—and robust compliance for NIS2, the CRA, ISO 27001 or BSI C5—only emerges when engineering, security and compliance owners work from the same data.
Today, the biggest danger is no longer technically missing a vulnerability. The risk is that the truly critical problems get lost in the background noise of hundreds of unprioritized alerts. Successful vulnerability management is therefore measured not by the number of bugs found, but by how reliably and efficiently a company reduces its actual risks.
Automating vulnerability management and ASPM with Farion
We built Farion precisely to bridge the gap between technical scanners, engineering teams and regulatory requirements. As an Application Security Posture Management (ASPM) platform, Farion brings together results from a wide range of security analyses and open-source scanners in one place and enriches them with the context that matters: by analyzing dependencies (SBOM), actual reachability in the code (reachability analysis) and exploitability, teams see immediately which risks are truly relevant to their applications.
Intelligent prioritization combines technical risk with urgency, SLA targets and remediation effort. At the same time, a complete history makes progress measurable, so you can show executive leadership and auditors at any time that your security risks are under control.