As the demand for quicker, more organized development has increased, CI/CD solutions have found their way into the very heart of most organizations’ development infrastructures.

From simple indentation checks on submitted code to publishing generated code to production servers, CI/CD solutions assist automate most of the fundamental, repetitive processes of the application development lifecycle.

The increasing sophistication and breadth of CI/CD technologies necessitate providing them with appropriate access levels so that they may fulfill their many roles. To automate the deployment process, a CD tool that pushes produced code to production servers would need the same access and/or permissions as a person.

However, because CI/CD methods have made software development so automated, it is now easy for attackers to covertly introduce malicious code into the build process without anybody noticing. Cryptocurrency miners’ code has been sneaked into software releases without detection by attackers.

That’s why it’s so dangerous to use CI/CD technologies that aren’t secure or aren’t properly configured; doing so greatly expands your company’s attack surface.

CI/CD Security Incidents Recently

Misconfigurations and using outdated versions of CI/CD technologies are common causes of security holes. Scanning for servers running these out-of-date versions is easy for a “robot” (like those found trying SSH logins all over the internet) to conduct, whether by capturing banners or brute-forcing a vulnerability PoC on a publicly available CI/CD tool.

As a result of a recently discovered GitLab flaw, servers with outdated GitLab installations were exploited to launch DoS assaults, which, compounded by the total number of servers using the vulnerable version, resulted in internet DDoS attacks reaching 1 terabit per second.

GitLab has experienced authorization-related flaws that have allowed unauthorized users to enter your instance, allowing them to do everything from sending out internet attacks (illegal in most countries) to accessing sensitive data. Additionally, ACL-related vulnerabilities might allow hacked, yet permitted, users to push and retrieve data from restricted parts of your GitLab instance.

Even if these flaws have been addressed in subsequent versions of GitLab, it is still vital to monitor the release of these updates and, in turn, to upgrade your instances (typically on your own) to minimize your exposure to attack.

Similarly, other CVEs, including cross-site scripting (XSS) and cross-reference (CSRF) flaws and permission bypass flaws, have been discovered in the widely used open-source CI/CD application Jenkins.

In light of the preceding, it could appear that the natural choice would be to use hosted or SaaS CI/CD solutions instead of self-hosted technologies; nevertheless, hosted CI/CD products might present security concerns. Due to the nature of Git, erasing the.travis.yml file from within Git wasn’t adequate to prevent the injection of environment variables via pull requests, which exposed sensitive information about the project.

Similarly, if your deployment process uses Git and clones the repository onto a production instance, then any user visiting your in-production web app would be able to download or see the.travis.yml file holding your application/build secrets, even if your Git repository was private and secrets weren’t leaked out via the repository itself.