dlor

I don't even know why we're spending time blaming anyone here. The only reason any of these vulnerabilities matter is because bad people do bad things with them. The night of the disclosure, I saw reports like this one and many others, and it was more than enough for what I thought any reasonable person would deem to meet the bar for early release. It turns out reasonable people can disagree on almost anything.

I'd rather we all collectively spend this time talking about how we go fix all the rest of the vulnerabilities we (and everyone else) are finding as quickly as possible and get the patches and mitigations deployed to everyone that needs them as quickly as possible over the coming months.

(I'm the guy that decided to release these early)

We've been working with the team on the coordinated disclosure, but I made the call to get these out early when exploits hit in the wild.

The vulnerability and patch are both very complex, and the maintainers did an incredible job on this one. We tested the patch extensively and it's holding up well.

We've made these images free and will keep them that way.

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".