blog.deps.dev

Why does this matter?

Build tooling is a critical part of the software supply chain – vulnerabilities in build plugins can be as dangerous as those in application-level dependencies. By providing visibility into these plugins, deps.dev is one step closer to giving developers a more complete understanding of their project’s security posture.

What’s next?

Data is currently only served for gem versions with the default platform “ruby”. In the future, we plan to serve data for all gem versions regardless of platform.

How does knowing the base image help?

Not knowing the base image makes analyzing images for vulnerabilities difficult. While we’ve been using a simple image as an example, in practice, many images are built from multiple base images chained together. If you don’t know which of these images introduced a vulnerability, it’s difficult to remediate that vulnerability.

How does the container base image API work?

As mentioned above, an image is made up of file system layers, a manifest file and a configuration file. The manifest and config files don’t explicitly tell us the base image of an image is. However they do provide an ordered, content-addressed list of the layers. A layer is an archive of added and deleted files. They can be content-addressed by their diff ID (a hash of the decompressed archive).

How can I use this?

The easiest way to try this out is by using the new OSV-Scanner v2 release (blog) which leverages QueryContainerImages to scan containers for vulnerabilities and attribute them to layers. osv-scanner scan image Example output from the osv-scanner scan image command.