![](\"https:\/\/www.trendmicro.com\/content\/dam\/trendmicro\/global\/en\/devops\/thumbnails\/23\/protect-ci-cd-pipeline.jpg\")
<\/p>\n<\/p>\n
<\/div>\nLast fall, the Open Worldwide Application Security Project (OWASP) announced a new project<\/a> focused on the top 10 security risks for CI\/CD pipelines. (CI\/CD stands for continuous integration and continuous delivery\/deployment, a sort of \u2018perpetual motion\u2019 approach to software development.)<\/p>\n The top 10 reflects how widespread CI\/CD have become\u2014and how vulnerable its pipelines can be due to technology stack complexity, increased use of automation and infrastructure as code, and more third-party integration. It also highlights another case of traditional cybersecurity practitioners taking on expanded responsibilities as security operations and cloud security continue to converge<\/a>.<\/p>\n Least privilege, Zero Trust<\/span><\/p>\n Based on our assessment, OWASP\u2019s Top 10 CI\/CD Security Risks<\/a> fall into three general categories: access and credential risks; integration and dependency risks; and configuration risks. If there\u2019s a recurring message, it\u2019s that organizations should adopt least-privilege principles wherever possible and embrace the spirit of the Zero Trust approach<\/a>.<\/p>\n Access and credential risks in the CI\/CD pipeline<\/span><\/p>\n Inadequate Identity and Access Management<\/b><\/p>\n The open, continuous nature of CI\/CD adds up to more people and machines participating in the development ecosystem across its phases and stages. Even one compromised identity has the potential to cause fairly serious damage.<\/p>\n According to OWASP, identities can suffer from any number of weaknesses\u2014from too-broad permissions to lapsing out of date. It recommends continuous mapping of all internal and external identities, removing unnecessary permissions, and not granting blanket permissions to all users or large groups. Stale accounts should have a defined shelf life. Local accounts (ones that aren\u2019t managed centrally) should be prohibited, along with the use of personal or non-enterprise email addresses, self-registration, and shared accounts.<\/p>\n Insufficient credential hygiene<\/b><\/p>\n Bad actors prize credentials for the access they give to high-value resources and the opportunities they afford to deploy malicious code and artifacts. They can be exposed any number of ways in the CI\/CD pipeline.<\/p>\n If pushed to a software change management (SCM) repository branch, credentials can be read by anyone with access to the repository. They can be left out in the open when used insecurely in build and deployment processes or image layers and may also be printed to console outputs.<\/p>\n OWASP\u2019s recommendations are to rotate credentials regularly, apply the principle of least privilege always, use temporary credentials instead of static ones, and remove any secrets or credentials from artifacts once they are no longer needed.<\/p>\n Insufficient pipeline-based access controls (PBAC)<\/b><\/p>\n CI\/CD execution nodes access both internal and external systems and resources. Bad actors can use that access to disseminate malicious code, exploiting all the permissions associated with the pipeline stage the code is running in.<\/p>\n To remedy this, OWASP says nodes with different levels of sensitivity or resource requirements should not be shared by multiple pipelines. It also advises a form of least privilege to ensure every pipeline step can access only the secrets it needs, and no others. Once the pipeline is executed, the node should be restored to its \u201cpristine state\u201d, and every node should have fully up-to-date security patches.<\/p>\n Integration and dependency risks in the CI\/CD pipeline<\/span><\/p>\n Dependency chain abuse<\/b><\/p>\n Code in the CI\/CD pipeline may depend on other code to function, and those dependencies can be used to import malicious packages into the development process.<\/p>\n OWASP has identified four common dependency chain attacks: dependency confusion (naming malicious packages the same as legitimate packages); dependency hijacking (replacing legitimate packages with malicious ones); \u2018typosquatting\u2019 (naming malicious packages variations of common misspellings of popular legitimate packages); and \u2018brandjacking\u2019 (camouflaging malicious packages as trusted brands).<\/p>\n OWASP says package-fetching from the internet or untrusted sources should be prohibited, and all private packages should be verified as being within the organization\u2019s scope. Any installation scripts should run without access to secrets or sensitive resources, and the names of internal projects should never be published to public repositories.<\/p>\n Poisoned pipeline execution<\/b><\/p>\n The whole CI\/CD pipeline can also be \u2018poisoned\u2019 with malicious code if an attacker gains access to source control systems. Pipelines using unreviewed code are especially susceptible.<\/p>\n Organizations should restrict pipelines that run unreviewed code to isolated nodes, and all CI configuration files should be reviewed before the pipeline runs. OWASP recommends limiting the pipelines that can be triggered on public repositories and protecting sensitive pipelines with branch-protection rules in the SCM. And if users don\u2019t need certain permissions in the SCM repository, they shouldn\u2019t have them.<\/p>\n Ungoverned usage of third-party services<\/b><\/p>\n Third-party access to an organization\u2019s internal resources is built into the CI\/CD model, and a compromised third party can be used to penetrate the entire ecosystem. To illustrate the point, OWASP gives the example of a third party with write permissions being exploited to push code to a repository that then triggers a build and infects the build system.<\/p>\n Recommended remedies include:<\/p>\n Improper artifact integrity validation<\/b><\/p>\n Artifacts in the CI\/CD pipeline are pieces of code or data used in the build process that get saved or remain accessible to the system. If they aren\u2019t validated, they can be used to push malicious code or artifacts into the pipeline.<\/p>\n Here again, OWASP has a few recommendations: validate the integrity of all resources from development to production; incorporate secure code-signing technology; deploy artifact verification software; and monitor for \u2018configuration drift\u2019 in CI\/CD assets. These apply equally to internal and external\/third-party artifacts.<\/p>\n Configuration risks in the CI\/CD pipeline<\/span><\/p>\n Insufficient flow control mechanisms<\/b><\/p>\n Many of the risks summarized so far are exacerbated by the fact that once an attacker has access to some part of the CI\/CD process, they have virtually free rein to push malicious code wherever they want due to a lack of flow control mechanisms.<\/p>\n OWASP\u2019s recommendation is to ensure that no person, machine, or program can \u201cship sensitive code and artifacts through the pipeline without external verification or validation\u201d by:<\/p>\n Insecure system configuration<\/b><\/p>\n Sub-optimal configurations can be a significant source of risk in CI\/CD pipelines. Attackers can take advantage of self-managed assets that are out of date, unpatched, or have admin privileges installed in the operating system. They can also exploit systems with excessive access permissions, inadequate credential hygiene, or insecure configurations related to authorization, logging, and other functions.<\/p>\n Organizations should address configuration vulnerabilities by keeping a complete, current inventory of systems and versions, and checking regularly for known vulnerabilities. OWASP also recommends least-privilege access and permissions along with periodic configuration reviews.<\/p>\n Insufficient logging and visibility<\/b><\/p>\n As OWASP puts it: \u201cThe existence of strong logging and visibility capabilities is essential for an organization\u2019s ability to prepare for, detect and investigate a security related incident.\u201d IT cybersecurity tends to do a good job of this, but engineering systems and processes don\u2019t have the same protections.<\/p>\n This can be addressed by maintaining a current map of the environment, setting up appropriate human and programmatic log sources, aggregating and correlating logs from different systems for intelligence-gathering, and using alerts to flag anomalies and potential malicious activity.<\/p>\n These kinds of actions can be taken with extended detection and response (XDR) capabilities, centralizing logs and telemetry across cloud security and AppSec tools. Break down cloud security siloes and leverage information from those tools as part of a broader XDR approach to hunt, investigate, and respond to theats in a single platform.<\/p>\n Protect your CI\/CD pipeline<\/span><\/p>\n OWASP\u2019s top 10 lists are invaluable resources for cybersecurity teams, especially those coming from the traditional security operations center (SOC) world and are now finding themselves on the hook for application security, DevOps protection, and cloud defenses.<\/p>\n The CI\/CD pipeline top 10 is a welcome addition to the set, reinforcing unequivocally that strong checks and balances, tightly restricted permissions, and an overall Zero Trust mindset are crucial to keeping enterprise assets and data safe while capitalizing on the open and iterative nature of the CI\/CD model.<\/p>\n These measures align with Trend Micro\u2019s position that a Zero Trust approach is critical in distributed development environments. Organizations need Zero Trust Secure Access<\/a> and continuous assessments of identity and device-related risks to provide a secure foundation for fast-moving DevOps teams. Trend Vision One helps drive secure development by including identity logs and user behavior as part of investigations, scanning artifacts for vulnerabilities and malware, and more. It\u2019s all part of our commitment to help security teams take on new responsibilities in the software-created enterprise and support businesses\u2019 strategic use of the cloud.<\/p>\n\n\n
\n Access and credential risks<\/td>\n Integration and dependency risks<\/td>\n Configuration risks<\/td>\n<\/tr>\n \n Inadequate identity and access management
Insufficient credential hygiene
Insufficient pipeline-based access controls (PBAC)<\/td>\nDependency chain abuse
Poisoned pipeline execution
Ungoverned usage of third-party services
Improper artifact integrity validation<\/td>\nInsufficient flow control mechanisms
Insecure system configuration
Insufficient logging and visibility<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n
\n