images VS vulnerabilities

I'm very sorry that we broke things for you.

To be clear, nothing has changed with Wolfi. Wolfi is an open source community project and everything is still available there: https://github.com/wolfi-dev/.

We have made changes to Chainguard Images - our commercial product built on top of Wolfi - which mean you can no longer pull images by tag (other than latest). Chainguard images are rebuilt everyday and have a not inconsiderable maintenance cost.

The easiest way to avoid this is to build the images yourself. You can rebuild identical images to ours using apko and the source files in the images repo e.g: https://github.com/chainguard-images/images/blob/main/images... (note you can replace package names with versioned versions). You can also just use a Dockerfile with the wolfi-base image to "apk add" packages. Full details are here: https://www.chainguard.dev/unchained/a-guide-on-how-to-use-c...

I agree that pinning is a best practice. The above blog explains that you can still do it using a digest, but I accept this isn't the simplest solution.

If I can help any more, please feel free to get in touch - you can find me most places including twitter https://twitter.com/adrianmouat

We needed Wolfi to be able to create minimal (distroless if you like) container images based on glibc with 0 vulnerabilities. Turns out a lot of other people are interested in Wolfi for various reasons, and we're more than happy to work with them.

You definitely don't need to use Wolfi! But I would say, if you run containers you might want to check out Chainguard Images: https://github.com/chainguard-images/images

In this article, we'll see how to leverage Wolfi to create safer PHP application environments based on containers. To demonstrate Wolfi usage in a Dockerfile workflow (using a Dockerfile to build your image), we'll create an image based on the wolfi-base image maintained by Chainguard. The goal is to have a final runtime image able to execute a PHP command-line script. By definition, this image won't be completely distroless, because it will require APK to be present in order to install system dependencies described in the Dockerfile. For building pure distroless images, you should have a look at apko.

Do you provide an OVAL feed?

Alpine is out of the picture for us because the guy that works on their security tracker just doesn't care, and responds half a year after filing an issue. The tracker itself is broken for over a year and the response was to basically rebuild our own package index and host our own security tracker.

So I would not say that Alpine has security as a high priority, even though in theory there are the secfixesdb.

Redhat Enterprise, Debian and Ubuntu are used because they provide an OVAL feed that are easily integrated with zero development overhead. So if compliance is your focus, I'd heavily recommend generating an OVAL feed when you're regenerating the secfixes json files.

Source: Am building a cross-linux-distro vulnerability database and I am scraping _all_ linux security trackers. [1]

[1] https://github.com/tholian-network/vulnerabilities

I was trying to find the security tracker or advisories page for VoidLinux, as I'm building a cross-distro vulnerabilities database; where I want to match the confidence via reliable disclosures and unreliable advisories.