Security that runs with your pipeline: our session at Startup Village

Where it all began: Web2

Software went through this already. Testing used to be a phase: a separate team, after development, before release. Then it became something that runs on every commit, with JUnit, Jenkins and GitHub Actions. Monitoring and scanning followed the same path, from a quarterly review to tools like Datadog, Snyk and OSS-Fuzz watching the running code all day. Each time, the trigger was the same. Once a system became load-bearing, security stopped being a milestone and became something that runs alongside the code.

Where on-chain code is now

Smart contracts are load-bearing. They hold the money. And yet the deep security work, the kind that finds the exploit rather than the lint warning, still happens the old way: an audit before launch, then nothing until the next one, while the code keeps changing. The attacker does not work on that calendar. Since 2023 the attacker often is not a person at all; models built for security work, and the agents on top of them, hunt for exploits around the clock.

So the question we put to the room was not whether to automate security. It was why the deepest part of it, the part that proves an exploit works, is still the one part that runs once a quarter.

What continuous looks like

Every change attacked as it lands. A finding that only counts when the exploit runs. The fix delivered where the bug is, as a pull request, so the team reviews instead of investigates. That is what we are building with Orbit, and it was good to argue the case in a room of people who ship. Thanks to Startup Village and Superteam Netherlands for hosting, and to everyone who pushed back; the best questions came from the people who had been audited the most.

If you build on Solana and want the attacker on every change, join the waitlist.