Proofroom
Book a callStart free trial
Start free trial
Menu
Try the demoBook a call

Software bill of materials (SBOM)

Every Proofroom release comes with an SBOM: the list of everything inside the release Docker image, and the check that none of it has a serious known vulnerability. Operators whose security team asks “what is in this and is it safe” can hand over the file below.

What it covers

  • The app image ghcr.io/proofroom-team/proofroom:<version>: the operating system packages (Debian) and the Node.js packages the app runs. This is what clients run, not the development dependencies.
  • The licence server image (licence/Dockerfile) is generated and scanned in CI on every build, but is not attached to releases, because it runs on our server only.
  • Format: CycloneDX JSON, generated by syft. Vulnerabilities are matched by grype. Both are open source (Anchore). Both are pinned by version and image digest (scripts/lib/sbom.sh).

Where to get it

In Proofroom: Admin → About → Download SBOM. Each version carries the SBOM of exactly what it runs, and About shows the scan it passed before release. Admins and auditors can download it. For a version older than 1.5.0, write to hello@proofroom.com.

The threshold

A scan fails on:

  • any CRITICAL vulnerability, and
  • any HIGH vulnerability that has a fix available.

Everything else (HIGH with no fix yet, MEDIUM, LOW) is listed in the full report and does not fail the build. A release is built, its SBOM written and scanned, and only then pushed, so an image over the threshold is not published.

The SBOM inside the image

Each image's SBOM is made by the same pinned tool as the release's own, from the finished image. A release whose image SBOM and release SBOM list different packages is not published. The scan summary in About is written at release, from that day's scan: it says what that scan found, not that nothing was found since; the newest release is scanned again every night.

Handling a finding

  • A fix exists: upgrade the package (a dependency bump, or a newer base image) and release again.
  • It does not apply to us: add an entry to .grype.yaml with the reason and a review date written above it. Every ignore needs both. Review the entries on their dates and remove them when the fix lands.