Vulnerability Response Evidence Example
This fictional example shows what "we fixed it" should include beyond a statement.
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 |
| 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 |
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.