SBOM for DevOps: Generate, Scan and Manage Dependencies
An application can be small and still depend on hundreds of packages. A Python service may pull in transitive libraries through its web framework; a container image also contains operating-system packages. When a vulnerability is disclosed, the first question is often not “How do we patch it?” but “Which of our releases actually contain it?” A software bill of materials, or SBOM, helps answer that question.
This guide shows a practical SBOM workflow for a small DevOps team: choose the artifact to inventory, generate a machine-readable file, scan it, review the result, and preserve the SBOM with the release. It uses Syft and Grype for examples, while explaining how GitHub’s dependency graph fits into the picture. Commands are illustrative and should be run against your own project and image; they are not results from a security assessment.
What is an SBOM, and what problem does it solve?
An SBOM is a structured inventory of components in a software product. Useful entries identify a package, its version, supplier or ecosystem when available, and its relationship to other components. Think of it as the ingredient list for a particular build, not a certificate saying the product is secure. CycloneDX describes the purpose as representing software components and dependency relationships in a machine-readable format; SPDX is another widely used open standard.
The inventory improves incident response. If a new advisory names a specific library, a team can search release SBOMs to identify potentially affected builds. It also supports license review, procurement questions and the handoff between developers and operations. The value depends on coverage and freshness: an incomplete or stale SBOM can give false confidence.
An SBOM is not the same as a vulnerability scan. The SBOM says what the tool found. A scanner compares those components to advisories. Neither automatically establishes whether a flaw is reachable in your application, whether an exploit is feasible, or whether compensating controls exist.
Start with the artifact you actually ship
Repository, build output and container image are different inventories
A repository scan describes source files and package manifests that the tool can identify. A built container scan can additionally discover operating-system packages and libraries introduced by the base image or build stages. These inventories answer related but different questions. If customers run your container, attach an SBOM to that exact release image; if you also distribute a Python wheel or Java archive, create an inventory for that artifact as well.
Do not rely solely on an SBOM generated from the default branch and assume it describes a deployed image. Builds can use different lockfiles, build arguments, base images or dependency resolution. Record the release version, commit and immutable image digest alongside the generated file so you can map a finding to a real deployment.
What a useful SBOM should let you answer
For every important package, can you identify its exact version? Can you tell whether it came directly from your manifest, transitively from another dependency, or from the base image? Can you connect this SBOM to one specific build? Can the receiving team parse the format with its own tools? These questions matter more than simply counting how many lines the JSON file contains.
Choose a format: CycloneDX or SPDX
CycloneDX and SPDX both represent software component data, but their fields and integrations differ. CycloneDX emphasizes a detailed component and relationship inventory and also has related capabilities for vulnerability information. SPDX is an international open standard and is the format GitHub uses when exporting the current state of a repository dependency graph. Choose the format your downstream vulnerability, compliance or customer workflow accepts. If you need both, generate both from one scan rather than maintaining unrelated inventories manually.
Avoid equating format conversion with better detection. A converter can re-express data that already exists, but it cannot reconstruct packages a scanner never discovered. Keep the original scan output and document which tool, version and input produced each SBOM.
Generate your first SBOM with Syft
Syft is an open-source CLI that inventories container images and filesystems and supports CycloneDX JSON and SPDX JSON. Install it using the project’s current installation instructions, then run it against a small test project. Review the package list before using the output as an audit artifact; language-specific manifests, vendored code and compiled binaries may need different discovery approaches.
Example for a project directory: syft ./my-project -o cyclonedx-json=./sbom-project.json. Example for a locally built image: syft my-app:1.0 -o spdx-json=./sbom-image.spdx.json -o cyclonedx-json=./sbom-image.cdx.json. Syft’s documentation shows this output-file syntax. Use a meaningful immutable image reference for a release rather than a moving tag such as latest.
Inspect a few known components manually. If your Dockerfile installs a system package, verify that the image inventory includes it. If requirements or a lockfile name a library, verify the corresponding package and version. A missing expected package should trigger investigation of scan scope, build output or ecosystem support, not an immediate declaration that the package is absent.
A realistic Python and Docker example
Imagine a Flask API with a requirements lockfile and a Dockerfile based on a Linux Python image. First generate an SBOM from the checkout to understand application dependencies. Build the image, then generate another SBOM from the finished image. Compare the two: base operating-system packages will typically appear only in the image inventory, while development-only files in the checkout may never reach the release. That difference is useful information, not necessarily a scanning error.
If your build uses multiple stages, scan the final runtime image that will be pushed and deployed. A build stage can contain compilers and testing tools that are intentionally omitted from the final image. Conversely, a runtime package introduced by the base layer will not appear in a Python requirements file. Keep the inventories clearly named so reviewers do not confuse source and runtime scope.
Scan the SBOM for known vulnerabilities
Grype can scan an SBOM produced by Syft. The documented command is grype sbom:./sbom-image.cdx.json. It matches identified packages to known vulnerability records and reports findings for review. Check the scanner’s supported formats and current vulnerability database before integrating it into a release gate. A scanner result is a lead for triage, not a definitive exploitability verdict.
For each finding, validate the package identity and affected-version range, identify which artifact contains it, examine whether a fixed version exists, and decide who owns the remediation. A finding in a base-image package may require rebuilding on a patched base rather than editing application requirements. A transitive package may require updating the parent dependency or selecting a safer alternative.
Prioritize by exposure and impact, not only a single severity number. A remotely reachable service with a relevant vulnerable path deserves attention sooner than a package that is present but unused by the runtime. Document exceptions and expiration dates. Where a vulnerability-exploitability statement is used, make sure it refers to the precise product and vulnerability rather than treating an unrelated “not affected” statement as global permission to ignore it.
Where GitHub’s dependency graph helps—and where it stops
GitHub’s dependency graph summarizes manifest and lockfile data in a repository, plus dependencies submitted through its dependency submission API. GitHub documents an Export SBOM control under Insights → Dependency graph, and says its export uses SPDX. This is a fast route to a repository-level inventory and a useful independent cross-check against a local scan.
The repository export is not automatically the same as an SBOM for a built container image. It can miss components that only appear after packaging, such as base-image operating-system packages. Conversely, a container scan may not be the right representation of development-only dependencies. Use both views when they answer different operational questions, and label each output accurately.
Teams already using GitHub Actions can generate SBOM artifacts during workflows; GitHub documents supported actions for that purpose. Whether you use those or a CLI step, pin third-party actions to reviewed versions or commit SHAs, review their permissions and keep the workflow token narrowly scoped. For broader credential hygiene, see NeoAI Tech’s GitHub Actions secrets management guide.
Put SBOM generation into a release pipeline
A six-stage workflow
A sensible pipeline sequence is: check out the approved commit; install and test dependencies; build the release artifact; generate its SBOM; run vulnerability checks and human triage where required; then publish the artifact and its matching SBOM together. Record the commit and image digest in release metadata. This order avoids creating a polished inventory for something different from what was ultimately shipped.
Make failures visible. An SBOM generation error should not silently produce an empty file and still show a successful release. Validate that the JSON parses and contains the expected top-level metadata and at least representative packages. Compare known-package expectations between releases, but avoid a brittle gate that rejects every legitimate change in package count.
Store the SBOM as a release artifact with access appropriate to the project. A public open-source project may publish it openly; a private service may keep it in an artifact store. Decide retention based on incident-response needs, because the SBOM for a retired version can still matter when investigating a historical exposure. Restrict who can overwrite or delete release evidence.
Add policy gradually
Begin by generating and retaining an SBOM on every release. Next, review critical findings and set an explicit response owner. Once the workflow is reliable, introduce narrowly defined gates—for example, block a new release with an unreviewed critical finding affecting a production dependency. A blanket “fail on any vulnerability” policy often causes noisy failures and encourages people to bypass the pipeline. Publish your exception process and revisit exceptions after dependency or advisory updates.
Common SBOM mistakes
Scanning only source code while shipping containers is a scope error. Scanning only an unpinned latest image can make the inventory irreproducible. Treating an SBOM as proof of security confuses inventory with assessment. Uploading a sensitive private SBOM to an unapproved third-party service can leak details about your stack. And discarding old release inventories makes it difficult to answer whether an earlier version was affected.
Another frequent mistake is assuming every detected vulnerability can be fixed by changing one direct dependency. Transitive packages and base layers have different owners and update paths. Record the package’s origin and the artifact where it appears, then assign remediation to the team that controls that layer. If a component is not detected, check scan coverage before concluding it is safe.
A practical first-week implementation plan
Day one: pick one service and identify its shipping artifact and owner. Day two: generate both a source and runtime SBOM, inspect known packages, and select the format your consumers can parse. Day three: scan the runtime SBOM and triage a small sample of findings. Day four: add generation, validation and storage to the release workflow. Day five: document who reviews new advisories, how releases are mapped to SBOMs and when an exception expires.
If your application is not containerized, adapt the same principles to your wheel, package, JAR or binary distribution. The central question is always “What exactly did we ship?”—not “Which command looks most impressive in a demo?”
Frequently asked questions
Does an SBOM make my application secure?
No. It improves visibility into identified components. Security still depends on patching, configuration, access control, testing, secure build practices and a response process. An incomplete inventory can also miss important packages.
Should I scan the repository or the container?
Usually both when you ship a container. The repository helps with source-level dependency management; the final container better reflects runtime and base-image packages. Name and store the outputs separately.
Is an SBOM the same thing as a vulnerability report?
No. The SBOM is the component inventory. A vulnerability scanner compares that inventory with advisory data. A finding then needs validation and risk assessment in the context of the actual deployment.
How often should an SBOM be regenerated?
Generate one for every release or build artifact whose composition may change. Re-scan retained SBOMs against updated vulnerability data when new advisories appear; a newly disclosed flaw can affect an unchanged historical release.
Which format should a small team choose?
Start with a format supported by your consumers. SPDX works well with GitHub’s repository export; CycloneDX is another common choice for component and vulnerability-management workflows. Test the output with the receiving tool and document the version and generator.
Turn an inventory into an operational habit
The most useful SBOM is the one your team can connect to a real release, regenerate when needed and consult quickly during an incident. Start with one service, validate coverage, automate generation and attach ownership to findings. NeoAI Tech works on practical cloud and software delivery; contact us if you need help designing a build, release or dependency-security workflow for your project.
Primary documentation and standards
$50
Product Title
Product Details goes here with the simple product description and more information can be seen by clicking the see more button. Product Details goes here with the simple product description and more information can be seen by clicking the see more button
$50
Product Title
Product Details goes here with the simple product description and more information can be seen by clicking the see more button. Product Details goes here with the simple product description and more information can be seen by clicking the see more button.
$50
Product Title
Product Details goes here with the simple product description and more information can be seen by clicking the see more button. Product Details goes here with the simple product description and more information can be seen by clicking the see more button.
Comments