security-sbomUse this skill when asked about SBOM, software bill of materials, dependency graph, SPDX, CycloneDX, supply chain security, component inventory, or dependency analysis. This skill enforces: SBOM generation in CycloneDX/SPDX formats, dependency vulnerability correlation with severity gating, license compliance checks, and attestation signing. Do NOT use for:…
Independent GitHub snapshot · Automated classification · Original documentation governs
Design an SBOM generation pipeline with format selection, vulnerability correlation, license compliance, and policy enforcement for software supply chain security. Every build produces a signed, verifiable inventory of all components.
De facto standard for software supply chain security. OWASP project. JSON and XML formats. Rich dependency tree with parent-child relationships. Supports: components, services, vulnerabilities, licenses, pedigree (patch/backport info), external references (advisory URLs, issue tracker), properties (custom key-value metadata), formula (dependency computation evidence). Best for: CI/CD integration, vulnerability correlation tooling, automated policy enforcement. JSON preferred — wider tool support, easier to diff and query with jq.
International standard for software package data exchange. RDF/XML, tag-value, JSON, YAML, and XLSX formats. Stronger on legal and license documentation. Supports: package provenance, file-level licensing, cross-reference integrity (package verification codes), annotation by different agents. Best for: regulatory compliance, legal review, export control documentation. Mandatory for US federal government software procurement (EO 14028).
SPDX 2.3 (current stable): flat package list, document-centric model, proven tooling ecosystem, widely adopted. SPDX 3.0 (emerging): profile system (licensing, security, usage, build), core namespace for interoperability, relationship types describing build inputs/outputs, AI/ML dataset profiles, better support for composite SBOMs (SBOM-of-SBOMs). Migration path: generate SPDX 2.3 now, add SPDX 3.0 alongside as tooling matures. Both share the same licensing model.
Best for container images and filesystem scans. Supports all major ecosystems (npm, pip, Maven, Go, Cargo, NuGet, RPM, APK, etc.). Output: CycloneDX JSON/XML, SPDX JSON/Tag-Value, Syft custom JSON. Usage: syft packages <image> -o cyclonedx-json for container scans, syft dir:. -o cyclonedx-json for source tree scans. Fast (~1-3 seconds), no daemon dependency. Integrates with Grype for vulnerability scanning in one pipeline.
Unified scanner (SBOM + vulnerability + secrets + IaC). Can generate SBOM and scan it in a single pass. Usage: trivy image --format cyclonedx --output bom.json <image>. Generates attestation-compatible output with embedded vulnerability results. Slower than Syft alone but reduces tool count.
Language-agnostic, integrates with build tools via plugins. Plugins: cyclonedx-maven-plugin (Maven), cyclonedx-npm (npm), cyclonedx-gradle (Gradle), cyclonedx-pip (pip), cyclonedx-go (Go modules). Generates SBOM during build, capturing exact resolved dependency versions. Usage: cyclonedx-bom -o bom.xml --include-compile-scope. More accurate than post-hoc scanning because it uses the build tool's resolved dependency tree.
Generate SBOM after successful build, before artifact push. Store alongside the artifact in the registry. Propagate through environments for deployment-time policy checks.
# GitHub Actions example
jobs:
build:
steps:
- run: syft packages . -o cyclonedx-json > bom.json
- run: cosign attest --predicate bom.json --type cyclonedx $IMAGE
- run: trivy image --severity CRITICAL,HIGH --exit-code 1 $IMAGE
Policy gates: block promotion from dev→staging if CRITICAL vulns, block staging→prod if any HIGH vulns older than 7 days without patch. Weekly full re-scan with SBOM diff report for drift detection.
https://api.osv.dev/v1/query. Supports all major ecosystems.https://services.nvd.nist.gov/rest/json/cves/2.0. References CWE classifications and CVSS 3.1 scores.| Severity | CVSS Range | Policy |
|---|---|---|
| CRITICAL | 9.0–10.0 | Block build. Patch SLA: 48 hours |
| HIGH | 7.0–8.9 | Block promotion to prod. Patch SLA: 7 days |
| MEDIUM | 4.0–6.9 | Warn. Review at next triage |
| LOW | 0.1–3.9 | Allow. Log for quarterly audit |
Define license allowlist and enforce at pull request time, not release time.
# .license-policy.yml
allow:
- MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause
- ISC, Unlicense, CC0-1.0, Zlib
block:
- GPL-3.0, AGPL-3.0, SSPL
- BUSL-1.1 (source-available, not open source)
- any unknown/no-license
review:
- LGPL-2.1, LGPL-3.0, MPL-2.0, EPL-2.0
- CDDL-1.0, EUPL-1.2
Tools: license_checker, askalono (fast license detection), scancode-toolkit (comprehensive), built-in checkers in Snyk and FOSSA.
Sign SBOM to establish non-repudiation. Verify before deployment.
cosign attest --predicate bom.json --type cyclonedx $IMAGE
cosign verify-attestation --type cyclonedx $IMAGE
Stores attestation in OCI registry as an attached artifact. Uses keyless signing (OIDC identity from GitHub/GitLab) or key-pair signing. No key distributed management overhead with keyless mode.
Attestation framework for multi-step build pipelines. Each step produces a signed link (command, materials, products). Final layout verification ensures every step was performed by the right actor with the right inputs/outputs. Use with Sigstore for the signing layer.
# Deployment gate
step:
verify-attestation:
- signature matches expected identity
- predicate type is cyclonedx
- no CRITICAL vulnerabilities in attestation
- license blocklist not violated
Store SBOM alongside the artifact it describes. Distribution options:
cosign download attestation. Preferred for container-based deployments.Retention: current release + last 3 releases. Weekly full SBOM regeneration for deployed artifacts to catch newly published vulnerabilities.
Exact user phrases: "SBOM", "software bill of materials", "dependency graph", "SPDX", "CycloneDX", "supply chain", "component inventory", "dependency analysis", "license compliance", "vulnerability correlation", "attestation", "dependency tree", "syft", "cyclonedx", "spdx".
Before activating, verify:
SBOM pipeline configuration as YAML and policy files.
# SBOM generation step
# Policy rules
# CI pipeline config
# Attestation payload template
No preamble. No postamble. No explanations. No filler/hedging/transitions. Compress output — why use many token when few do trick.
250 lines of configuration and policy.
CycloneDX default — de facto standard, rich dependency tree, broad tooling, OWASP-backed. SPDX for regulatory contexts (ISO 5962:2021). Generate both when compliance requires SPDX. Store SBOM alongside build artifacts in artifact registry. SBOM per: service image, library package, deployment artifact.
Syft for container images and filesystems — fastest, broadest ecosystem support. CycloneDX CLI for build-time generation with resolved dependency graph. Trivy when unified SBOM + vulnerability scanning is preferred.
Source: OSV.dev primary (fastest updates), NVD comprehensive (slower, CVSS 3.1), GHSA (GitHub ecosystem). Correlate by package name + version range. Apply severity gates per environment.
Every dependency checked against allowlist. Block copyleft and unknown licenses. Flag weak-copyleft for legal review. Store policy in version-controlled .license-policy.yml. Enforce at PR time.
Sign SBOM with Sigstore Cosign. Keyless mode preferred. Verify attestation signature and predicate content before deployment. In-toto layout for multi-step build chains.
Generate SBOM after build, before image push. Store in artifact registry. Verify attestation in deployment pipeline. Gate deployment on vulnerability policy. Monthly full dependency audit with SBOM diff report.
Push SBOM to Dependency Track or Harbor for continuous monitoring. Configure alerts for new vulnerabilities on deployed components. Weekly re-scan of all active SBOMs. Retention: current + last 3 releases.
# Generate CycloneDX JSON SBOM for Docker image
syft packages registry.example.com/app:v1.2.3 \
-o cyclonedx-json > bom.cdx.json
# Generate SPDX JSON SBOM
syft packages registry.example.com/app:v1.2.3 \
-o spdx-json > bom.spdx.json
# Scan local directory for source-level SBOM
syft packages dir:. \
-o cyclonedx-json > bom-source.cdx.json
# Install CycloneDX plugin for npm
npm install -g @cyclonedx/cyclonedx-npm
# Generate SBOM during build
cyclonedx-npm --output-format JSON > bom.cdx.json
# Generate SBOM and scan in one pass
trivy image --format cyclonedx \
--output bom.cdx.json \
--severity CRITICAL,HIGH \
registry.example.com/app:v1.2.3
#!/usr/bin/env python3
"""Validate SBOM before deployment."""
import json
import sys
def validate_sbom(path: str) -> bool:
with open(path) as f:
sbom = json.load(f)
components = sbom.get("components", [])
for c in components:
vulns = c.get("vulnerabilities", [])
for v in vulns:
if v.get("severity") == "critical":
print(f"BLOCKED: {c['name']}@{c['version']} has {v['id']}")
return False
print(f"SBOM validated: {len(components)} components, 0 critical vulns")
return True
if __name__ == "__main__":
sys.exit(0 if validate_sbom(sys.argv[1]) else 1)
name: SBOM Pipeline
on:
push:
branches: [main]
jobs:
sbom:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Generate SBOM
uses: anchore/sbom-action@v0
with:
path: ./
format: cyclonedx-json
output-file: bom.cdx.json
- name: Upload SBOM
uses: actions/upload-artifact@v4
with:
name: sbom
path: bom.cdx.json
- name: Vulnerability Scan
uses: aquasecurity/trivy-action@master
with:
scan-type: sbom
scan-ref: bom.cdx.json
severity: CRITICAL,HIGH
exit-code: 1
- name: Sign SBOM
run: |
cosign attest --predicate bom.cdx.json \
--type cyclonedx \
--keyless \
registry.example.com/app:${{ github.sha }}
package sbom.policy
# Block if any component has a critical vulnerability
default allow = false
allow {
count(violations) == 0
}
violations[component] {
component := input.components[_]
vuln := component.vulnerabilities[_]
vuln.severity == "critical"
}
# Block copyleft licenses
license_violations[component] {
component := input.components[_]
component.licenses[_].id == "GPL-3.0-only"
}
# .github/workflows/sbom-policy.yml
jobs:
policy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check SBOM Policy
run: |
opa eval --data sbom-policy.rego \
--input bom.cdx.json \
"data.sbom.policy.allow"
Attacker publishes a malicious package to a public registry with the same name as a private/internal package. Package managers without scoping resolve to the public registry. Mitigation: use scoped packages (@org/package), enforce registry allowlisting, verify package provenance.
Attacker registers packages with names similar to popular packages (e.g., reqeusts vs requests). Mitigation: use package lockfiles, enable 2FA for package publishing, monitor for lookalike packages.
Attacker takes over a maintainer's account and publishes a malicious update. Mitigation: package signing (Sigstore), multi-party publishing, npm OTP enforcement.
A legitimate package depends on a compromised indirect dependency. Mitigation: SBOM analysis of full dependency tree, dependency pinning with hash verification, dependency auditing.
Attacker pushes a malicious tag to a registry that overrides an existing version. Mitigation: use digest-based references, enable tag immutability, sign releases.
Generating SBOM after deployment misses the purpose of vulnerability-aware deployment decisions. SBOM must be generated during build, before artifact push, and verified in the deployment pipeline.
Generating an SBOM but never scanning it for vulnerabilities defeats the purpose. Always correlate SBOM components against vulnerability databases (OSV, NVD, GHSA) at build time and continuously after deployment.
SBOM that only includes direct dependencies misses the majority of the attack surface. Transitive dependencies account for 70-90% of vulnerabilities in modern applications. Include full dependency tree in the SBOM.
Generating SBOM once at release and never refreshing it. New vulnerabilities are discovered daily. Deployed components must be continuously monitored against updated vulnerability databases. Weekly re-scan with automated alerting.
SBOM without cryptographic attestation can be modified or replaced by an attacker. Anyone could claim an artifact has a clean SBOM. Sign the SBOM with Sigstore/Cosign and verify before deployment.
Build-time SBOM includes dev dependencies not present in production. Generate separate production SBOM that excludes dev dependencies. Container image SBOM represents what's actually deployed.
| Feature | Syft | Trivy | CycloneDX CLI | FOSSA |
|---|---|---|---|---|
| SBOM formats | CycloneDX, SPDX | CycloneDX, SPDX | CycloneDX | CycloneDX, SPDX |
| Input types | Images, filesystems, repos | Images, repos, filesystems | Build plugins | Source repos |
| Speed | Fast (1-3s) | Medium (5-15s) | Fast (1-5s) | Slow (scan) |
| Vulnerability scan | Via Grype | Built-in | No | Built-in |
| License detection | Via Syft metadata | Yes | Yes | Yes |
| CI integration | GitHub Action, CLI | GitHub Action, CLI | Maven/Gradle/npm | Native CI |
| Attestation | Via Cosign | Via Cosign | No | No |
| Cost | Free (Apache 2.0) | Free (Apache 2.0) | Free | Commercial |
| Best for | Primary SBOM tool | Unified scanning | Build-time accuracy | Enterprise compliance |
security-container-security for image scanning integration
devops-ci-cd for pipeline configuration and artifact storage
` interface EventObserver { onEvent(event: T): Promise; }
class EventBus { private observers: Set<EventObserver> = new Set(); subscribe(observer: EventObserver): void { this.observers.add(observer); } unsubscribe(observer: EventObserver): void { this.observers.delete(observer); } async emit(event: T): Promise { const results = Array.from(this.observers).map(o => o.onEvent(event)); await Promise.allSettled(results); } } `
config: defaults: timeout: 30s retryCount: 3 overrides: production: timeout: 60s retryCount: 5 development: timeout: 300s retryCount: 1
| Metric | Threshold | Severity | Action |
|---|---|---|---|
| Error rate | > 1% over 5min | Critical | Page on-call |
| p99 latency | > 2s over 5min | Warning | Investigate |
| Throughput drop | > 50% over 1min | Critical | Check upstream |
| Queue depth | > 1000 over 1min | Warning | Scale consumers |
| Disk usage | > 85% | Warning | Clean or expand |
| Memory usage | > 90% heap | Critical | Restart or scale |
| Anti-Pattern | Symptom | Root Cause | Solution |
|---|---|---|---|
| Premature optimization | Complex code for no measured benefit | Guessing instead of profiling | Measure first, optimize based on data |
| Copy-paste reuse | Duplicate code across codebase | Lack of abstraction | Extract shared logic into libraries |
| Gold-plating | Features with no current requirement | Over-engineering | YAGNI — build what's needed now |
| Magical thinking | Assumptions without validation | Skipping error handling | Handle all failure modes explicitly |
Cache hierarchy: L1 (in-memory local) → L2 (distributed Redis/Memcached) → L3 (CDN/Edge). Cache invalidation: TTL-based (simple, stale), event-based (complex, fresh), write-through (consistent, higher write latency), write-behind (fast writes, eventual consistency).