Skip to main content

Update & Vulnerability

Update evidence helps a recipient decide whether changes were authorized, delivered, installed, and recoverable. Vulnerability evidence helps a recipient decide whether known exposures are tracked, remediated, accepted, mitigated, or communicated.

Decision Supported​

Is the product up to date, supportable, and aligned with known vulnerability and remediation decisions?

Who Produces It​

Manufacturers, suppliers, product-security teams, update services, vulnerability management teams, build systems, operators, and support teams may produce update and vulnerability evidence.

Who Consumes It​

Customers, operators, procurement teams, product-acceptance teams, auditors, assessors, incident responders, and vulnerability management teams may consume it.

When It Is Generated​

Evidence may be generated during release, update authorization, update delivery, installation, rollback, vulnerability triage, remediation, disclosure, and support lifecycle decisions.

When It Is Verified​

Verification may occur at acceptance, during update installation, after update completion, during vulnerability triage, during audit, or during incident response.

Evidence Examples​

  • Update authorization records.
  • Signing records.
  • Delivery records.
  • Installation records.
  • Version history.
  • Rollback and recovery evidence.
  • Vulnerability records.
  • Affected-product analysis.
  • Remediation or mitigation records.
  • Risk acceptance records.
  • Customer notification records.

What Makes It Verifiable​

Update and vulnerability evidence is stronger when it is bound to a product version, signed or integrity-protected, tied to a known vulnerability or update decision, and connected to installation, rollback, and remediation records.

Retention​

Update and vulnerability records should be retained for the support period and long enough to support audit, incident response, customer assurance, and lifecycle-state decisions.

Practical Questions​

Questions to ask suppliers​

  • What artifact, record, measurement, certificate, manifest, log, or report can you provide for this evidence area?
  • When is it generated, updated, superseded, or retired?
  • What product, component, version, supplier scope, or lifecycle event is it bound to?

Questions to ask internally​

  • What decision will this evidence support: selection, acceptance, operation, update, audit, transfer, or retirement?
  • Who verifies it, what acceptance criteria apply, and what happens if the evidence is missing or inconsistent?
  • How long does it need to remain available and interpretable?

Questions to ask assessors / auditors​

  • Can origin, integrity, freshness, scope, and product binding be checked independently?
  • Is there a clear trail from the evidence to the control, requirement, or assurance claim being assessed?
  • Are gaps, exceptions, expired artifacts, or remediation actions recorded?

Questions to ask implementers​

  • What system or process produces this evidence with enough metadata for later verification?
  • How are signatures, hashes, timestamps, issuers, trust anchors, and access controls protected?
  • How will recipients retrieve, verify, refresh, and correlate the evidence across lifecycle events?

Standards And Technology Support​

Relevant mappings may include SBOM, VEX-like records, update frameworks, firmware signing, vulnerability databases, disclosure frameworks, secure boot, attestation, and audit logs.

What It Does Not Solve​

Update evidence does not prove provenance or identity by itself. Vulnerability records do not prove remediation unless connected to product versions, update records, and verification.