2026

• CISA 2026 SBOM Minimum Elements: What to Prepare and Which Tools Fill the Gaps
• What the US AI Executive Order (2026-06-02) Means for Enterprise Open Source Managers
• The EU Open Source Strategy: Institutionalizing Open Source for Tech Sovereignty
• AI-Generated Code: How Far Should Open-Source Scanning Go?
• EU Cyber Resilience Act (CRA) Vulnerability Reporting Obligations — A Research Report for the 2026-09-11 Compliance Date
• Rockchip and FFmpeg: A License Dispute Case Study

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

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 the public 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 decisionC3.

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 standard NOASSERTION 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 textA5. 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 guidanceA10. 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 estimationD1.

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 as pre-build and container and binary scans as post-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 write unknown; 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 writing unknown 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. The screen below comes from the public demo, where a single CycloneDX 1.6 document received from outside is inspected.

Figure 3. The conformance assessment screen in the public demo. All 23 elements are assessed, with the 4 the tool cannot judge separated out for human review (BomLens public demo, FlaskDataService 3.2.0)

• Present, 11 — six SBOM metadata fields (author, data format name and version, timestamp, tool name, SBOM version), four component data fields (name, version, hash algorithm, dependency relationship), and one operational practice (machine-processable data).
• Gap, 8 — author signature, generation context, tool version, component producer, component identifiers, component license, component hash value, and the explicit marking of unknown information.
• 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 the public 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.

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. G7 Cybersecurity Working Group / CISA et al. (2026). Software Bill of Materials for AI — Minimum Elements. Published May 12, 2026, TLP:CLEAR. https://www.cisa.gov/resources-tools/resources/software-bill-materials-ai-minimum-elements. ↩

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 Enterprise Open Source Managers

Summary

The executive order “Promoting Advanced Artificial Intelligence Innovation and Security,” signed on June 2, 2026, imposes no obligations on enterprises. Its substance is the Treasury Department-led AI Cybersecurity Clearinghouse (a relay body that pools, verifies, and distributes vulnerability information, to be established within 30 days) and a voluntary pre-disclosure framework for frontier models (to be designed within 60 days); mandatory licensing and pre-approval are explicitly excluded A1. No provision applies directly to enterprise open source managers either. Still, there is a reason to read this order: the context behind it. AI finding open source vulnerabilities faster than humans do has already become reality. Ahead of the executive order, an unreleased Anthropic 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 is not compliance with the executive order, but a response system that can handle a check of patch-processing capacity, cleanup of end-of-life (EOL) components, and the EU Cyber Resilience Act reporting obligation taking 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” along with an America First cybersecurity posture, and Section 5 contains standard general provisions. The substance is in the three sections in between A1.

Section 2 covers 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 within the same period the Treasury Secretary, in consultation with the National Cyber Director, the National Security Agency (NSA), and the Cybersecurity and Infrastructure Security Agency (CISA), establishes an AI cybersecurity clearinghouse. A clearinghouse originally referred to an interbank facility for exchanging and settling checks; here the term means a relay body that pools, verifies, and distributes information from multiple participants. In this order, it is tasked with coordinating software vulnerability scanning through voluntary cooperation with the AI industry and critical infrastructure operators to eliminate duplication, discovering and verifying vulnerabilities, and prioritizing patch development and deployment A1.

Section 3 covers the safe deployment of frontier models. Within 60 days, it establishes a classified benchmarking process to assess the cyber offensive capability of AI models, and based on the results, the NSA Director sets the threshold for which models qualify as a “covered frontier model.” Through a voluntary framework, developers consult with the government on whether their models meet the designated criteria, provide the government access to the model up to 30 days before the planned public release, and jointly select trusted partners who receive early access. Sec. 3(c) states explicitly 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 covers investigation and enforcement. The Attorney General prioritizes enforcement of existing federal criminal law, including 18 U.S.C. § 1030 (Computer Fraud and Abuse), against unauthorized computer access and damage carried out using AI and other crimes committed in the process A1.

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 40, 'rankSpacing': 45}} }%%
flowchart TD
    A["<b>2023-10-30</b> &nbsp; Biden Executive Order 14110 — first comprehensive AI governance framework"]
    B["<b>2025-01</b> &nbsp; Inauguration Day (01-20): EO 14110 revoked; Executive Order 14179 signed (01-23)"]
    C["<b>2025-07-23</b> &nbsp; America's AI Action Plan released — includes a section encouraging open source and open weights"]
    D["<b>2026-04-07</b> &nbsp; Anthropic announces Mythos Preview and Project Glasswing"]
    E["<b>2026-06-02</b> &nbsp; This executive order signed; Glasswing expands to 150 organizations"]
    F["<b>2026-06-05</b> &nbsp; NSPM-11 — national security AI memorandum"]
    G["<b>2026-07-02</b> &nbsp; 30-day deadline — clearinghouse established, federal systems defended"]
    H["<b>2026-08-01</b> &nbsp; 60-day deadline — classified benchmarking and voluntary framework designed"]
    A --> B --> C --> D --> E --> F --> G --> H
    style E fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

Figure 1. Policy timeline around the executive order (source: official White House documents A1, A2, A3, A4, A5, Anthropic A6, Wiley’s deadline calculation B1. As of 2026-06-10)

The choice of lead agency has drawn comment as unexpected. Looking only at the function of vulnerability coordination, CISA or the Office of the National Cyber Director would seem the natural fit, yet the Treasury Department leads the clearinghouse. The Council on Foreign Relations (CFR) suggested this may be because Treasury is “one of the few agencies with institutional capacity left,” while the Atlantic Council flagged the risk of overlap with existing vulnerability coordination systems B4·B5. The threshold for the key term “covered frontier model” is also left undefined in the text. It will be set based on the classified benchmarking results, and WilmerHale expects defining this threshold to be the focus of agency rulemaking over the coming months B2.

2. Why Now

The direct background to the executive order is Claude Mythos Preview, announced by Anthropic 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 instead of 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 more than 90% were real vulnerabilities C1·C2. Notable examples include a remote crash flaw that lay dormant in OpenBSD for 27 years, a 16-year-old flaw in FFmpeg that had survived 5 million automated test runs, 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 for fixing these bugs is human capacity to triage, report, and design and ship patches,” and once open source maintainers became the bottleneck, it began working with OpenSSF’s Alpha-Omega project C1·C2. Bruce Schneier assessed that, for now, “finding in order to fix” is easier than “finding in order to exploit,” giving defenders a favorable window, but that this window is temporary and that an era of automated zero-day discovery will arrive before we finish preparing for it. He added the caveat that this capability is not any one company’s exclusive property, noting that the security firm Aisle reproduced part of the results using an older public model C3.

The executive order is the US government’s response to this situation. The clearinghouse is a plan for the government to coordinate at a national level what private actors, such as Glasswing, had been doing individually: finding and verifying vulnerabilities with AI and coordinating patches A1·B5.

3. What This Means for Enterprise Open Source Managers

3.1 A Document That Never Says “Open Source”

The term “open source” appears nowhere in the executive order’s text or the White House fact sheet A1·A2. Read favorably, this means no regulatory burden. The order imposes no obligations on open source developers or open-weight model distributors, and because the licensing-ban provision in Sec. 3(c) covers “development, publication, disclosure, and deployment” of a model altogether, distribution by releasing weights also falls within its protection A1. The administration’s official stance remains what it stated in the July 2025 AI Action Plan: the choice between open and closed is entirely up to the developer, and the federal government will create an environment favorable to open models A5.

The open question is the threshold for a covered frontier model. Since it will be set by a classified benchmark, it is not yet possible to know what happens if an open-weight model crosses that threshold. The core mechanism of the voluntary framework, “government access 30 days before release,” is designed around closed models whose release timing can be controlled; it does not fit open models, whose weights, once released, cannot be recalled. CFR’s experts expect frontier-level vulnerability-reasoning capability to be reproduced in open-weight systems before long, and similar reproduction studies are already being cited B5. If this capability spreads to open models, the gap in a design built on voluntary pre-disclosure will become apparent, and further regulatory discussion could then target open models. Enterprises that use open-weight models internally, or fine-tune and deploy them, should watch how the benchmarking process due by August 1 and the rulemaking that follows treat open models.

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

3.2 Where the Clearinghouse Meets Enterprise Vulnerability Management

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

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 50, 'rankSpacing': 60}} }%%
flowchart TB
    GOV["<b>AI Cybersecurity Clearinghouse</b><br/>Treasury-led — in consultation with NSA, CISA, National Cyber Director<br/>(established by 2026-07-02)"]
    VOL["<b>Voluntary participants</b><br/>AI developers (vulnerability-discovery capability), critical infrastructure operators"]
    OSS["<b>Open source maintainers</b><br/>Receive vulnerability reports via coordinated disclosure"]
    ENT["<b>Enterprise open source managers</b><br/>Consume patches, SBOM, CVD"]
    GOV <-->|"Scan coordination, discovery and verification, patch prioritization"| VOL
    VOL --> OSS --> ENT
    GOV -.->|"Recommendations and deployment coordination (operating model undisclosed)"| ENT
    style ENT fill:#e3f2fd,stroke:#1565c0,stroke-width:2px

Figure 2. The position of enterprise open source managers in the clearinghouse and vulnerability information flow (source: analysis based on Executive Order Sec. 2(d) A1. The dotted line marks an operating model not yet disclosed)

Most enterprises will encounter the clearinghouse as consumers of information. Once it is operating, information on the discovery, verification, and patch prioritization of open source component vulnerabilities will flow out through a new channel. This adds one more US-originated channel to a company’s vulnerability intelligence pipeline, and one more coordinating body influencing patch-priority decisions.

Whether to participate directly in the clearinghouse is a separate decision. Companies in critical infrastructure sectors (energy, finance, healthcare, telecommunications, and others) are explicitly named as participants A1. Participating means receiving vulnerability information earlier, having a voice in patch coordination, and gaining access to the government-supported security tools mentioned in Sec. 2(c)(iii). In exchange, a company takes on the legal review burden that comes with information sharing, and, as Crowell & Moring pointed out, inherits the uncertainty of liability protection for participants going unspecified and the consequences of non-participation going undefined B3. If, as WilmerHale forecasts, the voluntary provisions migrate into federal procurement standards, there is a scenario in which participation becomes a de facto prerequisite for companies doing business with the US government B2. There is no reason to rush a decision before the operating model is disclosed in early July.

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

A change already underway independent of the executive order is being accelerated by it. Once AI-based discovery is institutionalized as a national system and backed with federal funding (Sec. 2(e)), the number of vulnerabilities reported in open source components can only increase. The Glasswing figures previewed the scale of this.

The first thing enterprises run into is throughput. As new CVEs increase for open source components included in a company’s products, triage (impact analysis), patch application, and customer communication all have to scale up together. Organizations relying on manual triage are the first to accumulate a backlog.

End-of-life (EOL) components pose a deeper problem. AI scans code indiscriminately, whether or not it is still maintained, but a patch only comes from 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 an inventory still holds components where discovery keeps accelerating but 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 “old and stable means safe” no longer holds A6.

The burden on the upstream side also eventually comes back around as enterprise risk. Anthropic itself has confirmed that open source maintainers are becoming a bottleneck under the flood of reports C2. When the maintainer of a core component a company depends on is buried in triage, it is the company that ends up absorbing the patch delay. Adding maintenance health (number of maintainers, security response history, foundation affiliation) as an evaluation criterion for core dependencies, and participating in upstream support such as Alpha-Omega where warranted, 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 — the discovery and patching of software vulnerabilities — is the same territory the EU has made mandatory through the Cyber Resilience Act (CRA — Regulation (EU) 2024/2847).

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

For a Korean company shipping products into both markets, the priority is clear: the one with binding force, a deadline, and fines comes first. The CRA Article 14 reporting workflow must be operational by September 11, three months out, and there is a confirmed practical constraint that, since ENISA does not currently offer an API to integrate with the SRP, the process has to be designed for manual human submission A7·D1. The US clearinghouse comes after that. That said, both regimes run on the same underlying capabilities: a component inventory (SBOM), vulnerability triage, a coordinated vulnerability disclosure (CVD) intake channel, and a patch deployment process. Since the system built to prepare for the CRA becomes the foundation for voluntary participation on the US side, there is no need to build a separate system twice.

3.5 A Policy Divergence: US Voluntary Cooperation, EU Institutionalization

On June 3, the day after the executive order, the European Commission announced its tech sovereignty package, placing open source at the center of digital policy. Its substance is roughly €2 billion in public and private funding mobilized over seven years, a new Open Source Maintenance Instrument, and the opening up of public procurement A8·D2. Issued a day apart, the two documents show opposing institutional designs for the same technological environment. The US model excludes regulation and has the government coordinate voluntary private-sector capability; the EU model institutionalizes the open source ecosystem itself through public funding and legal obligation, including the CRA’s steward regime.

A global company’s open source management policy has to be built on this divergence. In the US market, it must decide whether to join a voluntary cooperation channel; in the EU market, it must meet the obligations of CRA compliance and the steward regime. Since the same team ends up running both modes within one company, a structure that layers market-specific modules on top of shared capability is more realistic than splitting policy documents and response organizations by market.

3.6 A Different Axis from Managing AI-Generated Code

A separate analysis on the inflow of AI-generated code into open source and snippet screening D3 and this issue both touch AI and open source management, but they sit on different axes. That analysis covered inflow management — the license and provenance problems that arise when AI coding tools bring undeclared code snippets into a codebase. This executive order points to operations — the response problem in an environment where AI makes vulnerabilities in already-present open source components surface faster and in greater numbers. AI now affects both the stage where code comes in and the stage where vulnerabilities surface, and the response systems for the two axes need to be checked separately.

4. Preparation

Since the executive order makes no direct demands of enterprises, 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. Consolidate, in one place, the models developed or fine-tuned in-house (especially open-weight-based ones), the AI coding and security tools adopted, and the current state of AI-generated code that has entered the codebase. The point is to be able to judge immediately, once the covered-frontier-model threshold takes shape after August 1, whether your company falls near that line.

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

The most urgent item is cleaning up EOL components. Identify end-of-life components from the SBOM, set a schedule for those with an upgrade path, and for those that cannot be removed immediately, settle on a patch source such as commercial LTS or an in-house patch. Document items that can be shown not to be affected using Vulnerability Exploitability eXchange (VEX) to reduce the triage burden C4.

Finally, assess the health of core upstream dependencies. Check the maintainer base size and security response history of upstream components that revenue-critical products depend on, and for projects at risk of becoming a bottleneck, consider support measures such as sponsorship or contribution C2.

What to Watch

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

5. Conclusion

This executive order imposes no new obligation on enterprise open source managers, but it signals that the premises of the working 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 speeding up while patching still runs at human speed. In that gap, the only thing a company can control is its own inventory’s processing capacity. Since the EU CRA reporting obligation taking effect three months from now requires SBOM, triage, and CVD capability regardless, preparing for both markets under one system is the most efficient path. As for the executive order itself, it is enough to mark two dates on the calendar: July 2 (the clearinghouse) and August 1 (the benchmarking standard).

References

All URLs were checked for access and content match on 2026-06-10 (except where noted).

A. Primary Sources (Official Government Documents, Party Announcements)

A1. The White House (2026). Promoting Advanced Artificial Intelligence Innovation and Security (Executive Order). Signed 2026-06-02. https://www.whitehouse.gov/presidential-actions/2026/06/promoting-advanced-artificial-intelligence-innovation-and-security/ (accessed 2026-06-10). — The primary source for this report. ↩

A2. The White House (2026). Fact Sheet: President Donald J. Trump Promotes Advanced Artificial Intelligence Innovation and Security. 2026-06-02. https://www.whitehouse.gov/fact-sheets/2026/06/fact-sheet-president-donald-j-trump-promotes-advanced-artificial-intelligence-innovation-and-security/ (accessed 2026-06-10). ↩

A3. The White House (2026). National Security Presidential Memorandum/NSPM-11 — Artificial Intelligence in the National Security Enterprise. 2026-06-05. https://www.whitehouse.gov/presidential-actions/2026/06/national-security-presidential-memorandum-nspm-11/ (accessed 2026-06-10). ↩

A4. The White House (2025). Removing Barriers to American Leadership in Artificial Intelligence (Executive Order 14179). 2025-01-23. https://www.whitehouse.gov/presidential-actions/2025/01/removing-barriers-to-american-leadership-in-artificial-intelligence/ (accessed 2026-06-10). ↩

A5. The White House (2025). Winning the Race: America’s AI Action Plan. 2025-07. https://www.whitehouse.gov/wp-content/uploads/2025/07/Americas-AI-Action-Plan.pdf (accessed 2026-06-10, the relevant passage was verified directly against the PDF original). ↩

A6. Anthropic (2026). Project Glasswing: Securing critical software for the AI era. Announced 2026-04-07 (updated since). https://www.anthropic.com/glasswing (accessed 2026-06-10). ↩

A7. European Parliament and Council (2024). Regulation (EU) 2024/2847 — Cyber Resilience Act. OJ L, 2024/2847, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (accessed 2026-05-12, verified during this workspace’s CRA report fact-check). ↩

A8. European Commission (2026). Communication on European Tech Sovereignty, accompanied by an EU Open Source Strategy. COM(2026) 503 final, 2026-06-03. https://digital-strategy.ec.europa.eu/en/library/communication-european-tech-sovereignty-accompanied-eu-open-source-strategy (accessed 2026-06-10). ↩

B. Legal and Policy Analysis

B1. Wiley Rein LLP (2026). New AI Executive Order Addresses Frontier Models and Cybersecurity Vulnerabilities. https://www.wiley.law/alert-New-AI-Executive-Order-Addresses-Frontier-Models-and-Cybersecurity-Vulnerabilities (accessed 2026-06-10). ↩

B2. WilmerHale (2026). New Executive Order Addressing Early Government Access to Frontier AI Models. 2026-06-02. https://www.wilmerhale.com/en/insights/client-alerts/20260602-new-executive-order-addressing-early-government-access-to-frontier-ai-models (accessed 2026-06-10). ↩

B3. Crowell & Moring LLP (2026). Executive Order Creates Voluntary Regulatory Regime of Frontier AI Models. https://www.crowell.com/en/insights/client-alerts/executive-order-creates-voluntary-regulatory-regime-of-frontier-ai-models (accessed 2026-06-10). ↩

B4. Atlantic Council (2026). Reading between the lines of Trump’s new executive order on AI. https://www.atlanticcouncil.org/dispatches/reading-between-the-lines-of-trumps-new-executive-order-on-ai/ (accessed 2026-06-10). ↩

B5. Council on Foreign Relations (2026). Assessing Trump’s Executive Order on AI Oversight. https://www.cfr.org/articles/assessing-trumps-executive-order-on-ai-oversight (accessed 2026-06-10). ↩

B6. CSO Online (2026). OpenAI responds to White House executive order on AI governance. https://www.csoonline.com/article/4181294/openai-responds-to-white-house-executive-order-on-ai-governance.html (accessed 2026-06-10).

B7. Open Source Initiative (2025). OSI and Apereo Foundation Respond to White House on AI Action Plan. https://opensource.org/blog/osi-and-apereo-foundation-respond-to-white-house-on-ai-action-plan (accessed 2026-06-10). ↩

C. Industry and Security Community

C1. CyberScoop (2026). Anthropic expanding access to Project Glasswing. 2026-06-02. https://cyberscoop.com/anthropic-project-glasswing-expansion-critical-infrastructure-claude-mythos/ (accessed 2026-06-10). ↩

C2. Help Net Security (2026). Anthropic: Claude Mythos identified 10,000+ software flaws. 2026-05-26. https://www.helpnetsecurity.com/2026/05/26/anthropic-project-glasswing-update/ (accessed 2026-06-10). ↩

C3. Schneier, Bruce (2026). On Anthropic’s Mythos Preview and Project Glasswing. Schneier on Security, 2026-04. https://www.schneier.com/blog/archives/2026/04/on-anthropics-mythos-preview-and-project-glasswing.html (accessed 2026-06-10). ↩

C4. HeroDevs (2026). AI Cybersecurity Executive Order 2026: What It Means for EOL Software. https://www.herodevs.com/blog-posts/ai-cybersecurity-executive-order-2026-what-it-means-for-eol-software (accessed 2026-06-10). — Cited with awareness that this is a commercial LTS vendor’s blog post. ↩

D. Related Analysis (This Blog)

D1. EU Cyber Resilience Act (CRA) Vulnerability Reporting Obligations — An Investigative Report on Preparing for the 2026-09-11 Effective Date (updated 2026-06-09). ↩

D2. EU Open Source Strategy: Institutionalizing Open Source for Tech Sovereignty (2026-06-05). ↩

D3. AI-Generated Code: How Far Should Open Source Screening Go? (2026-06-08). ↩

The EU Open Source Strategy: Institutionalizing Open Source for Tech Sovereignty

Summary

The European Commission’s “Communication on European Tech Sovereignty” (COM(2026) 503 final), published on June 3, 2026, comes with an EU Open Source Strategy attached. It is the first time open source has been placed at the center of EU digital policy. The strategy sets four objectives — leveraging open source for sovereignty, strengthening the ecosystem, opening up public administration, and reinforcing standards and international cooperation — and calls for roughly EUR 2 billion in public and private funding to be mobilized for open-source-related measures over the next seven years. The aim is to reduce the EU’s dependence on US proprietary IT, on which it spends an estimated EUR 264 billion annually. Civil society (FSFE) and policy analysts have welcomed the direction while flagging limits: whether the funding is sufficient, how open standards relate to open source, the light treatment of open hardware, and the practitioner skills gap. For Korean public-sector and enterprise practitioners, the points worth watching directly are the opening of EU procurement, the open-source steward regulation, and the open-source default for the EUDI Wallet.

1. Overview

The Commission unveiled its technological sovereignty package in Brussels on June 3, 2026. A Communication is not binding legislation; it is a document setting out the Commission’s policy direction and planned follow-up actions.A1·A2 The package consists of four interlinked initiatives: the Chips Act 2.0 for semiconductors, the Cloud and AI Development Act (CADA), the Open Source Strategy, and a roadmap for digitalizing the energy sector and AI. This report covers only the Open Source Strategy, which forms Chapter 4 of the COM document.A1

The problem the strategy sets out to answer is clear. The Draghi Report found that the EU depends on non-EU suppliers for more than 80% of its digital products, services, infrastructure, and intellectual property.A1 The Open Source Strategy chose open source as the means to reduce that dependence. Europe, the birthplace of Linux, has more than three million open source contributors, and nearly half of all code commits come from companies with fewer than 50 employees. The asset base exists, but it faces structural limits in scaling and funding.A1

2. Core Content: Four Objectives

The strategy combines two tracks of action: supply-side measures that help EU communities and companies develop and maintain high-quality open source components, and demand-side measures that accelerate adoption across the private and public sectors. It pairs public funding 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

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 45, 'rankSpacing': 55}} }%%
flowchart TD
    ROOT["EU Open Source Strategy<br/>COM(2026) 503"]
    O1["Objective (i)<br/>Leveraging open source<br/>for sovereignty"]
    O2["Objective (ii)<br/>Strengthening and fostering<br/>a vibrant ecosystem"]
    O3["Objective (iii)<br/>Open and interoperable<br/>public administration"]
    O4["Objective (iv)<br/>Reinforcing standards and<br/>international cooperation"]
    ROOT --> O1 & O2 & O3 & O4
    O1 --> AC1["Open Internet Stack, open-sourcing<br/>EUID/EBW, 30M users by 2030"]
    O2 --> AC2["Business accelerators, stewardship<br/>toolkit, open source maintenance instrument"]
    O3 --> AC3["Public money, public code<br/>procurement reform, stronger OSPO network"]
    O4 --> AC4["Standardisation Regulation revision,<br/>Team Europe international cooperation"]
    style ROOT fill:#e3f2fd,stroke:#1565c0,stroke-width:2px

Figure 1. The strategy’s four objectives and their headline measures (source: COM(2026) 503 final, Chapter 4, 2026-06-03)

Leveraging open source for sovereignty (Objective i). The Commission is expanding the Open Internet Stack into a shared catalogue of European open source building blocks, and has mobilized EUR 41.3 million across three calls under the Horizon Europe 2026–2027 work programme.A1 Open-sourcing the EU digital identity ecosystem is a core pillar. The EU Digital Identity Regulation (EUDIR) set a legal default requiring the application components of the EUDI Wallet to be open source; building on that, the Commission is developing open source reference implementations of the identity wallet (EUID) and the European Business Wallet (EBW), and transferring their long-term stewardship to the European Digital Public Infrastructure Foundation.A1 It will cooperate with member states through the European Digital Infrastructure Consortium (EDIC) on Digital Commons, with a target of reaching 30 million active users of open source collaboration, productivity, and secure email tools by 2030.A1

Strengthening the ecosystem (Objective ii). Open source building blocks are mostly maintained through foundations, and most of the funding for them comes from US and Chinese big tech.A1 The open source software steward concept introduced by the Cyber Resilience Act (CRA) is the regulatory backbone of this objective. The Commission is developing a stewardship toolkit to help establish foundations, and supporting the creation of a European Digital Public Infrastructure Stewards organization to govern EU-funded strategic assets from a single hub. To maintain and secure key components, it is also setting up an Open Source Maintenance Instrument to build European capacity to fork projects when necessary.A1

[!IMPORTANT] The “EUR 350 million for the Open Source Maintenance Instrument” figure often cited in outside analysis does not appear in the COM(2026) 503 text itself. It is the TechPolicy.Press authors’ own estimate of what the instrument would need; the original document attaches no figure.A1·E1 By contrast, “about EUR 500 million for RISC-V” does appear in Annex II, but it is recorded as a Chips Joint Undertaking investment and is separate from the Open Source Strategy’s EUR 2 billion budget.A1

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

Standards and international cooperation (Objective iv). In its revision of the Standardisation Regulation, the Commission is improving cooperation between open source and standardization communities and creating conditions for certain standards to be implemented in open source. Through a Team Europe approach, it is deploying EU open source solutions to enlargement and partner countries.A1

Governance Structure

Rather than creating new bodies, the strategy weaves together existing governance assets. Three tracks come together.

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 45, 'rankSpacing': 50}} }%%
flowchart TD
    EC["Commission OSPO<br/>(established 2020)"] --> NET["EU Public Sector OSPO Network<br/>(25 members, 11 countries)"]
    EDIC["Digital Commons EDIC<br/>(established 2025-10-29)"] --> FND["European Digital Public<br/>Infrastructure Foundation (in formation)"]
    NET --> FND
    FND --> ASSET["Long-term stewardship of strategic<br/>open source assets: EUID, EBW, etc."]
    style FND fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

Figure 2. How the strategy’s governance bodies connect (source: COM(2026) 503 final, Chapter 4 and Annex II, 2026-06-03; OSPO Network membership as of 2026-05)

The Commission OSPO (established 2020) and the EU Public Sector OSPO Network, with 25 members across 11 countries, cover the public-administration track, while the Digital Commons EDIC, established on October 29, 2025, covers the multi-country cooperation track.A1·A5 Both converge on the European Digital Public Infrastructure Foundation, now 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 standalone regulation but a policy umbrella layered on several EU legal acts. 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 is 2020. On October 21, 2020, the Commission adopted the “Open Source Software Strategy 2020–2023” (C(2020) 7149 final), introducing a “think open” culture, and its first action was to establish the Commission OSPO.A5 That was followed by 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).A1 The new strategy explicitly cites these as its foundation.

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

4. Recent Developments and Timeline

Because the announcement is only days old, developments so far consist of the immediate reaction and the procedural steps ahead.

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 35, 'rankSpacing': 45}} }%%
flowchart TD
    J["<b>2026-01-12</b> &nbsp; Call for evidence opens"]
    F["<b>2026-02-03</b> &nbsp; Call closes (1,600+ responses)"]
    P["<b>2026-06-03</b> &nbsp; COM(2026) 503 published"]
    D["<b>2026-12</b> &nbsp; National roadmaps revised"]
    S["<b>Later</b> &nbsp; Standardisation Regulation revision proposed"]
    J --> F --> P --> D --> S
    style P fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

Figure 3. 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 said “the question now is implementation, which requires secured long-term funding, meaningful civil society participation, and effective enforcement of the Digital Markets Act."B4

TechPolicy.Press’s policy analysis (Gates, Givropoulou, Karhu, 2026-06-03) called the strategy “Europe’s most significant open source advancement to date” while identifying four gaps.E1 The sequencing between open standards and open source remains unsettled, open hardware treatment is confined to RISC-V and EDA tools, the seven-year EUR 2 billion is modest against EUR 264 billion in annual dependence, and practitioner-level contribution, maintenance, and governance capacity-building remain weak. The law firm Covington also summarized the package’s investment scale and business impact on June 4, 2026.E3

The nature of the funding adds to the uncertainty. The EUR 2 billion is not a fixed budget allocation but a combined estimate of what public and private actors “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 at the stage of a commitment to “create,” with no concrete design or figures yet set.

On the timeline ahead, the package will feed into member states’ revision of their national Digital Decade strategy roadmaps in December 2026, and the proposed revision of the Standardisation Regulation together with the CADA and Chips Act 2.0 legislative processes will spell out open source requirements in more detail. The Commission will discuss progress annually in the Digital Decade Board and report to the European Parliament every three years.A1

5. Implications and Considerations

The strategy does not apply directly to Korean public institutions 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 allowed to compete with proprietary solutions, Korean software suppliers seeking to enter EU public markets will need open-source-friendly proposals and clear licensing to compete effectively.A1·B2 Conversely, this widens the opportunity for Korean companies whose business is built on open source to enter EU procurement.

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

From the perspective of Korea’s public software policy, the institutionalization path for the “public money, public code” principle and the OSPO Network governance model are worth studying as reference models. That said, since the EU itself has left funding sufficiency and practitioner capacity as open questions, the gap between declaration and implementation is also worth watching.B4·E1

6. References

A. Primary Legal and Regulatory Texts

A1. European Commission (2026). Communication from the Commission on European Tech Sovereignty, accompanied by an EU Open Source Strategy. COM(2026) 503 final, Brussels, 3.6.2026 (main text and ANNEXES 1–2). The primary source for this report. sources/COM-2026-503-eu-tech-sovereignty.pdf and …-annexes.pdf. Download: https://digital-strategy.ec.europa.eu/en/library/communication-european-tech-sovereignty-accompanied-eu-open-source-strategy (accessed 2026-06-05). ↩

A2. European Commission (2026). Strengthening Europe’s tech sovereignty (press release). 2026-06-03. https://commission.europa.eu/news-and-media/news/strengthening-europes-tech-sovereignty-2026-06-03_en (accessed 2026-06-05). ↩

A3. European Parliament and Council (2024). Regulation (EU) 2024/2847 — Cyber Resilience Act. Official Journal, OJ L, 2024/2847, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (accessed 2026-06-05). ↩

A4. European Parliament and Council (2024). Regulation (EU) 2024/903 — Interoperable Europe Act. Official Journal, OJ L, 2024/903, 22.3.2024. https://eur-lex.europa.eu/eli/reg/2024/903/oj/eng (accessed 2026-06-05). ↩

A5. European Commission (2020). Open Source Software Strategy 2020–2023. C(2020) 7149 final, Brussels, 21.10.2020. https://commission.europa.eu/system/files/2023-02/en_ec_open_source_strategy_2020-2023.pdf (accessed 2026-06-05). ↩

B. Official Publications and Policy Pages from Issuing Bodies

B1. European Commission — Shaping Europe’s digital future (2026). The EU Open Source Strategy (policy page). Updated 2026-06-03. https://digital-strategy.ec.europa.eu/en/policies/open-source-strategy (accessed 2026-06-05).

B2. European Commission (2026). Commission boosts open and interoperable digital ecosystems for public administrations (press release). 2026-06-03. https://commission.europa.eu/news-and-media/news/commission-boosts-open-and-interoperable-digital-ecosystems-public-administrations-2026-06-03_en (accessed 2026-06-05). ↩

B3. European Commission — Shaping Europe’s digital future (2026). Commission opens call for evidence on Open-Source Digital Ecosystems. 2026-01-12 (closed 2026-02-03). https://digital-strategy.ec.europa.eu/en/news/commission-opens-call-evidence-open-source-digital-ecosystems (accessed 2026-06-05). ↩

B4. Free Software Foundation Europe (2026). EU Tech Sovereignty: A milestone for Public Code? Now implementation is key. 2026-06-03. https://fsfe.org/news/2026/news-20260603-01.en.html (accessed 2026-06-05). ↩

C. Standards and Frameworks

C1. European Commission (2024). Regulation (EU) 2024/1689 — Artificial Intelligence Act. Official Journal, OJ L, 2024/1689, 12.7.2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng (accessed 2026-06-05). ↩

C2. European Parliament and Council (2023). Regulation (EU) 2023/2854 — Data Act. Official Journal, OJ L, 2023/2854, 22.12.2023. https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng (accessed 2026-06-05).

D. Academic and Policy Research

D1. Blind, K. et al. (2021). The impact of Open Source Software and Hardware on technological independence, competitiveness and innovation in the EU economy. European Commission. https://digital-strategy.ec.europa.eu/en/library/study-about-impact-open-source-software-and-hardware-technological-independence-competitiveness-and (accessed 2026-06-05).

E. Industry, Law Firm, and Media Analysis (Supplementary)

E1. Gates, N., Givropoulou, A., Karhu, J. (2026). How the EU’s Tech Sovereignty Package Finally Puts Open Source to the Test. TechPolicy.Press, 2026-06-03. https://www.techpolicy.press/how-the-eus-tech-sovereignty-package-finally-puts-open-source-to-the-test/ (accessed 2026-06-05). ↩

E2. TechPolicy.Press (2026). EU Unveils Sweeping Tech Sovereignty Push, Balancing Autonomy with Openness. 2026-06-03. https://www.techpolicy.press/eu-unveils-sweeping-tech-sovereignty-push-balancing-autonomy-with-openness/ (accessed 2026-06-05).

E3. Covington & Burling (2026). EU Tech Sovereignty Package. Global Policy Watch, 2026-06-04. https://www.globalpolicywatch.com/2026/06/eu-tech-sovereignty-package/ (accessed 2026-06-05). ↩

E4. Agence Europe (2026). European Commission seeks to harness open source in its tech sovereignty strategy and develop European alternatives. 2026-06. https://agenceurope.eu/en/bulletin/article/13877/4/european-commission-seeks-to-harness-open-source-in-its-tech-sovereignty-strategy-and-develop-european-alternatives (accessed 2026-06-05).

AI-Generated Code: How Far Should Open-Source Scanning Go?

First, one thing to get straight

There is no quick yes-or-no answer to this question, because the deciding factor is not AI itself — as we will see. AI coding raises the rate at which code fragments enter a codebase without being declared as packages, but it does not change the conditions under which a license obligation arises. So instead of asking “does scanning still matter in the AI era,” it helps to ask “under what conditions does snippet-level scanning matter more, and under what conditions less.”

Snippet scanning and SCA are different things

First, separate the terms so the discussion does not get tangled.

Software Composition Analysis (SCA) refers broadly to identifying the open source that has entered your code and managing its vulnerabilities and licenses. Most SCA looks at declared dependencies, as in the first row of the table. Snippet-level matching is a separate capability that only some commercial tools have: it compares the source code itself against a vast number of open-source projects to find the origin of fragments that were never declared as packages. What this article addresses is not SCA as a whole, but this snippet matching.

How real is the legal risk?

Let us start with cases where AI code snippets led to license-violation disputes.

The best-known case is the Copilot class action filed in November 2022 by open-source developers against GitHub, Microsoft, and OpenAI. In May 2023 the copyright-infringement claim was dismissed for lack of specific examples of copying, and in July 2024 the claim under Section 1202(b) of the Digital Millennium Copyright Act (DMCA) was also dismissed. That provision prohibits removing the copyright management information attached to an original work; the court did not accept the claim, reasoning that Copilot’s output was not sufficiently identical to the original A2. Of the original 22 claims, only two remain: breach of an open-source license and breach of contract A2·A3.

There are facts here that can be read two ways.

On one hand, the defendants in these disputes have all been the vendors who built the AI tools, and there is no publicly reported case of a company being sued merely for using AI-generated code C1. Microsoft also announced, in September 2023, the Copilot Copyright Commitment, under which it will cover defense costs and damages if a paid commercial customer is sued by a third party over the output. This comes with conditions: the customer must not disable the product’s built-in filters and must not deliberately try to generate infringing material B1·C5.

On the other hand, the legal position is not settled. The DMCA issue above has gone to the Ninth Circuit Court of Appeals as an interlocutory appeal — where a specific issue is argued before the appellate court ahead of the trial-court judgment — and as of June 2026 no ruling has issued while the trial-court proceedings are stayed A1. The absence of a reported precedent does not mean there is no risk.

When does a license obligation arise?

One distinction matters here. Being sued and having an obligation to comply with a license are different things. Even if no one sues, the obligation to comply with an open-source license remains. And the moment when that obligation is triggered is what matters.

Copyleft obligations in the GPL family, which require disclosing source, arise when you distribute the software. Merely running it internally is “use,” not “distribution,” so no obligation arises C3·C4. Pure SaaS, which hands code to no one, is likewise outside GPL obligations for the same reason. Two caveats apply.

• AGPL is a stricter license that treats even providing a network service as distribution. If you use an AGPL-licensed component, an obligation to disclose source arises even when you only offer it as a service without handing over the code C3. Such components can be managed by excluding them through internal policy.
• “Internal” must mean used only by your own employees; if distribution later happens through an acquisition or open-sourcing, the problem arises at that point.

The copyrightability of short code is another factor. A few lines of functional code may involve too small an amount of copying to be actionable (de minimis), or may fall outside protection because there is essentially only one way to express the idea (merger doctrine) A4·A5. That said, this is a case-by-case judgment, and since long, creative blocks of code are protected, it is hard to assume every snippet is free.

In practice, small fragments often arrive carrying obligations. Code from Stack Overflow, which developers frequently reuse, is under the CC BY-SA license, which requires attribution and share-alike. Yet one study found that at most 1.8% of GitHub projects used such code in a way compliant with the license C6. Even a small fragment can carry a license obligation, and that obligation is widely unmet.

Does the standard require snippet scanning?

OpenChain ISO/IEC 5230, the international standard for open-source license compliance, focuses on where to place compliance processes, how to assign roles and responsibilities, and how to keep the process sustainable A6. It is a non-prescriptive standard that defines what to achieve while leaving the specific methods to the organization, so it does not mandate any particular technique such as snippet scanning A6·A7. What the standard requires is to identify third-party components and to maintain a Software Bill of Materials (SBOM), the list of those components. What matters for meeting the standard is understanding which components have entered the code; it does not require analyzing the origin of every single fragment. In fact, many widely used SCA tools operate only at the dependency level, without snippet matching.

This reads two ways. It means you can meet the standard without snippet scanning, and at the same time it means there is an area the standard does not cover. Dependency-level scanning cannot see fragments that were copied in or generated by AI without being declared as packages. Snippet matching fills exactly that gap, and some organizations perform it for more thorough intellectual-property management.

When does it matter more?

How much weight to give snippet scanning depends on two conditions a company faces.

First, whether you hand code or binaries directly to customers. When code leaves the company — as with on-premises installed products, mobile apps, SDKs, or embedded device firmware — it counts as distribution, and copyleft obligations can be triggered. Pure SaaS, which hands over no code, carries less of this burden.

Second, whether you undergo external verification. Situations such as M&A due diligence, a large customer’s security audit, regulatory requirements, or an SBOM request that goes down to the snippet level — where someone outside the company actually examines the origin of the code.

The more these two overlap, the more likely a latent obligation turns into a real cost. If you hand over code but there is no occasion for verification, the risk stays latent; if you hand over no code, the obligation rarely arises in the first place. Both conditions are independent of whether AI is used. AI coding increases the inflow when the conditions hold, but it does not create the conditions.

Looking at it by company type

Placing the two conditions above on two axes yields four quadrants.

Figure 1. How much weight snippet scanning deserves, by condition

The top-right quadrant carries the greatest burden: code leaves the company, creating a license obligation, and there is also a trigger — such as M&A due diligence or a customer audit — that actually looks into that obligation. In the top-left, even if an obligation arises, there is no one to check it, so it stays latent. In the bottom two quadrants, there is no distribution at all, so an obligation rarely arises to begin with.

This diagram is a starting point for judgment, not a definitive answer. Even within the same quadrant, the choice can vary depending on the nature of the code involved, the licenses used, and the company’s risk tolerance.

Embedded is a different story

Everything so far assumed software built with a package manager. Software that runs as embedded or firmware — routers, set-top boxes, IoT devices, automotive controllers — is different. It is mostly written in C/C++, and open source is often copied directly into the project as source, without a manifest. When that happens, dependency-level SCA has no manifest to read and sees almost none of the open source.

One thing to distinguish: large components used wholesale, such as the Linux kernel or BusyBox, are usually known to the company. That is not a detection problem but a question of meeting the obligation to disclose source. Snippet scanning is needed in a different case: the small fragments pulled in piecemeal from various open-source projects that no one put on a list. Finding these fragments, which dependency-level SCA cannot see, is the job of snippet scanning.

So in embedded, snippet scanning is closer to a basic means of finding undeclared open-source fragments than a conditional supplement.

Filtering before code comes in

Apart from after-the-fact scanning, there is also a way to block problematic code before it comes in. GitHub Copilot has a setting that blocks suggestions matching public code: it does not show suggestions that match public code at or above a certain length (about 150 characters on average) B2·C2. GitHub has stated that verbatim copying of more than 150 characters happens about 1% of the time, while independent studies report higher rates depending on context. Either way it is not zero, but turning the setting on reduces the inflow of fragments of unclear origin. It costs almost nothing, and it is also a precondition for the vendor indemnity mentioned earlier.

This setting overlaps in purpose with after-the-fact snippet scanning. One finds code after it is in; the other blocks it before it gets in. Which one to use, and how much, is something to decide together with the conditions and costs above.

Putting the inflow paths and inspection methods covered so far in one place looks like this.

Figure 2. Code inflow paths and the methods that catch them

Where the blind spot of dependency-level SCA lies, and how snippet matching fills that spot, is the starting point for this judgment.

Criteria for the decision

There is a reason this decision is not simple. The only practical way to find code fragments that were copied in, or generated by AI, without being declared as packages is snippet matching. Neither dependency-level SCA nor a filter applied at generation time catches all of those fragments. So there is a small but real part that only snippet matching covers. At the same time, in many companies that small part rarely turns into an actual loss, and snippet scanning carries tool costs and review effort. In the end, it is about deciding whether the cost is worth it to close a small but real risk.

Four things to consider:

• Do you send code outside — the more you do, the greater the chance a copyleft obligation actually arises.
• Do you undergo external verification — M&A due diligence or a customer audit can surface an obligation that had been buried.
• How much license risk are you willing to accept — there is no reported lawsuit precedent, but the legal position is not settled either. How you take this uncertainty is a matter of company policy.
• What other checks do you already have — if you already run dependency-level SCA, an AI-tool setting that blocks suggestions matching public code, and a policy of excluding AGPL components, the part snippet scanning would additionally catch shrinks accordingly.

One more point. Snippet scanning is not an all-or-nothing choice. The occasions when someone outside actually examines the origin of code are fairly predictable — M&A due diligence or a large customer’s audit. So one option is to run only dependency scanning and the blocking setting day to day, and have a snippet scan done when such an occasion is expected.

Applying these four factors and this operating approach to your own situation, the answer to how much weight to give snippet scanning will come out differently for each company. The exception is embedded software built without a manifest. There, snippet scanning is not a conditional supplement but a basic means of finding undeclared open-source fragments.

Security vulnerabilities are a separate matter

Everything so far has been about licenses. Security vulnerabilities are a different axis, and you should not apply the conditional conclusion above to them. If vulnerable open source is in your code, it is dangerous whether or not you distribute, and whether or not you are audited — because it is exposed to attack even in internal-only software or a pure-SaaS backend. So vulnerability checking is broadly necessary for almost every company.

There are two main tools for security checking.

• Dependency-level SCA — looks at the name and version of declared open-source libraries and checks them against lists of known vulnerabilities (CVEs) D1. Known vulnerabilities in the libraries AI pulled in are caught here.
• SAST (static analysis) — finds risky coding patterns in the source code itself, regardless of where the code came from. The main security risk in AI code is here. In one study, about 40% of 1,689 programs generated by Copilot contained vulnerabilities D2.

Whether code was copied in or generated by AI, security checking is no different from any other code. SAST handles risky patterns in the code itself, and dependency-level SCA handles known vulnerabilities in the libraries you brought in. Snippet scanning is a feature for finding license origin, not a tool for security checking.

One exception worth noting: a rare case where vulnerable code with a known vulnerability is copied in verbatim, escaping both SAST’s patterns and the dependency list. Catching this requires not the license-oriented snippet feature but a separate check that compares your code directly against signatures of vulnerable code built from CVE patches — vulnerable code clone detection D3. Academic tools and some commercial tools provide this.

Sources

A1. BakerHostetler (2025). Doe v. GitHub, Inc. — The Copilot Litigation. https://www.bakerlaw.com/the-copilot-litigation/ (accessed 2026-06-08). — Claim-by-claim progress of the Copilot class action and its pending status before the Ninth Circuit. ↩

A2. Claburn, T. (2024). Judge dismisses DMCA copyright claim in GitHub Copilot suit. The Register, 2024-07-08. https://www.theregister.com/2024/07/08/github_copilot_dmca/ (accessed 2026-06-08). — Dismissal of the DMCA §1202(b) claim; 2 of the original 22 claims (license breach, breach of contract) remain. ↩

A3. Pearl Cohen (2024). Copyright Claims Against GitHub, Microsoft, and OpenAI Largely Dismissed. https://www.pearlcohen.com/copyright-claims-against-github-microsoft-and-openai-largely-dismissed/ (accessed 2026-06-08). — Overall picture of the dismissed claims and the surviving claims. ↩

A4. Goldstein Patent Law. Understanding the Copyright Merger Doctrine. https://www.goldsteinpatentlaw.com/copyright-merger-doctrine/ (accessed 2026-06-08). — The merger doctrine, which denies copyrightability of functional code. ↩

A5. NYU Journal of Intellectual Property & Entertainment Law. Clarifying the De Minimis Doctrine in Copyright Law. https://jipel.law.nyu.edu/clarifying-the-de-minimis-doctrine-in-copyright-law/ (accessed 2026-06-08). — The de minimis doctrine, under which trivial copying is not actionable. ↩

A6. OpenChain Project. OpenChain ISO/IEC 5230 — License Compliance. https://openchainproject.org/license-compliance (accessed 2026-06-08). — The standard defines processes and roles but does not mandate any specific technique such as snippet scanning. ↩

A7. ISO. ISO/IEC 5230:2020 — Information technology — OpenChain Specification. https://www.iso.org/standard/81039.html (accessed 2026-06-08). — Bibliographic record of the standard. ↩

B1. Microsoft (2023-09-07). Microsoft announces new Copilot Copyright Commitment for customers. https://blogs.microsoft.com/on-the-issues/2023/09/07/copilot-copyright-commitment-ai-legal-concerns/ (accessed 2026-06-08). — IP indemnity for paid commercial customers, conditioned on keeping the built-in filters on. ↩

B2. GitHub. GitHub Copilot (product page). https://github.com/features/copilot (accessed 2026-06-08). — Existence and behavior of the public-code matching filter. ↩

C1. TechTarget. AI lawsuits explained: Who’s getting sued?. https://www.techtarget.com/whatis/feature/AI-lawsuits-explained-Whos-getting-sued (accessed 2026-06-08). — Indication that defendants are concentrated among vendors and that no adopter company has been reported as sued. ↩

C2. Microsoft Community Hub. Demystifying GitHub Copilot Security Controls. https://techcommunity.microsoft.com/blog/azuredevcommunityblog/demystifying-github-copilot-security-controls-easing-concerns-for-organizational/4468193 (accessed 2026-06-08). — The roughly 150-character match threshold of the public-code matching filter and the ~1% copying rate. ↩

C3. Mend.io. The SaaS Loophole In GPL Open Source Licenses. https://www.mend.io/blog/the-saas-loophole-in-gpl-open-source-licenses/ (accessed 2026-06-08). — Copyleft’s distribution trigger, the non-applicability to internal and SaaS use, and the AGPL §13 exception. ↩

C4. Revenera. Understanding the SaaS Loophole in GPL. https://www.revenera.com/blog/software-composition-analysis/understanding-the-saas-loophole-in-gpl/ (accessed 2026-06-08). — Supporting detail on the distribution trigger and the SaaS exception. ↩

C5. TechTarget. Microsoft Copilot Copyright Commitment explained. https://www.techtarget.com/searchenterprisedesktop/tip/Microsoft-Copilot-Copyright-Commitment-explained (accessed 2026-06-08). — Supporting detail on the scope and conditions of the indemnity. ↩

C6. Baltes, S. & Diehl, S. (2019). Usage and Attribution of Stack Overflow Code Snippets in GitHub Projects. Empirical Software Engineering, arXiv:1802.02938. https://arxiv.org/abs/1802.02938 (accessed 2026-06-08). — Empirical study finding that at most 1.8% of GitHub projects used Stack Overflow code (CC BY-SA) in a license-compliant way. ↩

D1. Cycode. What Is Software Composition Analysis (SCA)?. https://cycode.com/blog/what-is-software-composition-analysis-sca/ (accessed 2026-06-08). — How SCA finds vulnerabilities by matching components and versions against CVE/NVD. ↩

D2. Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B., & Karri, R. (2022). Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions. IEEE S&P 2022, arXiv:2108.09293. https://arxiv.org/abs/2108.09293 (accessed 2026-06-08). — About 40% of 1,689 generated programs across 89 scenarios contained vulnerabilities. ↩

D3. Kim, S., Woo, S., Lee, H., & Oh, H. (2017). VUDDY: A Scalable Approach for Vulnerable Code Clone Discovery. IEEE S&P 2017. https://seulbae-security.github.io/pubs/vuddy-sp17.pdf (accessed 2026-06-08). — How vulnerabilities propagate through copied code and remain unpatched after the upstream fix, and how to detect them. ↩

EU Cyber Resilience Act (CRA) Vulnerability Reporting Obligations — A Research Report for the 2026-09-11 Compliance Date

Summary

The EU Cyber Resilience Act (Cyber Resilience Act, CRA — Regulation (EU) 2024/2847) is the EU’s first comprehensive product security regulation, imposing horizontal cybersecurity obligations on every “product with digital elements” (PDE) placed on the EU market. The regulation entered into force on December 10, 2024, and applies in phases. From September 11, 2026, the Article 14 reporting obligations take effect, requiring manufacturers, importers, and distributors to notify ENISA (the European Union Agency for Cybersecurity) and Member State CSIRTs of actively exploited vulnerabilities and severe incidents within a staged 24-hour, 72-hour, and 14-day window. Companies that have not stood up a reporting workflow by this date face fines of up to €15 million or 2.5% of worldwide annual turnover, and Korean companies that place products on the EU market are subject to the obligation immediately. A1, B1, E1

1. Why 2026-09-11 Matters to Korean Companies

September 11, 2026, is the first application date for the CRA’s Article 14 reporting obligations. ENISA’s Single Reporting Platform (SRP) also goes live on this date. A1, B4 The CRA’s remaining essential obligations — CE marking and conformity assessment among them — are not due until December 11, 2027, but the reporting workflow has to be in place 15 months ahead of that.

For Korean companies, the weight of this date comes from the CRA’s legal character. The CRA is not a Directive that Member States transpose into national law; it is a Regulation with direct effect, applying the moment a product enters the EU market, with no national implementing legislation required. A1 A company headquartered in Korea with no EU legal entity, exporting directly, is not exempt. Legacy products — those already placed on the EU market — are covered as well, a point that also warrants attention. E1

As of June 2026, roughly three months remain before the reporting obligation takes effect. ENISA has said it will run a testing period but has not yet announced an official schedule, and has signaled that an operational manual will be available sometime in June 2026. ENISA has also stated explicitly that it does not currently offer an API for SRP integration. B4 Companies that assumed automated integration will need to redesign their reporting process around manual submission to the platform.

2. The Structure of the CRA

2.1 Legislative Background and Timeline

The CRA’s formal title is Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements. First signaled in Commission President Ursula von der Leyen’s State of the Union address in September 2021, the European Commission proposed the legislation on September 15, 2022. The European Parliament adopted it in plenary on March 12, 2024, by a vote of 517 to 12, the Council gave its final adoption on October 10 of the same year, it was signed on October 23, and it was published in the Official Journal of the EU on November 20. It entered into force on December 10, 2024. A1, B1

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 40, 'rankSpacing': 45}} }%%
flowchart TD
    A["<b>2021-09</b> &nbsp; President von der Leyen<br/>signals the CRA in her State of the Union"]
    B["<b>2022-09-15</b> &nbsp; European Commission<br/>proposes legislation (COM(2022)454)"]
    C["<b>2023-11-30</b> &nbsp; Provisional political agreement reached"]
    D["<b>2024-03-12</b> &nbsp; European Parliament plenary adoption<br/>(517 for, 12 against)"]
    E["<b>2024-10-10</b> &nbsp; Council final adoption"]
    F["<b>2024-12-10</b> &nbsp; Entry into force"]
    G["<b>2026-09-11</b> &nbsp; Article 14 reporting obligations<br/>take effect, SRP goes live"]
    H["<b>2027-12-11</b> &nbsp; CRA full application"]
    A --> B --> C --> D --> E --> F --> G --> H
    style G fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

Figure 1. CRA legislative and implementation timeline (source: Regulation (EU) 2024/2847, EC Legislative Train) A1, B1

The open source community’s public positioning during the legislative process was notable. During the 2022-2023 draft stages, the Eclipse Foundation, the Open Source Initiative (OSI), and The Document Foundation, among others, warned that an unclear definition of “commercial activity” could push compliance burdens onto volunteer developers. The provisional agreement of December 2023 introduced the concept of an “open-source steward” along with exemptions, easing some of that concern, but the scope of application to small-scale redistributors remains contested. D1

2.2 Scope of Application (Art. 2-3)

The CRA applies to “products with digital elements” (PDE). This covers hardware and software capable of logical or physical data connection to a device or network, and includes software components placed on the market independently. B3

Some products fall outside the scope. The main exclusions are free and open source software supplied without commercial activity, and products already subject to stricter sector-specific cybersecurity regulation, such as medical devices or automotive systems. Even where existing sector-specific cybersecurity rules apply, the CRA may still apply “complementarily,” so a sector-by-sector judgment is needed. A1, E2

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 40, 'rankSpacing': 50}} }%%
flowchart TD
    A["Is the product placed on the EU market?"] -->|No| Z["Out of scope"]
    A -->|Yes| B["Is it a product with digital elements?"]
    B -->|No| Z
    B -->|Yes| C["Is there commercial activity?<br/>(includes commercial FOSS)"]
    C -->|No| Z2["Out of scope (non-commercial FOSS)"]
    C -->|Yes| D["Does a stricter sector-specific<br/>cybersecurity law already apply?<br/>(e.g., MDR for medical devices)"]
    D -->|Yes| Z3["Out of scope"]
    D -->|No| E["Subject to the CRA"]
    E --> F["Classification:<br/>default / important Class I /<br/>important Class II / critical"]

    style E fill:#fce4ec,stroke:#c2185b
    style F fill:#fce4ec,stroke:#c2185b

Figure 2. CRA applicability decision flow (source: CRA Art. 2-3, Implementing Regulation (EU) 2025/2392) A1, A3

2.3 Phased Implementation

The CRA does not enter into full application at a single point in time.

A1, B3

What has to be in place by September 11, 2026, is not product certification but a vulnerability and incident reporting workflow. CE marking and conformity assessment are due 15 months later, on December 11, 2027.

3. Manufacturer Obligations (Art. 13)

3.1 Annex I Essential Requirements

Article 13 requires manufacturers to meet the essential cybersecurity requirements set out in CRA Annex I. The requirements fall into two groups. A1, B3

Part I — Product security requirements: shipping with no known exploitable vulnerabilities, no default passwords, provision of security updates, application of least-privilege principles, data protection, minimization of the attack surface, resilience by design, and provision of records of access to and modification of personal data.

Part II — Vulnerability handling requirements: identifying and documenting vulnerabilities, maintaining an SBOM, providing patches promptly and free of charge, a Coordinated Vulnerability Disclosure (CVD) policy, reporting exploited vulnerabilities and incidents (Art. 14), and monitoring vulnerabilities across the product’s lifecycle.

No harmonized standards for these requirements have yet been finalized, so companies must implement directly against the CRA’s functional text in the meantime. The CRA Requirements Standards Mapping (2024), jointly published by ENISA and the JRC, maps the requirements to existing standards, with ISO/IEC 30111 (vulnerability handling), ISO/IEC 29147 (vulnerability disclosure), and NIST SP 800-218 (SSDF) serving as the main reference points. B5, C1, C2, C6

3.2 Support Period

Manufacturers must provide security support for the expected product lifetime after market placement, and for at least 5 years in any case. Products with an expected lifetime shorter than 5 years may use that shorter period as the support period. The support period must be clearly indicated on the product, and vulnerability handling and security updates are mandatory throughout it. A1, B3

3.3 SBOM Requirements

CRA Annex I Part II mandates a Software Bill of Materials (SBOM). Manufacturers must generate an SBOM for each release version and keep it in a machine-readable format so it can be produced on request from a Market Surveillance Authority. There is no obligation to disclose the SBOM to third parties, but it must be submitted to the Market Surveillance Authority when requested. A1

SPDX and CycloneDX have become the de facto standard formats. SPDX was standardized as ISO/IEC 5962:2021 (based on SPDX v2.2.1; the current specification is v3.0), C3, C4 and CycloneDX, a specification maintained by OWASP, published ECMA-424 2nd Edition (based on v1.7) on December 10, 2025. C5 As of June 2026, no CRA-level implementing act has established an official SBOM schema. Germany’s Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI) published TR-03183-2 v2.1.0 in August 2025, which is the most practical reference point available today for mapping SBOM fields to CRA alignment. G1

4. Reporting Obligations (Art. 14) — In Effect from 2026-09-11

4.1 Notification Triggers

Article 14 defines two categories of event that trigger a manufacturer’s notification duty. A1, B2

The first is an actively exploited vulnerability. The trigger is not the mere theoretical existence of a vulnerability, but confirmation that an attacker has actually exploited it. The second is a severe incident — an event that has a significant impact on product security by causing, or being liable to cause, serious operational disruption, loss, or damage.

Importers and distributors, too, must notify the manufacturer when they discover non-compliance or become aware of an incident.

4.2 The Three-Tier Deadline (24h/72h/14d)

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 40, 'rankSpacing': 50}} }%%
flowchart TD
    T0["Point of awareness<br/>(actively exploited vuln.<br/>or severe incident)"]
    T1["Within 24 hours — Early Warning"]
    T2["Within 72 hours — Notification"]
    T3["Within 14 days of mitigation<br/>becoming available — final report (vulnerability)"]
    T4["Within 1 month of notification<br/>— final report (incident)"]

    T0 --> T1 --> T2
    T2 --> T3
    T2 --> T4

    style T1 fill:#ffebee,stroke:#c62828
    style T2 fill:#fff3e0,stroke:#ef6c00
    style T3 fill:#e8f5e9,stroke:#2e7d32
    style T4 fill:#e8f5e9,stroke:#2e7d32

Figure 3. CRA Article 14 reporting deadlines (source: CRA Art. 14, EC “CRA — Reporting obligations”) A1, B2

The content required differs at each stage. A1, B2

The CRA text is explicit that the 24-hour deadline does not require the vulnerability to be classified or resolved by then; its purpose is to signal existence as an early warning. Micro and small enterprises may be exempted from fines for missing the 24-hour deadline. A1

4.3 The Single Reporting Platform (Art. 16)

All Article 14 notifications go through the Single Reporting Platform (SRP). Operated by ENISA, a single submission by the manufacturer is automatically routed to the coordinator CSIRT (Computer Security Incident Response Team) of the Member State where the manufacturer’s main establishment is located, and to ENISA. B4, A1

In procuring the SRP, ENISA required a forward-looking architecture capable of integrating with the incident and vulnerability reporting systems under NIS2 and DORA. The design goal is a platform that can interoperate with adjacent regulatory regimes, not just serve the CRA obligation on its own.

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 45, 'rankSpacing': 55}} }%%
flowchart TD
    ID["Importer /<br/>Distributor"]
    M["Manufacturer"]
    SRP["ENISA SRP<br/>(Single Reporting Platform)"]
    CSIRT["Member State<br/>Coordinator CSIRT"]
    ENISA["ENISA"]
    OTHER_CSIRT["Other Member State<br/>CSIRTs"]
    MSA["Market Surveillance<br/>Authority (MSA)"]

    ID -->|"Notify on discovering non-compliance"| M
    M -->|"Art.14 24h/72h/14d"| SRP
    SRP --> CSIRT
    SRP --> ENISA
    CSIRT -->|"Dissemination<br/>(delay conditions apply)"| OTHER_CSIRT
    ENISA --> MSA
    MSA -->|"Corrective or recall order"| M

    style M fill:#e3f2fd,stroke:#1565c0
    style SRP fill:#fff3e0,stroke:#ef6c00
    style ENISA fill:#fff3e0,stroke:#ef6c00
    style CSIRT fill:#fff3e0,stroke:#ef6c00

Figure 4. Stakeholder interaction in the CRA reporting framework (source: CRA Art. 13-16, Delegated Regulation (EU) 2026/881) A1, A2

4.4 Conditions for Delaying Inter-CSIRT Dissemination (Delegated Regulation 2026/881)

Delegated Regulation (EU) 2026/881, adopted December 11, 2025 (published in the Official Journal April 20, 2026), sets out the conditions under which a Member State CSIRT may withhold immediate dissemination of a notification received via the Single Reporting Platform to other CSIRTs. A2 Delay is permitted where an assessment of the notified information’s nature justifies it, where the receiving CSIRT cannot guarantee the confidentiality of the information, or where the Single Reporting Platform itself has been compromised or is temporarily unable to operate. Beyond this, delay is allowed only for the period “strictly necessary,” and only when tools such as the Traffic Light Protocol (TLP) or the Permissible Actions Protocol (PAP) cannot mitigate the risk.

The 24-hour deadline for manufacturers reporting to a CSIRT is unaffected by this Delegated Regulation. What it addresses is the further dissemination step between CSIRTs, adding a security-based safety valve there.

4.5 Concurrent Application with GDPR and NIS2

CRA reporting obligations can arise alongside those of other regulations at the same time. When a vulnerability or incident compromises data that includes personal data, CRA notification does not replace the 72-hour supervisory authority notification obligation under Article 33 of the GDPR (General Data Protection Regulation). A5 The two notifications must go through separate channels and separate recipients — the data protection authority on one side, CSIRTs and ENISA on the other.

The same holds for operators of essential and important services subject to the NIS2 Directive (Directive (EU) 2022/2555) that become aware of a vulnerability or incident in their own products. Both CRA reporting and NIS2 reporting may be required simultaneously. The Digital Omnibus package’s “report once, share many” model is under discussion as a way to consolidate the two reporting obligations, but it has not yet been enacted into law. A4, E2

5. Conformity Assessment and CE Marking (2027-12-11)

Conformity assessment is due December 11, 2027, with the pathway determined by classification. Default-category products may self-assess, issue an EU Declaration of Conformity, and affix CE marking. Important Class I products may self-assess using EU harmonized standards, or opt for third-party evaluation by a Conformity Assessment Body (CAB). Important Class II and critical products require mandatory enhanced review by a CAB. A1, B3

In February 2025, ENISA published CRA Implementation via EUCC and its Applicable Technical Elements, analyzing how EU Common Criteria (EUCC) certification can be used as a pathway for CRA conformity assessment. B6

From June 11, 2026, the provisions on notification of conformity assessment bodies take effect. By this date, each Member State must designate a notifying authority, and the accreditation process for notified bodies to handle third-party conformity assessment must begin so that sufficient capacity is in place by December 11, 2026. B3

Penalties for non-compliance vary by violation type. The most serious violations — failure to meet essential requirements, and breach of the reporting obligations — can draw fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is greater, along with the possibility of an order to withdraw the product from the EU market. A1, E1

6. Mapping to Standards and Frameworks

The CRA specifies only essential requirements and delegates technical detail to harmonized standards. CEN/CENELEC JTC 13 WG 9 is developing European harmonized standards (EN) for the CRA, targeting publication of horizontal standards by August 30, 2026, and vertical standards by October 30, 2026. The horizontal standards take the form of the prEN 40000-1 series: vocabulary (prEN 40000-1-1), principles (prEN 40000-1-2), vulnerability handling (prEN 40000-1-3), and general security requirements (prEN 40000-1-4). The final list of cited standards has not yet been settled, so the table below can be used as a candidate mapping for now. B5

C1, C2, C3, C4, C5, C6, G1, C7

The European Vulnerability Database (EUVD) went live on May 13, 2025, operated by ENISA in implementation of Article 12 of the NIS2 Directive. F1 The EUVD can serve as a primary monitoring source under the CRA’s “vulnerability monitoring” requirement. It uses its own identifier scheme (EUVD-YYYY-NNNNNN) alongside CVE IDs and CVSS scores. It is a separate system from the SRP: the SRP is the channel through which manufacturers notify authorities, while the EUVD is a public database. B4, F2

7. Recent Developments (2025-2026)

Since entering into force in December 2024, the regulatory landscape has taken shape through delegated acts, implementing acts, and guidance documents.

Implementing Regulation (EU) 2025/2392 was adopted November 28, 2025, and entered into force December 21. It finalizes the technical definitions that sort the “important” and “critical” products referenced in CRA Annexes III and IV into 28 categories, distributed across Class I, Class II, and critical. This is the primary legal basis manufacturers use to determine their product’s conformity assessment pathway. A3

Delegated Regulation (EU) 2026/881 was adopted December 11, 2025, and published in the Official Journal on April 20, 2026. It codifies the conditions under which inter-CSIRT dissemination of notifications may be delayed (see §4.4). A2

Guidance has arrived in two stages. The Commission’s first official FAQ was issued December 3, 2025 (updated December 19), setting out — non-bindingly, but for the first time — the scope and recurrence of risk assessment and the concept of “intended purpose.” That was followed by the first draft guidance under CRA Article 26, published March 3, 2026. Roughly a quarter of its 75 pages is devoted to defining open-source stewards, and it also covers remote data processing solutions, free and open source software, the support period, and the interplay between the CRA and other regulations such as NIS2 and DORA. The comment period closed March 31, but as of June 2026 no final version had been published. E3

The open source community’s collective response became visible on April 2, 2024, when seven foundations — the Apache Software Foundation, the Blender Foundation, the Eclipse Foundation, OpenSSL, the PHP Foundation, the Python Software Foundation, and the Rust Foundation — announced they would jointly develop common standards for secure software development. The effort was led by the Eclipse Foundation AISBL in Brussels and grew, on September 24 of the same year, into the Open Regulatory Compliance Working Group (ORC WG), which published a white paper setting out the scope of a steward’s obligations. OpenSSF published its direction for aligning SBOM standards on October 22, 2025. F3, D1

The most persistent point of contention is whether the 24-hour notification requirement actually works. Security researchers, including HackerOne, have repeatedly argued since 2024 that notifying authorities of a vulnerability’s existence before a patch is ready risks exposing an unmitigated vulnerability. E4 Delegated Regulation (EU) 2026/881 only introduced conditions for delaying dissemination between CSIRTs; it left the manufacturer-to-CSIRT 24-hour deadline itself untouched.

8. A Korean Company’s Perspective — What to Do in the Next Three Months

8.1 Determining Applicability

The first step is confirming whether the reporting obligation due September 11, 2026, applies to your company at all. Work through the questions in order: is the product placed on the EU market, is it a product with digital elements, and is a stricter sector-specific cybersecurity law already in force for it? “Placed on the EU market” covers direct sales, resale, and OEM supply alike, and applies even without an EU legal entity if a Korean headquarters exports directly. Any software or hardware capable of data connection to a network or device qualifies as a product with digital elements. If a stricter regime already applies — medical device or automotive safety regulation, for example — the CRA may not apply.

Legacy products are covered too. Many companies overlook that products already placed on the EU market also become subject to the reporting obligation from September 11. E1

8.2 Preparation Steps

No certificate is required by September 11. What is required is a reporting workflow. There must be a human structure and technical connection in place to issue an early warning within 24 hours of becoming aware of a vulnerability or incident, with an on-call rotation, decision-making authority, and a designated external communications contact set up in advance.

A pipeline that automatically generates and retains an SBOM in SPDX or CycloneDX format for every release version is also needed by September 11. BSI TR-03183-2 v2.1.0’s field mapping can serve as a practical reference point. G1

ENISA has stated that it does not currently offer an API for SRP integration (as of June 2026). An operational manual has been promised for release sometime in June, so companies should build a process for manual submission to the platform rather than assuming automated integration, and watch for ENISA’s manual and testing-period announcements.

A process for monitoring the EUVD (https://euvd.enisa.europa.eu) against your company’s own product components is also needed, with the ability to handle both the CVE ID and EUVD-YYYY-NNNNNN identifier schemes.

By December 11, 2027, another step is required: CE marking, conformity assessment, selection of a CAB matching the product’s classification (for Class I and above), and a declaration of conformity once the harmonized standards are published. Companies should track the publication of CEN/CENELEC’s horizontal standards (targeted for 2026-08-30) and vertical standards (targeted for 2026-10-30).

8.3 Comparison with Other Jurisdictions

C6, E2

The CRA’s most distinctive feature is its horizontal application across IoT, software, and embedded systems, combined with direct effect. Korea’s Software Supply Chain Security Guideline 1.0, built on the NIST SSDF, recommends 30 checklist items and an SBOM procedure; because the CRA’s essential requirements align functionally with the SSDF, a system built to the domestic guideline is a reasonable starting point for CRA readiness. That said, the Korean guideline is advisory while the CRA is a legal obligation backed by a fine regime, and the CRA layers a separate reporting obligation on top of it.

9. Conclusions and Recommendations

September 11, 2026, is the date the CRA first imposes a substantive compliance obligation on manufacturers. CE marking and conformity assessment are not due until December 11, 2027, but the reporting workflow has to be complete before then.

For a Korean company, the first priority is confirming whether its products fall under the CRA, and if so, determining which classification — default, important, or critical — applies, using Implementing Regulation (EU) 2025/2392 as the basis. Classification determines the 2027 conformity assessment pathway and how much lead time it requires.

Building the reporting infrastructure and internal playbook comes next. The SRP operational manual has not yet been published, but the human structure and internal procedures can be designed now regardless. Since ENISA has said it will not provide an integration API, companies should set up a manual submission process for the platform and watch for the manual and testing-period announcements.

SBOM pipeline automation needs to be finished by September 11. Without an SBOM automatically generated and retained in SPDX or CycloneDX format for every release version, the software composition information the reporting obligation requires simply will not exist. A1, B2, E2, E4

References

A. Legislative and Regulatory Text (Primary)

A1. European Parliament and Council (2024). Regulation (EU) 2024/2847 of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union, OJ L, 2024/2847, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (accessed: 2026-05-12). ↩

A2. European Commission (2025). Commission Delegated Regulation (EU) 2026/881 of 11 December 2025 supplementing Regulation (EU) 2024/2847 with regard to the conditions for delaying dissemination of notifications of actively exploited vulnerabilities and severe incidents. Published 20 April 2026. https://eur-lex.europa.eu/eli/reg_del/2026/881/oj (accessed: 2026-05-12). ↩

A3. European Commission (2025). Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 laying down technical descriptions of categories of important and critical products with digital elements. OJ L, 2025/2392. https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202502392 (accessed: 2026-05-12). ↩

A4. European Parliament and Council (2022). Directive (EU) 2022/2555 of 14 December 2022 on measures for a high common level of cybersecurity across the Union (NIS2 Directive). OJ L 333, 27.12.2022. https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng (accessed: 2026-05-12). ↩

A5. European Parliament and Council (2016). Regulation (EU) 2016/679 — General Data Protection Regulation (GDPR). OJ L 119, 4.5.2016. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679 (accessed: 2026-05-12). ↩

B. Official Documents from Issuing Bodies

B1. European Commission, DG CNECT (2026). Cyber Resilience Act — Shaping Europe’s digital future. https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act (accessed: 2026-05-12). ↩

B2. European Commission, DG CNECT (2026). Cyber Resilience Act — Reporting obligations. https://digital-strategy.ec.europa.eu/en/policies/cra-reporting (accessed: 2026-05-12). ↩

B3. European Commission, DG CNECT (2024). The Cyber Resilience Act — Summary of the legislative text. https://digital-strategy.ec.europa.eu/en/policies/cra-summary (accessed: 2026-05-12). ↩

B4. ENISA (2026). Single Reporting Platform (SRP). https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp (accessed: 2026-05-12). ↩

B5. ENISA & Joint Research Centre (2024). Cyber Resilience Act Requirements Standards Mapping — Joint Analysis. April 2024. https://www.enisa.europa.eu/publications/cyber-resilience-act-requirements-standards-mapping (accessed: 2026-05-12). ↩

B6. ENISA (2025). Cyber Resilience Act implementation via EUCC and its applicable technical elements. 26 February 2025. https://certification.enisa.europa.eu/publications/cyber-resilience-act-implementation-eucc-and-its-applicable-technical-elements_en (accessed: 2026-05-12). ↩

C. Standards and Frameworks

C1. ISO/IEC (2019). ISO/IEC 30111:2019 — Information technology — Security techniques — Vulnerability handling processes. Edition 2. https://www.iso.org/standard/69725.html (accessed: 2026-05-12). ↩

C2. ISO/IEC (2018). ISO/IEC 29147:2018 — Information technology — Security techniques — Vulnerability disclosure. Edition 2. https://www.iso.org/standard/72311.html (accessed: 2026-05-12). ↩

C3. ISO/IEC (2021). ISO/IEC 5962:2021 — Information technology — SPDX® Specification V2.2.1. https://www.iso.org/standard/81870.html (accessed: 2026-05-12). ↩

C4. The Linux Foundation / SPDX Project (2024). SPDX Specifications (current: v3.0). https://spdx.dev/specifications/ (accessed: 2026-05-12). ↩

C5. OWASP Foundation / Ecma International (2025). CycloneDX Specification v1.7 / ECMA-424, 2nd Edition. ECMA-424 published 2025-12-10. https://cyclonedx.org/specification/overview/ (accessed: 2026-05-12). ↩

C6. Souppaya, M., Scarfone, K., Dodson, D. — NIST (2022). Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. NIST SP 800-218. DOI: 10.6028/NIST.SP.800-218. https://csrc.nist.gov/publications/detail/sp/800-218/final (accessed: 2026-05-12). ↩

C7. OpenSSF Global Cyber Policy Working Group (2026). CRA Standards Map. https://policy.openssf.org/CRA/standards.html (accessed: 2026-06-09). — Used to confirm the numbering and progress of CEN/CENELEC JTC 13 WG 9’s prEN 40000-1 series (horizontal harmonized standards). ↩

D. Academic and Policy Research

D1. OpenSSF Best Practices WG / Global Cyber Policy WG (2025). Cyber Resilience Act (CRA) Brief Guide for Open Source Software (OSS) Developers. Lead author: David A. Wheeler. https://best.openssf.org/CRA-Brief-Guide-for-OSS-Developers.html (accessed: 2026-05-12). ↩

E. Industry and Law Firm Analysis

E1. Bird & Bird LLP (2026). CRA’s phased entry into application starts in September 2026. Bird & Bird Insights. https://www.twobirds.com/en/insights/2026/cra%E2%80%99s-phased-entry-into-application-starts-in-september-2026 (accessed: 2026-05-12). ↩

E2. DLA Piper — Blum, L. & Moylan Burke, L. (2026). Cyber Resilience Act: What you need to know and what you need to be doing. 19 February 2026. https://www.dlapiper.com/en/insights/publications/2026/02/cyber-resilience-act-what-you-need-to-know-and-what-you-need-to-be-doing (accessed: 2026-05-12). ↩

E3. DLA Piper (2026). Cyber Resilience Act: Commission unveils draft implementation guidance. Law in Tech. https://www.dlapiper.com/en-us/insights/publications/law-in-tech/2026/cyber-resilience-act (accessed: 2026-05-12). ↩

E4. HackerOne — Eldering, B. (2026). EU Cyber Resilience Act: Preparing Your VDP for 2026 Reporting Requirements. https://www.hackerone.com/blog/cyber-resilience-act-vdp-2026-reporting-readiness (accessed: 2026-05-12). ↩

F. Press and Official Announcements (Supplementary)

F1. ENISA (2025). Consult the European Vulnerability Database to enhance your digital security! News release, 13 May 2025. https://www.enisa.europa.eu/news/consult-the-european-vulnerability-database-to-enhance-your-digital-security (accessed: 2026-05-12). ↩

F2. European Commission (2025). EU launches a European vulnerability database to boost its digital security. https://digital-strategy.ec.europa.eu/en/news/eu-launches-european-vulnerability-database-boost-its-digital-security (accessed: 2026-05-12). ↩

F3. Eclipse Foundation (2024). The Open Source Community is Building Cybersecurity Processes for CRA Compliance. Life at Eclipse, 2 April 2024. https://eclipse-foundation.blog/2024/04/02/open-source-community-cra-compliance/ (accessed: 2026-05-29). ↩

G. Member State Agency Technical Guides

G1. Bundesamt für Sicherheit in der Informationstechnik (BSI) (2025). Technical Guideline TR-03183-2 v2.1.0 — Cyber Resilience Requirements for Manufacturers and Products, Part 2: Software Bill of Materials (SBOM). August 2025. Summarized in: Sbomify, EU Cyber Resilience Act (CRA) SBOM Requirements. https://sbomify.com/compliance/eu-cra/ (accessed: 2026-05-12). ↩

Rockchip and FFmpeg: A License Dispute Case Study

Hello.

I have put together a summary of the Rockchip and FFmpeg license dispute, which became a hot topic in the embedded Linux industry. I first wrote this article in December 2025, when the repository was taken down. Since then, Rockchip has taken action and the repository was restored. I have thoroughly revised the article to reflect these developments, and replaced the evidence with the actual code that became available for review once the repository reopened.

This case is not just about one company’s mistake. It also shows the kind of supply chain risk that comes with taking an SDK or BSP provided by a hardware vendor and using it as-is, and how a misunderstanding of licensing can inflate a simple fix into a two-year-long task.

1. Overview of the Incident

In December 2025, Rockchip’s GitHub repository rockchip-linux/mpp (Media Process Platform) was disabled. This was in response to a DMCA (Digital Millennium Copyright Act) takedown notice filed by an FFmpeg contributor.

Rockchip has provided a middleware library called mpp for hardware video acceleration on its chipsets (such as the RK3588). The problem is that this library’s stream header parser code came from FFmpeg’s libavcodec. Simply taking the code was not, by itself, the problem; the compliance violation arose from three overlapping acts. Rockchip deleted the original copyright notices, rewrote the headers to make it appear that Rockchip was the author, and redistributed code that had been LGPL 2.1 under Apache-2.0.

The notice specified exactly these three acts, and stated as grounds for infringement that this is “evident from the identical code structure and comments, including commented-out calls to FFmpeg internal functions retained under their original names.”

Timeline

Figure 1. Dispute timeline (Source: DMCA notice, MPP commit history, Issues 530 and 73, Internet Archive. Verified 2026-07-23.)

The exact date the repository reopened was not publicly disclosed. Internet Archive snapshots returned HTTP 451 (Unavailable for Legal Reasons) through March 6, 2026, and new forks began appearing starting March 11, so the reopening is estimated to have occurred sometime in between. The repository was inactive for roughly 10 weeks.

One point worth noting about the DMCA process: it is commonly said that a platform must take content down within a set time after receiving a notice, but 17 U.S.C. §512(c)(1)(C) of the US Copyright Act only uses the term “expeditiously,” with no specific deadline. As a matter of operating policy, GitHub gives repository owners roughly one business day to self-correct when a notice identifies specific files, before taking the repository down.

2. What Was Copied

The notice identified 12 infringing files: 4 related to AV1, 3 related to H.265, and 5 related to VP9. With the repository restored, it became possible to pull the commit as it stood at the time infringement was alleged and compare it directly against the FFmpeg original. Below are the results of that comparison.

Copyright Header Replacement

The header from FFmpeg’s libavcodec/vpx_rac.h:

/*
 * Copyright (C) 2006  Aurelien Jacobs <aurel@gnuage.org>
 *
 * This file is part of FFmpeg.
 *
 * FFmpeg is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2.1 of the License, or (at your option) any later version.
...
*/

The same location in MPP’s mpp/codec/dec/vp9/vpx_rac.h:

/*
*
* Copyright 2015 Rockchip Electronics Co. LTD
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
...
*/

The name of the original author, Aurelien Jacobs, the LGPL terms, and any reference to FFmpeg all disappeared, replaced with an Apache-2.0 header under Rockchip’s name. The original authors of vpx_rac.c, Fiona Glaser, and of vp9data.h, Ronald S. Bultje and Clément Bœsch, likewise vanished without a trace.

Matching Function Bodies

Let’s compare the core function of the VP9 range coder.

FFmpeg libavcodec/vpx_rac.h:

static av_always_inline int vpx_rac_get_prob(VPXRangeCoder *c, uint8_t prob)
{
    unsigned int code_word = vpx_rac_renorm(c);
    unsigned int low = 1 + (((c->high - 1) * prob) >> 8);
    unsigned int low_shift = low << 16;
    int bit = code_word >= low_shift;

    c->high = bit ? c->high - low : low;
    c->code_word = bit ? code_word - low_shift : code_word;

    return bit;
}

MPP mpp/codec/dec/vp9/vpx_rac.c (commit 14667441, as of the time infringement was alleged):

rk_s32 vpx_rac_get_prob(VpxRangeCoder *c, uint8_t prob)
{
    unsigned int code_word = vpx_rac_renorm(c);
    unsigned int low = 1 + (((c->high - 1) * prob) >> 8);
    unsigned int low_shift = low << 16;
    int bit = code_word >= low_shift;

    c->high = bit ? c->high - low : low;
    c->code_word = bit ? code_word - low_shift : code_word;

    return bit;
}

The only changes are dropping the inline specifier and changing the return type from int to rk_s32. The function body is identical down to the whitespace, and the uint8_t parameter type and unsigned int in the body remain exactly as written in FFmpeg.

Traces Left in the Code

Comments unrelated to functionality are exactly what reveal provenance. The following comments remained untouched in the MPP files.

// branchy variant, to be used where there's a branch based on the bit decoded
// rounding is different than vpx_rac_get, is vpx_rac_get wrong?

The first is a word-for-word match with FFmpeg’s vpx_rac.h. The second is a question the FFmpeg developer posed to themselves; the original refers to vp56_rac_get, and MPP simply substituted its own function name while carrying the comment over unchanged. A rhetorical question-style comment like this could not coincidentally appear as an identical sentence in independently written code.

At the top of the file, a description referring to a codec that MPP doesn’t even support was left in place.

/**
 * vp56 specific range coder implementation
 */

In FFmpeg, this description exists because the file is shared across VP5 through VP9, but it carried straight over into MPP, which doesn’t handle VP5 or VP6 at all. There is also a spot where an alignment macro was redefined to do nothing.

#define DECLARE_ALIGNED(n,t,v)      t v

This macro name exists in both FFmpeg and libvpx, so by itself it doesn’t establish provenance. However, where it is used tracks FFmpeg exactly. FFmpeg’s vp56.h declares the first field of its motion vector struct as DECLARE_ALIGNED(4, int16_t, x);, and MPP’s corresponding struct carries this line over verbatim. The equivalent struct in libvpx does not use this macro at all.

A match at this level would be unlikely to survive a substantial similarity analysis under copyright law. Changing type names or macros alone does not make a work independent. This approach is sometimes used when absorbing external open source into an internal codebase, and this case demonstrates exactly the risk that carries.

The Probability Tables Are a Somewhat Different Matter

The codec’s probability tables, however, are an area where snap judgments should be avoided. These figures are constants defined in the VP9 bitstream specification, and comments like /* a/l both not split */ next to the values are not expressions FFmpeg created either. The same wording already appears in libvpx (Google, BSD-family license), the reference implementation of VP9. FFmpeg, too, should be understood as having taken these from libvpx.

So the fact that the comments match does not by itself tell us where they were taken from. Placing the three codebases side by side, the point where they diverge is not the wording but the formatting.

libvpx:

      { 222, 34, 30 },  // a/l both not split

FFmpeg:

            { 222,  34,  30 } /* a/l both not split */,

libvpx places a comma and then attaches a // comment, while FFmpeg places a /* */ comment before the comma and aligns the numbers to two-character width. MPP’s version matches FFmpeg’s format byte-for-byte. While the values and wording trace back to libvpx, the formatting fits the conclusion that the actual copying source was the FFmpeg version.

The reason this distinction matters is clear. In areas where implementing the same algorithm naturally produces similar code, similarity by itself is not grounds for infringement. One has to pin down which version’s specific traces were followed.

3. Why It Took 22 Months

This is the part of the case with the most to learn from. The issue was first made public on February 23, 2024. FFmpeg’s official account posted the callout on X, and on the same day, the developer maintaining the ffmpeg-rockchip fork opened Issue 530 on the MPP repository to relay it. It took 22 months from there to the DMCA notice.

Contrary to what is commonly assumed, Rockchip did not stay silent. The person in charge issued a public apology in February 2024, and continued to respond afterward with statements such as “it’s delayed,” “it’s in progress,” and “the refactor is on hold.” This was a case of responding without correcting.

Rockchip later revealed the reason for the delay.

But after studying the license details, we realised that simply restoring
the LGPL headers would convert the entire MPP library to LGPL-licensed code.
While this is acceptable for dynamically linked libraries, it would mandate
that any project statically linking MPP also adopt the LGPL license.
To avoid this mixed-license scenario, we decided to develop a brand-new parser.

Rockchip’s reasoning was that restoring the LGPL headers would make all of MPP LGPL-licensed, forcing even customer projects that statically link MPP to adopt the LGPL as well. To avoid that outcome, they decided to write a new parser from scratch — but they underestimated the amount of work involved, and progress stalled as it was crowded out by day-to-day work.

This reasoning is only half right. The first part has a basis. If FFmpeg code was incorporated into MPP, MPP becomes a “work based on the Library” as that term is used in LGPL 2.1, and Section 2(c) requires that the entire work be licensed under the terms of the LGPL.

The second part is different. Section 6 provides an exception for combined works, including those using static linking.

6. As an exception to the Sections above, you may also combine or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, ...

A combined work can be distributed under terms of the distributor’s choosing. The conditions are that customers must be permitted to modify it for their own use, reverse engineering for debugging must be permitted, and either a re-linkable form must be provided or a shared library mechanism must be used. A customer company that statically links MPP is not required to release its own product under the LGPL.

Because the license clause was misread, a task that would have ended with restoring the headers instead inflated into a full parser rewrite, and because that task was heavy, it sat neglected for nearly two years. Distribution in a state of violation continued the entire time. This is the kind of way costs balloon when a compliance judgment is wrong.

4. Rockchip’s Response and Remaining Issues

After the DMCA notice, Rockchip moved quickly. Within a little over ten days of the notice, it restored the LGPL headers on the 12 identified files, and then went on to replace the VP9, AV1, and H.265 parsers in turn. In mid-February 2026, it announced that it had “removed all FFmpeg LGPL code” and requested review.

A substantial portion of this was actually carried out. Eight of the 12 identified files disappeared from the repository, and the range coder was replaced with an implementation with an entirely different function naming scheme and structure. Scanning all 778 source files in the repository for FFmpeg-specific identifiers such as ff_vp9_, av_always_inline, AVCodecContext, and libavcodec turned up none. No source file mentions the LGPL either. The only trace left is the title of the restoration commit in the changelog document.

Still, a few things remain.

The identified file vp9data.h was not deleted; it was renamed to vp9d_codec.c. In the commit history, this file’s status is shown as a rename, not a deletion. In the process, the header was changed again. The FFmpeg copyright notice and LGPL terms that the LGPL-restoration commit had added were removed, reverting to sole Rockchip copyright with an Apache-2.0 notice. The two commits were made the same day, three hours apart. Of 1,299 lines, 1,045 remain unchanged, and the probability tables and comments also remain in the FFmpeg formatting seen earlier.

Files not listed in the notice were left untouched. In the hardware abstraction layer’s hal_vp9d_com.c, the VP9 probability tables discussed earlier remain in FFmpeg’s exact formatting. This bears out the caveat the notice attached before its file list: “(and possibly others).”

Whether this portion constitutes infringement is hard to say definitively. Since the values and comment wording trace back to libvpx and the specification document, the scope of copyright protection itself is open to dispute.

Above all, there is no public record that FFmpeg has reviewed or accepted this state of affairs. Issue 530 was closed on April 1, 2026, but it was closed by the third-party fork maintainer who had opened it, not by the FFmpeg project. That is not the same as a release from the rights holder. Neither side has stated a policy on how already-distributed past versions will be handled.

5. Why License Laundering Is Dangerous

It is easy to assume that “code released under Apache-2.0 is safe.” This case shows that Apache-2.0 code with an opaque copyright provenance can actually be a greater risk. This is because it is the code’s actual origin, not its stated license, that determines the obligations that attach to it.

Mapping each violation to the relevant clause looks like this.

Falsely altering attribution is treated differently depending on the country. In Korea and France, this constitutes infringement of the right of attribution, one of the moral rights of authors. US copyright law has no general moral rights regime; the Visual Artists Rights Act (VARA) applies only, and narrowly, to works of visual art.

What the Correct Structure Looks Like

The Linux kernel provides a standard interface called V4L2 (Video for Linux 2) for hardware acceleration. In this structure, FFmpeg is left unmodified in user space, and hardware-dependent code is kept separate in the kernel driver.

Figure 2. Comparison of hardware acceleration integration structures

Because FFmpeg and the kernel driver are cleanly separated into user space and kernel space, there is no longer any reason for a vendor to tear apart and redistribute FFmpeg code itself.

Progress in this direction was led not by Rockchip but by Collabora. Decoder support for the RK3588’s VDPU381 and the RK3576’s VDPU383 was merged into mainline in February 2026 and landed in Linux 7.0 (April 2026). The current scope covers H.264 and H.265, while AV1, VP9, and multi-core decoding remain as follow-up work.

One point of caution: the nyanmisaka/ffmpeg-rockchip fork, commonly mentioned by developers using Rockchip hardware as an alternative, does not replace MPP. This project is an FFmpeg fork that implements hardware acceleration by calling MPP and librga, so it does not avoid MPP’s provenance problem. To escape the dependency on MPP, one must use the mainline V4L2 path.

6. The Allwinner Case, Ten Years Earlier

There is a history of embedded chip vendors repeating the same mistake with multimedia codec licenses. The closest precedent is Allwinner’s CedarX from 2015.

In March 2015, Allwinner put out an “LGPL release,” but in practice it amounted to no more than an API layer wrapping a closed binary. The eventual resolution was that a Cedrus driver, reverse-engineered by the community, was merged upstream. This is structurally similar to how, in the Rockchip case, the V4L2 driver work was led by Collabora.

There are also cases where a license violation led to actual monetary liability. On February 14, 2024, the Paris Court of Appeal ordered damages of 800,000 euros in the lawsuit Entr’ouvert brought against Orange. This consisted of 500,000 euros in economic damages, 150,000 euros for infringement of moral rights, and 150,000 euros in restitution of unjust enrichment, with 60,000 euros in litigation costs added separately. This was the conclusion reached 13 years after the suit was filed in 2011, following a first-instance trial, an appeal, and a remand from the Court of Cassation. This ruling matters because it treated the open source license violation as copyright infringement rather than as a breach of contract.

In Germany, the Hamburg Regional Court held in the 2013 Fantec case that “a supplier’s assurance of license compliance alone does not provide a defense; the distributor must verify it independently.” This applies directly to any company that takes a BSP from an SoC vendor and incorporates it into a product.

7. What Companies Should Check

The same problem may be hiding in an SDK or BSP provided by a vendor. Here are three things to check.

First, a supply-chain license audit. You need to verify that a vendor-supplied library — especially code related to multimedia, graphics, or AI acceleration — retains the original author’s license. Even if a vendor claims Apache-2.0 or MIT, if the internal code came from a GPL or LGPL project, the entire product is exposed to risk. Scanning vendor-supplied code with a source code analysis tool such as Black Duck or FOSSID can surface original license notices or copyright markings left inside. As this case shows, the decisive clue is often found in comments unrelated to functionality.

Second, check whether the vendor’s driver is upstream in the mainline kernel. Code merged into mainline has gone through review and license scrutiny by multiple developers, giving it higher reliability than a vendor’s own self-managed repository. That said, being mainlined and being feature-complete are separate questions, so you should check the scope of support alongside it.

Third, internal development rules. When bringing in external open source, committing changes that delete the copyright header at the top of a file or change it to the company’s own name should never be permitted. This can be read as willful infringement and becomes damaging evidence in any later dispute. If integration is needed, prefer a linking approach, and make it a standing rule to always preserve the original author’s license and copyright notice.

Summary

The Rockchip case shows that releasing source and complying with an open source license are two different things. LGPL code cannot be relicensed under something like Apache-2.0 without the copyright holder’s consent, and deleting copyright notices and changing attribution are infringements in themselves.

The more practical lesson lies in how the delay came about. Because the license clause was misread, a task that should have ended with restoring the headers instead became a full parser rewrite, and its weight left it neglected for nearly two years. License determinations should be made together with legal or compliance teams, and the larger the apparent cost of a remedy looks, the more that determination needs to be double-checked.

Rather than simply trusting software as delivered by a vendor, it is necessary to periodically check, using a source code analysis tool, what licenses and copyright notices are present, and to have a process in place for using those results to sort out the division of responsibility with the vendor.

References

• FFmpeg DMCA Notice on GitHub (2025-12-18)
• rockchip-linux/mpp Issue #530 — LGPL license violation reported by upstream FFmpeg
• HermanChen/mpp Issue #73 — Official explanation from Rockchip
• rockchip-linux/mpp repository
• GNU LGPL 2.1, original text
• 17 U.S.C. §512 (Cornell LII)
• Hackaday: GitHub Disables Rockchip’s Linux MPP Repository After DMCA Request
• Tom’s Hardware: Rockchip Repository Disabled
• Collabora: RK3588 and RK3576 video decoders support merged in the upstream Linux Kernel
• libvpx (VP9 reference implementation)
• CNX Software: Allwinner’s CedarX May Infringe on Open Source Licenses (2015-02-26)
• CNX Software: Allwinner CedarX GPL/LGPL Compliance Update (2015-03-23)
• nyanmisaka/ffmpeg-rockchip

Revised on July 23, 2026 to reflect subsequent developments.