Get steps to prevent risky misconfigurations in your SDLC.
With the software development factory becoming more complex and automated,
there are increasing opportunities for misconfigurations to create risk.
In fact, misconfigured SDLC assets, such as SCMs, build servers, and artifact repositories, have led to some significant breaches in recent years. They're a popular target because they allow threat actors to gain access to systems and then move laterally within an organization.
Although these build assets all provide configuration mechanisms to prevent these issues, they need to be used and continually monitored for proper use. Based on our experience, that use and monitoring are not happening consistently.
Misconfigured build assets Legit frequently finds
When we first start working with an enterprise, we often discover misconfigured build servers in their environment. This is a common problem, but also one that creates significant vulnerabilities. Build systems are essentially automated, implicitly trusted pathways straight to the cloud, yet most aren't treated as critical from a security perspective. In many cases, these systems -- like Jenkins, for example -- are misconfigured or otherwise vulnerable and unpatched.
Working with one large enterprise, the Legit team found an exposed Jenkins server with access to the public Internet. The Legit research team was able to access proprietary code via the Internet through that Jenkins server.
We also often find Jenkins servers that have unnecessary access to many S3 buckets. An attacker who breaches a server with this kind of access has a treasure trove of data to pursue.
Attacks related to misconfigured build assets
These misconfigurations don't just represent a hypothetical risk either; they have led to significant real-world breaches, including:
Codecov: In the Codecov attack, attackers used an unpinned Docker image to alter the Bash Uploader script. This modification enabled them to steal sensitive data from many of Codecov's clients, highlighting the risks of not locking Docker image versions in CI/CD pipelines.
Kaseya: Attackers used an exploit to get into a build pipeline and change code in a package that was then sent to all of Kaseya's customers.
What we recommend to prevent misconfigured build assets
Below are our recommendations to prevent these risky and exploitable misconfigurations.
Branch protection: Enable branch protection and enforce code review (where the reviewer is not the committer) for all important repositories.
Continual monitoring: Keep in mind that it's important to have continual monitoring and verification of configurations. We recently partnered with a security team at a large enterprise; the team would enable branch protection, and then their development team would disable it. Obviously, developer/security communication and collaboration goes a long way here, but also continual monitoring of a constantly changing environment.
Enforce authentication: Ensure build servers require authentication. Some build servers, like Jenkins, have configuration settings that do not require authentication, which allows any user with network access to the server to perform any action.
Limit permissions: Limit the ability to create public repositories. When non-admins can create public repos, it increases the likelihood that a repo that should be private becomes public by mistake, and once public, it can be published, cached, or stored by external parties.
Similarly, ensure that cloud storage (e.g., S3 buckets) is not publicly writable and ensure it is only publicly readable when necessary. Unprotected S3 buckets are one of the major causes of data theft and intrusions.
Expire keys: Security keys are often not set to expire by default. Ensure that your infrastructure settings define security key expiration times and key rotation.
Never execute third-party resources before verification: Third-party resources should be verified by checksum or, if checksum is unavailable from the supplier, consumed from the local artifact registry after it's been downloaded and reviewed. If users of CodeCov followed this best practice, they would have caught that the checksums did not match and avoided being collateral damage from their compromised supplier.
Avoid unsafe cross workflow actions: When possible, avoid creating a job in your builds that references another image that might be changed externally. For example, avoid always pulling the "latest" image from an external source because if that image is compromised, you will automatically pull in the affected image.
Understanding common SDLC risks
As development environments become more complex, they introduce more risk, much of it unknown. Risky misconfigurations are just one of these risks.
Get our new guide on the top unknown SDLC risks we uncover to get a sense of the risks that might be lurking in your development environment, and how to address them.