OSPO | Haksung

CISA 2026 SBOM Minimum Elements: What to Prepare and Which Tools Fill the Gaps

Haksung Jang — Sun, 09 Aug 2026 00:00:00 +0000

This article was written with Claude Code, and the key facts cited here were cross-checked against primary sources.

Summary

On July 29, 2026, the Cybersecurity and Infrastructure Security Agency (CISA) and 17 other agencies published a revised set of minimum elements for a Software Bill of Materials (SBOM)[A2]. The document states plainly that it replaces, rather than amends, the baseline established in 2021 by the National Telecommunications and Information Administration (NTIA).

The bar has risen noticeably. The data fields grew from 7 to 17, and six operational practices were specified alongside them. Ten of the elements are entirely new.

Three changes matter most in practice.

Licensing entered the SBOM minimum baseline for the first time.
Dependencies must now be recorded in full, down to transitive dependencies, with no depth limit.
New fields were added to declare the origin and integrity of the SBOM document itself.

The document carries no effective date and no enforcement power. Preparation is still warranted, because national regulations increasingly require SBOMs without enumerating the fields those SBOMs must contain. The practical significance of this document is that it gives procurement contracts a multilateral consensus baseline to cite.

The nature of that preparation is easy to misjudge. Meeting the minimum elements is not a matter of picking a tool. Fewer than half of the 23 elements can be filled by a generation tool on its own. The rest are filled by the build pipeline, the signing infrastructure, and policies the organization decided on in advance.

I also checked how far an actual tool gets. BomLens is an SBOM generation and management tool that SK telecom developed for software supply chain security and released as open source. Assessing all 23 elements with it produced the following:

The tool fills 11 of the 17 data fields directly with values.
It inspects supplier-submitted SBOMs against all 23 elements, separating out the 4 that the organization must decide as items for human review.
The remaining gaps exist not because the tool is deficient, but because those values must be determined by whoever runs it or by the build stage at which it runs.

The assessment screen can be viewed directly in thepublic demo, with nothing to install.

1. What Changed

1.1 The Structure of the Elements

The minimum elements fall into two categories. Seventeen data fields are the values actually carried in the SBOM document; six operational practices govern how an organization handles SBOMs.

Figure 1. The composition of the CISA 2026 SBOM minimum elements(source: 2026 Minimum Elements for a SBOM, 2026-07-29)

SBOM metadata is a category that did not exist in the 2021 edition. Where the earlier baseline asked for little more than an author and a timestamp, the document now requires the SBOM to declare for itself which tool produced it, when, at what stage, and who signed it.

1.2 Three Substantive Changes

Licensing became mandatory. The seven data fields of the 2021 edition did not include licensing, because that document was aimed at security and vulnerability management. The revision adds component licensing as a new element, requiring that it be conveyed in a machine-processable form such as an SPDX license identifier where possible, and that the presence of proprietary license terms be disclosed as well. Territory that belonged to the Open Source Program Office (OSPO) is now part of the SBOM minimum baseline.

The floor on dependency resolution is gone. The Depth element of the 2021 edition required only top-level dependencies. The revision replaces it with a Coverage element that requires all constituent components including transitive dependencies, and states explicitly that recording only to a certain depth is no longer sufficient. The document is candid about why. The 2021 baseline “reflected the capabilities of SBOM tooling at the time rather than the depth of information needed for informed security decisions,” and since tooling has advanced in the interim, the requirement has been raised.

Supplier Name became Component Producer. This is a change of definition, not merely of label. The document states that Supplier Name “proved ambiguous in practice, particularly in relation to software distributors.” The intent is to end the practice of naming redistributors and to point the field at the entity that originally created the software. Where the producer is unclear, as with open source projects, the document requires that the unknown provenance be stated explicitly.

Separately, Software Identification (SWID) tags were dropped from the list of accepted formats. Two remain: SPDX and CycloneDX.

2. What the OSPO Must Decide

The six operational practices are items an organization must answer, not a tool. The document says as much: organizations “should explicitly address these elements in all policies, contracts, and agreements that require or provide SBOMs.”

2.1 How Much to Include

The Coverage element requires all transitive dependencies while permitting the exclusion of non-code files. It adds that security-relevant files, such as configuration files, may be included. Where to draw the line on security relevance is for the organization to decide.

The vulnerability management test offered by the document is a useful criterion: an SBOM recipient should be able to conclude that a newly reported vulnerability does not affect them if the associated component is absent from the list. A scope definition that fails this test does not satisfy the Coverage requirement.

Linking each subcomponent to a separate SBOM is also permitted, but with a condition. The recipient must be able to access every linked SBOM. Providing links without access rights does not meet the requirement.

2.2 When to Regenerate

The Frequency element requires a corresponding SBOM for each software version or update. Every new build or release calls for a new SBOM, and that includes builds where only dependencies changed.

One more obligation attaches here. If errors are found in existing SBOM data, or new facts about a component come to light, a revised edition must be issued. This means an SBOM may need to be reissued without any accompanying release, which in turn requires a way to track where already-distributed SBOMs went.

2.3 How to Record What Is Not Known

Explicit identification of unknowns is a major update. The requirement is specific: when a value is absent, it must be clear whether the information is unknown to the author or whether the author is knowingly withholding it.

The distinction conveys different information to the recipient. Unknown means the supply chain trace broke off at that point; withheld means the supplier has the information and is not providing it. For the latter case, the document requires a process through which recipients can inquire, and adds that an SBOM withholding essential component data may be treated as incomplete.

In practice, the notation convention has to be settled first. Simply leaving a field empty makes the three cases indistinguishable: whether the value does not exist, was never confirmed, or was deliberately not disclosed.

2.4 Which Formats to Accept

The machine-readable data element names SPDX and CycloneDX while directing organizations to accept widely used, interoperable formats. One condition attaches: SBOMs for new software generated with deprecated versions should not be accepted.

That condition creates a second acceptance criterion. Format version matters as much as format name, and the new SBOM data format name and version elements provide the basis for that judgment.

2.5 What to Put in Contracts

Translated into contract language, the items above come out as follows.

The required format and minimum version
The coverage scope, including transitive dependencies
The obligation to supply an SBOM with each release, and to supply a revision when errors are found
Distinct notation for unknown versus withheld, and an inquiry process for withheld items

The three actions the document recommends to organizations point the same way: require SBOMs that satisfy the updated minimum elements, use tooling to generate, collect, and analyze SBOM data, and generate SBOMs that satisfy the minimum elements themselves.

3. Who Fills Each Element

Sorting the 23 elements by who fills them clarifies what preparation actually involves.

Figure 2. The four domains that fill the 23 minimum elements(source: compiled from the element definitions in the original document)

What a generation tool can handle alone sits on the component data side. The rest must be filled from outside the tool.

Generation context must be recorded inside the build pipeline to be accurate. An SBOM built from source corresponds to “pre-build” and one built from binary analysis to “post-build” — a value determined by when the scan runs, not by what it scans.

Component hashes require an executable artifact to compute. At source-scan time that artifact does not yet exist, making it inherently impossible, and the document itself prescribes an unknown marking for this case. Requiring hashes means generating or updating the SBOM at a post-build stage.

Author signatures presuppose key management. The document directs organizations to use existing software signing infrastructure and key management, which falls outside the scope of an SBOM tool.

SBOM Author is a value the tool cannot know. Since the definition is the entity operating the tool, whoever runs it has to supply it.

3.1 Which Formats Carry the New Elements

Formats differ in how far they carry the 10 new fields, which makes the choice of format itself a practical decision[C3].

Element	CycloneDX 1.6	SPDX 2.3	SPDX 3.0
SBOM generation context	`metadata.lifecycles[].phase`	No dedicated field	`software_Sbom.sbomType`
SBOM author signature	Built into root`signature`	Not specified in the document	No signature class
SBOM version	Integer +`serialNumber`	Handled as a change of document identity	Document identity +`amendedBy`
SBOM tool version	`tools.components[].version`	Embedded in the creator string	No dedicated property
Unknown notation	No global marker; convention required	`NOASSERTION`	`NOASSERTION`

Table 1. How each format can express the new elements(source: RunSafe Security field mapping analysis, 2026)

CycloneDX has the advantage on the new metadata. Generation context and signatures exist as native fields, and the lifecycle phase vocabulary the original document uses as an example maps across directly.

Conversely, SPDX offers the better mechanism for marking unknowns. Its standardNOASSERTION marker distinguishes “no value” from “not determined,” whereas CycloneDX has no marker at that level, requiring a separate convention using properties or annotations. And marking unknowns is precisely one of the requirements this revision strengthened.

The judgment at this point is as follows. The combination that carries the minimum elements most completely is CycloneDX 1.6, provided the organization establishes its own convention for marking unknowns. Organizations using SPDX as their primary format have no place in 2.3 for generation context or signatures, which makes this the moment to consider migrating to 3.0.

4. Relationship to Regulation

The minimum elements carry no legal force in themselves. The disclaimer states that the publication “is not intended as compliance, regulatory, or legal advice.”

Its real influence comes through citation. The European Union Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers to provide an SBOM as part of the technical documentation, but does not enumerate the fields in its text[A5]. Germany’s BSI TR-03183-2 filled that gap with concrete technical requirements, and India’s CERT-In and Japan’s Ministry of Economy, Trade and Industry have issued guidance of their own. The minimum elements are the baseline these all reference in common.

One caution applies. Although the European Commission’s Directorate-General for Communications Networks, Content and Technology (DG CONNECT) contributed to the drafting, a footnote states that the document does not interpret European Union law, does not bind the Commission, and that not all of its elements reflect Union law. It cannot be used as-is to demonstrate Cyber Resilience Act compliance.

There is also a terminological trap. A footnote in the original explicitly warns against confusing the “producer” of Component Producer with the “manufacturer” of the Cyber Resilience Act. Every manufacturer is a producer, but not every producer is a manufacturer. Documents that address both regimes need to keep the terms distinct.

From Korea, two organizations participated as co-authors: the National Cyber Security Center under the National Intelligence Service, and the Korea Internet & Security Agency. That participation gives domestic procurement and internal policy a basis for citing this document. Because the international common baseline was updated immediately after the government’s joint Software Supply Chain Security Roadmap was announced in June 2026, domestic policy now has a reference to draw on when it comes to specifying required fields.

Organizations working with AI systems should note the ordering. The original document introduces no AI-specific elements, deferring them to the G7 joint guidance[A10]. The two documents are hierarchical: fill this general software baseline first, then add the AI-specific elements.

5. How Far Do Actual Tools Get Today

Reading a baseline and confirming that a tool actually meets it are separate exercises. Even when a format has a place for a value, the field stays empty if the tool does not put one there.

I assessed all 23 elements using BomLens, the SBOM generation and management tool that SK telecom developed for software supply chain security and released as open source. The basis was actual scan output and source code rather than estimation[D1].

5.1 What the Tool Fills with Values

The tool fills 11 of the 17 data fields directly.

SBOM metadata: data format name and version, generation context, timestamp, tool name, SBOM version
Component data: name, version, identifier, license, dependency relationships

Three of these are filled in ways that bear directly on the minimum element requirements.

Generation context is determined automatically from the input type. Source scans are recorded aspre-build and container and binary scans aspost-build, so the user never selects the value.
Licensing is filled for 98.4% of components on the source path and 94.7% on the container path. The source side reads from package manifests, the container side from the operating system package database.
The tool name records both BomLens itself and its underlying generators. The minimum elements ask for the tools that generated or modified the SBOM, so both are retained.

Among the six operational practices, it satisfies machine-readability and distribution and delivery. It emits CycloneDX 1.6 as its default format and supports conversion to SPDX 2.3, covering both formats the minimum elements designate.

5.2 What the Tool Cannot Fill

The remaining items are empty not because the tool falls short, but because of the structure described in section 3.

SBOM author and author signature: the entity running the tool must supply the value. The author is passed via--sbom-author, and signing is a separate option that uses cosign.
Component hash: at source-scan time no executable artifact exists to hash. On paths where an artifact does exist, such as containers and firmware, the scan target itself is hashed.
Component producer: the package metadata must carry producer information for this to be filled. Coverage is 60.9% on the source path and 94.7% on the container path.

How the absence of a value is handled matters from the minimum elements perspective. When no author is specified, this tool does not writeunknown; it leaves the field empty and adds a document-level declaration that empty fields were not determined by the author. Because the minimum elements define the author as the entity operating the tool, and that entity knows who it is, a tool writingunknown would not be marking an unknown but making a false statement. Hashes follow the same principle: no value is invented.

5.3 Assessing Received SBOMs Against the Minimum Elements

The tool can also inspect supplier-submitted SBOMs against all 23 elements. Results come out in three branches.

Figure 3. The conformance assessment screen. All 23 elements are assessed, with the 4 the tool cannot judge separated out for human review(BomLens 1.10.3 output, 2026-08-09)

Met, 13 — the 11 data fields plus 2 operational practices.
Not met, 6 — the items covered in section 5.2.
Human review, 4 — Coverage, Accommodation of Updates to SBOM Data, Distribution and Delivery, and Frequency. These are decided by the organization, so the tool passes them to a person rather than judging them.

Not treating what it cannot judge as a pass is what makes this useful in practice. The four items marked for human review are the same organizational decisions covered in section 2.

The same screen can be opened directly in thepublic demo. It runs in a browser with nothing to install, and each element carries a note on what is missing and how to fill it. Note that the demo shows the result of inspecting a supplier-submitted SBOM, so its subject differs from the figure above.

5.4 What Remains

Some gaps remain before the minimum elements are fully met.

The tool version is recorded as an image tag rather than a release number. The minimum elements call for a value that identifies a specific delivery of code.
The SBOM version stays fixed at 1 across regenerations and cannot express revision relationships. This connects directly to the accommodation of updates element, but a locally running tool cannot know where its previous output went, which makes user-specified versioning the realistic alternative.

6. Conclusion

What the revised minimum elements demand is not more fields but a different kind of preparation.

With licensing in the minimum baseline, the SBOM is no longer a document belonging to the security team alone. Filling in license identifiers in machine-processable form, disclosing the presence of proprietary terms, and stating plainly when something is not known — this is how an OSPO already works. What changed is that the result now has to leave the organization in a standard format.

Much of the preparation has to be finished before a tool is selected. Four items are for the organization to decide.

How much to include
When to regenerate
How to mark what is not known
Which formats and versions to accept

Adopt a tool without settling these, and whatever defaults the tool produces become the organization’s policy.

It is equally necessary to separate what can be demanded of a tool from what cannot. A source-scanning tool cannot be asked for the hash of an executable artifact, and no tool can decide an organization’s name on its behalf. Demand that unfillable values be filled and the tool will invent plausible ones, which is the direction the minimum elements prohibit.

Checking what your current tool fills and what it leaves empty is worth doing once. Format support and field satisfaction are different questions, and the gap between them only shows when you open the output yourself. If there is no obvious tool at hand to check, BomLens from section 5 is a starting point. It is open source and free to download, and it shows both how far a generated SBOM meets the 23 elements and whether a supplier-submitted SBOM meets the baseline, on the same screen.

References

A2. Cybersecurity and Infrastructure Security Agency and 17 other agencies (2026).2026 Minimum Elements for a Software Bill of Materials (SBOM). v2.1, published July 29, 2026, TLP:CLEAR.https://www.cisa.gov/sites/default/files/2026-07/2026_cisa_sbom_minimum_elements_508c.pdf.

A5. European Parliament and Council (2024).Regulation (EU) 2024/2847 — Cyber Resilience Act. Official Journal of the European Union, October 23, 2024.https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202402847.

A10. CISA and G7 partners (2026).Software Bill of Materials for AI – Minimum Elements. May 2026. — Covered in detail in theG7 SBOM for AI Minimum Elements report.

A1. National Telecommunications and Information Administration (2021).The Minimum Elements For a Software Bill of Materials (SBOM). Published July 12, 2021.https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom.

A3. Federal Register (2025).Request for Comment on 2025 Minimum Elements for a Software Bill of Materials. Published August 22, 2025; comment period closed October 3, 2025.https://www.federalregister.gov/documents/2025/08/22/2025-16147/request-for-comment-on-2025-minimum-elements-for-a-software-bill-of-materials.

B1. SPDX.The System Package Data Exchange.https://spdx.dev/. ISO/IEC 5962:2021.

B2. CycloneDX.https://cyclonedx.org/. Ecma International,ECMA-424: CycloneDX Bill of Materials Specification, December 2025.

C3. RunSafe Security (2026).Mapping CISA’s 2026 SBOM Minimum Elements to CycloneDX and SPDX.https://runsafesecurity.com/blog/sbom-minimum-elements-cyclonedx-spdx/. — The basis for Table 1. The per-format field mapping is taken from this analysis and was not verified directly against the specifications.

D1. BomLens. An SBOM generation and management tool developed and released by SK telecom for software supply chain security, Apache-2.0.https://github.com/sktelecom/bomlens. The coverage assessment in section 5 was determined from actual scan output and source code using version 1.10.3 of this tool.

]]>

What the US AI Executive Order (2026-06-02) Means for Corporate Open Source Managers

Haksung Jang — Wed, 10 Jun 2026 00:00:00 +0000

This article was written with Claude Code, and the key facts cited here were cross-checked against primary sources.

Summary
The executive order “Promoting Advanced Artificial Intelligence Innovation and Security,” signed on June 2, 2026, imposes no obligations on companies. Its core is the Treasury Department-led AI Cybersecurity Clearinghouse (a relay body that gathers, verifies, and distributes vulnerability information in one place, to be formed within 30 days) and a voluntary pre-sharing framework for frontier models (to be designed within 60 days); mandatory licensing and pre-approval are explicitly excluded A1. No provision applies directly to corporate open source managers either. Still, the order is worth reading because of what lies behind it. AI finding open source vulnerabilities faster than humans is already a reality. Before the order, Anthropic’s unreleased model found 6,202 high- or critical-severity vulnerabilities in open source projects over two months, and patching has not kept pace A6·C1. What open source managers need to prepare for is not executive-order compliance but a response system that can handle a patch-processing capacity check, EOL component cleanup, and the EU Cyber Resilience Act reporting obligations that take effect September 11, 2026 — all at once.

1. What the Executive Order Actually Establishes

The executive order consists of five sections, all premised on voluntary cooperation. Section 1 declares a stance of “refusing to stifle innovation through excessive regulation” and an America First approach to cybersecurity, while Section 5 contains standard general provisions. The substantive content sits in the three middle sections A1.

Section 2 addresses strengthening federal and private-sector cyber defense. Within 30 days, it prioritizes defense of national security systems, Department of War systems, and federal civilian systems, and on the same timeline the Treasury Secretary, in consultation with the National Cyber Director, the National Security Agency (NSA), and the Cybersecurity and Infrastructure Security Agency (CISA), forms the AI cybersecurity clearinghouse. A clearinghouse originally refers to an interbank institution for clearing checks — a relay body that gathers, verifies, and distributes information from multiple participants in one place. Here, it takes on the role of coordinating software vulnerability scanning through voluntary cooperation with the AI industry and critical infrastructure operators to eliminate duplication, discovering and verifying vulnerabilities, and prioritizing the fixing and distribution of patches A1.

Section 3 addresses the safe deployment of frontier models. Within 60 days, it establishes a classified benchmarking procedure to assess AI models’ cyberattack capabilities, and the NSA Director determines, based on those results, the threshold for which models qualify as “covered frontier models.” Through a voluntary framework, developers consult with the government on whether their models meet the designated criteria, provide the government with model access up to 30 days before the planned public release date, and jointly select trusted partners who will receive early access. Sec. 3(c) explicitly states that nothing in this section establishes mandatory licensing, pre-approval, or permitting requirements for the development, publication, disclosure, or deployment of new AI models A1.

Section 4 addresses investigation and enforcement. The Attorney General prioritizes enforcement of existing federal criminal law — including18 U.S.C. 1030 (Computer Fraud and Abuse Act) — against unauthorized computer access and damage carried out using AI, and other crimes committed in the process A1.

Figure 1. Policy timeline before and after the executive order(source: official White House documents)

Observers describe the choice of lead agency as unexpected. Given that vulnerability coordination is the function at stake, it would seem natural for CISA or the Office of the National Cyber Director to lead, yet the clearinghouse is led by the Treasury Department. The Council on Foreign Relations (CFR) suggested this may be because Treasury is “one of the few agencies with institutional capacity remaining,” while the Atlantic Council flagged the risk of overlap with existing vulnerability coordination frameworks B4·B5. The key term “covered frontier model” is also left undefined in the text. It will be determined as a result of the classified benchmarking, and WilmerHale expects this definition to be the focus of agency rulemaking over the coming months B2.

2. Why Now

The direct backdrop to the executive order is Claude Mythos Preview, which Anthropic announced on April 7, 2026. This unreleased model scored 83.1% on the vulnerability-reproduction benchmark CyberGym (up from 66.6% for the prior model), and rather than a general release, Anthropic chose Project Glasswing, opening access only to 12 partners including AWS, Apple, Google, and Microsoft A6. In under two months, participating organizations identified more than 10,000 high- or critical-severity vulnerabilities. Anthropic’s own scans alone turned up 23,019 issues across more than 1,000 open source projects, of which 6,202 were high or critical severity, and an independent security firm verified a sample of 1,752 and confirmed that more than 90% were genuine vulnerabilities C1·C2. Notable examples include a remote crash flaw that had lain dormant in OpenBSD for 27 years, a 16-year-old flaw in FFmpeg that had survived 5 million automated tests, and a privilege-escalation chain in the Linux kernel A6.

This process revealed a sharp mismatch between the speed of finding vulnerabilities and the speed of fixing them. Anthropic itself stated that “the bottleneck to fixing these bugs is human capacity to triage, report, and design and ship patches,” and as open source maintainers became that bottleneck, it began collaborating with OpenSSF’s Alpha-Omega project C1·C2. Bruce Schneier assessed that, for now, “discovery for fixing” remains easier than “discovery for exploitation,” opening a window favorable to defenders — but that this window is temporary, and an era of automated zero-day discovery will arrive before we finish preparing for it. He also noted, citing the security firm Aisle’s reproduction of some results with older, publicly available models, that this capability is not the exclusive property of any one company C3.

The executive order is the US government’s response to this situation. The clearinghouse is the government’s plan to coordinate at a national level what had been done individually in the private sector, as with Glasswing — using AI to find and verify vulnerabilities and coordinate patches A1·B5.

3. What This Means for Corporate Open Source Managers

3.1 A Document That Never Says “Open Source”

Neither the executive order’s text nor the White House fact sheet contains the phrase “open source” anywhere A1·A2. Viewed favorably, this means there is no regulatory burden. The order imposes no obligations on open source developers or open-weight model distributors, and Sec. 3(c)’s prohibition on licensing covers “development, publication, disclosure, or deployment” of models broadly, so distribution via open weights also falls within its protection A1. The administration’s official stance is consistent with what was stated in the July 2025 AI Action Plan: the choice between open and closed rests entirely with the developer, and the federal government will foster an environment favorable to open models A5.

What remains an open question is the threshold for covered frontier models. Because it is determined through a classified benchmark, it is currently impossible to know what happens if an open-weight model exceeds that threshold. The core mechanism of the voluntary framework — “government access 30 days before release” — is designed for closed models whose release timing can be controlled, and this approach does not translate to open models, whose weights, once released, cannot be recalled. CFR experts have suggested that frontier-level vulnerability-reasoning capability will likely be reproduced in open-weight systems before long, and similar reproduction studies are already being mentioned B5. If the capability spreads to open models, the gap in the voluntary pre-sharing design will become apparent, and further regulatory discussion could then target open models. Companies that internally adopt or fine-tune and deploy open-weight models should watch how the benchmarking procedure and subsequent rulemaking, due by August 1, treat open models.

Open source foundations have also stayed quiet so far. As of the search conducted on 2026-06-10, no statement from the Open Source Initiative (OSI), the Linux Foundation, or OpenSSF regarding this executive order could be found. With no obligations imposed, the incentive to respond immediately appears to have been weak. The closest official position is OSI’s response to the 2025 AI Action Plan public comment period, submitted in March 2025 B7.

3.2 Where the Clearinghouse Meets Corporate Vulnerability Management

The clearinghouse’s three functions — coordinating scans, discovering and verifying vulnerabilities, and prioritizing patch deployment — overlap precisely with the vulnerability management systems that corporate open source organizations (OSPOs or product security teams) already operate A1.

Figure 2. Where the corporate open source manager sits in the clearinghouse and vulnerability information flow(source: Executive Order Sec. 2(d))

Most companies will encounter the clearinghouse as information consumers. Once it is operational, discovery, verification, and patch-priority information for open source component vulnerabilities will flow through a new channel. This effectively adds a US-originated channel to a company’s vulnerability intelligence pipeline and adds a coordinating body that influences patch-priority decisions.

Whether to participate directly in the clearinghouse is a separate decision. Companies in critical infrastructure sectors (energy, finance, healthcare, telecommunications, and the like) are explicitly named as intended participants A1. Participation brings early access to vulnerability information, a voice in patch coordination, and access to the government-supported security tools mentioned in Sec. 2(c)(iii). In exchange, participants take on the legal-review burden that comes with information sharing, and, as Crowell & Moring pointed out, face the uncertainty that liability protection for participants is not specified and the consequences of non-participation are not defined either B3. As WilmerHale anticipates, if the voluntary provisions migrate into federal procurement standards, there is a scenario where participation becomes a de facto precondition for companies doing business with the US government B2. There is no reason to rush a decision before the operational details are published in early July.

3.3 The Most Direct Impact: A Surge in Patch Demand and EOL Risk

Changes already underway independent of the executive order are now being accelerated by it. As AI-driven discovery becomes institutionalized at the national level, backed by federal funding (Sec. 2(e)), the volume of reported vulnerabilities in open source components can only grow. The Glasswing figures gave an early preview of that scale.

The first thing companies run into is throughput. As new CVEs multiply across the open source components in a company’s own products, triage (impact analysis), patch application, and customer communication must scale up together. Organizations relying on manual triage will be the first to accumulate a backlog.

EOL (End-of-Life) components present a deeper problem. AI scans code indiscriminately, whether or not it is still maintained, but patches require a maintainer. As HeroDevs, a commercial long-term support (LTS) vendor, has pointed out, the gap between discovery speed and fix speed opens widest in EOL software. If components remain in inventory for which discovery is accelerating while a fix will never arrive, that risk only grows over time C4. The 27-year-old OpenBSD flaw and the 16-year-old FFmpeg flaw show that the assumption that older, stable components are safer no longer holds A6.

Pressure on the upstream side ultimately becomes the company’s own risk. Anthropic itself confirmed that open source maintainers are becoming the bottleneck in the flood of reports C2. When the maintainer of a core component a company depends on is overwhelmed with triage, it is the company that bears the resulting patch delay. Adding upstream maintenance health (maintainer count, security-response track record, foundation affiliation) as an evaluation criterion for core dependencies, and participating in upstream support such as Alpha-Omega where needed, is a path to reducing that risk.

3.4 Contrast with the EU CRA: Handling Voluntary and Mandatory Regimes at Once

The problem the US clearinghouse addresses — discovering and patching software vulnerabilities — is the same area the EU has made mandatory through the Cyber Resilience Act (CRA — Regulation (EU) 2024/2847).

Category	US Executive Order (2026-06-02)	EU CRA Article 14 (effective 2026-09-11)
Nature	Voluntary cooperation (company chooses to participate)	Legal obligation (applies immediately upon placing on the EU market)
Scope	AI industry, critical infrastructure operators	Manufacturers, importers, and distributors of products with digital elements
Key mechanism	Clearinghouse scan coordination and patch deployment coordination	Staged 24-hour/72-hour/14-day reporting of actively exploited vulnerabilities
Receiving body	Treasury-led clearinghouse (operational details not yet public)	ENISA’s Single Reporting Platform (SRP) and member-state CSIRTs
Non-compliance	No penalty (possible shift to procurement standards is still speculative)	Fines up to €15 million or 2.5% of global annual turnover
Model regulation	Explicit exclusion of mandatory licensing and pre-approval	CRA is a product-security regulation, not an AI model regulation

Table 1. Comparison of US executive order and EU CRA vulnerability reporting regimes(sources: original text of the executive order A1, Regulation (EU) 2024/2847 A7, separate report D1. As of 2026-06-10)

For Korean companies shipping products into both markets, the priority is clear. Whichever regime carries binding force, deadlines, and fines comes first. The CRA Article 14 reporting workflow must be operational by September 11, three months from now, and it has already been confirmed that, because ENISA does not currently offer an SRP integration API, the workflow must be designed as a manual, human-submitted process A7·D1. The US clearinghouse comes next. Still, both regimes run on the same underlying internal capabilities — a component inventory (SBOM), vulnerability triage, a Coordinated Vulnerability Disclosure (CVD) intake channel, and a patch deployment process. A system built to prepare for the CRA becomes the foundation for voluntary participation on the US side, so there is no need to build a separate system twice.

3.5 Policy Divergence: US Voluntary Cooperation, EU Institutionalization

The day after the executive order, on June 3, the European Commission published its Tech Sovereignty package, placing open source at the center of digital policy. Its core elements are mobilizing roughly €2 billion in public and private funding over seven years, establishing an Open Source Maintenance Instrument, and opening up public procurement A8·D2. The two documents, published a day apart, reveal contrasting institutional designs for the same technological landscape. The US model excludes regulation and has government coordinate the private sector’s voluntary capacity; the EU model institutionalizes the open source ecosystem itself through public funding and legal obligation (including the CRA’s steward regime).

Global companies’ open source management policy needs to be built with this divergence as a given. In the US market, they must decide whether to enter the voluntary cooperation channel; in the EU market, they must respond to the obligations of CRA compliance and the steward regime. Since the same team within a company will end up operating both modes, it is more realistic to build market-specific modules on top of shared capabilities than to keep policy documents and response organizations separated by market.

3.6 A Different Axis from AI-Generated Code Management

A separate analysis addressing the inflow of AI-generated code into open source and snippet inspection D3 and this matter both sit at the intersection of AI and open source management, but along different axes. That analysis addressed inflow management — the licensing and provenance problems that arise when AI coding tools bring code fragments not declared as packages into a codebase. What this executive order points to is operations — the response problem in an environment where vulnerabilities in open source components already present in the codebase are being surfaced faster and in greater volume because of AI. AI is now affecting both the stage where code enters and the stage where vulnerabilities surface, and the response systems for both axes need to be checked separately.

4. What to Prepare

Since the executive order makes no direct demands of companies, preparation splits into what to do now and what to watch.

What to Do Now

The starting point is an inventory of your own AI exposure surface. Bring together, in one place, the models you develop or fine-tune internally (especially open-weight-based ones), the AI coding and security tools you’ve adopted, and the current state of AI-generated code that has entered your codebase. This puts you in a position to judge quickly, once the covered-frontier-model criteria take shape after August 1, whether your company falls near that boundary.

Also review your open source vulnerability response system. Check whether SBOMs are current across all products, whether new-CVE triage can absorb a two- to three-fold increase in volume, and whether the CVD intake channel is functioning. This review is the same work as preparing for CRA Article 14 (deadline September 11), so there is no need to spin up a separate project — fold it into CRA preparation D1.

The most urgent item is cleaning up EOL components. Identify end-of-maintenance components in your SBOM, set a schedule for those with an upgrade path, and for those that cannot be removed immediately, arrange a patch source such as commercial LTS or in-house patching. For items where you can demonstrate no impact, document them using Vulnerability Exploitability eXchange (VEX) to reduce the triage burden C4.

Finally, assess the health of critical upstream dependencies. Check the maintainer base size and security-response track record of the upper-level components that your revenue-critical products depend on, and consider support measures such as sponsorship or contribution for projects where a bottleneck is a concern C2.

What to Watch

Item to track	Timing	What to check
Clearinghouse formation announcement	By 2026-07-02	Operating body and participation process, scope of information sharing expected from companies, whether liability protection exists A1·B3
Classified benchmarking and voluntary framework	By 2026-08-01	Contours of the covered-frontier-model threshold, treatment of open-weight models A1·B2
Subsequent rulemaking	Over a period of months	Whether voluntary provisions migrate into federal procurement standards B2
NSPM-11 classified annex and implementation	By early 2026-09	Treatment of open source AI in national security procurement A3
Open source foundation responses	From July onward	Statements and participation approach from OSI, the Linux Foundation, and OpenSSF B7
EU CRA SRP going live	2026-09-11	Reporting workflow going into actual operation (tracked in the separate report D1)

Table 2. Items to track and their timing(as of 2026-06-10)

5. Conclusion

This executive order imposes no new obligations on corporate open source managers, but it is a signal that the premises of the operating environment are shifting. An era in which AI finds open source vulnerabilities in bulk has been demonstrated, and the US government has decided to institutionalize that trend through coordination rather than regulation. Discovery is accelerating while patching still moves at human speed. The only thing companies can control in this gap is the processing capacity of their own inventory. Because the EU CRA reporting obligation taking effect three months from now requires SBOM, triage, and CVD capabilities regardless, preparing for both markets with a single system is the most efficient path. As for the executive order itself, only two dates need to go on the calendar: July 2 (clearinghouse) and August 1 (benchmarking criteria).

References

All URLs were confirmed accessible and matching their cited content on 2026-06-10 (except where noted otherwise).

EU Open Source Strategy: Institutionalizing Open Source for Technological Sovereignty

Haksung Jang — Fri, 05 Jun 2026 00:00:00 +0000

This article was written with Claude Code, and the key facts cited here were cross-checked against primary sources.

Summary
The Communication on European Tech Sovereignty (COM(2026) 503 final), published by the European Commission on June 3, 2026, comes with an attached EU Open Source Strategy. It is the first instance of placing open source at the center of EU digital policy. The strategy sets four goals — leveraging open source for sovereignty, strengthening the ecosystem, opening up public administration, and standards and international cooperation — and calls for the public and private sectors to mobilize approximately €2 billion for open-source-related measures over the next seven years. The aim is to reduce the EU’s dependency structure, under which it spends €264 billion annually on proprietary IT from the United States. Civil society (FSFE) and policy analysts welcomed the direction while pointing to limitations in funding adequacy, the relationship between open standards and open source, the neglect of open hardware, and the practitioner skills gap. For Korean public and corporate practitioners, the opening of EU procurement, open source steward regulation, and the open-source default for the EUDI Wallet are the points to watch directly.

1. Overview

The European Commission announced the technological sovereignty package in Brussels on June 3, 2026. A Communication is not binding legislation but a document that sets out the Commission’s policy direction and planned follow-up actions.A1·A2 The package consists of four interconnected initiatives: Chips Act 2.0 for semiconductors, the Cloud and AI Development Act (CADA), the Open Source Strategy, and a roadmap for energy sector digitalization and AI. The scope of this report is the Open Source Strategy (Chapter 4 of the COM document).A1

The problem the strategy seeks to address is clear. The Draghi Report noted that the EU depends on non-EU suppliers for more than 80% of its digital products and services, infrastructure, and intellectual property.A1 The Open Source Strategy chose open source as the means to reduce this dependency. Europe, the birthplace of Linux, has more than 3 million open source contributors, and nearly half of code commits come from small companies with fewer than 50 employees. The assets exist, but they face structural limitations in scaling and funding.A1

2. Key Content: Four Goals

The strategy combines two tracks of measures: supply-side measures that help EU communities and companies develop and maintain high-quality open source components, and demand-side measures that accelerate adoption in the private and public sectors. It bundles public funding together with market- and demand-driven measures, and was built on more than 1,600 responses received through the Commission’s call for evidence.A1·B3

Figure 1. The four goals of the Open Source Strategy and their representative measures(Source: COM(2026) 503 final, Chapter 4, 2026-06-03)

Leveraging open source for technological sovereignty (Goal i). The Commission is expanding the Open Internet Stack into a shared catalogue of European open source building blocks, and has mobilized €41.3 million through three calls under the Horizon Europe 2026–2027 work programme.A1 Making the EU digital identity ecosystem open source is a central pillar. The EU Digital Identity Regulation (EUDIR) sets a legal default requiring the EUDI Wallet application components to be open source; building on this, the reference implementations of the Identity Wallet (EUID) and the European Business Wallet (EBW) are being developed as open source, with their long-term stewardship transferred to the European Digital Public Infrastructure Foundation.A1 The Commission cooperates with member states through the European Digital Infrastructure Consortium (EDIC) on Digital Commons, and aims to reach 30 million active users of open source collaboration and productivity tools and secure email by 2030.A1

Strengthening the ecosystem (Goal ii). Open source building blocks are mostly maintained through foundations, and most of the funding comes from US and Chinese Big Tech.A1 The open source software steward concept introduced by the Cyber Resilience Act (CRA) is the regulatory pillar of this goal. The Commission is developing a stewardship toolkit to help establish foundations, and supports the establishment of a European Digital Public Infrastructure steward organization that governs EU-funded strategic assets from a single hub. To maintain and secure key components, it is creating a new Open Source Maintenance Instrument, building European capacity to fork projects when needed.A1

Important

The figure of “€350 million for the Open Source Maintenance Instrument,” frequently cited in outside analyses, does not appear in the original COM(2026) 503 text. It is the TechPolicy.Press authors’ own estimate of what the instrument would require, and the original document attaches no amount to it.A1·E1 By contrast, “approximately €500 million for RISC-V” is actually listed in Annex II, but it is recorded as a Chips Joint Undertaking investment and is a separate line item from the Open Source Strategy’s €2 billion budget.A1

Opening up public administration (Goal iii). The “public money, public code” principle has been explicitly written into the strategy.A1·B2 The Commission already operates a Matrix-based communication platform, the openDesk collaboration environment, and Drupal across more than 300 europa.eu sites.A1 In procurement, it is revising tender guidelines so that open source can compete with proprietary solutions, and strengthening the Open Source Programme Office (OSPO) and the EU Public Sector OSPO Network as central hubs.A1·B2

Standards and international cooperation (Goal iv). In the revision of the EU Standardisation Regulation, the Commission is improving cooperation between open source and standardization communities, and providing conditions for specific standards to be implemented as open source. Through the Team Europe approach, EU open source solutions are being deployed to enlargement and partner countries.A1

Governance Structure

Rather than creating new bodies, the strategy weaves together existing governance assets. Three pillars interlock.

Figure 2. How the governance bodies of the Open Source Strategy connect(Source: COM(2026) 503 final, Chapter 4 and Annex II, 2026-06-03)

The Commission’s OSPO (established 2020) and the EU Public Sector OSPO Network, with 25 members from 11 countries, handle the public administration pillar, while the Digital Commons EDIC, established on October 29, 2025, handles the multi-country cooperation pillar.A1·A5 Both converge into the European Digital Public Infrastructure Foundation, currently being established, which will take on long-term stewardship of strategic assets such as EUID and EBW.A1

3. Background and Context

The Open Source Strategy is not a standalone regulation but a policy umbrella layered on top of several pieces of EU legislation. The Interoperable Europe Act (Regulation (EU) 2024/903) defines “open source licence” and underpins public sector reuse,A4 while the CRA (Regulation (EU) 2024/2847) provides the steward regulatory category and voluntary security attestation (Article 25).A3 The AI Act places proportionate obligations on free and open source models, and the EUDIR sets the open-source default for the EUDI Wallet.A1·C1

The watershed in this policy lineage was 2020. The Commission adopted the Open Source Software Strategy 2020–2023 (C(2020) 7149 final) on October 21, 2020, introducing a “think open” culture, and established the Commission’s OSPO as its first action.A5 Since then, code.europa.eu (4,500 users and 1,280 repositories as of May 2026) and the EU Open Source Solutions Catalogue (launched March 2025, 1,047 solutions) have been built.A1 The new strategy explicitly cites these as its foundation.

The “public money, public code” principle originated in a campaign launched by the Free Software Foundation Europe (FSFE) in 2017. The strategy adopted this principle nine years after the campaign began.B4

4. Recent Developments and Timeline

As the announcement was only days ago, developments center on the immediate reactions and the procedures scheduled ahead.

Figure 3. Rollout timeline of the EU Open Source Strategy(Source: COM(2026) 503 final and Commission announcements, as of 2026-06-05)

On the day of the announcement, FSFE issued a cautious welcome. While welcoming the adoption of the “Public Money? Public Code!” principle, Johannes Näder said “the Commission still falls short on concrete goals, milestones, and secured funding,” and Lucas Lasota stated that “implementation is now what matters, and it will require secured long-term funding, meaningful civil society participation, and effective enforcement of the Digital Markets Act."B4

A policy analysis by TechPolicy.Press (Gates, Givropoulou, Karhu, 2026-06-03) assessed the strategy as “Europe’s most meaningful progress yet” while pointing to four gaps.E1 The precedence between open standards and open source remains unsettled, treatment of open hardware is limited to RISC-V and EDA tools, the €2 billion over seven years is insufficient against the €264 billion in annual dependency, and development of practitioner-level contribution, maintenance, and governance capacity remains weak. The law firm Covington also summarized the package’s investment scale and corporate impact on June 4, 2026.E3

The nature of the funding adds to the uncertainty. The €2 billion is not a firmly allocated budget but an aggregate estimate of what the public and private sectors “should mobilize” over seven years.A1 The Open Source Maintenance Instrument, the European Digital Public Infrastructure Foundation, and the voluntary EU assessment framework are all still at the stage of a “we will create” commitment, with no concrete design or amount yet determined.

On the schedule ahead, the package will be reflected in member states’ revisions of their national Digital Decade strategic roadmaps in December 2026, and the proposed revision of the Standardisation Regulation and the legislative processes for CADA and Chips Act 2.0 will flesh out the open source requirements. The Commission discusses progress annually at the Digital Decade Board and reports to the European Parliament every three years.A1

5. Implications and Considerations

This strategy does not apply directly to Korean public agencies and companies, but there are several points worth watching in practice.

The opening of EU public procurement is the most concrete variable. If tender specifications come to include open standards and models, and open source is put in a position to compete with proprietary solutions, Korean software vendors seeking to enter the EU public market will benefit from open-source-friendly proposals and clear licensing.A1·B2 Conversely, this opens up EU procurement opportunities for Korean companies with open-source-based businesses.

Open source steward regulation is a point that companies launching CRA-covered products in the EU need to examine. Security attestation for products relying on open source components (CRA Article 25) and the scope of steward responsibility are expected to be fleshed out through the strategy’s voluntary EU assessment framework, so it is prudent to put a Software Bill of Materials (SBOM) and dependency management framework in place in advance.A1·A3 That the EUDI Wallet and the European Business Wallet default to open source reference implementations is something Korean fintech and authentication providers considering EU digital identity integration should watch.A1

From the perspective of Korean public software policy, the institutionalization path of the “public money, public code” principle and the OSPO Network governance model offer a useful reference. However, since the EU itself has left funding adequacy and practitioner capacity as unresolved challenges, the gap between declaration and implementation also bears watching.B4·E1