syft VS Lean and Mean Docker containers

Syft is a popular open source CLI tool created by Anchore for generating an SBOM from container images and filesystems. It’s designed to provide a catalog of dependencies for other tools to use as a data source. It supports many popular programming languages, package managers, and container image formats.

I'm curious to hear what tools folks are using for generating software bill of materials (SBOMs) today? We're huge fans of the Syft project: https://github.com/anchore/syft

Inside of the SBOMs, we can detect a lot: https://github.com/anchore/syft#supported-ecosystems

You're right that the active/dormant detection needs to be customized per type of runtime. We cover rpm/deb, python and java with the node and others coming very soon. The compiled languages will be our main focus next. For example, Go binaries embed some dependency metadata in the binary itself.

Also related to this effort is the "in-toto" integrity chain: https://in-toto.io/in-toto/ Since we're already connecting build to run, we aim to complete the chain.

The data format is supported by cargo audit, Syft and Trivy. Reading it from your own tools is also very easy.

A Software-Bill-of-Materials (SBOM) lists all the software components included in an image. Buildpacks support SBOMs in CycloneDX, Syft and SPDX formats.

I think you can already do that using Syft.

I'll continue relying on Anitya for the feed and syft/grype to build my SBOM and track vulnerabilities.

Today corporations, open source projects, nonprofit foundations, and even governments are all trying to figure out how to improve the global software supply chain security. While these efforts are more than welcome, for the moment, there is hardly any straightforward way for organizations to improve on that front.

For example, let's see how the DevSecOps process can detect and prevent zero-day vulnerabilities like log4j. Using Syft tool, we can generate SBOM for our application code and pass this SBOM report to Grype which can detect these new vulnerabilities and report to us if there is any fix or patch available. As these steps are part of our CI/CD, we can alert our developers and security team to remediate this issue as soon as it is identified.

Slim.ai presents the data in a more user friendly way than many of the other tools in this post. On top of its open source SlimToolkit for identifying the contents of an image, Slim.ai uses Trivy for vulnerability scanning.

What about https://github.com/slimtoolkit/slim?

Anyone tried using https://github.com/docker-slim/docker-slim To minify an image?..

Distroless images are better left for people with serious need for lightweight images and good Linux knowledge because they require lot of planning with the build so that they stay light and work. If you need lighter images but docker isn't your main tool and you can't afford to take hours and hours of practicing different build strategies you can check docker-slim (https://dockersl.im/). With this tool you can easily size down the images.

Maybe this would help in that regard: https://github.com/docker-slim/docker-slim

I have heard of slim.ai, there core tool is open source https://github.com/docker-slim/docker-slim

* We have a lightweight engineering process based on trust, self-alignment and visibility.

Email me at [email protected] if you'd like to learn more.

P.S.

Take a look at DockerSlim ( https://github.com/docker-slim/docker-slim ) if you are interested in working on the open source project that powers our SaaS.

In last weeks blog I talked about what my plan was for release 2.9. My main areas of concern was finishing the migration to make use of the images stored in our Docker registry. The other area I was planning on taking on was to slim down those images in the registry by using Docker-Slim.