Threat matrix for CI CD Pipeline
Threat matrix for CI/CD Pipeline
https://github.com/rung/threat-matrix-cicd
This is an ATT&CK-like matrix focus on CI/CD Pipeline specific risk.
MITRE ATT&CK® is a knowledge base of adversary tactics and techniques.
To map the threat of CI/CD Pipeline, I use the same classification as the framework.
(Feedback is welcome)
This threat map is published in conjunction to the presentation “Attacking and Securing CI/CD Pipeline” at CODE BLUE 2021 Opentalks.
The purpose of this matrix is to share knowledge on securing CI/CD environments with Cybersecurity community.
This matrix was created by Mercari Security Team, and reviewed by Platform Team.
threat matrix
(CI, CD) Limit egress connection via Proxy or IP Restriction
(CI, CD) Audit Logging of the activities
(CI, CD) Security Monitoring using IDS/IPS, and EDR
(CI, CD) Check each tool’s Integrity
(CI, CD) Doesn’t allow untrusted libraries, tools | | Valid Account of Git Repository (Personal Token, SSH key, Login password, Browser Cookie) | Use developer’s credentials to access to Git Repository Service \ (Personal token, SSH key, browser cookie, or login password is stolen) |
(Device) Device security is out of scope
(Git Repository) Network Restriction
(Git Repository) Limit access permission of each developer (e.g. no write permission, limited read permission)
(CI, CD) Use GitHub App and enable IP restriction | | Valid Account of CI/CD Service (Personal Token, Login password, Browser Cookie) | Use SSH key or Tokens to access to CI/CD Service Servers directly |
(CI, CD) Strict access control to CI/CD pipeline servers
(CI, CD) Hardening CI/CD pipeline servers | | Valid Admin account of Server hosting Git Repository | Use SSH key, Tokens to access to Server hosting Git Repository |
(Git Repository) Strict access control to server hosting Git Repository
(Git Repository) Hardening git repository servers |
(Git Repository) Only allow pushing of signed commits
(CI, CD) Disallow CI/CD config modification without review (CI/CD must not follow changes of a branch without review)
(CI, CD) Add signature to CI/CD config and verify it
(CI, CD) Limit egress connections via Proxy and IP restrictions
(CI, CD) Audit Logging of activities
(CI, CD) Security Monitoring using IDS/IPS, and EDR | | Inject code to IaC configuration | For example, Terraform allows code execution and file inclusion. The code is executed during CI(plan stage) Code Execution: Provider installation(put provider binary with .tf), Use External provider File inclusion: file Function |
(Git Repository) Only allow pushing of signed commits
(CI, CD) Restrict dangerous code through Policy as Code
(CI, CD) Restrict untrusted providers
(CI, CD) Limit egress connections via Proxy and IP restrictions
(CI, CD) Audit Logging of activities
(CI, CD) Security Monitoring using IDS/IPS, and EDR | | Inject code to source code | Application executes test code during CI |
(CI, CD) Restrict dangerous code through Policy as Code
(CI, CD) Limit egress connections via Proxy and IP restrictions
(CI, CD) Audit Logging of the activities
(CI, CD) Security Monitoring using IDS/IPS, and EDR | | Supply Chain Compromise on CI/CD | (Repeated) | | | Inject bad dependency | Inject bad dependency |
(CI, CD) Code checks by SCA(Software composition analysis)
(CI, CD) Restrict untrusted libraries, and tools
(CI, CD) Limit egress connections via Proxy and IP restrictions
(CI, CD) Audit Logging of activities
(CI, CD) Security Monitoring using IDS/IPS, and EDR | | SSH to CI/CD pipelines | Connect to CI/CD pipeline servers via SSH or Valid Token |
(CI, CD) Implement strict access control to CI/CD pipeline servers
(CI, CD) Disallow SSH access |
(Secret Manager) Rotate credentials regularly or issue temporary tokens only
(Production environment) Network Restriction to Cloud API
(Production environment) Enable Audit Logging
(Production environment) Security Monitoring of data access
(Production environment) Enforce principle of least privilege to issued credentials
(Production environment) Rate limiting | | Deploy modified applications or server images to production environment | Deploy modified applications or server images (e.g. container image, function, VM image) to production environment via stolen credentials |
(Secret Manager) Rotate credentials regularly or issue temporary tokens only
(Git Repository) Require multi-party approval(peer review)
(Production environment) Verify signature of artifacts
(Production environment) Network Restriction to Cloud API
(Production environment) Enable Audit Logging
(Production environment) Security Monitoring of deployment
(Production environment) Enforce principle of least privilege to issued credentials
(Production environment) Rate limiting |
(CI, CD) Clean environment created on every pipeline run | | Implant CI/CD runner images | Implant container images for CI/CD with malicious code to establish persistence |
Use signed/trusted CI runners only
Implement strict access controls to container registry
(CI, CD) Audit Logging of activities | | (Modify CI/CD Configuration) | (Repeated) | | | (Inject code to IaC configuration) | (Repeated) | | | (Inject code to source code) | (Repeated) | | | (Inject bad dependency) | (Repeated) | |
(CI, CD) Limit the scope of credentials in each step.
(CI) Always enforce Least Privilege. CI(not CD) must not have credentials for deployment
(CI, CD) Use different Identities between CI and CD
(CI, CD) Maintain strong isolation between CI and CD | | Privileged Escalation and compromise other CI/CD pipeline | Privilege Escalation from CI/CD Environment to other components |
(CI, CD) Hardening of CI/CD pipeline servers
(CI, CD) Isolate CI/CD pipeline from other systems. |
(Git Repository) Limit admin users
(Git Repository) Require multi-party approval(peer review) | | Bypass Review | Bypass Peer Review of Git Repository |
(Git Repository) Restrict repository admin from pushing to main branch without a review
(CD) Require additional approval from reviewer to kick CD | | Access to Secret Manager from CI/CD kicked by different repository | Use a CI/CD system in a different repository to leverage stolen credentials to access secret manager |
(Secret Manager) Restrict and separate access from different workloads | | Modify Caches of CI/CD | Implant bad code to caches of CI/CD pipeline |
(CI, CD) Clean environment on every pipeline run | | Implant CI/CD runner images | (Repeated) | |
(CI, CD) Don’t use environment variables for storing credentials
(Secret Manager) Use secret manager which has network restriction
(Secret Manager) Enable Audit Logging
(Secret Manager) Security Monitoring to detect malicious activity
(Secret Manager) Rotate credentials regularly or issue temporary tokens only
(CI, CD) Enable Audit Logging
(CI, CD) Security Monitoring using IDS/IPS, and EDR | | Access to Cloud Metadata | Access to Cloud Metadata to get access token of Cloud resources |
(CI, CD) Restrict metadata access from suspicious processes
(Secret Manager) Use secret manager which has network restriction
(Secret Manager) Enable Audit Logging
(Secret Manager) Security Monitoring to detect malicious activity
(Secret Manager) Rotate credentials regularly or issue temporary tokens only
(CI, CD) Enable Audit Logging
(CI, CD) Security Monitoring using IDS/IPS, and EDR | | Read credentials file | Read credentials file mounted in CI/CD pipeline |
(CI, CD) Disable or mask contents of files in results of CI/CD
(Secret Manager) Use secret manager which has network restriction
(Secret Manager) Enable Audit Logging
(Secret Manager) Security Monitoring to detect malicious activity
(Secret Manager) Rotate credentials regularly or issue temporary tokens only
(CI, CD) Enable Audit Logging
(CI, CD) Security Monitoring using IDS/IPS, and EDR | | Get credential from CI/CD Admin Console | See credential from CI/CD admin console |
(CI, CD) Doesn’t use CI/CD services that expose credentials from the system console |
(CI, CD) Isolate CI/CD pipeline systems from other services | | (Monorepo) Get credential of different folder's context | In monorepo architecture of Git Repository, there are many approvers. Need to set access controls carefully |
(Git Repository) Set approver for each folder
(CI, CD, Secret Manager) Avoid sharing CI/CD environment and credentials between different folders.
(CI, CD) should be isolated by environment folder or context | | Privileged Escalation and compromise other CI/CD pipeline (Repeated) | | |
(CI/CD) Doesn’t put data access credential in CI/CD
(Production environment) Network Restriction to Cloud API
(Production environment) Enable Audit Logging
(Production environment) Security Monitoring of data access
(Production environment) Enforce principle of least privilege to issued credentials
(Production environment) Rate limiting | | Clone Git Repositories | Exfiltrate data from Git Repositories |
(Git Repository) Network Restriction
(Git Repository) Use temporary tokens instead of long life static tokens
(Git Repository) Limit access permission of each developer (e.g. no write permission, limited read permission)
(Git Repository) Enable Audit Logging
(Git Repository) Security Monitoring of data access
(Git Repository) Rate limiting |
(CI, CD) Scalable Infrastructure |
Supply-chain attacks are one of the most serious risks. But it is not the only risk for CI/CD Pipelines. The entire attack surface need to be considered. You can check my slide: “Attacking and Securing CI/CD Pipeline” to know risks of CI/CD pipeline
Last updated