As the systems we use to deliver software to the cloud get more complex and reliant on third-party components, they also leave more opportunities for attacks. Just last year, software supply chain attacks jumped 51%, which is proof that bad (and creative) actors are capitalizing on these weaknesses.
Software supply chains are only as strong as their weakest link, and Continuous Integration/Continuous Delivery (CI/CD) pipelines are the latest attack vectors left vulnerable by unassuming DevOps teams. Just one CI/CD misconfiguration can expose sensitive information and can then be used as an entry point for injecting malicious code and leaking sensitive data. Ultimately, this can corrupt the entire CI/CD pipeline and the software supply chain.
A recent Unit 42 Cloud Threat Report found that overly permissive credentials created opportunities for lateral movement and CI/CD pipeline poisoning. Additionally, they found that 63% of infrastructure as code (IaC) templates contain misconfigurations, and 91% of container images contain high or critical security vulnerabilities.
CI/CD and the Software Supply Chain
Cloud-native software supply chains combine third-party software components like open source packages and IaC modules, plus the underlying delivery pipelines required to store, manage and deliver software. Those delivery pipelines, such as Git repositories and CI/CD pipelines, are the lifeblood of agile teams.
Deploying software multiple times a day is no longer a feat achieved solely by the likes of Netflix and Google. The only way to stay competitive in today’s market is to deliver performant, reliable and secure software quickly. And the best way to do that is with a well-oiled CI/CD pipeline.
CI/CD pipelines carry out a number of functions to compile components, provision infrastructure and trigger tests to make sure that the new code does not break existing features and that the new features are working correctly. With DevSecOps practices in place, CI/CD pipelines also allow security teams to enforce security best practices before merging into a code base and one last time before deployment. While shift-left security aims to empower developers to address security even earlier in the development lifecycle, CI/CD pipelines provide the centralized automation required to maintain infrastructure and application security best practices.
CI/CD Weaknesses and Software Supply Chain Risks
As powerful as our CI/CD pipelines are for ensuring the quality and security of our applications before they’re deployed, they require care in how they themselves are configured and what user behavior is and isn’t allowed. Oversight in this area may lead to unmitigated access to mission-critical services and infrastructure that can allow bad actors to leak sensitive data or inject malicious code or scripts.
These are some common CI/CD weaknesses to watch out for:
- Allowing the use of deprecated commands/beta features
- Secrets exfiltration with the use of unprotected command executions
- Not preventing network call commands that can be used for code injection
- Allowing tests to run in privileged pods that can be hijacked for nefarious purposes
- Using arbitrary and vulnerable images to execute build and testing, which opens them up to poisoning and attacks
Securing Pipelines With Pipelines
We know that software delivery pipelines create opportunities for poisoning and cyberattacks. At the same time, CI/CD pipelines are crucial for delivering secure software components. So why not take the same approach you take to secure application and infrastructure code in pipelines to secure the pipelines themselves?
Similar to the benefits of finding and fixing vulnerabilities and misconfigurations throughout the development process, being able to identify CI pipeline misconfigurations consistently leads to improved software supply chain security posture. Because CI pipelines are configured in code, you can leverage the same policy-as-code approach you might to identify IaC misconfigurations or open source vulnerabilities to surface CI/CD weaknesses.
Flagging suspicious coding patterns in the pipeline code as a pull request that is opened to edit that pipeline code can prevent many of the weaknesses listed above. Automation coupled with human reviews can flag to a developer when they attempt to add a deprecated command to a pipeline as they write their pipeline code or flag to a maintainer when a bad actor opens a pull request to edit pipeline code that includes a secret exfiltration command. By shifting left, security and DevOps teams can work together to proactively harden pipelines by leveraging existing tools and frameworks that make up CI/CD pipelines.
Interested in learning more best practices to secure your software supply chain? Download our Software Supply Chain Security Checklist.
This post originally appeared as a Forbes Technology Council post.