[REVIEW] sbom-analysis: add dependency scope and artifact-stage gates

[sato820]

Skill Being Reviewed

Skill name: sbom-analysis
Skill path: skills/vuln-management/sbom-analysis/

False Positive Analysis

Benign code/configuration that triggers a false positive:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [
    {
      "type": "library",
      "name": "eslint-plugin-internal",
      "version": "4.2.0",
      "scope": "excluded",
      "licenses": [{"license": {"id": "GPL-3.0-only"}}],
      "properties": [
        {"name": "cdx:npm:package:development", "value": "true"},
        {"name": "acme:stage", "value": "lint-only"}
      ]
    }
  ]
}

Why this is a false positive:
The skill flags GPL/AGPL and other strong-copyleft licenses as distribution or SaaS concerns, but it does not require component scope/stage classification first. A lint-only development dependency excluded from the shipped runtime artifact should not be treated like a production dependency in distributed software or a network-exposed SaaS component. It should still be recorded, but priority and legal analysis should be different.

Coverage Gaps

Missed variant 1:

{
  "components": [
    {"name": "openssl", "version": "3.0.8", "type": "library", "scope": "required"},
    {"name": "vulnerable-test-fixture", "version": "1.0.0", "type": "library", "scope": "excluded"}
  ],
  "dependencies": [
    {"ref": "app", "dependsOn": ["openssl", "vulnerable-test-fixture"]}
  ]
}

Why it should be caught:
The skill counts known CVEs and transitive risk, but it does not require separating required runtime dependencies from excluded/dev/test/build-only dependencies before assigning risk. That can over-prioritize test fixtures and under-prioritize runtime libraries that are actually reachable in production.

Missed variant 2:

FROM node:22 AS build
RUN npm ci --include=dev
RUN npm run build

FROM gcr.io/distroless/nodejs22
COPY --from=build /app/dist /app/dist
CMD ["/app/dist/server.js"]

Why it should be caught:
An SBOM generated from the source tree or build stage can differ materially from the deployed image SBOM. The skill asks for software identity and component counts, but it does not require declaring whether the SBOM represents source, build environment, container image, runtime filesystem, or deployed service. Without that, vulnerability and license decisions can be made against the wrong artifact stage.

Edge Cases

Some organizations intentionally keep dev/build dependencies in a separate SBOM for auditability. That is useful, but the report should not merge dev, build, test, and runtime components into one severity bucket.

For containerized apps, a package may be present in the build image but absent from the final runtime layer. Conversely, a base image package may be absent from the application lockfile but present in production. The analysis should require stage and artifact labels before risk classification.

Remediation Quality

• Fix resolves the vulnerability
• Fix doesn't introduce new security issues
• Fix doesn't break functionality
• Issues found: Add dependency scope/stage gates before vulnerability priority and license-conflict classification.

Suggested additions:

SBOM artifact stage: source tree, lockfile, build image, final image, runtime filesystem, deployed service.
Component scope: required/runtime, optional, dev, test fixture, build-only, excluded.
Risk rule: production/runtime components drive vulnerability SLA; dev/build-only components drive separate hygiene/legal review unless shipped or reachable.

Comparison to Other Tools

Tool	Catches this?	Notes
Syft/Grype	Partial	Can generate image SBOMs and scan vulnerabilities, but the reviewer still must choose source vs final image.
CycloneDX	Partial	Supports scope/properties/formulation data, but the skill must require reviewers to use them.
SCA dashboards	Partial	Often separate dev/prod dependency groups, but container base-image packages still require runtime artifact scanning.

Overall Assessment

Strengths: Strong NTIA minimum-element validation, VEX interpretation, transitive risk, and license-conflict coverage.

Needs improvement: Require artifact stage and component scope before deciding vulnerability SLA, license conflict severity, and overall supply-chain risk.

Priority recommendations:

1. Add an artifact-stage field to the SBOM overview and executive summary.
2. Add component scope distribution to the transitive dependency and license sections.
3. Separate runtime vulnerability priority from dev/build-only hygiene findings.

Bounty Info

• I have read and agree to the CONTRIBUTING.md bounty terms
• Preferred payment method: Crypto after maintainer acceptance

[NiXouuuu]

/attempt #1608

I will make a focused improvement pass on skills/vuln-management/sbom-analysis/SKILL.md to add artifact-stage and component-scope gates before vulnerability priority and license classification. Planned coverage: CycloneDX lifecycle/scope handling, SPDX primary package purpose/source context, runtime vs dev/build/test split, output tables, risk classification updates, and prompt-injection guardrails. Payment preference can be provided privately after maintainer acceptance.

[NiXouuuu]

Implemented in PR #1609: #1609

Scope:

• Added artifact-stage assessment gates before vulnerability and license decisions.
• Added component-scope distribution for runtime, optional runtime, dev/test, build-only, excluded, and unknown-scope components.
• Updated transitive dependency risk, license analysis, classification, output format, common pitfalls, and prompt-injection guardrails.

Validation:

• git diff --check
• Markdown fence-balance check
• Required marker checks for artifact-stage, component-scope, runtime dependency, unknown-scope, and v1.1.0 output additions

Payment preference: PayPal; details can be provided privately after maintainer acceptance.

[rock2089]

I'd like to work on this bounty.

[heroking777]

Thank you for sharing the detailed issue context. After reviewing the discussion and previous attempts, I propose a focused improvement to address the core issues without over-engineering.

Proposed Solution

File: skills/vuln-management/sbom-analysis/SKILL.md

Root Cause:
The current implementation lacks clear artifact stage and component scope gates before vulnerability priority and license classification. This leads to incorrect risk assessments, especially for dev/build-only dependencies.

Diff Summary:

1. Add Artifact Stage Gates: Introduce a requirement to specify the SBOM artifact stage (e.g., source tree, build image, final image) before processing.
2. Component Scope Classification: Define and enforce component scopes (required/runtime, optional, dev, test fixture, build-only, excluded) to differentiate between production and non-production components.
3. Risk Rule Update: Adjust the risk classification rules to prioritize vulnerabilities in runtime components while handling dev/build-only components separately for hygiene and legal review.

By implementing these changes, we ensure that the SBOM analysis accurately reflects the artifact stage and component scope, leading to more precise vulnerability and license assessments.

Benefits

• Simplicity: Minimal changes with a clear impact.
• Effectiveness: Directly addresses the core issues without introducing unnecessary complexity.
• Alignment: Aligns with industry best practices for SBOM analysis.

Next Steps

1. Review PR Improve SBOM artifact stage and scope analysis #1609: Ensure that the implementation aligns with the proposed solution.
2. Validation Checks: Perform necessary checks to confirm code quality and functionality.
3. Maintainer Acceptance: Submit the PR for review and obtain maintainer approval.

Let's move forward with this strategic approach to enhance the SBOM analysis skill effectively.