Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

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.

Static credential practices — where certificates, keys, and tokens persist for months or years and are manually rotated — create systemic risk in DevOps pipelines. Rotating these secrets is time-consuming and costly. In fact, organizations may spend dozens of hours and involve multiple teams to rotate a single credential. Manual rotation quickly becomes impractical across thousands of service accounts. In this post, you will learn.