We're on a wild ride. AI will find every vulnerability there is in code, and then more. It's a waterfall. You can't sip. You have to consume the whole thing or be vulnerable. Let that sink in for a second before you read on.

Unstoppable

A serious Linux Distribution project attempts to protect their users from flawed software. It does this by using strategies and tools to make software more secure, send updates with fixes out faster, and by assessing the risk of software vulnerabilities, properly.

But here's the thing: You can't do this last part by just casually reading slashdot.org every day. Or LinkedIn. There is no way you can even pretend that you're serious about the risks of deployed Software unless you have a solid machine in place that mechanizes handling all the security disclosures in a way which doesn't drop a single one of them by accident.

And the current pace of LLM's being capable of finding existing software flaws that really, really smart people didn't spot for sometimes over 10+ years is nothing short of overwhelming, for any person. For any tool that is, this might be doable. The flow will not stop. So the machine must never stop either.

The Goals:

After the fact is the same as never

Here's the rub: You can't just ship software, and then scan for CVE's and discover existing vulnerabilities. This already puts the bad software in the hands of your users. We don't ever want this. Insecure software that has known gaping holes should never be published to begin with.

• This is promise #1

You can't accept new software until at least it is known where vulnerabilities for the software can be found. This can usually be tested by looking at older releases for the new software - those should instantly match, so they can be assessed before allowing the package into the public repos.

Scanning happens always, because disclosures do

Software doesn't just get used one time, and then deleted. Probably billions of computers are right now using software that was written more than 20 years ago. If you think I'm overestimating things, try and run a git blame on some Linux kernel code. And that code runs on every Android phone and Linux server, today.

• This is promise #2

It is unacceptable to stop scanning for new disclosures. Scanning must re-scan every existing software component. Every new vulnerability disclosed must be reconciled against the software in the repositories. If the build system doesn't permit this, it can't take action, and it can't inform users of the additional risk, let alone hunt for a fix, mitigation, or information.

An uninformed user is an insecure user

A user that has no way to assess their own risk can't make informed decisions about securing themselves. They are left powerless - unable to deal with the flow of disclosures and no idea whether the software they have deployed is a risk to them.

• This is promise #3

Users must have full visibility into their security risk. At all times users must be able to inspect which disclosures are affecting their deployed software components. To put it simply: This must be as simple as running a simple command on the installed system, immediately showing them every single affected component and what the security risk there is.

Here's where we are with this:

First, I admitted at launch as much that the system I had in place wasn't doing it right at all. So much of the last 2 weeks has been occupied by work to shore up the disclosure handling code and bring everything up to standard.

Starting at promise #1 - designer now will refuse to allow any new change to be merged without it having an identity. The identity is what makes CVE's and disclosures discoverable. Without identity, you can't discover new vulnerabilities. With identities locked down, you can. Before we did not enforce this. As of today, this is fully enforced. I have just forced myself to assign 2000 identities to 2000 packages, as a result. Worth it? Absolutely. A minor pain, sure. We'll get through it, though.

At promise #2 we were doing misguided work. Scanning happened, but often affected the wrong things, and the right disclosures didn't get tied to the right items. Today we're in much better shape. As I'm assigning identities I'm seeing exposures becoming published for older versions of packages, which is exactly the confirmation that this is working correctly. That is major progress. Once we backfill all the identities, we can start on the next item:

For promise #3: This is ongoing work. It will require likely a repo format change to capture and publish vulnerabilities in such a way that pkg can emit these in both machine parseable and human readable code. It also should tell users whether updates for vulnerabilities are available, because nothing is worse than leaving a user searching for answers that are right there and available to them.

The future

I'm plowing through items #1 and #2 here swiftly and will spend the next weeks exercising the strict enforcement of the rules to map out and assign existing vulnerabilities. That work can then expand into the #3 item to keep you informed. Once that functions, the machine will keep on cranking and protecting users.

--sofar (aka Auke)