By Josh Bressers, VP of Security at Anchore

In recent years, we've witnessed the software supply chain transition from a quiet corner of cybersecurity into a primary battlefield. Today, cybercriminals have fully embraced the hidden complexity of software supply chains as a ripe vector to exploit.

SBOMs are an inventory of the complex dependencies that make up modern applications. SBOMs help organizations scale vulnerability management and automate compliance enforcement-among other things. The end goal is to increase transparency in an organization's supply chain where 70-90% of modern applications are open source software (OSS) dependencies. This significant source of risk demands a proactive, data-driven solution

Software Bills of Materials (SBOMs) have emerged as a focal point to achieve visibility and accountability in a software ecosystem that will only grow more complex. Looking ahead to 2025, we at Anchore, see 3 trends emerging in the area of software supply chain security:

1. Supply chain attacks continue their rapid acceleration
2. Global regulatory bodies continue to steadily drive SBOM adoption
3. Foundational software ecosystems begin to implement build-native SBOM support

Supply Chain Attacks Continue to Accelerate

Software supply chain attacks have a long history, but their magnitude and frequency kept them from reaching mainstream consciousness until recently. In 2017, the NotPetya attack foreshadowed the era of high-profile supply chain exploits. The turning point arrived in 2020 with the SolarWinds Orion breach which demonstrated the massive blast radius that has become the defining feature of prominent supply chain attacks. A single compromised vendor not only incurs the damages of a security breach; the impact ripples across their entire customer base and the industry as a whole.

The numbers don't lie: from 2019 to 2022, software supply chain attacks saw a staggering 540% year-over-year growth. On top of that, it is estimated these attacks will cause $80.6 billion in damages by 2026. Given the success that adversaries are seeing and the unabated growth of software complexity, the only rational expectation is that this trend will continue to accelerate into 2025. As these threats multiply, the security community will have to respond in kind.

Fortunately, the defensive front isn't standing still. Instead, they are coalescing around SBOMs as the scalable solution to software supply chain security.

Global Regulatory Bodies Continue Steady Adoption of SBOMs

As supply chain attacks surged, policymakers and standards bodies recognized this new threat vector as a critical threat with national security implications. To stem the rising tide supply chain threats, global regulatory bodies have decided that SBOMs are one of the solutions.

Over the past decade, we've witnessed a global legislative and regulatory awakening to the utility of SBOMs. Early attempts like the Cyber Supply Chain Management and Transparency Act of 2014 may have failed to pass, but they paved the way for more significant milestones to come. The U.S. EO 14028 in 2021 explicitly named SBOMs as the foundation for a secure software supply chain. The following year the European Union's Cyber Resilience Act (CRA) pushed SBOMs from the realm of "suggested best practice" to "expected norm."

Global guidance is not limited to the US and the EU. Regulators and security agencies worldwide-such as Germany's Office for Information Security (the BSI), the UK's National Cyber Security Centre, India's CERT-In, Canada's Centre for Cyber Security, and Australia's ACSC-have all signaled strong support for SBOM adoption.

This constant pressure ensures that SBOMs adoption will only continue to grow. It won't be long until they are table stakes for anyone operating an online business. We expect the steady march forward of SBOMs to continue in 2025. In fact, this regulatory pressure is being felt by the foundational ecosystems of the software industry.

Software Ecosystems Trial Build-Native SBOM Support

Until now, SBOM generation has been relegated to afterthought in software ecosystems. Businesses scan their internal supply chains with software composition analysis (SCA) tools; trying to piece together a picture of their dependencies. But as SBOM adoption continues its upward momentum, this model is evolving. In 2025, we expect that leading software ecosystems will promote SBOMs to a first-class citizen and integrate them natively into their build tools.

Industry experts have recently begun advocating for this change. Brandon Lum, the SBOM Lead at Google, notes, "The software industry needs to improve build tools propagating software metadata." Rather than forcing downstream consumers to infer the software's composition after the fact, producers will generate SBOMs as part of standard build pipelines. This approach reduces friction, makes application composition discoverable, and ensures that software supply chain security is not left behind.

We are already seeing early examples:

• Linux Ecosystem (Yocto): The Yocto Project's OpenEmbedded build system now includes native SBOM generation. This demonstrates the feasibility of integrating SBOM creation directly into the developer toolchain, establishing a blueprint for other ecosystems to follow.

• Python Ecosystem: In 2024, Python maintainers explored proposals for build-native SBOM support, motivated by the regulations such as, the Secure Software Development Framework (SSDF) and the EU's CRA. They've envisioned a future where projects, package maintainers, and contributors can easily annotate their code with software dependency metadata that will automatically propagate at build time.

• Perl Ecosystem: The Perl Security Working Group has also begun exploring internal proposals for SBOM generation, again driven by the CRA's regulatory changes. Their goal: ensure that Perl packages have SBOM data baked into their ecosystems so that compliance and security requirements can be met more effortlessly.

• Java Ecosystem: The Eclipse Foundation and VMware's Spring Boot team have introduced plug-ins for Java build tools like Maven or Gradle that streamline SBOM generation. While not fully native to the compiler or interpreter, these integrations lower the barrier to SBOM adoption within mainstream Java development workflows.

In 2025 we won't just be talking about build-native SBOMs in abstract terms-we'll have experimental support for them from the most forward thinking ecosystems. This shift is still in its infancy but it foreshadows the central role that SBOMs will play in the future of cybersecurity and software development as a whole.

Closing Remarks

The writing on the wall is clear: supply chain attacks aren't slowing down-they are accelerating. In a world of complex, interconnected dependencies, every organization must know what's inside its software to quickly spot and respond to risk. As SBOMs move from a nice-to-have to a fundamental part of building secure software, teams can finally gain the transparency they need over every component they use, whether open source or proprietary. This clarity is what will help them respond to the next Log4j or XZ Utils issue before it spreads, putting security team's back in the driver's seat and ensuring that software innovation doesn't come at the cost of increased vulnerability.

##

ABOUT THE AUTHOR

Josh Bressers is the Vice President of Security at Anchore where he manages the Infosec team and guides security features for the company's commercial and open source solutions. Additionally, Josh acts as a public security advocate and evangelist, representing Anchore on topics including DevSecOps best practices, software supply chain security, and other key cybersecurity initiatives.

Prior to joining Anchore, Josh was with Elastic where he built the product security team, managed Elastic Stack supply chain defense, and created an application security program with a strong emphasis on realistic requirements. Before Elastic, Josh was an early hire to the Red Hat Security Response Team where he specialized in helping their open source projects coordinate and disclose vulnerabilities and became the CVE Numbering Authority for all OSS projects within Red Hat. Later, he founded the Red Hat Product Security Team which oversaw security for development lifecycles and the ongoing application security for Red Hat products.

Josh is co-host of the Open Source Security Podcast and the host/producer of the Cyphercon Hacker History Podcast. Josh is a member of the OpenSSF technical advisory council, and co-lead of the OpenSSF SBOM Everywhere project. Josh is also a co-founder of the Global Security Database project which is a Cloud Security Alliance working group exploring the future of security vulnerability identifiers.