In March, two attacks landed within days of each other.

The first hit aquasecurity/trivy-action. An attacker force-pushed 75 of 76 version tags — rewrote the history under tags people had already pinned. If your pipeline referenced one of those tags, and most did, your next run pulled credential-harvesting code. It read secrets out of /proc/<pid>/environ, encrypted them, and sent them to a typosquat domain. The advice we'd all given — "pin to a tag, don't float on latest" — is exactly what got people hit.

The second was litellm. Two malicious releases on PyPI carried a stealer in a .pth file, which Python executes on interpreter startup. You didn't have to import anything. If the package was ever on the machine, the code already ran.

Two different ecosystems, one shape: CI executed code it had no reason to trust, holding credentials it had no reason to hold, and afterward nobody could produce a signed record of what actually ran. You could read the workflow file. You couldn't prove what executed.

The same gap, now with agents​

If that threat model feels abstract, look at how code gets written this week. An AI agent writes it. The agent edits the workflow. The agent opens the PR and, in plenty of shops, the agent triggers the release. The human in the loop is skimming a diff late at night, or there's no human at all — just another agent reviewing the first one.

I'm not anti-agent. We build with them every day. But "the agent did it" is not provenance, and the permissions you hand an agent are the permissions a poisoned dependency inherits. The fix isn't to slow the agent down. It's to put a gate at the end that the agent cannot open by itself.

What CI/lock actually does​

Wrap any command:

cilock run -- go build -o app ./...

CI/lock records what ran: the command, the inputs it read, the environment, the artifacts it produced. It signs that record — keyless, so there are no long-lived keys to leak — and you get your first signed attestation in about 60 seconds.

Then you gate on it:

cilock verify ./app --policy release.policy

The policy is signed by a human, with their key. It says what's allowed to ship. The agent can do everything else — run the build, gather the evidence, draft the release — but it can't sign the policy, so it can't decide what ships. That line, between "did the work" and "decided what ships," is the whole point.

It's Apache 2.0, and it speaks Witness in both directions, so it drops into what you already have instead of asking you to rip anything out. It runs where your agent already runs: Claude Code, Codex, Cursor.

Built for how we ship now​

The tooling we built to secure the supply chain assumed a human doing the setup by hand, at human speed. An agent is already three commits deep before you've finished reading the docs. CI/lock is what Witness taught me, rebuilt for that: same lineage, with the bug fixes we found auditing the upstream code. What's new is who it's for. The first-class user is your agent.

Point your agent at a goal like "get this build to SLSA Level 3" and it can take you there. CI/lock is the engine: it emits SLSA Provenance and in-toto evidence at every step, signs it, and verifies it against Rego policy you write. The evidence then flows into the TestifySec platform, which maps it onto the frameworks you answer to — FedRAMP, SOC 2, NIST 800-53. A compliance report stops being a project you dread and becomes a read of evidence you already have.

And the part people dread most is already done: you don't stand up Fulcio, a timestamp authority, or any Sigstore plumbing. The platform hosts it. In CI you don't even log in — signing uses your runner's ambient OIDC token, keyless, no secrets. cilock login only matters when you want attestations stored on the platform. No CA to operate, no keys to rotate.

If you're already running Witness​

You don't have to switch tools to get any of this. CI/lock is the in-tree continuation of Witness: anything you produced with Witness verifies under CI/lock unchanged, and CI/lock's shared-format attestations verify back under Witness. Here's what the next iteration adds.

None of this is a break from Witness. Same lineage, same envelopes, same policy model, moving forward for a world where an agent is the one wrapping the build at 2am. We contribute fixes back upstream where they apply, because a stronger Witness is good for everyone. If you're running Witness today, CI/lock drops in next to it and reads what you already have.

Try it on your next build​

Most security engineers I talk to aren't missing conviction. They're missing a first step. "Secure your supply chain" is a mandate, not an instruction, and the world of SBOMs and signing and provenance is hard to walk into.

So here's the first step: wrap one command, sign one build, read the record it leaves behind. Once you have a signed account of what ran, everything downstream — policy, gating, the audit evidence — has something real to stand on. You don't need any of it to start.

You need one signed build. Get started.

Everything after the 62 minute mark was writing what you are reading. The security work landed in about an hour, and the documentation accreted as a byproduct of doing it. The runbook was created at the 25 minute mark, while the gate it documents did not yet exist. Here is how the hour went, and why it went that fast.

Act 1: The climb​

We started by forking Hugo, a static site generator that real people ship real sites with, not a hello-world repo built to make a point. The first tier of hardening needs no account and no network trust at all. One script wraps every build stage in a CI/lock attestation. It pins the source commit, records the build, produces a CycloneDX software bill of materials, runs a vulnerability scan, and signs a policy that gates the binary. All of it offline, with a local key.

That earns SLSA Build Level 1, plus the cryptographic substance that Level 2 also asks for: real signatures over real provenance. It is honest to call it exactly that, and nothing more. A local key sitting on the same machine as the build is forgeable, which means it is not Level 2 and not Level 3, and we did not dress it up as either.

Reaching Level 3 takes no extra YAML. It is a change of where the build runs and who holds the key. Move the same steps onto an ephemeral GitHub Actions runner, give the job an OIDC token, and the signer becomes a short-lived Fulcio certificate bound to the workflow's own identity. The build steps never touch a private key, because there is no longer a private key for them to touch. That isolation, a builder you do not operate and a key the build cannot reach, is what Level 3 actually means. The certificate on our CI attestation states it in plain text: issued by the TestifySec Platform Fulcio CA, subject set to the exact workflow file at github.com/testifysec/hugo, runner environment recorded as github-hosted. None of that is a name a human typed. It is the pipeline vouching for itself.

Authenticating the build to the platform, captured live at the 21 minute mark.

Act 2: The gate​

Generating provenance is the easy 80 percent, and it is where a lot of the industry stops. An attestation nobody checks is a sticker. The question that matters is whether your pipeline will refuse to ship when the evidence is wrong, and the only way to know is to try to break it.

So we tried. We took the built binary, appended a single byte, and ran verification again. It failed, for the correct reason: the tampered digest is not a subject of any attestation signed by the trusted workflow identity. The honest binary verifies and the altered one is rejected, and the build stops there. The policy doing the enforcing is itself signed, by the offline release key, and it trusts exactly one signer for the build step: the keyless CI identity from Act 1. The operator signs the rule, the build signs the evidence, and the two are checked against each other. That separation is the whole game.

The gate, green in CI: the honest build verifies and ships.

Act 3: Why it was fast​

Here is the part that matters if you are the one paying for it. Standing up Level 3 with policy-gated releases is normally scoped as a multi-week project for a platform team, because the list of moving parts is long: a Fulcio certificate authority, a timestamp authority, an attestation store, a policy engine, and the glue holding them together. We ran none of it. The TestifySec platform brings that trust plane and you operate exactly none of it. Our side of the contract was one workflow permission, id-token: write, and four words of attestor configuration. The platform URL, the keyless signing, and the attestation storage all came from defaults.

That is the real reason the clock reads an hour and not a quarter. The undifferentiated work, the part every company would otherwise rebuild and rebuild badly, is already done and already running. You bring a build command and an identity.

There is a second multiplier, and leaving it out would be dishonest, because half this story is that the session was driven by an AI coding agent rather than typed by hand. The agent read the release manifest and declined to pipe the installer into a shell. It decoded the signing certificate to confirm the identity was what we expected. It walked into a genuine wall, a Go build that is not bit-for-bit reproducible across machines, worked out why the gate verifies the attested artifact instead of a local rebuild, and kept going. A human approved the browser login and owned the judgment calls about visibility and naming. The agent did the rest, and it wrote the runbook as it worked. A CLI built to be driven, and an agent able to drive it; neither half alone gets you to an hour.

Act 4: The payoff you did not have to ask for​

None of the evidence we just produced is disposable. It is signed, timestamped, and durable, and it maps to the compliance frameworks you will be asked about, on the day you decide you are ready to be asked. The most pressing of those today is the EU Cyber Resilience Act.

CRA is not a voluntary badge you chase to close a deal. It is law, with obligations phasing in toward 2027 and vulnerability-reporting duties landing earlier, and it gates access to the EU market with real penalties behind it. For products with digital elements it requires a machine-readable bill of materials covering at least your top-level dependencies, documented vulnerability handling, evidence that the product was built and shipped with integrity, and technical documentation that demonstrates all of it. Read that list again against what the build already emitted.

A careful line is owed here, because this is legal ground and overclaiming on it is its own kind of insecurity. The platform produces and maps the technical evidence that underpins these requirements. It does not file your conformity assessment, affix a CE mark, or run your disclosure process. Those are organizational obligations, and your counsel owns the exact dates and the scope. What the platform takes off your plate is the part engineers actually dread, which is assembling the evidence after the fact, by hand, under a deadline. You generated it as a side effect of a build you were going to run regardless.

The same evidence answers more than CRA. Point it at NIST's Secure Software Development Framework, at SOC 2, at FedRAMP, and it is the same signed attestations read through a different control mapping. You do the security engineering once. The audit artifacts are there when you need them and not a minute sooner, which is precisely how a security team prefers it.

The receipt​

That is the whole story. A real project, forked and hardened to a Level 3 release with a gate that fails closed, in about an hour, with the write-up coming out of the same session. The speed holds up because the trust plane was already running and the agent driving the CLI knew what it was doing. The compliance mapping, CRA included, is not a second project you signed up for later. It is the same evidence, waiting.

The screenshots above are from that session, timestamped from the build. Everything here verifies.