Software Bills of Material
Software bills of material are full lists of every code package inside your app. You build them by running a scanner during your normal code build steps. Most engineering teams set up these tools inside their release pipelines. They grant broad read roles to the build system so it can check every file. When these permissions are too wide, build jobs can read private keys or prod databases. How software bills of material work in your build flow A build pipeline pulls code from your main repo a
Software Bill of Materials (SBOM): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Software bills of material are full lists of every code package inside your app. You build them by running a scanner during your normal code build steps. Most engineering teams set up these tools inside their release pipelines. They grant broad read roles to the build system so it can check every file. When these permissions are too wide, build jobs can read private keys or prod databases.
How software bills of material work in your build flow
A build pipeline pulls code from your main repo and external package stores. During this step, a scanner reads your lock files and container layers. It writes down the name, version, and maker of every single library. The tool then outputs a structured text file in a standard format. Teams store this file in a secure bucket or attach it to the app image.
To make this work, admins set up service roles for the build server. The server uses these roles to log in and read code across many repos. Many teams use one shared role for all build jobs to save time. That role often holds permissions to read cloud buckets, container stores, and secret stores. If a bad package runs during the build, it can use that same broad role.
Where build lists fall short during live app runs
Generating a dependency list helps you find known bugs before you ship code. Security teams read these files to see if an app uses a broken library. When a new bug comes out, you can search your lists right away. You do not need to scan the whole code base again. It also helps you check software licenses for legal rules.
Still, a static list only shows what went into the app at build time. It does not check what engineers, scripts, or apps do after they log in. Build tools check package names, while cloud roles only decide who can log in. Neither tool looks at the actual queries or commands running against live data. An approved app or user can still run a bad command in prod.
Teams also struggle with the data returned by live queries. Even when every library is clean, an engineer might query a table with user data. Native roles let the whole table return to the screen. Without field checks, emails, phone numbers, and card numbers appear in plain text. You need controls that inspect live commands and rewrite matched fields in results.
Software Bill of Materials (SBOM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to keep package lists accurate over time
Treat your dependency list as a live record that updates on every code push. Set up your pipeline to make a new file each time a developer merges code. Block the release if the scanner finds a high risk bug in any package. Sign the output file with a private key so no one can change it later.
Next, pair your build checks with strict rules for live system sessions. Give your build servers tiny roles that only read the exact repos they need. Remove broad admin roles from daily developer accounts and automated scripts. Check every live command and database query at the moment it runs.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
When should our team generate a new dependency list?
You should create a new list every time your pipeline builds an app image. This keeps your records tied to the exact version running in prod.
Do software bills of material stop live data leaks?
No, they only list the code packages inside your app at build time. They do not inspect live database queries or mask sensitive fields in results.
Who needs to read these package lists?
Security teams use them to track new bugs across all company apps. Legal teams and customers also read them to check open source licenses.