From Trust to Verification: Rethinking Software Security

by Vijendra Katiyar, Co-Founder and Chief Revenue Officer, CleanStart

We Trust More Than We Verify
Modern software development is built on layers of assumptions. Developers assume the open-source package they download is legitimate, that a container image is safe because it comes from a well-known registry, that a dependency has not been tampered with, and that the software artifact moving through the CI/CD pipeline is the same artifact that eventually reaches production.

But today’s applications are rarely built entirely from code an organization owns or controls. They are assembled from open-source packages, transitive dependencies, third-party libraries, container base images, build tools, CI/CD components, external APIs, pre-built software artifacts, and increasingly, AI-generated code and dependencies. Each layer introduces another point at which trust is inherited rather than established.

The problem is not simply that modern software has become more complex. Organizations often assume the components they rely on are trustworthy without having the visibility or mechanisms to verify them. Software security has traditionally focused on identifying what is known to be vulnerable. That remains important, but vulnerability status alone cannot establish trust. Software can have no known CVEs and still have an unknown origin, an unverifiable build process, or components that cannot be accounted for.

As software becomes more distributed, automated, and increasingly AI-driven, trust can no longer be based primarily on where software came from or the reputation of the system that delivered it. It needs to be grounded in evidence that can be examined, verified, and carried with the software throughout its lifecycle.

Source Reputation Is Not the Same Thing as Verifiable Trust
In software development, “trusted source” has increasingly become a shortcut for “trusted software.” A package came from GitHub, so it must be safe. A container image came from an official registry, so it must be secure. A dependency passed a vulnerability scan, so it must be acceptable. Code was generated by an enterprise AI tool, so its underlying components must be reliable.

But these assumptions confuse reputation with verification. The industry has become comfortable using reputation as a proxy for trust. A trusted platform does not guarantee that every package hosted on it is legitimate, that every dependency is uncompromised, or that an artifact has remained unchanged throughout its journey into production. Reputation tells us why we might trust a source. It does not prove the software itself.

A legitimate source can distribute a compromised package. An authorized contributor can unknowingly introduce a malicious dependency. A trusted build system can produce an artifact that contains an unsafe component. By the time software reaches production, knowing where it came from is only one part of understanding whether it can be trusted.

The question organizations should be asking is no longer simply, “Where did this software come from?” It is also, “Can we prove what it is, what went into it, how it was built, and that it has not been altered?”

Provenance, software bills of materials, cryptographic signatures, reproducible builds, and continuous verification can provide that evidence and make trust something that can be established rather than assumed.

A trusted source may be a useful starting point. It cannot be the endpoint of trust.

AI Is Accelerating the Trust Problem
AI is fundamentally changing the economics of software development. Code that once took hours or days to write can now be generated in minutes, along with recommendations for libraries, packages, frameworks, and dependencies. This creates enormous productivity gains, but it also changes the scale at which organizations consume and assemble software.

The challenge is that AI accelerates creation far more easily than verification. A developer can ask an AI coding assistant to generate a feature and receive not only the code, but also recommendations for the libraries and packages needed to implement it. Those dependencies can quickly become part of an application without the same level of scrutiny that a developer might apply manually.

This creates a growing gap between the speed at which software can be created and the speed at which organizations can establish confidence in what they are deploying. The issue is not that AI-generated code is inherently unsafe. AI is not creating an entirely new software supply-chain trust problem. It is scaling an existing one.

It removes much of the friction that once limited how quickly software could be created and assembled, while the mechanisms used to verify that software have not evolved at the same pace. In an AI-driven development environment, organizations need to ask not only whether AI can help developers build faster, but whether their ability to verify software can operate at the same speed. Verification needs to become faster, more automated, and more deeply integrated into the software supply chain itself.

India’s Software Supply Chain Is Growing Up
India is not just consuming the software supply chain. It is helping build it.

India is home to one of the world’s largest technology-services ecosystems, a rapidly expanding GCC landscape, major banks and fintechs, and a growing software and SaaS industry. These organizations are simultaneously consumers, builders, integrators, and distributors of software, relying on open-source components and third-party software while producing applications and software artifacts consumed around the world.

Recent supply-chain incidents make the implications clear. Attackers have increasingly abused legitimate credentials, trusted contributors, package repositories, CI/CD workflows, and publishing mechanisms to introduce malicious software through systems that continue to function as designed.

The problem is not always that the trusted system failed. Sometimes the problem is that we trusted the system to tell us whether the software was trustworthy.

Indian enterprises are already confronting this challenge in practice. IIFL, for example, found that its existing scanning tools could identify vulnerabilities but could not verify how its container images were assembled or whether workloads followed a consistent baseline. It addressed the issue at the foundation layer by standardizing on CleanStart images, verifying included dependencies, and generating SBOMs and provenance data.

This represents a broader shift in how software security needs to work. Rather than waiting for vulnerabilities to surface after software enters the environment, organizations can establish stronger assurance in the software foundations they use before those foundations become part of production.

For Indian organizations operating at this scale, software supply-chain security needs to become part of how software is sourced, built, verified, and governed from the beginning.

Trust Needs a Chain, Not a Checkbox
Security cannot be reduced to a single scan, approval, or compliance checkbox somewhere in the software development lifecycle. In a modern software environment, trust needs to be established and maintained as software moves from source to dependencies, from build to artifact, from registry to deployment, and ultimately into runtime. Each stage presents an opportunity for something to be introduced, modified, or overlooked.

Organizations therefore need a continuous chain of evidence that allows them to understand where software came from, what went into it, how it was built, and whether it has changed along the way. This evidence needs to travel with the software rather than remain isolated in a security tool or development system. Provenance can establish how an artifact was produced. An SBOM can provide visibility into its components. Cryptographic signatures can help establish integrity and authenticity. Reproducible builds can provide greater confidence that the artifact corresponds to its source.

These mechanisms become particularly important as development becomes increasingly automated and AI-driven. When software is created, assembled, and delivered at machine speed, organizations cannot depend on manual review to establish trust at every stage. Verification needs to be part of the software lifecycle itself.

The objective is not simply to scan more software or add more approvals. It is to create a chain of evidence that allows each organization consuming the software to verify the claims made about it.

Trust should be an attribute of the software, not an assumption made about it.

From Securing Software to Building Verifiable Software
Security has traditionally focused on identifying and managing risk after software has been assembled. But if the foundation beneath an application already contains vulnerable dependencies, unnecessary components, or software whose provenance cannot be verified, organizations are starting from a position of assumed risk. By the time those risks are discovered, the software may already be embedded across applications, environments, and production systems.

The answer is not to eliminate trust. Trust is essential to how modern software ecosystems function. The answer is to change the basis on which trust is established.

That means building on cleaner software foundations, verified libraries, hardened container images, signed artifacts, and verifiable provenance, so that security is not something added after software is assembled but something established as the software moves through its lifecycle.

Visibility tells us what exists. Vulnerability scanning tells us what is known to be wrong.

Compliance controls tell us whether certain requirements have been met. But verifiable trust goes further. It provides evidence that software is what it claims to be, that its components can be accounted for, that its origins are known, and that its integrity has been maintained.
This is more than a change in security practice. It is a change in how we define trust in software.

That shift becomes even more important as software development becomes faster, more distributed, and increasingly AI-driven. Organizations cannot rely on reputation, periodic scans, or manual approvals to keep pace with the volume of software being created and consumed. Verification needs to operate at the same speed as development and become an integral part of the software supply chain.

The future of software security will not be defined by how much we trust the systems that deliver software. It will be defined by how confidently we can verify the software itself.

Trust should not be something we assume. It should be something software can prove.