Hacker News Reader

Comment by dlor | Hacker News Reader

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!

View on HN

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

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

OVAL: https://oval.mitre.org/

Probably because "the guy" is not a guy, but who cares, it's easier to just be salty on HN and spread lies about the project.

> it's easier to just be salty on HN and spread lies about the project.

https://gitlab.alpinelinux.org/ariadne/secfixes-tracker/-/is...

Check response time (in months or years) and also closed issues.

What specifically was a lie in my comment?

For one, you refer to me as "a guy." I am, in fact, not a guy.

Secondly, the issue you opened was against an internal project used by the security team to do continuous CVE triage of the distribution. It is not meant to be used for public security data. We are tired of security vendors scraping our internal tool, as generating those reports in real time is very expensive on resources.

For public security data, you can use the secdb: https://secdb.alpinelinux.org/

No, it's not OVAL, but we would accept patches to generate an OVAL feed as well.

I'm sorry I did not ask you beforehand about your preferred pronouns. If you want people to use the correct pronoun and it's such a big deal for you, add it to your profiles.

Regarding the rest: don't call it a security focussed distro if you don't even care about providing the data for vulnerabilities.

If you can't see the constructive criticism I tried to provide in the issues (and pull requests) that I filed then I made a good choice avoiding your distribution ecosystem from now on.

Maybe @dang wants to chime in here to prevent more chan-level escalations.

We do provide the data for vulnerabilities, at secdb.alpinelinux.org.

The security tracker is a tool for the security team to remediate vulnerabilities.

The data provided by it is not particularly useful nor intended for consumption by people other than the security team and alpine package maintainers: it generates reports for possible CVEs to review and possibly mitigate in the package collection. The presence of data in the tracker that is not present in the secdb (either as an ACK or NAK) is just an indication that there is a vulnerability to investigate, not that anything has been confirmed or denied. Really, the data is not relevant as a product for end users to consume.

The secdb outlines what package versions fix what CVEs, and what CVEs have been formally NAKed. Speculative data from a distribution-wide vulnerability scanning tool is not useful data to be making security-related decisions with.

I’ve worked in a few industries that were crazy about compliance. Do you have any certifications for different compliances? Ie FedRamp, IL4/5/6, HIIPA, etc.

I don’t think any other container images are strictly compliant with these standards - they’re not certified, but the technology stack (ECS, EKS, etc) is certified. Either way, if you can get this certified with different compliance platforms that would be a big selling point for B2B customers.

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

Reply on news.ycombinator.com