Generating SBOMs using Syft and Grype

Software bills of materials, or SBOMs, are becoming a practical part of software supply chain security rather than a niche compliance artefact. For UK SMEs building or shipping software, they give you a structured inventory of what is inside an application, container image, or release package. That inventory helps with vulnerability response, supplier assurance, and internal change control.

Syft and Grype are a common pairing for this work. Syft generates the SBOM, while Grype checks the resulting inventory against known vulnerability data. Used well, they can fit into a development workflow without adding much friction. Used badly, they can create noise, false confidence, or pipeline failures that teams stop trusting.

Why SBOM generation matters in software supply chain security

What an SBOM is and what it is not

An SBOM is a machine-readable list of software components and related metadata. In practice, that usually includes package names, versions, suppliers where available, hashes, and dependency relationships. It may also include the application itself, operating system packages, language libraries, and transitive dependencies pulled in by build tools.

An SBOM is not a security control by itself. It does not prevent vulnerable code from being shipped, and it does not prove that software is safe. What it does provide is visibility. That visibility is valuable when you need to answer questions such as:

• Which releases contain a vulnerable library?
• Which container images still include an old base image?
• Which customer-facing service depends on a package with a newly disclosed issue?
• What third-party components were included in a build at a specific point in time?

For technical teams, the main benefit is traceability. For procurement and supplier assurance, the benefit is evidence. For incident response, it can shorten the time needed to work out exposure.

Where SBOMs fit in secure development and procurement

SBOMs sit between secure development and operational assurance. In a secure development lifecycle, they support dependency management, release review, and vulnerability response. In procurement, they help buyers understand what they are consuming from a supplier and whether the supplier can identify affected components quickly.

For UK SMEs, this is especially useful where the engineering team is small and the product stack is built from multiple layers, such as a web application, a container runtime, managed cloud services, and several open-source libraries. Without an SBOM, dependency risk is often managed by memory, spreadsheets, or ad hoc package lists. That becomes unreliable as soon as releases accelerate.

Choosing Syft and Grype for practical SBOM workflows

Syft for software inventory generation

Syft is a software composition analysis tool that can generate SBOMs from a range of inputs, including container images, directories, archives, and some language ecosystems. It is useful because it can inspect artefacts after they are built, which means it can see what actually shipped rather than what the source tree suggests should have shipped.

That distinction matters. Source repositories may not reflect generated files, vendored dependencies, or packages introduced by the build process. Syft can help close that gap by analysing the final artefact as part of the release process.

Grype for vulnerability matching and triage

Grype consumes SBOMs or direct artefacts and matches component metadata against vulnerability feeds. The output is a list of findings that can be used for triage, ticketing, or pipeline gating. It is not a replacement for human judgement. A finding needs context such as exploitability, exposure, compensating controls, and whether the vulnerable component is actually reachable in the deployed service.

In practice, Syft and Grype work best when treated as a repeatable workflow rather than one-off scanners. Syft creates the inventory, Grype checks it, and the results are stored as build artefacts so they can be reviewed later if a vulnerability disclosure affects an older release.

Designing an SBOM workflow for a UK SME engineering team

Build-time versus release-time generation

There are two common places to generate SBOMs. The first is during the build itself. The second is at release time, after the artefact has been assembled and before it is promoted.

Build-time generation is useful when you want every build to produce an inventory automatically. It is easy to automate and gives you a record for each pipeline run. Release-time generation is often better when you want the SBOM to describe the exact artefact that is being signed, stored, or deployed.

For most SMEs, the best pattern is to do both where practical:

• Generate a draft SBOM during the build for early visibility.
• Generate or refresh the SBOM again for the final release artefact.
• Store the release SBOM alongside the signed artefact and release notes.

This gives developers fast feedback and gives operations a trusted record of what was deployed.

Handling container images, source repositories, and packaged artefacts

The input you choose affects the quality of the SBOM. A source repository scan is useful for early analysis, but it may miss build-time additions. A container image scan is usually better for production services because it reflects the runtime environment. A packaged artefact scan is useful for desktop software, archives, or distributable bundles.

For containerised applications, scan the image that will actually be deployed, not just the Dockerfile. For example:

syft myregistry.example.com/myapp:1.4.2 -o spdx-json > sbom.spdx.json

That approach captures the final image contents, including base image packages and any copied application files. If you also want to understand build inputs, scan the source tree separately and compare the two inventories.

Generating SBOMs with Syft in common delivery environments

Local developer use and CI pipeline use

Developers can run Syft locally to inspect a container image or working directory before committing. That is useful for quick checks, especially when introducing a new dependency or base image. In CI, the same command can be used as a standard pipeline step so the output is consistent across teams.

A simple local workflow might look like this:

syft dir:. -o cyclonedx-json > sbom.cdx.json

For container images:

syft image:myapp:latest -o spdx-json > sbom.spdx.json

For CI systems, the important point is consistency. Use the same output format, the same naming convention, and the same retention policy across builds. If every team stores SBOMs differently, they become difficult to search and compare.

Output formats such as SPDX and CycloneDX

Syft supports common SBOM formats such as SPDX and CycloneDX. Both are widely used machine-readable standards for software inventory exchange. The choice is usually driven by downstream tooling, customer expectations, or procurement requirements.

As a rule of thumb:

• Use SPDX if your downstream consumers already expect it or if you want broad interoperability with compliance and inventory tooling.
• Use CycloneDX if your ecosystem already uses it for dependency and vulnerability workflows.

There is no universal winner. The practical question is which format your pipeline, security tooling, and customers can consume without extra conversion steps. If you need both, generate both from the same build stage rather than maintaining separate scans.

Using Grype to assess SBOM content for known vulnerabilities

Matching package metadata to vulnerability feeds

Grype compares the component data in the SBOM with vulnerability information from its feeds. The quality of the match depends on the accuracy of the package metadata, the completeness of the SBOM, and the quality of version identification. That means a clean inventory is important. If the SBOM is incomplete, the vulnerability output will be incomplete too.

A basic scan against an SBOM might look like this:

grype sbom:sbom.spdx.json -o table

For pipeline use, JSON output is often more useful because it can be parsed into tickets or dashboards:

grype sbom:sbom.cdx.json -o json > grype-results.json

From there, teams can route findings into a ticketing system, a security dashboard, or a release gate.

Reducing noise with ignore rules and policy thresholds

Vulnerability scanning is only useful if teams can act on the output. Grype will often find issues that are not immediately actionable, such as vulnerabilities in packages that are not reachable in the deployed path, or issues that are already mitigated by configuration, isolation, or compensating controls.

To keep the signal useful, define a small number of policy rules. Examples include:

• Fail the build only for critical vulnerabilities in internet-facing services.
• Raise a review task for high-severity issues in internal services.
• Ignore findings that are formally accepted for a fixed period and tracked in a risk register.

Be careful with ignore rules. They should be explicit, time-bound, and reviewed. A long list of permanent suppressions usually means the process is hiding risk rather than managing it.

Integrating SBOM generation into CI/CD without creating friction

Pipeline stages, artefact storage, and retention

A practical pipeline pattern is to place SBOM generation after the build and before deployment. At that point the artefact exists, but it has not yet been promoted. The pipeline can then archive the SBOM, the Grype output, and the build metadata together.

Useful artefacts to retain include:

• The SBOM in a machine-readable format
• A human-readable summary for release notes
• The Grype vulnerability report
• The image digest or package hash
• The pipeline run ID and commit SHA

Retention matters because SBOMs are most valuable when you need to look back at a specific release. If a vulnerability is disclosed later, you need to know exactly which artefact versions were affected. Keep the SBOM for as long as you keep the release artefact, and ideally in the same storage system or linked release record.

Failing builds versus creating review gates

Not every finding should fail a build. In smaller teams, overly strict gates can create release bottlenecks and encourage developers to bypass the process. A better approach is to define different responses by severity and exposure.

For example:

• Critical findings in production releases may block promotion.
• High findings may create a mandatory review task before release.
• Medium findings may be logged for scheduled remediation.

This approach keeps the pipeline usable while still making risk visible. The key is to make the policy predictable. Developers should know in advance what will block a release and what will not.

Operational considerations for maintaining SBOM quality

Transitive dependencies and build reproducibility

Most software risk sits in transitive dependencies, not just the packages a team deliberately added. That is why SBOM quality depends on how the build resolves dependencies. If builds are not reproducible, the SBOM may vary from one run to the next even when the source code has not changed.

To improve quality, pin dependency versions where possible, use lock files, and avoid uncontrolled package resolution during release builds. If your build process pulls from public registries, document which registries are trusted and how they are authenticated.

Version drift, base image updates, and re-scanning cadence

SBOMs are point-in-time records. They do not stay current by themselves. If your base image is updated, or if a package repository changes, the SBOM for an older release may no longer reflect the latest vulnerability status. That is why re-scanning matters.

A sensible cadence is:

• Scan on every build
• Re-scan release artefacts when a significant vulnerability disclosure affects your stack
• Periodically review older supported releases

For containerised services, also track base image refreshes. A small change in the base layer can remove several known issues at once, but only if the image is rebuilt and the SBOM is regenerated.

How to use SBOMs for remediation and supplier assurance

Prioritising fixes using exploitability and exposure

Grype findings should be prioritised using more than severity alone. A high-severity issue in a non-exposed internal tool may be less urgent than a medium-severity issue in a public API. Consider whether the vulnerable component is reachable, whether the service is internet-facing, whether authentication is required, and whether the package is actually used at runtime.

Useful triage questions include:

• Is the affected component in the deployed path?
• Can an attacker reach it remotely?
• Is there a known exploit in the wild?
• Is there a compensating control such as network restriction or feature disablement?

This is where SBOMs become operationally useful. They help you move from generic vulnerability lists to targeted remediation.

Sharing SBOMs with customers and third parties

Some customers may ask for SBOMs as part of supplier assurance. If you share them, make sure you understand what is being disclosed. An SBOM can reveal package names, versions, and product structure. That is usually acceptable in a controlled supplier relationship, but it should still be handled as sensitive operational information.

A sensible approach is to provide the SBOM for the exact release in question, together with a short explanation of the format, the date generated, and any known limitations. If you are receiving SBOMs from suppliers, store them in a consistent location and link them to the relevant product or service record so they can be used during incident response.

Common pitfalls when adopting Syft and Grype

False confidence from incomplete inventories

The most common mistake is assuming that a successful scan means the software is safe. If the scan input is incomplete, the SBOM will be incomplete. If the build process hides dependencies, the inventory will miss them. If the package metadata is poor, the vulnerability match will be noisy or inaccurate.

To reduce that risk, test the workflow against a known sample application before relying on it for production releases. Compare the SBOM output with the expected dependency list and verify that the artefact type you scan is the one you actually deploy.

Over-reliance on vulnerability counts without context

A raw count of findings is not a useful security metric on its own. Ten low-severity issues in a library that is not reachable may matter less than one high-severity issue in a public service. Teams should track trends, but they should also track remediation time, exposure, and the proportion of findings that are genuinely actionable.

For UK SMEs, the goal is not perfect inventory hygiene. The goal is a repeatable, defensible process that helps engineering and security teams make better decisions. Syft and Grype can support that, provided they are embedded into the delivery process and not treated as a one-off audit exercise.

If you want to introduce SBOM generation into an existing pipeline, start with one service, one artefact type, and one output format. Prove the workflow, tune the policy, then roll it out more widely. That tends to work better than trying to standardise everything at once.

For organisations that want help aligning software supply chain controls with a broader security programme, a consultant can help define the right operating model, evidence set, and release gates for your environment.

Speak to a consultant if you want practical support with software supply chain assurance, SBOM workflow design, or secure development controls that fit a UK SME delivery team.