The vulnerability management lifecycle for software vendors

What is the vulnerability management lifecycle?

The vulnerability management lifecycle is the repeatable process a product vendor follows to handle a vulnerability in software it ships: receive or find it, verify it, work out what is affected, fix it, release the fix and tell customers. In a vendor organization it is usually run by a product security incident response team (PSIRT), with engineering teams doing the fixes.

This page covers the vendor side. IT vulnerability management, scanning and patching the servers and laptops an organization runs, shares the vocabulary but not the hard parts. A vendor has to answer for every supported release in customers' hands, and has to publish what it found.

The stages of the lifecycle

1. Receive or discover. Vulnerabilities arrive from outside researchers through your disclosure program, from customers, from coordinators such as national CSIRTs, and from your own monitoring: a new CVE in an open-source dependency, a scanner finding or an internal test. Log each one with a tracking ID and acknowledge external reporters.
2. Verify and triage. Reproduce the issue or confirm the dependency match, decide whether it is a vulnerability in your product, and rate how severe and how urgent it is. Close what does not apply, with a reason you can show later. Prioritization signals such as EPSS and the CISA KEV catalog help rank what remains.
3. Assess affected products and versions. Find every product, release and supported branch that contains the vulnerable code or component, and every customer deployment that runs one. This step decides the scope of the fix and the advisory.
4. Remediate. The owning team develops and tests a fix: an upgraded dependency, a code change, or a mitigation such as a configuration change when a fix is not yet possible.
5. Release the fix. Ship updated versions for each affected supported branch, through a channel customers can trust.
6. Advise and disclose. Publish an advisory that says what is affected, how severe it is and what to do, assign or reference a CVE ID, and credit the reporter. Machine-readable formats such as CSAF and VEX let customers process advisories automatically.
7. Monitor and learn. Watch for exploitation and new information, update the advisory, and feed the root cause back into development so the same class of flaw does not ship again.

ISO/IEC 30111 and ISO/IEC 29147

Two international standards describe this lifecycle for vendors. They split it at the edge of the organization:

	ISO/IEC 30111:2019	ISO/IEC 29147:2018
Title	Vulnerability handling processes	Vulnerability disclosure
Covers	What happens inside: verifying, investigating, prioritizing and remediating	The interfaces: receiving reports and publishing advisories
Key content	Policy and organization, PSIRT responsibilities, handling phases, supply chain considerations	Stakeholder roles, report handling, advisory contents, coordination, disclosure policy
Audience	Vendors handling reported vulnerabilities	Vendors that receive reports and disclose vulnerabilities

The standards are designed to be used together. ISO/IEC 30111 names six handling phases: preparation, receipt, verification, remediation development, release and post-release. It also asks for process monitoring, confidentiality of vulnerability information, and attention to the supply chain, since many vulnerabilities sit in components you did not write. Both standards are current editions, confirmed at their last ISO reviews, and are marked for revision.

Other frameworks follow the same shape. The FIRST PSIRT Services Framework groups the work into vulnerability discovery, triage and analysis, remediation and disclosure, and IEC 62443-4-1 includes security update and defect management in its secure development lifecycle for industrial products.

Roles

• PSIRT or product security team: owns the process, receives reports, triages, coordinates fixes and publishes advisories. See CRACI for PSIRT teams and how a PSIRT differs from a CSIRT.
• Product and engineering teams: own the code, develop and test the fixes, and ship the releases.
• Release management: decides which supported branches get a fix and when.
• Customer support and communications: handle customer questions and the advisory's audience.
• Legal: advises on disclosure, contracts and regulatory notifications.
• External parties: reporters, coordinators such as CERT/CC or a national CSIRT, upstream maintainers of affected components, and customers who must deploy the fix.

Timelines and SLAs

There is no single required timeline. Most vendors set internal targets by severity and publish the external ones in their disclosure policy. A typical structure:

• Acknowledge an external report within a few business days.
• Triage within days, so the reporter and the owning team know where it stands.
• Remediate on a clock set by severity and exploitation, shortest for critical findings and anything known to be exploited.
• Disclose when the fix is available, or at an agreed deadline if the fix slips.

Outside pressure sets the outer bound. Researchers often set a disclosure deadline (Google Project Zero gives vendors 90 days), and regulation is adding its own: the EU Cyber Resilience Act requires manufacturers to remediate vulnerabilities "without delay" and sets reporting deadlines for actively exploited ones (see what the CRA requires). When a vulnerability is already exploited, as with a zero-day, every stage runs on the shortest clock.

Where the lifecycle breaks

Most delays are not in writing the fix. They come from not knowing what you shipped.

• Not knowing which releases contain a component. A new CVE lands in a library. Which of last year's releases include it, and which customers run them? Without a per-release record, teams rebuild old tags or search repositories by hand, and the affected-version list in the advisory is a guess.
• Transitive dependencies. Many vulnerable packages are not ones you chose. They arrive as transitive dependencies several levels down, so a search of your manifests misses them.
• Development dependency noise. Scanners that read lockfiles report test frameworks and build tools that never ship. Each one costs triage time and buries the findings that matter.
• Components outside the package manager. Binaries downloaded by build scripts, base images and vendor components do not appear in a lockfile at all.
• Unclear ownership. A finding that no team owns waits. Triage is only finished when the fix has an owner.
• Fixes that do not stick. A vulnerable version comes back through another dependency or an old branch, because nothing stops it entering the next build.

Metrics

Metric	What it shows
Time to acknowledge	Whether reporters hear back when your policy says they will
Time to triage	How long a finding waits before anyone knows whether it matters
Time to remediate, by severity	How fast fixes ship, measured from receipt to an available release
Time to advisory	How long customers wait for information after the fix
Share within target	Whether internal SLAs hold, especially for critical and exploited findings
Backlog by age	Findings that are stuck, and where
Not-affected rate	How much triage effort goes to findings that do not apply

Measure each stage separately. A long time to remediate often turns out to be a long time to find the affected releases.

Run the lifecycle on a record of what you shipped

Every stage after triage depends on knowing what is in each release. CRACI runs your GitHub Actions builds on its own runners and records the packages each job actually fetched, including transitive dependencies, packages restored from CI caches and dependencies no lockfile lists. Each SBOM carries a completeness state and exports as CycloneDX or SPDX.

CRACI re-evaluates monitored SBOMs continuously and aggregates them across builds and repositories, and vendor SBOMs can be added so bought-in components are monitored alongside your own. When a new CVE appears, build history shows which past builds contained the vulnerable dependency, direct or transitive, so you know the period you were affected, and the inventory view shows which software versions are deployed to which products. Security teams triage findings in CRACI and send them to the teams that own the fix, CRACI supports VEX, and policy gates can block builds that contain a specific CVE so a fixed vulnerability stays out. See vulnerability tracking.

Vulnerability management lifecycle: frequently asked questions

What are the stages of the vulnerability management lifecycle?

For a product vendor: receive or discover the vulnerability, verify and triage it, find the affected products and versions, develop the remediation, release the fix, publish the advisory, then monitor and learn. ISO/IEC 30111 names the phases preparation, receipt, verification, remediation development, release and post-release.

What is ISO/IEC 30111?

ISO/IEC 30111:2019 is the international standard for vulnerability handling processes. It gives vendors requirements and recommendations for processing and remediating reported vulnerabilities in their products and services, from policy and the PSIRT's role to the handling phases and supply chain considerations.

What is the difference between ISO/IEC 30111 and ISO/IEC 29147?

ISO/IEC 29147 covers the outward part: receiving reports and publishing advisories. ISO/IEC 30111 covers the internal handling in between: verifying, investigating, prioritizing and fixing. The two are meant to be used together. See coordinated vulnerability disclosure for the 29147 side.

What is vulnerability triage?

Triage is the step where a security team confirms a reported or discovered vulnerability is real, judges how severe and how urgent it is for your product, and sends it to the team that owns the fix. Good triage also closes the findings that do not apply, with a recorded reason.

How is product vulnerability management different from IT vulnerability management?

IT vulnerability management patches the systems an organization runs. Product vulnerability management handles flaws in software the organization builds and ships to others, so it adds steps IT teams do not have: working out which released versions are affected, shipping a fix to customers and telling them about it in an advisory.

Which metrics should a vulnerability handling process track?

Time to acknowledge a report, time to triage, time to remediate and time to advisory, each by severity, plus the share of findings that meet your internal targets, the open backlog by age, and how many findings were closed as not affected.