CI/CD pipelines, once considered internal infrastructure, are now primary targets for software supply chain attacks. Recent data from cybersecurity firms Xygeni and Gartner show that adversaries are increasingly bypassing perimeter defenses and going directly after the systems that automate software builds and deployments.
Gartner’s 2025 Software Engineering Security Brief identified software supply chain risk as one of the top five security concerns for enterprise organizations. Meanwhile, Xygeni’s report, released in May 2025, found a 39% year-over-year increase in CI/CD-targeted attacks. Common entry points included pipeline misconfigurations, poisoned dependencies, and unauthorized script injections.
These findings are prompting platform engineering teams to rethink where trust begins in the software lifecycle. Major software supply chain security players are calling for a redefinition of zero-trust that starts not at runtime, but at the build stage.
Why Zero-Trust Must Start Before Deployment
Traditional security models often treat CI/CD pipelines as trusted zones, applying strict controls only once software enters staging or production environments. However, this model creates blind spots in earlier stages of the software development lifecycle. Attackers can modify source code, inject malicious logic, or tamper with build scripts without being detected.
Zero-trust doesn’t start when software is deployed; it starts the moment a commit is pushed to a repository and the build begins. Every artifact created should actually be traceable, signed, and policy-verified before it moves another step.
The issue is not solely technical. Workflow design and enforcement also matter. In fact, according to Scribe Security’s internal data, more than 60% of incidents involving compromised build artifacts were traced to weak or missing policy checks within early pipeline stages. Scribe Security partners with clients in defense, technology, and financial services, and provides a software supply chain security platform that enables continuous assurance and attestation, building trust into every step of your SDLC.
Policy-as-Code Moves Security Left
One strategy gaining attention is policy-as-code. This approach involves codifying security rules and integrating them directly into CI/CD workflows. These rules can include requirements for code signing, dependency verification, and configuration checks. The goal is to eliminate manual oversight and create automated gates that stop non-compliant software from proceeding.
Defining compliance requirements as code helps reduce ambiguity. The companies can also verify that these rules are being followed in real time, not just during a quarterly audit.
Organizations using this method are reporting measurable results. A U.S.-based fintech company, for example, saw a 47% decrease in failed builds caused by unapproved third-party packages. More notably, it reported zero critical vulnerabilities reaching production following the adoption of policy-as-code in its CI pipeline.
The Role of Attestation and Signed Evidence
Another key strategy involves collecting signed, machine-readable evidence from each step of the build process. This includes who triggered a job, what scripts ran, which components were included, and how those components were verified.
Solutions like Scribe Security apply this practice through their attestation framework, which helps organizations establish clear audit trails for software integrity. These attestations can be used internally or shared with regulators and partners who require formal proof of secure development practices.
“We’ve seen a growing demand from CISOs who want verifiable proof that what they ship is what they built,” said Arbel. “That proof doesn’t come from perimeter firewalls. It comes from the build process itself.”
This shift in demand is in line with regulatory trends. The U.S. Executive Order 14028 requires federal contractors to generate software bills of materials and document their secure development practices. The European Union is adopting similar requirements under the Cyber Resilience Act, which will require transparency and accountability throughout the software supply chain.
Automation Aligns Security and Development Teams
For DevSecOps managers and platform engineering leads, integrating zero-trust principles into CI/CD workflows is as much about operational efficiency as it is about reducing risk. Automating attestations, artifact signing, and policy validation reduces the need for manual enforcement while making compliance part of daily development.
The objective is not to delay releases. Instead, it is to embed trust throughout the software lifecycle in a way that is both scalable and auditable. Platforms that allow security and engineering teams to share visibility, track compliance metrics, and respond to issues in real time are becoming essential.
Organizations are beginning to treat the build process as the foundation of software trust. Rather than relying solely on perimeter defenses or post-deployment controls, they are investing in earlier safeguards that embed verification into every stage of development. Solution providers like Scribe Security argue that effective zero-trust security depends on continuous validation from the moment code is written, and through to its release.
