Chainguard’s CTO on why every build needs an identity

How build identity and scoped access secure software

Matt Moore, co-founder and CTO of Chainguard, joined the podcast to discuss the overlap between open-source software supply chain security and identity and access controls.

Modern applications depend on open-source packages, base images, and tools that most teams don’t maintain internally. When one of those dependencies is vulnerable, compromised, or published using stolen credentials, the compromise can move through the build and into software that reaches production. As AI coding agents gain authority, they introduce a new layer of uncertainty to the software development lifecycle. Matt argued that before shipping, teams need to know what enters a build, who or what changed it, and which credentials the workflow can access. 

Most of what you ship is inherited

Developing with open-source projects includes known security risks. For teams working under time constraints, open-source projects provide packages, runtimes, tools, and the images they need to build applications and jumpstart a build, but those components also become part of the software an organization must inventory and update.

Across industries, open-source software is a critical building block of the software supply chain. Black Duck’s 2026 Open Source Security and Risk Analysis Report found open-source components in 98% of the 947 audited codebases it analyzed.

The amount of software that we actually write to ship modern applications is this tiny tip of the iceberg, compared to what we’re actually running in our environments.”

–Matt Moore, co-founder and CTO, Chainguard

To help developers make safe choices, many organizations create approved package lists, internal registries, dependency policies, and standard base images. These recommendations reduce the time it takes to source and review a package, but don’t make a dependency permanently safe from new vulnerabilities or guarantee it’ll be maintained and updated.

For developers, monitoring and patching vulnerabilities can feel like a distraction from other critical work. Matt shared that Chainguard’s approach addressed this by moving trust decisions earlier in the workflow, keeping security work off the developer’s task list. Chainguard tracks upstream source, builds artifacts from source, and provides evidence of how those artifacts were produced. By giving developers a more controlled and verifiable starting point, it provides more visibility into risks than an opaque artifact from a public registry.

How a compromised package becomes an identity incident

In the builder workflow, Matt sees two distinct identity types to secure. Human identities that need controls like password managers, MFA, and SSO, and machine identities that need federation and short-lived access. In both cases, security depends on removing reusable, long-lived credentials in a workflow. Despite the availability of credential security tools and best practices, long-lived credentials continue to play a significant role in supply chain compromises.

Matt recalled how the SolarWinds compromise showed attackers moving through a trusted software build to distribute malicious code via a legitimate update path. And again, how the Shai-Hulud campaign showed malicious npm packages scanning for developer and CI/CD credentials and using compromised access to distribute malicious packages.

“That is why you should never put credentials on disk,” Nancy affirmed.

Matt continued that short-lived credentials should be part of build security standards because many supply chain benefits rely on credentials. As he said, “Credentials let you launch the next wave of these things.”

This is one of the access problems 1Password is working to solve. 1Password Credential Broker verifies a workload’s identity against policy, delivers only the approved credential at runtime, and logs which workload requested it and which policy authorized delivery. This keeps long-lived credentials out of pipeline configurations and environments and offers security teams clear documentation of machine access.

As AI-assisted development increases the number of agents and automated workflows that can initiate access, software supply chain security and identity security must expand to make every authorization and access decision visible, secure, and auditable.

The co-pilot takes off

Every deployed agent is part of the software supply chain it operates within.

When securing identities, the agent and the CI pipeline have different roles; thus, they need different authority models, an idea 1Password has explored in agent identity architectures. A coding assistant acting for a developer has delegated authority. A CI workflow has bounded authority within a defined build process. Treating both as “agents” obscures the security questions of who authorized the action, what the agent was allowed to reach, and which workload performed it.

To Matt, right-sized access can limit an agent to the repositories, dependency manifests, and build configurations it is authorized to change. An audit trail should connect the authorization to the resulting change, the agent that made it, the workload that executed it, and the credentials issued to that workload.

He believes security starts upstream, with the software developers consume. Chainguard’s approach is to keep that upstream path current, controlled, and verifiable through source builds, supported versions, and automation.

As agents and automated workflows take on more of the path from code to production, organizations need to know not only what software they are building but also which identities can access it, what those identities can do, and when that access ends.

That is the identity problem emerging around AI-assisted development. Agents need an authority model that matches their role. By eliminating standing access and linking attribution to each access request, organizations can securely leverage the ease of open-source software and the efficiency of autonomous agents.