mcpField
S
sbom-analyzer

sbom-analyzer

github.com/snykSecurity68136 installsUpdated 1w ago
Repository

About sbom-analyzer

sbom-analyzer is a security skill for analyzing software bills of materials in third-party risk and compliance workflows. It validates CycloneDX or SPDX JSON files, scans component vulnerabilities, and compiles risk and remediation guidance.

Key features

  1. 01Validate CycloneDX and SPDX formats
  2. 02Check SBOM completeness and purls
  3. 03Scan components for vulnerabilities
  4. 04Compile risk findings
  5. 05Provide upgrade guidance and vendor templates

Use cases

  1. 01Review an SBOM supplied by a vendor
  2. 02Assess third-party component risk
  3. 03Generate and scan an internal project's SBOM

MCP support

The skill calls Snyk's MCP SBOM scanning tool to analyze component vulnerabilities. Scanning requires network access and package URLs in components.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/snyk/studio-recipes --skill sbom-analyzer

After installing, type/sbom-analyzerin Claude Code to confirm it loaded.

Bundled filesreferences/sbom-formats.md

Details

From the project README

SBOM Security Analyzer

Analyze Software Bill of Materials to identify vulnerabilities in declared components for third-party risk management and compliance workflows.

Core Principle: Know what's in your software supply chain.


Quick Start

1. Receive or locate SBOM file (CycloneDX or SPDX)
2. Validate SBOM format and completeness
3. Run mcp_snyk_snyk_sbom_scan for vulnerability analysis
4. Generate risk report with prioritized findings
5. Provide remediation guidance

Supported SBOM Formats

FormatVersionsFile Extension
CycloneDX1.4, 1.5, 1.6.json
SPDX2.3.json

Note: mcp_snyk_snyk_sbom_scan requires Package URLs (purls) in the SBOM for component identification.


Phase 1: SBOM Validation

Goal: Ensure the SBOM is valid and complete before analysis.

Step 1.1: Identify SBOM Format

Check the file structure:

CycloneDX Indicators:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [...]
}

SPDX Indicators:

{
  "spdxVersion": "SPDX-2.3",
  "SPDXID": "SPDXRef-DOCUMENT",
  "packages": [...]
}
Step 1.2: Validate Completeness

Check for required elements:

ElementCycloneDXSPDXRequired
Format versionspecVersionspdxVersionYes
Component listcomponentspackagesYes
Package URLspurl in componentsexternalRefsYes*
LicenseslicenseslicenseConcludedRecommended
ChecksumshasheschecksumsRecommended

* Package URLs are required for Snyk to identify vulnerabilities.

Step 1.3: Report Validation Issues

If SBOM is incomplete, produce a report in this format:

## SBOM Validation Results

**File**: supplier-sbom.json
**Format**: CycloneDX 1.5

### Issues Found
| Issue | Severity | Count |
|-------|----------|-------|
| Missing purl | Error | 15 components |
| Missing license | Warning | 8 components |
| Missing checksum | Info | 23 components |

### Components Without purl (Cannot Scan)
- component-a (no package URL)
- component-b (no package URL)

**Recommendation**: Request updated SBOM from supplier with package URLs.

Phase 2: Security Scan

Goal: Identify vulnerabilities in SBOM components.

Step 2.1: Run SBOM Scan

Call the tool directly:

mcp_snyk_snyk_sbom_scan(file="path/to/sbom.json", severity_threshold="medium")
Step 2.2: Organization-Scoped Scan

To apply org-specific policies:

mcp_snyk_snyk_sbom_scan(file="path/to/sbom.json", org="<org-id>", severity_threshold="high")

Phase 3: Risk Analysis

Goal: Generate a comprehensive risk report from scan results.

Produce a single consolidated report covering summary, critical findings, and an overall risk score:

## SBOM Security Analysis

### Overview
| Metric | Value |
|--------|-------|
| Total Components | 156 |
| Components Scanned | 141 |
| Components Skipped | 15 (missing purl) |
| Vulnerable Components | 23 |
| Total Vulnerabilities | 47 |

### Severity Breakdown
| Severity | Count |
|----------|-------|
| Critical | 3 |
| High | 12 |
| Medium | 18 |
| Low | 14 |

### Critical Vulnerabilities
| Component | Version | CVE | CVSS | Exploited |
|-----------|---------|-----|------|-----------|
| log4j-core | 2.14.1 | CVE-2021-44228 | 10.0 | Yes |
| spring-core | 5.3.17 | CVE-2022-22965 | 9.8 | Yes |
| jackson-databind | 2.9.10 | CVE-2020-36518 | 9.8 | No |

### Risk Score: 78/100 (High Risk)
- ⚠️ 2 vulnerabilities with known exploits
- ⚠️ 3 critical severity issues
- ✓ Components from untrusted sources: 0

**Recommendation**: Do not integrate this software until critical vulnerabilities are addressed.

Phase 4: Remediation Guidance

Goal: Provide actionable upgrade recommendations and vendor communication.

Step 4.1: Upgrade Recommendations
## Recommended Actions

### Priority 1: Critical (Must Fix)
| Component | Current | Fixed Version | Notes |
|-----------|---------|---------------|-------|
| log4j-core | 2.14.1 | 2.17.1+ | Log4Shell |
| spring-core | 5.3.17 | 5.3.18+ | Spring4Shell |

### Priority 2: High (Should Fix)
| Component | Current | Fixed Version | Notes |
|-----------|---------|---------------|-------|
| lodash | 4.17.15 | 4.17.21 | Prototype pollution |
| axios | 0.21.1 | 1.6.0+ | SSRF vulnerability |

### Priority 3: Medium (Plan to Fix)
| Component | Current | Fixed Version | Notes |
|-----------|---------|---------------|-------|
| minimist | 1.2.5 | 1.2.8+ | Prototype pollution |
Step 4.2: Vendor Communication

Draft a message to the vendor using this template (populate with actual findings):

Subject: Security Vulnerabilities in Software SBOM

Dear [Vendor],

During our security review of [Product Name], we identified the following
vulnerabilities in the provided SBOM:

**Critical Issues (Require Immediate Action)**:
1. [Component] [Version] - [CVE] ([Name])
2. [Component] [Version] - [CVE] ([Name])

**Request**:
1. Provide updated software with patched versions
2. Provide updated SBOM reflecting the changes
3. Confirm expected remediation timeline

We require resolution of critical issues before proceeding with integration.

Regards,
[Your Name]

SBOM Generation (Internal Projects)

To generate an SBOM for your own project using the Snyk CLI, then scan it:

# Generate CycloneDX SBOM
snyk sbom --format=cyclonedx1.5+json > sbom.json

# Generate SPDX SBOM
snyk sbom --format=spdx2.3+json > sbom.json

Then scan the generated SBOM:

mcp_snyk_snyk_sbom_scan(file="sbom.json")

Error Handling

Invalid SBOM Format
Error: Unable to parse SBOM file

Solutions:
1. Verify file is valid JSON
2. Check SBOM format (CycloneDX/SPDX)
3. Validate against schema
4. Request corrected SBOM from source
Missing Package URLs
Warning: X components missing purl - cannot scan

Solutions:
1. Request updated SBOM with purls
2. Manually add purls if components are known
3. Document risk of unscanned components
Unsupported Version
Error: SBOM version not supported

Supported versions:
- CycloneDX: 1.4, 1.5, 1.6
- SPDX: 2.3

Convert SBOM to supported version if possible.

Constraints

  1. Requires purls: Components without package URLs cannot be scanned
  2. JSON only: XML format not currently supported
  3. Version limits: Only specific CycloneDX/SPDX versions supported
  4. Network required: Vulnerability database lookup needs connectivity
  5. Point-in-time: SBOM reflects a specific version — rescan on updates

Comments

Markdown supported