How we built a verifiable release cycle at Arkis

The funds lending into Arkis need to be able to verify the system they rely on, not just trust the stated results. That means confirming that the software running on-chain was built and reviewed exactly as claimed, with nothing altered along the way. To do that, Arkis built, together with Spearbit, the first fully verifiable, tamper-proof digital provenance for institutional smart contracts.

Building on SLSA

The standard practice for smart contract security is a point-in-time audit: a security firm reviews the code at a specific moment in the development lifecycle, documents what it found, and delivers a report. But the software that runs in production passes through a much longer chain before it gets there: code is written and merged, dependencies are compiled, artifacts are built and packaged, deployments are scripted. Any of those steps is a potential point of modification that an audit at review time has no mechanism to detect.

When Arkis started looking for a way to address this, we wanted a framework that treated the entire supply chain as the unit of security, not just the code at a specific point in time. That led us to SLSA, Supply-chain Levels for Software Artifacts, the open industry standard for software supply-chain integrity.

SLSA is designed to build verifiable trust between software producer and consumer, and it gave us a way to think about security at every stage of how software is produced: from the moment a developer writes code, through the build process, all the way to how the final artifact is packaged and distributed. We wanted to build a holistic view of the supply chain, rather than any single review event, and SLSA proved to be a good foundation for that.

The reason supply-chain integrity matters beyond point-in-time reviews is that code remains vulnerable at every step in the chain - changes can happen through unintentional modification, insider threat, or compromised accounts, and the risk exists from source through build to packaging and distribution.

Source: SLSA

The attestation chain

Running builds on a hosted build platform compliant with SLSA L3, Arkis greatly reduced the impact of compromised package upload. But SLSA alone does not address attestation of smart contracts: who reviewed them, and whether what was reviewed is exactly what will be deployed. To close that gap, we built attestation directly into the release pipeline and made third-party sign-off a hard requirement at every stage.

Arkis attestation is designed around independent third-party reviewers. The starting point is an immutable Docker image, an SLSA attestation is associated with it, providing strong confidence that the package was built from the Arkis official source and build process. The image is tamper-proof and contains also Smart Contract attestation. The attestation records what the bytecode is, when and where it was built, and that it was produced by our pipeline. The image is sealed at that point, and any modification to the bytecode, the scripts, or any part of the metadata immediately invalidates that signature.

The sealed image is passed to Spearbit for review. The assigned auditor pulls the image, independently compiles the same source code on their own machine, and verifies that their output matches the bytecode in the image. If it does not, the review stops. If it does, the auditor has confirmed that the code under review is exactly what will be deployed. The security review runs against that exact bytecode produced by Arkis.

When the review is complete and the auditor is satisfied, they issue a signed attestation: the second signed record in the chain. The signature is the individual auditor’s, not the firm’s: a personal commitment to that specific release. If the auditor is not satisfied, they do not sign. Without that signature, the release cannot proceed.

Spearbit must sign every release before it can reach production, otherwise infrastructure and/or governance board will not promote the release further.

Arkis & Spearbit use the Sigstore ecosystem that offers a keyless signing process. Fulcio, Sigstore’s certificate authority, issues a short-lived certificate that binds the signature to Arkis’s and Spearbit’s verified identity. Cosign signs artifacts and can be used later to verify the signature. Rekor provides a public transparency log for auditability and integrity.

The result is a deployment artifact that carries an independent chain of signatures from everyone who built and verified it. Any third party can check both against a public transparency log. That is what the digital provenance delivers: a cryptographic record that any counterparty can verify for themselves.

For how Spearbit independently verifies and attests each release from their side, see Spearbit’s technical article.