The News
At OCX 2026, the Eclipse Foundation brought together open source leaders, embedded systems engineers, and compliance experts to address two increasingly connected priorities: preparing for the EU Cyber Resilience Act (CRA) and operationalizing the Eclipse Trustable Software Framework (TSF).
Mike Milinkovic, Executive Director of the Eclipse Foundation, argued that CRA responsibility falls most heavily on manufacturers selling products into Europe, not on volunteer open source maintainers. John Ellis of CodeThink expanded on that theme by showing how the TSF converts “trust” from a vague aspiration into a measurable engineering model built around provenance, reproducibility, controlled change, and evidence generation.
Together, the sessions made a broader point: software is entering an era where governance, security, and supply chain accountability are no longer optional side processes. They are becoming product requirements.
Analysis
CRA Is Not GDPR — and Most Manufacturers Don’t Know That Yet
One of the clearest messages from OCX was that many companies still misunderstand the scale of the CRA. Milinkovic contrasted the regulation with GDPR. While GDPR forced organizations to improve documentation, privacy controls, and data handling practices, the CRA goes further. It reaches directly into how products are built, secured, maintained, and certified. For certain categories of products, external auditors may be required before CE marking can be granted. His warning was blunt: companies targeting European markets should already be acting, and many are not.
That matters because the deadline carries business consequences, not just regulatory ones. If a product cannot be CE marked on schedule, launch dates slip, revenue gets delayed, and supply chains are disrupted. Many organizations still frame compliance as a legal exercise. CRA makes it an engineering discipline.
Open Source Consumption Without Engagement Is Becoming Riskier
Milinkovic also highlighted a long-standing imbalance in enterprise software consumption. For years, many manufacturers consumed open source code passively: download it, build it, ship it, and only contact maintainers when something breaks. CRA changes that posture. Manufacturers now need visibility into upstream security practices, disclosure processes, patch models, and dependency governance.
That creates a new strategic choice:
- Engage with upstream projects and support their governance models
- Build internal controls around dependencies
- Fork code and own the maintenance burden directly
The third option is usually the most expensive. That makes open source stewardship, foundation governance, and supplier transparency more valuable than many organizations previously assumed.
What the Trustable Software Framework Actually Delivers
John Ellis positioned the TSF as a unifying operating model rather than another standalone standard. Its six tenets (provenance, construction, change, definition, results, and confidence) are designed to help organizations reason across competing demands such as security, safety, quality, resilience, and long lifecycle maintenance.
This is crucial framing as many regulated sectors still operate with conflicting incentives. Safety teams may prioritize stability and minimal change. Security teams prioritize rapid patching and continuous updates. Traditional standards often treat those goals separately. TSF attempts to create a structured way to manage both.
Ellis emphasized that evidence should be generated continuously during builds, not assembled later during audits. That philosophy feels especially relevant as software supply chains become more dynamic and AI-generated code increases release velocity.
This is not purely theoretical. Ellis described real certification work using a Linux-based distribution aligned to IEC 61508 through the TSF model, showing the framework is already being applied in practice.
What This Means for ITDMs
For technology decision-makers, the business case for acting early is straightforward. Organizations that lack traceability, mature SBOM practices, reproducible builds, and clear vulnerability response processes are likely to face both remediation costs and business disruption tied to delayed product timelines. In many cases, the commercial impact of missed launch windows can be more significant than the compliance work itself.
ECI Research data reinforces the gap between intention and readiness. Nearly half of respondents (49.3%) say compliance and data governance are high priorities when developing AI/ML systems, including 24% who rank it as a top priority. Yet only 1.6% report adopting Software Bill of Materials (SBOM) requirements in response to supply chain attacks. That disconnect is exactly where regulatory pressure tends to surface.
IT leaders should already have a clear view into whether they can trace critical software dependencies, reproduce builds consistently, maintain a vulnerability disclosure process aligned to reporting deadlines, and demonstrate governance across suppliers and open source components. If those answers are still uncertain, the timeline is already becoming a factor.
What This Means for Developers
The OCX discussions also made clear that developers are now part of the compliance conversation. Milinkovic noted that AI-assisted development is accelerating quickly, and some teams are already shipping code they did not fully inspect. His suggested control model was practical: separate requirements generation, code generation, and acceptance testing into distinct stages so one agent cannot silently validate another. That idea maps directly to TSF principles. Claims need evidence. Outputs need validation. Accountability needs separation of duties.
Another OCX session on AI coding assistants reinforced that productivity gains are real but conditional. Researchers cited 30–40% productivity improvements, while warning that much of the benefit disappears if code quality drops and cleanup work rises later. Context engineering, structured repositories, and developer judgment remain central.
ECI Research found that 82% of AI/ML teams report skill gaps in AI/ML operations, with 31.3% describing them as extremely prevalent. That means many organizations risk creating compliance debt at the same speed they create new code.
Looking Ahead
The Open Source Ecosystem Is About to Get Louder
Milinkovic outlined a plausible near-term scenario: manufacturers wait too long, then flood open source projects with security and compliance questionnaires at the same time. The result is friction for both maintainers and buyers.
Foundations that centralize governance responses, publish security practices, and standardize compliance information may become critical buffers between commercial buyers and volunteer-led projects.
Compliance Will Become a Procurement Filter
Over the next 18–24 months, CRA readiness is likely to shift from legal concern to buying criterion. In sectors such as automotive, industrial systems, healthcare, and critical infrastructure, buyers will increasingly prefer vendors that can demonstrate:
- Auditable supply chains
- Transparent dependency management
- Reproducible builds
- Secure update processes
- Clear evidence trails
Those capabilities reduce risk and shorten procurement cycles.
Final Take
The most important message from OCX 2026 was simple: software trust is becoming operationalized. The CRA raises the floor for how products must be built and maintained. TSF offers one framework for proving that work has been done. AI-assisted development increases the urgency because release velocity is rising faster than governance maturity. For enterprises, this is no longer about whether regulation is coming. It is about whether engineering systems are ready when it arrives.
SAP and S3NS Bring Sovereign Cloud ERP to France
OCX 2026 Wrap-Up: Open Source Finds Its Moment in the Heart of Europe
Eclipse ThreadX and RISC-V Advance the Open Embedded Stack
CRA Compliance and Trustable Software: What OCX 2026 Revealed
Jakarta EE AI Integration: What’s Coming in EE 12 and 13
