OWASP has just released the 2025 Top 10, and there's a significant shift that security leaders need to be aware of: Software Supply Chain Failures is now A03, sitting firmly in the top three risks. The OWASP community survey revealed that 50% of respondents ranked Software Supply Chain as their number one concern—and for good reason.
The 2025 definition represents more than incremental guidance. Where the 2021 Top 10 focused on "Vulnerable and Outdated Components," the 2025 update expands to comprehensive "Software Supply Chain Failures." This new scope covers breakdowns and compromises across the entire lifecycle of building, distributing, and updating software—from third-party libraries and CI/CD pipelines to IDEs, IDE extensions, artifact repositories, and SBOM management.
For AppSec leaders and CISOs, this isn't just expanded guidance. It's OWASP acknowledging where software is actually written and how it's being compromised. The question is how to operationalize A03 in practice.
What Changed: The 2025 Definition Matters
The statistics tell part of the story. Software Supply Chain Failures has the highest average incidence rate in the Top 10 at 5.19%, yet only 11 CVEs are mapped to the related CWEs. This highlights a crucial point: most supply chain failures aren't traditional vulnerabilities tracked in public databases. They're systemic breakdowns in how we build, distribute, and secure software.
The 2025 definition explicitly expands the attack surface to include components that traditional security programs often overlook:
- Developer workstations now require hardening equivalent to production systems—including MFA enforcement, regular patching, and continuous monitoring.
- IDEs and IDE extensions require tracking and governance, acknowledging that developers' tools are part of the supply chain.
- AI coding assistants are recognized as a new attack vector, generating code that may introduce vulnerabilities before any security review occurs.
- And critically, all development tooling—not just CI/CD pipelines—falls within the security perimeter.
This philosophical shift matters because it changes where the security boundary exists. The traditional perimeter ended at the repository and CI/CD pipeline. The 2025 reality acknowledges that the supply chain starts at the developer workstation, where most code is actually written.
The Real-World Validation: GlassWorm
OWASP doesn't just theorize about these risks—it cites real attacks. Scenario #3 in the 2025 guidance describes the GlassWorm attack on the VS Code Marketplace, where malicious actors implemented invisible, self-replicating code into legitimate extensions. The malware auto-updated onto developer machines, immediately harvesting local secrets, attempting to establish command and control, and emptying developers' crypto wallets when possible.
The GlassWorm attack was extremely advanced, fast-spreading, and damaging. By targeting developer machines directly, it demonstrated that developers themselves are now prime targets for supply chain attacks. This pattern has repeated: the Bybit $1.5 billion theft occurred through a supply chain attack in wallet software, and the PhantomRaven campaign compromised 126 npm packages targeting development environments.
The key insight: Attackers aren't just targeting production systems anymore. They're targeting the people and tools that create those systems, exploiting the gap between where code is written and where security controls typically exist.
For CISOs, this creates an uncomfortable question: Can you enumerate what's installed on your developers' machines right now? For most organizations, the answer is no.
AI Assistants: Supply Chain Components That Write Code
OWASP 2025 includes a specific vulnerability criterion: "If developers are allowed to download and use components from untrusted sources, for use in production." This takes on new meaning when AI coding assistants—used by 91% of development teams—are recommending packages to developers based on training data that's 3-6 months old at minimum.
The mechanism creates systematic risk. AI training data represents what was common in historical code, not what is secure today. When a developer asks an AI assistant to implement JWT authentication, the AI might suggest importing PyJWT version 1.7.1 because that version appeared frequently in its training data. But PyJWT 1.7.1 contains a critical CVE that allows authentication bypass. The correct recommendation is PyJWT 2.8.0 with secure implementation patterns.
This happens at scale. One bad AI recommendation multiplied by 500 developers equals systematic exposure across your codebase. And because AI generates code before any security review, these vulnerabilities exist in development environments long before they reach CI/CD scanners.
AI Agents as First-Class Supply Chain Components
The risk extends beyond code suggestions. AI agents now autonomously install and execute packages, make architectural decisions, and wire together open-source components. Their non-deterministic behavior and potential for dramatic impact deserve special attention.
Organizations need to treat AI agents as first-class supply chain components, which means:
- Tracking agent actions and package installations
- Applying governance policies to agent behavior
- Maintaining audit trails for compliance
- Establishing guardrails for autonomous execution
The technical solution emerging in the industry uses the Model Context Protocol (MCP) to provide real-time security context to AI systems. MCP injects current vulnerability data, malicious package intelligence, and security best practices into AI responses. This works with tools like Cursor, Windsurf, GitHub Copilot, and Claude, making AI assistants security-aware at the point of code generation rather than relying on detection after deployment.
For security leaders, the implication is clear: If you're adopting AI coding assistants without security controls, you're systematically introducing vulnerabilities faster than your security team can remediate them.
The Malicious Package Threat: Scale and Sophistication
While vulnerable packages receive significant attention, malicious packages represent a distinct and accelerating threat that OWASP 2025 explicitly addresses. The numbers tell a concerning story: 512,847 malicious packages were detected in 2024 alone, representing a 156% year-over-year increase. For context, this means more than 1,400 new malicious packages are being published every single day.
These aren't random attacks. Malicious actors have developed sophisticated, repeatable techniques specifically designed to exploit how developers install packages. Understanding these attack patterns is critical for security leaders building defense strategies.
Typosquatting: Exploiting Human Error at Scale
Typosquatting attacks exploit the simple reality that developers make typos. An attacker publishes a package with a name that's one character different from a popular legitimate package. When a developer types pip install tensroflow instead of tensorflow, they unknowingly install malware that executes immediately.
The technique is devastatingly effective because it requires no sophistication on the target side—just a single keystroke error. Popular packages like requests, urllib3, pandas, and numpy have dozens of typosquat variants actively maintained by attackers. These malicious packages often include the legitimate package's functionality to avoid immediate detection, while silently exfiltrating credentials, environment variables, or establishing backdoors.
Dependency Confusion: Attacking Private Package Names
Dependency confusion exploits how package managers resolve names when both public and private repositories are configured. Organizations typically maintain private packages with internal names like company-auth-lib or internal-api-client. Package managers, by default, prefer the highest version number when a package name exists in multiple sources.
Attackers scan for private package names in public repositories, error messages, or leaked configuration files, then publish public packages with those exact names but artificially high version numbers. When developers run standard installation commands, the package manager pulls the public malicious version instead of the private legitimate one. This attack has resulted in significant bug bounties, with researchers demonstrating compromise potential across multiple Fortune 500 companies.
Compromised Legitimate Packages: The Trust Exploitation
Perhaps most concerning are attacks on legitimate, trusted packages. Attackers compromise maintainer accounts, exploit CI/CD pipelines, or leverage social engineering to inject malicious code into packages with millions of weekly downloads. Once compromised, the trusted package becomes a distribution mechanism for malware across thousands of organizations.
Recent examples include packages with 16 million weekly downloads being compromised to exfiltrate cryptocurrency wallet credentials, authentication tokens being harvested through compromised logging libraries, and backdoors being inserted into developer tools that provided persistent access to corporate networks.
The sophistication of these attacks continues to evolve. Modern malicious packages often include:
- Conditional execution that only triggers in specific environments to avoid detection
- Time-delayed activation that waits days or weeks before executing malicious payloads
- Anti-analysis techniques that detect and evade security scanning tools
- Legitimate functionality that masks malicious behavior during manual review
- Polymorphic code that changes signatures to evade static analysis
Why Traditional Scanning Fails Against Malicious Packages
Traditional security tools are designed to find known vulnerabilities in known packages. They excel at identifying CVE-2024-12345 in requests 2.28.0. But they fail completely against malicious packages because:
No CVE Exists: Malicious packages aren't vulnerabilities in legitimate software—they're purpose-built attack tools. They'll never appear in vulnerability databases because they were malicious from the moment of creation.
Batch Scanning Happens Too Late: Traditional SCA tools scan code after it reaches repositories. But malicious packages execute the moment they're installed during development. By the time the code reaches your scanner, the attacker has already harvested credentials, established persistence, and potentially moved laterally.
No Signature Database: Unlike antivirus tools that maintain signature databases of known malware, traditional SCA tools have no equivalent database of known malicious packages. They're blind to the threat entirely.
Installation-Time Execution: Package installation scripts run arbitrary code on the developer's machine with the developer's permissions. A malicious package can compromise the entire machine in milliseconds—long before any security scan occurs.
The Architecture Required for Malicious Package Protection
Defending against malicious packages requires fundamentally different architecture than vulnerability scanning. Organizations need:
Real-Time Threat Intelligence: Continuously updated databases of known malicious packages, typosquat variants, and dependency confusion attempts. This intelligence must include packages identified through multiple techniques: static analysis, dynamic analysis, behavioral analysis, and community reporting.
Install-Time Interception: The security check must happen before package installation completes—at the exact moment when the developer runs pip install. This requires integration at the package manager level, not at the repository scanning level.
Behavioral Analysis Capability: Beyond signature matching, the system must analyze package behavior for malicious patterns: unexpected network connections, file system access, credential harvesting attempts, and execution of obfuscated code.
Comprehensive Coverage: Protection must extend across all package managers (pip, conda, poetry, uv, npm, etc.), all development environments (local machines, cloud workstations, containers), and all installation paths (direct installs, dependency resolution, automated builds).
Silent Operation: Developers shouldn't need to become security experts. Protection should operate transparently, blocking malicious packages while allowing legitimate development work to proceed without friction.
The threat landscape has fundamentally shifted. Malicious packages now represent a higher-probability risk than vulnerability exploitation for many organizations. Security architectures must adapt accordingly.
Operationalizing A03: What OWASP Requires
OWASP 2025 provides specific prevention guidance. For security leaders trying to operationalize these requirements, the challenge is translating guidance into practical implementation. Here's what OWASP mandates and what it takes to actually deliver it.
Know Your SBOM Centrally
OWASP requires organizations to maintain a centrally managed Software Bill of Materials dictionary, track both direct and transitive dependencies, and continuously inventory versions across all environments.
The implementation gap is significant. Traditional SCA tools only scan code in repositories. But data scientists work in Jupyter notebooks for months before committing anything. Developers write local scripts and experiments that never reach version control. AI assistants generate code that may never be formally reviewed. In most organizations, 60-80% of actual Python usage never reaches repositories—and therefore never gets an SBOM.
Organizations addressing this requirement are deploying agents to developer machines that automatically inventory all package installations, generate SBOMs for local development contexts, and maintain complete audit trails. The goal is instant search capability: "Show me all machines with Log4j 2.14" returns results in seconds, not days.
This isn't theoretical. When the next Log4j-style incident occurs, the difference between minutes and weeks in damage assessment is the difference between contained incident and catastrophic breach.
Only Obtain Components from Official Sources
OWASP requires verified packages from trusted sources, preferably signed, with verification before installation. The challenge: malicious packages reach package repositories before detection through typosquatting, dependency confusion, and compromised legitimate packages.
Traditional security architecture has no verification at install-time on developer machines. Malicious packages reach systems and execute before any security tool sees them.
Organizations implementing this requirement are moving to firewall-first architectures that intercept package installations in real-time, check against comprehensive malicious package databases, and block threats before they reach the system. This protection works across all package managers—pip, conda, poetry, uv, npm—and operates transparently to developers, providing silent protection.
The architecture shift is from batch scanning after code exists to real-time blocking before malicious code executes.
Harden and Monitor Developer Workstations
OWASP requires developer machines to have security controls equivalent to production systems: regular patching, MFA enforcement, monitoring capabilities, and documented change tracking.
The traditional implementation gap exists because developer machines are often excluded from security controls under the assumption that "developers need to move fast" and "repository scanning is sufficient." Data science and analyst machines are frequently completely unmanaged.
What's actually needed is security controls that don't disrupt workflows—visibility without friction, protection that developers don't need to think about, central security team visibility without per-developer overhead.
Organizations successfully hardening developer environments use lightweight agents with minimal performance impact, policy enforcement that's invisible until it blocks threats, central dashboards for security teams with zero UI for developers, and complete audit trails without requiring manual reports.
Track Supply Chain Changes
OWASP requires change tracking for CI/CD settings, code repositories, developer IDEs and extensions, SBOM tooling, and artifact repositories. The implementation challenge: developer environment changes typically go unmonitored, IDE extension installations are untracked, and there's no correlation between local changes and security incidents.
The capability required is comprehensive logging of all package installations with timestamp, user, machine, and version tracking, integration with SIEM and security monitoring platforms, and fast incident response—the ability to search "what was installed where and when" in minutes.
Continuous Vulnerability Monitoring
OWASP requires regular vulnerability scanning and automated monitoring. The traditional approach—scanning only repositories—misses the local development code that doesn't get committed until weeks or months later, and creates overwhelming alert fatigue by flagging 100% of CVEs without prioritization.
The Data Science and Local Development Imperative
Data science teams represent the highest-risk, least-protected development environments in most organizations. They handle the most sensitive data—PII, financial information, research IP. They work primarily in local notebooks and scripts that rarely get committed to repositories. They're heavy Python users with minimal security oversight. And they're often explicitly excluded from existing security controls.
When auditors ask about data science environments, most organizations struggle to answer basic questions. "Show us your SBOM for data science work"—there isn't one, because the work never reached repositories. "How do you prevent vulnerable packages in data science environments?"—assumptions and trust. "What's your incident response time for Log4j-style vulnerabilities?"—days or weeks to even identify affected machines. "How do you demonstrate compliance with data handling regulations?"—hope.
The board-level risk is clear. The average data breach costs $4.2 million according to IBM's 2024 study. Data science teams handle precisely the data that drives this cost. One compromised notebook with production database credentials creates breach potential that traditional security controls never see.
OWASP A03 demands specific capabilities for these environments: package inventory across all analyst machines, vulnerability scanning for local notebooks and scripts, malicious package protection at the point of installation, audit trails that work without disrupting workflows, and SBOM generation for work that never reaches version control.
The architecture required must operate silently—data scientists aren't security experts and shouldn't need to be. Protection must happen at install-time, before malicious code executes. Security teams need central visibility without creating friction for every data scientist. And the solution must integrate with Jupyter notebooks, IDEs, and data science tools without requiring workflow changes.
How Safety Addresses OWASP A03 Requirements
For organizations ready to operationalize OWASP A03 guidance, Safety provides a comprehensive platform specifically designed to secure the Python software supply chain across the expanded attack surface that OWASP now mandates.
Total Visibility Across All Python Environments
Safety delivers the centralized SBOM capability that OWASP requires by turning unmanaged Python tool sprawl into something observable and governable. The platform provides:
Continuous Inventory: Every Python package installation across workstations, notebooks, scripts, containers, and CI/CD environments is automatically tracked and inventoried. This includes packages that never reach version control—addressing the 60-80% of Python usage that traditional tools miss entirely.
Comprehensive Tracking: Safety monitors not just packages, but the entire supply chain ecosystem OWASP identifies: IDEs and IDE extensions, notebook environments, MCP tool usage, AI assistant integrations, and AI agent execution. Each component is logged with user, machine, environment, and timestamp data.
Instant Search Capability: For incident response, Safety provides the "what is our exposure to X?" capability that OWASP's guidance implicitly requires. Security teams can identify all machines with a specific package version in seconds—critical for Log4j-style incidents where time to assessment determines breach scope.
Real-Time Protection via Firewall Architecture
Safety's firewall-first architecture addresses OWASP's requirement to verify packages before installation by intercepting package installations at the moment they occur:
Install-Time Blocking: Safety's Firewall intercepts every package installation—whether from pip, poetry, uv, conda, or other package managers—and screens against comprehensive threat intelligence before allowing installation to proceed. Malicious packages are blocked before they execute, not detected after compromise.
Malicious Package Intelligence: The platform maintains proprietary threat intelligence covering typosquatting variants, dependency confusion attempts, compromised legitimate packages, and behavioral indicators of malicious intent. This database is updated continuously as new threats emerge.
Silent Operation: Protection works transparently to developers. There's no new tooling to learn, no workflow changes required, and no security friction until an actual threat is blocked. Development proceeds normally; security operates invisibly.
Securing AI Assistants as Supply Chain Components
Recognizing that AI agents represent first-class supply chain components—as OWASP 2025 now acknowledges—Safety provides specialized capabilities for AI governance:
MCP Integration: Safety integrates with AI coding assistants via the Model Context Protocol, providing real-time security context to tools like Cursor, Windsurf, GitHub Copilot, and Claude. When AI assistants recommend packages, they receive current vulnerability intelligence and malicious package data, preventing the systematic introduction of vulnerabilities that outdated training data would otherwise cause.
AI Agent Governance: When AI agents autonomously install, run, or wire together open-source packages, they do so within the same governance framework that applies to human developers. Safety tracks agent actions, applies policies to autonomous execution, and maintains audit trails for compliance purposes.
Guardrails for Non-Deterministic Behavior: Given AI agents' non-deterministic behavior and potential for dramatic impact, Safety enforces policies that prevent agents from installing known-malicious packages, using vulnerable versions, or violating organizational governance rules—all without requiring agents to become security-aware themselves.
Comprehensive Audit and Compliance Framework
For AppSec and IT teams, Safety serves as a single source of truth for Python supply chain security—the centralized visibility and control that OWASP requires:
Complete Audit Trail: Every package installation is logged with complete context: what was installed, by whom, on which machine, in which environment, at what timestamp, and through which installation path. This audit trail supports both compliance requirements and incident response.
Policy Enforcement Without Workflow Changes: Safety secures and governs existing package managers—pip, poetry, uv, conda—without requiring teams to adopt new tooling or modify workflows. Policies enforce silently in the background across all tools simultaneously, ensuring consistent governance.
SBOM for All Code: Unlike traditional tools that only scan repositories, Safety generates SBOMs for all Python usage: local development, notebooks, scripts, AI-generated code, and experimental work that may never be committed. This addresses OWASP's requirement for comprehensive dependency tracking.
Instant Damage Assessment: When security incidents occur, Safety enables immediate response with questions like "which machines have this package?" and "who installed this version?" answered in seconds rather than days. This capability is critical for containing supply chain compromises before they escalate.
Protecting Data Science Environments
For the highest-risk, least-protected environments in most organizations, Safety provides specialized capabilities:
Silent Protection: Data scientists continue working in Jupyter notebooks, VS Code, PyCharm, and other familiar tools with zero workflow changes. Protection operates invisibly until a malicious package is blocked or a vulnerable dependency is detected.
Local Development Coverage: Every package installation on data scientist machines is protected and audited, whether the code ever reaches version control or not. This addresses the fundamental gap where 60-80% of data science work occurs outside traditional security controls.
Governance Without Friction: Central security teams gain complete visibility and policy enforcement capability without creating per-analyst overhead. Data scientists don't become security experts; security becomes automatic in their existing workflows.
Safety's architecture recognizes the fundamental truth that OWASP 2025 makes explicit: if you don't understand and continuously control your software supply chain across all environments where code is written, you're not really doing application security. The platform operationalizes this principle across the expanded attack surface that OWASP now defines.
Building Your Implementation Roadmap
For security leaders translating OWASP guidance into action, start with honest assessment. Can you enumerate all packages installed on developer machines today? Do you have SBOM coverage for code that never reaches repositories? How long would it take to identify all systems with a specific package version? Are data science teams included in your supply chain security program? Do you track IDE extensions? Can you block malicious packages before they execute? How are AI coding assistants secured?
Map your current capabilities against OWASP requirements: developer workstation hardening, IDE and extension tracking, AI assistant governance, local development visibility, real-time protection capability, and comprehensive SBOM coverage. Most organizations find significant gaps.
Phased Implementation
Phase 1: Visibility (30 days)—Deploy agents to developer machines to establish baseline inventory. Identify gaps in current coverage, document AI assistant adoption across teams, and map all supply chain components. You can't protect what you can't see.
Phase 2: Protection (60 days)—Implement real-time package protection with malicious package blocking at installation. Establish policy framework for supply chain security, create incident response procedures for supply chain attacks, and pilot with high-risk teams like data science. Start with visibility-only mode to build confidence, then enable blocking.
Phase 3: Governance (90 days)—Full deployment across the organization, AI assistant security integration via MCP, comprehensive audit framework for compliance, and continuous monitoring with optimization.
The Business Case
The risk quantification is straightforward. Average supply chain breach cost is $4.2 million. Unprotected developer environments represent high-probability attack vectors, as GlassWorm and similar incidents demonstrate. Data science teams present the highest risk with the least protection. And regulatory penalties for non-compliance continue to increase.
The investment reality is equally clear. Prevention costs 10-100× less than breach response and recovery. Compliance efficiency improves dramatically—organizations report reducing audit preparation from days to hours. Developer productivity is preserved because solutions that work silently don't disrupt workflows. And demonstrating security leadership creates competitive advantage.
For board and auditor purposes, organizations need to demonstrate five capabilities: Awareness (we know what's installed across development environments), Prevention (we block malicious and non-compliant packages before installation), Detection (we continuously scan all code, including local development), Response (we can identify affected systems in minutes, not weeks), and Governance (we enforce policies consistently across all environments).
The documentation required includes supply chain security policy explicitly aligned with OWASP A03, risk assessment covering developer environments, incident response procedures for supply chain attacks, audit trail demonstrating continuous monitoring, and compliance reports showing comprehensive SBOM coverage.
Operationalizing A03 in Practice
OWASP's expansion of Software Supply Chain Failures to A03, with explicit inclusion of developer workstations, IDEs, and AI assistants, represents recognition of where modern software is actually written and how it's being compromised. The shift from "Vulnerable and Outdated Components" to comprehensive "Supply Chain Failures" acknowledges a fundamental truth: you can't secure what you can't see. And for most organizations, 60-80% of development work happens in environments with zero visibility and protection.
GlassWorm and similar attacks prove that attackers have already adapted to this reality. They're targeting developers directly, compromising the tools developers trust, and exploiting the gap between where code is written and where security controls exist.
For security leaders, the question isn't whether to expand supply chain security to developer environments—OWASP has made that requirement explicit. The question is whether you'll implement it proactively, on your terms, with manageable disruption, or reactively after an incident when costs are exponentially higher and options are limited.
The practical path forward starts with visibility. Deploy capability to see what's actually installed across your development environments. Add protection by implementing real-time blocking before malicious code executes. Build governance with policies that enforce automatically and silently. Enable incident response with instant search capabilities for damage assessment. And secure AI assistants by treating them as first-class supply chain components with appropriate controls.
If you don't understand and continuously control your software supply chain—across repositories, developer machines, data science environments, and AI assistants—you're not really doing application security. OWASP 2025 makes this explicit.
The supply chain perimeter has expanded. The question is how quickly your security architecture will expand with it.
Note: This article references OWASP Top 10 2025 Release Candidate guidance. Organizations should monitor OWASP.org for the final release and any updates to the A03 definition and prevention guidance.
