CI/CD Pipeline Security

There’s a lot of vulnerability in today’s software supply chain. Here’s how CI/CD pipeline security helps to reduce it. 

In 2024, the National Vulnerability Database (NVD) recorded almost 40,000 Common Vulnerabilities and Exposures (CVEs) – a 39% increase on 2023’s number. While all vulnerabilities aren’t created equal, and not every CVE will grow into a KEV (Known Exploited Vulnerability), it’s fair to say there’s a lot of vulnerability in today’s software supply chain. And no one knows that more than threat actors: multiple sources have noted an average time-to-exploit (TTE) of just five days in 2024 – a dramatic drop from the previous year’s 32 days. 

How do you fix it? More to the point, when there’s so much vulnerability out there, how do you prioritize the most relevant exposures? Why don’t we start by reducing the number of security vulnerabilities introduced during the software development process in the first place?

Why We Need Secure Software Development

Early software development processes were heavily skewed towards functionality, reliability, and efficiency, with little regard to security. That made sense in a world where systems operated in controlled environments, with little potential for outside attack. Everything changed when the internet and connected systems became the norm, and new security risks emerged.

By the early 2000s, security breaches were becoming more widespread and severe – security teams and developers began collaborating to develop and formalize more secure coding practices.  The rise of DevOps in the 2010s led to the concept of DevSecOps – the detection and resolution of security issues earlier in the Software Development Life Cycle (SDLC).  Fast forward to 2025, and that includes security for the Continuous Integration/Continuous Deployment (CI/CD) pipeline. 

CI/CD Pipeline Security: Why Should You Care? 

CI/CD pipelines are integral to modern software development. They automate workflows to build, test, and deploy code, making development faster and more efficient. In today’s accelerated software development environments, that’s hugely beneficial, but it also makes them more vulnerable: Increased reliance on third-party code, automated delivery systems, and distributed infrastructure has created a new, expansive attack surface – often with privileged access to critical environments. That last point has not gone unnoticed among cyberattackers. 

Among the key reasons why pipeline vulnerabilities matter more than ever: 

1. Access to sensitive data and environments: CI/CD pipelines often have privileged access to critical environments, repositories, and credentials. If breached, attackers could gain unauthorized access to sensitive data or systems.

2. Automation amplifies impact: A single exploited vulnerability could allow attackers to make code changes, insert malicious code, or manipulate processes across multiple environments. One attack could affect all stages of software delivery, from development to production.

3. The heart of the software supply chain: A malicious change introduced in a software build distributed to customers, partners, or users could have a significant impact on the wider software supply chain. 

4. Ever-expanding attack surface: As more organizations develop custom applications and accelerated delivery models, pipelines have become more central to operations, giving attackers a new attack surface to target. 

Where CI/CD Pipelines are Vulnerable

The risky combination of critical systems and expanding attack surface gives attackers a lot of scope for access and damage. Among the CI/CD pipeline vulnerabilities being actively exploited are:

• Third-party dependencies: In accelerated SDLCs, code reuse is a fact of life – 40-80% of code in new software projects comes from third parties, primarily from open-source components. These packages often introduce (and reintroduce) outdated, flawed, or unpatched code into the pipeline.

• Insecure configuration and default settings: Weak Secrets security, poor access controls and authentication, and forgotten service accounts can all present an open door to attackers. Stemming from poor development practices, research shows that secrets exposure is one of the most prevalent high-risk security findings in application security. When developers take the convenient route of embedding sensitive credentials (API keys, passwords, tokens) directly into code, this creates significant vulnerability. 

• Compromised build infrastructure and hijacked updates: The SolarWinds breach has become the poster child for how vulnerabilities in the build environment can be exploited with far-reaching consequences. Attackers can exploit vulnerabilities, misconfigurations, or stolen credentials to inject malicious code or backdoors into the build process. This is automatically deployed to the production environment, allowing attackers to ‘poison’ software such as plugins and containers —which themselves are distributed to users via updates. 

Weaponized vulnerabilities in the CI/CI pipeline pose direct security threats to software integrity, enabling sensitive data breaches, ransomware deployment, and broader supply chain attacks that compromise customer environments. 

So what can organizations do to ensure a secure CI/CD pipeline?

CI/CD Pipeline Security Best Practices 

Best practices for security in CI/CD pipelines include layered defenses with proactive, risk-based security measures. As with so much in AppSec, the best place to start is visibility – Software Bill of Materials (SBOM) and Supply-chain Levels for Software Artifacts (SLSA),  which are powerful tools to bring traceability and visibility at each stage of the pipeline:

SBOM: Like an “ingredients list” for each application in your environment, SBOMs detail all the software components in an application, including source code, libraries, packages, and modules – along with their corresponding version numbers, licenses, and any other relevant metadata. This drives visibility, identifying critical flaws, potential vulnerabilities, and other weaknesses in code. It also helps with rapid vulnerability triage when new CVEs emerge. 

SLSA: Supported by OpenSFF and Google, this framework provides progressive levels of security assurance across the SDLC, to mitigate tampering with code. It includes build documentation, provenance metadata to verify build sources, code signing, and auditability. 

Between them, SBOMs give a full list of components, while SLSA ensures the integrity of those components. Now you know what you’re working with, let’s take a look at some of the best practices to use while you’re working.

Baking Security Into Every Stage of Development

Automated security testing is essential for secure CI/CD pipelines. The most effective approach brings multiple automated scanning tools and techniques together, integrating them into your processes. Tools include:

Static Application Security Testing (SAST): Scans source code and binaries for vulnerabilities, such as cross-site scripting (XSS) and SQL injection. When integrated directly into the CI/CD pipeline, SAST enables early detection and prioritization. One of the key benefits of SAST is that it can analyze every single line of code in an application, making it truly comprehensive. On the downside, because it can deep dive into code, SAST can yield false positives and a lot of alerts, requiring human expertise to maximize the insights. 

Software Composition Analysis (SCA): SCA tools scan open-source and third-party code and dependencies for potential security issues. Because it tracks license requirements, SCA helps mitigate compliance risks related to open-source components.

SCA is important because it helps AppSec and security teams to manage and mitigate risks in the software supply chain. Its automated processes reduce the need for manual security checks, taking friction out of the software development process. 

Dynamic Application Security Testing (DAST): Dynamic Application Security Testing (DAST) – aka “outside in” security testing – takes an attacker’s approach to code, simulating attacks on applications to expose vulnerabilities. It helps to identify security gaps in code or identify unforeseen outcomes that could have a knock-on effect on application security. 

Container Scanning: When pipelines span container clusters, cloud storage, and container registries, gaps in visibility pose a risk to cloud security. As the name suggests, container security tools analyze container images such as Docker and Kubernetes for vulnerabilities, misconfigurations, and compliance risks. 

Integrating security checks at each phase of the pipeline helps prevent risk accumulation. Automation plays a crucial role in security CI/CD pipelines, but you can’t secure what you don’t monitor. That’s why continuous monitoring is a cornerstone of best practice in securing CI/CD pipelines. Let’s take a look. 

Exploitable vs. Not-Exploitable

How to Tell the Difference for Your Software Vulnerabilities.

Read more

Continuous Monitoring for CI/CD Pipelines 

Traditional security scans at fixed intervals are no longer enough to keep up with the accelerated threat levels – vulnerabilities in open-source and other third-party code are often exploited very quickly following disclosure.

Continuous monitoring involves the ongoing, automated surveillance of the software production and development environment, for real-time detection of threats, vulnerabilities, and anomalies. Done right, it ensures that every step of the SDLC is secure — from code commits to production and runtime. What does “done right” look like? We’ve just looked at one crucial aspect of it – automated scanning – but other key elements include: 

• Real-time threat detection

This includes log analysis to track pipeline activities,  such as code changes, and build logs, and flag unusual patterns or signs of unauthorized access. Intrusion Detection Systems (IDS) provide alerts on suspicious activities, such as credential misuse or attempted code injection. 

• Anomaly detection

Machine Learning (ML) is used to identify any deviations from normal pipeline behavior, while Threat Modeling predicts attack vectors.

• Compliance and policy enforcement

Automated audits using pre-configured rules help ensure compliance with regulations such as the GDPR or SOC 2. Secrets management detects hard-coded credentials in code or logs, and enforces rotation policies to maintain good security practice. 

Continuous, real-time monitoring is a fundamental part of effective CI/CD security. To bring everything together, a secure workflow could look something like this:

1. Code commit: SAST tools scan for known vulnerabilities, secrets detection blocks commits containing exposed credentials such as API keys, tokens, or passwords. Code signing ensures all code changes are verified and traceable. 

Benefit: Vulnerabilities and hardcoded secrets are caught before merge. Only signed, secure code moves to the next phase. 

2. Build phase: SCA tools scan third-party code for known vulnerabilities, policy engines enforce compliance with rules such as blocking builds with outdated libraries or critical vulnerabilities. Container images are scanned for vulnerabilities. 

Benefit: Builds carrying known vulnerabilities or policy violations are automatically prevented from reaching the deployment phase. 

3. Deployment: Machine learning-powered monitoring flags abnormal API and network traffic, triggering automated responses if threats are detected. Misconfigurations are flagged, along with any non-compliant container workloads. 

Benefit: Only secure, compliant applications are deployed in your environment. 

Continuous monitoring and testing play a crucial role in underpinning secure coding practices and overall CI/CI pipeline security. They support a feedback loop in which code is improved and secured every time it is tested. 

To really enhance your security posture, a formalized risk management approach that puts everything in context will help teams move away from a traditional,    reactive scanning approach into strategic risk management and mitigation. All of this can be integrated into your CI/CD pipeline. 

Risk Management for CI/CD Pipelines

A formalized risk management approach helps AppSec and development teams to adopt a proactive, context-based approach to security in the CI/CD pipeline. Instead of simply flagging a vulnerability, a risk-based approach will consider issues such as: 

Is this library exposed? 

Is it part of a critical service? 

Is it connected to a critical system? 

What is the likelihood of exploitation? 

This context informs and drives better security decisions, such as whether or not to block a build, escalate an issue to human expertise, or place in a queue for later remediation. 

CI/CD pipeline security best practices align closely with overall security strategies, helping to identify and resolve threats in a clear, methodical way. We’ve already seen how frameworks like SBOM and SLSA provide clear methods for ensuring transparency and policy enforcement. Let’s take a look at how CI/CD pipeline security best practices align with guidelines from the National Institute of Standards and Technology (NIST) and Cybersecurity and Infrastructure Security Agency (CISA).

NIST Secure Software Development Framework (SSDF – aka SP 800-218)

Designed to help organizations reduce software vulnerabilities – and contribute to overall supply chain security – by embedding secure practices into every phase of the SDLC. 

Some areas where NIST SSDF maps to the CI/CD pipeline include: 

• Define security requirements for software development: For example, critical CVEs block builds.
• Reuse software only from trusted resources: This could include enforcing allow lists in package managers, using signed artifacts, and validating SBOMs. 
• Perform threat modeling: Integrate automated threat modeling for APIs and microservices, and refine based on known threats in your pipeline.
• Identify and remediate vulnerabilities: Scan and test code using tools like SAST in workflows, to catch and fix flaws before deployment. 
• Analyze third-party software for security risks: Software Composition Analysis (SCA) tools and validated SBOMs help identify known vulnerabilities in dependencies. 
• Verify the integrity of software and components: Code signing and artifact signing across build and release help ensure integrity of code.
• Protect code from unauthorized access and tampering: Access controls, signed commits, and secure build environments help maintain secure code. 
• Implement a process for tracking and documenting changes: Enable audit logs and version control in the CI/CD pipeline, for greater clarity and easier identification of potential issues. 

CISA’s Secure by Design Principles complement NIST’s SSDF guidelines, including:

• Security is a core business requirement, not a feature: Calls for embedding security tools like SAST and SCA as mandatory gates in the CI/CD pipeline. 
• Eliminate entire classes of vulnerabilities: Use memory-safe languages and integrate compiler-level protections in the build phase. 
• Ensure strong authentication and access controls: Enforce Multifactor Authentication (MFA) and Rules-based Access Control (RBAC) in CI/CD platforms, requiring signed commits in the release process. 
• Prioritize security in the SDLC: Make threat modeling, vulnerability scanning, and secure code review an integral part of every code merge and deployment. 

How NIST and CISA Guidelines Support CI/CD Pipeline Security

Both NIST and CISA are often used together – NIST provides the how and what, CISA defines the why, along with organizational expectations. In both cases, the guidelines provide clear benefits for CI/CD security:

Early vulnerability detection: Detect issues in code, dependencies, and configurations before deployment. 

Build integrity assurance: Tamper prevention ensures that only verified artifacts are released. 

Reduced attack surface: When risky third-party code is blocked, secure defaults are enforced across the SDLC. 

Faster, more secure software releases: Automation allows policy checks and security testing to be integrated into the pipeline without slowing production. 

More traceability and accountability: By auditing every action across the pipeline, you build greater accountability and traceability into the SDLC. 

Continuous risk management: Creates a positive feedback loop of continuous improvement based on new insights and threat data. 

OX Security: Baking Security into your Software Pipeline

OX helps AppSec teams and developers to stop accumulating security debt, and automatically block vulnerabilities introduced into code by making security an integral part of the development process — instead of an afterthought. 

OX enables teams to automatically enforce guidelines and policies from code to cloud, and automate protective actions like blocking code merges, to ensure teams implement required changes. Our unified platform aligns security with DevOps using existing tools and workflows to automate best practices early in the process, and continuously verify code integrity throughout the pipeline. 

Get started today: Book a demo.