Dan Lorenc discusses AI-driven software engineering, software supply chain security, CI/CD risks, autonomous coding agents, and why trust, verification and governance will define the future of software development.
Artificial intelligence is fundamentally changing software engineering. Code generation is becoming increasingly automated, autonomous agents are contributing production-ready pull requests, and software factories are beginning to operate at a pace no human engineering team could sustain alone. While this promises unprecedented gains in developer productivity, it also introduces a new set of challenges around trust, software supply chain integrity and security governance.
In an exclusive conversation with CIO&Leader, Dan Lorenc, Co-founder & CEO of Chainguard, discusses why engineering teams should spend less time writing code and more time engineering trust, why CI/CD pipelines have become one of the most valuable targets for cybercriminals, and why the industry’s next competitive advantage will come from securing autonomous software development rather than merely accelerating it.
CIO&Leader: As software velocity scales exponentially while human cognitive capacity remains finite, how must downstream trust and testing pipelines evolve to prevent software factories from fracturing?
Dan Lorenc:
The biggest change isn’t that AI is writing more code. The real shift is where engineering organisations choose to invest their effort. As code generation becomes abundant, writing software stops being the bottleneck. Trust becomes the bottleneck.
That requires a completely different engineering mindset. Rather than developers spending most of their day producing code, they’re increasingly directing AI agents, reviewing implementation strategies, steering execution and validating that every generated output complies with the quality and security expectations of the organisation.
Because we’ve invested heavily in that automated verification layer, our engineering process is stronger than it has ever been. We have broader regression coverage, more comprehensive performance testing and significantly better test coverage across the board. Interestingly, those investments don’t only improve confidence in AI-generated code—they also make human-written software more reliable because every change passes through the same rigorous validation pipeline.
Ultimately, engineering productivity is no longer determined by how quickly developers can write code. It’s determined by how effectively organisations can build factories capable of continuously verifying that the code—regardless of who produced it—is safe to ship.
CIO&Leader: With AI agents enhanced capabilities trust becomes the challenge. How does this change traditional corporate code review policies? Are we moving towards a future where AI agents both generate and approve code?
Dan Lorenc: That’s probably one of the biggest debates happening across the software industry today.
The question isn’t simply whether agents can write code—they clearly can. The real question is whether organisations can trust agents to review work produced by other agents.
We’ve experimented with that model in lower-risk scenarios, but today our approach is slightly different.
Instead of allowing AI to generate enormous pull requests containing thousands of lines of code, we deliberately break development work into much smaller increments. An AI agent first develops a concrete implementation plan. A human reviews that overall approach before any code is generated. Once the plan is approved, the agent begins producing implementation in small, incremental chunks that can often be reviewed in a matter of minutes rather than hours.
That changes the role of the engineer quite significantly. Humans spend less time reviewing individual lines of code and more time validating architecture, intent and overall design decisions, while AI performs much of the implementation.
Breaking work into smaller units also helps reviewers maintain context. Reviewing a thousand-line pull request often becomes mentally exhausting, whereas reviewing incremental changes every few minutes allows teams to maintain higher quality while moving substantially faster.
Looking further ahead, I do believe organisations will eventually become comfortable allowing AI to perform much larger portions of security review.
AI is actually exceptionally good at analysing software against predefined security rules.
CIO&Leader: Enterprise development teams frequently integrate third-party GitHub Actions into their CI/CD pipelines without thoroughly evaluating them. Why have software delivery pipelines become such attractive targets for attackers?
Dan Lorenc: CI/CD pipelines have traditionally been one of the most overlooked parts of the software development lifecycle. They’re often treated as infrastructure that simply works once it’s configured. People build the pipeline, get it operational, and then largely forget about it.
The reality is that those systems often hold the most privileged credentials inside an organisation. Many developers cannot deploy software directly into production environments, but the CI/CD platform certainly can. It effectively possesses the keys to the kingdom.
That makes it an extremely valuable target for attackers.
Depending on how authentication is configured, a single typo inside a GitHub Action—or a compromise involving one third-party GitHub Action—can expose credentials capable of deploying malicious software into production.
We’ve already witnessed several attacks exploiting exactly these weaknesses.
One example involved the compromise of the Trivy security scanning ecosystem, where weaknesses surrounding GitHub Actions contributed to security-conscious organisations unknowingly exposing credentials. Ironically, software intended to improve security became part of a broader supply chain compromise because attackers understood that compromising CI/CD infrastructure delivers access far beyond compromising an individual workstation.
The broader lesson is that software supply chains increasingly represent the shortest path into enterprise production environments.
Attackers understand that compromising the delivery pipeline allows them to compromise everything downstream.
CIO&Leader: How can organisations prevent AI agents from being manipulated into executing malicious actions or leaking sensitive credentials?
Dan Lorenc: Prompt injection remains one of the biggest unsolved problems in AI security. The industry has developed techniques that reduce the likelihood of successful prompt injection, but nobody has discovered a universal defence that eliminates the problem altogether.
Because of that, organisations need to change their assumptions.
Any AI agent interacting with untrusted external information should itself be treated as operating in an untrusted environment. You have to assume that, at some point, an attacker may successfully influence that agent’s behaviour.
The practical defence therefore isn’t trying to eliminate prompt injection completely—it’s limiting what the agent is capable of doing if prompt injection succeeds.
That comes down to permissions. If an AI agent never receives privileged credentials, it cannot leak them. If an agent only receives narrowly scoped permissions based on least-privilege principles, then even a successful compromise results in limited damage.
In other words, the safest approach isn’t trusting the intelligence of the model—it’s carefully constraining the authority the model possesses.
CIO&Leader: Security has traditionally been viewed as a cost centre rather than a revenue driver. With Chainguard Factory 2.0 introducing agentic reconciliation bots that continuously patch open-source drift, how does this fundamentally change the economics of enterprise security?
Dan Lorenc: Security has always been viewed as a cost centre because, fundamentally, it doesn’t generate revenue. Security only exists because there are malicious actors trying to compromise systems. If we lived in a world without attackers, organisations wouldn’t need to invest heavily in cybersecurity, just as people wouldn’t need locks on their doors.
That’s why boards typically evaluate security in terms of risk reduction rather than business growth. Every security investment is essentially weighed against the financial and reputational impact of a potential breach. In many ways, security functions like an insurance policy—you invest enough to reduce the likelihood and impact of catastrophic events.
The challenge is that traditional security doesn’t scale very well. If organisations continued relying solely on manual reviews, periodic vulnerability assessments and point-in-time scanning, security spending would eventually consume an unsustainable proportion of enterprise IT budgets while attackers continued becoming more sophisticated.
Technologies such as AI fundamentally change that equation.
Instead of reducing risk incrementally, AI enables organisations to eliminate entire classes of repetitive security work. If historically every dollar invested reduced organisational risk by one per cent, autonomous security systems can potentially improve that return several times over because they’re capable of continuously monitoring software, identifying vulnerabilities, validating changes and applying remediation without waiting for human intervention.
That’s ultimately what we’re trying to achieve with Factory 2.0. Rather than simply making existing security teams work harder, we’re changing the economics of security itself. Organisations can continuously reduce risk without requiring security spending to grow proportionately with software complexity.
As software ecosystems continue expanding, that’s the only sustainable way to keep pace with increasingly capable threat actors.
CIO&Leader: When you compare organisations across different geographies, how do you assess the cybersecurity maturity of Indian enterprises?
Dan Lorenc: From what we’ve observed, geography isn’t actually the biggest differentiator. The more meaningful variables are enterprise maturity, company size and the industries organisations operate within.
Small digital-native startups tend to look remarkably similar regardless of whether they’re based in India, Europe or North America. They naturally prioritise speed and product development first, with security becoming a larger investment as they mature.
On the other hand, organisations serving regulated industries—whether financial services, healthcare or critical infrastructure—typically invest in security much earlier because regulatory expectations and customer requirements demand it.
So rather than thinking about security maturity geographically, I think it’s much more useful to think about organisational maturity.
CIO&Leader: When you speak with CISOs, particularly in India, what concerns are dominating those conversations today? What advice would you offer organisations preparing for the next phase of AI-driven software engineering?
Dan Lorenc: The biggest uncertainty keeping many CISOs awake today isn’t necessarily today’s AI—it’s the next generation of AI.
Everyone is watching the rapid evolution of autonomous coding agents and trying to understand what those capabilities will mean once they become broadly available across enterprise software development.
Many organisations don’t yet have access to the newest generation of AI systems, but they’re already asking how they should prepare before those capabilities become mainstream.
That’s the right question to ask.
My advice is not to wait until autonomous software engineering becomes ubiquitous before strengthening your security foundations.
Organisations should focus first on building robust software supply chain practices, understanding every dependency they rely upon, improving software provenance, strengthening CI/CD security, and establishing reliable policy enforcement throughout the development lifecycle.
Those capabilities remain valuable regardless of how AI evolves.
When more capable autonomous agents eventually become widely available, organisations with strong software supply chain foundations will be able to adopt those technologies much more confidently than organisations still trying to understand what software they’re actually running.
Ultimately, AI will continue accelerating software development, but that acceleration must be matched by equally sophisticated systems for verification, trust and governance.
The future of software engineering won’t be defined by how quickly organisations can generate code. It will be defined by how effectively they can prove that every line of software entering production deserves to be trusted.