Featured

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.

The discussion revolved around how to effectively manage Software Bill of Materials (SBOMs) in the automotive and embedded software industries, which are complex and critical. The core challenge is that without automated SBOMs, managing risks across many software parts is extremely difficult, especially given regulatory requirements and complex supply chains.

A key focus was on leveraging existing open-source tools and frameworks to streamline this process. Automotive Grade Linux (AGL), a non-profit open-source Linux project for automotive systems, was highlighted as a strong starting point. By combining AGL with Yocto (a build toolchain), the presenters proposed a robust foundation for embedded SBOM operations. During the session it was also mentioned that no certification is required for AGL even for production used which is huge advantage.

The main idea was to build an automated system for assessing SBOMs, called AGL Assessment Automation (AAA). Its purpose is to create a reference system and share best practices for SBOMs in these industries. This involves:

• Validating policy-based assessment automation within the AGL Continuous Integration (CI) system.
• Adopting cybersecurity best practices from organizations like OpenSSF and CNCF, covering aspects like SBOM lifecycles and SLSA (Supply-chain Levels for Software Artifacts).
• Targeting SPDX 3.0 JSON as the preferred SBOM format (which is Yocto-compatible).
• Collaborating with various open-source communities like Yocto, OpenSSF, OpenChain, and SPDX.
• Utilizing open-source, reusable toolchains.

The presentation showed a best-case implementation flow for SBOMs, involving steps like generating, verifying, analyzing, enriching, and sharing SBOMs, with a continuous focus on risk management and vulnerability monitoring. A crucial pipeline example demonstrated building an SBOM from AGL, verifying it, analyzing risks, enriching it with more data, attesting its validity, and finally publishing it.

For risk analysis, the proposed system would normalize SBOM data from various sources (like Yocto environments generating SPDX 2 or 3) and then use a policy engine, such as OPA (Open Policy Agent), to perform policy-based risk analysis against defined policies.

Initial proof-of-concept work showed promising results, particularly in validating Yocto SPDX 3 SBOMs generated from AGL. While tools for SPDX 3.0 validation are still emerging, a simple validator was implemented as a proof-of-concept.

Looking ahead, the next steps include exploring different policy engines like OPA or OSS Review Toolkit (ORT), enhancing CVE/VEX operations within the Yocto ecosystem, and further integrating SLSA for improved software supply chain security.

There was a discussion regarding the legal and technical challenges surrounding open-source license compliance when distributing container images. The discussion highlighted the growing importance of understanding the layered structure of containers and the responsibilities associated with their distribution.

The Anatomy of a Container Image

Container images are essentially stacked layers. A typical image starts with a base layer containing fundamental system requirements like a C library, package manager, and shell. Subsequent layers add applications and libraries, and the top layer often involves customizations, including removing or modifying components. While a container’s runtime view might show a consolidated result, all underlying components remain present within it.

The Compliance Conundrum in Containers

The core challenge from a legal compliance standpoint is that it’s often unclear what software is actually distributed within a container. Most containers heavily rely on Free and Open Source Software (FOSS), and with FOSS, come license obligations. These obligations include providing license texts, legal notices, and sometimes even the source code and build instructions. Public container repositories frequently lack this crucial compliance information, yet the responsibility for fulfilling these obligations ultimately rests with the distributor, not necessarily the repository owner.

Who is the Distributor?

A key point emphasized was the legal interpretation of “distributor.” When a recipient executes a Containerfile (a script to assemble a container image), software is downloaded directly. The entity that “controls the distribution” is considered the distributor. This means that merely distributing a Containerfile can be legally equivalent to distributing software, triggering all associated license compliance duties.

OSADL’s Approach to Compliant Base Images

To address these complexities, the presentation introduced the concept of an OSADL Base Image. This is a minimal image built upon a Linux distribution, providing essential GNU tools, shell, C-lib, package manager, and networking functionalities. Crucially, it’s designed with license compliance in mind, including:

• Source code of all packages
• License texts and copyright notices
• Legal notices

OSSelot and FOSSology: Tools for Streamlined Compliance

The presentation highlighted the roles of OSSelot and FOSSology in achieving compliance:

• OSSelot is a publicly available, trusted database providing curated compliance information for frequently used FOSS components. It significantly reduces the time needed to “clear” a software package by allowing the reuse of pre-vetted licensing and copyright data.
• FOSSology is used in conjunction with OSSelot. The process involves:
  1. Using the OSSelot REST API to identify available OSSelot data for a container’s source packages.
  2. Uploading the OSSelot versions of packages into FOSSology, which then automatically clears the entire package.
  3. Uploading container source packages into FOSSology, running scanners, and reusing relevant OSSelot uploads to clear remaining files and copyrights.

Immediate vs. Delayed Source Code Disclosure

The OSADL Base Image offers two main approaches for source code disclosure:

• Immediate disclosure: All source code and legal information are included directly within the image. This approach simplifies access but can significantly increase the image size.
• Delayed disclosure: Only extracted compliance material, legal notices, and a written offer are included in the image. The full source packages with rebuild instructions are provided separately for later delivery. This method results in smaller container images but requires a separate mechanism for source code provision.

Both approaches ensure that instructions on how the base image is created and how it can be used are consistently provided.

As recommendation it was also mentioned that best practice would be FOSS compliance to be made layer by layer, meaning once you take for example OSADL Base Image then in order to make your own app you need to add few layers so its better to handle FOSS compliance after each layer instead of keep adding them until you reach the final product and handling this huge container with several layers in total in regards to FOSS compliance which would be harder and more time consuming.