Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

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.

Modern engineering teams ship fast. Attackers move faster. CI/CD pipelines are no longer just build systems; they are a critical part of production infrastructure. A compromised pipeline can allow attackers to inject malicious code, poison dependencies, leak secrets, or deploy compromised builds directly to production. As Engineering Managers, we’re expected to maintain high delivery velocity while reducing security risks.

In software engineering, the deployment process is not just about running a script and hoping it sticks. A big part of it is automation, not as a luxury, but a necessity. And that’s where Azure Pipelines steps in. The software provides a robust CI/CD engine embedded in the Azure DevOps ecosystem. Developers and DevOps engineers working with version control systems, containers, or even legacy monoliths can leverage Azure Pipelines.