Skip to main content

SBOM Monitoring Guide

PropertyValue
Version1.0
Date2026-04-02
StatusActive

1. Overview​

This document describes how SIROS Foundation monitors Software Bill of Materials (SBOMs) for both:

  • Outgoing SBOMs: SBOMs we produce for software we release
  • Incoming SBOMs: SBOMs from dependencies and vendors we consume
┌─────────────────────────────────────────────────────────────────────────────┐
│                           SBOM Monitoring                                    │
├────────────────────────────────┬────────────────────────────────────────────┤
│      OUTGOING (We Produce)     │         INCOMING (We Consume)              │
├────────────────────────────────┼────────────────────────────────────────────┤
│ Our repos → SBOM → Consumers   │ Dependencies → SBOM → Our evaluation       │
│ - go-wallet-backend            │ - Container base images                    │
│ - wallet-frontend              │ - Go/npm packages                          │
│ - wwwallet-core                │ - Commercial dependencies                  │
└────────────────────────────────┴────────────────────────────────────────────┘

2. SBOM Generation Workflow​

2.1 How It Works​

All sirosfoundation repositories use a shared reusable workflow:

# In your repository's .github/workflows/sbom.yml
jobs:
  sbom:
    uses: sirosfoundation/.github/.github/workflows/sbom.yml@main
    with:
      artifact-name: myproject
      scan-vulnerabilities: true

2.2 Workflow Features​

FeatureDefaultDescription
artifact-namerepo namePrefix for SBOM files
scan-image(none)Container image to scan
scan-vulnerabilitiestrueRun Grype vulnerability scan
fail-on-severity(none)Fail if vulns at this level
upload-to-releasetrueAttach to GitHub releases
require-sbomfalseFail build if SBOM fails

2.3 Output Files​

FileDescription
{name}-sbom.cdx.jsonCycloneDX JSON SBOM
{name}-container-sbom.cdx.jsonContainer SBOM (if image scanned)

3. Outgoing SBOM Monitoring​

3.1 Continuous Vulnerability Scanning​

Every SBOM workflow run includes Grype vulnerability scanning:

Vulnerability sources:

  • National Vulnerability Database (NVD)
  • GitHub Security Advisories
  • OSV (Open Source Vulnerabilities)

Results location: Repository → Security → Code scanning alerts

3.2 Artifact Publication​

TriggerArtifact LocationRetention
Push/PRWorkflow artifacts90 days
ReleaseRelease assetsPermanent

3.3 Quality Metrics​

MetricTargetMeasurement
SBOM coverage100% of releasesAll 13 repos have SBOM workflow
Component coverage100%All deps have PURL in SBOM
Vulnerability response<7 daysTime from CVE disclosure to patch

4. Incoming SBOM Monitoring​

4.1 Dependency Scanning​

Dependencies are scanned when we generate our SBOM:

4.2 Third-Party Dependency Sources​

Dependency TypeSBOM SourceMonitoring Method
Go modulesGenerated by SyftPart of our SBOM
npm packagesGenerated by SyftPart of our SBOM
Container imagesRegistry attestationsManual verification
Commercial SWVendor-providedManual ingest

4.3 Supply Chain Attack Detection​

Grype and GitHub Dependabot detect:

  • Known vulnerabilities (CVEs)
  • Malicious packages (via advisory databases)
  • Typosquatting attempts (npm/PyPI advisories)

5. Alerting & Response​

5.1 Alert Channels​

Alert SourceDestinationSLA
Grype critical vulnGitHub Security tabReview within 24h
Dependabot alertGitHub Security tabReview within 7 days
New dependency addedPR diffReview in PR

5.2 Vulnerability Response Process​

5.3 Severity Response SLAs​

SeverityResponse TimeResolution Time
Critical24 hours72 hours
High7 days14 days
Medium30 days60 days
LowBest effortNext release

See Vulnerability Management SLA for full details.

6. Future Enhancements​

6.1 Dependency-Track Integration (Planned)​

Centralized SBOM management platform:

┌─────────────────────────────────────────────────────┐
│               Dependency-Track                       │
│  ┌───────────┐  ┌───────────┐  ┌───────────────┐   │
│  │ Portfolio │  │ Continuous│  │ Policy        │   │
│  │ Dashboard │  │ Monitoring│  │ Enforcement   │   │
│  └───────────┘  └───────────┘  └───────────────┘   │
│                                                      │
│  Features:                                          │
│  - All projects in one view                         │
│  - Continuous vuln correlation                      │
│  - License compliance                               │
│  - Shared component analysis                        │
└─────────────────────────────────────────────────────┘

6.2 Release Gating (Opt-in)​

When require-sbom: true and fail-on-severity: high:

Release blocked if:
- SBOM generation fails
- High/Critical vulnerabilities found

7. Operational Procedures​

7.1 Adding SBOM to a New Repository​

  1. Create .github/workflows/sbom.yml:
name: SBOM

on:
  push:
    branches: [main]
    tags: ['v*']
  pull_request:
    branches: [main]
  release:
    types: [published]

jobs:
  sbom:
    uses: sirosfoundation/.github/.github/workflows/sbom.yml@main
    with:
      artifact-name: my-project
      scan-vulnerabilities: true
    permissions:
      contents: write
      id-token: write
      security-events: write
  1. Enable GitHub Advanced Security for the repo (for SARIF upload)
  2. Verify workflow runs on next push

7.2 Responding to Security Alerts​

  1. Go to repository → Security → Code scanning
  2. Review each alert's details
  3. For each alert:
    • If false positive: Dismiss with reason
    • If valid: Create issue, prioritize fix
  4. Track resolution in SBOM metrics

7.3 Verifying a Release SBOM​

# Download release SBOM
gh release download v1.0.0 -p "*-sbom.cdx.json*"

# Scan for current vulnerabilities
grype sbom:*-sbom.cdx.json

8. References​