The continuous integration/continuous delivery (CI/CD) pipeline has become the backbone of the software development process, so it's critical to ensure developers meet and exceed the most critical security measures. Rather than discovering vulnerabilities post-production, when exploitation and damage to business operations may have already occurred, CI/CD security addresses vulnerabilities early on.
By identifying and mitigating risks early in the software development lifecycle, organizations can move from a reactive state of cybersecurity to proactive. While it’s challenging given how fast-moving and ever-changing cybercriminal tactics are, we’ve developed a checklist of four steps and a handful of tools and tactics security leaders can use to bake risk-based vulnerability management into their CI/CD pipelines:
Step 1: Create a healthy environment.
Organizations and their software development teams should think about security at the very beginning of the software development process when teams are still in the planning phase. When mapping out a product roadmap, there are specific tasks the team can implement, such as threat modeling and supply-chain levels for software artifacts (SLSAs). Threat modeling shines the spotlight on potential areas of attack and introduces countermeasures needed to mitigate them. By taking on the perspective of the adversary, teams can continuously evaluate the environment and strengthen their defenses against real-world simulations.
SLSA frameworks are particularly useful during the planning phase. Acting as a common language to determine the security of a CI/CD pipeline, it consists of a list of controls, standards, and best practices to steer clear of supply-chain attacks and prevent exploitation.
Step 2: Ensure healthy code.
Development teams can’t secure what they can’t see. Visibility into the entire CI/CD pipeline requires understanding all of the code that makes it up and how they relate and interact with each other. It also necessitates keeping a close eye on all possible entry points. Software teams can achieve this by performing Software Composition Analysis (SCA) and using a software bill of materials (SBOM), which can play an integral part in tracking all open-source and third-party components in the codebase. Development teams should also add static application security testing (SAST). The SAST tests encompass a set of tools used to examine application source code, assembly code, bytecode, and binary files for possible security flaws. Developers can leverage them early on in the cycle to detect issues before becoming a part of the code base, or closer to the end of the cycle to ensure a secure code base. Of course, deploying these tools in no way completely relieves the responsibility of manual code reviews by security professionals, as no one tool is perfect.
Developers should also consider a code-signing service. During this phase of the software development lifecycle (SDLC), these tools verify the authenticity of the code by stamping it with a digital signature before it heads to a production environment. This ensures that developers can trust the code and it has not been manipulated.
Step 3: Test the code.
At this point, continually test the software, especially if new features are added. Developers can use dynamic application security testing (DAST) to analyze a build from the outside-in through simulated attacks. Unlike SAST tools, which can only detect flaws in a static environment, DAST tools can detect runtime flaws in a dynamic, actively changing environment. During this testing phase, employ container scanning tools, as the use of containers for application development has become widely accepted and a growing trend in cloud computing.
Going beyond the code, it’s critical to perform security acceptance testing, which makes sure the security controls in place are strong enough to protect the entire system. This includes checking for vulnerabilities in dependencies, testing for insecure configuration settings, and verifying that authentication and authorization controls work properly. Done either through automated tools or manually, but preferably both, consider security acceptance testing as essential to a continuously healthy system throughout the entire CI/CD pipeline.
Step 4: Practice continuous monitoring.
The team’s environment, code, and testing strategy are now up and running, and now it’s time to take preventive measures to keep the CI/CD pipeline as secure as it started. This box should always remain unchecked because it’s a task that’s never fully complete. For real success, security must embrace the continuous aspect of continuous monitoring. Here’s where identity and access management (IAM) becomes important. IAM focuses on a few simple, but important questions: Who has access to what? When do they have access to it? And what level of permissions does each identity within the organization have? Developers often disregard IAM to make room for other reactive security measures and tools, but tightening access controls and separating duties has become the lifeblood of a continuously secure environment. Make sure the team has an IAM strategy in place at all times to manage the mounds of data the organization holds.
Properly securing a CI/CD pipeline takes many moving parts, and teams must prioritize the risks that are most detrimental based on their organization’s unique blueprint. This risk-based approach to security keeps security teams focused as they manage risk throughout every stage of the SDLC. This toolbox of tactics will ensure the team can defend against the barrage of attacks against the CI/CD pipeline and will lead the company’s cyber risk management program in the right direction.
Tal Morgenstern, co-founder, chief strategy officer, Vulcan Cyber
