An ABOM (Actions Bill of Materials) is a complete inventory of every GitHub Action your CI/CD pipelines depend on — including transitive dependencies buried inside composite actions, reusable workflows, and tool wrappers that your workflow files never mention directly.
If you know what an SBOM is, you already get it. SBOMs catalog your application dependencies. ABOMs catalog your pipeline dependencies. And right now, most organizations have no idea what's actually running in their CI.
The problem
Take this workflow:
- name: Scan for vulnerabilities
uses: crazy-max/ghaction-container-scan@v3
No mention of Trivy anywhere. But ghaction-container-scan downloads and runs Trivy internally. When 76 of 77 Trivy release tags were poisoned with credential-stealing malware in March 2026, organizations that grepped their workflows for trivy-action found nothing — and assumed they were safe.
They weren't.
This isn't a Trivy-specific problem. It's a structural one. GitHub Actions have a dependency tree just like application code does, but nobody's been tracking it.
Why SBOMs don't cover this
SBOMs document what goes into your software — libraries, packages, container base images. That's the artifact side.
But the pipeline that builds, tests, scans, and deploys that software has its own dependency tree. A compromised CI action can steal every secret in your pipeline, poison every artifact it touches, and propagate to every downstream system — and none of that shows up in an SBOM.
After Trivy, this stopped being theoretical. The attack exfiltrated AWS credentials, Kubernetes tokens, Docker configs, and SSH keys from CI runners. It then used stolen npm credentials to publish a self-propagating worm into downstream packages. The pipeline was the entry point for all of it.
What an ABOM contains
An ABOM maps every action in your workflows, resolved recursively:
Direct dependencies — the actions your workflows reference explicitly. This is what grep finds.
Transitive dependencies — actions called by composite actions or reusable workflows your workflows use. This is what grep misses. A single uses: line in your workflow might resolve to a chain of five or six nested actions, any one of which could be compromised.
Embedded tools — actions that don't call other actions but silently download and execute external tools like Trivy, Grype, or Snyk. These don't show up as action dependencies at all — you have to analyze the action's metadata and inputs to detect them.
For each action, the ABOM records the owner, repository, version reference, whether it's pinned to an immutable SHA or a mutable tag, and the full chain of how your workflow reaches it.
What you do with it
Incident response. When a GitHub Action gets compromised, you need to know in minutes whether you're affected — not after a manual audit of every composite action your workflows use. Query the ABOM for the affected action and get an immediate answer, including transitive and embedded exposure.
CI gate. Generate an ABOM on every pull request and fail the build if it contains a known-compromised action. The same way you'd fail a build for a critical CVE in an application dependency.
Compliance. If you're already generating SBOMs for regulatory or customer requirements, your CI/CD pipeline is a gap in that inventory. An ABOM closes it.
Drift detection. Compare ABOMs across builds to detect when a new transitive dependency appears or when a previously-pinned action gets changed to a mutable tag.
Standard formats
ABOMs shouldn't be a proprietary format. The dependency relationships in a CI pipeline map cleanly onto existing BOM standards:
- CycloneDX 1.5 — actions become components, transitive relationships go in the dependency graph, compromised actions show up as vulnerabilities. Plugs directly into Dependency-Track, Grype, and other tooling.
- SPDX 2.3 — actions become packages with
DEPENDS_ONrelationships. Works with existing license compliance and SBOM aggregation tools.
This means you can manage your pipeline dependencies with the same tools you already use for application dependencies.
Try it
We built abom to generate ABOMs from any GitHub repository:
# Install
go install github.com/julietsecurity/abom@latest
# Generate an ABOM for your repo
abom scan .
# Check against known-compromised actions
abom scan . --check
# Export as CycloneDX
abom scan . -o cyclonedx-json
It resolves transitive dependencies by fetching action metadata from GitHub, caches results locally, and checks against a community-maintained advisory database of known-compromised actions. It's open source under Apache 2.0.
This will happen again
The Trivy compromise was not a one-off. GitHub Actions are a high-value target: they run with access to cloud credentials, deployment keys, package registry tokens, and production infrastructure. Any widely-used action is one misconfigured token away from becoming the next supply chain incident.
The question is whether you'll find out you were affected from a tool, or from an incident report.
Questions? Reach us at contact@juliet.sh.