themarmack sbom-reviewer
The supply-chain risk dimension that isn't CVE matching. CVE flagging is well-served by daily-cve-digest + Dependabot; this skill covers structural concerns: who maintains the code, are releases signed, is the SBOM complete.
When to use
- New SBOM published — review for structural concerns before adopting the artifact.
- Vendor SBOM provided — assess the vendor's supply chain.
- Annual portfolio audit of declared dependencies' supply-chain posture.
- After a publicized supply-chain incident — re-scan for the affected pattern.
When NOT to use
- CVE matching →
daily-cve-digest. - License compliance →
license-compliance-checker. - Workflow security →
actions-workflow-hardener.
Input
- CycloneDX JSON (
bom.json) or SPDX (spdx.json/spdx.yaml) - Optionally: lockfile cross-reference (to verify SBOM matches actual dependencies)
Checks
1. Signing + provenance
| Check | Severity |
|---|---|
Component declares pedigree or provenance with signed attestation (SLSA / sigstore) |
INFO when present, MEDIUM when absent for tier-1 deps |
| Component release tagged but no signature on the tag | HIGH for critical-library deps |
| Component publisher matches expected upstream identity | HIGH if mismatch |
2. Maintenance health
| Check | Severity |
|---|---|
| Last upstream commit > 12 months ago (abandoned) | HIGH |
| Last release > 24 months ago | MEDIUM |
| Single maintainer on a critical-library tier dep | HIGH (per [[daily-cve-digest]]'s critical_libraries config) |
| Maintainer departed publicly (e.g., maintainer announced retirement / hand-off pending) | MEDIUM |
3. Known-malicious / typo-squat
| Check | Severity |
|---|---|
| Package name matches a known typo-squat pattern (Levenshtein ≤ 2 from a popular package, but newer publisher) | CRITICAL |
| Maintainer email / account in known-bad publisher list (per OpenSSF / community advisories) | CRITICAL |
| Package publisher recently transferred (within 90d) for a critical-library dep | HIGH |
4. SBOM completeness
| Check | Severity |
|---|---|
| Declared dependency depth < actual lockfile depth | HIGH |
| Components missing version OR purl | MEDIUM |
| Hashes missing for components | MEDIUM |
| Components present in lockfile not in SBOM | HIGH |
5. License consistency
| Check | Severity |
|---|---|
| Component license declared in SBOM differs from upstream registry declaration | HIGH (potential mislabeling) |
| Component lacks any license declaration | MEDIUM |
Workflow
- Parse the SBOM (CycloneDX or SPDX).
- For each component: run the 5 check categories.
- Cross-reference against
daily-cve-digest/stack.ymlto identify which components are critical-library tier (severity boost). - Produce findings: per-component, per-check.
- Summary: posture score (% of components passing), top concerns by severity — presented in chat.
- Persist the review — after presenting findings, write the full review note via
vault-writer.write_researchtovault/research/supply-chain/YYYY-MM-DD-sbom-{service-slug}.md(frontmatter perresearch.yml,topic: supply-chain) so future reviews and incident re-scans can query it.
Output structure
# SBOM Review — {SBOM filename or service}
## Summary
- Components in SBOM: {N}
- Findings: {M} ({critical/high/medium counts})
- Posture score: {%} of components pass all structural checks
## Top concerns
[per concern: component + reason + severity]
## Findings by category
[per category, listed]
## Cross-reference: critical libraries
- {Critical-library deps present + structural posture summary}
## Sources
{linked vault notes, stack.yml}
Lands at vault/research/supply-chain/YYYY-MM-DD-sbom-{service-slug}.md (workflow step 6).
Composes with
daily-cve-digest—stack.ymlis the critical-library reference.vault-writer.write_research— persists the review note (workflow step 6).license-compliance-checker— license dimension.- [[2026-06-20-actions-hardening-post-shai-hulud]] — supply-chain context.
Acceptance test (for step 26 done-criteria)
5 check categories documented; each with named checks + severity. Live exercise against a real SBOM deferred to first invocation.