Pipeline Bill of Materials
A pipeline bill of materials lists every runner, script, and tool in a build flow. You create one by recording each step, image, and key used during a run. Most teams start by saving build logs and runner files after each job finishes. Still, broad runner permissions can let a single build step change records or read extra data. How a pipeline bill of materials works in practice A normal software bill lists the libraries inside your final app. A pipeline bill of materials goes further and tra
Software Bill of Materials (SBOM) + DevSecOps Pipeline Design: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A pipeline bill of materials lists every runner, script, and tool in a build flow. You create one by recording each step, image, and key used during a run. Most teams start by saving build logs and runner files after each job finishes. Still, broad runner permissions can let a single build step change records or read extra data.
How a pipeline bill of materials works in practice
A normal software bill lists the libraries inside your final app. A pipeline bill of materials goes further and tracks the build system itself. It records the exact runner image, the build scripts, and the third-party actions that ran. It also logs which service roles and keys the runner used during the job.
To set this up, your build tool collects metadata at the start of every step. The runner checks the hash of each container image and script before it runs them. When the build finishes, the system writes these facts into a signed file. Security teams then read this file to verify how the app was built.
This workflow relies on role settings inside your source control and cloud platforms. Each runner gets an identity role so it can pull code and push build outputs. Teams also give the runner permissions to talk to databases or cloud storage during tests. The build record captures which role ran the job and when the job finished.
What native build tracking solves and what it misses
Recording your build steps helps you find weak spots in your delivery flow. If a build tool has a bad bug, you can check past build records fast. You will know right away which apps used that broken tool during their build runs. Signing the record also proves that the build steps ran in the expected order.
Still, a static build record only tells you which tools and roles were present. Native runner roles decide who can log in, not what individual commands do in flight. Once a build step starts with a valid database role, the runner has full role permissions. The build record does not show the exact queries or commands that ran inside that step.
This gap matters when a build job runs database changes or pulls test data. A third-party build plugin runs in the same space as your own scripts. If that plugin reads your database key, it can run broad queries against live tables. Your pipeline record will show a normal build, even if a step pulled sensitive records.
Software Bill of Materials (SBOM) + DevSecOps Pipeline Design: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to tighten runner roles and audit build steps
Teams reduce this risk by splitting large build jobs into smaller, separate steps. You should give each step its own narrow role instead of sharing one broad role. For example, the compile step should never hold the key for the database migration step. When a step finishes, its temporary role should expire right away.
You also need visibility into the actual commands that runners send to external systems. Tracking the container hash is good, but logging every query and command is better. If a test runner queries a table, your logs should show the exact statement. Masking rules can also rewrite emails, phone numbers, and card numbers in query results.
Combining a signed build record with command-level checks gives you full clarity. You know which tools ran in the pipeline and what they did to your systems. Audits become much faster because you have both the build list and the action logs.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How is a pipeline bill of materials different from an SBOM?
An SBOM lists the code packages inside your finished software app. A pipeline bill of materials lists the runners, plugins, and steps that built that app. You need both records to check your full software supply chain.
When should our build system create this record?
Your build system should create the record during every build and deploy run. Waiting until after a release makes it hard to capture temporary runner states. Recording facts at runtime keeps the file accurate for every single build.
Does a signed build record stop bad commands during a deploy?
No, a signed build record only logs which tools ran during the job. It does not inspect or block individual database queries or shell commands in flight. You need command-level controls to stop unsafe actions while the build runs.