Software Supply Chain Security: Risks Hide Beyond Your Code

Software Supply Chain Security: Not a New Term, but Old Problems Erupting

Today, almost no system is built from scratch. A typical system includes open-source components, commercial middleware, third-party SDKs, database drivers, OS images, container images, low-code platform capabilities, external interfaces, outsourced development outputs, vendor operations tools, and scripts and configurations left by different teams over time. These elements together constitute the system's real runtime shape.

The problem is that many organizations know what functions their systems have, but not exactly which software components they contain. They know who their suppliers are, but cannot verify whether the delivered software packages are traceable, whether dependencies are auditable, whether vulnerability fixes have SLAs, or whether upgrade processes leave audit trails. This creates an illusion: the system appears to be yours, but security responsibility has been scattered across many external links.

The National Cybersecurity Standardization Technical Committee (TC260) recently published multiple supply chain security practice cases, repeatedly pointing to similar shifts: supply chain risk is not only final product risk, but also includes supply relationship risk, technical risk, intellectual property risk, and transitive risk from insufficient supplier cybersecurity capabilities. Especially in critical industry scenarios, insufficient supplier capability, untraceable delivery processes, and lack of integrity verification for third-party software can let risks enter internal systems from external chains.

The real concern is not "another security concept," but that software construction methods have changed. The more a system relies on external components and collaborative delivery, the less security can focus only on the final code.

The Real Trouble Isn't Using Third Parties, It's Not Knowing What You Use

Discussions about software supply chains often frame the problem as "can we avoid open source" or "can we avoid third-party components." That is not the point. In real software engineering, avoiding third-party components is nearly impossible and unnecessary. Mature components, open-source ecosystems, commercial middleware, and cloud services are essential efficiency foundations. The real risk is not "using external things," but "not knowing what you use, where it comes from, what changed, and who is responsible when risk appears."

This uncertainty can be broken into four questions:

Are components clear? Surface: there are installation packages, source code, deliverables. Real question: which components, versions, dependencies, licenses, and external modules does the software contain?

Is the source trustworthy? Surface: it's delivered by a partner vendor. Real question: can the build, signing, download, transmission, and deployment chain be verified?

Are changes traced? Surface: there are version numbers and update notes. Real question: can every modification, upgrade, patch, and configuration change be traced to a responsible person and timestamp?

Is risk closed-loop? Surface: vulnerabilities can be notified. Real question: can affected systems be quickly located, remediation driven, results verified, and evidence retained?

This table reveals a basic judgment of supply chain security: security is not just about "whether there are vulnerabilities," but whether the organization can explain the entire process of software from source to runtime.

If the answer is unclear, risk turns into three troubles:

Cannot find: A component vulnerability is disclosed; the security team knows the news, the business unit knows the system, the supplier knows the delivery package, but no one can quickly confirm which of the organization's systems are affected.

Cannot fix: After risk discovery, internal systems cannot be stopped arbitrarily, supplier response is slow, version compatibility is unclear, patch verification lacks environments, and the only recourse is temporary hardening.

Cannot retain evidence: Remediation was done, but pre- and post-fix versions, test results, impact scope, and supplier response records do not form a closed loop. During audits, inspections, retrospectives, or liability determinations, it is hard to prove the risk was effectively handled.

This is why Software Bill of Materials (SBOM), supplier security assessment, third-party software testing, vulnerability response SLAs, and deliverable integrity verification are repeatedly emphasized. They are not for adding paperwork, but to move software systems from "visible functions" to "visible components, sources, changes, and responsibilities."

Supplier Management Shifting from Qualification Review to Capability Verification

Traditionally, supplier management focused on qualifications, case studies, contracts, promises, and acceptance materials. These are important but insufficient for software supply chain security because software delivery is not a one-time purchase. It involves continuous development, version iteration, vulnerability fixes, remote support, operations response, and subsequent upgrades. A supplier with complete bidding documents does not necessarily have sufficient security capability in the real delivery chain.

The practical shift is from "reviewing materials" to "verifying capabilities." For example: Does the supplier have a secure development process? Can they manage their own open-source components and third-party dependencies? Can they provide verifiable software composition information? Can they perform graded vulnerability response? Can they guarantee deliverable package integrity? Can they explain permission boundaries of remote operations tools? Can they cooperate in locating and fixing risks when they occur?

These detailed questions determine whether the system can truly move forward when incidents happen.

TC260's recent supply chain security practice cases mention requirements based on GB/T 43698-2024 and GB/T 36637-2018 for procurement and supplier management, including setting supplier security qualification thresholds, improving security protocols, optimizing third-party software selection and certification processes, and integrating vulnerability response and remediation SLAs into security requirement specifications. Other cases focus on critical industry supplier cybersecurity capability requirements, assessing capabilities across development, delivery, and usage phases.

These practices send a clear signal: supply chain security is not done by procurement alone, nor by security writing a policy alone. It requires connecting procurement, R&D, testing, operations, security, legal, and business responsibilities.

Especially for industry software, the most easily overlooked risk is continuous risk after delivery. Many systems are not most dangerous on launch day, but after years of operation, repeated modifications, and continuous integration of new interfaces and components, they gradually become complex systems where "everyone uses, everyone changes, no one fully understands." Supply chain security that stops at the procurement gate cannot manage this part of risk.

A Practical Benchmark: Can Four Lists Align?

Judging whether an organization's software supply chain security is getting on track does not necessarily start with how many tools it has or how many policies it wrote. A more practical observation is whether four lists can align:

System List: Which business systems, platforms, applications, interfaces, and services are running in the organization.

Supplier List: Behind each system, which software suppliers, development service providers, operations service providers, cloud service providers, and key component providers exist.

Software Composition List: For each system, which open-source components, third-party libraries, middleware, SDKs, images, scripts, and plugins are included, along with their versions and sources.

Risk Disposal List: When vulnerabilities, component risks, supplier security incidents, or upgrade changes occur, can impact scope, disposal responsibility, fix status, verification results, and evidence materials form a closed loop?

If these four lists are disconnected, supply chain security cannot land. System list and supplier list misaligned → responsibility chain unknown. Supplier list and composition list misaligned → deliverable contents unknown. Composition list and risk disposal list misaligned → external vulnerability intelligence cannot translate into internal disposal actions. Risk disposal list and system list misaligned → business risk convergence cannot be proven.

Often, so-called "supply chain security capability" starts not from a high-end platform, but from cross-checking these four lists.

This is the biggest difference between software supply chain security and traditional vulnerability management. Vulnerability management is like finding a point and fixing a point; supply chain security is like building a relationship graph: who provided what, what entered where, what was affected, and who is responsible for fixing it properly.

For Industry Software Construction, Supply Chain Security Becomes a Default Requirement

From public standards and practice cases, software supply chain security is moving from "a topic for security teams" to "a default requirement for industry software construction." Several reasons drive this:

System dependencies are increasingly complex. AI, RPA, low-code, microservices, containers, open-source components, and cloud-native platforms improve delivery efficiency but make software composition and dependency relationships harder to see at a glance.

Security responsibilities are becoming more concrete. Data security, personal information protection, critical information infrastructure protection, graded protection, and cybersecurity review all push organizations to prove their security management is not paper promises but executable, verifiable, and traceable.

Supplier capability differences directly affect user-side risk. Two suppliers delivering the same system: one provides component lists, vulnerability response, integrity verification, and upgrade records; the other provides only an installation package and a manual. The difference is invisible during normal use but huge when risk occurs.

External security events propagate faster. A widely used component, tool, or SDK issue can affect many systems. Without internal mapping, organizations can only rely on manual investigation and supplier verbal confirmation, making disposal efficiency hard to guarantee.

Future software construction will not only ask "can the function be implemented," but increasingly "where does this capability come from, what does it depend on, how to verify, how to update, how to respond to risk."

This does not mean every unit must make supply chain security overly complex. The key is forming a clear direction: turning software from black-box delivery into identifiable, verifiable, traceable, and disposable assets.

When a system can clearly state what it consists of, who delivered it, what changes it underwent, and how risk loops are closed, it becomes more like a long-term operable industry software asset.

The core of supply chain security is not distrust of suppliers, but turning chains originally maintained by trust into collaboration relationships with evidence, boundaries, and response mechanisms.

This is a lesson many industry systems cannot bypass going forward.

Sources and References

National Cybersecurity Standardization Technical Committee: Cybersecurity Standard Application Practice Cases | Supply Chain Security Theme 9, 2026-06-29.

https://www.tc260.org.cn/portal/article/1/07d60a8d728445fbb3526ca97e3d02d9

National Cybersecurity Standardization Technical Committee: Cybersecurity Standard Application Practice Cases | Supply Chain Security Theme 8, 2026-06-29.

https://www.tc260.org.cn/portal/article/1/c5bff06b0a544674b12b89271bf8df02

National Standard Full Text Public System: GB/T 43698-2024 "Cybersecurity Technology - Software Supply Chain Security Requirements", published 2024-04-25, implemented 2024-11-01.

https://openstd.samr.gov.cn/bzgk/std/newGbInfo?hcno=94FEB278E715BD48566C48804F1A56EC

National Standard Information Public Service Platform: GB/T 43698-2024 "Cybersecurity Technology - Software Supply Chain Security Requirements".

https://std.samr.gov.cn/gb/search/gbDetailed?id=173829859D2E1AA5E06397BE0A0AA311

National Standard Information Public Service Platform: National Standard "Cybersecurity Technology - Software Bill of Materials Data Format" related information.

https://std.samr.gov.cn/gb/search/gbDetailed?id=49FD1852CB33C31FE06397BE0A0A1304