Vulnerability Management for Software Products: How to Detect, Assess and Respond Within 24 Hours

Executive summary For most software companies, a critical vulnerability used to be a technical problem with a flexible deadline. That is changing. Since 11 September 2026, manufacturers selling products with digital elements in the EU must send an early warning about actively exploited vulnerabilities within 24 hours of becoming aware of them. Enterprise customers increasingly write similar expectations into contracts, and attackers now exploit published vulnerabilities within days, sometimes hours. Meeting a 24-hour window is not a matter of working faster when something happens. It depends on what is in place beforehand: a complete inventory of every component in the product, detection that separates real threats from noise, clear decision rights, a pipeline that can ship a fix safely and people available when it matters. This article describes the five building blocks of a vulnerability management process that works under time pressure, the metrics that show whether it is ready and when it makes sense to run it as a managed service.

Why 24 Hours Has Become the Benchmark

Three developments have turned response time into a business issue.

Regulation. Since 11 September 2026, the EU Cyber Resilience Act (CRA) has required manufacturers of products with digital elements to report actively exploited vulnerabilities and severe security incidents, starting with an early warning within 24 hours. The obligation applies to products already on the EU market, not only to new releases, and it covers manufacturers outside the EU that sell into it. We deliberately leave the legal interpretation to legal advisers; what matters here is the operational consequence. A company cannot report within 24 hours what it cannot detect, understand and assess within 24 hours.

Customer expectations. Banks, insurers, manufacturers and public-sector buyers are themselves subject to regulations such as NIS2 and DORA, and they pass security requirements down their supply chains. Questions about vulnerability handling, response times and software bills of materials now appear routinely in security questionnaires and contracts.

Attacker speed. The time between the public disclosure of a vulnerability and its active exploitation keeps shrinking. A process designed around monthly patch cycles leaves a window that attackers are well equipped to use.

Why Most Software Companies Are Not Ready

In our work with software producers, the same gaps appear again and again. None of them is unusual, and most are invisible until the first serious incident.

• No reliable inventory. The team knows its own code, but not every open source library, container base image and third-party SDK in each supported version of the product.
• Too much noise. Scanners report hundreds of findings. Without prioritisation, the one vulnerability that is actively exploited gets lost among those that are theoretical.
• Unclear ownership. When a critical issue appears on a Friday evening, nobody is sure who assesses it, who decides on the response and who informs customers.
• Slow release path. The pipeline was built for planned releases. Shipping an urgent fix means bypassing steps, which introduces new risks.
• Many versions in the field. Customers run older releases, on-premise installations or embedded versions that cannot simply be updated with the next deployment.

Each of these gaps adds hours or days to the response. Closing them is the real work of vulnerability management.

The Five Building Blocks of Fast Response

1. Know What Is in Your Product

Every response starts with one question: are we affected? Answering it in minutes rather than days requires a software bill of materials (SBOM) for every release and every version still supported in the field. The SBOM lists all direct and transitive dependencies, including versions, and should be generated automatically in the CI/CD pipeline rather than compiled by hand.

The SBOM only helps if it is kept up to date and can be searched quickly. When a new vulnerability is published, the team should be able to see within minutes which products, versions and customers are affected.

2. Detect What Actually Matters

Detection combines several sources:

• Software composition analysis to identify known vulnerabilities in dependencies,
• static analysis of the company's own code,
• container and infrastructure scanning for base images, configurations and cloud resources,
• external threat intelligence, such as the CISA Known Exploited Vulnerabilities catalogue or the EPSS score, which estimates how likely a vulnerability is to be exploited.

The key is prioritisation. A vulnerability that is actively exploited and reachable in your product is far more urgent than a higher-scoring one in code that never runs. Teams that triage by exploitation and exposure, not just by severity score, spend their time where it counts.

3. Assess and Decide Quickly

Once a relevant vulnerability is detected, the clock is running. A fast assessment answers four questions: is the vulnerable code actually used, is it exposed, what is the potential impact, and which customers are affected?

Speed here depends less on technical skill than on clearly defined roles. Who confirms the finding? Who decides whether it is critical? Who involves legal and compliance when reporting may be required? Who communicates with customers? These decisions should be documented in a playbook and rehearsed before they are needed.

4. Fix and Ship Safely

A fix that takes two weeks to release does not help much. The release path for security fixes should be as automated and as safe as the normal one: automated tests on critical paths, the ability to release a patch independently of the feature roadmap, and procedures for backporting fixes to older supported versions.

Mature DevOps, cloud security and managed services practices make this possible: infrastructure as code, reproducible builds, controlled deployment strategies and secrets management that does not depend on individual people.

5. Communicate and Learn

Customers need clear, timely information: what is affected, what they should do and when a fix will be available. Internally, every significant event should end with a blameless post-mortem that identifies what slowed the response and what needs to change. Over time, these reviews turn individual incidents into a better process.

What the First 24 Hours Should Look Like

The exact steps depend on the product and the organisation, but a workable timeline for an actively exploited vulnerability looks roughly like this:

The first 24 hours are mostly about knowing and deciding, not about fixing. That is why preparation determines whether the window can be met.

How to Know Whether You Are Ready

A few metrics show whether the process works in practice, not just on paper:

• SBOM coverage: the share of products and supported versions with an up-to-date, automatically generated SBOM.
• Time to triage: how long it takes from detection to a confirmed assessment.
• Time to remediate by severity: how long critical, high and medium vulnerabilities remain open.
• Patch lead time: how quickly a security fix can be released once it is ready.
• Coverage of supported versions: the share of supported releases that receive fixes within the target time.

Running a simulated incident, for example with a recently published vulnerability in a common library, is one of the fastest ways to see where the process breaks.

In-House, Managed Service or a Combination?

Fast response requires people who are available outside office hours. A reliable 24/7 on-call rotation typically needs at least five engineers to be sustainable, which is a significant investment for a mid-sized software company, especially when serious incidents are rare.

For many organisations, a combined model works best. The product team retains ownership of the code and the fixes, while an external partner provides continuous monitoring, alerting and escalation, on-call coverage, incident management with post-mortems and automated collection of compliance evidence. The question is not whether to outsource responsibility, but how to make sure someone competent is always watching.

AI can also shorten parts of the process: summarising security advisories, checking whether vulnerable functions are actually called, proposing dependency upgrades and generating tests for the fix. Used within a governed workflow, as described on our AI-assisted software delivery page, it can remove hours of manual work from triage and remediation. Where the main obstacle is outdated dependencies in legacy code that cannot be upgraded without major changes, an AI refactoring assessment helps identify a realistic modernisation path.

Why Investors Are Paying Attention

Vulnerability handling is also becoming part of how companies are valued. In a technology due diligence, buyers increasingly ask for SBOMs, remediation times and evidence of incident response. A company that can show a working process is a lower-risk acquisition; one that cannot is likely to face price adjustments or specific indemnities.

Response Speed Is Now Part of the Product

Customers no longer judge software only by its features. They also judge how quickly and transparently its producer reacts when something goes wrong. The ability to detect, assess and respond within a day has become a quality attribute of the product itself.

Building that ability does not require a large security department. It requires an accurate inventory, focused detection, clear decision rights, a safe release path and people available when it counts. If you want to assess how ready your product is or set up round-the-clock monitoring and response, let's talk about how our DevOps, cloud security and managed services team can help.

This article describes operational practices and does not constitute legal advice. Whether and how the Cyber Resilience Act applies to a specific product should be assessed with qualified legal counsel.