Swift Supply Chain Validation

The recent spate of cyberattacks demonstrates a need to make validating a build all the way from the most removed tools and 3rd party components through product final test something that's straightforward and secure. Before we go down the build tool road too far, I'm asking that we consider how to build security into the overall Swift supply chain / build / test / deliver architecture.

I'm specifically not trying to address the issue of protecting against attack code intentionally embedded by a developer into their product - I think doing that is in the "too hard” bucket, and in any event it’s a different bucket. If we can reach a state where we can protect our own code against attacks in tools or libraries by others, however, we'd have taken a giant step.

To that end, it's my opinion that certificates aren't enough, even after ignoring that they themselves get spoofed now and then. Without a way to recursively validate all elements back to bare metal - specifically including not only the source code and build tools, but also all related test suites and supporting test environments - we're open to attack.

A product-level identity certificate supports only an assumed level of trust that the associated product hasn't been tampered with, because the composite chain proving the state of the build's components isn't verified by the certificate, only the identity of the build’s developer is. You have to either trust that the certificate holder validated down through every leaf of the tree culminating in the build, or you have to do it yourself. Few developers are funded to do that research, which is why an automated system is so important.

By analogy, consider that although developer certificates are required in the App Store, all they establish is proof of the developer's identity, and otherwise they're content-free. Libraries loaded with malware are not scare-mongering fiction, so if a Swift "Component Store" supporting a framework marketplace uses nothing more than the same identity-based security model, it won't be able to guarantee there's been no tampering.

Instead, we need a way to know that the entire supporting tool and component chain was what the developer thought it was and intended it to be. That means every component of a build has a to be configuration controlled, and the “certificate of authenticity” has to record all the controlled elements. With that, it would be possible to screen the entire dependency tree and be certain of the provenance.

I don’t know that it has to be complicated - I think if each build can have an attached metadata file with hashes of all the component libraries, tests, test results, and build tools, plus a certificate authenticating that metadata, that’s enough to enable automated provenance checking. (I’m assuming there’s a means to avoid do-it-yourself metadata, since the idea is to not be able to spoof the metadata)

I’m more than willing for my ignorance regarding the fine points of security to be roasted; my goal is the discussion and ultimately the capability.

4 Likes
Terms of Service

Privacy Policy

Cookie Policy