The CI/CD threat matrix that maps attacks to pipeline components

A knowledge base, not a pipeline tool

It helps to be clear about what this repository is. There is no source code to run, no package to install, and no binary. The top level contains .github/, .gitignore, README.md and images/, and the work product is a single long Markdown page holding a threat matrix, a table of pipeline components, and a technique-by-technique listing of mitigations.

The classification scheme is borrowed deliberately. The author describes it as an ATT&CK-like matrix focused on CI/CD pipeline specific risk, using the same classification approach as MITRE ATT&CK, and the document carries a note asking for feedback on that mapping. The shape matters more than any individual row: a tactic taxonomy forces a reviewer to state what an attacker is trying to do before discussing what to buy or configure.

The document was published alongside a presentation titled Attacking and Securing CI/CD Pipeline at CODE BLUE 2021 Opentalks, and it credits the Mercari Security Team with creating the matrix and the Platform Team with reviewing it. The repository has no GitHub releases, and the last push was on 2026-05-31.

A note sits at the very top of the project page, dated June 2026, announcing that the author is building cicd-sensor, described as a vendor-neutral open-source runtime security sensor, like an EDR for CI/CD pipelines. It is stated to be in pre-release and under active development. So the matrix is the current deliverable and the tool is the intended successor, which is worth keeping in mind when you decide what to depend on.

Six components, and every technique is tagged to one of them

The most reusable idea in the document is its components table. It divides a CI/CD system into six parts, and then tags mitigations with the part they apply to. The components are Device, listed as a developer workstation on Mac, Windows or a cloud-based machine; the Git Repository Service, with GitHub and GitLab named; CI, with CircleCI, Cloud Build, CodeBuild and GitHub Actions as examples; CD, listing the same CI/CD services plus Spinnaker and ArgoCD; Secret Management, with AWS Secret Manager, GCP Secret Manager and HashiCorp Vault; and the production environment, covering AWS, Google Cloud and Microsoft Azure alongside container registries, Linux servers and Kubernetes.

The tag appears in the mitigation text itself, in the form of a component name in parentheses, for example (CI, CD) for pipeline-side measures and (Git Repository) for repository-side ones. That convention is what makes the document usable in a review. A mitigation list without an owner is a wish list; here each line is already routed to a team and a system.

It also makes the gaps visible. When a technique lists only (CI, CD) mitigations and nothing for the Git Repository or Secret Management, that absence is a finding in itself, and one you can raise without re-deriving the threat model. For security reviews in a growing organisation, that routing is the part most worth reusing, even if you write your own matrix.

Initial access is mostly account abuse, not exploit chains

The first tactic section, Initial Access, lists four techniques, and every one of them is about valid credentials rather than a software flaw. There is supply chain compromise on CI/CD, described as attacks against application libraries, tools and container images used in the pipeline. There is a valid account of the Git repository service, where the credential in play can be a personal token, an SSH key, a login password or a browser cookie. There is a valid account of the CI/CD service, accessed with an SSH key or token, and a valid admin account on the server hosting the Git repository.

The mitigations follow that logic. For supply chain compromise, the pipeline-side list is to limit egress connections through a proxy or IP restriction, keep audit logging of activities, run security monitoring with IDS/IPS and EDR, check each tool's integrity, and not allow untrusted libraries or tools. For the stolen git credential, the notes put device security explicitly out of scope, then add network restriction, limiting each developer's access permission such as no write permission or limited read permission, and using a GitHub App with IP restriction enabled.

The honest reading here is that the matrix treats credential theft and pipeline tampering as the primary path in, not as one path among many. Its mitigations lean on network controls, review gates, logging and monitoring. That is defensible for CI/CD, where the pipeline is trusted by definition and therefore a prize, but it is worth noticing what the tactic does not cover. There is no row here for a vulnerability in the CI server itself, for exposed artifacts, or for a compromised developer workstation beyond the note that device security is out of scope.

Execution starts at the config file and the IaC plan stage

The Execution section makes the mechanism concrete, naming the exact files an attacker would edit. The modify CI/CD configuration technique lists CircleCI config at .circleci/config.yml, CodeBuild at buildspec.yml, CloudBuild at cloudbuild.yaml and GitHub Actions at .github/workflows/*.yaml, and describes the attack as modifying the CI/CD configuration held in the Git repository.

The mitigations for that row are a mix of repository-side and pipeline-side measures: only allow pushing of signed commits, disallow CI/CD config modification without review, which the matrix spells out as the CI/CD must not follow changes of a branch without review, add a signature to CI/CD config and verify it, limit egress connections via proxy and IP restrictions, keep audit logging, and run security monitoring with IDS/IPS and EDR.

The second row is the more interesting one for infrastructure teams, because it turns infrastructure as code into a code execution surface. Inject code to IaC configuration notes that Terraform allows code execution and file inclusion, and that the code runs during the CI plan stage, with the specific vectors given as provider installation, putting a provider binary alongside the .tf files, and using an external provider, plus file inclusion through the file function. The mitigations again start from signed commits, then add restricting dangerous code through Policy as Code and restricting untrusted providers.

A third row covers injecting code into source code, described as the application executing test code during CI. The lesson across all three is the same: in a pipeline, code execution does not need a remote exploit. Editing a config file or a Terraform provider is enough, and the plan stage is where a Terraform file becomes a running binary.

The mitigation vocabulary repeats, and that is the point

Read a few of the mitigation lists and a small set of controls keeps coming back. Egress limitation through a proxy or IP restriction appears on supply chain compromise, on CI/CD configuration modification, on IaC injection and on source code injection. Audit logging of activities appears on the same rows. Security monitoring with IDS/IPS and EDR appears on the same rows too. Signed commits and Policy as Code appear wherever a repository file is the target.

A small repeated vocabulary is a sign of coherence rather than of thin content, and it has a practical consequence: the matrix is a good argument for tooling that enforces the same handful of controls everywhere, because there is no per-application nuance to implement. Egress control, review gates on config changes, signature verification and audit logging are the load-bearing parts. Everything else in a pipeline review can be argued about later.

One caveat. The list also names components the author has explicitly placed out of scope for some rows, and device security is called out as out of scope in the git credential technique. So the matrix is not a complete threat model for the whole system, and the technique list itself continues past the section that is visible here, with headings for Execution in Production, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Lateral Movement, Exfiltration and Impact, followed by a Common Question section that takes on the claim that supply chain attacks are the only risk of a CI/CD pipeline.

What you can and cannot do with a Markdown matrix

Here is the practical limitation. The repository has no releases, no published version, no licence statement and no schema for the data. The techniques and mitigations live in HTML tables in the project page, and the matrix itself is a PNG image under images/. The images are a genuine problem for automation: a table rendered as a picture cannot be diffed in a pull request, searched, or turned into a checklist.

That limits the tool to reference use. You can read it, print it, use it to structure a threat model workshop, and lift its component tagging scheme into your own document. You cannot feed it to a scanner, generate a coverage report from it, or assert in CI that every mapped technique has an assigned control. If you want that last property, you need to re-encode the matrix in a structured format yourself, which is a transcription effort rather than a configuration one. Given the layout, expect that cost.

The image-only matrix also means the two artefacts can drift. The tables in that page carry the same techniques with fuller mitigation text, while images/matrix.png carries the summary view, and a change to one does not force a change to the other.

The alternative to a bespoke pipeline threat matrix is MITRE ATT&CK itself, which the author points to as the classification source. ATT&CK is broader, machine-readable and maintained as a data set, but it has no CI/CD-specific tactics, so it will not tell you that .github/workflows/*.yaml is an execution entry point or that the Terraform plan stage runs provider binaries. The realistic use of this repository is as a CI/CD-specific layer on top of that general framework, not as a replacement for it.

Watch the cicd-sensor pre-release for the automated version

The June 2026 note changes how you should treat the repository. A matrix is static; the author's stated direction is toward cicd-sensor, a runtime security sensor for pipelines, positioned as vendor-neutral and comparable to an EDR for CI/CD. The note is explicit that the project is in pre-release and under active development, and it invites feedback.

Pre-release means exactly that. There is no version to pin in the note, no install instructions in this repository for it, and no guarantee that the sensor will model the pipeline in the same component scheme the matrix uses. The sensible sequence is to use the matrix now, because it works as a document today, and to watch the sensor project for the point where a runtime view of the same techniques becomes available.

On licensing, the repository listing states no licence, so there is nothing to rely on when you want to copy the table into an internal wiki or your own threat model. Ask the author directly before reusing the text at scale, or reproduce the structure with your own content, which is straightforward since the taxonomy follows a public framework and the mitigations are mostly generic control categories. The last push was on 2026-05-31, so the document is still being revised, and the cicd-sensor note means the content is likely to grow rather than settle.

Editorial conclusion

Adopt this matrix as a checklist for reviewing a pipeline: it forces every threat to name the component it lands on, which is a discipline most informal threat lists skip. Do not adopt it as a control, a scanner or a source of truth for your own ATT&CK mapping, because it is a single Markdown page with no releases and no stated licence. Verify first that the mitigation you plan to rely on is actually available in the tools you run, then read the cicd-sensor note at the top of the project page, since that is the author's stated next step and it is still pre-release.

Frequently asked questions

Official sources

1. Issues
2. README
3. rung/threat-matrix-cicd on GitHub