Labrador Labs Presents Practical Response Strategies at the 2026 Supply Chain Security Workshop.
Software may appear to be a single finished product, but it is actually composed of numerous components.
A single piece of software is built by assembling diverse elements, including open-source software, external libraries, frameworks, container images, and packages installed on production servers.
Much like how building a car requires an engine, tires, a battery, and semiconductors, software operates through the combination of various digital parts.
The critical issue is that if a security vulnerability arises in just one of these components, the entire system can be compromised. Consequently, the importance of the SBOM (Software Bill of Materials) is rapidly growing worldwide.
In light of this, Hak-soo Cho, CTO of Labrador Labs, recently participated in the ‘2026 Supply Chain Security Workshop’ to deliver a presentation titled “Software Supply Chain Security Responses in the Era of Mandatory SBOMs.”
“SBOMs: No Longer Optional, But Mandatory”
In the past, the primary focus was simply on developing software well and operating it stably. Today, however, the questions have changed:
- What open-source software is embedded within the software we use?
- If a vulnerability is discovered in an open source component, will our system be affected?
- Out of countless vulnerabilities, which one should we patch first?
- How can we verify that the software delivered to us is secure?
An SBOM is precisely what is needed to answer these questions.
The United States is strengthening software supply chain security through Executive Order (EO) 14028. Similarly, the European Union is reinforcing security compliance for digital products centered around the Cyber Resilience Act (CRA). Today’s global market demands SBOM submissions when delivering or exporting software.
This shift is beginning in the domestic market as well.
The Ministry of Science and ICT (MSIT) and the National Intelligence Service (NIS) are preparing to introduce an SBOM submission policy for IT products supplied to the public sector in 2027, with full-scale operations slated for 2028. SBOMs are no longer just a niche interest for a few security experts; they are becoming a fundamental security framework that must be established across major industries, including the public sector, finance, manufacturing, defense, and cloud computing.
“Vulnerability Explosion in the AI Era”
One of the reasons software supply chain security has become more critical recently is AI.
As AI technology advances, the speed at which open-source and software vulnerabilities are discovered is accelerating significantly. Vulnerabilities that previously required long hours of analysis by security experts can now be uncovered rapidly by AI.
While discovering vulnerabilities quickly is certainly a positive development, it simultaneously creates a new challenge. When vulnerabilities are detected too rapidly and in massive quantities, security teams cannot process all of them at the same speed. In actual production environments, applying a single patch requires careful consideration of its impact on services, compatibility, and the potential for system downtime. Therefore, the key is not merely finding more vulnerabilities. The core objective is to swiftly filter out the vulnerabilities that actually impact our systems and prioritize remediation based on risk levels.
“Shifting Roles for Developers, Buyers, and Regulatory Bodies”
Supply chain security is not a problem confined solely to software developers.
The roles of developers, buyers, and regulatory bodies are all evolving together.
First, software developers must move beyond simply utilizing open source for rapid development and establish frameworks to take responsibility even after deployment. When a new vulnerability is publicly disclosed after a product has been delivered, developers must immediately verify whether that vulnerability impacts their product. In particular, they must track not only the open source they directly used but also the underlying sub-components that the open source relies on a concept known as transitive dependency. Simply put, it means verifying not just the parts they directly inserted, but also the components embedded within those parts.
The perspective of software buyers is also shifting.
In the past, the focus was on what software was purchased, how many units were acquired, and how many licenses were held. Now, the priority lies in understanding what the software consists of, what risks it carries, and how to comprehensively manage SBOMs received from multiple vendors. Public institutions or large enterprises that adopt a wide variety of software cannot afford to treat SBOMs merely as static files stored away. Whenever a new vulnerability is disclosed, they must be capable of analyzing which products are affected in real time.
Regulatory bodies also require a system that allows them to centrally monitor and validate compliance in real time. They need a single-pane-of-glass view to see what software subordinate organizations are using, how many high-risk vulnerabilities remain unresolved, and whether patching is progressing correctly. Ultimately, supply chain security is expanding beyond individual corporate security activities into a framework of trust at the industry and national levels.
“The Urgent Need for Advanced Supply Chain Security”
Generating an SBOM is merely the starting point of supply chain security. True supply chain security requires much more sophisticated technology.
- First, diverse vulnerability databases must be integrated.
Vulnerability information comes from various sources, including NIST NVD, CVE, OSV, GHSA, KEV, and the domestic KNVD. Each dataset has different formats and standards. Technology is required to collect this data, eliminate duplicates, and accurately map it to actual software components. This process relies on identifiers like PURL and CPE to normalize components and vulnerability data ensuring that identical parts and vulnerabilities called by different names are correctly recognized. - Second, various forms of software must be analyzed.
Software does not exist solely as source code; it exists as compiled binaries, container images, and packages installed on production servers. A supply chain security platform must be capable of analyzing binaries, containers, and operating systems in addition to source code. In production environments especially, the actual installed state often diverges from the initial deployed state a phenomenon known as operational drift. Supply chain security must not end at the development phase; it must continuously extend into the operations phase. - Third, software trustworthiness must be proven.
Secure software does not just mean having fewer vulnerabilities. Organizations must be able to verify that the process from development to deployment has not been tampered with, that the build process is trustworthy, and that deployment files have not been altered mid-transit. To achieve this, technologies such as build integrity verification, provenance tracking, security attestation, and signature/hash verification are becoming increasingly vital. In the future, it will not just be about “what software was made,” but proving “through what secure process the software was delivered.”
“Labrador Labs Supports the Entire Lifecycle: Development, Procurement, and Operations”
Labrador Labs provides an integrated supply chain security platform that allows organizations to manage the entire lifecycle of software supply chain security in a single, seamless flow. Supply chain security should not be confined to software development alone; it must connect everything from before software enters an organization, through the development process, during delivery and procurement, and into the actual production environment. To support this, Labrador Labs offers the following core solutions:
- CDB/VDB (Component DB / Vulnerability DB)
This serves as the data foundation for supply chain security. It builds comprehensive component and vulnerability databases, integrating and normalizing information from multiple sources to enable highly accurate analysis. - Labrador SCA (Software Composition Analysis)
This automatically analyzes open-source components embedded within source code, binaries, and containers. It allows organizations to grasp what open source is included in their software without developers having to manually check every single component. - IVAS (Integrated Vulnerability Analysis System)
This identifies vulnerable components on a project-by-project basis, determining actual impact and patch prioritization. It goes beyond simply listing vulnerabilities to help organizations judge which risks require immediate attention. - ISMP (Integrated SBOM Management Portal)
A centralized platform designed for software-buying organizations to collect, validate, and comprehensively manage SBOMs. It allows organizations to manage SBOMs from multiple vendors in one place and quickly identify affected products when new vulnerabilities are disclosed. - ServerCare
This continuously monitors software and components installed on live servers and systems. It detects operational changes and drift, supporting organizations in managing risks within their active production environments.
“The Core of SBOM Compliance is ‘Continuous Management'”
As the era of mandatory SBOMs approaches, many organizations initially focus solely on the idea that they “need to generate an SBOM file.” While SBOM generation and submission are undoubtedly important, the core of supply chain security does not end with filing a document.
The SBOM is just the starting point.
The true value lies in using that list to continuously identify new vulnerabilities, analyze actual impacts, determine patch priorities, and track changes in production environments. In other words, supply chain security is not a one-time paperwork exercise; it is a continuous operational framework.
Software supply chain security goes beyond mere regulatory compliance
It is a fundamental capability for organizations to accurately understand the software they use and swiftly evaluate risks. Moving forward, the security competitiveness of enterprises and institutions will be determined by their ability to prove what their software is made of, what risks it carries, and how quickly they can respond.
Labrador Labs provides practical, actionable response strategies for the era of mandatory SBOMs through its integrated supply chain security platform that encompasses development, procurement, and operations.
📌 Prepare for the era of mandatory SBOMs by building an integrated supply chain security platform!
Phone: US Office +1 650-278-9253 (Mon–Fri, 9 AM–6 PM)
Email: contact@labradorlabs.ai (1:1 demo requests and pricing inquiries)