Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

You run the pipeline. You own the releases. And somewhere between the security team's findings and the development team's sprint, you're the one getting asked to explain why nothing is getting fixed. That's not a security problem. It's a coordination problem, and it's structural. According to the DuploCloud AI + DevOps Report, Sep 2025, The pipeline is under more pressure than it's ever been. The attack surface is wider than it's ever been.

The shift-left approach and prioritizing security from the very beginning of the coding process are what the tech industry talks endlessly about. Yet, many DevOps teams falsely believe that simply scanning code makes them secure. The harsh reality is that your CI/CD pipeline is rarely guarded with the same level of rigor and monitoring as the production environment it serves.

Security teams are under more pressure than ever, and most of them believe they’re keeping up. That confidence, it turns out, may be the most consequential finding in the JFrog 2026 Software Supply Chain Security State of the Union.

CI/CD pipeline security is not a single tool decision. The pipeline spans source code, build systems, container registries, infrastructure configs, and production workloads. Each stage carries different risks and needs different controls. This guide covers the full stack of ci/cd pipeline security tools, the industry standards that govern them, and the CI/CD security best practices that make them work in production.

In March 2026, a GitHub account called hackerbot-claw, describing itself as an “autonomous security research agent powered by claude-opus-4-5,” began systematically targeting open source repositories—including one from Datadog. Over a week, it opened many pull requests designed to exploit misconfigurations in GitHub Actions workflows.

Source code management (SCM) and CI/CD pipelines have become the industry standard for automating software delivery. But from the time a code change enters your SCM until it’s deployed, it’s susceptible to changes and reconfigurations that can go so far as to modify the pipeline itself. If you’re not proactively securing your CI/CD system, attackers can use it to grant themselves permissions, access secrets, and ship malicious code.

In Part 1 of this series, we discussed the CI/CD security boundary, mapped out potential attack vectors with a CI/CD threat matrix, and introduced a simple threat model focused on ideating detection workflows. In this post, we’ll apply these principles to a real-world source code management (SCM) tool example that every developer is familiar with: GitHub. In addition to threat modeling, we’ll also be taking a closer look at historical attacks on GitHub and GitHub Actions ecosystems.

Imagine your lead Software Engineer walks into your office and says, “Good news! I just deployed that critical update to production. I wrote the code on my personal laptop, didn’t run it through CI/CD, skipped the security scan, and just copied the files directly to the server with a USB drive.” You would fire them. Or you would revoke their access immediately.

For many engineering teams, CI/CD security appears to be working. Static scans run automatically. Vulnerabilities are flagged. Security checks exist somewhere in the pipeline. Yet issues still surface after release. The reason is rarely the absence of tools. More often, it is the absence of structural enforcement across the build lifecycle. Security controls run inside the pipeline, but they do not always guarantee that the artifact being tested is the same artifact that ultimately reaches users.