Catch a compromised CI dependency

A workflow that references an action by tag can run different code if that tag is moved. A full commit-SHA pin continues to identify the original commit; a changed tag does not defeat it. GitHub explains this distinction in its guidance on third-party actions.

In this recorded example, the developer asks Claude to inspect a build-helper before shipping. CI/lock records the helper's observed activity, and a policy checks the collected evidence. The result depends on the configured capture mode, trusted execution environment, and policy; a signature alone does not establish that the workload was safe.

What it does, step by step

1. Run the pinned step under CI/lock. cilock run --step ci-task --trace -a environment,secretscan -- ./build-helper.sh wraps the dependency. --trace turns on kernel-side capture (eBPF here, with ptrace+seccomp fallback where eBPF can't load); -a secretscan adds content scanning. The signed attestation records the activity visible to that capture mode.
2. Open the evidence. Claude pulls the captured process tree straight from the command-run attestation — and there it is: cat /proc/self/environ, cat aws-credentials, and curl http://169.254.169.254/… (the cloud-metadata endpoint), with the real connect() recorded. The secretscan attestation flags a leaked github-pat.
3. Visualize it. A terminal diagram links the dependency to the harvested files, the metadata SSRF, and the leaked token — feeding the policy decision.
4. Show the policy. The signed policy's no-leaked-secrets Rego rule blocks any step that leaks a credential.
5. Verify → blocked. cilock verify returns Verification failed — credential leak detected in CI step and exits non-zero. See policy verification.
6. Write the incident report. The evidence that mattered — the process tree, the metadata connection, the leaked secret, the rule — is captured into a markdown incident report: the durable, auditable record of exactly what happened.

This example combines kernel tracing of process and network activity with secretscan analysis of captured output. Secret scanning is a content check, not a kernel observation. A later policy denial does not undo data that a process has already sent; isolation and credential restrictions are separate controls.

Related tools and attestors

• secretscan — Gitleaks over the run output, with recursive base64/hex/URL decoding; can fail the build on detection.
• The same --trace capture records every connection (destination, port, TLS SNI) in the command-run attestation, so a Rego rule can fail a step that connects to a destination outside an allowlist — here, the cloud-metadata IP.
• Pair with provenance and scanning from the internal supply-chain use case: Trivy, Grype, Syft SBOMs, Semgrep.
• Restrict which actions may run at all with a signed Rego policy over the github-action / gitlab attestations — defense in depth alongside this behavioral check.