Vulnerability Response Evidence Example
This fictional example shows what "we fixed it" should include beyond a statement.
Use it with the Evidence Package Template to see how a vulnerability response decision can capture affected scope, remediation evidence, verification, known gaps, exceptions, retention, and follow-up actions.
Scenario
A public vulnerability affects a third-party network library used in a supplier's gateway product. The buyer asks whether its deployed version is affected and what evidence supports the supplier's answer.
Decision being made
Should the buyer continue operating, deploy an update, apply a mitigation, or accept residual risk?
Decision: continue operation with mitigation while deploying update 5.4.3.
Main condition: customer-managed devices without telemetry require manual confirmation or exception review within 30 days.
Evidence maturity: Level 4–5 for products with fixed-version verification and retained deployment evidence; lower for customer-managed devices until installation is confirmed.
Weak answer
The supplier says:
We reviewed the vulnerability and fixed it.
Assessment: weak. The answer does not identify affected products, versions, evidence sources, remediation status, or verification.
Evidence maturity: Level 1, supplier assertion.
Better answer
The supplier says:
The vulnerable library is present in some products. Gateway firmware 5.4.2 is affected and firmware 5.4.3 fixes it.
Assessment: better. The answer identifies an affected version and a fix, but still needs evidence tying the claim to component records, update records, and verification.
Evidence maturity: Level 2–3, documented status and produced claim without complete verification.
Stronger answer
The supplier provides:
- affected-product analysis tied to SBOM/xBOM records;
- vulnerable component version and fixed component version;
- affected firmware versions and not-affected versions;
- remediation plan and release approval for firmware 5.4.3;
- signed update package and deployment guidance;
- verification record showing the fixed component is present in 5.4.3;
- customer notification with affected scope, mitigation, and update instructions;
- risk acceptance record for devices that cannot update immediately.
Assessment: strong. The response turns a vulnerability claim into product-scoped, reviewable evidence.
Evidence maturity: Level 4–5 when fixed-version verification and deployment records are retained.
What changed from weak to strong?
| Improvement | Why it matters |
|---|---|
| Affected-product scope added | Separates affected, fixed, not affected, and unknown product states |
| SBOM/xBOM linkage added | Shows why the vulnerability is relevant to this product |
| Fixed-version evidence added | Connects remediation to a specific release and component version |
| Deployment status added | Shows whether the fix reached the product in use |
| Residual risk recorded | Makes delayed updates and customer-managed gaps visible |
| Retention owner added | Keeps vulnerability evidence available for customer assurance, audit, and later incidents |
Evidence package
| Field | Example content |
|---|---|
| Decision supported | Continue operation with mitigation until update 5.4.3 is deployed |
| Decision outcome | Continue operation with mitigation while deploying update 5.4.3 |
| Decision owner | Buyer vulnerability response owner with operations approval |
| Threat/failure mode addressed | Unsupported "we fixed it" claim, unclear affected versions, missing deployment evidence, stale vulnerability status |
| Practice/control supported | Vulnerability intake workflow, affected-product analysis, remediation tracking, vulnerability status communication |
| Scope | Gateway product family GW-100, firmware 5.4.0-5.4.2 affected, firmware 5.4.3 fixed |
| Evidence included | SBOM record, affected-product analysis, vulnerability status record, remediation plan, signed update manifest, verification result, customer notification, risk acceptance for delayed deployments |
| Producer/source | Supplier product security team, supplier release team, buyer vulnerability response owner |
| Consumer/recipient | Buyer product owner, operations team, customer assurance team, audit owner |
| Verification method | Check SBOM/component mapping, affected-version list, fixed-version evidence, update package signature, deployment records, and status communication scope |
| Known gaps | Some customer-managed devices have no telemetry confirming update installation |
| Exceptions/risk acceptance | Delayed-update devices require mitigation and manual confirmation within 30 days |
| Retention owner | Buyer vulnerability response owner and supplier product security lead |
| Follow-up actions | Track update deployment, request manual confirmation for devices without telemetry, and review exceptions after 30 days |
Verification questions
- Which product versions are affected, fixed, not affected, or still under investigation?
- What component evidence supports the affected-product analysis?
- What update or mitigation evidence supports the remediation claim?
- How are delayed updates, unsupported devices, or customer-managed deployments tracked?
- Is customer communication scoped to the right product and lifecycle state?
Gaps, exceptions, and retention
The buyer accepts temporary operation with mitigation for delayed-update devices. Devices without telemetry require manual confirmation or an exception review.
Vulnerability evidence is retained with update records, customer notification records, and risk acceptance records.
Related pages
Understand the practices:
Review and package evidence:
Verify component and update evidence:
Retain vulnerability evidence: