SBOM Monitoring Guide

Policy status

Status: Approved · approved 2026-06-17

sirosfoundation Supply Chain Security

Version: 1.0
Date: 2026-04-02
Status: Active

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

Feature	Default	Description
`artifact-name`	repo name	Prefix for SBOM files
`scan-image`	(none)	Container image to scan
`scan-vulnerabilities`	`true`	Run Grype vulnerability scan
`fail-on-severity`	(none)	Fail if vulns at this level
`upload-to-release`	`true`	Attach to GitHub releases
`require-sbom`	`false`	Fail build if SBOM fails

2.3 Output Files

File	Description
`{name}-sbom.cdx.json`	CycloneDX JSON SBOM
`{name}-container-sbom.cdx.json`	Container SBOM (if image scanned)

3. Outgoing SBOM Monitoring

3.1 Continuous Vulnerability Scanning

Every SBOM workflow run includes Grype vulnerability scanning:

CI/CD ──▶ Syft (SBOM) ──▶ Grype (Scan) ──▶ GitHub Security Tab
                                │
                                ▼
                        SARIF Results

Vulnerability sources:

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

Results location: Repository → Security → Code scanning alerts

3.2 Artifact Publication

Trigger	Artifact Location	Retention
Push/PR	Workflow artifacts	90 days
Release	Release assets	Permanent

3.3 Quality Metrics

Metric	Target	Measurement
SBOM coverage	100% of releases	All 13 repos have SBOM workflow
Component coverage	100%	All deps have PURL in SBOM
Vulnerability response	<7 days	Time from CVE disclosure to patch

4. Incoming SBOM Monitoring

4.1 Dependency Scanning

Dependencies are scanned when we generate our SBOM:

go.mod / package.json
        │
        ▼
    Syft scans ──▶ SBOM includes all transitive deps
        │
        ▼
    Grype checks each component against vuln DBs

4.2 Third-Party Dependency Sources

Dependency Type	SBOM Source	Monitoring Method
Go modules	Generated by Syft	Part of our SBOM
npm packages	Generated by Syft	Part of our SBOM
Container images	Registry attestations	Cosign verify
Commercial SW	Vendor-provided	Manual 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 Source	Destination	SLA
Grype critical vuln	GitHub Security tab	Review within 24h
Dependabot alert	GitHub Security tab	Review within 7 days
New dependency added	PR diff	Review in PR

5.2 Vulnerability Response Process

1. Alert received (Grype/Dependabot)
        │
        ▼
2. Triage: Is it exploitable in our context?
        │
        ├── No → Document exception
        │
        └── Yes → Prioritize fix
                │
                ▼
        3. Update dependency / apply patch
                │
                ▼
        4. Release with new SBOM
                │
                ▼
        5. Verify fix in security scan

5.3 Severity Response SLAs

Severity	Response Time	Resolution Time
Critical	24 hours	72 hours
High	7 days	14 days
Medium	30 days	60 days
Low	Best effort	Next release

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

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

Enable GitHub Advanced Security for the repo (for SARIF upload)
Verify workflow runs on next push

7.2 Responding to Security Alerts

Go to repository → Security → Code scanning
Review each alert's details
For each alert:
- If false positive: Dismiss with reason
- If valid: Create issue, prioritize fix
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

sirosfoundation Supply Chain Security​

1. Overview​

2. SBOM Generation Workflow​

2.1 How It Works​

2.2 Workflow Features​

2.3 Output Files​

3. Outgoing SBOM Monitoring​

3.1 Continuous Vulnerability Scanning​

3.2 Artifact Publication​

3.3 Quality Metrics​

4. Incoming SBOM Monitoring​

4.1 Dependency Scanning​

4.2 Third-Party Dependency Sources​

4.3 Supply Chain Attack Detection​

5. Alerting & Response​

5.1 Alert Channels​

5.2 Vulnerability Response Process​

5.3 Severity Response SLAs​

6. Future Enhancements​

6.1 Dependency-Track Integration (Planned)​

6.2 Release Gating (Opt-in)​

7. Operational Procedures​

7.1 Adding SBOM to a New Repository​

7.2 Responding to Security Alerts​

7.3 Verifying a Release SBOM​

8. References​