dlor

Enriching does a few things, but the main ones are adding CVSS information and CPE information.

CVSS (risk) is already well handled by other sources, but CPE (what software is affected) is kind of critical. I don't even know how they're going to focus enrichment on software the government uses without knowing what software the CVEs are in.

We're going to be launching Chainguard Libraries for Rust in a few weeks, this article perfectly calls out the issues.

crates are somewhat better designed than NPM/PyPI (the dist artifacts are source based), but still much worse than Go where there's an intermediate packaging step disconnected from the source of truth.

It's both. They got compromised by another supply chain attack on Trivy initially.

Hey!

I work at Chainguard. We don't guarantee zero active exploits, but we do have a contractual SLA we offer around CVE scan results (those aren't quite the same thing unfortunately).

We do issue an advisory feed in a few versions that scanners integrate with. The traditional format we used (which is what most scanners supported at the time) didn't have a way to include pending information so we couldn't include it there.

The basic flow was: scanner finds CVE and alerts, we issue statement showing when and where we fixed it, the scanner understands that and doesn't show it in versions after that.

so there wasn't really a spot to put "this is present", that was the scanner's job. Not all scanners work that way though, and some just rely on our feed and don't do their own homework so it's hit or miss.

We do have another feed now that uses the newer OSV format, in that feed we have all the info around when we detect it, when we patch it, etc.

All this info is available publicly and shown in our console, many of them you can see here: https://github.com/wolfi-dev/advisories

You can take this example: https://github.com/wolfi-dev/advisories/blob/main/amass.advi... and see the timestamps for when we detected CVEs, in what version, and how long it took us to patch.

Really cool to see all the hard work on Trusted Publishing and Sigstore pay off here. As a reminder, these tools were never meant to prevent attacks like this, only to make them easier to detect, harder to hide, and easier to recover from.

This is awesome to see, and the result of many years of hard work from awesome people.

There's no defeating of scanners or even static linking. It's all automation, dynamic linking and patching to make the scanners happy. We go to great lengths to make sure that the scanners actually find everything so the results are accurate.

I can confirm our business is roughly 0 percent consulting and that it's 100% selling these hardened images.

The big ones that help are SBOMs, STIGs, FIPS, and CVE reduction. The images and the paperwork we provide make it so they can be dropped in to even the most regulated environments without toil.

Most of our customers use them for FedRAMP or IL 5/6 stuff out of the box.

The program details are here: https://docs.docker.com/trusted-content/dvp-program/

Yep, that's it - the product is hardened container images!

Great question! We take hardening of our build infrastructure very seriously, and helped build many of the OSS technologies in this space like the SLSA framework and the Sigstore project.

We produce SBOMs during the build process, and cryptographically sign SLSA-formatted provenance artifacts depicting the entire build process so you can trace a built container all the way back to the sources it was built from.

We also try to make as much of our build system reproducible as possible (but we're not all the way there yet), so you can audit or rebuild the process yourself.

Good callout, if you know how to use docker and and dockerhub then it's just as easy as `docker pull chainguard/node`

I work at Chainguard, happy to answer any questions!

Have you ever been on a boat? It's not safe to assume the existence of anything, including a toilet, on them.

Yep - a new version of image spec and distribution spec (not runtime spec).

This version allows for formalized ways to store other types of content in registries (think Helm Charts, OPA policies, etc.), as well as a way to "attach" arbitrary content to registries and then retrieve it later.

Both of these are powerful and will have lots of use cases, but the primary ones at this point are focused on supply chain security - storing content like SBOMs, digital signatures and attestations.

Personally? I've done quite a bit here although there's always more. I worked at Google to fund Rust development internally and externally, helped sponsor the work that eventually led to getting Rust adopted in the Linux kernel, and now run a company that's building a new Linux distribution that prioritizes shipping code written in memory safe languages.

https://security.googleblog.com/2021/02/mitigating-memory-sa...

https://www.chainguard.dev/unchained/building-the-first-memo...

SQL injection and XSS are typically solved at a library/framework level instead of a programming language one, although type systems can help make those frameworks usable and work well.

Either way, they're effectively "solved" from a programmer's perspective if you're willing to adopt modern frameworks instead of string-concatenating HTML or SQL manually.

It's somewhat disheartening as a software developer focused on security that the top four elements are still:

* Out-of-bounds Write

* Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

* Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

* Use After Free

We're trying to fix this problem at Chainguard. We have our own Linux distro that packages modern versions of software (like minutes or hours after it's released), as well as older versions.

We're also working on FIPS 140-2 and 3, and support pretty much every compliance framework we can find.

I'm not a lawyer, but that's definitely not their only recourse here.

Lawyers are not going to look at this coordinated attempt to subvert a EULA and say "oh well, nothing we can do here".

We work with much of the Alpine community and some of the maintainers. The glibc choice instead of musl alone means that a separate toolchain and distro is required, but there are also a lot of other distinctions.

We still work with them upstream on apk and apk-tools, and would be happy to collaborate on more tooling.

The real number is probably somewhere in the middle - one yaml file can define many packages - see the gcc or clang or argocd ones for examples of that.

glibc explodes into a few dozen, for example.

We're rapidly approaching 10k packages, here's today's count:

/ # apk update fetch https://packages.wolfi.dev/os/aarch64/APKINDEX.tar.gz [https://packages.wolfi.dev/os] OK: 9494 distinct packages available

We're definitely coming at this from a different angle from Nix, but the approaches are pretty complementary. I'm a big fan of all the work they do.

musl vs. glibc is one of the big departures we make from Alpine though, we use glibc everywhere because of those issues you pointed out.

Wolfi is for running inside the container instead of on a VM or bare metal host. They're complementary - you'd run something like Clear Linux to boot up into a container host, then run this inside the containers.

Roughly yes! I think we have a few advantages - mainly that we're focused on container workloads - that simplify the problem. But otherwise, yes!

I'm betting that with enough automation we can get there :)

And the fun part there is that this image is effectively a workaround - node.js 20 is installed via curl | bash. That means CVE scanners and SCA tools can miss node itself in that image.

As silly as it sounds, try running "snyk container test --print-deps" on that image, and look around for Node.

This approach works fine, but means that you might not be able to rely on most container security scanners to let you know when there's an issue.

Thanks for the pointer! We update the JSON feed now but should be able to generate an OVAL feed too.

We're working on FIPS builds and will self-attest to the NIST SSDF stuff later this fall, but there aren't too many other requirements that directly apply to our images.

The images are very useful for other organizations working on FedRAMP or HIPAA though, even though we don't need to have those ourselves. We wrote a bit more about that here: https://www.chainguard.dev/unchained/fortify-comply-and-conq...

In this case, supply chain security mostly means compliance. Alpine and other distros already do a great job at most aspects of supply chain security, but we make package/image signatures and SBOMs very easy to get in Wolfi.

We're also more flexible on packaging extra software in Wolfi than other distros are, which has an effect on your overall supply chain security posture. We're aiming to package the entire Cloud Native landscape (to start!), so you can simply "apk add" anything you need, without having to drop back to "curl | bash" in your Dockerfile.

By making it easier for devs to get the software they need "the right way", they'll have a reduced need to work around the already existing secure distribution mechanisms built into their distros.

If you're already on Alpine and like it, that's great! If there are some packages you can't find in Alpine, or musl vs. glibc ever causes you issues, or you need SBOMs for some reason, give Wolfi a try!