In January 2022, Palo Alto Networks paid roughly $195 million for Cider Security, folded it into Prisma Cloud, and rebranded the result as an Application Security Posture Management (ASPM) offering. It was a reasonable bet on a real problem: security teams had visibility into cloud workloads and runtime, but almost none into the developer environment where those workloads originate — CI/CD pipelines, build systems, package registries, and the identities and secrets that hold them together. Three years later, that gap is still where breaches start. The xz-utils backdoor (CVE-2024-3094, discovered March 29, 2024), the March 2025 tj-actions/changed-files compromise that exposed CI secrets across roughly 23,000 repositories, and the 2021 Codecov Bash Uploader breach all began in developer infrastructure, not production. "Developer security posture" is the practice of treating that infrastructure — not just application code — as a first-class asset to inventory, score, and defend, starting before a single line of code reaches a cloud environment.
What is developer security posture, and why does it start before code ships?
Developer security posture is the continuously measured state of the tools, identities, and pipelines developers use to build and ship software — separate from, and earlier than, the application security posture of the code itself. It covers things like which CI/CD runners have write access to production registries, which OAuth apps and personal access tokens have repo-admin scope, whether build steps pull unpinned dependencies over HTTP, and whether a former contractor's SSH key is still authorized on a self-hosted GitHub Actions runner. Gartner's original ASPM definition, coined in 2022, focused on aggregating findings from SAST, SCA, and DAST tools into a single risk view of applications. That's necessary but insufficient: by the time a SAST scan runs, the developer has already committed code through a pipeline that may itself be compromised. A 2023 Sonatype State of the Software Supply Chain report found more malicious packages uploaded to open source registries that single year than in the previous four years combined — attackers are increasingly targeting the pipes, not just the endpoints.
Why did Prisma Cloud build ASPM from the cloud outward instead of the developer inward?
Prisma Cloud's ASPM grew out of a cloud security posture management (CSPM) platform, so its strongest signal is still runtime and cloud configuration, with code and pipeline findings correlated back to workloads after the fact. That lineage shows in the product: Prisma Cloud excels at answering "which running container has a vulnerable library that's also internet-facing," a genuinely valuable runtime-to-code correlation. But it was not built around the developer's day-to-day surface — the laptop, the local git config, the CLI tools, the CI runner fleet, the registry credentials — as a primary telemetry source. Cider Security's original product did cover pipeline security, but integrating an acquired product into a much larger CNAPP suite (Prisma Cloud spans CSPM, CWPP, CIEM, and more) tends to pull engineering priority toward the platform's cloud core. The practical effect for buyers: developer infrastructure findings often surface as a module within a broader cloud console rather than as the primary lens, which matters when the incidents you're trying to prevent start at commit time, not deploy time.
What happened when CI/CD pipelines became the primary attack surface?
CI/CD pipelines became a primary attack surface once they accumulated more standing access than the production systems they deploy to, and 2024-2025 supply chain incidents confirm it. In the tj-actions/changed-files incident (March 14-15, 2025), attackers modified a widely-used GitHub Action to dump CI runner memory, exposing secrets in public build logs across thousands of downstream repositories — a single compromised action, not a compromised application. In the 3CX incident (disclosed March 2023), attackers compromised a build pipeline through a trojanized third-party library, ultimately shipping malware inside a signed, legitimate desktop application to hundreds of thousands of customers. And the SolarWinds attack (discovered December 2020, with the injection dated back to at least September 2019) remains the reference case: attackers inserted malicious code into the Orion build process itself, not the finished product's source repository. Each of these bypassed traditional AppSec controls entirely, because SAST and SCA tools scan source code and dependencies — they don't typically evaluate whether the build server that assembles them has been tampered with.
Why does treating pipeline security as a checklist item leave real gaps?
Treating pipeline security as a checklist item leaves gaps because most organizations still manage it with static, point-in-time reviews instead of continuous posture scoring. A typical enterprise runs CI/CD across multiple providers — GitHub Actions, GitLab CI, Jenkins, CircleCI — often inherited through acquisitions, with no single inventory of which runners are self-hosted, which have outbound internet access, or which secrets they can read. A checklist audit in Q1 doesn't catch the self-hosted runner spun up in Q3 with a public IP and cached cloud credentials. This is the same failure pattern that made cloud misconfiguration the top cause of cloud breaches for years before CSPM tools existed to continuously monitor drift. Developer infrastructure needs the same continuous model: pipeline configurations, third-party GitHub Actions/CI plugins, and registry publish permissions change weekly in an active engineering org, and posture that isn't re-evaluated on every change is stale within days.
How much more does it cost to fix a posture issue after deployment than at commit time?
Fixing a security issue after deployment costs substantially more than catching it before merge, largely because remediation after release requires coordinating a hotfix, a re-deploy, and often an incident response process rather than a code review comment. IBM's Cost of a Data Breach reports have consistently shown organizations with mature DevSecOps and automated security testing save well over $1 million per breach on average compared to those without it, and breaches involving the software supply chain took 26% longer to identify and contain than the overall average in IBM's 2023 analysis. Shift-left economics apply just as directly to infrastructure as to code: revoking an overprivileged CI token during a pull request review costs a few minutes; discovering that same token was used to exfiltrate a signing key three months after a release ships costs an incident response engagement, customer notifications, and possibly a compliance finding under frameworks like SOC 2 or SLSA.
How Safeguard Helps
Safeguard was built to give developer infrastructure the same continuous, first-class posture treatment that CSPM tools gave cloud environments — not as a module bolted onto a broader cloud suite, but as the primary lens. Safeguard continuously inventories CI/CD pipelines across GitHub Actions, GitLab CI, and self-hosted runners, flagging overprivileged tokens, unpinned third-party actions, and runners with unexpected network egress before they become the next tj-actions incident. It scores developer identity risk — stale personal access tokens, unused OAuth app grants, admin-scoped service accounts — and ties findings directly to the commit, pipeline run, or registry publish event that introduced them, so engineering teams get actionable, pull-request-level context instead of a dashboard alert disconnected from the code. For teams already running Prisma Cloud or another CNAPP for cloud workload protection, Safeguard is designed to complement that runtime coverage rather than duplicate it, closing the pre-deploy gap in developer infrastructure posture that cloud-first ASPM tools inherited from their CSPM roots. The result is a developer security posture that's measured continuously, tied to real engineering workflows, and caught at commit time — when it's a code review comment, not an incident.