Live data from Hacker News

Show HN: SecureBuild – Zero-CVE Images That Pay OSS Projects

securebuild.com

11–19 of 19 posts

Re: Show HN: SecureBuild – Zero-CVE Images That Pay OSS Projects

#11
post #10

The intersection of entities whose security is based around "responding to every CVE quickly" and the entities that care about supporting OSS projects has measure zero.

well... our core users are ISVs (who distribute commercial software into enterprise controlled, self-hosted environments... think big banks, governments, tech companies). They care about supporting OSS (almost 1/2 of them are open core themselves) and their customers mandate that they care about closing out CVEs quickly in the software they're consuming from them.

Re: Show HN: SecureBuild – Zero-CVE Images That Pay OSS Projects

#12
post #9
post #7

Earlier quoted context omitted.

We often deliver in way less than 6 days but sometimes the dependency tree is deep for a patch. I've seen most auditors mandate 30 days for Critical, but you clearly want to move a lot quicker than that.

> I've seen most auditors mandate 30 days for Critical, but you clearly want to move a lot quicker than that. You seem to fundamentally not understand security. A proper security program should never be driven by an auditors expectations or even used as a reasonable guideline. Don't track CVEs and SLAs in days. You need to have patches out before active exploitation in the wild begins, that is the only metric that ma…

We’d love for this to be true... most images fill up with CVEs so fast in dependencies, we’re providing minimal images (much less surface area) and have the automation to rebuild the entire dependency graph at least daily, if not multiple times per day.

Hopefully everyone will run a "proper security program" someday!

Re: Show HN: SecureBuild – Zero-CVE Images That Pay OSS Projects

#13
post #9

Earlier quoted context omitted.

> I've seen most auditors mandate 30 days for Critical, but you clearly want to move a lot quicker than that. You seem to fundamentally not understand security. A proper security program should never be driven by an auditors expectations or even used as a reasonable guideline. Don't track CVEs and SLAs in days. You need to have patches out before active exploitation in the wild begins, that is the only metric that ma…

We’d love for this to be true... most images fill up with CVEs so fast in dependencies, we’re providing minimal images (much less surface area) and have the automation to rebuild the entire dependency graph at least daily, if not multiple times per day. Hopefully everyone will run a "proper security program" someday!

It can be true for you if your correct your thinking on the problem.

CVEs are basically just bugs that are not triggered by normal operation. If you race to "fix" them all, you are going to drown (as you are discovering).

Focus on your solution for tracking actively exploited vulnerabilities and a prioritization system and you'll greatly simplify the problem while better serving your customers.

Re: Show HN: SecureBuild – Zero-CVE Images That Pay OSS Projects

#15
post #2

this looks cool - your homepage video should open with what it is though!

thanks! say more about what you mean... you're saying instead of: Secure, Sustainable Open Source Partner with SecureBuild to offer secure, vulnerability-free builds of your open source project while generating recurring software revenue, no support contracts required. we should say something different?

More about what you actually do -- I'd suggest something like "Secure, Sustainable Open Source: We partner with open source projects to monitor their upstream dependencies for security fixes, and automatically rebuild and distribute our partners' projects with those fixes. Our partners don't have to change what they do, and we share 70% of our subscription revenue with them."

Also:

> New SecureBuilds are created whenever upstream CVEs are available, with a 6-day SLA for critical vulnerabilities.

Surely this should be "New SecureBuilds are created whenever upstream fixes for CVEs are available" -- you cut new builds for the fixes, not the bugs, no?

Re: Show HN: SecureBuild – Zero-CVE Images That Pay OSS Projects

#16

Earlier quoted context omitted.

thanks! say more about what you mean... you're saying instead of: Secure, Sustainable Open Source Partner with SecureBuild to offer secure, vulnerability-free builds of your open source project while generating recurring software revenue, no support contracts required. we should say something different?

More about what you actually do -- I'd suggest something like "Secure, Sustainable Open Source: We partner with open source projects to monitor their upstream dependencies for security fixes, and automatically rebuild and distribute our partners' projects with those fixes. Our partners don't have to change what they do, and we share 70% of our subscription revenue with them." Also: > New SecureBuilds are created when…

i like it! and yes, that is correct :)

Re: Show HN: SecureBuild – Zero-CVE Images That Pay OSS Projects

#18

What's the process to add new images? I assume this is limited to CVEs in the underlying layers, and adding in the latest of the primary package. Given that how/are you testing the images after you fix the CVEs?

Adding images involves us creating a new package (APK) in our APK repo. This is done by creating a melange build config (https://github.com/chainguard-dev/melange). The melange config defines some basic tests. It's not comprehensive, but generally validates that the binary produced is functional.

When we build the OCI image, we validate it via some custom tests that we've written. We have identified the canonical image (i.e. DockerHub, GHCR, etc), and we confirm that our image has the same entrypoint, args, env that the canonical image has. Then we have some generated scenarios we run the OCI image through to make sure it functions the same as the canonical image runs.

For example, we have Postgres in the catalog today. When we rebuild, we have some tests that run with various configurations of PG_DATABASE/PG_PASSWORD, etc env vars. We run these with our image and with index.docker.io/library/postgres, and expect to see the same output with both.

Post reply on HN