Security in CI and CD: How to Master the OWASP Top 10 Risks

Continous Integration (CI) and Continous Deployment (CD) have become important components of software engineering in recent years. Automation enables development teams to deploy new features and updates quickly and efficiently. However, the use of CI/CD also poses some security risks that must be considered. The OWASP Top 10 CI/CD Security Risks provide an overview of the most common risks and suggests ways to overcome them.

Why is Continous Integration (CI) and Continous Deployment (CD) Needed?

CI/CD is the automation of recurring tasks and activities in software development, for example the automatic quality assurance and release of new software versions. It originated in the early 2000s, when agile methods became increasingly popular in software development. An agile environment implies frequent and high-quality releases. The goal of CI/CD is to deliver value quickly and iteratively to stakeholders, as well as improve the quality of the software.

The Six Benefits of Continous Integration (CI) and Continous Deployment (CD) are:

1. shorter development cycles
2. better software quality through automated tests and reviews
3. reduction of errors and delays through continuous integration and verification
4. shortening time-to-market through automated deployment of changesincreasing efficiency through automation and standardization of the development process
5. improving security through automated security checks in CI/CD pipelines, including checks for outdated dependencies and hard-coded credentials

Overall, CI/CD can help to make the development of software faster, more efficient and with fewer errors. However, these automated processes also provide new attack surfaces. OWASP unveiled its first official Top 10 CI/CD Security Risks in October 2022.

The Top 10 Security Risks of Continous Integration (CI) and Continous Deployment (CD)

Avoiding the OWASP Top 10 CI/CD Security Risks requires implementing appropriate security measures and practices throughout the CI/CD process. It is important to carefully monitor CI/CD processes and implement all necessary safeguards to ensure the security of systems and data.

These systems are often very complex. The OWASP Top 10 provides reference points to follow.

CICD-SEC-1: Insufficient Flow Control Mechanism

Example Scenario

An attacker gains access to an organization’s Source Code Management (SCM) system, such as Github or Gitlab, and pushes malicious code to a branch that is automatically deployed to the production environment without any additional approval or review. The code is then built and deployed automatically.

Risk

CI/CD flows enable rapid development and release of code. Often, there is complete reliance on automated processes that are granted high privileges. When software is built and deployed automatically, malicious code may be integrated and distributed.

Measures There should be thorough reviews and manual approvals for every change and customization in the environment. Code should be reviewed automatically, but new customizations should still require a manual code review. This can be defined as mandatory with most SCM services like Github

CICD-SEC-2: Inadequate Identity and Access Management

Example Scenario

An attacker uses password brute forcing to find active credentials of an old test account for which a simple password was set, but never deactivated. The attacker can use this to inject malicious code, steal data, or otherwise compromise the system.

Risk

The complexity of different identities and access methods in the system makes it difficult to manage and secure authorizations. The reason for this is that CI/CD systems require both human users and different users for automated processes on different environments.

Measures

The following points can be helpful:

• A continuous analysis and allocation of all identities
• Removal of unnecessary authorizations
• Deactivation/removal of obsolete accounts
• Avoidance of local user accounts
• Permissions with a predetermined expiration dates

In general, the least privilege principle should always apply.

CICD-SEC-3: Dependency Chain Abuse

Example Scenario

An attacker publishes a malicious package in a public repository that has the name of an internal package of an organization. When developers or build servers download the package, the malicious package is downloaded and executed instead of the internal one. This gives the attacker the ability to access the environment where the package is running.

Risk

Dependencies are often loaded from a directory. Attackers can exploit vulnerabilities in workstations and build environments to place malicious code there. As described in the scenario, code from central repositories such as NPM or PyPi, where external code is stored, can also be affected.

Measures

The recommendation for risk reduction is to use a central artifact system. The dependencies released by the company are loaded onto this system and their checksums are verified. One example is Azure Artifacts.

CICD-SEC-4: Poisoned Pipeline Execution (PPE)

Example Scenario
An attacker with access to an SCM repository can manipulate the build process by inserting malicious code into the build pipeline configuration file. The code is then executed as part of the build process and can be used to access secret information. For example, credentials to a cloud service or other systems can be stolen.s

Risk

PPE risks arise when an attacker infiltrates source control systems and injects malicious code into the build pipeline configuration. Continous Integration (CI) and Continous Deployment (CD) automatically compile and execute code without any checks.

Measures Unchecked code in pipelines should be run on isolated systems and access to sensitive environments must be limited. Pipeline triggering on public repositories should be controlled and unnecessary user permissions should be removed. CI configuration files should be checked before pipeline execution.

CICD-SEC-5: Insufficient PBAC (Pipeline-Based Access Controls)

Example Scenario
An attacker is able to run a pipeline job that has higher privileges than required. In this scenario, by penetrating the pipeline job that accesses a production database, the attacker can steal data and resources and then exploit them in other parts of the system or even in external systems.

Risk

CI/CD systems, which execute pipelines, often have access to sensitive data and systems, both inside and outside the execution environment. An attack on the pipeline-based access control (PBAC) can result in malicious code execution within the pipeline, allowing access to sensitive data and resources.

Measures

Recommended mitigation measures include using dedicated environments for sensitive pipelines, limiting access permissions to required resources, and limiting network connectivity of the execution environment.

CICD-SEC-6: Insufficient Credential Hygiene

Example Scenario

An attacker finds a public CI/CD repository. Accidentally stored API keys and access data to cloud services are discovered there. With these credentials, the attacker can now set up their own pipeline jobs in the CI/CD system to inject malicious code into the build or deployment process.

Risk

Credentials are used in different contexts, which increases the risk of insecure use. Typical vulnerabilities are, for example:

• Credentials in code and configuration files
• Access data in container images
• Insecure use of credentials in the build and deployment process
• Old, unchanged access data

Measures

Recommendations for improving security include the use of temporary rather than static credentials and the avoidance of shared credentials for different contexts. Furthermore, it is recommended to use automated scanners that look for credentials in files. Examples include git-secrets from AWS Labs and TruffleHog from Truffle Security.

CICD-SEC-7: Insecure System Configuration

Example Scenario
Attackers identify a component in the CI/CD system that uses an outdated version of a web server. A known vulnerability in this web server can be exploited to gain access to the system. Once attackers have gained access, further attacks may be possible that enable the attackers to move within the CI/CD system, access sensitive tokens or credentials, and ultimately inject malicious artifacts into production.

Risk
Risks from insecure system configurations can arise due to vulnerabilities in the security settings, configurations and safeguards of the various systems in the CI/CD pipeline ecosystem. This can often make it easy for attackers to expand their position in the environment. This can involve developer devices as well as servers.

Measures

To optimize CI/CD security, it is important to pay attention not only to the code and artifacts, but the posture and resilience of each system as well. Recommended measures to improve security include regular reviews of system configurations and updates of outdated software versions.

CICD-SEC-8: Ungoverned Usage of 3rd Party Services

Example Scenario
An insecure third-party framework is used in a system. Attackers could gain access to a CI/CD system through an unregulated use of third-party services where they hijack the framework’s directory. They could subsequently inject malicious code or malware that is then executed throughout the pipeline system.

Risk

The CI/CD attack surface includes both internal functionalities and third-party services. Risks associated with the unregulated use of third-party services are related to the fact that third-party services can easily gain access to resources in CI/CD systems. In addition, systems can be modified by third-party providers without being noticed.

Measures

It is important to implement governance controls around the use of third-party services to increase security. This can be done, for example, through signature and checksum checks.

CICD-SEC-9: Improper Artifact Integrity Validation

Example Scenario

An attacker with access to a system within the CI/CD process uploads a seemingly innocuous artifact that actually contains malicious code and replaces the correct artifact. If proper mechanisms to validate the integrity of the artifacts are not in place, the malicious code can flow through the entire process and eventually be executed in the production environment.

Risk
Insufficient validation of the integrity of artifacts in the CI/CD process can allow an attacker to inject malicious artifacts into the process. That is, an artifact created by the pipeline is replaced by an attacker.

Measures

Resource integrity checks should be performed to mitigate risk, e.g.,   and code and artifact review tools.

CICD-SEC-10: Insufficient Logging and Visibility

Example Scenario:

Attackers have exploited one of the scenarios mentioned earlier to gain access to the CI/CD systems. They may go unnoticed due to insufficient logging and visibility controls when performing malicious activities within the CI/CD system.

Risk

While an organization typically has comprehensive logs and visibility programs for workstations, servers, network devices, and key IT and business applications, these are often missing for systems and processes in engineering environments. This makes it impossible to track automated processes.

Measures

It is important that organizations have strong tracking and visibility capabilities by using logging to detect attacks and investigate security incidents. It is recommended to create alarms to detect anomalies and potentially malicious activity in multiple systems in the process.

Conclusion

Continuous Integration (CI) and Continous Deployment (CD) is an important process in the software development lifecycle that ensures changes can be pushed into production quickly and efficiently. However, there are risks such as lack of monitoring and review, insecure access permissions, and dependency issues. These occur primarily when too much trust is placed in the automated processes.

In summary, there are a few points that need special attention. It is recommended to keep the environments at the lowest possible privileges and to separate them in accordance with the principle of least privilege. It is also important to always ensure the integrity of all internal and external components. All activities in the supply chain must be logged and checked.

The OWASP Top 10 CI/CD can be used to define security vulnerabilities in the supply chain. The Penetration Testing Team helps you to find security gaps in your supply chain and to survey measures. We look forward to hearing from you:

Bibliography

• OWASP Top 10 CI/CD Security Risks, OWASP
• Was ist CI/CD? Konzepte und CI/CD Tools im Überblick, Redhat