diff --git a/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/github-repository.png b/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/github-repository.png
new file mode 100644
index 0000000000..e8fe4ddeb1
Binary files /dev/null and b/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/github-repository.png differ
diff --git a/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/gitlab-license-excluded-no-license.png b/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/gitlab-license-excluded-no-license.png
new file mode 100644
index 0000000000..af50fb1026
Binary files /dev/null and b/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/gitlab-license-excluded-no-license.png differ
diff --git a/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/gitlab-license-usage.png b/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/gitlab-license-usage.png
new file mode 100644
index 0000000000..8f7189f921
Binary files /dev/null and b/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/gitlab-license-usage.png differ
diff --git a/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/index.md b/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/index.md
index a81da88b58..445c349566 100644
--- a/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/index.md
+++ b/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/index.md
@@ -26,4 +26,56 @@ Measures the contributions of members of a commercial organization using publicl
According to the analysis score, Google is at the forefront, with Microsoft and Red Hat coming next. Samsung is ranked 29th for Korean companies and LG Electronics is ranked 71st.
## License Status used by Major Companies
-See [Open Source License Usage Survey](https://solutionshub.epam.com/blog/post/examining-open-source-license-usage)
+The [Open Source License Usage Survey](https://solutionshub.epam.com/blog/post/examining-open-source-license-usage), drawn from data collected through OSCI, is also worth a look. Measurement was already possible with tools like Google BigQuery, but the results were unreliable because abuse and other invalid data weren't filtered out. Building OSCI made it possible to compile statistics over a set of meaningful GitHub repositories, which makes this data more useful.
+
+The study examined the license choices of new public repositories created on GitHub from early 2018 through mid-2020, and also studied a year of data from GitLab to compare patterns across popular open source hosting platforms.
+
+### The Sharp Rise in New GitHub Repositories
+
+
+It shows that the number of repositories created on GitHub has grown sharply over the past two and a half years. This growth in open source is a trend that deserves particular attention.
+
+
+### License Usage Trends Since 2018
+Looking at repositories created from early 2018, several trends stand out.
+
+- 34% of repositories do not include a license file, which puts their open source status in question.
+- 21% of repositories are not recognized by GitHub as a standard license type. This is usually because the license file contains custom license text, often just a minor edit of standard license text. Finally, and most importantly, Apache 2.0 and MIT are the two most widely used license types, together accounting for more than 35% of all repositories.
+
+
+
+Excluding repositories without a license file, more than half use the Apache 2.0 or MIT license. A third of repositories use some form of custom license text, and the remaining 13% cover a range of licenses, most commonly variants of BSD and the GNU Public License.
+
+
+Repositories continue to be created without a license file despite GitHub's guidance. The data suggests that many individual contributors do not understand the importance of including a license file in an open source project.
+
+
+### License Usage at the Top 5 OSCI-Ranked Companies
+The chart for commercial organizations looks different from the one covering all repositories analyzed on GitHub. Apache 2.0 is by far the most widely used license, followed by custom license text. The MIT license is the only other standard license to gain significant adoption. **Copyleft licenses are barely used.** Finally, a non-trivial number of repositories still have no license file; a manual review of a sample found that most of these are not code repositories at all, but examples or documentation.
+
+
+Looking at each of the top 5 companies individually, the results are interesting, and preferences differ from company to company.
+
+
+
+
+Apache is the most preferred license at Google, IBM, and Red Hat. At Microsoft, most licenses are custom text, with MIT as the next most preferred standard license type. A manual review of some of that custom license text found that it was often actually MIT (for code repositories) or Creative Commons (for documentation).
+
+Intel, by contrast, appears to use a much wider variety of license types, with Apache the most preferred, followed by custom license text and 3-Clause BSD. A manual study of the custom license text in Intel's repositories shows it to be a mix based on Apache 2.0, 3-Clause BSD, and other standard license types.
+
+
+### GitLab Analysis
+Over the 12 months from Q2 2019 through the end of Q1 2020, a pattern emerged that is very different from the GitHub results. In particular, 77.7% of public repositories created in this period have no license file. This again suggests that developers are not aware of the need for, or value of, choosing an open source license. It may also reflect some difference between the users who create open source projects on GitLab and on GitHub, with more individual use relative to commercial use.
+
+
+
+Excluding repositories without a license file, the image below shows MIT as the most popular at 37%, followed by custom license text at 21%, GPL 3.0 at 17%, and Apache 2.0 at 10%. In summary, permissive license types are again the most widely used on GitLab, but MIT leads, and Apache 2.0 usage is much lower than on GitHub. Copyleft licenses hold a similarly small share on both GitLab and GitHub.
+
+
+
+## Conclusion
+This study surfaces a number of interesting findings.
+- Apache 2.0 and MIT are the clear leaders, and the trend toward permissive license types is growing.
+ Copyleft license types see only modest use.
+- The number of repositories created without a license is growing, which suggests that individual developers in particular may not understand the legal aspects of open source.
+- Custom license types are especially widespread among commercial organizations, and in most cases appear to be based on standard license types.
diff --git a/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/license-usage-exclude-no-license.png b/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/license-usage-exclude-no-license.png
new file mode 100644
index 0000000000..8c77246523
Binary files /dev/null and b/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/license-usage-exclude-no-license.png differ
diff --git a/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/license-usage-top5.png b/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/license-usage-top5.png
new file mode 100644
index 0000000000..89dbedbbea
Binary files /dev/null and b/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/license-usage-top5.png differ
diff --git a/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/license-usage.png b/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/license-usage.png
new file mode 100644
index 0000000000..8623f8d994
Binary files /dev/null and b/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/license-usage.png differ
diff --git a/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/license-used-by-company.png b/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/license-used-by-company.png
new file mode 100644
index 0000000000..0cd284f71d
Binary files /dev/null and b/content/en/blog/2021/20210115-opensource-license-used-by-it-companies/license-used-by-company.png differ
diff --git a/content/en/blog/2021/20211123-nipa-opensource-guide/featured-opensource-sw-company-guide.jpg b/content/en/blog/2021/20211123-nipa-opensource-guide/featured-opensource-sw-company-guide.jpg
new file mode 100644
index 0000000000..8254db55cd
Binary files /dev/null and b/content/en/blog/2021/20211123-nipa-opensource-guide/featured-opensource-sw-company-guide.jpg differ
diff --git a/content/en/blog/2021/20211123-nipa-opensource-guide/index.md b/content/en/blog/2021/20211123-nipa-opensource-guide/index.md
new file mode 100644
index 0000000000..4bdf4fe849
--- /dev/null
+++ b/content/en/blog/2021/20211123-nipa-opensource-guide/index.md
@@ -0,0 +1,67 @@
+---
+date: 2021-11-23
+title: "NIPA Publishes Four Guides for Using Open Source Software"
+linkTitle: "NIPA Open Source Guides"
+description: "The National IT Industry Promotion Agency (NIPA) has published four 'NIPA Open Source Software Guides' to help enterprises, institutions, and organizations use open source software safely."
+author: Robin Hwang ([@revfactory](https://github.com/revfactory))
+categories: ["blog"]
+tags: ["NIPA", "Training Material"]
+resources:
+- src: "**.{png,jpg}"
+ title: "Image #:counter"
+ params:
+ byline: "Photo: Robin Hwang"
+---
+
+NIPA has published four guides for using open source software. (Source: https://www.oss.kr/news/show/ef0900db-f5b4-40fb-8745-f1b937fbd8d0)
+
+The four open source software guides cover the following.
+The Corporate Open Source Software Governance Guide was co-authored by current OpenChain KWG steering committee members Haksung Jang, Seoyeon Lee, and Minho Hwang.
+
+## Open Source Software License Guide (Revised Edition)
+[Download the Open Source Software License Guide](https://www.oss.kr/oss_guide/show/a17c94f3-a470-4e1d-8cfe-d5d15d6535f7)
+
+Covers an overview and introduction to open source software licenses, how to comply with license obligations, copyright and patent considerations, license-related checklists, management approaches, notable dispute cases, and frequently asked questions, organized so the core content applicable to a company or organization can be identified and used across a range of situations.
+
+The Open Source Software License Guide gives developers and managers at companies and organizations an easier way to understand the general concepts and key compliance requirements of open source licenses, and provides guidance on the matters they need to review to apply that understanding in practice. It is organized into: open source software concepts and definitions; open source license concepts and obligations; copyright and patent issues in open source software; open source license compatibility and dual licensing; open source license checklists by distribution method; open source license management; open source license dispute cases; and support available for open source license matters. Because the obligations a user must review and apply differ depending on the license, the mode of use, and the distribution method even when using the same open source software, this guide also offers separate tips for each section to help readers identify the content that matters most for their own company or organization and apply it across different situations.
+
+
+
+
+
+## Public Sector Open Source Software Governance Guide
+[Download the Public Sector Open Source Software Governance Guide](https://www.oss.kr/oss_guide/show/824f56c5-8ed7-40cc-84d1-a03fa2f42bb1)
+
+Provides the relevant laws and guidelines, and the considerations and checkpoints to review, at each stage of a public-sector IT project when using open source software: planning, plan development, vendor selection and contracting, project execution, inspection and operation, and performance evaluation.
+
+The Public Sector Open Source Software Governance Guide reflects an analysis of domestic and international open source policy and technology trends, and provides the laws and guidelines that must be checked, along with practical information and approaches, for using and managing open source software when carrying out an IT project in the domestic public sector. Each chapter covers the need for open source software management in IT projects and how to manage open source software in IT projects. The section on the need for management introduces the open source policies and use cases of governments at home and abroad, organizes the relevant laws, guidelines, and commentaries for IT projects, and explains the provisions relevant to open source software management. The section on managing open source software in IT projects introduces a basic management and review process for each stage — planning, plan development, vendor selection and contracting, project execution, inspection and operation, and performance evaluation — provides a list of guidelines and commentaries practitioners can reference at each stage, and offers management factors and review items for checking open source software management.
+
+
+
+
+
+## Corporate Open Source Software Governance Guide
+[Download the Corporate Open Source Software Governance Guide](https://www.oss.kr/oss_guide/show/2f7c25e8-df31-4ad9-9d25-1d8234c322c0)
+
+Explains three cases of using open source software in enterprise software development and delivery — use, contribution, and release — in a way practitioners can apply directly, and closes with guidance on the organizational structure a company needs for open source software governance.
+
+As companies increasingly develop and release software products and services built on open source software, the Corporate Open Source Software Governance Guide provides the guidance needed to establish open source software governance — covering source code management and supply policy, compliance processes, management tools, and organizational structure — as well as how a company can contribute to and release into the community. Each chapter covers using open source software, contributing to open source software, releasing open source software, and the OSPO (Open Source Program Office). Each topic is explained separately from the perspective of the company and of the developer to aid understanding. The company section focuses on what an open source software manager needs to know to establish policy and process, while the developer section explains what a developer at a company needs to use open source software.
+
+
+
+
+
+## Open OS Adoption Guide
+[Download the Open OS Adoption Guide](https://www.oss.kr/oss_guide/show/0e9ad67e-9d2a-4a0a-8f2d-092226e3ea07)
+
+Introduces open operating systems for transitioning office PCs, their types, the adoption process and scope, ongoing maintenance, and case studies, giving practitioners a guide to the overall project plan when considering adoption of an open OS.
+
+The Open OS Adoption Guide addresses the policy of expanding open OS adoption, a topic under active discussion domestically as part of open source software policy, and helps institutions considering adoption understand open operating systems, drawing on real adoption cases to make the guide useful throughout the review and implementation process. Each chapter covers an overview of open OS; open OS adoption case studies; matters to review before adopting an open OS; the project procurement process for adopting an open OS; the open OS maintenance process; and how to use this guide. Drawing on a range of reference models and cases for open OS adoption, it offers guidance on the overall project plan and the procedures and considerations practitioners need when reviewing adoption of an open OS.
+
+
+
+
+
+
+
+---------
diff --git a/content/en/blog/2021/20211123-nipa-opensource-guide/opensource-sw-governance-guide.jpg b/content/en/blog/2021/20211123-nipa-opensource-guide/opensource-sw-governance-guide.jpg
new file mode 100644
index 0000000000..acbd667234
Binary files /dev/null and b/content/en/blog/2021/20211123-nipa-opensource-guide/opensource-sw-governance-guide.jpg differ
diff --git a/content/en/blog/2021/20211123-nipa-opensource-guide/opensource-sw-license-guide.jpg b/content/en/blog/2021/20211123-nipa-opensource-guide/opensource-sw-license-guide.jpg
new file mode 100644
index 0000000000..4770235ddc
Binary files /dev/null and b/content/en/blog/2021/20211123-nipa-opensource-guide/opensource-sw-license-guide.jpg differ
diff --git a/content/en/blog/2021/20211123-nipa-opensource-guide/opensource-sw-openos-guide.jpg b/content/en/blog/2021/20211123-nipa-opensource-guide/opensource-sw-openos-guide.jpg
new file mode 100644
index 0000000000..a5ae9c2ffd
Binary files /dev/null and b/content/en/blog/2021/20211123-nipa-opensource-guide/opensource-sw-openos-guide.jpg differ
diff --git a/content/en/blog/2021/20211212-log4shell/featured-log4j.png b/content/en/blog/2021/20211212-log4shell/featured-log4j.png
new file mode 100644
index 0000000000..4a00e18d38
Binary files /dev/null and b/content/en/blog/2021/20211212-log4shell/featured-log4j.png differ
diff --git a/content/en/blog/2021/20211212-log4shell/index.md b/content/en/blog/2021/20211212-log4shell/index.md
new file mode 100644
index 0000000000..14a6a0a9c1
--- /dev/null
+++ b/content/en/blog/2021/20211212-log4shell/index.md
@@ -0,0 +1,93 @@
+---
+date: 2021-12-12
+title: "The Log4j 2 Security Vulnerability Incident (Log4Shell)"
+linkTitle: "Log4Shell RCE"
+description: "A summary of the open source security issue known as Log4Shell."
+author: Robin Hwang ([@revfactory](https://github.com/revfactory))
+categories: ["blog"]
+tags: ["log4j", "Open Source Security"]
+resources:
+- src: "**.{png,jpg}"
+ title: "Image #:counter"
+ params:
+ byline: "Photo: Robin Hwang"
+---
+
+A vulnerability in Apache Log4j 2 ([CVE-2021-44228, NVD](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228)) could lead to further damage such as malware infection, prompting urgent security update measures worldwide (2021.12.10). This post summarizes the related details.
+
+### Log4j
+Log4j is an open source project from the Apache Software Foundation, used for logging purposes in most Java-based web services.
+
+
+
+### Timeline
+- 2021.11.24 First discovered by the Alibaba Cloud security team ([Apache announcement](https://logging.apache.org/log4j/2.x/security.html))
+- 2021.11.30 The Log4j team opened the pull request [Restrict LDAP access via JNDI](https://github.com/apache/logging-log4j2/pull/608) (merged 12/5)
+- 2021.11.30 The Log4j team opened the pull request [no longer formats lookups in messages by default](https://github.com/apache/logging-log4j2/pull/607) (merged 12/5)
+- 2021.12.09 The issue began to spread after a [tweet](https://twitter.com/P0rZ9/status/1468949890571337731) posted the Log4j 2 security PR along with a screenshot reproducing the vulnerability
+- 2021.12.10 The issue gained widespread attention after Minecraft's technical lead announced via [tweet](https://twitter.com/slicedlime/status/1469150993527017483) that the issue had been fixed
+- 2021.12.10 The security vulnerability was patched with the **release of Log4j 2.15.0**
+- 2021.12.12 The Log4j team added [Disable JNDI by default](https://github.com/apache/logging-log4j2/commit/44569090f1cf1e92c711fb96dfd18cd7dccc72ea)
+- 2021.12.12 Log4j 2.15.1 release candidate (JNDI disabled by default)
+
+### Press Coverage (Korea)
+- 2021.12.11 ["Worst vulnerability in the history of computing found" — global security industry stunned](https://www.yna.co.kr/view/AKR20211211035951009?section=popup/print)
+- 2021.12.11 [Worst-ever 'Log4j' security flaw discovered, threatening nearly every server](https://news.naver.com/main/tool/print.naver?oid=092&aid=0002241848)
+- 2021.12.11 [Following reports of "the worst vulnerability in the history of computing," the National Intelligence Service says it has "taken preemptive measures"](https://news.naver.com/main/tool/print.naver?oid=421&aid=0005778626)
+- 2021.12.12 [Ministry of Science and ICT recommends urgent security measures for the "critically vulnerable" open source project Log4j](https://v.kakao.com/v/20211212103345131)
+- 2021.12.12 ["The worst security flaw" — the IT industry thrown into turmoil](https://v.kakao.com/v/20211212180303915)
+- 2021.12.12 [Electronic Times: damage is hard to assess — software details need to be identified](https://v.kakao.com/v/20211212184805464)
+- 2021.12.12 ['Emergency response team' activated amid concerns over IT server hacking](https://v.kakao.com/v/20211212193223921)
+- For coverage outside Korea, search for "**Log4Shell**"
+
+### Response Measures
+- **[Security advisories/notices related to Log4Shell (CVE-2021-44228)](https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592)**
+- 2021.12.06 [Apache notice on 2.15.0 regarding CVE-2021-44228](https://logging.apache.org/log4j/2.x/)
+- 2021.12.10 [Spring, Log4J2 Vulnerability and Spring Boot](https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot)
+- 2021.12.11 [KISA (Korea Internet & Security Agency), advisory on the Apache Log4j 2 security update](https://www.krcert.or.kr/data/secNoticeView.do?bulletin_writing_sequence=36389)
+- 2021.12.12 [Ministry of Science and ICT, urgent security patch recommendation for Apache Log4j 2 web services](https://www.korea.kr/news/pressReleaseView.do?newsId=156485848) (the guidance is the same as above)
+
+### Response Examples (Reference)
+- 2021.12.10 [AWS, Apache Log4j2 Issue](https://aws.amazon.com/ko/security/security-bulletins/AWS-2021-005)
+- 2021.12.11 [How Cloudflare Security responded to the Log4j 2 vulnerability](https://blog.cloudflare.com/how-cloudflare-security-responded-to-log4j2-vulnerability/)
+
+
+### Scope of Impact
+- Log4j versions from 2.0-beta9 up to (but not including) 2.15.x
+
+- [Regarding Spring Boot](https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot)
+ - Spring Boot defaults to a different logging library, Logback, and is affected by the vulnerability only
+ [if the default logging system has been switched to Log4j2](https://docs.spring.io/spring-boot/docs/current/reference/html/howto.html#howto.logging.log4j).
+ - As of 2021.12.12, in Spring Boot 2.6.1 (the latest version at the time), switching to Log4j2
+ without specifying a version installs 1.14.1
+ - Spring Boot 2.6.2, not yet released at the time, was planned to update to Log4j 2.15.x
+
+
+### Known Vulnerability Scanners
+- [Labrador Log4Shell code-level inspection tool](https://labrador.iotcube.com/) (jointly developed by Labrador Labs and the Korea University Security Research Institute)
+- [Huntress Log4Shell Testing Application](https://github.com/huntresslabs/log4shell-tester)
+
+- **Labrador Log4Shell test**
+ - (Step 1) Scan via package management, then (Step 2) scan Jar files
+ - Tested using a Spring Boot 2.6.1 sample project ([GitHub](https://github.com/revfactory/log4j-vulnerability-test)) ([create your own](https://start.spring.io/#!type=maven-project&language=java&platformVersion=2.6.1&packaging=jar&jvmVersion=11&groupId=com.kakao.opensource&artifactId=log4j-vulnerability-test&name=log4j-vulnerability-test&description=Demo%20project%20for%20Spring%20Boot&packageName=com.kakao.opensource.log4j-vulnerability-test&dependencies=web))
+ ```$java -jar LabradorLog4ShellDetector.jar -project [path]```
+ - Scanning the default Spring project: no vulnerability found
+ 
+ - [After switching the logging system to Log4j2](https://docs.spring.io/spring-boot/docs/current/reference/html/howto.html#howto.logging.log4j)
+ 
+
+
+### Attack Method
+- Log4Shell is classified as an RCE (Remote Code Execution) vulnerability.
+- It carries the risk of zero-day attacks (attacks that exploit a publicly disclosed but not yet patched security vulnerability).
+- [See here for details](https://www.hahwul.com/2021/12/11/log4shell-internet-is-on-fire/)
+ 
+ [Image source](https://www.hahwul.com/2021/12/11/log4shell-internet-is-on-fire/)
+
+
+### Government Considers Surveying Open Source Usage
+The government is also considering ways to raise the security level of open source software. A Ministry of Science and ICT official said, "Because there is so much open source in use, similar incidents are likely to occur again," and added, "we are considering follow-up measures, including a usage survey."
+
+(excerpted from [this article](https://v.kakao.com/v/20211212233003588))
+
+---------
diff --git a/content/en/blog/2021/20211212-log4shell/labrador-test1.png b/content/en/blog/2021/20211212-log4shell/labrador-test1.png
new file mode 100644
index 0000000000..3dcf35d7aa
Binary files /dev/null and b/content/en/blog/2021/20211212-log4shell/labrador-test1.png differ
diff --git a/content/en/blog/2021/20211212-log4shell/labrador-test2.png b/content/en/blog/2021/20211212-log4shell/labrador-test2.png
new file mode 100644
index 0000000000..dc3e2dcc0f
Binary files /dev/null and b/content/en/blog/2021/20211212-log4shell/labrador-test2.png differ
diff --git a/content/en/blog/2021/20211212-log4shell/log4shell-exploit-flow.png b/content/en/blog/2021/20211212-log4shell/log4shell-exploit-flow.png
new file mode 100644
index 0000000000..ecfea0c4e0
Binary files /dev/null and b/content/en/blog/2021/20211212-log4shell/log4shell-exploit-flow.png differ
diff --git a/content/en/blog/2023/20230405_offline_checklist/brown.jpg b/content/en/blog/2023/20230405_offline_checklist/brown.jpg
new file mode 100644
index 0000000000..272b233bda
Binary files /dev/null and b/content/en/blog/2023/20230405_offline_checklist/brown.jpg differ
diff --git a/content/en/blog/2023/20230405_offline_checklist/index.md b/content/en/blog/2023/20230405_offline_checklist/index.md
new file mode 100644
index 0000000000..bd31fdebf0
--- /dev/null
+++ b/content/en/blog/2023/20230405_offline_checklist/index.md
@@ -0,0 +1,61 @@
+---
+date: 2023-04-05
+title: "Checklist for Preparing an In-Person Meeting"
+linkTitle: "Checklist for Preparing an In-Person Meeting"
+description: "A checklist of what's needed to prepare an in-person OpenChain Korea Workgroup meeting."
+author: Seoyeon Lee / [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)
+resources:
+- src: "**.{png,jpg}"
+ title: "Image #:counter"
+ params:
+ byline: ""
+---
+
+Hello. Last March 28 was a time everyone will remember. It was our first in-person meeting in three years, since before COVID. Having gone so long without one, I learned that hosting a venue takes more ~~miscellaneous~~ preparation than I expected.
+
+We'll hold another in-person meeting like this at some point, so drawing on this experience, I put together a checklist for preparing one. (_The next host might end up being me again... oops, better not jinx it!_)
+
+
+
+## Before the Meeting
+A list of tasks worth doing before the meeting. It includes work the Planning Sub-group should handle.
+
+- [ ] Set the date and time of the meeting
+- [ ] Recruit speakers
+- [ ] Collect advance registrations — a Google Form is recommended (to gauge how large a venue you'll need and to collect information needed for building access)
+- [ ] Check the visitor access procedure and pre-register visitors if required
+- [ ] Check visitor parking arrangements
+- [ ] Check whether visitors may bring electronic devices
+- [ ] Check what wireless internet is available to visitors
+- [ ] Prepare name badges for attendees (so names and affiliations are easy to recognize)
+- [ ] Prepare venue guidance slides
+- [ ] Send a guidance email about visiting the venue
+- [ ] Check the venue and confirm equipment (desks, chairs, speaker laptop, microphone, sound system, projector, laser pointer, etc.)
+- [ ] Prepare a budget for refreshments and giveaways if needed
+
+
+## Day of the Meeting
+A list of tasks to complete on the day of the meeting, before it starts.
+
+- [ ] Put up event signage (to guide other employees nearby)
+- [ ] Check the microphone, sound system, and projector setup and connections
+- [ ] Prepare the presentation laptop
+- [ ] Set up the venue, adding chairs if needed
+- [ ] Post Wi-Fi instructions (print them out and place them in the venue)
+- [ ] Set up a table for handing out name badges
+- [ ] Prepare refreshments if needed
+- [ ] Have company introduction materials on hand if needed
+- [ ] Guide attendees in and direct them to their seats
+
+
+## After the Event
+A list of tasks to complete after the event ends.
+
+- [ ] Guide attendees out (returning visitor badges, settling parking)
+- [ ] Take down event signage
+- [ ] Tidy up the venue
+
+
+That covers the memorable points I've drawn on to put together this checklist. I hope it helps with preparing future events. If I learn anything new from a future event, I'll update the list again.
+
+Thank you.
diff --git a/content/en/blog/2024/20241223_oracle_rimini/featured-rimini-street.jpeg b/content/en/blog/2024/20241223_oracle_rimini/featured-rimini-street.jpeg
new file mode 100644
index 0000000000..e068bc90bb
Binary files /dev/null and b/content/en/blog/2024/20241223_oracle_rimini/featured-rimini-street.jpeg differ
diff --git a/content/en/blog/2024/20241223_oracle_rimini/index.md b/content/en/blog/2024/20241223_oracle_rimini/index.md
new file mode 100644
index 0000000000..c661d98873
--- /dev/null
+++ b/content/en/blog/2024/20241223_oracle_rimini/index.md
@@ -0,0 +1,127 @@
+---
+date: 2024-12-23
+title: "What the Oracle v. Rimini Street Case Tells Us About the Scope of GPL Derivative Works"
+linkTitle: "Oracle v. Rimini Street Case"
+description:
+author: Haksung Jang / [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)
+license: Apache-2.0
+categories: ["blog"]
+tags: ["Oracle v. Rimini", "GPL"]
+resources:
+- src: "**.{png,jpg}"
+ title: "Image #:counter"
+ params:
+ byline: ""
+---
+
+## **Introduction**
+
+In disputes over software intellectual property infringement, the concept of "derivative works" is critically important. This concept becomes a central issue especially when dealing with open source licenses such as the [GNU General Public License (GPL)](https://www.gnu.org/licenses/gpl-3.0.html). The recent litigation between [Oracle](https://www.oracle.com/) and [Rimini Street](https://www.riministreet.com/) has drawn renewed attention to the legal interpretation of what counts as a derivative work. This article looks at the background of the case, the key rulings, and the implications for open source licensing.
+
+---
+
+## **Background of the Case**
+
+### **PeopleSoft and Rimini Street**
+
+[PeopleSoft](https://www.oracle.com/applications/peoplesoft/) is an ERP (Enterprise Resource Planning) software product from Oracle that supports functions such as human resources management, financial management, and supply chain operations for businesses. PeopleSoft receives regular updates, and Oracle provides these updates to customers as part of its maintenance services.
+
+[Rimini Street](https://www.riministreet.com/) is a company that provides third-party maintenance services to Oracle customers. Rimini operated by generating PeopleSoft updates on behalf of customers, then modifying or distributing them for deployment to customer systems. In the course of this, Oracle alleged that Rimini had violated its copyrights and license terms, and filed suit.
+
+
+
+---
+
+## **The Legal Battle**
+
+### **Initial Ruling: Problems with Process 1.0**
+
+In 2015, the court ruled that the initial operating method Rimini Street used (Process 1.0) infringed Oracle's copyrights. The main problems were as follows:
+
+1. **Cross-use**: Distributing an update generated in one customer's environment to another customer.
+2. **Use of Oracle PeopleTools**: Generating updates using Oracle's own software tools.
+3. **Copying and distribution**: Copying and modifying PeopleSoft files and providing them to multiple customers.
+
+The court found that this approach violated Oracle's license terms and constituted copyright infringement.
+
+---
+
+### **The Introduction of Process 2.0 and New Disputes**
+
+Starting in 2018, Rimini Street discontinued its previous approach and introduced a new process, **Process 2.0**. Process 2.0 has the following characteristics:
+
+- **Work within the customer's environment**: All update generation and testing is performed within each customer's own PeopleSoft environment.
+- **Limited use of automation tools**: Automation tools used previously were minimized or removed.
+- **Preventing cross-use**: Data and work product are kept separate between customers to prevent cross-use issues.
+
+Oracle nonetheless argued that copyright infringement continued to occur under Process 2.0. The main issues were that Rimini performed some work on its own servers and that updates generated in one customer's environment were passed on to another customer.
+
+---
+
+### **The 2023 Ruling by the Federal District Court of Nevada**
+
+In July 2023, the Federal District Court of Nevada found that Rimini Street continued to infringe Oracle's copyrights even under Process 2.0. The court identified the following problems with Rimini's approach:
+
+1. Some work was still performed on Rimini's own servers.
+2. Cross-use occurred during the distribution of updates.
+3. The automation tools Rimini developed were closely tied to Oracle's software.
+
+Accordingly, the court issued a permanent injunction against Rimini.
+
+---
+
+### **The 2024 Appellate Ruling**
+
+In December 2024, the [Ninth Circuit Court of Appeals](https://www.courtlistener.com/opinion/10293082/oracle-international-corporation-v-rimini-street-inc/) reversed part of the Nevada district court's decision and set out a new legal standard:
+
+1. **Narrowing the definition of a derivative work**:
+ - For a work to be a derivative work, Oracle's work must be substantially incorporated into it, either literally or nonliterally.
+ - Merely interacting with or being compatible with PeopleSoft is not, by itself, sufficient to establish a derivative work.
+2. **Reconsidering the cross-use question**:
+ - The court remanded the question of whether transferring an update generated in one customer's environment to another customer violated the license terms, for the district court to reconsider.
+3. **Possible viability of a §117(a) defense**:
+ - The appellate court found that Rimini may have the right, under §117(a), to make copies on behalf of Oracle customers, and ordered this to be reconsidered as well.
+
+---
+
+## **GPL and Derivative Works**
+
+### **How the GPL Interprets Derivative Works**
+
+The [GNU General Public License (GPL)](https://www.gnu.org/licenses/gpl-3.0.html) defines derivative works broadly. It has a "viral" characteristic in that any work combined with GPL-licensed software must also follow the terms of the GPL. According to the [GPL FAQ](https://www.gnu.org/licenses/gpl-faq.html), a work may be considered a derivative work in the following cases:
+
+1. **Modifying code**: Directly modifying the source code of GPL-licensed software
+2. **Incorporating code**: Including part of the code of GPL-licensed software in one's own program
+3. **Linking**: Statically or dynamically linking against a GPL-licensed library
+4. **Plugins or extensions**: Developing a plugin or extension for GPL-licensed software
+
+### **Contrast with the Oracle v. Rimini Ruling**
+
+In this ruling, the appellate court offered a narrower interpretation of what counts as a derivative work:
+
+1. Mere interaction or compatibility does not, by itself, establish a derivative work.
+2. A work is recognized as a derivative work only when the code or expression of the original software is "substantially incorporated."
+
+This could spark legal debate over the scope of GPL applicability, and could have a significant effect on where the line is drawn between open source and commercial software.
+
+---
+
+## **Positive Aspects and Remaining Challenges**
+
+This ruling could have the following positive effects:
+
+1. Clarifying the definition of a derivative work, reducing unnecessary legal disputes.
+2. Giving third-party maintenance service providers greater latitude.
+
+Even so, challenges remain to be resolved:
+
+- Static/dynamic linking: Whether a program statically or dynamically linked against a C library is a derivative work of that library remains unclear. This may depend on how "substantial" the content of the library's header files is.
+- Clarifying the rules governing interaction between open source projects and commercial software.
+
+---
+
+## **Closing**
+
+In *Oracle v. Rimini*, the court's narrower reading of the concept of a "derivative work" gave developers greater freedom, but it also opened the possibility of weakening the reach of open source licenses.
+
+This ruling is a reason for developers to examine the license terms they use more carefully, and it is important to adopt independent design approaches to reduce the risk of legal disputes. Open source is a powerful tool for innovation and collaboration, but it also comes with rules that must be followed.
diff --git a/content/en/blog/2026/20260518_eu-cra/index.md b/content/en/blog/2026/20260518_eu-cra/index.md
new file mode 100644
index 0000000000..54a89471d8
--- /dev/null
+++ b/content/en/blog/2026/20260518_eu-cra/index.md
@@ -0,0 +1,392 @@
+---
+date: 2026-05-18
+lastmod: 2026-06-10
+title: "EU Cyber Resilience Act (CRA) Vulnerability Reporting Obligations — A Research Report for the 2026-09-11 Compliance Date"
+linkTitle: "EU CRA Vulnerability Reporting Obligations"
+description: The EU Cyber Resilience Act (CRA) brings its Article 14 reporting obligations into force on September 11, 2026. This article draws primarily on primary sources to lay out how Korean companies should prepare for the 24-hour, 72-hour, and 14-day notification deadlines, along with SBOM and conformity assessment requirements.
+author: Haksung Jang / [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)
+categories: ["blog"]
+tags: ["CRA", "Cyber Resilience Act", "Vulnerability Reporting", "SBOM", "Cybersecurity", "Software Supply Chain"]
+---
+
+
+{{% alert color="info" %}}
+This article was written with Claude Code, and the key facts cited here were cross-checked against primary sources.
+{{% /alert %}}
+
+
+> **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](#a1), [B1](#b1), [E1](#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](#a1), [B4](#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](#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](#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](#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](#a1), [B1](#b1)
+
+```mermaid
+%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 40, 'rankSpacing': 45}} }%%
+flowchart TD
+ A["2021-09 President von der Leyen
signals the CRA in her State of the Union"]
+ B["2022-09-15 European Commission
proposes legislation (COM(2022)454)"]
+ C["2023-11-30 Provisional political agreement reached"]
+ D["2024-03-12 European Parliament plenary adoption
(517 for, 12 against)"]
+ E["2024-10-10 Council final adoption"]
+ F["2024-12-10 Entry into force"]
+ G["2026-09-11 Article 14 reporting obligations
take effect, SRP goes live"]
+ H["2027-12-11 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](#a1), [B1](#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](#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](#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](#a1), [E2](#e2)
+
+```mermaid
+%%{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?
(includes commercial FOSS)"]
+ C -->|No| Z2["Out of scope (non-commercial FOSS)"]
+ C -->|Yes| D["Does a stricter sector-specific
cybersecurity law already apply?
(e.g., MDR for medical devices)"]
+ D -->|Yes| Z3["Out of scope"]
+ D -->|No| E["Subject to the CRA"]
+ E --> F["Classification:
default / important Class I /
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](#a1), [A3](#a3)
+
+### 2.3 Phased Implementation
+
+The CRA does not enter into full application at a single point in time.
+
+| Date | Obligation | Legal Basis |
+|---|---|---|
+| 2024-12-10 | Entry into force | CRA Art. 71 |
+| 2026-06-11 | Provisions on notification of conformity assessment bodies (Chapter IV) | CRA Art. 71(2) |
+| **2026-09-11** | **Article 14 reporting obligations + SRP goes live** | CRA Art. 14, 16 |
+| 2027-12-11 | CE marking, conformity assessment, and essential requirements in full application | CRA Art. 71(2) |
+
+[A1](#a1), [B3](#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](#a1), [B3](#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](#b5), [C1](#c1), [C2](#c2), [C6](#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](#a1), [B3](#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](#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](#c3), [C4](#c4) and CycloneDX, a specification maintained by OWASP, published ECMA-424 2nd Edition (based on v1.7) on December 10, 2025. [C5](#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](#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](#a1), [B2](#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)
+
+```mermaid
+%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 40, 'rankSpacing': 50}} }%%
+flowchart TD
+ T0["Point of awareness
(actively exploited vuln.
or severe incident)"]
+ T1["Within 24 hours — Early Warning"]
+ T2["Within 72 hours — Notification"]
+ T3["Within 14 days of mitigation
becoming available — final report (vulnerability)"]
+ T4["Within 1 month of notification
— 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](#a1), [B2](#b2)
+
+The content required differs at each stage. [A1](#a1), [B2](#b2)
+
+| Stage | Deadline | Content Required |
+|---|---|---|
+| Early Warning | 24 hours after awareness | Member States affected, whether linked to malicious activity |
+| Notification | 72 hours | General nature of the vulnerability or incident, available mitigations, sensitivity assessment |
+| Final report — vulnerability | 14 days after mitigation becomes available | Severity and scope of impact, threat actor information, content of the security update |
+| Final report — incident | 1 month after Notification | Detailed description of the incident, threat type and root cause, mitigations applied |
+
+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](#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](#b4), [A1](#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.
+
+```mermaid
+%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 45, 'rankSpacing': 55}} }%%
+flowchart TD
+ ID["Importer /
Distributor"]
+ M["Manufacturer"]
+ SRP["ENISA SRP
(Single Reporting Platform)"]
+ CSIRT["Member State
Coordinator CSIRT"]
+ ENISA["ENISA"]
+ OTHER_CSIRT["Other Member State
CSIRTs"]
+ MSA["Market Surveillance
Authority (MSA)"]
+
+ ID -->|"Notify on discovering non-compliance"| M
+ M -->|"Art.14 24h/72h/14d"| SRP
+ SRP --> CSIRT
+ SRP --> ENISA
+ CSIRT -->|"Dissemination
(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](#a1), [A2](#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](#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](#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](#a4), [E2](#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](#a1), [B3](#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](#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](#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](#a1), [E1](#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](#b5)
+
+| Standard/Framework | Owner | CRA Mapping |
+|---|---|---|
+| ISO/IEC 30111:2019 | ISO/IEC | Vulnerability handling process — Annex I Part II "vulnerability handling" requirements |
+| ISO/IEC 29147:2018 | ISO/IEC | Coordinated Vulnerability Disclosure (CVD) — Art. 14 notification workflow |
+| SPDX v3.0 (ISO/IEC 5962) | Linux Foundation / ISO | SBOM standard format |
+| CycloneDX v1.7 (ECMA-424) | OWASP / Ecma | SBOM standard format — native support for VEX (Vulnerability Exploitability eXchange) |
+| NIST SP 800-218 (SSDF) | NIST | Secure-by-design practices — functionally aligned with Annex I Part I requirements |
+| prEN 40000-1-3 (draft) | CEN/CENELEC | CRA harmonized horizontal standard — vulnerability handling, targeted for 2026-08-30 |
+| BSI TR-03183-2 v2.1.0 | BSI (Germany) | Technical guideline mapping SBOM fields to CRA alignment |
+
+[C1](#c1), [C2](#c2), [C3](#c3), [C4](#c4), [C5](#c5), [C6](#c6), [G1](#g1), [C7](#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](#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](#b4), [F2](#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](#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](#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](#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](#f3), [D1](#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](#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](#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](#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
+
+| Item | EU CRA | US (EO 14028 / CISA KEV) | UK PSTI Act | Korea's SW Supply Chain Guideline |
+|---|---|---|---|---|
+| Scope | All PDEs on the EU market | Federal-procurement software (advisory for private sector) | Consumer connected products | All software (non-mandatory) |
+| Legal force | EU Regulation — direct effect | Executive order, binding operational directives (BOD) | Statute | Administrative guideline |
+| Reporting deadline | 24h/72h/14d | Deadline set per KEV entry | Duty to maintain a reporting channel only | None |
+| SBOM | Mandatory (SPDX/CycloneDX) | Advisory for federal-procurement software (NTIA) | None | SSDF-based recommendation |
+| Enforcement date | 2026-09-11 (reporting) / 2027-12-11 (full) | 2021-05 | 2024-04-29 | 2024-05 |
+
+[C6](#c6), [E2](#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](#a1), [B2](#b2), [E2](#e2), [E4](#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. (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. (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. (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. (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. (accessed: 2026-05-12). ↩
+
+---
+
+### B. Official Documents from Issuing Bodies
+
+**B1.** European Commission, DG CNECT (2026). *Cyber Resilience Act — Shaping Europe's digital future*. (accessed: 2026-05-12). ↩
+
+**B2.** European Commission, DG CNECT (2026). *Cyber Resilience Act — Reporting obligations*. (accessed: 2026-05-12). ↩
+
+**B3.** European Commission, DG CNECT (2024). *The Cyber Resilience Act — Summary of the legislative text*. (accessed: 2026-05-12). ↩
+
+**B4.** ENISA (2026). *Single Reporting Platform (SRP)*. (accessed: 2026-05-12). ↩
+
+**B5.** ENISA & Joint Research Centre (2024). *Cyber Resilience Act Requirements Standards Mapping — Joint Analysis*. April 2024. (accessed: 2026-05-12). ↩
+
+**B6.** ENISA (2025). *Cyber Resilience Act implementation via EUCC and its applicable technical elements*. 26 February 2025. (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. (accessed: 2026-05-12). ↩
+
+**C2.** ISO/IEC (2018). *ISO/IEC 29147:2018 — Information technology — Security techniques — Vulnerability disclosure*. Edition 2. (accessed: 2026-05-12). ↩
+
+**C3.** ISO/IEC (2021). *ISO/IEC 5962:2021 — Information technology — SPDX® Specification V2.2.1*. (accessed: 2026-05-12). ↩
+
+**C4.** The Linux Foundation / SPDX Project (2024). *SPDX Specifications (current: v3.0)*. (accessed: 2026-05-12). ↩
+
+**C5.** OWASP Foundation / Ecma International (2025). *CycloneDX Specification v1.7 / ECMA-424*, 2nd Edition. ECMA-424 published 2025-12-10. (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. (accessed: 2026-05-12). ↩
+
+**C7.** OpenSSF Global Cyber Policy Working Group (2026). *CRA Standards Map*. (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. (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. (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. (accessed: 2026-05-12). ↩
+
+**E3.** DLA Piper (2026). *Cyber Resilience Act: Commission unveils draft implementation guidance*. Law in Tech. (accessed: 2026-05-12). ↩
+
+**E4.** HackerOne — Eldering, B. (2026). *EU Cyber Resilience Act: Preparing Your VDP for 2026 Reporting Requirements*. (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. (accessed: 2026-05-12). ↩
+
+**F2.** European Commission (2025). *EU launches a European vulnerability database to 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. (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*. (accessed: 2026-05-12). ↩
diff --git a/content/en/blog/2026/20260609_eu-oss-strategy/index.md b/content/en/blog/2026/20260609_eu-oss-strategy/index.md
new file mode 100644
index 0000000000..c49480033f
--- /dev/null
+++ b/content/en/blog/2026/20260609_eu-oss-strategy/index.md
@@ -0,0 +1,168 @@
+---
+date: 2026-06-09
+lastmod: 2026-06-10
+title: "The EU Open Source Strategy: Institutionalizing Open Source for Tech Sovereignty"
+linkTitle: "EU Open Source Strategy"
+description: An analysis of the EU Open Source Strategy (COM(2026) 503), published by the European Commission on June 3, 2026, based on primary sources. Covers the four objectives, the seven-year EUR 2 billion mobilization, the governance structure, civil-society criticism, and implications for Korean public-sector and enterprise practice.
+author: Haksung Jang / [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)
+categories: ["blog"]
+tags: ["Open Source", "EU Open Source Strategy", "Tech Sovereignty", "Open Source Strategy", "Digital Sovereignty", "OSPO", "public code"]
+---
+
+{{% alert color="info" %}}
+This article was written with Claude Code, and the key facts cited here were cross-checked against primary sources.
+{{% /alert %}}
+
+
+> **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](#a1)·[A2](#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](#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](#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](#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](#a1)·[B3](#b3)
+
+```mermaid
+%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 45, 'rankSpacing': 55}} }%%
+flowchart TD
+ ROOT["EU Open Source Strategy
COM(2026) 503"]
+ O1["Objective (i)
Leveraging open source
for sovereignty"]
+ O2["Objective (ii)
Strengthening and fostering
a vibrant ecosystem"]
+ O3["Objective (iii)
Open and interoperable
public administration"]
+ O4["Objective (iv)
Reinforcing standards and
international cooperation"]
+ ROOT --> O1 & O2 & O3 & O4
+ O1 --> AC1["Open Internet Stack, open-sourcing
EUID/EBW, 30M users by 2030"]
+ O2 --> AC2["Business accelerators, stewardship
toolkit, open source maintenance instrument"]
+ O3 --> AC3["Public money, public code
procurement reform, stronger OSPO network"]
+ O4 --> AC4["Standardisation Regulation revision,
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](#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](#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](#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](#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](#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](#a1)·[E1](#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](#a1)
+
+**Opening up public administration (Objective iii).** The "public money, public code" principle has been explicitly written into the strategy.[A1](#a1)·[B2](#b2) The Commission already runs the Matrix-based communication platform, the openDesk collaboration environment, and Drupal across more than 300 europa.eu sites.[A1](#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](#a1)·[B2](#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](#a1)
+
+### Governance Structure
+
+Rather than creating new bodies, the strategy weaves together existing governance assets. Three tracks come together.
+
+```mermaid
+%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 45, 'rankSpacing': 50}} }%%
+flowchart TD
+ EC["Commission OSPO
(established 2020)"] --> NET["EU Public Sector OSPO Network
(25 members, 11 countries)"]
+ EDIC["Digital Commons EDIC
(established 2025-10-29)"] --> FND["European Digital Public
Infrastructure Foundation (in formation)"]
+ NET --> FND
+ FND --> ASSET["Long-term stewardship of strategic
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](#a1)·[A5](#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](#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](#a4) while the CRA (Regulation (EU) 2024/2847) provides the steward regulatory category and voluntary security attestation (Article 25).[A3](#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](#a1)·[C1](#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](#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](#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](#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.
+
+```mermaid
+%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 35, 'rankSpacing': 45}} }%%
+flowchart TD
+ J["2026-01-12 Call for evidence opens"]
+ F["2026-02-03 Call closes (1,600+ responses)"]
+ P["2026-06-03 COM(2026) 503 published"]
+ D["2026-12 National roadmaps revised"]
+ S["Later 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](#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](#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](#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](#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](#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](#a1)·[B2](#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](#a1)·[A3](#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](#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](#b4)·[E1](#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: (accessed 2026-06-05). ↩
+
+**A2.** European Commission (2026). *Strengthening Europe's tech sovereignty* (press release). 2026-06-03. (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. (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. (accessed 2026-06-05). ↩
+
+**A5.** European Commission (2020). *Open Source Software Strategy 2020–2023*. C(2020) 7149 final, Brussels, 21.10.2020. (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. (accessed 2026-06-05).
+
+**B2.** European Commission (2026). *Commission boosts open and interoperable digital ecosystems for public administrations* (press release). 2026-06-03. (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). (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. (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. (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. (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. (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. (accessed 2026-06-05). ↩
+
+**E2.** TechPolicy.Press (2026). *EU Unveils Sweeping Tech Sovereignty Push, Balancing Autonomy with Openness*. 2026-06-03. (accessed 2026-06-05).
+
+**E3.** Covington & Burling (2026). *EU Tech Sovereignty Package*. Global Policy Watch, 2026-06-04. (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. (accessed 2026-06-05).
diff --git a/content/en/blog/2026/20260610_us-ai-eo-ospo/index.md b/content/en/blog/2026/20260610_us-ai-eo-ospo/index.md
new file mode 100644
index 0000000000..b820977d42
--- /dev/null
+++ b/content/en/blog/2026/20260610_us-ai-eo-ospo/index.md
@@ -0,0 +1,213 @@
+---
+date: 2026-06-10
+title: "What the US AI Executive Order (2026-06-02) Means for Enterprise Open Source Managers"
+linkTitle: "US AI Executive Order and Open Source Management"
+description: An analysis of the US AI executive order signed on June 2, 2026, based on primary sources. Covers what the AI Cybersecurity Clearinghouse and the voluntary frontier model framework mean for enterprise open source managers, how they contrast with the EU CRA's mandatory reporting, and what to do now versus what to watch.
+author: Haksung Jang / [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)
+categories: ["blog"]
+tags: ["AI Executive Order", "Open Source Security", "Vulnerability Management", "SBOM", "EOL", "EU CRA", "OSPO"]
+---
+
+{{% alert color="info" %}}
+This article was written with Claude Code, and the key facts cited here were cross-checked against primary sources.
+{{% /alert %}}
+
+> **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](#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](#a6)·[C1](#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](#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](#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](#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](#a1).
+
+```mermaid
+%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 40, 'rankSpacing': 45}} }%%
+flowchart TD
+ A["2023-10-30 Biden Executive Order 14110 — first comprehensive AI governance framework"]
+ B["2025-01 Inauguration Day (01-20): EO 14110 revoked; Executive Order 14179 signed (01-23)"]
+ C["2025-07-23 America's AI Action Plan released — includes a section encouraging open source and open weights"]
+ D["2026-04-07 Anthropic announces Mythos Preview and Project Glasswing"]
+ E["2026-06-02 This executive order signed; Glasswing expands to 150 organizations"]
+ F["2026-06-05 NSPM-11 — national security AI memorandum"]
+ G["2026-07-02 30-day deadline — clearinghouse established, federal systems defended"]
+ H["2026-08-01 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](#a1), [A2](#a2), [A3](#a3), [A4](#a4), [A5](#a5), Anthropic [A6](#a6), Wiley's deadline calculation [B1](#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](#b4)·[B5](#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](#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](#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](#c1)·[C2](#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](#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](#c1)·[C2](#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](#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](#a1)·[B5](#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](#a1)·[A2](#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](#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](#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](#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](#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](#a1).
+
+```mermaid
+%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 50, 'rankSpacing': 60}} }%%
+flowchart TB
+ GOV["AI Cybersecurity Clearinghouse
Treasury-led — in consultation with NSA, CISA, National Cyber Director
(established by 2026-07-02)"]
+ VOL["Voluntary participants
AI developers (vulnerability-discovery capability), critical infrastructure operators"]
+ OSS["Open source maintainers
Receive vulnerability reports via coordinated disclosure"]
+ ENT["Enterprise open source managers
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](#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](#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](#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](#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](#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](#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](#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).
+
+| Category | US Executive Order (2026-06-02) | EU CRA Article 14 (effective 2026-09-11) |
+|---|---|---|
+| Nature | Voluntary cooperation (participation is a company choice) | Legal obligation (applies immediately upon EU market entry) |
+| Scope | AI industry, critical infrastructure operators | Manufacturers, importers, and distributors of products with digital elements |
+| Core mechanism | Clearinghouse coordinates scans and patch deployment | Tiered 24-hour/72-hour/14-day reporting of actively exploited vulnerabilities |
+| Recipient | Treasury-led clearinghouse (operating model undisclosed) | ENISA's Single Reporting Platform (SRP) and member-state CSIRTs |
+| Non-compliance | No penalty (procurement-standard adoption remains speculative) | Fines of up to €15 million or 2.5% of global annual turnover |
+| Model regulation | Explicit exclusion of mandatory licensing and pre-approval | CRA regulates product security, not AI models |
+
+**Table 1.** Comparing the US executive order and EU CRA vulnerability reporting regimes *(source: the executive order text [A1](#a1), Regulation (EU) 2024/2847 [A7](#a7), a separate report [D1](#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](#a7)·[D1](#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](#a8)·[D2](#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](#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](#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](#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](#c2).
+
+### What to Watch
+
+| Item to Track | Timing | What to Check |
+|---|---|---|
+| Clearinghouse formation announced | By 2026-07-02 | Operating entity and participation process, scope of enterprise information sharing, whether liability protection exists [A1](#a1)·[B3](#b3) |
+| Classified benchmarking and voluntary framework | By 2026-08-01 | Shape of the covered-frontier-model threshold, treatment of open-weight models [A1](#a1)·[B2](#b2) |
+| Follow-on rulemaking | Over coming months | Whether voluntary provisions migrate into federal procurement standards [B2](#b2) |
+| NSPM-11 classified annex and implementation | By early September 2026 | Treatment of open source AI in national security procurement [A3](#a3) |
+| Open source foundation response | From July onward | Statements and participation approach from OSI, the Linux Foundation, and OpenSSF [B7](#b7) |
+| EU CRA SRP goes live | 2026-09-11 | Reporting workflow going operational (tracked in a separate report [D1](#d1)) |
+
+**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. (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. (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. (accessed 2026-06-10). ↩
+
+**A4.** The White House (2025). *Removing Barriers to American Leadership in Artificial Intelligence* (Executive Order 14179). 2025-01-23. (accessed 2026-06-10). ↩
+
+**A5.** The White House (2025). *Winning the Race: America's AI Action Plan*. 2025-07. (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). (accessed 2026-06-10). ↩
+
+**A7.** European Parliament and Council (2024). *Regulation (EU) 2024/2847 — Cyber Resilience Act*. OJ L, 2024/2847, 20.11.2024. (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. (accessed 2026-06-10). ↩
+
+### B. Legal and Policy Analysis
+
+**B1.** Wiley Rein LLP (2026). *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. (accessed 2026-06-10). ↩
+
+**B3.** Crowell & Moring LLP (2026). *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*. (accessed 2026-06-10). ↩
+
+**B5.** Council on Foreign Relations (2026). *Assessing Trump's Executive Order on AI Oversight*. (accessed 2026-06-10). ↩
+
+**B6.** CSO Online (2026). *OpenAI responds to White House executive order on AI governance*. (accessed 2026-06-10).
+
+**B7.** Open Source Initiative (2025). *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. (accessed 2026-06-10). ↩
+
+**C2.** Help Net Security (2026). *Anthropic: Claude Mythos identified 10,000+ software flaws*. 2026-05-26. (accessed 2026-06-10). ↩
+
+**C3.** Schneier, Bruce (2026). *On Anthropic's Mythos Preview and Project Glasswing*. Schneier on Security, 2026-04. (accessed 2026-06-10). ↩
+
+**C4.** HeroDevs (2026). *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]({{< relref "/blog/2026/20260518_eu-cra" >}}) (updated 2026-06-09). ↩
+
+**D2.** [EU Open Source Strategy: Institutionalizing Open Source for Tech Sovereignty]({{< relref "/blog/2026/20260609_eu-oss-strategy" >}}) (2026-06-05). ↩
+
+**D3.** [AI-Generated Code: How Far Should Open Source Screening Go?]({{< relref "/blog/2026/20260608_ai_snippet_scan" >}}) (2026-06-08). ↩
diff --git a/content/ko/blog/2021/20211212-log4shell/index.md b/content/ko/blog/2021/20211212-log4shell/index.md
index bce879e384..8cef2624ba 100644
--- a/content/ko/blog/2021/20211212-log4shell/index.md
+++ b/content/ko/blog/2021/20211212-log4shell/index.md
@@ -13,7 +13,7 @@ resources:
byline: "Photo: Robin Hwang"
---
-Apache Log4j 2에서 발생한 취약점([CVE-2021-44228, NVD](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228))을 통해 악성코드 감염 등 추가 피해가 발생할 수 있어 전 세계적으로 긴급 보안 업데이트 조치 (2021.11.10)가 있었으며, 관련 내용을 정리합니다.
+Apache Log4j 2에서 발생한 취약점([CVE-2021-44228, NVD](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228))을 통해 악성코드 감염 등 추가 피해가 발생할 수 있어 전 세계적으로 긴급 보안 업데이트 조치 (2021.12.10)가 있었으며, 관련 내용을 정리합니다.
### Log4j
Log4j는 로그를 목적으로 Java 기반의 웹서비스에서 대부분 사용되는 Apache 재단의 오픈소스입니다.