Skip to main content
SmoothGlue Logo

SBOM — what it is, why DoD requires it, how SmoothGlue generates it

ExplanationPublic

The problem this solves​

DoD Executive Order 14028 and NIST guidance require a Software Bill of Materials for any software in federal systems. Without automated SBOM generation, producing one is a manual, error-prone, and expensive process — and it's out of date the moment the software changes.

How SBOM works in SmoothGlue​

Every container image built through the Pillars of Creation pipeline automatically:

  1. Runs Syft to generate a CycloneDX-format SBOM listing every package, library, and dependency
  2. Attaches the SBOM to the image as an OCI artifact — stored alongside the image in Nexus
  3. Runs Grype to cross-reference the SBOM against known CVEs and fail the pipeline on critical findings

The SBOM is available for any image via the Console. No developer action required.

What the SBOM contains​

Each SBOM lists:

  • Every OS package in the base image (name, version, license)
  • Every application library and its version
  • The build environment (Go version, Node version, etc.)
  • The image's SHA-256 digest — proving the SBOM matches the artifact

What SmoothGlue handles for you​

  • SBOM generation — automatic in the Pillars of Creation pipeline
  • SBOM storage — attached to the image as an OCI artifact, no separate database
  • Vulnerability scanning — Grype cross-references the SBOM at build time
  • Pipeline gating — builds with critical CVEs fail before the image is published

What you still own​

  • Reviewing SBOM findings and making risk acceptance decisions
  • Including the SBOM in your ATO package
  • Tracking CVEs discovered post-build (SmoothGlue scans at build time, not continuously post-deploy)

Learn more​