Securing the Software Supply Chain: Challenges, Tools, and Regulatory Forces

What is Software Supply Chain (SSC)

Let’s understand the definition by an example. Imagine a software development team is building an ASP.NET Core API with Angular frontend.

Followings are the technical components:

1. Source Code: C# and TypeScript/Javascript code
2. Dependencies: This can include NuGet packages, NPM packages and other paid or free software tools or libraries.
3. Build & CI/CD Tools: Include tools like Jenkins, GitHub Actions, or Azure DevOps, Docker images etc.
4. Artifact Repositories: Includes container registry, or build packages that others consume.
5. Host/Deployment: Includes IIS, Azure App Service or Kubernetes.

Believe it or not, but SSC includes all of the above components and more.

The common misconception is that SSC only includes external tools, however, it’s much more than that. Basically, SSC refers to the entire ecosystem of people, processes, tools, code, and infrastructure that come together to produce and deliver software. [1]

What constitutes securing SSC

Securing Software Supply Chain (SSC) means putting guardrails in place across the entire lifecycle - from writing code to running it in production - so you can trust what you ship. For example, protecting your code repository, branch protection, static code analytics and much more. In a nutshell, all the security aspects (including cybersecurity) from software development to production deployment are included in securing SSC.

Why Securing SSC is important

In 2025, securing SSC has evolved from a niche concern to a board-level priority. With software now composed of 70–90% open-source and third-party components, a single vulnerability can have cascading effects far beyond its origin. Gartner reports that “60% of large enterprises are already deploying software supply chain security (SSCS) tools in 2025, and this is predicted to jump to 85% by 2028”[2]. High-profile attacks targeting build systems, open-source repositories, and code dependency chains highlight the scale and urgency of this issue.

The Rise of Threats and Attacks

Attackers are increasingly targeting weaknesses in software supply chains, using methods ranging from exploiting popular open-source modules to injecting malicious code during the build process. According to ReversingLabs, “attacks are growing in sophistication, targeting AI, crypto, open source, and commercial software”[3]. In their 2025 analysis, they note 23 documented supply chain breaches affecting cryptocurrency infrastructure, and that “cybercriminals and nation states continue to target and exploit endemic weaknesses in black-box, commercial-software binaries”. The World Economic Forum’s 2025 Outlook concludes, “vulnerabilities arising from complex supply chain interdependencies are a primary concern for business and cyber leaders”.[4]

Managing Dependencies and the Dilemma of Open Source

Modern software is deeply dependent on open-source components - often nested several layers deep. This is mainly to gain productivity and reusability. Black Duck’s OSSRA 2025 report finds that “the average open source project now includes over 1,200 dependencies - a 30% increase from the previous year - and exceeds 100 MB in size” with “84% of codebases including at least one known open-source vulnerability”. [5]. Isn’t that alarming?

The primary risk drivers are:

• Transitive dependencies: Libraries your direct dependency depends on, which get pulled in automatically.
• Unpatched vulnerabilities: Known CVEs(Common Vulnerabilities and Exposures) present but the original maintainers (upstream) haven’t yet fixed them.
• Malicious code injection: Attackers introducing harmful code into open-source projects.

Now let’s discuss what are the trends in addressing this complex security concern.

SBOM (Software Bill of Materials) as a Cornerstone

An SBOM is an inventory list of all ingredients in a software — just like a food label tells you what’s inside a chocolate bar, an SBOM tells you what’s inside your software.

The adoption of SBOM is accelerating due to regulatory and market forces. The enforcement of PCI DSS 4.0 (Payment Card Industry Data Security Standard) in March 2025 and Europe’s Cyber Resilience Act require not only inventorying components but also their versions and place of origin. The US CISA ((Cybersecurity and Infrastructure Security Agency)) and NSA (National Security Agency) emphasize SBOMs as “an integral condition for software to be secure by design...enabling greater visibility across an organization’s supply chain and enterprise system by documenting information about software dependencies”. [6]

Real benefits include:

• Faster vulnerability identification and targeted patching.
• Improved compliance reporting and risk communication.
• Enabling downstream consumers to respond quickly to emerging threats.

New Best Practices and Organizational Approaches

Recent guidance from Gartner and Veracode points to the shift from application-level security controls (“shift left” - move security checks earlier in the development cycle) to automated, systemic management of the entire SDLC (Software Development Lifecycle), with unified artifact tracking, identity management, and continuous validation.[2] [7]. In other words, just having security checks at application level is not enough, instead treat the whole pipeline (from code → build → packaging → deploy → runtime) as part of the security boundary.

This includes:

• Automated SBOM generation and validation at every release stage.
• Early inventory mapping of all open-source components used.
• Professionalization of maintenance: Long-term support contracts with Open Source Software providers and early planning for EOL (End of Life) scenarios (Preparing for end-of-life (EOL) of critical dependencies so systems don’t break unexpectedly.).[8]
• Leveraging AI for automated bug detection, risk scoring, and managing complex dependency graphs.
• Auditing using package specific tools: For example, running “npm audit” or “yarn audit” etc.

Measuring and Managing Risk

Organizations today use both technical tools and team practices to keep their software supply chain secure. Here are the best practices from JFrog and GitLab:

• Technical: Lead time for patch adoption, vulnerability exposure windows, percentage of dependencies covered by SBOM [7] [9]
• Organizational: Incident response readiness, SLA compliance for OSS maintenance, employee training rates.

Further, continuous monitoring - with layered alerts tied to vulnerability feeds, threat intelligence, and internal asset registries has emerged as essential. [10]

Conclusion

As the software ecosystem grows ever more interconnected, securing the supply chain is both a technical and a leadership imperative. The combination of regulatory mandates, more sophisticated attacks, and exploding software complexity means that “SBOMs and automated supply chain security controls are foundational, not optional, for enterprise risk management in 2025 and beyond”. Leaders who act now - investing in automation, transparency, and support models for OSS will not only reduce risk but gain a competitive edge as trust and security become differentiators.

About the Authors

First Author: Rupenkumar Anjaria

Rupenkumar Anjaria is a seasoned software engineering professional with over 20 years of progressive experience in enterprise application development, maintenance, and production support. With a master’s degree in computer applications and a bachelor’s in mathematics, he has consistently delivered scalable and secure technology solutions across highly regulated sectors, including U.S. healthcare, mortgage, and market research domains. Currently serving as a Software Engineer at Acclaim Systems Inc., he plays a pivotal role in the development and support of digital services for government-regulated online portals and hybrid mobile platforms.

References

[1]: GitHub Blog

[3]: ReversingLabs report

[5]: Black Duck’s report

[7]: GitLab blog

[9]: JFrog article

Disclaimer: The authors are completely responsible for the content of this article. The opinions expressed are their own and do not represent IEEE's position nor that of the Computer Society nor its Leadership.