Skip to content
OPS // KITitspentest.sh

E-SYF

syft

Generates a Software Bill of Materials (SBOM) from container images and filesystems.

Official siteBack to catalog

OVERVIEW

Syft (github.com/anchore/syft), from Anchore, scans a container image, filesystem, or archive and catalogs every package it finds — OS packages, language-specific dependencies (npm, pip, gems, Go modules, JARs, and more) — into a Software Bill of Materials in industry-standard formats like SPDX and CycloneDX.

It's the inventory half of a two-tool pattern with Grype (the scanning half): generate the SBOM once, then feed it to Grype or another vulnerability database repeatedly without re-analyzing the image each time, which matters when scanning the same base image across many services.

USE CASES

Practical use cases

  • 01

    Cataloging every OS and language-level package inside a container image before triage.

  • 02

    Producing an SPDX/CycloneDX SBOM to hand off as a deliverable alongside the pentest report.

  • 03

    Feeding a generated SBOM into Grype (or another scanner) for repeat vulnerability checks without re-scanning the image.

  • 04

    Diffing SBOMs between two image builds to see exactly what dependencies changed.

QUICK START

Before or alongside vulnerability scanning, to get a full inventory of what packages and versions actually ship inside an image.

  1. Confirm which images or filesystems are in scope for cataloging.
  2. Install syft from a release binary, package manager, or the install script.
  3. Run syft against the target image to generate an SBOM.
  4. Export it in SPDX or CycloneDX format for the report or for feeding into Grype.
syft app:latest -o cyclonedx-json=sbom.json

BEFORE YOU RUN IT

What to check before running it

An SBOM is an inventory, not a verdict — it lists what's present, so pair it with Grype or another scanner to know what's actually vulnerable.

Package detection depends on lockfiles and metadata being intact inside the image; stripped or vendored dependencies without manifests can be under-reported.

Scanning a production image pulled directly from a client registry still counts as touching client infrastructure — confirm registry pull access is in scope.

KEEP EXPLORING

View the whole phase →