7 CI/CD Security Best Practices to Focus on

Your CI/CD pipeline is your company’s innovation engine: it takes ideas from code to production faster than ever before. But to attackers, it looks like something else entirely: a single, trusted doorway into your infrastructure. Compromise the pipeline, and the rest of your defenses can crumble.

Breaches like SolarWinds and Codecov exposed just how devastating poisoned pipelines can be. And the threat is only accelerating:  Gartner projects that by the end of 2025, 45% of organizations will have suffered a supply chain attack, with pipelines among the most common targets.  Attackers aren’t just after your product anymore; they’re after the building process.

For CTOs, DevSecOps leaders, and product security teams, the message is clear: the security of your software is inseparable from the integrity of the pipeline through which it flows.

What is CI/CD Security?

CI/CD security refers to the set of practices and controls designed to protect the software delivery pipeline - the automated system that takes code from development into production. Your pipeline compiles code, pulls dependencies, runs tests, and deploys artifacts to staging or live environments. Every stage touches sensitive assets like source code, credentials, and infrastructure settings, making the pipeline a prime target if left unguarded.

SolarWinds, the most significant software supply chain attack in history (to date), used the CI/CD pipeline as the attack vector. Attackers pushed backdoored updates directly to customers by inserting malicious code into trusted processes. This attack illustrates why the pipeline, with its high degree of automation and broad privileges across build, test, and deployment, represents one of the most critical choke points in modern software delivery.

Because CI/CD has become a potentially critical failure point, multiple security frameworks now define how you should secure it. For example:

• The OWASP Top 10 CI/CD Security Risks highlight pitfalls such as insufficient credential hygiene, poisoned pipeline execution, and insecure system configurations. 

• The US government’s NIST SP 800-204D directly maps software supply chain security controls into DevSecOps workflows. It recommends artifact integrity checks, continuous SBOM generation, and provenance validation. 

• Similarly, the SLSA framework (Supply-chain Levels for Software Artifacts) provides a tiered approach to securing build systems against tampering.



Why You Need CI/CD Security Now

Since SolarWinds, attacks targeting CI/CD pipelines have increased significantly. Incidents like the 2023 CircleCI attack and the recent GhostAction GitHub attack demonstrate the attractiveness of breaching a pipeline to attackers. Such attacks can ripple across thousands of organizations, making their blast radius and cost significant.

Several forces are amplifying the risk. The unchecked use of unapproved AI tools (“shadow AI”), the explosive growth of open-source dependencies, and inconsistent governance around code and infrastructure all widen the attack surface. In fact, a staggering 63% of organizations lack proper AI governance policies. At the same time, the financial consequences keep climbing: a data breach now costs $4.4M on average.

External penetration testing of CI/CD environments increasingly confirms what attackers already know: pipelines represent some of the most valuable targets in the modern software supply chain. Clearly, securing the application itself is no longer enough. You must protect the pipeline that builds, tests, and deploys it just as rigorously. Strong CI/CD security delivers:

• Prevention of supply chain compromises before they spread downstream.

• Faster, safer releases without introducing new risks.

• Greater reliability, avoiding outages that disrupt customers and revenue.

• Reduced financial and compliance exposure, from regulatory fines to breach costs.

• Stronger organizational resilience, with faster detection and containment of pipeline threats.



Top Threats in CI/CD Pipelines

Attackers go where the trust is; in most organizations, nothing is more trusted than the CI/CD pipeline. It pushes code into production, runs with elevated privileges, and orchestrates the systems developers rely on daily. That level of control makes it a prime target: once the pipeline is compromised, every downstream environment and application is suddenly in play.

Multiple threats can target your pipeline. Here are a few of the more common dangers you may encounter:

• Misconfigured runners and permissions: Over-privileged build agents or poorly isolated self-hosted runners create easy pivot points for lateral movement.

• Poisoned dependencies: Typosquatting and malicious open-source packages remain a leading cause of supply chain compromise, slipping into trusted builds when developers pull components from public registries.

• Poisoned pipeline execution (PPE): When pipeline configurations, scripts, or build tools are tampered with, attacker code executes under the pipeline’s trusted identity. PPE was the core technique behind the SolarWinds attack, where attackers signed and distributed malicious updates through legitimate build processes.

• Exposed secrets: Hardcoded keys, tokens, passwords, or even mismanaged Kubernetes secrets continue to leak into repositories and build logs, providing attackers with direct access to infrastructure and production systems.

• Unverified third-party actions: Community-contributed plugins and workflows can be tampered with, as shown by recent campaigns that exploited GitHub Actions to siphon secrets across projects.

7 CI/CD Security Best Practices to Focus on

1. Scan for Hardcoded Secrets

Secret leakage is still one of the most frequent entry points in CI/CD breaches, but the real issue isn’t just that developers commit keys by mistake; it’s how quickly attackers harvest those secrets once exposed. They continuously scan public repos and logs for credentials, sometimes exploiting secrets within minutes of appearing. That makes reactive cleanup (revoking and rotating) too slow to rely on.

Instead of relying only on detection, the focus should be on making secret exposure harder to exploit in the first place. That means catching issues early with scanners in pull requests and build jobs, and stopping them even sooner with pre-commit hooks on developer machines. Credentials should never be static; use vaulting systems and short-lived, just-in-time tokens so that even if something leaks, it quickly loses value. For sensitive assets such as cloud keys, add another layer of defense by watching for abnormal usage patterns that signal compromise.



2. Integrate SAST and SCA into Every Pull Request

The earlier you find a vulnerability, the cheaper it is to fix it. SAST and SCA tools are most effective when they run automatically at the pull request stage, stopping insecure code before it merges. 

Developers get instant feedback on issues like insecure functions or outdated libraries, keeping fixes small and localized. With Jit, results surface directly as inline comments in GitHub, complete with contextual guidance. That way, developers can address problems immediately, without breaking their flow or waiting for a security review weeks later.

3. Use Dependency Graphs

A dependency graph is a control point for managing supply chain risk. Build and maintain a complete graph of direct and transitive dependencies, and configure it to update automatically with each build so it never goes stale. Use it to flag known-vulnerable packages and unfamiliar or low-reputation components that could be typosquats or malicious uploads.

The real value comes from using the graph to drive prioritization. Focus remediation on dependencies that sit on critical execution paths or touch sensitive workloads, rather than spreading effort across rarely used libraries. Integrate graph insights into vulnerability management workflows so security teams know which services need attention when a new CVE is published. 

You can use tools like GitHub’s Dependency Graph or Zeitgeist to generate and update dependency mapping automatically. Importantly, you should treat dependency analysis as a continuous control: run it with every build, feed the results into your vulnerability management process, and set policies to block high-risk packages before they enter the pipeline.



4. Automate Infrastructure-as-Code (IaC) Scanning

Cloud misconfigurations are one of the leading causes of breaches, and IaC templates can hardwire those risks straight into production. An overly permissive IAM role or an open security group in Terraform or Kubernetes may slip through review. Still, once deployed, it is replicated across environments and exposes a much larger attack surface.

Use tools like KICS, tfsec, and Legitify to catch insecure defaults before they leave version control. The key is not just running scans but embedding them directly into developer workflows: configure checks to trigger automatically on pull requests, block merges that fail policy, and build templates around least privilege by default. 

Jit codifies IaC scanning into Security Plans as Code. Every build is automatically tested against hardened baselines on every commit, with results surfaced directly inside GitHub pull requests. Developers see contextual fixes in the same place they write code, which shortens remediation time and keeps security from becoming a bottleneck. Its Compliance Agent goes a step further by mapping IaC checks against frameworks like NIST, SLSA, and PCI DSS, so every misconfiguration fix also strengthens audit readiness and compliance posture.

5. Continuously Generate and Verify SBOMs

Static Software Bills of Materials (SBOMs) are worse than none at all. In fast-moving environments, dependency sets change daily, and an outdated inventory only gives teams a false sense of security. The real value of SBOMs comes from automation: generating them with every build, validating them against vulnerability feeds, and ensuring provenance so attackers can’t slip in tampered components. 

Tools such as Syft or CycloneDX can generate SBOMs automatically in standard, machine-readable formats and feed them into vulnerability management systems for continuous comparison against CVE databases. To make those inventories meaningful, they should be paired with artifact integrity checks so teams can confirm what’s in the build and that it hasn’t been altered.

Jit handles this as part of the delivery process itself. By embedding SBOM generation directly into Security Plans as Code, every build produces a verifiable, continuously updated inventory without extra overhead. That consistency helps teams meet NIST and SLSA requirements while giving security leaders more immediate visibility into exposure.



6. Harden Build Environments with Ephemeral Runners

Build environments are a favorite target for attackers. Long-lived runners accumulate risk over time, making them easier to compromise. By contrast, ephemeral runners spin up fresh for each job and tear down immediately after, denying attackers persistence. 

Start by classifying which workloads require persistent runners (such as resource-heavy builds) and migrate everything to on-demand execution. Implement policies for secret injection that prevent long-lived tokens from being embedded in runner images. Lastly, network security can be strengthened by segmenting runners from production systems and restricting their connectivity, so the exposure is contained even if one is compromised mid-job.

7. Build Runtime-to-Code Feedback Loops

Some vulnerabilities only surface once software is running. The challenge is that runtime signals often sit in monitoring dashboards or SIEMs, disconnected from the developers who wrote the code. Without a clear path back to the source, incidents linger, and remediation cycles stretch into weeks.

The answer is to close the loop. Tie runtime telemetry directly to builds, artifacts, and even specific commits, so when an anomaly appears in production, it can be traced back to the code or configuration that introduced it. 

Jit’s Knowledge Graph ties runtime data back to CI/CD vulnerabilities and presents them inside developer workflows. Instead of runtime alerts becoming background noise, it connects directly to the code that caused them. Its SecOps Agent closes the loop by automating remediation workflows, converting runtime incidents into actionable, developer-friendly tickets, and reducing mean time to remediation (MTTR).



Turning Pipelines into Secure Innovation Engines

CI/CD pipelines have become the nervous system of modern software delivery. They move ideas from code to production quickly, but the same trust and automation that make them powerful make them a prime target. Secrets, poisoned dependencies, and compromised runners are no longer edge cases; they’re the entry points attackers actively look for. The difference between risk and resilience is how well the pipeline is secured.

The fundamentals aren’t complicated, but deploying them consistently at scale, however, is where most teams struggle. Jit weaves security into the development process itself, with one-click activation of tools, automated SBOMs, and Security Plans as Code that make best practices the default. Combined with AI-assisted analysis and a Knowledge Graph that filters out the noise, this platform gives teams what they need most: the ability to keep shipping quickly, without exposing the pipeline. Explore more here.