Better Security in CD Begins With Security in CI
Nissan North America learned a painful lesson when the source code for its mobile apps and internally developed tools leaked online after the company misconfigured one of its Git servers. The Git server was left exposed to the internet because it used its default username and password of admin/admin, one of its engineers said.
Amid this cautionary tale, many organizations have adopted DevOps and are turning their attention to DevSecOps to ensure continuous security is added to their continuous integration (CI)/continuous delivery (CD) pipelines.
The CI/CD (continuous integration/continuous delivery) pipeline is the foundation upon which all DevOps processes are constructed. So it is imperative that securing every tool and environment comprising the pipeline becomes a priority if you practice DevOps.
What CI/CD Means
Continuous integration is a coding philosophy and set of practices development teams use to implement frequent, reliable small changes and check-in code to version control repositories.
Teams use CI with the goal of establishing a consistent and automated way to build and test applications. The idea is that by having consistency within the integration process, code changes are likely to be made more frequently, which fosters better collaboration and software quality as well as an increase in software release velocity.
Continuous delivery is the next step because it automates application delivery in short cycles quickly and on a regular basis. Besides production, most teams also work with development and testing environments, and CD provides an automated way to push code changes to them.
The Importance of Protecting the CI/CD Pipeline From Exploit
Just as Nissan North America found, the CI/CD pipeline is ripe for compromise because every connection to it provides access to a treasure trove of information–including proprietary code, databases, and credentials—which makes it an appealing target for hackers.
Yet, alarmingly, application security is not a top priority for a whopping 86% of developers, and only 29% believe writing code free of vulnerabilities should be a top priority.
Security should be a multi-stage process with the goal of identifying and mitigating security risks throughout the entire CI/CD pipeline, but it starts with CI. When security is built into the CI process, it will eliminate bottlenecks in the app production. It also means happier developers and enhanced security in CD.
Some examples of CI/CD security risks include:
- Importing insecure code into a CI/CD pipeline
- Not limiting access to source code repositories or build tools. An attacker can leverage this to inject malicious code into an application.
- A hack into a dev/test environment, giving a malicious actor the ability to disable a security test.
- Utilizing practices such as hardcoding passwords into IaC template, which could give an attacker not just access to the information but the ability to use it to execute a breach.
How to Secure Your CI/CD Pipeline
To help keep hackers at bay, you have to first identify any potential security threats and points of vulnerability within the entire build and deployment process and add protection where needed.
Patch and scan all devices connected to the pipeline on a regular basis and block devices that fail to meet security policy requirements. You also need to lock down build servers and configurations for repositories.
Use Software Composition Analysis (SCA) to scan source code to identify vulnerabilities originating from third parties or libraries such as ones imported from open source projects. Static application security testing (SAST) complements SCA by assessing custom-written code for potential vulnerabilities.
Controlling access to the CI/CD pipeline is also important. Create access control lists and rules, and log, monitor, and manage access to all components. Conducting regular audits will ensure permissions have been revoked so former employees do not have access to redundant machine or service accounts. Also, change passwords frequently.
For the best defense at preventing what happened to Nissan North America —safeguard your Git-based code repository by limiting access, even if you’re hosting it internally. Deploy two-factor authentication and define access roles for each repository to permit only developers with valid access credentials to interact with each one.
By definition, a pipeline is about keeping things constantly flowing, so the CI/CD environment should be constantly monitored. To reduce the attack surface of containers and VMs, make sure any irrelevant tools and utilities are removed. Whenever new tools or services are added, update and incorporate them into the incident response plan.
Treat the CI/CD pipeline like any other critical business operation and ensure it is adequately secured to prevent attacks or failures that will affect the build and delivery processes. If your CI/CD pipeline is insecure, that will in turn, lead to an insecure application.
There is still much more work development teams and software companies need to do before secure coding becomes part of their culture, but the fact that they are starting to take security more seriously is a good beginning.
Secure Your Environment at the Pace your Business Requires
Rezilion and GitLab CI together make it possible to support the product innovation cycle and untangle these common manual security bottlenecks, without sacrificing productivity. Learn more about how our partnership is transforming DevSecOps and start your free 30-day trial today by visiting https://www.rezilion.com/sign-up-for-30day-free-trial/.