# Catch a compromised CI dependency

Source: https://www.testifysec.com/docs/cilock/use-cases/credential-harvester

Inspect a compromised CI dependency with CI/lock tracing and secret scanning, then evaluate the recorded evidence against a policy before release.

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](https://docs.github.com/en/actions/reference/security/secure-use#using-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.

 

A Claude Code session running a compromised CI dependency under CI/lock; eBPF and secretscan catch the credential theft and the policy blocks the release

[Download terminal recording (.cast)](https://www.testifysec.com/media/docs/recordings/ci-credential-harvester.cast)

 

## 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](https://www.testifysec.com/docs/cilock/concepts/capture-modes) (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`](https://www.testifysec.com/docs/cilock/attestors/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`](https://www.testifysec.com/docs/cilock/attestors/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](https://www.testifysec.com/docs/cilock/concepts/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`](https://www.testifysec.com/docs/cilock/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`](https://www.testifysec.com/docs/cilock/attestors/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](https://www.testifysec.com/docs/cilock/use-cases/litellm-supply-chain): [Trivy](https://www.testifysec.com/docs/cilock/tools/trivy), [Grype](https://www.testifysec.com/docs/cilock/tools/grype), [Syft](https://www.testifysec.com/docs/cilock/tools/syft) SBOMs, [Semgrep](https://www.testifysec.com/docs/cilock/tools/semgrep).
 - Restrict which actions may run at all with a signed Rego policy over the [`github-action`](https://www.testifysec.com/docs/cilock/attestors/github-action) / [`gitlab`](https://www.testifysec.com/docs/cilock/attestors/gitlab) attestations — defense in depth alongside this behavioral check.

 

Pin the commit, then inspect the work

A full commit-SHA pin prevents a moved tag from selecting a different commit. It does not prove that the pinned code is benign or that everything it downloads is pinned. Review the action and its dependencies, restrict its permissions, and evaluate the evidence your configured capture mode can observe.

Reference generated from the product documentation. Match commands and support details to your installed release.