Vulnerability Intelligence Annual Report 2025
Vulnerability Intelligence Annual Report 2025
The software supply chain encompasses every component, tool, process, and person involved in building, packaging, and delivering software from the first line of code written on a developer's laptop to the final product deployed in production. This includes:
An inventory of all these components is called a Software Bill of Materials (SBOM) but more on that shortly.
The key insight for security leaders: every link in this chain is a potential entry point for attackers. And unlike attacks on the final product, supply chain attacks exploit the trust organizations place in the tools and components used during development making them far stealthier and significantly harder to detect.
The SolarWinds breach in 2020 and the Log4Shell vulnerability in 2021 were not anomalies. They were a preview.
Today, attackers understand that targeting a widely used third party component yields far greater returns than attacking a single organization's perimeter. A single compromised open source package can cascade across thousands of enterprises simultaneously all without triggering traditional security controls.
Consider this: 78% of organizations rely on open source software in their codebases. Each dependency brings its own dependency tree, meaning the actual attack surface is often orders of magnitude larger than what security teams realize.
This reality is reshaping how CISOs and Heads of AppSec think about risk. Patching a vulnerability after the fact or hardening the perimeter of the final application is no longer sufficient. The software supply chain itself is now a strategic entry point into your organization's codebase and it demands a dedicated, proactive security strategy.
To protect the supply chain, you first need to understand its components and the specific risks each one introduces.
Dependencies are external code libraries that developers pull into their projects to accelerate development. They're reused across projects and teams, which means a single vulnerability or compromised package can have a wide blast radius across your entire codebase.
Risk: A malicious or vulnerable dependency can introduce exploitable code that is difficult to trace back to its source especially when nested several layers deep in a transitive dependency tree.
Package managers like npm (JavaScript), pip (Python), Maven (Java), Gradle, NuGet (.NET), and Composer (PHP) automate the downloading, installation, and management of dependencies. They are essential productivity tools for developers and a high value target for attackers.
Risk: Package managers can be tricked into fetching malicious packages through naming manipulation or version spoofing, executing attacker controlled code directly on developer machines or in build environments.
Public registries like npmjs.com, PyPI, or Maven Central are open platforms anyone can publish a package, including attackers. Private repositories add a layer of control, but they too can be compromised or misconfigured.
Risk: Malicious packages can be uploaded directly, existing legitimate packages can be hijacked, or legitimate packages can be replaced with trojanized versions.
Platforms like GitHub, GitLab, Bitbucket, and Azure DevOps are where code lives and evolves. They are also where trust is highest and security controls are sometimes weakest.
Risk: Compromised developer credentials, exposed API tokens, or misconfigured branch protections can allow attackers to inject malicious commits that flow all the way to production.
The build stage is where source code becomes deployable artifacts. CI/CD pipelines automate this process and are a critical and often under secured part of the supply chain.
Risk: If an attacker gains access to the build environment, they can inject malicious code into compiled artifacts. For compiled languages, detecting these alterations post compilation requires reverse engineering an expensive and time consuming process.
Understanding the threat landscape in technical terms is essential for both security teams and developers. Here are the most prevalent attack patterns targeting the modern software supply chain:
Attackers compromise developer laptops, steal SCM credentials, or intercept communications to inject malicious code directly into the codebase. Attack vectors include phishing campaigns targeting developers, leaked API tokens, and man in the middle (MITM) attacks on code submission channels.
When adversaries gain access to a build system, they can alter the software artifacts produced without ever touching the source code. This is particularly dangerous in compiled language environments (C/C++, Java, Go) where reverse engineering is required to detect tampering.
Modern applications can have hundreds of indirect (transitive) dependencies. Compromising even one deeply nested package can cascade across every application that consumes it downstream. This is how attackers achieve broad impact with minimal effort.
Attackers register packages with names that closely mimic popular, trusted libraries exploiting typographical errors made by developers during installation. Examples include swapping letters, adding/removing hyphens, or misordering characters.
For cloud security teams, this is particularly insidious because the malicious package executes code on the developer's machine or in the CI/CD pipeline at install time before any traditional security scan is triggered.
In this sophisticated attack, an adversary publishes a public package with the same name as a company's internal package but with a higher version number. Package managers, configured to prefer higher versions, fetch the malicious public package instead of the intended internal one.
This attack was famously demonstrated by security researcher Alex Birsan in 2021, who used it to breach major tech companies including Microsoft, Apple, and Uber.
StarJacking and RepoJacking
One of the most important frameworks in software supply chain security is SLSA Supply chain Levels for Software Artifacts (pronounced "salsa").
SLSA provides a structured, incremental path to verifying that software artifacts are built and distributed without tampering. It focuses on three core areas:
For most organizations, starting at SLSA Level 1 or 2 delivers significant risk reduction and creates the foundation for incremental improvement. The goal isn't perfection on day one it's systematic, measurable improvement toward a more trustworthy software supply chain.
A Software Bill of Materials (SBOM) is a complete, structured inventory of every component in a software artifact including open source libraries, commercial dependencies, their versions, and licensing information.
Think of it as the ingredient list for your software. Just as food manufacturers are required to disclose what goes into their products, software producers increasingly need to disclose what goes into theirs.
The two dominant formats are CycloneDX (backed by OWASP) and SPDX (backed by the Linux Foundation). The NTIA has defined the minimum required fields for a valid SBOM, including component name, version, unique identifier (CPE/PURL), supplier, and relationship data.
President Biden's Executive Order 14028 (May 2021) mandated SBOM inclusion for all software supplied to the US government. This is already creating a ripple effect across the private sector. Organizations that build SBOM generation into their CI/CD pipelines today will be well ahead of incoming compliance requirements tomorrow.
Here is a practical framework for cloud security engineers and enterprise security leaders to build a defensible SSCS posture:
You cannot protect what you cannot see. Automate SBOM generation as part of every build and release cycle. Integrate it into your CI/CD pipeline so that every artifact is accompanied by an accurate, timestamped inventory of its components.
Use a Scorecard approach to evaluate your projects by their security posture looking at factors like branch protection status, CI test coverage, code review enforcement, presence of binary artifacts, and known unfixed vulnerabilities. Focus remediation resources on the highest risk projects first.
Hard coded credentials, API tokens, and secrets embedded in code are a persistent supply chain risk. Implement automated secrets detection across your repositories, CI/CD pipelines, and developer collaboration tools (Slack, Confluence, etc.) to prevent credential exposure before it becomes a breach.
Static point in time scans are not enough. Threats evolve a package that was clean last month may be compromised today. Integrate continuous dependency monitoring with threat intelligence feeds that flag newly discovered malicious packages in real time.
The open source ecosystem is vast. Manually reviewing packages for malicious behavior is not scalable. Leverage threat intelligence solutions that have pre analyzed millions of packages and can surface known malicious components at the IDE, CLI, and pipeline level giving developers actionable security context where they already work.
If your organization runs containerized workloads, container image scanning is non negotiable. Scan images pre deployment to identify vulnerable open source components, and correlate pre production findings with runtime data to focus remediation on vulnerabilities that are actually exploitable in your environment.
Use the SLSA framework as your maturity model. Start at Level 1, establish a baseline, and incrementally move up levels. Document your current level, communicate it to stakeholders, and build a roadmap toward Level 3 or 4 for your most critical software assets.
One of the most underrated challenges in SSCS is the organizational one: getting developers to care and act without creating friction.
Here's what works:
The software supply chain is no longer a back office concern it is a strategic security domain that requires dedicated resources, tooling, and executive attention.
To summarize what every CISO, Head of AppSec, and cloud security engineer should walk away knowing:
At Loginsoft, we work alongside cloud security engineers and enterprise security teams to navigate the complex and rapidly evolving landscape of software supply chain security. We believe that strong security and developer productivity are not in conflict; they are complementary goals that the right strategy and tooling can achieve simultaneously.
Whether you're starting your SSCS journey or looking to mature your existing program, our team is here to help you build a supply chain security posture that is both defensible and scalable.
Ready to secure your software supply chain? Connect with the Loginsoft team to discuss your environment and get started.
Q1. What is software supply chain security?
Software supply chain security (SSCS) refers to the set of practices, tools, and frameworks used to protect every component, process, and environment involved in building and delivering software including source code, dependencies, build pipelines, and distribution mechanisms from tampering, compromise, or malicious code injection.
Q2. Why is the software supply chain a target for attackers?
Attackers target the supply chain because it offers a broad impact on lower effort. Compromising a single widely used open-source package or build tool can cascade across thousands of downstream organizations simultaneously while bypassing the advanced security defenses typically applied to the final software product.
Q3. What is an SBOM and why does my organization need one?
A Software Bill of Materials (SBOM) is a complete inventory of every component in your software, including open-source libraries, versions, and licensing data. It enables your team to immediately identify exposure when a new vulnerability is disclosed, support compliance requirements, and maintain ongoing visibility into your supply chain at risk.
Q4. What is SLSA and how does it help?
SLSA (Supply chain Levels for Software Artifacts) is a security framework with four incremental levels that help organizations verify the integrity of their software build and source processes. Starting at SLSA Level 1 establishes basic provenance and automated builds, while Level 4 demands the highest assurance controls including hermetic builds and two-person code reviews.
Q5. What is the difference between a vulnerable package and a malicious package?
A vulnerable package contains unintentional developer mistakes that make the software exploitable. A malicious package contains intentionally inserted harmful code designed to cause damage. Both pose serious risks, but they require different detection and response strategies.
Q6. What is a dependency confusion attack?
A dependency confusion attack occurs when an attacker publishes a public package with the same name as a company's internal package but assigns it a higher version number. Package managers that prioritize higher versions may fetch the malicious public package instead of the intended internal one, executing attacker-controlled code in the build environment.
Q7. How does Loginsoft help organizations with software supply chain security? Loginsoft works with cloud security engineers and enterprise security teams to build and mature their SSCS programs. This includes vulnerability research, threat intelligence integration, SBOM implementation support, CI/CD pipeline security assessments, and aligning development environments to SLSA compliance all tailored to your organization's stack and risk profile.
Q8. How can organizations balance developer productivity with supply chain security? The key is integrating security into developer workflows rather than adding separate, friction heavy processes. Tools that surface security findings directly in the IDE, CLI, or pull request workflow with actionable remediation guidance enable developers to act on security without context switching. Loginsoft helps teams identify and implement the right toolchain for this balance.
Q9. Is SBOM compliance mandatory?
For organizations supplying software to the US government, SBOM inclusion is mandated under Executive Order 14028 (May 2021). While not yet universally mandatory in the private sector, regulatory momentum is building globally, and organizations that adopt SBOM practices proactively will be significantly better positioned for compliance and incident response.
Q10. Where should an organization start with SSCS?
Start with visibility. Automate SBOM generation for your most critical applications, audit your top level and transitive dependencies for known vulnerabilities and malicious packages, and assess your SCM and CI/CD platforms for basic security hygiene. From there, use the SLSA framework as a maturity roadmap and build incrementally. Loginsoft's team can help you define and execute this roadmap from day one.
