[REVIEW] sbom-analysis: VEX scope expiry and channel matching

[stmr]

Skill Being Reviewed

skills/vuln-management/sbom-analysis

Review Focus

The skill covers SBOM format, component completeness, NTIA fields, dependency graph, license data, vulnerability matching, and VEX status. The gap I found is VEX statement scope and expiry. A VEX record can be technically present but still misleading if it applies to the wrong product variant, wrong distribution channel, stale component version, or has no revalidation trigger.

False Positive Analysis

A "not affected" VEX status should be accepted when it is well-scoped. Benign evidence includes:

• Product name, version, build, architecture, and distribution channel match the deployed artifact.
• VEX justification is specific, such as vulnerable code not present or vulnerable function not reachable.
• The statement is signed or traceable to an authorized producer.
• There is a revalidation trigger for version changes, rebuilds, or upstream advisory changes.

The review should not reject VEX automatically, but should verify scope before trusting it.

Coverage Gaps

Please add checks for:

• Product/variant matching: VEX statement applies to the exact package, image, appliance, build, architecture, and distribution channel in use.
• Expiry or revalidation: VEX should be revisited after component upgrades, rebuilds, base image changes, or advisory changes.
• Justification quality: "not affected" should include a machine-readable status and a human-readable reason.
• Producer authority: VEX from an upstream, vendor, or internal team should be tied to an accountable source.
• Conflict handling: if scanner results and VEX disagree, the skill should require a documented decision path.

Edge Cases

• A container image may contain a patched distro backport with the same upstream version string; VEX must align with distro package metadata.
• A library can be unreachable in one service but reachable in another using the same SBOM component.
• A SaaS product may have different vulnerability exposure across regions or feature flags.
• A VEX status can become stale when a disabled component becomes enabled later.

Remediation Quality

Good remediation should include:

• Exact artifact identifier, version, digest, and distribution channel in the VEX evidence.
• Revalidation trigger and owner.
• Signed or source-traceable VEX statement.
• A policy for conflicts between VEX and scanner findings.
• Evidence that the deployed artifact matches the SBOM/VEX pair.

Comparison To Existing Tools

SBOM tools such as Syft, Grype, Trivy, Dependency-Track, and vendor portals can ingest VEX, but they often trust a statement without checking whether it matches the deployed product variant. This skill can add value by reviewing the context around the VEX, not just its presence.

Overall Assessment

The skill has good SBOM basics. Adding VEX scope, expiry, and conflict-resolution checks would reduce the risk of accepting stale or misapplied "not affected" statements.

Suggested Acceptance Criteria

• Add product/variant/distribution-channel matching for VEX.
• Add VEX expiry or revalidation triggers.
• Require justification quality and producer authority evidence.
• Add scanner-vs-VEX conflict handling guidance.

Bounty Info

This is submitted as a skill review bounty claim. Preferred payout: PayPal samik4184@gmail.com.

[Errordog2]

/claim #2549

Implemented in #2572.

Summary:

• adds VEX product/variant/distribution-channel matching before accepting status claims
• requires expiry or revalidation triggers, producer authority, and scanner-vs-VEX conflict disposition
• updates the sbom-analysis report template, risk classification, pitfalls, and version history

Validation:

• git diff --check
• Markdown fence balance check

Payment details can be provided privately after maintainer acceptance.