Contents
Introduction
The supply chain defense series established that cooldown is a time-based defense that prevents “newly published malicious versions” from entering the dependency tree. But supply chain security also involves a prior question:
When a new vulnerability is disclosed, is our project in the blast radius?
If that question cannot be answered immediately, response times during an incident will be critically slow — regardless of how sophisticated the other defenses are. This article covers SBOM (Software Bill of Materials) — the tool that solves that problem — and how to automate it with GitHub.
The Risk: Not Being Able to Answer “Are We Affected?”
A modern frontend project pulls in hundreds or even thousands of dependencies. If package.json lists 50 direct dependencies, it is common for the full dependency tree — including all transitive dependencies pulled in by those 50 — to exceed 1,000 packages.
When a new CVE is disclosed in this environment, the following typically happens:
- A headline appears:
[Popular library] CVE-XXXX-XXXXX discovered - Someone on the team asks: “Are we affected?”
- Developers start searching through
package.json,yarn.lock, andpnpm-lock.yamlwith grep - Not finding it as a direct dependency, they go back to check whether it came in as a transitive dependency
- Once the affected apps and services are identified, patching begins
Fast, this process takes an hour or two. Slow, it takes days. And during that time, our systems may already be under attack.
The Price of Poor Visibility: What Log4Shell Revealed
Log4Shell (CVE-2021-44228), disclosed in December 2021, was an arbitrary code execution vulnerability in Apache Log4j. CVSS score: 10.0. Virtually every Java application was directly or indirectly affected.
The biggest lesson the incident left for security teams worldwide was not the vulnerability itself, but the fact that no one knew where in their organization Log4j was being used.
- Present without ever being listed as a direct dependency, because another library pulled it in
- Included as a fat jar inside a built JAR file, invisible to code search
- Nobody had an up-to-date picture of the dependency tree for older services
The CISA official advisory listed “Identify the use of Log4j” as the very first required action. Identification came before patching.
In the aftermath of this incident, the U.S. government issued Executive Order 14028, mandating that all software suppliers to the federal government submit an SBOM (CISA SBOM policy page). Visibility was formally recognized as a prerequisite for security.
What Is an SBOM?
An SBOM (Software Bill of Materials) is literally a “bill of materials for software” — a machine-readable record of which libraries, at which versions, and in which dependency relationships are included in a software build.
With an SBOM, the five-step process above collapses to four:
- A CVE is disclosed
- The SBOM is matched against the CVE database (automated)
- The list of affected systems is produced immediately
- Patching begins against that list
The answer to “are we affected?” arrives in computer time, not human time.
The two major SBOM standards are:
- CycloneDX: OWASP-led format. Supports both JSON and XML
- SPDX: Linux Foundation-led format. ISO/IEC 5962 standard
The tooling is nearly identical for both. What matters is simply having a process for generating and maintaining an SBOM regularly.
How to Apply It: GitHub Dependency Submission
SBOM sounds like it might require specialized tools and workflows, but if you are already working on GitHub, the most important part is very likely already running automatically. It helps to think of adoption in two tiers.
Foundation: GitHub Dependency Graph Already Runs Automatically
GitHub automatically generates a Dependency Graph when a repository contains standard manifest files like package.json, yarn.lock, pubspec.yaml, Gemfile, or pom.xml — with no additional configuration needed. This graph is matched against the GitHub Advisory Database to power Dependabot Alerts.
Check these two things:
- Settings → Security → “Dependency graph” is enabled (it is on by default)
- Security tab → “Dependabot alerts” — receive notifications for known CVE matches
If both are working — which they almost certainly are for mainstream ecosystems supported by GitHub like npm, pub, and gradle — Dependabot Alerts will automatically appear for affected dependencies as soon as a new CVE is published.
In short: for everyday supply chain visibility and CVE detection, no additional workflow is needed.
The most practical value described in the introduction — “being able to answer immediately whether we are affected when something like Log4Shell drops” — is already provided for free to GitHub users.
Additional: When You Need a Standard SBOM File
A standalone SBOM file in SPDX or CycloneDX format is only necessary in these scenarios:
- Compliance requirements from government, finance, or other regulated industries that mandate SBOM submission
- Attaching SBOM as a release artifact for customers or auditors
- Piping SBOM to external analysis tools like Trivy, Grype, or Snyk Container
- Tracking areas GitHub cannot automatically detect — vendored libraries, native binaries, etc. in build outputs
If one of these applies, add a single workflow:
# .github/workflows/sbom.yml
name: SBOM
on:
release:
types: [published] # attach as an artifact at release time
workflow_dispatch:
permissions:
contents: write
jobs:
generate-sbom:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@<SHA> # v6
- uses: actions/setup-node@<SHA> # v6
- run: corepack enable && yarn install --immutable
- uses: advanced-security/sbom-action@<SHA>
with:
path: ./Besides advanced-security/sbom-action, alternatives include Anchore’s sbom-action and CycloneDX’s GitHub Action. Regardless of which tool you use, the output is in SPDX or CycloneDX standard format and compatible with external tooling.
Summary
| Goal | What’s needed |
|---|---|
| Receive Dependabot Alerts on GitHub | Automatic (no setup required) |
| Maintain a dependency tree inventory | Automatic (no setup required) |
| Attach SBOM for external compliance | sbom-action workflow required |
| Pipe SBOM to external tools (Trivy, etc.) | sbom-action workflow required |
Limitations
SBOM is a visibility tool, not a defense tool. Keep these points in mind:
- An SBOM is only useful if someone acts on it. Connecting Dependabot alert notifications to a channel like Slack (
/github subscribe <ORG>/<REPO> vulnerability_alerts) is a necessary follow-up step. - An SBOM is a snapshot from build time. If dependencies change after it is generated, a new one must be produced. (This is why a scheduled cron job is recommended.)
- An SBOM does not capture everything. External scripts loaded via CDN (such as Google Fonts) will not appear in the SBOM. Tools like SRI cover that gap.
Conclusion
SBOM does not directly block attacks. But when an attack does occur — when the next Log4Shell-level event arrives — it compresses the response time from days to minutes.
Getting started with GitHub Dependency Submission takes a single workflow file. The overhead is minimal. And when the next major CVE drops, its value becomes impossible to ignore.
References
- Apache Log4j Vulnerability Guidance (CISA)
- GitHub Dependency Submission API
- CycloneDX SBOM specification
- SPDX SBOM specification
- CISA SBOM official page
- NIST Executive Order 14028 page
Was my blog helpful? Please leave a comment at the bottom. it will be a great help to me!
App promotion
Deku.Deku created the applications with Flutter.If you have interested, please try to download them for free.
