Featured

The cybersecurity topic stream at the first day of Open Chain and Friends event began with an impactful keynote from Dirk Targoni, spotlighting the critical connection between cybersecurity and open source. His practical session provided invaluable insights into navigating supply chain risks, emphasizing that effective remediation requires a holistic approach, not isolated solutions.

We gained clarity on essential factors: Asset Management (SBoM), Vulnerability Monitoring, Code and Binaries Checks, Pentesting, and robust Vulnerability and Incident Handling. A key takeaway was the interdependence of these elements – none are sufficient without the others. The session powerfully underscored that supply chain security has moved from the server room to the boardroom, driven by incidents where a single compromised dependency cascades rapidly.

Targoni also addressed the pervasive question, “Will AI take my job?” His reassuring answer: “AI is your assistant, can do the routine work for you”.

Following the foundational discussion on supply chain security, the cybersecurity session at Open Chain and Friends shifted focus to another rapidly evolving frontier: the critical importance of secure AI systems. Dr. Maike Massierer from Bosch took the stage, providing an insightful look into the topic. Her session highlighted the critical intersection of AI, cybersecurity, and regulation, especially within the automotive industry.

With AI increasingly powering automotive functions like road sign recognition and navigation, ensuring its security is paramount. Dr. Massierer demystified the EU AI Act, outlining its purpose: to ensure the safe and ethical use of AI across the European Union. Attendees learned about the serious implications of non-compliance and the vital importance of Article 15, which mandates AI systems to meet high standards of accuracy, robustness, and cybersecurity. Beyond regulation, the session offered practical insights into securing AI, with AI-specific Threat and Risk Analysis highlighting how crucial it is for addressing security needs effectively.

The OpenChain and Friends event took place between 24 and 26 March 2026, with various tracks spread over three different locations, all focusing on the challenges we face in the supply chain. I’m not very good at writing about details—nor am I sure I’m even allowed to, since if I do that, it wouldn’t be hard to figure out who was the source of the information, and the conference did take place under the Chatham House Rule—but I’m fairly confident in my abilities to synthesize. And one thing that stood out to me is that, regardless of whether we’re talking about infrastructure, software, data, or AI agents, what we’re dealing with is really one big supply chain with various facets.

Not only that, but it seems what we’re really trying to solve, in no small part, is the problem of trust. OpenChain is, of course, built around the cornerstone of creating trust in the open source software supply chain. Trust reduces friction and makes it possible for everyone involved to spend valuable time and resources on the things that are actually differentiating for one’s business.

But trust is also brought up when it comes to data – one needs to be sure that the data one is working with has integrity, that it has not been tampered with, that it does not infringe on anyone’s right to privacy, and that is of high quality. And the same applies to data spaces, which were quite heavily discussed in the AI track, regarding data provided by others.

Trust is also crucial for AI agents, which were also a topic presented in the AI track. There, I learned that 39% of US consumers have already used an AI agent to buy something online. This means that those 39% have provided an AI agent with a credit card. If we are to create an economy built heavily around agents, it’s quite clear that we absolutely need to emphasize the issue of trust, including trust in the underlying infrastructure.

And last but not least, trust would be a critical element in building a global system to manage the flow of vulnerability information, the topic of my talk on GVIP in the Cybersecurity track, where the conditions necessary to have trust in the system are explicitly formulated as a separate requirement.

The key takeaway from this three-day conference for me is the primary important we should all be placing on trust: trust in our infrastructure, trust in our software supply chain, and trust in our data supply chain. And if we are to have all of that, we would need to dedicate the necessary resources to create and implement the required standards and processes, and to build the necessary organizations, that make it possible to decide whom to trust and when.

The session provided crucial guidance on preparing for CRA compliance presented by Thomas Liedtke. A key insight clarified the CRA’s interaction with open source. Pure open-source development – code published on platforms like GitHub without commercial activity or monetization – generally falls outside the CRA’s scope. However, at that moment when open-source software becomes part of a commercial product (e.g., an open-source library in commercial software, or components in IoT devices), the entire commercial product must be CRA compliant. Companies must evaluate if they provide “products with digital elements” and, if so, implement controls to secure them throughout their lifecycle.

The session detailed essential compliance activities like cybersecurity concepts, risk management, managing open source dependencies and software supply chain risks. To achieve the appropriate security level of your product you have to follow a risk-based approach, know the elements of the secure market placement and take care about strong access management and data protection, not mentioning the importance of the resilience of your systems. Among the others robust vulnerability management was also highlighted, with specific mention of Article 13 (manufacturers’ obligations) and Article 14 (reporting tasks). This session underscored that for any organization using open source in commercial offerings, understanding and proactively addressing the CRA’s requirements is absolutely essential for future market access. And do not forget about the industry specific regulations for medicine, automotive or aviation if you work in these areas.

In today’s digital landscape, the threat surface is ever-expanding. We face an increasing tide of sophisticated attacks and data breaches, often perpetrated by well-organized adversaries who operate with the efficiency of a company. This reality highlights a critical truth: isolation is no longer an option for defense. The solution is clear: networking instead of silos – said by Christian Billmann. Creating communities and exchange ideas are getting more and more important that is the reason why Cybersecurity Region Stuttgart Meetup was created. Regional and local collaborations have a real impact on cybersecurity defense strategies. This initiative is dedicated to bringing people together, fostering connections, and sharing knowledge. Anyone interested can join their community, easily found on LinkedIn.

Another great initiative is the Automotive Security Research Group (ASRG) which was presented by Dirk Targoni. ASRG was born from the recognition that across the automotive industry, professionals facing similar problems related to cybersecurity. The increasing dependence on external data sources means shared challenges, and the logical response is to work together to solve them. ASRG currently boasts a dedicated network of over 100 volunteers working on different projects and researches.

In an era where attackers pool their resources and knowledge, it’s more critical than ever for defenders to do the same. We are not competitors; we are stronger together.

This presentation, “Using Apache Airflow to Automate Autonomous Driving Tests” by Bosch, details the significant challenges of testing software for autonomous vehicles and how Apache Airflow provides a robust solution.

The core problem lies in the sheer scale of testing required: to statistically prove that autonomous vehicles are safer than human drivers (e.g., 20% lower fatality rate with 95% confidence), an astronomical 14 billion kilometers of testing is needed. Physical testing alone would take 400 years with a fleet of 100 vehicles operating non-stop, making it impractical and statistically impossible for ensuring safety. Moreover, the “chaos of reality” (as illustrated by a chaotic street scene) demands testing across an immense number of complex scenarios. Standard CI/CD tools fall short here, as they are designed for short-lived code builds, not the massive test volumes, dynamic workflows, complex dependencies, and specialized hardware environments inherent to autonomous driving development.

Bosch, in collaboration with Cariad through the “Automated Driving Alliance,” adopted Apache Airflow as their orchestrator to manage thousands of parallel test executions. Airflow was chosen for its large community, Python-based workflow-as-code approach, enterprise-readiness, scalability, vendor/tech neutrality (Kubernetes, Spark/Hadoop, Docker), and Apache license, avoiding vendor lock-in. They even leverage Airflow for “Edge Worker” deployments to manage testing on remote sites with specialized hardware.

Key lessons learned include the importance of building on mature products rather than developing in-house solutions, leveraging the community for support, and prioritizing upstream contributions to minimize custom code. Bosch actively contributes to Airflow, helping shape its development in a direction that meets their critical safety needs.

Indeed, Bosch has been an extremely active contributor to the Apache Airflow project, making over 900 contributions, including new features, bug fixes, and improvements. They are deeply involved in the Airflow community through conferences, podcasts, and discussions, demonstrating a strong commitment to open-source collaboration and development. This extensive contribution highlights how they not only use Airflow but also actively help evolve it to meet the demanding requirements of autonomous driving test automation.

AI is everywhere, yet true, reliable AI innovation often feels out of reach. With only 9% of organizations achieving AI maturity (Gartner 2024) and 95% of GenAI projects expected to fail (MIT 2025), it’s clear: AI needs a disciplined approach to move from hype to real-world impact.

Dr. Thomas Usländer from Fraunhofer IOSB highlighted a critical solution at OpenChain and Friends 2026: AI Systems Engineering.

Why You Need AI Systems Engineering

Simply put, AI only becomes an innovation when it’s reliably, securely, and efficiently applied. We’re currently in the “Trough of Disillusionment” on the Gartner Hype Cycle for AI – where initial excitement fades as projects hit roadblocks. AI Systems Engineering is our map out of this trough.

It’s about treating AI not as magic, but as complex systems that need proper engineering.

What Is It? (The Core Idea)

AI Systems Engineering is a new discipline focused on:

1. Methodology: Structured ways to build and deploy AI. Think of PAISE® (Process Model for AI Systems Engineering) – it even treats data as “sub-systems” with their own development cycles.
2. Data Management (Data Spaces): AI needs data! Open, secure data-sharing platforms like Catena-X are crucial for industrial AI to scale and work together.
3. Responsible AI: With regulations like the European AI Act, building AI responsibly (considering roles, risks, and ethics) isn’t optional – it’s integrated into the engineering process.
4. System-Wide View: AI isn’t just an algorithm; it’s part of a larger system. This discipline ensures AI integrates smoothly and safely into broader operations.

AI Systems Engineering + Data Spaces: The Perfect Pair

These two concepts are inseparable. AI Systems Engineering gives you the “how-to” (the engineering process), while Data Spaces provide the “what-to-use” (the secure, shared data). Together, they enable the efficient development, deployment, and operation of AI systems, especially for industrial uses.

The Bottom Line

AI is powerful, but its true value is unlocked through discipline. AI Systems Engineering is crucial for making AI reliable, compliant, and genuinely innovative. Without it, many AI projects risk getting stuck in the “Valley of Death.” It’s the engineering foundation AI needs to thrive.

The following information was explain in this event:

• What is AGL? Automotive Grade Linux is a non-profit, open-source Linux-based collaborative project hosted at the Linux Foundation. Its goal is to build the car of the future through rapid innovation by uniting the automotive and software industries. It covers areas like infotainment, instrument clusters, Head-up Displays (HUD), telematics/connectivity, functional safety, and Advanced Driver Assistance Systems (ADAS).
• AGL at a Glance: It’s a Linux Foundation collaborative project with members including automakers, Tier 1 suppliers, and technology companies. It started in 2015 as the Unified Code Base (UCB) – an open platform for Software-Defined Vehicles (SDVs). It has been in production in Toyota and Lexus vehicles since 2018, with a refresh in 2026, and will be integrated into Subaru, Mazda, and Mercedes-Benz Vans. Its scope has expanded from infotainment to instrument clusters, telematics, ADAS, and beyond.
• 10+ Years of Tier 1/OEM Collaboration: AGL has proven that competitors can collaborate on shared software. It provides a neutral ground where OEMS and Tier 1s work side-by-side on a common platform. Code contributions come from automotive companies such as Toyota, Honda, Panasonic, Aisin, Denso, Jaguar Land Rover, Denso Ten, Mitsubishi, Daimler, and Subaru. This shared investment reduces duplication and accelerates innovation, resulting in production-ready open-source software in millions of vehicles.
• “The Last Mile Problem”: Lack of Senior Management Buy-In: The primary organizational barrier to open-source contribution is that leadership often fails to see the business value of contributing. Open source is not perceived as a strategic asset, and there are concerns about competitive advantage and intellectual property leakage. Without executive sponsorship, Open Source Program Offices (OSPOs) and contribution efforts stall, preventing developers from posting code to open repositories.
• AGL OSPO Expert Group: Launched in November 2024, this group is led by Toyota, with key members including Panasonic and Honda. Its objectives are to encourage companies to establish their own OSPOs, share pain points and collaborate on solutions, develop best practices for open source in the automotive industry, and address business restrictions (e.g., export control, anti-trust). The group meets monthly and is open to everyone which shows that everyone is welcome to participate and to support the team.
• AGL OSPO Expert Group – Executive Support: The group recognized the need for open-source sponsorship at the highest levels within companies. They created an “Executive Slide Deck,” available for anyone to use, to promote the value and usage of open source to executives. This deck includes case studies from Honda, Toyota, Bosch, and an unnamed Tier One supplier.
• Deployment Example: Suzuki e Vitara: New Suzuki EVs feature AGL and QT, developed by Aisin and Yazaki.

As summary I would take this as one good example how many different car manufacture can use one base and how everyone can participate in order to make this project better and better.