Javed Hasan is the CEO and Co-founder of Lineaje, a leader in software supply chain security management.
For decades, security teams have relied on a reactive, linear model: detect, respond, investigate, remediate and move on. In this legacy framework, the primary objective is forensic—understanding and patching a failure after it’s already occurred.
While this post-incident model was sufficient when organizations built the software they operated and had greater visibility into its creation, it’s increasingly incompatible with modern engineering. Today, the ubiquity of third-party dependencies, decentralized architectures and rapid-fire deployment pipelines has created significant visibility gaps.
AI is shipping code faster than organizations can govern it. Without real-time visibility into the origin, intent and lineage of AI-generated dependencies, AppSec is operating completely blind.
Our research found that over 70% of application code in modern enterprises originates outside direct corporate control, a dependency rapidly amplified by AI-assisted development. While vulnerability management has scaled, the enterprise attack surface has scaled with it. The operating standard must extend beyond visibility and continuously eliminate vulnerabilities, novel vulnerabilities and embedded code threats before they become enterprise exposure.
Why do traditional security models fall short?
Many organizations assume they secure what they build. In reality, they’re securing what they inherit. By the time software reaches production, it may already carry hidden dependencies, outdated libraries, or vulnerabilities introduced upstream or malicious code embedded inside otherwise trusted components.
Security teams have largely focused on areas where software runs, such as hardened environments, zero-trust architectures and air-gapped systems. However, software is assembled elsewhere, from public repositories, third-party dependencies and AI-generated code. Software creation now moves faster than most organizations can verify origin, lineage and security posture.
Attackers understand this. Compromising a dependency or development tool is easier and more scalable than attacking a well-defended production system. Once introduced, those weaknesses are carried into otherwise secure environments.
Over the last two years, AI-assisted development has exposed the limits of traditional AppSec. Code creation has accelerated, but security review velocity hasn’t. Organizations now have more code to review, more dependencies to validate and less visibility into how software was created.
Policy lit the spark, but implementation must now catch up.
Federal policy has helped bring software supply chain risk into sharper focus. U.S. government initiatives, particularly the push for software bills of materials (SBOMs), have established transparency as a baseline expectation for software suppliers. CISA has introduced risk-based remediation timelines that can require federal agencies to address certain high-risk vulnerabilities within three days. This reflects a broader reality: The window between disclosure and exploitation is shrinking.
While that progress is positive, policy alone isn’t enough. In practice, many SBOMs are still treated as compliance artifacts. An SBOM that lists 1,200 components is an inventory record. An SBOM that shows exposure, exploitability, provenance and remediation priority becomes operational intelligence.
Operational intelligence still isn’t elimination. Organizations need continuous validation and remediation as software changes, particularly as AI-assisted development increases the volume of code entering enterprise environments.
Organizations must move from forensics to prevention.
Preventing software supply chain risk requires an operating model that continuously eliminates vulnerabilities, novel vulnerabilities and embedded code threats before they reach production.
Organizations need to spend more time understanding software before it enters production. That means moving beyond surface-level inventories to deeper transparency. Teams need visibility into software lineage, exposure and provenance, combined with the ability to continuously scan software, source secure replacements, fix exploitable weaknesses and certify what’s delivered.
This is the zero-vulnerability operating standard: continuously discover and eliminate exploitable vulnerabilities as software changes rather than allowing security teams to manage an ever-growing remediation backlog. When done correctly, developers should review fixes in the workflows they already use rather than becoming owners of another security ticket queue.
For AI-enabled and agentic applications, prevention also requires policy governance. Teams need to define which agents are approved, which tools they may use, what data they may access and which actions require control before execution.
The goal isn’t to assign blame or malicious intent but to understand origin, quality and integrity before software becomes enterprise risk.
Prevention starts before software’s deployed.
Open source itself isn’t the problem. Unknown or unverified open source is the problem. The industry needs to move toward a standard where components are continuously evaluated, traceable to their origins and vetted before they enter a build. AI-generated and AI-assisted code must meet the same standard.
For organizations that buy more software than they build, prevention begins during acquisition. SBOMs should be the first question, not the last. Procurement teams should ask vendors:
• Can you produce an SBOM on demand?
• Can you trace every component to its source?
• Has the software been evaluated against CISA’s KEV catalog?
• What percentage of the codebase is AI-generated?
• Can you provide provenance and attestation for the software you deliver?
These requirements establish a chain of trust across software that organizations source, build, buy and deploy. Without that chain, security teams are left reconstructing risk after software has already entered the enterprise.
The reality is that post-breach forensics will remain necessary, but it can’t remain the primary operating model for software supply chain security. Organizations need continuous visibility into what enters their software, governance over how it’s created and acquired, and continuous elimination of exploitable risk across the SDLC. That’s the operating standard required when software creation moves faster than traditional AppSec can review it.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?