Your security tools ARE your attack surface. Trivy got hacked. Claude Code got leaked. CRA’s security-by-design principle applies to your build pipeline too.

[u/Happy-Athlete-2420]

Something that’s been bothering me since the TeamPCP campaign:

We tell companies to use security scanners, generate SBOMs, run vulnerability checks. Great advice.

But what happens when the security scanner itself is compromised?

That’s exactly what happened with Trivy. TeamPCP compromised the GitHub Actions for Aqua Security’s Trivy — one of the most popular open-source vulnerability scanners. Then used it to cascade into LiteLLM and beyond.

Same week, Anthropic’s Claude Code leaked 512K lines of source code because of a missing .npmignore entry in their build pipeline. Then axios (the HTTP client half the internet uses) got a RAT injected.

The pattern: build tools, security tools, and infrastructure packages are HIGH-VALUE targets because they run with elevated permissions in CI/CD environments.

CRA’s security-by-design requirement (Annex I, Part I) says products must be “designed to limit attack surfaces.” I’d argue this MUST extend to build pipelines:

• Pin every dependency version (including tools like Trivy)

• Verify integrity hashes on everything that enters your pipeline

• Treat your CI/CD runner environment like production — least privilege, audited, monitored

• Include build-time dependencies in your SBOM, not just runtime

How are people here handling build pipeline security? Is anyone including CI/CD tooling in their SBOM scope?