CI/CD Pipeline Security: Best Practices

Since DevOps‘ earliest days, CI/CD pipelines have emerged as a best practice for fast software development. However, when left unattended, these pipelines constitute a significant attack surface, posing a severe risk to the software supply chain. With that in mind, CI/CD pipeline security is crucial to maintaining the safety of your software.

According to Reversing Labs, 63% of the companies can’t detect tampering in the supply chain, and 40% acknowledge CI/CD pipeline exposures as a real threat. Cloudflare stated that, on September 8, 2025, attackers invaded accounts on npm to publish malicious versions of 18 popular packages. It resulted in billions of weekly downloads being exposed. The malicious code could steal user crypto assets and steal developer tokens from CI/CD pipelines and cloud accounts.

While the CI/CD pipeline is not the only vulnerable point, it is a critical, discrete attack surface because it often holds the “keys to the kingdom”. With an Authentication token, a cracker can have access to your Cloud’s vault.

Today, we will discuss CI/CD pipeline security best practices to ensure the safety of your build and deployment pipelines. Whether you’re a startup or an enterprise, using Jenkins or GitHub Actions, AWS or on-prem, these security practices remain universally applicable.

Common Risks and Vulnerabilities in CI/CD Pipelines

CI/CD pipelines can be appealing targets for attackers if not properly secured. Some common vulnerabilities and risks include exposed credentials, supply chain vulnerabilities, misconfigured systems, pipeline tampering via code injection, and mismanaged access controls.

Exposed Secrets and Credentials

Developers may inadvertently commit API keys, passwords, or tokens in code or configuration. Attackers who discover these secrets can use them to breach systems or services.

For example, from March to June 2025, a Salesloft GitHub account leaked cloud credentials used to access and compromise 22 companies’ sensitive data stores.

Dependency and Supply Chain Flaws

CI/CD pipelines rely on numerous third-party libraries, plugins, and build tools. If an attacker compromises a widely used dependency or package repository, malicious code can be propagated into many projects (a supply chain attack).

There was a case involving SolarWinds Orion. The supply chain attack compromised the build pipelines at a software vendor. They injected a backdoor into a popular product update, resulting in widespread downstream. The attackers gained undetected backdoor access to the networks of the organizations that installed the update. The victims included high-profile government agencies such as the U.S. Treasury and the Department of Homeland Security, and companies like Microsoft and FireEye.

Misconfigurations

Insecure default settings or misconfigured pipeline infrastructure can open the door to exploits. For instance, overly permissive access settings, default passwords, or unrestricted network access to build servers may allow unauthorized viewing or modification of code and pipeline. Such misconfigurations undermine the security of the entire CI/CD environment.

In early 2021, Nissan North America suffered a source code leak after leaving a Bitbucket Git server misconfigured, leaving it exposed with default admin/admin credentials. The leak included the source code for various internal tools, mobile apps, and connected services. Once inside the server, the attacker was able to download large volumes of proprietary, sensitive data.

Pipeline Tampering and Code Injection

Attackers who gain a foothold in the CI/CD environment can alter build scripts or inject malicious steps into the pipeline. This could lead to unauthorized code execution or the insertion of vulnerabilities into the delivered code.

Regarding the npm incident in September, a malware script hidden in a CI pipeline exfiltrated secrets and compromised the code of numerous companies.

Loose Access Controls

Lack of strict access control allows too many people or systems broad rights in the pipeline. Weak credentials or overly generous permissions can enable an outsider (or malicious insider) to manipulate code, swap out artifacts, or otherwise compromise the pipeline’s integrity. Inadequate access restrictions increase the blast radius of an attacker’s reach.

In 2019, Stack Overflow utilized a TeamCity CI server for its build and deployment pipelines. A key access control flaw was identified: newly created user accounts were granted Admin privileges by default. The attacker did not need to perform complex privilege escalation. They immediately gained broad rights to manipulate or view anything in the pipeline, which included the source code and build artifacts.

Mapping Threats: The CI/CD Attack Surface and OWASP Risks

Modern DevOps environments are both highly complex and connected. Therefore, security teams must organize their defenses around known attack vectors. The OWASP Top 10 CI/CD Security Risks provides a consensus for high-impact threats, guiding the strategic plan of defensive resources.

Key Pillars of CI/CD Security: Identity, Integrity, and Isolation

Effective defense against modern software supply chain attacks requires a strategy centered on three architectural pillars: Identity, Integrity, and Isolation.

1. Identity

Security must enforce strict access controls, utilizing mechanisms like Role-Based Access Control (RBAC) and Multi-Factor Authentication (MFA), combined with the universal application of the Principle of Least Privilege (PoLP). Use short-lived, verifiable credentials for all CI/CD processes.

2. Integrity

The company must ensure the safety and integrity of every component. There are cryptographic mechanisms such as artifact signing, provenance generation, and Docker secrets that guarantee no component was injected with malicious code.

3. Isolation

Execution environments (build runners) must be treated as inherently untrusted. Apply architectural isolation, network segmentation, and ephemeral (disposable) architectures to contain the blast radius from an attacker.

9 Best Practices for CI/CD Pipeline Security

To mitigate these risks, companies must implement strong security measures throughout their CI/CD processes.

1. Isolation Security in the CI/CD Pipeline

Your CI/CD pipeline is your production environment as much as the servers hosting your application. A compromised pipeline poses an existential threat, as it can be leveraged to rapidly deploy malicious code, effectively bypassing all downstream security controls.

Avoid shared infrastructure and never use shared or public build agents/runners for executing your pipeline steps, especially when dealing with sensitive or proprietary code.

Also, utilize dedicated infrastructure. Opt for ephemeral build environments (e.g., containers, virtual machines) for each job. These agents should be completely rebuilt or destroyed after each use to eliminate any potential malware persistence or residual data from previous builds.

Apply strict network segmentation and firewall rules to restrict the build environment’s access only to the internal and external resources strictly necessary for the build and deployment process.

2. Robust Access Control and Monitoring

Every user, system, and process interacting with the pipeline must operate under the principle of least privilege. It ensures that the build system and its associated service accounts only have the minimum permissions necessary to perform their required tasks (e.g., read code, write artifacts, deploy to staging). Do not grant them blanket administrative access. Here are some best practices for Access Control:

• Assign fine-grained roles for build triggers, artifact publishing, and deployment actions.
• Integrate your CI/CD platform with SSO and MFA for human users.
• Avoid static credentials; prefer OIDC, SAML, or short-lived API tokens issued per job.
• Review permissions periodically to remove unused or over-privileged accounts.

3. Short-Lived and Rotated Credentials

All automation within the pipeline should strictly use short-lived tokens or credentials, generated just in time for the execution of a specific task.

Implement an automated process for any long-lived secrets rotation (e.g., API keys or service account passwords). It minimizes the opportunity for an attacker if a secret is leaked.

4. Secure Source Code and Dependencies

Your CD/CI pipeline security starts before the build even runs. Protect repositories with branch protection rules, signed commits, and mandatory code reviews.

Enable dependency scanning (SCA) to detect known vulnerabilities in libraries and containers. Use checksum validation for third-party binaries and internal dependency mirrors to prevent supply-chain attacks. Finally, regularly audit Git history for secrets or credentials that might have been leaked in the code.

5. Harden Build and Deployment and Environments

Build servers and runners often store sensitive information, such as environment variables, access tokens, or signing keys. But they can’t enter these environments if they are blown up as soon as they serve their purpose. Use ephemeral build environments (containers or VMs) that self-destruct after each run.

Store secrets in dedicated secret managers. Some examples are HashiCorp Vault, Azure Key Vault, AWS Secrets Manager, and OCI Vault.  Don’t store your secrets in the .env files.

Validate build integrity by using checksums, SBOMs (Software Bill of Materials), and signature verification. If someone tries to tamper with your artifacts, you will know.

6. Input and Output Validation for CI/CD Security

The CI/CD pipeline acts as a processing system, consuming various inputs (code, configuration, scripts, parameters) and producing outputs (build artifacts, deployed code). Every element that flows through this system is a potential attack vector. Rigorous validation of these elements is crucial to prevent injection attacks, ensure code integrity, and verify that only trusted, secure components are deployed.

Treat all environment variables and build parameters as untrusted input. Implement strict sanitization and input validation to filter, escape, or reject any suspicious characters or commands that could enable command injection, cross-site scripting (XSS), or other injection vulnerabilities against the build agent or environment.

Encrypt and sign every generated build artifact (containers, binaries, packages) using established tools like GPG or modern, transparent standards like Sigstore. This signature serves as a tamper-proof certificate that confirms who built the artifact and that it has not been altered since it was created.

Before any deployment, the pipeline must verify the integrity of the final artifact. Compare its computed cryptographic hash (for example, SHA256) against a known, trusted hash generated immediately after the build. If the hashes don’t match, someone likely changed the artifact, and the deployment must be stopped.

Finally, run Static Application Security Testing (SAST) tools on the source code before merging to identify vulnerabilities like buffer overflows, improper handling of user input, and hard-coded secrets. Also, utilize Dynamic Application Security Testing (DAST) tools on the running application in a staging environment. They will search for runtime vulnerabilities like cross-site scripting and SQL injection.

7. Implement Continuous Monitoring and Logging

You can’t protect what you can’t see. Centralize logs from your CI/CD platform (e.g., GitLab CI/CD, Jenkins, Azure DevOps), build agents, and deployment targets. Track every build and deploy event: who triggered it, what commit, and where it was deployed. Monitor for anomalies like unexpected deployment frequency or unauthorized config changes. Finally, enable alerting and audit trails to track back any unauthorized action.

8. Train Developers and Operators

Tools and policies are useless without awareness. The human factor is the biggest security threat to any system. According to Verizon’s 2024 Data Breach Investigations Report, 60% of all security breaches were due to human error. A fundamental strategy in CI/CD security is “shift-left” security, a DevSecOps mindset. Shift-left integrates security measures into each phase of the software development lifecycle rather than waiting until security breaches occur. In traditional models, security checks happened late (for instance, just before deployment or in production).

From the moment code is written until the end user, security steps must be in play. Throughout all stages, if a security check fails, the pipeline can halt the process for remediation. Such an approach aligns with DevSecOps principles, emphasizing that security is not solely the security team’s job; it’s everyone’s concern and should be woven into daily development work

9. Continuously Audit and Improve

CI/CD security isn’t static; it must evolve as your toolchain and attack surface evolve. Run periodic security audits and penetration tests on the CI/CD infrastructure. Then track and remediate vulnerabilities with a formal SLA. Don’t forget to review and tighten pipeline permissions and network boundaries periodically. Benchmark your CI/CD pipeline security with frameworks like NIST SSDF, OWASP CI/CD Top 10, and SLSA (Supply Chain Levels for Software Artifacts).

Conclusion

CI/CD pipeline security is essential and non-negotiable. As they often hold the “keys to the kingdom,” an attacker who compromises a pipeline can inject malicious code directly into the final product, bypassing all downstream controls. Companies can transform their pipelines from an attractive attack surface into a protected and trustworthy part of the DevSecOps lifecycle.

Therefore, a proactive, “shift-left” security mindset that integrates measures from the moment code is written is the only way to safeguard the software supply chain against evolving threats.

But maybe you are not sure how to implement all these security safeguards all by yourself. A system security developer can protect your application in your CI/CD pipelines and all your systems! Contact us, and we will find you the best security developer for you!

Cesar Fazio

César is a digital marketing strategist and business growth consultant with experience in copywriting. Self-taught and passionate about continuous learning, César works at the intersection of technology, business, and strategic communication. In recent years, he has expanded his expertise to product management and Python, incorporating software development and Scrum best practices into his repertoire. This combination of business acumen and technical prowess allows structured scalable digital products aligned with real market needs. Currently, he collaborates with DistantJob, providing insights on marketing, branding, and digital transformation, always with a pragmatic, ethical, and results-oriented approach—far from vanity metrics and focused on measurable performance.