Is supply chain security harder than it needs to be?
Many developers just want to ship their features. “Ok, that’s fine, but do it safely,” we say. But what does safely mean? Do the developers know what to do? If they know what to do, do they know how to do it? If they know how to do it, do they have the time to do it? What if they know how to do it, but their coding agent doesn’t?
What are we asking, is it all that much? It’s just: scan for vulns, run linters, ship an SBOM, have tests, update your dependencies frequently - but not too frequently, use SLSA, verify the package, did you remember to check that your build caching strategy is safe? Are you using trusted publishing? Did you remember to turn off the manual flows? Did you remember to remove pull_request_target?
That’s not a complete list. Even if it were a complete list today, it wouldn’t be the same list tomorrow. The attackers are always finding another way in, and the people working in supply chain security are doing amazing work coming up with great tools to defend against these evolving attacks. The problem though is that our users don’t go to the conferences. They don’t follow the blogs. They don’t know about the new tools. They don’t know about the new attack. And they don’t know how to fix it.
What if we gave developers one thing to adopt? What if that thing helped them ship the features they want, following today’s best practices, and promising updates as those best practices change? Could that provide better overall supply chain security and an easier development experience? Those are the questions I’m trying to answer with Wrangle.
Wrangle is an easy to adopt reusable GitHub workflow that uses some of the great security tools we already have available. It runs your tests, builds your package, helps you publish, and it does so while blocking pull_request_target in its builds, scanning for vulns with OSV, looking for CI/CD footguns with Zizmor, generating SBOMs with Syft, securing the build with SLSA, and verifying everything happened the way it should with Ampel. As new tools come up, they can be added to Wrangle and adopters get them with a simple Dependabot bump.
These aren’t theoretical protections either. Blocking pull_request_target would have prevented Ultralytics. Warning about tag-pinned actions might have prevented tj-actions/changed-files. Using a true SLSA Build L3 builder would shut down the cache abuse vector used in Mini Shai-Hulud. Vuln scanning flags your dependencies once the compromise is disclosed.
Of course, Wrangle won’t stop everything. It wouldn’t have caught the XZ backdoor, where an attacker spent years social-engineering a maintainer’s trust. It’s also just a proof-of-concept: the point wasn’t to ship it to users, but to find out whether a safe and easy path could be built at all. Some of the friction that’s left, like setting up and using trusted publishing, is upstream, and suggests other improvements outside the CI/CD system proper. No one’s given Wrangle a real security review yet. The only eyes on it are mine, so be careful and send feedback :)
What I wanted to know when building Wrangle was whether supply chain security has to be this hard, whether we could ask less of developers and be more secure. It seems like we can.
You can find Wrangle on GitHub. Please try it, poke holes in it, open an issue or send a PR. Above all, I'd love to hear what you think. Find me on Mastodon: @inyourbits@infosec.exchange.
