Hacker News Reader

Comment by bamboozled | Hacker News Reader

It's nice you can do that, it doesn't work for large distributed teams.

Sure it does. Do engineers not compile their code locally constantly as a part of the process of writing it? Store deterministic hashes of expected binaries with signed commits in PRs. Then untrusted CI merely needs to generate and sign -matching- hashes and now we are good as long as the engineer and CI system are not compromised at the same time.

What about testing? In my company, before any code goes to production it has to go through hundreds if not thousands of unit tests. This can't be done on a dev laptop (see XKCD #303)

Testing is a separate concern than supply chain security. Testing should also never require any secrets useful to an adversary, so third party hosted CI is low risk here.

You're talking about creating reproducible builds - which is a good idea, but in most cases you will still need to deliver that binary somewhere.

That typically requires authentication, whether you're deploying to kubernetes or copying the files somewhere using scp, etc

So either your laptop or the ci system needs some level of secrets present to put the artifact in the correct place

Engineers simply commit artifacts with Git LFS as a signed commit. Totally unprivileged build systems can append reproducible build signatures via git tags. That repo can be webhook triggered to be -pulled- by a lambda job or similar in the target environment that will the verify tags and signatures to assert if it is valid, and deploy artifacts to signature approved environments using ephemeral role credentials.

A VCS system or CI system should never have secrets or be trusted in any way. Doing this is always dramatically increases attack surface for no reason.

I run a security consulting firm and this is often one of the first things I help my clients to fix.

I think that depends entirely on the priorities and incentives driving the company.

Reply on news.ycombinator.com