Vulnerability Disclosure

Vulnerability disclosure is the producer-side process of assessing a reported vulnerability and communicating its impact to affected parties. This page covers the operational sequence: what to communicate, to whom, in what format, and when.

Detection, triage, and consumer-side monitoring are covered in the vulnerability management use case. VEX and VDR field definitions are in content requirements.

When to Disclose

The disclosure workflow activates when a producer becomes aware of a vulnerability affecting their product. Four common triggers:

• Internal discovery through code review, penetration testing, or automated scanning (SAST, DAST, dependency analysis)
• External report from a security researcher, customer, or CERT via the producer's security contact or vulnerability disclosure policy
• Public advisory listing a component the product includes (CVE, GitHub Advisory, CSAF feed)
• Dependency scanner alert flagging a newly disclosed vulnerability in a transitive or direct dependency

Awareness does not require certainty. Under the CRA, "becoming aware" means reaching a reasonable degree of certainty that a vulnerability exists (CRA Guidance §9.1). A credible report from a researcher or a confirmed scanner match both qualify.

Prerequisites: Security Contact and VDP

Producers need a published security contact and a vulnerability disclosure policy (VDP).

security.txt is a machine-readable file placed at /.well-known/security.txt on the producer's domain. It specifies the preferred contact method for reporting security issues, encryption keys, and a link to the producer's VDP. The format is defined in RFC 9116.

A vulnerability disclosure policy describes how the producer handles incoming reports: expected response times, scope, legal safe harbor for good-faith researchers, and the disclosure timeline. The CRA requires producers to have a coordinated vulnerability disclosure policy (CRA Annex I, Part II, PT2.5). ISO 29147 provides a framework for structuring one.

The Disclosure Workflow

Receive and Acknowledge

When a report arrives through any trigger channel, the security engineer acknowledges receipt to the reporter. Acknowledgment confirms the report reached the right team and provides a reference identifier for future correspondence. Timeliness matters: researchers who receive no response often escalate to public disclosure.

An acknowledgment includes: confirmation of receipt, a tracking identifier, expected timeline for initial assessment, and the producer's disclosure policy reference. It does not include a vulnerability assessment or commitment to a fix timeline.

Assess Impact Using SBOM Data

The security engineer determines which product versions and components are affected. SBOM data provides the component inventory: which version of the vulnerable library is included, in which product versions, and through which dependency paths.

At this stage, the security engineer sets the initial VEX state to under_investigation. This signals to anyone monitoring VEX feeds that the producer is aware of the vulnerability and actively assessing it. See VEX/VDR content requirements for field definitions.

Determine VEX Status

After assessment, the security engineer determines the vulnerability's disposition. Two primary outcomes:

• not_affected: the vulnerability does not impact the product in its operational context. This requires a justification: component_not_present, vulnerable_code_not_reachable, vulnerable_code_cannot_be_controlled_by_adversary, or inline_mitigations_already_exist. A bare not_affected without justification is insufficient for consumers to evaluate the claim.
• affected: the vulnerability impacts the product. This triggers the fix/mitigation track.

Transition from under_investigation to a determined state as soon as sufficient information exists. Consumers assume the worst when VEX status stagnates without updates.

Develop Fix or Mitigation

Once a vulnerability is confirmed as affected, the developer works on a fix or the security engineer identifies a mitigation (configuration change, workaround, compensating control). The VEX state remains affected with the planned action documented in the response field (e.g., will_fix, workaround_available).

For vulnerabilities with high severity or active exploitation, producers should issue an interim advisory describing available mitigations before the fix ships. Waiting for a complete fix before communicating leaves consumers exposed.

Report Upstream (Third-Party Components)

When the vulnerability exists in an integrated third-party component, the CRA (Article 13(6)) requires the producer to report it to the component maintainer and share the fix in machine-readable format (e.g., a merge request or patch file). This obligation applies to the specific version the producer integrates.

Two exceptions: the obligation does not apply if the component has no identifiable maintainer, or if the producer has forked the component and maintains it independently (CRA Guidance §9.2.1).

Report to Authorities (CRA Obligations)

When a vulnerability is actively exploited, the CRA (Article 14) requires producers to report to the designated CSIRT coordinator and ENISA. Three mandatory milestones:

1. 24 hours: early warning to the CSIRT coordinator and ENISA. Contains: nature of the vulnerability, confirmation of active exploitation, whether other products may be affected.
2. 72 hours: detailed notification. Contains: technical details, severity assessment, affected products and versions, known mitigations or patches.
3. 14 days (after corrective measure is available): final report. Contains: root cause analysis, corrective measures taken, residual risk assessment.

These timelines apply only to actively exploited vulnerabilities. "Actively exploited" means the producer has evidence or credible intelligence that the vulnerability is being used in attacks. A theoretical exploit or proof-of-concept publication alone does not trigger mandatory reporting.

The regulatory summary below consolidates the CRA obligations referenced in this workflow.

Ship Security Update

The release engineer ships the security update through the standard release pipeline. The release includes an updated SBOM reflecting the patched component version and a VEX document transitioning the vulnerability status to fixed, specifying the fix version.

Security updates are generally not "substantial modifications" under the CRA and do not trigger re-assessment or re-certification. The exception: a fix that fundamentally alters the product's intended purpose or core functionality (CRA Guidance §4.3).

Notify Customers

After becoming aware of a vulnerability, the CRA (Article 14(8)) requires producers to inform impacted users. This notification is risk-based and proportionate:

• Targeted notification to customers known to operate affected versions, particularly in sensitive or critical environments
• Broader notification via security mailing lists, customer portals, or advisory feeds once a patch is available

Notification content includes: affected product versions, severity rating, whether active exploitation is known, available mitigations or patches, and where to obtain the security update. Notifications should reference the specific VEX document or CSAF advisory for machine-readable consumption.

Publish Advisory

The security engineer publishes a public security advisory containing: CVE identifier, affected products and versions, fixed version, CVSS score and severity, remediation steps, and credit to the reporter (if agreed). The security engineer publishes the advisory in both human-readable and machine-readable formats.

CSAF 2.0 is the standard machine-readable format for security advisories. VEX information can be expressed as a CSAF VEX profile or embedded in a CycloneDX vulnerability record. Distribute the CSAF/VEX artifact alongside the advisory through the same release channels described in Release Management.

VEX Lifecycle in Practice

VEX states map to the disclosure workflow steps:

Each state transition produces a new VEX document (or a new version of an existing one). Consumers monitoring VEX feeds receive updates as the producer's assessment progresses. The VEX document's timestamp and version number establish the sequence. See VEX/VDR content requirements for field definitions and encoding.

Coordinated Disclosure

Coordinated disclosure gives affected parties time to patch before public announcement. A typical timeline:

Timelines vary by severity and complexity. Actively exploited vulnerabilities compress the timeline to days: the CRA's 24-hour early warning obligation overrides any embargo arrangement. The producer and researcher should agree on the disclosure date at the start of the coordination period.

Regulatory Summary

CRA obligations referenced in this page:

The regulatory summary below covers the CRA obligations and reporting timelines referenced in this workflow.

Common Pitfalls

• No published security contact. External reporters cannot reach the producer. Vulnerability reports go to public channels instead, forcing uncontrolled disclosure.
• Prolonged under_investigation without updates. Some consumers auto-escalate components stuck in under_investigation for more than 30 days, treating them as affected by default.
• not_affected without justification. Consumers and regulators cannot evaluate the claim. Always include a justification code and a human-readable explanation.
• Waiting for a complete fix before any communication. Regulated consumers may have their own 24h/72h reporting obligations. Without an interim advisory, they cannot assess whether the vulnerability triggers those obligations.
• Missing upstream report. The CRA requires reporting to component maintainers. Producers who fix a third-party vulnerability without reporting upstream violate Article 13(6) and deprive the broader ecosystem of the fix.
• Confusing advisory with VEX. A security advisory is a human-readable document describing the vulnerability and fix. A VEX document is a machine-readable status assertion. Producers should publish both.
• Security update triggering re-certification concern. Security patches are generally not substantial modifications under the CRA. Teams should not delay patches over re-certification uncertainty.

Related Concepts

• Vulnerability Management for the full detection-to-remediation lifecycle from both producer and consumer perspectives
• VEX/VDR Content Requirements for field definitions, encoding rules, and format examples
• Release Management for release-aligned delivery of VEX and CSAF documents