Continuous vulnerability management with AI for CRA requirements

Security teams relying on quarterly scans and spreadsheets cannot physically meet the 24-hour notification window for active exploits. Risk management automation is now a legal requirement for operating in the European market.

The Cyber Resilience Act (CRA), a natural evolution of the directives born with the EU Cybersecurity Act, ties access to the European market to strict security standards¹. By placing server operating systems and container runtimes in Class II of critical products², the regulation subjects the core components of modern infrastructure to the strictest controls provided by law.

The 2024 OSSRA report highlights how 91% of repositories contain components that are at least 10 versions behind³. Tracking vulnerabilities across these volumes to maintain CE marking exceeds the capabilities of any human team.

Implementing continuous vulnerability management driven by AI allows machine learning systems to handle massive data analysis. Integrating machine learning into workflows shifts security control from an isolated event to a process metric, provided the reliability of the decision-making models used is precisely measured.

Why reactive vulnerability management is no longer enough for the Cyber Resilience Act

Reactive vulnerability management fails under the Cyber Resilience Act because the legislation mandates the notification of active exploits within 24 hours for the entire product lifecycle. Traditional periodic scans generate unacceptable delays, exposing the company to fines of up to 15 million euros and sales bans.

Article 14 of the regulation defines inflexible reporting timelines to ENISA⁴ and national CSIRTs. The European legislator has eliminated the distinction between development and maintenance, forcing manufacturers to ensure constant security standards even years after the initial release.

To frame the regulatory perimeter and understand which responsibilities fall on the manufacturer, we have already explained how to identify the risk classes provided by the CRA in a dedicated article of this series.

The economic risk directly impacts business continuity, as national authorities gain the power to impose product withdrawals and bans on placement in the European market⁵. Added to this are fines for non-compliance with essential security requirements reaching up to 15 million euros or 2.5% of the company’s total global annual turnover, whichever is higher.

Faced with thousands of software dependencies layered over time, the volume of CVEs (Common Vulnerabilities and Exposures) to be manually evaluated grows faster than remediation capacity. The backlog accumulates, extending the MTTR (Mean Time To Remediation)—the average time between the discovery of a vulnerability and its resolution. A quarterly scan leaves weeks uncovered where an active exploit can hit systems. Manual prioritization is also subject to cognitive biases, leading analysts to overestimate known CVEs and underestimate contextual ones. Without a map of real exposure, every vulnerability seems equally urgent, and reconstructing an incident’s causal chain in a few hours becomes mathematically impossible.

How AI transforms vulnerability management into a continuous process

Artificial intelligence transforms vulnerability management by automating prioritization and reducing false positives. By correlating CVEs with actual code exposure in production, AI allows teams to focus on real risks, slashing the mean time to resolution and ensuring compliance with regulatory notification windows.

In our approach to complex fintech projects in 2023, managing over 400 repositories and thousands of historical CVEs, the integration of automation and contextual correlation generated measurable efficiency metrics. In our experience, starting from a baseline of 14 days, we believe the structured flow slashed the MTTR to less than 48 hours, with an estimated reduction of around 80%. This result stems from a process that crosses dependency identification, vulnerability databases, and continuous validation with selective blocking. The technological foundation lies in software lifecycle automation, a field we explored by analyzing how artificial intelligence is redesigning DevOps pipelines and security processes.

The AI-driven flow operates in four sequential phases:

1. Ingestion: continuous collection of SBOMs, logs, and runtime data from pipelines and production environments.
2. Correlation: automatic cross-referencing of components with vulnerability databases and active exploit indicators.
3. Prioritization: ranking of CVEs based on real impact on the product, not just theoretical severity.
4. Notification: generation of the audit trail needed to comply with ENISA reporting timelines.

Intelligent prioritization and noise reduction

Contextual prioritization distinguishes a useful alert from background noise. AI correlates each CVE with the real exposure context, verifying if the asset is in production, if the vulnerable code is actually called by the application flow, and if an active exploit is circulating.

In the same 2023 fintech program, where scanners on 400 repositories produced an average of over a thousand reports per week, contextual correlation cut the volume of alerts requiring human intervention by about two-thirds. Instead of manually sorting through hundreds of undifferentiated reports, the team intervened exclusively on flaws with a real impact on the product subject to CE marking.

Continuous monitoring and detection of anomalies

Anomaly detection models observe runtime behaviors and signal deviations from a learned baseline. This mechanism anticipates the exploitation of vulnerabilities not yet cataloged, shifting the security posture from reactive to proactive.

The DORA regulation⁶, relevant for those operating in the financial sector, presents similar dynamics. Both directives push toward continuous monitoring of digital risk, but with a different focus, as we analyzed when examining the impact of NIS2 and DORA on cloud-native cybersecurity.

The CRA looks at the product, while DORA looks at the entity. A financial company that develops software often falls under both, making continuous monitoring a double legal obligation.

What AI observability means and why it matters for compliance

AI observability consists of constantly monitoring data quality, model drift, and the reliability of decision-making outputs. For regulatory compliance, overseeing intelligent systems is mandatory: a degraded model generating false negatives exposes the product to undetected vulnerabilities, compromising CE marking.

Artificial intelligence observability ensures that automation tools do not introduce new blind spots. A system that misclassifies vulnerabilities causes active harm by ignoring threats it should block. ML observability thus becomes an integral part of the security chain. Introducing AI models into defensive processes requires transparency and risk management, as the manufacturer must account for automated decisions to maintain compliance.

Monitoring the models that monitor security

Three signals define the health of a model applied to security: data quality monitoring, drift detection, and output explainability. Drift is particularly insidious because it acts silently. A model trained on a certain threat profile degrades as attack types evolve, without generating obvious errors in traditional logs.

The category of data observability, represented on the market by tools like IBM Databand⁷, was born specifically to oversee the data pipelines that feed models. To delve deeper into control strategies for probabilistic systems, we described how to govern and monitor AI agents in production, a topic that applies with the same logic to security tools.

Guardrails and traceability of automated decisions

Compliance requires documented proof of how a specific vulnerability is classified and managed. An audit trail of AI decisions and guardrails are needed to prevent unverified automatic actions, especially when the outcome influences the validity of the CE marking.

Our security-by-design approach establishes that automation must empower teams while maintaining human control over critical decisions. It is necessary to monitor the quality of the data entering the model and measure drift relative to the training baseline. It becomes equally important to evaluate the decision latency between detection and classification, keeping the false negative rate under strict control.

Implementing continuous vulnerability management: what is really needed

Implementation requires a structured path: gaining total visibility into dependencies via SBOM, automating risk prioritization, and continuously monitoring AI models. This approach transforms regulatory compliance into a process integrated into DevSecOps pipelines, avoiding the bottlenecks typical of manual checks.

The first phase starts with the dependency inventory. We explored this aspect by explaining how the Software Bill of Materials maps supply chain risks under the CRA: without an updated SBOM, any automation works on incomplete data. Management risks require immediate attention, as blindly relying on AI without human supervision turns a mitigation tool into a single point of failure. This is followed by insufficient training data quality and friction in integration with existing DevSecOps pipelines. In these flows, security gates must block non-compliant releases without paralyzing development speed.

The reconciliation between CRA requirements and operational sustainability sees our team directly involved. Our CTO Paolo Mainardi is an Advisory Member of Linux Foundation Europe⁸ and supported the #FixTheCRA initiative, created to prevent the regulation from penalizing the open-source ecosystem⁹. Foundations like the Apache Software Foundation and the Eclipse Foundation expressed strong criticism of the initial text, later welcoming the late 2023 amendments¹⁰.

Measuring the real maturity of the process requires precise indicators:

• Updated and versioned dependency inventory (SBOM).

• Measurement of MTTR as an actual process metric and not just a simple estimate.

• CI/CD pipelines with active and blocking security gates.

• Continuous monitoring of the AI models used.

• Notification process capable of operating within strict regulatory timelines.

The absence of even one of these requirements leaves the exposure to legal risk open.

Conclusion and next steps

Automating vulnerability management through AI transforms compliance with the Cyber Resilience Act into a sustainable process, eliminating the race against time with every new CVE.

Fines of up to 15 million euros clearly define the business risk. At the same time, the 80% reduction in mean time to resolution (MTTR) quantifies the return on technical investment.

Assessing your process maturity requires inventory analysis, MTTR measurement, and verification of the AI models in use. To turn this assessment into an operational strategy across the entire chain, our specialists can accompany you in securing your software supply chain.

The next article in the series addresses the architectural and strategic criteria for choosing and implementing software solutions capable of maintaining CE compliance throughout the product lifecycle, providing agnostic guidelines for tool selection.

Notes and sources