September 2026
By Sal Kimmich and Simon John
In early May 2026, NHS England issued a reported internal guidance note, SDLC-8, mandating the removal of public access to several hundred GitHub repositories. The stated reason was AI-accelerated vulnerability discovery. The actual effect was to contradict years of established UK government open source policy with no public consultation, no published threat model, and no evidence the closures removed any meaningful attacker advantage.
On 14 May 2026, the Government Digital Service (GDS) and the Department for Science, Innovation and Technology (DSIT) issued guidance titled AI, Open Code and Vulnerability Risk in the Public Sector. It is a direct, technically grounded rebuttal. The guidance reaffirms open by default as the correct posture for publicly-funded code and makes it clear that closing repositories to compensate for poor security hygiene, or a misguided belief in security by obscurity is not an acceptable practice.
This brief summarizes what the guidance says, why the NHS England decision was wrong on its own terms, and what both mean for the international open source security community.
NHS England removed public access to repositories following vulnerabilities reported to it through Anthropic’s Project Glasswing, an initiative giving a limited set of organisations access to Claude Mythos Preview for defensive security work. AISI’s April 2026 evaluation of that model found it capable of discovering and exploiting vulnerabilities autonomously in controlled conditions.Â
The community response was fast. A petition at keepthingsopen.com crossed 2,000 signatures within days. Former NHSX Head of Open Technology Terence Eden, who helped build the open source and open standards policies NHS England is now reversing, described the decision as a non-technical management overreaction to a threat briefing. He has filed a Freedom of Information request for the internal deliberations.
| KEY FACT | As of 17 May 2026, reported closure to public repositories ranged from nearly 200 to over 850 NHS repositories depending on the source, and closure was partial rather than complete across NHS GitHub organisations. Independent researchers had already archived the affected code. |
This matters beyond NHS England. The governance problem is structural. NHS England carries significant operational independence from Cabinet Office digital governance. GDS standards apply cross-government, but enforcement is inconsistent. The GDS response makes clear that departmental autonomy has a limit: it does not extend to contradicting settled government-wide policy without a credible technical basis.
The NHS England pattern is not a one-off. Non-technical decision-makers receiving threat briefings that focus on offensive AI capability, without equivalent context on defensive tooling and operational hygiene, will keep reaching for the same lever. Closure feels decisive. It is not a security control.
The GDS/DSIT guidance, published 14 May 2026, does not name NHS England. It does not need to. It addresses the exact argument NHS England used and dismantles it on technical grounds. The document is structured around four recommendations and a further six points published under the heading “Additional considerations.” Both sections are worth understanding in detail.Â
GDS establishes a clear operational logic:
GDS is explicit that the minimum standard is not a new policy. It is a clarification of what secure-by-design and open-by-default guidance always assumed teams were doing. The guidance is direct on the central point: making code private is not an appropriate mitigation for lack of ownership, patching capability, or operational assurance. If a system cannot meet the minimum standard, the correct response is to fix the system or shut it down. Using repository closure to paper over maintenance debt is the thing the guidance explicitly prohibits. That is exactly what NHS England did.
GDS acknowledges the AI threat landscape directly. It cites the AISI Frontier AI Trends Report from December 2025 and the April 2026 AISI evaluation of Claude Mythos Preview, and accepts that these tools compress the window between a weakness existing and being exploited. It does not dismiss the technology. It reframes the question.
The evidence base has broadened considerably since. AISI’s April evaluation found Mythos Preview was the first model to complete its corporate network attack simulation end-to-end, an exercise AISI estimates would take a human around twenty hours. The obvious question was whether that reflected one model or a trend. AISI answered it by evaluating an early checkpoint of OpenAI’s GPT-5.5, which reached comparable performance. Two models from different developers, both showing among the largest capability jumps AISI has recorded.
| GDS FINDING | Production risk is primarily driven by secure-by-design architecture, deployment configuration, dependency hygiene, and access control. Source code visibility changes time-to-discovery and attacker uncertainty. It is not the dominant determinant of whether a weakness exists or how quickly it is mitigated. |
This is the correct framing. AI does not create vulnerabilities. It accelerates the discovery of vulnerabilities that already exist because of insecure architecture, poor secrets hygiene, missing patches, or weak configuration. Removing source access does not remove those underlying conditions. It removes the scrutiny that helps resolve them.
Under “Additional considerations,” GDS sets out six specific failure modes of private-by-default posture:Â
That last point deserves emphasis. GDS is naming a contagion risk. If NHS England’s justification stands in, it will spread. Every team receiving a threat briefing will use the same rationale. The guidance removes that path by establishing a principled, technically grounded counter-argument on the record.
The strongest argument against closure as a durable control arrived after the NHS decision. In JulyÂ
2026 AISI published its first public analysis of how far open weight models trail the closed frontier. It found GLM-5.2 performing comparably to Opus 4.6 and GPT-5.3-Codex, models released four months earlier, with DeepSeek V4-Pro tracking Opus 4.5 from five months prior. Both gaps are narrower than the six to ten months AISI measured in 2025. The practical implication is direct: capabilities that today require a controlled access programme are available in downloadable weights within months, with no safeguards and no gatekeeper. A closure decision justified by what one frontier model can do has a shelf life measured in a single release cycle. The underlying weaknesses, meanwhile, persist indefinitely.
The GDS guidance is a credible, publicly available, government-issued document that directly refutes security-by-obscurity reasoning dressed up as an AI threat response. Open source security practitioners and policy advocates should treat it as a reference document and use it as a foundation. The core argument is portable: AI changes speed, not fundamentals. Secure design, ownership, patching velocity, and secrets hygiene are the actual controls. That argument needs to be codified in position statements and decision-support frameworks such as SSDF, SLSA, and the OpenSSF Security Baseline.
GDS implicitly endorses using AI tools for continuous internal security review. The same tools that compress attacker discovery timelines also compress defender review timelines. That is the argument for investing in tools like OpenSSF Scorecard, OSV, Sigstore, and agentic threat modelling approaches in the SBOM and dependency review toolchain. It also cuts the other way, toward the code AI produces rather than only the code it reviews. The OpenSSF Security-Focused Guide for AI Code Assistant Instructions, a joint output of the AI/ML Security and Best Practices working groups, covers how to instruct code assistants so they account for input validation, secrets handling, dependency selection, and language-specific secure patterns. Public sector teams adopting AI assistance need that guidance as much as they need AI-assisted review, and it is available now. Governments that respond to AI-accelerated offense by closing repositories rather than building AI-accelerated defense are making the wrong tradeoff. OpenUK is positioned to make that case explicitly in UK and EU policy contexts.
The GDS minimum standard does not cite the EU Cyber Resilience Act, and such a citation is unnecessary. The two converge on the same controls: named ownership, vulnerability reporting routes, dependency hygiene, and patch SLAs. When a voluntary UK guidance document and a binding EU regulation arrive independently at the same conclusion, that is strong evidence the requirements are the right ones. The convergence is partial rather than complete. GDS does not address the machine-readable SBOM requirement in Annex I Part II or the Article 14 reporting clock that begins on 11 September 2026, and most public sector code publication sits outside CRA scope in any case, since it is not placed on the market as a commercial product. The guidance instead cross-references the DSIT Software Security Code of Practice and NCSC implementation guidance, which are the UK’s functional equivalents. The gap that matters is not coverage. GDS guidance is guidance, the CRA is law.Â
The NCSC’s June 2026 guidance on software supply chain attacks reinforces this operational picture. It identifies the complexity of modern dependency chains, automated CI/CD pipelines, and the implicit trust placed in packages and maintainers as key sources of supply-chain risk. Its response is not to make source code private. It recommends maintaining a clear inventory of dependencies, using dependency scanning, controlling how dependencies are introduced and updated, and securing the CI/CD and credential infrastructure through which software is built and distributed. The NCSC explicitly notes that this inventory can take the form of an SBOM. This is significant for the policy comparison: the UK’s own security agency is treating dependency visibility and operational controls as the response to supply-chain risk, rather than repository opacity.Â
The right European comparison for the UK’s Cyber Security and Resilience Bill is not the CRA but NIS2. The Bill amends the Network and Information Systems Regulations 2018, which transposed the original NIS Directive, and NIS2 is what replaced that Directive in the EU. Both are entity-based regimes covering operators of essential services rather than product regulation covering manufacturers. Read against NIS2, the Bill shows the same parallels with the GDS guidance: timely reporting and mitigation of active exploits, rapid patching and risk management instead of hiding flaws, automated dependency tracking and vulnerability scanning, clear code ownership and responsibility for code hygiene. The Bill is not yet law. It sits before the House of Lords as HL Bill 32, with committee stage scheduled for September 2026 and Royal Assent expected before year end. Its provisions are scheduled rather than binding.
NHS England is not the only government entity that has received threat briefings emphasizing offensive AI capability. The same dynamic is playing out in technology teams across EU member states, Australia, Canada, and US federal civilian agencies. The default response for non-technical decision-makers facing that briefing, without access to GDS-quality policy infrastructure, is likely to be closure. We should track whether the GDS counter-argument propagates positively across these contexts, and produce materials that support technically grounded policy teams in other jurisdictions making the same case internally.
NHS England had open source policies. They were built during the NHSX period and embedded in internal guidance. They did not hold when non-technical management received a compelling threat briefing. That is a governance failure, not a policy content failure. The lesson is not that better policy text would have changed the outcome. The lesson is that standards for OS policies need active maintenance, periodic reassessment, and an authority with standing and willingness to enforce them. GDS reasserting itself here is a governance signal worth noting. It will not always happen. The open source security community should think carefully about what the equivalent enforcement architecture looks like at the international level.
The technical content of the GDS minimum standard is not new. NIST SP 800-218, the Secure Software Development Framework, has covered ownership, vulnerability response, and secrets handling since version 1.1 was published in February 2022. SP 800-218A extended those practices to generative AI and dual-use foundation models in July 2024. The UK’s own DSIT and NCSC Software Security Code of Practice, fourteen voluntary principles co-sealed with the Canadian Centre for Cyber Security, covers the same territory from a different angle. A team that has done SSDF conformance work will find nothing in the GDS guidance that surprises them.
Section 5 argued that policy without enforcement is not enough. The US federal experience over the past four years is that argument in compressed form. OMB memoranda M-22-18 and M-23-16 required federal agencies to obtain software producers’ self-attestation of SSDF conformance before agencies could use their software, with CISA operating the common attestation form. The mechanism placed the burden on suppliers to produce a paper-based compliance representation, rather than creating a durable, machine-readable signal of actual security practice. Its value as an enforcement mechanism was therefore always contingent on the attestation regime itself remaining in place. Â
In June 2025, Executive Order 14306 amended EO 14144 and struck the subsections directing the FAR Council to require validated attestations and artifacts from software providers. On 23 January 2026, OMB Memorandum M-26-05 rescinded both memoranda outright, stating that M-22-18 had imposed what it called unproven and burdensome software accounting processes that prioritised compliance over genuine security investments. Under M-26-05 agencies may still choose to use the attestation form and may still choose to require SBOMs, but neither is mandatory.
What did not happen is equally important to consider. The same executive order that removed the attestation mandate directed NIST to produce an updated SSDF, with a preliminary update due 1 December 2025 and a final version within 120 days. NIST published the SSDF 1.2 initial public draft on 17 December 2025. As of NIST’s most recent review of the SSDF project page in April 2026, that draft had not been finalised. The framework survived and kept developing. What disappeared was the paper-based mechanism that had attempted to turn the framework into a procurement condition for suppliers.
That is the sharper version of the point section 5 makes, and it is the one worth carrying into any jurisdiction considering how to make a minimum standard stick. Guidance is cheap to publish and cheap to keep. A compliance mechanism built around attestations is politically expensive, administratively burdensome, and ultimately reversible; its removal does not mean that the underlying security practices have lost their value. The US experience instead suggests that durable enforcement should focus on observable, operational, and preferably machine-readable evidence from the software supply chain, while keeping regulatory responsibility with the actors legally responsible for the software product. This distinction is particularly important for upstream open source projects, which are not necessarily suppliers and should not be made responsible for downstream compliance through de facto attestation or certification requirements.Â
The binding lever now arriving is European. CRA Article 14 reporting obligations apply from 11 September 2026, ahead of the main provisions on 11 December 2027. From that date manufacturers of products with digital elements must notify ENISA and the relevant national CSIRT of actively exploited vulnerabilities, with an early warning inside 24 hours and a notification inside 72. Annex I Part II requires a software bill of materials in a commonly used, machine-readable format. Open source stewards sit in a distinct regime and face no penalties. The UK Cyber Security and Resilience Bill runs parallel with 24 and 72 hour reporting duties, but the government has committed to consult on implementation during 2026, with the substance arriving through secondary legislation afterwards. It is scheduled, not settled.
The Commission has also addressed the AI question directly. Its Action Plan on Cybersecurity and Artificial Intelligence, published 7 July 2026, sets out three objectives: promoting safe and responsible use of advanced AI, reinforcing EU cybersecurity and resilience, and scaling up European AI capabilities for cybersecurity. It commits the Commission to work with ENISA on a European Blueprint for secure access to advanced AI systems for cybersecurity purposes, and to establish a secure testing platform for organisations in critical sectors including health. Most relevant here, it explicitly encourages organisations to use AI, including open source models where appropriate, to detect and address vulnerabilities more quickly. That is the same conclusion GDS reached, arrived at independently and backed by a funded programme. Two jurisdictions looking at the same capability shift, both concluding that the answer is faster defensive use rather than reduced visibility.
For practitioners doing the mapping work, two scoping notes. The Open Source Project Security Baseline already publishes a crosswalk to existing standards and frameworks across its requirement set, so the sensible move is to extend that crosswalk rather than build a new one. And configuration hardening guidance, including the CIS Benchmarks, operates at the OS layer rather than the sourcecode layer. It matters to the secure-by-design posture GDS describes and it does not map row for row against a standard built around ownership, disclosure routes, and patch velocity. Keep the layers distinct or the crosswalk stops being useful.
OpenUK recommends the following:
Sources
UK government guidance and legislation
GDS and DSIT, AI, open code and vulnerability risk in the public sector, GOV.UK, 14 May 2026. https://www.gov.uk/guidance/ai-open-code-and-vulnerability-risk-in-the-public-sector
DSIT and NCSC, Software Security Code of Practice, 7 May 2025. https://www.ncsc.gov.uk/section/software-security-code-of-practice/overview
NCSC, Software Security Code of Practice implementation guidance. https://www.ncsc.gov.uk/collection/software-security-code-of-practice-implementation-guidance
Cyber Security and Resilience (Network and Information Systems) Bill, HL Bill 32. https://bills.parliament.uk/bills/4035
The Network and Information Systems Regulations 2018. https://www.legislation.gov.uk/uksi/2018/506/contents
NHS England, Data Security and Protection Toolkit. https://www.dsptoolkit.nhs.uk/
AI capability evaluation
UK AI Security Institute, Frontier AI Trends Report, 18 December 2025. https://www.aisi.gov.uk/research/aisi-frontier-ai-trends-report-2025
UK AI Security Institute, Our evaluation of Claude Mythos Preview’s cyber capabilities, April 2026. https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos-previews-cyber-capabilities
UK AI Security Institute, Our evaluation of OpenAI’s GPT-5.5 cyber capabilities, 2026. https://www.aisi.gov.uk/blog/our-evaluation-of-openais-gpt-5-5-cyber-capabilities
UK AI Security Institute, How Far Behind the Frontier are Leading Open Weight Models on Cyber?, July 2026. https://www.aisi.gov.uk/blog/how-far-behind-the-frontier-are-leading-open-weight-models-on-cyber
EU legislation and policy
Regulation (EU) 2024/2847, Cyber Resilience Act. https://eur-lex.europa.eu/eli/reg/2024/2847/oj
European Commission, The Cyber Resilience Act: summary of the legislative text. https://digital-strategy.ec.europa.eu/en/policies/cra-summary
Directive (EU) 2022/2555, NIS2. https://eur-lex.europa.eu/eli/dir/2022/2555/oj
European Commission, EU Action Plan on Cybersecurity and Artificial Intelligence, 7 July 2026. https://digital-strategy.ec.europa.eu/en/library/eu-action-plan-cybersecurity-and-artificial-intelligence
US frameworks and federal policy
NIST SP 800-218, Secure Software Development Framework v1.1, February 2022. https://csrc.nist.gov/pubs/sp/800/218/final
NIST SP 800-218r1 ipd, SSDF v1.2 initial public draft, 17 December 2025. https://csrc.nist.gov/News/2025/draft-ssdf-version-1-2
NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models, July 2024. https://csrc.nist.gov/pubs/sp/800/218/a/final
Executive Order 14306, Sustaining Select Efforts to Strengthen the Nation’s Cybersecurity, 6 June 2025. https://www.whitehouse.gov/presidential-actions/2025/06/sustaining-select-efforts-to-strengthen-the-nations-cybersecurity-and-amending-executive-order-13694-and-executive-order-14144/
OMB Memorandum M-26-05, Adopting a Risk-based Approach to Software and Hardware Security, 23 January 2026. https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf
OpenSSF resources
OpenSSF, Open Source Project Security Baseline. https://baseline.openssf.org/
OpenSSF, Security-Focused Guide for AI Code Assistant Instructions. https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions
OpenSSF, Concise Guide for Developing More Secure Software. https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software
OpenSSF, Concise Guide for Evaluating Open Source Software. https://best.openssf.org/Concise-Guide-for-Evaluating-Open-Source-Software
Commentary
Terence Eden, GDS Weighs In on the NHS Decision to Retreat from Open Source, 17 May 2026. https://shkspr.mobi/blog/2026/05/gds-weighs-in-on-the-nhss-decision-to-retreat-from-open-source/
Sal Kimmich works on agentic runtime security at NoLabs, home of nono, the open source project that enforces per-invocation capability brokering at the kernel level so an agent never holds a credential longer than the syscall that needs it. With a decade of contributions, Sal currently co-chairs the OpenSSF BEAR Working Group, co-maintains the CHAOSS Data Science Working Group, and serves as Policy Manager and International Ambassador at OpenUK, leading CRA and NIS2 implementation work for open source. Previously Technical Community Architect at the Linux Foundation Confidential Computing Consortium. As a Co-Director of the Native American owned and founded Immersive Educational company OurWorlds, Sal runs free high school workshops on digital sovereignty and open source transparency principles using PocketBeagle boards. Across all of this work, the goal is to let people experience what it feels like to understand everything about the computing system that they rely on, because they built it themselves.Â
Simon John is the Security Certification Manager at TuxCare, where he works on things like FIPS 140-3 validations and DISA STIGs for their AlmaLinux Extended Security Updates product, as well as the TuxCare Radar vulnerability scanner. You can catch him at conferences like Black Hat Europe and Infosecurity Europe chatting about FedRAMP, DORA, NIS2, SLSA, SBOM and maybe even a little about kernel LivePatching.
Simon has been using Linux for over 25 years and is an active community contributor to the AlmaLinux OS Foundation – he wrote their first CIS benchmark and sits on the Core and Certification SIGs, helping to certify hardware and software against the AlmaLinux OS.
The clock is ticking toward the European Union’s Cyber Resilience Act (CRA) deadlines, yet a staggering 66% of organizations remain completely unaware of what is coming. In this episode of What’s in the SOSS? host Sally sits down with Roman Zhukov, co-chair of the OpenSSF Global Cyber Policy Working Group and Security Communities Lead at Red Hat, to demystify this sweeping regulation. Using a brilliant “community garden” analogy, Roman breaks down the distinct roles of maintainers, stewards, and manufacturers under the law, illustrating why the traditional “consume and forget” model of open source is officially dead. They dive deep into the newly released 2026 CRA Awareness and Readiness Report, exposing the staggering $250,000+ engineering tax of maintaining private forks and detailing how active upstream collaboration is no longer just good citizenship—it’s a business and legal necessity. Tune in to discover actionable strategies, free educational resources, and how we can collectively bake “compliance as code” into the open source ecosystem.
This episode is part 2 of a four-part series on the CRA:
1. CRA Readiness: Practical Strategies for Open Source Communities with Megan Knight
3. Private Forks, CRA Deadlines, and the True Cost of Open Source Compliance with Dave Russo
4. Navigating the New Era: The EU Cyber Resilience Act Explained with Madalin Neag
00:23 – Introduction: The CRA Countdown is On
02:04 – Tomatoes, Gardens, and Restaurants: Defining the CRA Personas
06:40 – Reality Check: Shocking Findings from the 2026 Readiness Report
10:12 – The Awareness Gap: Why Are We Ignoring the Warning Signs?
15:01 – The End of “Consume and Forget”
17:49 – The Private Fork Tax: A $250K Engineering Trap
23:34 – Red Hat’s Blueprint & Free Community Security Tools
28:44 – Taming the AI Vulnerability Tsunami
31:27 – Build Your Program Now: Action Steps for Manufacturers
36:12 – Supporting SMEs & Navigating Free Resources
40:30 – Carrying the Torch as an OpenSSF Ambassador
43:35 – Rapid Fire & How to Get Involved
Sally (00:23)
Hello, hello, and welcome to What’s in the SOSS, an OpenSSF podcast, where we get to talk to some amazing people who make up this great open source security ecosystem. And today I have a very special guest. But before we get into that, here’s what I want you to know. The clock is ticking towards a massive cybersecurity deadline.
Research shows that 66% of organizations don’t even know what it is. Love it or hate it. It’s the European Cyber Resilience Act or the CRA. This is important because how do we navigate this shift? Stick around because today we’re going to talk to someone who has a CRA plan.
Roman Zhukov. Roman, thank you so much for being here. Why don’t you introduce yourself to everybody?
Roman Zhukov (01:21)
Certainly, thanks for having me here. Hi everyone, my name is Roman and I work for Red Hat. I do some cybersecurity things on the internet. But approximately two years ago I joined this NICE effort, as we all now call the EU Cyber Resiliency Act. So it is quite a journey, but having fun.
Sally (01:44)
Well, I love that you say it is fun. And yes, it has been quite a journey. And we are going to unpack some of that today and try to help the audience so they can better be prepared. So I guess let us just start with the basics, right? The European Cyber Resilience Act, CRA. How do you define that? And how does it fit in with the various personas who show up to meetings with you or maybe are not aware but need to be aware. I know there are manufacturers, open source stewards, and individual maintainers in this persona group. Can you define those?
Roman Zhukov (02:23)
Yeah, absolutely. and you are right, that is a lot, a lot of roles, a lot of ambiguity. But let us start with the basics. The CRA is the regulation set up to essentially safeguard European customers of digital products by establishing mandatory cybersecurity requirements for companies that operate in the European Union. and suddenly, if not compliant, those hardware and software vendors will be unable to sell their products in the EU market after December 2027. I think it is worth to mention that the first requirement actually kicks in even earlier, a few months from now, September 2026, all of those organizations need to report vulnerability and severe incidents to the authorities. I would use the analogy for the CRA.
And I mean that is so complex, but I will try to break it down to a few things that should be familiar to almost everyone to understand how the series defines the role or roles that you just mentioned. Let us use the analogy of a community garden. Think of the maintainer as the hobbyist gardener. These are developers who cultivate a beautiful, let us say, patch of tomatoes just because they love gardening and they want to share the harvest with the neighbors and the CRA recognizes those actors and the CRA recognizes that forcing them to pay for legal compliance would kill the garden eventually. Therefore, if you are an independent maintainer doing some non-commercial work, you are completely exempt. So you are out of scope.
Contributor or maintainer, if you don’t charge any money for anything for your open source project, just keep planting the code, right? Just keep doing this, you’re out of scope. Now there is an essential role of the open source software steward or simply steward that we call it in the community. You can think of them as a guard garden association, right? There are foundations like OpenSSF or Linux Foundation, they could be big companies, they do not own the veggies themselves, but they provide the land, the fencing, the water supply, you name it, and you know they protect the ecosystem. So under the CRA, a steward is responsible for setting up the baseline policies and basic health checks for the projects they host, acting, you know, as a trusted buffer, I would say, between the community, those planting veggies and the corporate interests.
Now, finally, the most important actor under the CRA that actually has the most obligations and most liability is the manufacturer. We can think in our little example of them as a commercial restaurant, right? This is like basically any company that walks into the free community garden, scoops up the tomatoes, puts them into the premium pasta sauce.
And sell it to paying customers. So the CRA is kind of crystal clear here. If you make money out of software and you know you just sell the software to the European market, you bear the full legal liability for these things. You are the manufacturer and you must run the safety gates to ensure that your product does not give your customers the let’s say the digital equivalent of food poisoning, if it would happen for community garden. So that’s those are the roles under the law.
Sally (06:12)
Love it, Roman. That really makes it make sense for me. I used to love the farm to table restaurants. That’s what I kept thinking of when you were using that metaphor. That’s such a great metaphor. Thank you for explaining it. Yeah, I want to get out into the garden now. Okay, so we have the 2026 CRA Awareness and Readiness Report, which launched on June 8th. Roman, you wrote the introduction for this report, what was the most surprising finding for you?
Roman Zhukov (06:52)
Right. I would start off with writing the introduction to this report was an incredible honor to me. And it was at the same time the sovereign experience because the data what really matters and the data gave us a massive reality check. There are a lot of really mind-blowing findings, I would say. So I encourage everyone to dive into the whole thing. It is hard to pick up.
The one thing, but the biggest finding to me personally was like really the contradictory shocking nature of findings when you combine them all together. Not single number, but when you look at them and you see the full picture, that is fascinating.
while critical enforcement milestones are rushing really towards all of us, as I mentioned, the September 2026, the first vulnerability reporting obligations will be enforceable. At the same time, the global awareness has completely stalled, right? Like over 60% of respondents still entirely unfamiliar with this CRA, which is fascinating.
Compounding this the organizations that are aware on the other hand are attempting to what they think like ease compliance by burying code inside the private forks. Unfortunately I have been hearing this kind of perception or understanding by some companies that you just can simply fork and kind of escape some of the obligations, right?
But the reality check, backed up by numbers in this report is the report explicitly provides that maintaining these isolated codebases can be really a disaster from economical perspective to a company, draining an average of more than $250k dollars per release cycle in pure engineering depth or kind of simply the l the losses if you would.
But I am glad to see this new report came out actually, as it sends an undeniable message, as far as I see it, to executives and to all the companies worldwide, because the traditional checkbox compliance exercise, as well as that we used to call “consume and forget” for open source, right? Those models are coming away actually. And we should stop treating the open source like a free vending machine.
That is going to simply give you some candies for free without any collaboration, anything else, and therefore now for all the companies that are affected by the law, it would be really hard to deny active upstream collaboration, because it is now something baked in the law and not optional.
Sally (09:50)
Thanks for that, Roman. Yeah, there’s a lot to unpack here. The one thing that stood out to me is you said over 60% of respondents are still unfamiliar with the CRA. Why do you think this awareness gap persists even as the deadlines approach?
Roman Zhukov (10:07)
Yeah, first of all, to me as a co-chair of OpenSSF Global Cyber Policy Working Group, which is a home for collaboration between all of those actors that I mentioned, manufacturers, maintainers and other community members, to me that awareness gap means that we as a working group have so many things to do. I feel we kind of do some work on the awareness front, but there is so much more to be done on that front.
But to be serious, I think this persistent awareness gap comes down to a few typical behaviors that we have seen every day in the software world specifically. First of all, that is like somebody calls it the compiler warning syndrome. That means like in software development, I think
A lot of us are famous for ignoring warnings like compiler flags, all of this that is not that red but yellow, something like that. I will fix that later, and along these lines. I think many global companies are treating the CRA compiler warnings to that extent, right? Because the active enforcement and fines and everything will be starting in
2027 and still of companies saying okay, this is not a this year thing, right? We will come to it as it goes. So they are basically waiting for the build. You know, yeah, they are simply waiting for maybe others to start off and pave the way, but also waiting for the actual lag enforcement date, which is wrong of course.
Yeah, that is unacceptable. The another thing that I think is hidden here is the problem to parse the law actually and to convert the CRA to some of the actionable items. And the lack of the clearly lack of the implementation guidance and the standards. Now the EU authorities are working on the standards and some of the other clarifications that would help manufacturers to navigate this the CRA. But so far a lot of them are still in draft mode.
That means all of these companies are simply left in front of the CRA text itself and it could be ambiguous, it is not concrete. I often got these questions like, okay, we read the CRA one hundred times, but we do not understand what we should do exactly because there are a lack of the technical details on it. So this also adds, I think, to this kind of
Awareness gap, I mean we have heard about this CI, but we don’t know what exactly that means and how exactly we would approach this. And the final piece is the geographic kind of illusion. at least previously I have heard a lot of misunderstanding about this, and I think it’s backed by the report itself.
over seventy percent of North American software producers aren’t familiar with the CRA, right? And this is a belief that okay, I you know, I’m in America, I don’t deal maybe with the EU and it doesn’t affect me, but the CRA is so complex it affects the whole supply chain and there is a non zero probability that even if you don’t sell anything directly to the European Union, you are maybe one of the suppliers of those who do, or you simply maybe the contributor to open source or open source steward for instance. Those also have some obligations. So that also adds to the lack of awareness, I think, generally.
Sally (14:02)
Yeah, it does. Thank you for that, Roman. you brought up a critical point that the report mentions the traditional consume and forget model of using open source and that it’s no longer viable under the CRA. How does this regulation change how companies must interact with upstream projects, if you will?
Roman Zhukov (14:23)
Yeah, absolutely. I mentioned it already. I like the analogy between the consumer forget and kind of free vending machine, right? You push a button and something pops out and you just drop it into your commercial application and that is it. You never thought about the maintainers.
And I personally talk to a lot of companies out there and I frequently ask the question, hey, who is consuming open source? Everybody, right? Because open source is everywhere. But when I ask the question who contributes back, significantly less hands, right? But now under the CRA if you sell a product containing the code, you know, you’re kind of legally responsible for your products, that means effectively for all kind of all of the components.
And if something breaks, even if it is third party to you, if it is an open source component, you hold the whole liability to customers, to your consumers. And I think the CRA has a good chance to end this consume and forget paradigm by transforming open source security into nto the obligations, actually, right?
And yes, historically you are right, commercial consumers operated under the assumption that because open source components work fine for years, someone else would always take care. Now there are certain obligations, like for example, if vulnerability is found in the open source, you need to report back to upstream.
If you produce a fix as a manufacturer of the product, then you actually have to upstream this fix back to the maintainers. And this is a huge push and I think a huge paradigm shift from pure consumption to actually collaborating with upstream and with open source projects.
Sally (16:37)
You talked about the cost of private forks. I was wondering if we could dive deeper into that. According to the data, maintaining private forks cost organizations an average of $250,000 per release cycle. Or actually more than that, $258,000. I’m looking at the research. What is the business case for moving that work to upstream contribution instead? Can you talk a little bit deeper on that?
Roman Zhukov (17:03)
Yeah, that is a perfect finding. That actually to me is one of the most compelling findings in this report: the hidden tax of the private forks. As a long-term open source supporter, I am personally convinced that working upstream, as I do and as we do here at Red Hat, for example, is the only path to go, right?
But now the CRA report backs it up with the numbers and provides the actual business reasons for everybody else besides me and the companies that already contribute to upstream instead of forking things. Yeah, the maintaining private forks may cost organizations more than $250,000 US dollars in labor, which is a big amount of money actually. I would justify the business case for why you should actually contribute upstream instead. I can start with the basics, right? And the basics is that maintaining a private fork forces typically engineering teams to pay a continuous rebase tax.
That means that every time that upstream project releases a new version, right, your developers must manually port your customer patches over, resolve conflicts, and et cetera, and et cetera. On the flip side, by actually merging your features or your or whatever you do new for the project directly into the upstream.community eventually inherits the maintenance and etc. And then you subsequently consume back the newer version where everything is integrated and your code is updated automatically and you don’t spend this additional money to maintain all of these forks. The other business reason could be the engineering velocity that we call in the industry.
That means when developers burdened under the technical depth of the private fork, that significantly affects the product roadmaps. Right? You just have limited amount of resources typically, so you want to spend them wisely and by contributing upstream instead, it shifts your engineering resources from defense like fixing broken mergers to more
Building revenue generating features, if you will, for your products to focus on the core innovations and etc. Those are the basics I think that are under the core incentives why you should contribute upstream. But now the icing on the cake is the CRA factor. Because under the CRA maintaining a private fork would
Increase dramatically, I would say legal risk exposure for you as a product manufacturer. Because pretend if you integrate an open source library into a product, it is third party for you in the meaning of the CRA. That means like the biggest obligation that you would need to form against this dependency, this third party is to perform due diligence, which is
Kind of the one obligation. As long as upstreaming fix things, and hopefully you help also upstream to do these fixes. So you are not responsible for vulnerability management, you are not responsible for secure by design and by default, and etc. Now imagine with a fork, right? Your organization would hold hundred percent legal accountability for this library.
That is now part of your product because you forked it, it is now kind of your property, your responsibility. And nobody cares if you actually do not know the architecture, you may not know the design of this component or even you write the product within a different framework, right? Now you should still do secure by design
Risk assessment, vulnerability management, and full conformity assessment because of the CRA. And now the scale factor, imagine now you have 1000 of these open source libraries you are ingesting every day. And you need to assess it, if it would be even feasible to ensure full engineering compliance support for all of them. So that is the massive shift and the massive push towards better upstream collaboration
backed up by the real kind of business case and business considerations from that point.
Sally (22:04)
Thanks, Roman. Well, you and Emily and me worked on an OpenSSF case study based off of Red Hat’s framework for depending the open source supply chain in this new era of regulations, what is the most important lesson other enterprise organizations can learn from Red Hat’s approach?
Roman Zhukov (22:28)
I would encourage everyone to read this case study which is published under OpenSSF now. But if I picked the only one thing that enterprise organization need to take away, it would be something like this: true software supply chain security requires enterprises to transition from passive consumers into active open source contributors, supporters with the focus on practical security.
If it seems like overhead from the you know as it looks like but it is actually not really overhead if you think it is from occasionally watering your community garden coming back to our lovely example in if you think of occasionally taking care of this community garden in your town so that yourself and others can enjoy these lovely tomatoes at the end, that is a different explanation. Yes, companies like Red Hat take up their responsible stewardship approach, for example, because we naturally support and are committed to do so, some of the open source projects that run the entire world, right.
But we understand that voluntary maintainers do not have compliance team, they do not have legal departments, and quite often the case they lack security background, right, to actually deal with complex mandates and policy and things like CRA. So for other companies, I would suggest to actually break one of the myths.
That I constantly hear say, we are not able to contribute to open source because we are not subject matter experts. Or we use the different programming language. It is kind of an excuse, I would say. Instead, think of there is a lot more you can help with actually, starting just from your questions, right? Just asking your questions is good.
Or raising your CRA concerns, or going down to the frameworks, to the white papers. So we have in the communities we have so much work to be done, both from like collaboration perspective and also on the on the practical security front. So you know, that is kind of natural that the companies that of all sides can actually contribute meaningfully to all of this work.
And I would also add that enterprise compliance has historically relied on manual forms to some extent, right? All these GRC questionnaires, legal declarations, spreadsheets. And this approach is not working for the CRA right now. The lessons from our own journey on the CRA is to focus on the tools, on the practical security things.
Because by implementing automated machine readable security tools and specs and frameworks, organizations can shift the burden of evidence away from voluntary communities to themselves, which is kind of the goal of the CRA. By the way, you cannot offload the liability to the community. So you as a company need to figure out this thing by yourself eventually.
Good news here, there are many open source security standards and tools that can help you to do so. Just to name a few under OpenSSF, we have Open Source Project Security Baseline (OSPS), we have SLSA framework, we have Gemara compliance framework, we have GUAC, and a number of other projects that actually can help both maintainers of the projects to do security better, but also can help companies as they as they adopt them.
Sally (26:43)
Love that. I’d love to hear the good news and all of the areas where we can help make this feel easier for the enterprises and for the whole ecosystem. And you know, I don’t think it would be a conversation in 2026 under open source security if we didn’t talk about AI, right?
There is a massive spike in reported vulnerabilities due to AI-driven tools. How can open source projects realistically manage this influx of disclosures?
Roman Zhukov (27:24)
Yeah, you are right to the point. To handle the massive tsunami of AI driven vulnerability reports and disclosures hitting the open source ecosystem now actually even harder than the enterprises, projects have to adjust their vulnerability management practices and of course tooling to adopt what I call the “post Mythos era” we are entering right now.
A few practical recommendations that I would stress out is first, you need to have a robust intake filter to do the basic sanity checks. It is clear that now a lot of AI agents are operating out there, and not all of them produce actually high-quality reports or high-quality pull requests, etc.
And as a maintainer, you need to introduce some of the filters and checking for things like okay, I do require the proof of concept, I do require affected versions, I do require reproduced steps and a couple of other things. If there are ants in the report, they just simply reject them. So as a maintainer I do not have capacity to deal with these reports.
Now of course automation would help. Automation of looking into some metrics even for the reporters themselves, like reputation, maximum number of emojis even in the report and in the pull requests. I have noticed that a lot of AI assisted contributions are flooding with the emojis, right? Maybe that is because some AI tools just like emojis, something like that.
Checking some of these things would actually help to reject anything that is suspicious bluntly for you as the reporter. So those would be my recommendations.
Sally (29:23)
Yeah, I have to tell my AI assistant, no emojis, no more emojis. They flood it. That’s interesting. Okay, so for the fewer than half of the manufacturers that were surveyed are expected to be fully compliant by the December 2027 deadline. What should these uncertain organizations focus on right now?
Roman Zhukov (29:48)
That is a hard question. I would say I think organizations need to stop looking at the CRA as just a 100-page legal monster something, or perceive it as a next GDPR with this cookie pop-up thingy that you need to implement, which CRA is far from actually. And organizations need to start treating it as a standards software engineering refactoring project. I would be that ambitious.
The EU commission itself actually keeps saying that the intention of the CRA is to make sure that companies invest in the real security improvements. And then compliance shall follow naturally. So start exploring the CRA in great detail right now.
Including all of the implementing acts that we have right now. And you will realize that scope is broader than you eventually think. There are a lot of terms, a lot of complexities in the intersection between the software as a service that are technically out of scope, but there are some of the components that we call remote data processing solution that could potentially make some of the cloud solutions be in scope, right?
And the open source is technically out of scope, but there are many cases when open source can be in scope. So understanding your role, whether you are a manufacturer, distributor, importer, maintainer, steward, contributor, is crucial, right? Because obligations differ dramatically.
But I would suggest to remember the one simple thing, liability always flows downstream. That means you cannot really offload the liability of anything to open source, for example. As a manufacturer, you are ultimately responsible for anything. So one of the advice that I can give to all the companies is to just stop harassing maintainers and asking them how they are doing about the CRA, right? It is not their responsibility to make sure they are CRA compliant.
To draw kind of a bottom line here, do not wait. Build your CRA program now. It is because it is definitely a cross-functional effort. I can speak from our experience. Yes, we are a big company, right, but buy-in from across the different functions inside the company is really vital to set a CRA program up for success. Right. And let us be honest, CRA did not invent brand new security practices. Some of the timelines like 24-hour reporting obligations of actively exploited vulnerabilities and severe incidents are hard. But in essence we all should be implementing all of the things like security by design or security by default, and doing proper vulnerability management as well as SBOMs for years now, right? So apply what is available right now to your products, to your practices. And again is good news. There are plenty of mature frameworks and a lot of open source tools actually that can help you, right?
If you do not know what to do the simple thing is just cooperate upstream. Join me, join my company and others, other peers at initiatives like OpenSSF, Global Cyber Policy Working Group, to learn more and to learn how to start. But yeah, there are plenty of things that you should do right now to prepare yourself to be compliant. 2027 is around the corner, really.
Sally (34:06)
I do feel more hopeful now hearing from your perspective and the things that people can do. One last thing that struck me from the report that I wasn’t expecting was that over half of the European small and medium enterprises, those SMEs, remain unfamiliar with the CRA. So how can the open source community best support these smaller type of organizations that lack a large legal team?
Roman Zhukov (34:30)
That is exactly where the community can actually help and help significantly. For example, as part of our OpenSSF Global Cyber Policy Working Group effort, we are creating digestible white papers, checklists, simple guidelines dedicated to different roles under the Cyber Resiliency Act, and they are meant to be easily consumable by those people in those organizations that are not necessarily familiar with the complex legislations or even unfamiliar with the sophisticated security concepts.
I would say one of the biggest and successful assets that we collaborated on and produced under this effort is the free CRA class that is now hitting way over 5,000 of enrollments, and this is really a good starting point specifically for small and medium organizations because it is again short, concise, sticks to the points and is free completely for everybody to take. It teaches you about the basics of the Cyber Resilience Act.
Also in our group we do regular briefings on what is new in the CRA development. Which is again super important to small and medium organizations because they simply do not have time and capability and desire to learn what is happening in the legislation every day. Therefore, we also do the workshops and brainstorming sessions, both offline and online, to handle cases that the members of our community actually bring to us. And this is a real thing. I would encourage all the SMEs that have questions to just come to our group and ask your questions. Bring up your case and we will do our best to provide our community advice for what you should do about this.
In addition, we also collaborate across multiple OpenSSF projects and broader industry initiatives to work on tools that would help companies, specifically smaller companies, because they are meant to handle or automate the large portion of the CRA compliance, at least we believe so. By standardizing and integrating community tools like the open source project security baseline or OSPS and now actively developed due diligence solution for manufacturers directly into the templates, into the development practices.
We actually as a community can bake compliance into the code, right? And finally reach the point when we can tell, okay, this is compliance as code, and we have all the evidence produced automatically. And this transforms to my personal understanding, a huge portion of complex CRA requirements into free, off the shelf, to some point click to deploy guardrails that can allow smaller companies to stay compliant with the CRA and more importantly actually implement the good security practices like secure by default and etc without needing the huge security teams or the army of lawyers or something.
So that is what can really help SMEs to navigate the Cyber Resiliency Act.
Sally (38:16)
That’s really helpful, Roman. Thank you. All right, let’s shift gears here. I want to talk about something that first off, just want to give you a huge congratulations for that you were just recently became part of our OpenSSF ambassador program, named to the first cohort. A quick question, I guess. What are you thinking you’re gonna do with this new role?
Roman Zhukov (30:40)
Thank you. Well, it is so natural to me as I feel I have been an ambassador in OpenSSF for quite a few years now already. I joined an OpenSSF fan club with the introduction of the first they call it beta or alpha version of the scorecards, a tool that analyzes the security health of open source projects in an automated fashion.
Years later I helped to roll out OpenSSF Scorecard across a few companies of different sizes. Right? So that is how my joining naturally started with OpenSSF. So now that is how I get into it. And you know the drill, right? Once you are in, it is really hard to escape from doing these good things.
With the community and for the community essentially. But to be serious, yeah, I am very proud to be named as an official OpenSSF ambassador. It is an incredible honor to me and also a huge responsibility. In this role I hope to provide what we call the open source way. And educate everybody that the open source way is not just a methodology for writing code, but also it is the most effective framework that we have now for solving global security and regulatory challenges, which we do not have a shortage of at the moment. As you mentioned, all of these AI vulnerabilities and regulatory compliance challenges across the world, they add up to the whole picture.
So by bringing a pragmatic engineering centric voice and approach that I personally really try to follow every day by bringing this to the table. I hope we can ensure that the security becomes an active feature of the ecosystem we all depend on so heavily, right? Rather than a blocking thing that is still perceived by some organizations.
So I have done security for twenty plus years now and it is so close to my heart and I just wanted to carry this torch and I want to spread the word about the beauty of security and all of the open source tools and collaborative nature of it so that it can be easily digestible and implemented across the other companies.
Sally (41:32)
Love that. Okay, that wraps wraps up our main deep dive. But before I let you go, Roman, we have a little thing called rapid fire on the OpenSSF What’s in the sauce podcast. So just first thing that comes to your mind, I’m gonna ask you a series of questions. This is fun stuff, not work stuff. All right, are you ready?
Roman Zhukov (41:52)
Mm-hmm. Yes, love it!
Sally (41:54)
Okay. Tea or coffee.
Roman Zhukov (41:56)
Coffee.
Sally (41:57)
Oh, I wasn’t expecting that. Cheers. I love it.
Roman Zhukov (41:59)
Oh really?
Sally (42:00)
Yeah, I was thinking tea. You’re in Ireland, right?
Roman Zhukov (42:07)
But I love coffee as well. I can drink it every day actually. Yes.
Sally (42:111)
I love coffee too. Really? Okay. I love that. Favorite open source mascot.
Roman Zhukov (42:16)
CRA-fish
Sally (42:17)
Yeah, good one. Star Trek or Star Wars?
Roman Zhukov (42:21)
it is hard but Star Wars, I think.
Sally (42:26)
The tracks. All right. So we talked a lot about your metaphor with the food. I loved that and with growing in the garden. If you’re gonna use one of those tomatoes and make salsa, would it be mild or spicy?
Roman Zhukov (42:39)
Spicy, one hundred percent.
Sally (42:41)
Love it. Okay. well, thank you so much, Roman. To wrap it up for listeners who want to leverage OpenSSF resources, like what you mentioned, the cyber global cyber policy working group, or maybe the new awareness sig, the training course. What’s the best place for them to start today?
Roman Zhukov (43:02)
Right. I would I I would end nearly where I started with again going back to my community garden analogy. with a community garden typically you don’t need any approvals or special permissions, you just show up, learn and see where you can actually help as like everyone else with the tomatoes to make sure they they are good then to eat and to enjoy.
Right, that’s essentially what we do in the community. And despite the scary policy compliance angle, we are super friendly at the OpenSSF Global Cyber Policy Working Group. and you have to trust me to here. just join one of our calls to learn what’s going on. It is free, open to everyone. You don’t have to be a member of anything at all. Just just show up, join.
To name a few specific entry points that could can help you depending on what you need or what you’re building. We have the one stop shop hub that we call it policy.openssf.org/CRA. This is the one stop shop that can get a handle on the landscape of the CRA, what’s happening around with the news without the getting dive into the legal text and all of these complexities.
Of course, explore our GitHub repository. Under OpenSSF, we have Global Cyber Policy Working Group. If you want to dive into the governance, check out what we’re working on, like go to this repo. There are a lot of materials published there. As I mentioned, checklists, guidelines and links and all that you need to know how to further participate in the community. Like we have the bi weekly calls of our main working group. We have also calls for our SIGs, which are awareness SIG and also standardization SIG. They all do a great job in their remit. So please consider joining these efforts if you wanted to dive a little bit deeper into either awareness things.
One of the examples I would as an opportunity I would show you is right now at the very moment we’re looking for collaborators for the blog post series that we plan for the CRA. If you would like to be the co-author, please join us and help to spread the word over there. Finally, we also do a lot of meetups across the globe and throughout the year.
But we also have the workshops and online webinars like EU CRA Monthly Tech Talks, when we actually have the guests speakers speak about everything that can be related and can be helpful on the CRA implementation, again from the different companies, from the different entities and different actors on this space. So just keep an eye out on the announcements.
We always have a lot of stuff to share, but also we have a lot of work to be done. Please come join us and collaborate on the overall effort of making this CRA meaningful and actionable for everyone.
Sally (46:42)
Brilliant, Roman. I feel much better about CRA awareness. Thank you. And until next time, stay secure and happy open sourcing. That’s a wrap.
The EU Cyber Resilience Act (CRA) is no longer a future regulatory discussion; it is an immediate operational reality. With the September 2026 reporting deadline rapidly approaching and full compliance required by December 2027, software manufacturers, commercial entities, open source stewards, and foundations must establish a clear, pragmatic path forward.
If your organization builds, distributes, or commercializes software with digital elements, now is the time to shift from policy interpretation to operational execution.
To help you navigate this transition, OpenSSF is hosting an upcoming Tech Talk: CRA Readiness: A Practitioner’s Guide to Compliance. Join industry leaders and security architects as they share real-world implementation strategies, empirical research, and actionable guidance for software supply chain transparency.
This interactive session moves beyond theoretical compliance to address how organizations are actively operationalizing CRA alignment on the ground. Key highlights include:
Whether you are auditing your software supply chain, implementing SBOM practices, or determining how CRA impacts your open source contributions, this session will provide concrete, peer-tested strategies to guide your roadmap.
Click here to register for the Tech Talk now
