This content originally appeared on DEV Community and was authored by Schiff Heimlich
A few weeks ago someone force-pushed 75 of 76 version tags in aquasecurity/trivy-action. Pipelines that had pinned to a tag — the thing we all tell people to do — pulled credential-stealing code on their next run. It read /proc//environ and sent secrets to a typosquat domain.
A few days later, two litellm releases on PyPI shipped a stealer in a .pth file. Python runs .pth files on startup. You did not have to import the package. If it touched the machine, the code already ran.
Both attacks had the same shape: CI ran code it had no reason to trust, with credentials it had no reason to hold, and afterward nobody could prove what actually executed.
The problem with "read the workflow file"
You can audit your CI workflow YAML. You can review the action source before you pin a version. But when the tag gets retagged after you pin, or when a dependency runs arbitrary code at import time, your workflow file does not show you what actually executed. There is no signed record.
This is the gap CI/Lock (cilock) tries to close. It wraps a CI command, traces what it actually does using ptrace (or eBPF if you prefer), and signs the evidence as an in-toto/DSSE attestation. The output is a signed document that says: here is what ran, here is what it read, here is what it produced.
cilock run -- go build -o app ./...
cilock verify ./app -p release.policy.signed -k policy.pub
The policy is signed by a human. The build agent is separate. This is the part that matters: an AI coding agent can run the build, gather the evidence, and draft a release — but it cannot sign the policy, so "the agent did it" is not provenance.
How it works in practice
- You install cilock in your CI environment
- You define a policy: what is allowed to ship, what is allowed to read
- You sign that policy with your key (or use GitHub Actions OIDC for keyless signing)
- You run your build through
cilock run -- <command> - On release, anyone can verify:
cilock verify <artifact> -p <policy> -k <pubkey>
The attestation records every file the process opens, the environment at build time, and the artifacts produced. If something later turns out to be malicious, you can compare what you think ran against what actually ran.
Why this is not just for big orgs
If you ship software — open source or internal — you are a potential supply chain target. The tooling here is not exotic. The in-toto framework has been around in the CNCF for years. CI/Lock is the practical layer that makes it usable in a normal CI pipeline without standing up a full PKI.
You do not need to trust that your CI environment is clean. You need a signed record of what happened, so you can verify rather than trust.
Source: https://news.ycombinator.com/item?id=48728596
This content originally appeared on DEV Community and was authored by Schiff Heimlich
Schiff Heimlich | Sciencx (2026-06-30T04:55:09+00:00) Your CI ran code it should not have, and you cannot prove it did not. Retrieved from https://www.scien.cx/2026/06/30/your-ci-ran-code-it-should-not-have-and-you-cannot-prove-it-did-not/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.