Software Composition Analysis (SCA)

What is SCA?

SCA is a method for analyzing open-source components included in software to detect known vulnerabilities (CVEs). It tracks the full dependency graph based on an SBOM (Software Bill of Materials) and enables immediate response when new CVEs are discovered.

The configuration below is an example — a fully working implementation lives in the reference repository

The YAML and commands on this page are examples that show the essentials. For a complete, copy-and-run pipeline (including policy files and a sample app), see the Best Practice repository.

SBOM Generation — syft

Basic Usage

Bash
# CycloneDX JSON generation (recommended)
syft . -o cyclonedx-json=sbom.cdx.json

# Generate SPDX JSON
syft . -o spdx-json=sbom.spdx.json

# Analyze a container image
syft nginx:latest -o cyclonedx-json=sbom.cdx.json

Format Selection

Format	Steward	Recommended Use
CycloneDX JSON	OWASP	Security and vulnerability management (grype integration)
SPDX JSON	Linux Foundation	Supply chain sharing and regulatory response

For security pipeline-centric workflows, CycloneDX JSON is recommended.

Vulnerability Scanning — grype

Full GitHub Actions Workflow

YAML
# .github/workflows/sca.yml

name: SCA — SBOM & Vulnerability Scan

on:
  pull_request:
    branches: [main, develop]

jobs:
  sca:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7

      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          format: cyclonedx-json
          output-file: sbom.cdx.json

      - name: Scan vulnerabilities
        uses: anchore/scan-action@v7
        with:
          sbom: sbom.cdx.json
          fail-build: true
          severity-cutoff: high
          config: .grype.yaml

      - name: Upload SBOM artifact
        uses: actions/upload-artifact@v7
        with:
          name: sbom-${{ github.sha }}
          path: sbom.cdx.json
          retention-days: 90

GitLab CI

YAML
# .gitlab-ci.yml (sca job section)

sca:
  stage: test
  image: ubuntu:22.04
  script:
    # The base ubuntu image does not include curl
    - apt-get update -qq && apt-get install -y -qq curl ca-certificates
    - curl -sSfL https://get.anchore.io/syft
      | sh -s -- -b /usr/local/bin
    - curl -sSfL https://get.anchore.io/grype
      | sh -s -- -b /usr/local/bin
    - syft . -o cyclonedx-json=sbom.cdx.json
    - grype sbom:sbom.cdx.json --fail-on high --config .grype.yaml
  artifacts:
    paths:
      - sbom.cdx.json
    expire_in: 90 days
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

Vulnerability Policy Design

Severity-Based SLA

The table below is an example of a hardened, organization-level SLA tuned for CI gates. For the KWG baseline (Critical 1 week, High 4 weeks) and the canonical response deadlines, see Vulnerability response deadlines and VEX.

Severity	CVSS Range	Hardened SLA Example	Build Block
Critical	9.0–10.0	24 hours	Block
High	7.0–8.9	7 days	Block
Medium	4.0–6.9	30 days	Warning only
Low	0.1–3.9	Next release	Ignore

At initial adoption, it is recommended to block only Critical issues, then expand to High after the team is accustomed.

grype Policy File

Always record reason and approval date for ignore rules

For audit response, exceptions without evidence can become a compliance risk.

YAML
# .grype.yaml

fail-on-severity: high

ignore:
  # not used in actual code paths — security team approved 2024-01-15
  - vulnerability: CVE-2023-XXXXX
    reason: 'confirmed function not used'
  # test-only package
  - package:
      name: some-test-lib
      type: npm

Using VEX

What is VEX (Vulnerability Exploitability eXchange)? It is a machine-readable document that specifies whether a particular CVE is actually exploitable in a given product. It formally expresses cases like "the CVE exists, but the affected code path is not used," reducing unnecessary alerts across downstream supply chains.

Practical use: Author it in CycloneDX VEX or OpenVEX format and distribute it with the SBOM. Adoption is still early, but its importance is growing as supply chain regulations tighten. For the concepts, including the four status values, Vulnerability response deadlines and VEX is the canonical reference.

SBOM Retention Policy

Storage location: Store as CI/CD artifacts and connect to release tags to track SBOMs by version. Use GitHub Actions upload-artifact and GitLab artifacts.paths.

Retention period: ISO/IEC 18974 requires retention for the life of the program. In practice, permanent retention per release version is recommended.

When to update: Regenerate whenever dependencies change. Automatic generation at the PR level keeps it always up to date.

SBOM Analyzer

Upload SBOM files generated by syft, trivy, or cdxgen to automatically analyze vulnerabilities and generate response guidance.

Preview with a sample first (no API key required)

You can view the analysis of a pre-built sample SBOM right away, without an API key. Get a feel for what the tool produces first, then run a real analysis on your own SBOM below.

Run a real analysis on your own SBOM

This tool requires an Anthropic API key

It calls the Anthropic API directly from your browser. Enter your own Anthropic API key to use it right away. Your key and inputs are sent only from your browser to Anthropic (they never pass through a trustedoss server). Usage is billed to your own Anthropic account.

Self-Study

In-depth SBOM analysis with Claude Code

The analyzer above is available directly in your browser. If you need deeper analysis and automatic .grype.yaml policy file generation, use the agent below.

Prerequisite: Clone the Trusted OSS repository

Bash
cd agents/sbom-vuln-analyst
claude

The agent automatically performs the following:

Auto-detects CycloneDX / SPDX / grype results
Classifies by severity and suggests fixed versions
Generates .grype.yaml exception handling examples
Provides CI/CD pipeline integration guidance

Next Steps

Prevent secret leakage: Secret Detection
Container image vulnerabilities: Container Security
Continuous post-deployment monitoring: Monitoring & Auto-Remediation
ISO/IEC 18974 alignment: ISO Standard Mapping

Need an SCA engine you run every day?

The analyzer above is for one-off checks. If your whole team needs a continuously running, self-hosted SCA, move on to TRUSCA — an Apache-2.0 tool that manages vulnerabilities (CVEs), license compliance, and SBOMs in one UI, no commercial SCA required.

Try it yourself: TRUSCA repository (Docker Compose or Helm deployment)
It is a free path to a continuously operated SCA in environments where adopting a commercial tool is hard (budget, staffing, air-gapped networks).

No hosted public demo instance is provided. Use the guide above to run it in your own environment.