CI/CD security: threat modeling using a MITRE-style threat matrix

CI/CD pipelines represent one of the juiciest attack surfaces in modern infrastructure, yet most organizations treat pipeline security as an afterthought. The problem isn't a lack of awareness that pipelines are sensitive—everyone knows they touch production—but rather the absence of a systematic framework for identifying where the actual risks live. Borrowing from MITRE ATT&CK's approach to threat modeling gives you a structured way to map out attack vectors before someone exploits them.

The core insight is treating your CI/CD infrastructure as its own trust boundary with distinct attack stages. Start with initial access vectors. Compromised source control credentials are the obvious entry point, but consider less obvious paths: a malicious pull request that exploits a vulnerability in your linting tools, or a supply chain attack through a compromised GitHub Action or Jenkins plugin. Each of these represents a different initial access technique that requires different controls.

Once an attacker has initial access, the next stage is typically privilege escalation within the pipeline itself. This is where most pipelines fall apart. A common pattern: your CI runners execute with overly permissive IAM roles or service accounts because "the pipeline needs to deploy to production." But does every job in every branch need those permissions? Probably not. The threat model should distinguish between PR validation jobs, which should run in a heavily restricted context, and deployment jobs triggered only from protected branches with additional approval gates.

Lateral movement in CI/CD contexts often means pivoting from the pipeline to adjacent systems. If your Jenkins instance can access your Vault cluster, and your build jobs run arbitrary code, you've created a path from any repository contributor to your secrets management system. The same applies to artifact registries, Kubernetes clusters, and cloud provider APIs. Map out what each pipeline component can reach, then ask whether those connections are necessary and whether they're appropriately scoped.

Persistence mechanisms in CI/CD are particularly insidious. An attacker who gains access once wants to maintain it. This might mean injecting malicious steps into pipeline definitions stored in repositories, creating backdoored container images in your registry, or modifying Terraform state to include resources that create future access paths. Your threat model needs to account for how an attacker could modify pipeline artifacts or configurations to survive beyond their initial compromise.

The exfiltration stage is where the impact becomes tangible. Pipelines typically have access to source code, environment variables containing secrets, cloud provider credentials, and production data used in testing. Without proper controls, a malicious pipeline step can trivially exfiltrate any of these to an external endpoint. Network egress controls and secret scanning are obvious mitigations, but they're often not enforced in CI/CD contexts.

Building this threat matrix isn't just an academic exercise. For each cell in your matrix—each combination of attack stage and technique—you should identify specific detective and preventive controls. Can you detect unusual API calls from CI runners? Do you have alerts for pipeline definition changes? Are secrets injected as short-lived credentials rather than long-lived tokens? Is there audit logging that survives a compromise of the CI system itself?

The value of this approach is forcing you to think like an attacker with a specific goal rather than applying generic security controls and hoping they're sufficient. Your CI/CD pipeline is production infrastructure. Threat model it accordingly.