# „Bitsea – Software Audit & Open-Source Compliance“ > Bitsea prüft Softwaresysteme auf versteckte Risiken, übernimmt technische Due Diligence und unterstützt Unternehmen — insbesondere Betreiber kritischer Infrastruktur — bei Open-Source-Compliance, Lizenzprüfungen und Software-Qualitätsanalyse. > Unsere Services umfassen Open-Source-Management, detaillierte Software-Qualitätsanalysen und technisches Projektmanagement. Mit modernsten Werkzeugen und ISO-basierten Verfahren identifizieren wir Lizenz- und Sicherheitsrisiken, garantieren Compliance und liefern klare Visualisierungen für Management und Entscheidungsträger. Vertrauen Sie auf jahrelange Erfahrung und höchste Standards bei Sicherheit, Wartbarkeit und Transparenz Ihrer Softwareprojekte. ## Seiten - [Produkte](https://bitsea.de/produkte/): CURATOR PRO TRANSPARENZ FÜR IHRE SOFTWARE-LIEFERKETTE. Schwachstellen erkennen Kontinuierliche Analyse bekannter CVEs CRA Compliance Auditierbare Nachweise & Reports KI-Assistent Vorschläge... - [Curator Pro (Englisch)](https://en.bitsea.de/services/curator-pro/): OPEN SOURCE MANAGEMENT PROFESSIONAL SERVICES FOR SOFTWARE RISK, COMPLIANCE AND DUE DILIGENCE What we deliver From baseline product audits to... - [Curator Pro](https://bitsea.de/produkte/curator-pro/): CURATOR PRO TRANSPARENZ FÜR IHRE SOFTWARE-LIEFERKETTE. Schwachstellen erkennen Kontinuierliche Analyse bekannter CVEs CRA Compliance Auditierbare Nachweise & Reports KI-Assistent Vorschläge... - [CRA Guardian (English)](https://en.bitsea.de/services/cra-guardian/): CRA GUARDIAN OUR CYBER RESILIENCE ACT COMPLIANCE READINESS SUITE CRA GUARDIAN Unsere Cyber Resilience Act Compliance Readiness Suite Situation The... - [CRA Guardian](https://bitsea.de/dienstleistungen/cra-guardian/): CRA GUARDIAN UNSERE CYBER RESILIENCE ACT COMPLIANCE READINESS SUITE CRA GUARDIAN Unsere Cyber Resilience Act Compliance Readiness Suite Situation Der... - [Orientierung im Open Source Ökosystem_v1 (Englisch (USA)) (English)](https://en.bitsea.de/oss-links/): Orientation in the Open Source Ecosystem Association, standards, and safety initiatives. Open source has long been a central component of... - [Orientierung im Open Source Ökosystem_v1 (Englisch (USA))](https://bitsea.us/oss-links-2/): Orientation in the Open Source Ecosystem Associations, standards, and safety initiatives. Open source has long been a central component of... - [Orientierung im Open Source Ökosystem_v1](https://bitsea.de/oss-links/): Orientierung im Open Source Ökosystem Verbände, Standards und Sicherheitsinitiativen. Open Source ist längst ein zentraler Bestandteil moderner Softwareentwicklung - aber... - [Datasheets](https://bitsea.us/datasheets/): Datasheets Our data sheets provide you with all the important information at a glance—from technical details to the advantages of... - [Datenblätter](https://bitsea.de/datenblatter/): Datenblätter Unsere Datenblätter bieten Ihnen alle wichtigen Informationen auf einen Blick – von technischen Details bis hin zu den Vorteilen... - [Kein Zugriff](https://bitsea.de/kein-zugriff/) - [Bitsea](https://en.bitsea.de/): Bitsea specializes in auditing software systems and identifying hidden risks in your code. We deliver the technical due diligence required... - [Bitsea](https://bitsea.us/): Bitsea specializes in auditing software systems and identifying hidden risks in your code. We deliver the technical due diligence required... - [Bitsea](https://bitsea.de/): Bitsea - Die Wahrheit liegt im Quellcode News Gründung der Bitsea US, Inc. Die Bitsea GmbH gibt die Übernahme des... - [Blog](https://bitsea.us/resources/blog-community/): Blog & Community Load more - [Blog](https://en.bitsea.de/resources/blog-community/): Blog & Community Load more - [Blog](https://bitsea.de/resources/blog-community/): Blog & Community MehrladenMehrladen - [404](https://bitsea.us/404-english-usa/): 404\n\nSeite nicht gefunden\n\nDer Server kann die von Ihnen angeforderte Datei nicht finden. Die Seite wurde entweder verschoben oder gelöscht, oder... - [404](https://bitsea.de/404-seite-nicht-gefunden/): 404 Page not found Server cannot find the file you requested. The Page has either been moved or deleted, or... - [404](https://bitsea.de/404-seite-nicht-gefunden/): 404 Seite nicht gefunden Der Server kann die von Ihnen angeforderte Datei nicht finden. Die Seite wurde entweder verschoben oder... - [Revenera](https://bitsea.de/ueber-uns/partner/revenera/): Revenera Visit Revenera: https://www. revenera. de/ Good developers don't write code from scratch. They know where to get code from.... - [Revenera](https://bitsea.de/ueber-uns/partner/revenera/): Revenera Visit Revenera: https://www. revenera. de/ Good developers don't write code from scratch. They know where to get code from.... - [Revenera](https://bitsea.de/ueber-uns/partner/revenera/): Revenera Revenera besuchen: https://www. revenera. de/ Gute Entwickler schreiben Code nicht von Grund auf neu. Sie wissen, woher Sie Code... - [Technical Project Management](https://bitsea.us/services/technical-project-management/): Technical Project Management Companies may unexpectedly reach a point where a lack of certain expert IT competence is realized. Complex... - [Software Quality Analysis](https://bitsea.us/services/software-quality-analysis/): Software Quality Analysis Many of the risks in software systems cannot be seen. This can seriously impact the company's “time-to-market”... - [Open Source Management](https://bitsea.us/services/open-source-management/): OPEN SOURCE MANAGEMENT PROFESSIONAL SERVICES FOR SOFTWARE RISK, COMPLIANCE AND DUE DILIGENCE What we deliver From baseline product audits to... - [Life at Bitsea](https://bitsea.us/careers/life-at-bitsea/): Life at Bitsea Interested? Take a look at Jobs TeamAt Bitsea, innovation thrives in a culture built on collaboration, curiosity,... - [Feedback](https://bitsea.de/feedback/): Customer Feedback Dear customer! Firstly we wanted to thank you for giving us the opportunity to run our assessment services... - [Software Quality Analysis](https://en.bitsea.de/services/software-quality-analysis/): Software Quality Analysis Many of the risks in software systems cannot be seen. This can seriously impact the company's “time-to-market”... - [Technical Project Management](https://en.bitsea.de/services/technical-project-management/): Technical Project Management Companies may unexpectedly reach a point where a lack of certain expert IT competence is realized. Complex... - [Open-Source-Management](https://en.bitsea.de/services/open-source-management/): Open-Source-Management Open source is everywhere. An efficient open-source-management framework and the use of suitable processes and toolchains are prerequisites for... - [Feedback](https://bitsea.de/feedback/): Customer Feedback Dear customer! Firstly we wanted to thank you for giving us the opportunity to run our assessment services... - [Life at Bitsea](https://bitsea.de/karriere/arbeiten-bei-bitsea/): Life at Bitsea Interested? Take a look at Jobs TeamBitsea is truly global: With employees from Germany, South Africa, Vietnam,... - [Feedbac](https://bitsea.de/feedback/): Kundenfeedback Sehr geehrter Kunde! Herzlichen Dank für Ihr Vertrauen in Bitsea und dafür, dass Sie uns Gelegenheit gegeben haben, für... - [Open-Source-Management](https://bitsea.de/dienstleistungen/open-source-management/): Open-Source-Management Open-Source ist überall. Ein effizientes Open-Source-Management Framework sowie der Einsatz geeigneter Prozesse und Werkzeugketten sind Voraussetzung für einen rechtssicheren... - [Technisches Projektmanagement](https://bitsea.de/dienstleistungen/technisches-projektmanagement/): Technisches Projektmanagement Unternehmen stehen oft unerwartet vor der Situation, dass bestimmtes IT-Know-how oder Expertise fehlt. Bei komplexen IT-Projekten wird der... - [Software Qualitätsanalyse](https://bitsea.de/dienstleistungen/software-qualitaetsanalyse/): Software Qualitätsanalyse Viele Risiken in Softwaresystemen sind "von außen" nicht sichtbar. Diese können einen gravierenden Einfluss auf den Zeitaufwand haben... - [Arbeiten bei Bitsea](https://bitsea.de/karriere/arbeiten-bei-bitsea/): Arbeiten bei Bitsea Interessiert? Sieh dir die Jobs an Team Wir bei Bitsea bieten ein tolles internationales Team mit Mitarbeitern... - [Lexicon](https://bitsea.de/ressourcen/lexikon/): Lexicon of the creatures of the wild and deep bit sea. On our journey to great code we discovered unusual... - [Events](https://bitsea.us/resources/events/): Events 02 12 December 2nd 2025 Bitkom AK Open Source Bitkom On December 2nd, 2025 and December 3rd, 2025, the... - [Lexicon](https://bitsea.de/ressourcen/lexikon/): Lexicon of the creatures of the wild and deep bit sea. On our journey to great code we discovered unusual... - [Events](https://en.bitsea.de/resources/events/): Events 02 12 December 2nd 2025 Bitkom AK Open Source Bitkom On December 2nd, 2025 and December 3rd, 2025, the... - [Lexikon](https://bitsea.de/ressourcen/lexikon/): Lexikon der Kreaturen der wilden und tiefen Bitsea. Auf unserer Reise zu gutem Code haben wir ungewöhnliche Muster der Lebensformen... - [Events](https://bitsea.de/ressourcen/events/): Events 02 12 2. Dezember 2025 Bitkom AK Open Source Bitkom Am 2. 12. 2025 sowie am 3. 12. 2025... - [Webinars](https://bitsea.de/ressourcen/webinare/): Webinar: Open Source Central: Was Sie Aktuell Über Open Source Security Wissen Sollten Kemp Little & Bitsea Webinar | Open... - [Research](https://bitsea.us/resources/research/): Bitsea research activity Bitsea is closely linked with research institutions and universities. Together we develop new products and services. European... - [Webinars](https://bitsea.de/ressourcen/webinare/): Webinar: Open Source Central: Was Sie Aktuell Über Open Source Security Wissen Sollten Kemp Little & Bitsea Webinar | Open... - [Research](https://bitsea.de/ressourcen/forschung/): Bitsea research activity Bitsea is closely linked with research institutions and universities. Together we develop new products and services EU... - [Webinare](https://bitsea.de/ressourcen/webinare/): Webinar: Open Source Central: Was Sie Aktuell Über Open Source Security Wissen Sollten Kemp Little & Bitsea Webinar | Open... - [Forschung](https://bitsea.de/ressourcen/forschung/): Forschung Bitsea ist eng verzahnt mit Forschungseinrichtungen und Universitäten. Gemeinsam entwickeln wir im Rahmen von Forschungsprojekten neue Produkte und Dienstleistungen.... - [Vision](https://bitsea.us/about-us/vision/): The truth is in the source code. How it all started To the Timeline Big software systems are like a... - [Tisax](https://bitsea.us/about-us/tisax/): Bitsea is TISAX- certified. The result is available for ENX members via the ENX portal: Retrieve TISAX result We have... - [Timeline](https://bitsea.us/about-us/timeline/): Timeline 2025 Founding of Bitsea US, Inc. 2024 EU-Digital Europe Program: OCCTET Development of a highly automated tool chain to... - [Sustainability](https://bitsea.us/about-us/sustainability/): Sustainability "It's cheaper to protect the planet now than to fix it later"-José Manuel Barosso Sustainable business plays an important... - [Partners](https://bitsea.us/about-us/partners/): Partners Bitsea works together with great partners: Bitsea is the exclusive services partner for Flexera/Revenera in Software Composition Analysis (SCA),... - [Associations](https://bitsea.us/about-us/associations/): Associations Bitsea closely cooperates with the following association: OpenChain Bitsea participates in the OpenChain Project. The OpenChain Project makes open... - [Vision](https://bitsea.de/ueber-uns/vision/): The truth is in the source code. How it all started To the Timeline Big software systems are like a... - [Associations](https://en.bitsea.de/about-us/associations/): Associations Bitsea closely cooperates with the following associations: Bitkom The Open Source Working Group addresses "open source as a strategic... - [Timeline](https://bitsea.de/ueber-uns/timeline/): Timeline 2024 EU-Digital Europe Program: OCCTET Development of a highly automated tool chain to facilitate CRA requirements for SMEs. 2024... - [Tisax](https://en.bitsea.de/about-us/tisax/): Bitsea is TISAX certified. The result is available for ENX members via the ENX portal: Retrieve TISAX result We have... - [Partners](https://en.bitsea.de/about-us/partners/): Partners Bitsea works together with great partners: Bitsea is certified partner of Revenera (formerly Flexera) and offers auditing services, installations... - [Sustainability](https://en.bitsea.de/about-us/sustainability/): Sustainability "It's cheaper to protect the planet now than to fix it later"-José Manuel Barosso Sustainable business plays an important... - [Nachhaltigkeit](https://bitsea.de/ueber-uns/nachhaltigkeit/): Nachhaltigkeit "Es ist billiger den Planeten jetzt zu schützen, als ihn später zu reparieren" -José Manuel Barosso Nachhaltiges Wirtschaften spielt... - [Partner](https://bitsea.de/ueber-uns/partner/): Partner Bitsea arbeitet intensiv mit folgenden Partnern zusammen: Bitsea ist zertifizierter Partner von Revenera (ehemals Flexera) und bietet Audit-Dienstleistungen, Installationen... - [Verbände](https://bitsea.de/ueber-uns/verbaende/): Verbände Bitsea arbeitet intensiv mit folgenden Verbänden zusammen: Bitkom Bitsea ist Mitglied der Bitkom und aktiv in der Open-Source-Arbeitsgruppe. Der... - [Tisax](https://bitsea.de/ueber-uns/tisax/): Bitsea ist TISAX-zertifiziert. Das Ergebnis ist für ENX-Mitglieder über das ENX-Portal abrufbar: TISAX Ergebnis anzeigen Vertraulichkeit, Verfügbarkeit und Integrität von... - [Unsere Geschichte](https://bitsea.de/ueber-uns/timeline/): Unsere Geschichte 2024 EU-Digital Europe Programm: OCCTET Entwicklung einer hoch automatisierten Werkzeugkette, um die Anforderungen des CRA für KMUs zu... - [Vision](https://bitsea.de/ueber-uns/vision/): Die Wahrheit liegt im Quellcode. Wie alles begann Zur Timeline Große Softwaresysteme sind wie ein wilder, weiter Ozean von Bits... - [Careers](https://bitsea.us/careers/): Life at Bitsea Learn moreJobs Bitsea is a leading provider of software audits and sustainable security, risk, and compliance management... - [Resources](https://bitsea.us/resources/): We analyze, evaluate and optimize your development processes, software architecture and software design. We take on the technical due diligence... - [About us](https://bitsea.us/about-us/): Our vision The truth is in the source code. Big software systems are like a wild wide ocean of bits... - [Resources](https://bitsea.de/ressourcen/): We analyze, evaluate and optimize your development processes, software architecture and software design. We take on the technical due diligence... - [Career](https://bitsea.de/karriere/): Life at Bitsea Read moreJobs Most industries today depend on IT systems. Rapid advances in software development and technology require... - [About us](https://en.bitsea.de/about-us/): Our vision The truth is in the source code. Big software systems are like a wild wide ocean of bits... - [Job & Karriere](https://bitsea.de/karriere/): Das Leben bei Bitsea Mehr erfahrenJobs Die meisten Branchen sind heute von IT-Systemen abhängig. Die rasanten Fortschritte in der Softwareentwicklung... - [Ressourcen](https://bitsea.de/ressourcen/): Wir analysieren, bewerten und optimieren Ihre Entwicklungsprozesse, Software-Architektur und das Software-Design. Wir übernehmen die technische Due-Diligence bei Firmenübernahmen. Forschung Mehr... - [Über uns](https://bitsea.de/ueber-uns/): Vision Die Wahrheit liegt im Quellcode. Große Softwaresysteme sind wie ein wilder, weiter Ozean von Bits und Bytes - unsere... - [Privacy Policy](https://bitsea.de/datenschutz/): Rechtliche Hinweise Wir freuen uns über Ihren Besuch auf unserer Website und Ihr Interesse an dem Leistungsangebot der Bitsea. Haftungsausschluss... - [Imprint](https://bitsea.de/impressum/): Imprint Bitsea GmbH Schlossstraße 7 53757 Sankt Augustin Handelsregister: Siegburg (HRB12763) Ust. -ID-Nr. : DE292785388 Geschäftsführer: Dr. Andreas Kotulla Telefon:... - [Contact](https://bitsea.us/contact/): Contact us Do you have any questions or are you interested in our services? Please use the contact form below... - [Contact](https://en.bitsea.de/contact/): Contact us Do you have any questions or are you interested in our services? Please use below contact form for... - [Imprint](https://bitsea.de/impressum/): Imprint Bitsea GmbH Schlossstraße 7 53757 Sankt Augustin Handelsregister: Siegburg (HRB12763) Ust. -ID-Nr. : DE292785388 Geschäftsführer: Dr. Andreas Kotulla Telefon:... - [Privacy Policy](https://bitsea.de/datenschutz/): Rechtliche Hinweise Wir freuen uns über Ihren Besuch auf unserer Website und Ihr Interesse an dem Leistungsangebot der Bitsea. Haftungsausschluss... - [Kontakt](https://bitsea.de/kontakt/): Kontaktformular Ihr direkter Draht zu uns. Hier können Sie einfach und direkt Kontakt mit uns aufnehmen. Oder Sie haben eine... - [Datenschutz](https://bitsea.de/datenschutz/): Rechtliche Hinweise Wir freuen uns über Ihren Besuch auf unserer Website und Ihr Interesse an dem Leistungsangebot der Bitsea. Haftungsausschluss... - [Impressum](https://bitsea.de/impressum/): Impressum Bitsea GmbH Schlossstraße 7 53757 Sankt Augustin Handelsregister: Siegburg (HRB12763) Ust. -ID-Nr. : DE292785388 Geschäftsführer: Dr. Andreas Kotulla Telefon:... ## Beiträge - [OpenChain CRA Checkliste](https://bitsea.de/blog/2026/08/openchaincra-checkliste-praxisleitfaden-fuer-den-cyber-resilience-act/): OpenChain CRA Anforderungen & Checkliste: So wird die Umsetzung des Cyber Resilience Acts greifbar Der europäische Cyber Resilience Act (CRA)... - [OpenChain CRA Checklist](https://bitsea.us/blog/2026/08/openchain-cra-checklist-copy/): OpenChain CRA Requirement & Checklist: Turning Cyber Resilience Act Compliance into Action The European Cyber Resilience Act (CRA) is transforming... - [OpenChain CRA Checklist](https://en.bitsea.de/blog/2026/08/openchain-cra-checklist/): OpenChain CRA Requirement & Checklist: Turning Cyber Resilience Act Compliance into Action The European Cyber Resilience Act (CRA) is transforming... - [SPDX 3.1 Is Coming – and Curator Pro Is Ready](https://bitsea.us/blog/2026/07/spdx-3-1-is-coming-and-curator-pro-is-ready-2/): How the new SBOM standard is transforming software supply chain management and why it is critical for your CRA compliance... - [SPDX 3.1 Is Coming – and Curator Pro Is Ready](https://bitsea.us/blog/2026/07/spdx-3-1-is-coming-and-curator-pro-is-ready-2/): How the new SBOM standard is transforming software supply chain management and why it is critical for your CRA compliance... - [SPDX 3.1 Is Coming – and Curator Pro Is Ready](https://en.bitsea.de/blog/2026/07/spdx-3-1-is-coming-and-curator-pro-is-ready/): How the new SBOM standard is transforming software supply chain management and why it is critical for your CRA compliance... - [SPDX 3.1 kommt – und Curator Pro ist bereit](https://bitsea.de/blog/2026/07/spdx-3-1-kommt-und-curator-pro-ist-bereit/): Wie der neue SBOM-Standard das Software-Lieferketten-Management verändert und warum das für Ihre CRA-Compliance entscheidend ist. Bitsea GmbH · Juli 2026... - [Warum FOSS-Audits bei Fusionen und Übernahmen wichtig sind](https://bitsea.de/blog/2026/04/warum-foss-audits-bei-fusionen-und-ubernahmen-wichtig-sind/): Software ist zu einem der wertvollsten Vermögenswerte moderner Technologieunternehmen geworden. Daher erfordern Fusionen und Übernahmen im Softwarebereich zunehmend eine sorgfältige... - [Why FOSS Audits Matter in Mergers and Acquisitions](https://en.bitsea.de/blog/2026/04/why-foss-audits-matter-in-mergers-and-acquisitions/): Software as a Core Asset Software is one of the most valuable assets in modern technology companies. As a result,... - [Für den „Ludwig 2026“ nominiert – Innovation aus Bonn/Rhein-Sieg](https://bitsea.de/blog/2026/04/fuer-den-ludwig-2026-nominiert-innovation-aus-bonn-rhein-sieg/): Wir haben großartige Neuigkeiten: Unser Unternehmen wurde für den regionalen Mittelstandspreis „Ludwig 2026“ in der Kategorie Innovation nominiert! Diese Nominierung... - [Wenn ein Patch für Open-Source zur gesetzlichen Pflicht wird: CRA-Schwachstellenbehandlung und die neue Verantwortung der Softwarehersteller](https://bitsea.de/blog/2026/04/wenn-ein-patch-fuer-open-source-zur-gesetzlichen-pflicht-wird-cra-schwachstellenbehandlung-und-die-neue-verantwortung-der-softwarehersteller/): Der Cyber Resilience Act (CRA) bringt eine subtile, aber tiefgreifende Veränderung in die Art und Weise, wie Hersteller über Open-Source-Software... - [When a FOSS Patch Becomes a Legal Obligation: CRA Vulnerability Handling and the New Responsibility of Integrators](https://bitsea.us/blog/2026/04/when-a-foss-patch-becomes-a-legal-obligation-cra-vulnerability-handling-and-the-new-responsibility-of-integrators/): The Cyber Resilience Act (CRA) introduces a subtle but profound shift in how manufacturers must think about open source software.... - [When a FOSS Patch Becomes a Legal Obligation: CRA Vulnerability Handling and the New Responsibility of Integrators](https://en.bitsea.de/blog/2026/04/when-a-foss-patch-becomes-a-legal-obligation-cra-vulnerability-handling-and-the-new-responsibility-of-integrators/): The Cyber Resilience Act (CRA) introduces a subtle but profound shift in how manufacturers must think about open source software.... - [Trivy, KICS, LiteLLM: A Supply Chain Warning on Transitive Dependencies](https://bitsea.us/blog/2026/04/trivy-kics-litellm-a-supply-chain-warning-on-transitive-dependencies-2/): How a compromise in trusted security tooling rippled through Checkmarx KICS and LiteLLM, exposing the real risk of transitive dependencies.... - [Trivy, KICS, LiteLLM: Eine Warnung zur Lieferkette hinsichtlich transitiver Abhängigkeiten](https://bitsea.us/blog/2026/04/trivy-kics-litellm-eine-warnung-zur-lieferkette-hinsichtlich-transitiver-abhangigkeiten/): Wie sich eine Sicherheitslücke in einem bewährten Sicherheitstool auf Checkmarx KICS und LiteLLM auswirkte und das tatsächliche Risiko transitiver Abhängigkeiten... - [Trivy, KICS, LiteLLM: A Supply Chain Warning on Transitive Dependencies](https://bitsea.us/blog/2026/04/trivy-kics-litellm-a-supply-chain-warning-on-transitive-dependencies/): How a compromise in trusted security tooling rippled through Checkmarx KICS and LiteLLM, exposing the real risk of transitive dependencies.... - [BSI 21st German IT-Security Congress](https://en.bitsea.de/blog/2026/03/bsi-21st-german-it-security-congress/): The Federal Office for Information Security (BSI) invites you to the 21st German IT Security Congress from April 15 to... - [BSI 21. Deutscher IT-Sicherheitskongress](https://bitsea.de/blog/2026/03/bsi-21-deutscher-it-sicherheitskongress/): Das Bundesamt für Sicherheit in der Informationstechnik (BSI) lädt vom 15. bis 16. April 2026 zum 21. Deutschen IT-Sicherheitskongress ein... - [CRA and Security Incidents Outside EU](https://bitsea.us/blog/2026/03/cra-and-security-incidents-outside-eu/): When a Security Incident Happens Outside the EU: Does the CRA Still Apply? The global nature of cybersecurity raises a... - [CRA und Sicherheitsvorfälle außerhalb der EU](https://bitsea.de/blog/2026/03/cra-und-sicherheitsvorfaelle-ausserhalb-der-eu/): Der CRA orientiert sich am Markt, nicht an der Geografie Der CRA ist eine Produktverordnung und gilt für Produkte mit... - [SaaS Is Not a blanket exemption: Remote Data Processing, SBOMs, and the CRA](https://bitsea.us/blog/2026/03/saas-is-not-a-blanket-exemption-remote-data-processing-sboms-and-the-cra/): Software companies often rely on a familiar distinction: they regulate products, but not services. They have viewed cloud delivery models,... - [SaaS ist keine generelle Ausnahme beim CRA: Remote-Datenverarbeitung, SBOMs und der CRA](https://bitsea.de/blog/2026/03/saas-ist-keine-generelle-ausnahme-beim-cra-remote-datenverarbeitung-sboms-und-der-cra/): Softwareunternehmen verlassen sich häufig auf eine vertraute Unterscheidung: Produkte sind reguliert, Services nicht. Cloud-Delivery-Modelle, abonnementbasierte Modelle und Remote-Verarbeitung wurden oft... - [CRA and Security Incidents Outside EU](https://en.bitsea.de/blog/2026/03/cra-and-security-incidents-outside-eu/): When a Security Incident Happens Outside the EU: Does the CRA Still Apply? The global nature of cybersecurity raises a... - [SaaS Is Not a blanket exemption: Remote Data Processing, SBOMs, and the CRA](https://en.bitsea.de/blog/2026/03/saas-is-not-a-blanket-exemption-remote-data-processing-sboms-and-the-cra/): Software companies often rely on a familiar distinction: they regulate products, but not services. They have viewed cloud delivery models,... - [Cyber Resilience Act and Legacy Products](https://bitsea.us/blog/2026/03/cyber-resilience-act-and-legacy-products/): One of the frequently asked questions surrounding the Cyber Resilience Act (CRA) concerns legacy products. Manufacturers ask whether they can... - [Cyber Resilience Act und Altsysteme](https://bitsea.de/blog/2026/03/cyber-resilience-act-und-altsysteme/): Eine der häufigsten Fragen zum Cyber Resilience Act (CRA) betrifft die Handhabe von Altsystemen. Hersteller aus verschiedenen Branchen fragen, ob... - [Cyber Resilience Act and Legacy Products](https://en.bitsea.de/blog/2026/03/cyber-resilience-act-and-legacy-products/): One of the frequently asked questions surrounding the Cyber Resilience Act (CRA) concerns legacy products. Manufacturers ask whether they can... - [SBOMs as Primary Compliance Mechanism](https://bitsea.us/blog/2026/02/sboms-as-primary-compliance-mechanism/): The EU’s growing focus on SBOMs, highlighted in ENISA’s SBOM Landscape Analysis – Towards an Implementation Guide, is a key... - [SBOMs als primärer Compliance-Mechanismus](https://bitsea.de/blog/2026/02/sboms-as-primary-compliance-mechanism/): Der zunehmende Fokus der Europäischen Union auf Software Bills of Materials (SBOMs), zuletzt sichtbar im ENISA-Bericht SBOM Landscape Analysis –... - [SBOMs as primary compliance mechanism](https://en.bitsea.de/blog/2026/02/sboms-as-primary-compliance-mechanism/): The EU’s growing focus on SBOMs, highlighted in ENISA’s SBOM Landscape Analysis – Towards an Implementation Guide, is a key... - [Linux Syscall Note: Devil is in the details](https://bitsea.us/blog/2026/02/linux-syscall-note-devil-is-in-the-details/): Introduction to the Syscall Exception The syscall exception maps closely to how the Linux kernel exposes its user-space interface. The... - [Die Linux-Syscall-Anmerkung verstehen](https://bitsea.de/blog/2026/02/die-linux-syscall-anmerkung-verstehen/): Die Syscall-Ausnahme orientiert sich eng daran, wie der Linux-Kernel seine Benutzerschnittstelle nach User Space bereitstellt. Der durch die Syscall-Notiz abgedeckte... - [Linux Syscall Note: Devil is in the details](https://en.bitsea.de/blog/2026/02/linux-syscall-note-devil-is-in-the-details/): Introduction to the Syscall Exception The syscall exception maps closely to how the Linux kernel exposes its user-space interface. The... - [Shai-Hulud, npm, and modern software supply chains](https://en.bitsea.de/blog/2026/01/shai-hulud-npm-and-modern-software-supply-chains/): In September 2025, the npm ecosystem experienced one of the most consequential software supply-chain compromises to date. A self-propagating worm,... - [Shai-Hulud, npm und moderne Software-Lieferketten](https://bitsea.de/blog/2026/01/shai-hulud-npm-und-moderne-software-lieferketten/): Im September 2025 widerfuhr dem npm-Ökosystem eine der bislang folgenschwersten Kompromittierungen der Software-Lieferkette. Ein sich selbst verbreitender Wurm, der heute... - [Shai-Hulud, npm, and modern software supply chains](https://bitsea.us/blog/2026/01/shai-hulud-npm-and-modern-software-supply-chains/): In September 2025, the npm ecosystem experienced one of the most consequential software supply-chain compromises to date. A self-propagating worm,... - [Die verschiedenen Creative-Commons-Lizenzen und ihre Auswirkungen auf die gemeinsame Nutzung von Software, die Einhaltung von Vorschriften und die Zusammenarbeit verstehen.](https://bitsea.de/blog/2026/01/die-verschiedenen-creative-commons-lizenzen-und-ihre-auswirkungen-auf-die-gemeinsame-nutzung-von-software-die-einhaltung-von-vorschriften-und-die-zusammenarbeit-verstehen/): Ein Überblick über die Creative Commons-Lizenzsuite Creative Commons (CC) Lizenzsuite wurde entwickelt, um die Weitergabe kreativer Werke zu vereinfachen und... - [Understanding the Different Creative Commons Licenses and How They Impact Software Sharing, Compliance, and Collaboration.](https://en.bitsea.de/blog/2026/01/understanding-the-different-creative-commons-licenses-and-how-they-impact-software-sharing-compliance-and-collaboration/): An Overview of the Creative Commons License SuiteBy Marcus Lucero, Senior Open Source Analyst at Bitsea The Creative Commons (CC)... - [Understanding the different Creative Commons licenses and how they impact software sharing, compliance, and collaboration.](https://bitsea.us/blog/2026/01/understanding_the_different_creative_commons_licenses_and_how_they_impact_software_sharing_compliance_and_collaboration/): An Overview of the Creative Commons License Suite Creative Commons (CC) designed its license suite to make sharing creative work... - [Understanding Open Source Remediation](https://en.bitsea.de/blog/2025/12/understanding-open-source-remediation/): When you work with open source software, you eventually come across a licensing issue that needs fixing. Maybe a GPL... - [Open Source-Remediation verstehen](https://bitsea.de/blog/2025/12/open-source-remediation-verstehen/): Wenn Sie mit Open-Source-Software arbeiten, stoßen Sie irgendwann auf ein Lizenzproblem, das behoben werden muss. Vielleicht hat sich eine GPL-Komponente... - [Understanding Open Source Remediation](https://bitsea.us/blog/2025/12/understanding-open-source-remediation-2/): When you work with open source software, you eventually come across a licensing issue that needs fixing. Maybe a GPL... - [Understanding India's SBOM requirements:](https://bitsea.us/blog/2025/11/understanding-indias-sbom-requirements/): What CERT-In and SEBI Expect As software supply chain risks escalate globally, India has moved decisively to strengthen its regulatory... - [Indiens SBOM-Anforderungen verstehen: CERT-In und SEBI](https://bitsea.de/blog/2025/11/indiens-sbom-anforderungen-verstehen-cert-in-und-sebi/): Angesichts der weltweit zunehmenden Risiken in der Software-Lieferkette hat auch Indien beschlossen, seine Regulierungsmaßnahmen zu verstärken. In den letzten Jahren... - [Understanding India's SBOM requirements: What CERT-In and SEBI Expect](https://en.bitsea.de/blog/2025/11/understanding-indias-sbom-requirements-what-cert-in-and-sebi-expect/): As software supply chain risks escalate globally, India has moved decisively to strengthen its regulatory posture. In recent years, two... - [What You Need to Know about the Different Types of SBOMs](https://en.bitsea.de/blog/2025/10/what_you_need_to_know_about_the_different_types_of_sboms-2/): When it comes to managing software security and compliance, understanding and generating Software Bill of Materials (SBOMs) is crucial, especially... - [SBOMs verstehen: Was Sie über die verschiedenen Arten von SBOMs wissen müssen](https://bitsea.de/blog/2025/10/sboms-verstehen-was-sie-uber-die-verschiedenen-arten-von-sboms-wissen-mussen/): Wenn es um das Management der Cybersicherheit und Software-Compliance geht, ist das Verständnis und die Erstellung von Software-Stücklisten (SBOMs) von... - [What You Need to Know about the Different Types of SBOMs](https://bitsea.us/blog/2025/10/what_you_need_to_know_about_the_different_types_of_sboms/): When it comes to managing software security and compliance, understanding and generating Software Bill of Materials (SBOMs) is crucial, especially... - [Anyone who continues to release AI-generated code today is acting with at least conditional intent to infringe the law.](https://bitsea.us/blog/2025/10/publishing-ai-generated-code-now-risks-legal-infringement/): From Efficiency to Exposure: The Rise of Vibe Coding Today, developers rarely write every line of code from scratch. Most... - [Wer heute noch KI generierten Code in Umlauf bringt, hat bedingten Vorsatz für Rechtsverletzungen.](https://bitsea.de/blog/2025/10/wer-heute-noch-ki-generierten-code-in-umlauf-bringt-hat-bedingten-vorsatz-fuer-rechtsverletzungen/): Von Effizienz zum Risiko: Der Aufstieg des Vibe Coding Entwickler schreiben nicht jede Zeile Code von Grund auf neu. Die... - [Anyone who still circulates AI-generated code has conditional intent for legal violations.](https://en.bitsea.de/blog/2025/10/anyone-who-still-circulates-ai-generated-code-has-conditional-intent-for-legal-violations/): From Efficiency to Exposure: The Rise of Vibe Coding Developers no longer write every line of code from scratch. Most... - [New Open Source Guide, Version 3.3:](https://bitsea.us/blog/2025/09/new-open-source-guide-version-3-3-practical-recommendations-in-a-nutshell/): – Practical recommendations in a nutshell The Bitkom publication Practical Recommendations for Open Source Software (version 3. 3) provides comprehensive... - [New open source guide, version 3.3: Practical recommendations in a nutshell](https://en.bitsea.de/blog/2025/09/new-open-source-guide-version-3-3-practical-recommendations-in-a-nutshell/): The Bitkom publication Practical Recommendations for Open Source Software (version 3. 3) provides comprehensive guidance for companies and administrations that... - [Neuer Open-Source-Leitfaden Version 3.3: Praxisempfehlungen kompakt](https://bitsea.de/blog/2025/09/neuer-open-source-leitfaden-version-3-3-praxisempfehlungen-kompakt/): Die Bitkom-Publikation Praxisempfehlungen für Open-Source-Software (Version 3. 3) liefert eine umfassende Orientierung für Unternehmen und Verwaltungen, die Open-Source gezielt einsetzen... - [Open Source Monitor 2025: The importance of open source for business and administration](https://en.bitsea.de/blog/2025/09/open-source-monitor-2025-the-importance-of-open-source-for-business-and-administration/): Open source is no longer a niche topic—in 2025, it is clearer than ever how indispensable open software has become... - [Open Source Monitor 2025](https://bitsea.us/blog/2025/09/open-source-monitor-2025-the-importance-of-open-source-for-business-and-administration/): – The importance of open source for business and administration Open source is no longer a niche topic—in 2025, it... - [Understanding Radio Equipment Directive: What it means for FOSS and SBOMs.](https://bitsea.us/blog/2025/09/understanding-radio-equipment-directive-what-it-means-for-foss-and-sboms/): Do you deliver Electronic Equipment with Radio components to the EU? Then the following new Regulation is relevant for you:... - [Understanding Radio Equipment Directive: What it means for FOSS and SBOMs.](https://en.bitsea.de/blog/2025/09/understanding-radio-equipment-directive-what-it-means-for-foss-and-sboms/): The Radio Equipment Directive (RED)1, formally known as Directive 2014/53/EU, is the European Union’s framework for regulating devices that communicate... - [Die neue EU Funkgeräterichtlinie verstehen](https://bitsea.de/blog/2025/09/die-neue-eu-funkgeraeterichtlinie-verstehen-was-sie-fuer-foss-und-sboms-bedeutet/): – Was sie für FOSS und SBOMs bedeutet Die Funkgeräterichtlinie ,,Radio Equipment Directive” (RED)1, offiziell bekannt als Richtlinie 2014/53/EU, ist... - [OpenSSF Community Day North America 2026: Advancing Open Source Security in Minneapolis](https://bitsea.us/blog/2025/08/forum-open-source-2025/): On May 21, 2026, the Open Source Security Foundation (OpenSSF) will bring its flagship community event to Minneapolis, co-located with... - [Invitation to the event: Digital sovereignty in the age of AI and regulation](https://en.bitsea.de/blog/2025/08/forum-open-source-2025/): We cordially invite you to the Cybersecurity Summit 2026 on 26 February from 3 p. m. at Motorworld Cologne. Learn... - [Einladung zum Event: Digitale Souveränität in Zeiten von KI und Regulierung](https://bitsea.de/blog/2025/08/forum-open-source-2025/): Wir laden Sie herzlich zum Cybersecurity Summit 2026 am 26. Februar ab 15:00 Uhr in der Motorworld Köln ein. Erfahren... - [Bitsea Establishes New U.S. Subsidiary and Acquires Revenera’s Auditing Services Team](https://bitsea.us/blog/2025/07/bitsea-establishes-new-u-s-subsidiary-and-acquires-reveneras-auditing-services-team/): Bitsea GmbH, a leading provider of IT services and open source compliance analysis based in Germany, announces the acquisition of... - [Bitsea Establishes New U.S. Subsidiary and Acquires Revenera’s Auditing Services Team](https://en.bitsea.de/blog/2025/07/bitsea-establishes-new-u-s-subsidiary-and-acquires-reveneras-auditing-services-team/): Bitsea GmbH, a leading provider of IT services and open source compliance analysis based in Germany, announces the acquisition of... - [Bitsea gründet neue US-Niederlassung und übernimmt Team von Revenera Auditing Services](https://bitsea.de/blog/2025/07/bitsea-gruendet-neue-us-niederlassung-und-uebernimmt-team-von-flexera-auditing-services/): Die Bitsea GmbH, ein führender Anbieter von IT-Dienstleistungen und Open-Source-Compliance-Analysen mit Sitz in Sankt Augustin, Deutschland, gibt die Übernahme des... - [OCCTET: An Open Source Lifeline for CRA Compliance in Europe](https://bitsea.us/blog/2025/05/occtet-an-open-source-lifeline-for-cra-compliance-in-europe/): Open Source Everywhere — And a New Challenge On any given day, tech companies in Europe are shipping products with... - [OCCTET: Eine Open Source Lösung für die CRA-Compliance in Europa](https://bitsea.de/blog/2025/05/occtet-eine-open-source-loesung-fuer-die-cra-compliance-in-europa/): Open Source ist überall—Und eine neue Herausforderung Täglich bringen europäische Tech-Unternehmen Produkte mit digitalen Komponenten auf den Markt. Im Hintergrund... - [OCCTET: An Open Source Lifeline for CRA Compliance in Europe](https://en.bitsea.de/blog/2025/05/occtet-an-open-source-lifeline-for-cra-compliance-in-europe/): Open Source Everywhere — And a New Challenge On any given day, tech companies in Europe are shipping products with... - [Shape the future now! We show you how – at the Mittelstand Innovation Day 2025](https://bitsea.us/blog/2025/04/zukunft-jetzt-gestalten-wir-zeigen-wie-beim-innovationstag-mittelstand-2025/): New technologies, innovative projects, and creative ideas as guide for the future – that’s what small and medium-sized enterprises will... - [Shape the future now! We show you how – at the Mittelstand Innovation Day 2025](https://bitsea.de/blog/2025/04/zukunft-jetzt-gestalten-wir-zeigen-wie-beim-innovationstag-mittelstand-2025/): On June 5, 2025, Innovation Day for SMEs in Berlin will showcase new technologies – including our VR visualization of software architecture. - [Zukunft jetzt gestalten! Wir zeigen wie – beim Innovationstag Mittelstand 2025](https://bitsea.de/blog/2025/04/zukunft-jetzt-gestalten-wir-zeigen-wie-beim-innovationstag-mittelstand-2025/): Am 5.06.2025 zeigt der Innovationstag Mittelstand in Berlin neue Technologien – mit dabei: unsere VR-Visualisierung zu Software-Architektur. - [Understanding the Cyber Resilience Act and Its Impact on the Automotive Industry](https://bitsea.us/blog/2025/03/cyber-resilience-act-und-seine-auswirkungen-auf-die-automobilindustrie-verstehen-3/): As cars become more like computers on wheels, cybersecurity is becoming a major concern. With vehicles now connected to the... - [Understanding the Cyber Resilience Act and Its Impact on the Automotive Industry](https://bitsea.us/blog/2025/03/cyber-resilience-act-und-seine-auswirkungen-auf-die-automobilindustrie-verstehen-2/): As cars become more like computers on wheels, cybersecurity is becoming a major concern. With vehicles now connected to the... - [Understanding the Cyber Resilience Act and Its Impact on the Automotive Industry](https://bitsea.de/blog/2025/03/cyber-resilience-act-und-seine-auswirkungen-auf-die-automobilindustrie-verstehen/): As cars become more like computers on wheels, cybersecurity is becoming a major concern. With vehicles now connected to the... - [Understanding the Cyber Resilience Act and Its Impact on the Automotive Industry](https://en.bitsea.de/blog/2025/03/cyber-resilience-act-und-seine-auswirkungen-auf-die-automobilindustrie-verstehen/): As cars become more like computers on wheels, cybersecurity is becoming a major concern. With vehicles now connected to the... - [Den Cyber Resilience Act und seine Auswirkungen auf die Automobilindustrie verstehen](https://bitsea.de/blog/2025/03/cyber-resilience-act-und-seine-auswirkungen-auf-die-automobilindustrie-verstehen/): Mit der fortschreitenden Digitalisierung werden Fahrzeuge zunehmend zu „Computern auf Rädern“. In diesem Zusammenhang gewinnt Cybersicherheit erheblich an Bedeutung. Moderne... - [The digital check-up: Static analysis as a doctor for your code](https://bitsea.de/blog/2025/01/the-digital-check-up-static-analysis-as-a-doctor-for-your-code/): The Challenges of Maintaining Legacy Software A quick, easy-to-understand overview is what many people want in life. Especially with historically... - [The digital check-up: Static analysis as a doctor for your code](https://bitsea.de/blog/2025/01/der-digitale-check-up-statische-analyse-als-arzt-fuer-ihren-code/): Explore Bisquat2: a static analysis tool that diagnoses code health with metrics, visualizations, and antipattern detection for robust, maintainable software. - [Der digitale Check-up: Statische Analyse als Arzt für Ihren Code](https://bitsea.de/blog/2025/01/der-digitale-check-up-statische-analyse-als-arzt-fuer-ihren-code/): Entdecken Sie Bisquat2: ein statisches Analysetool, das den Zustand von Code mit Metriken, Visualisierungen und Erkennung von Fehlverhalten für robuste, wartbare Software diagnostiziert. - [The Critical Role of Scanning Depth and SBOMs](https://bitsea.us/blog/2024/12/the-critical-role-of-scanning-depth-and-sboms/): Navigating Open-Source-Compliance in 2024: The Critical Role of Scanning Depth and SBOMs In the evolving landscape of cybersecurity and software... - [Die entscheidende Rolle von Scan-Tiefe und SBOM](https://bitsea.de/blog/2024/12/die-entscheidende-rolle-von-scan-tiefe-und-sbom/): Open-Source-Compliance im Jahr 2024: Die entscheidende Rolle von Scan-Tiefe und SBOMs Die Welt der Cybersicherheit und Software-Compliance steht an einem... - [The Critical Role of Scanning Depth and SBOMs](https://en.bitsea.de/blog/2024/12/the-critical-role-of-scanning-depth-and-sboms/): Navigating Open-Source-Compliance in 2024: The Critical Role of Scanning Depth and SBOMs In the evolving landscape of cybersecurity and software... - [Building a Resilient Software Supply Chain: Challenges Taiwan Faces in Adopting OpenChain](https://bitsea.de/blog/2024/11/building-a-resilient-software-supply-chain-challenges-taiwan-faces-in-adopting-openchain/): As a member of the OpenChain community Bitsea maintains partnerships worldwide. Today we would like to share insights on open... - [Aufbau einer widerstandsfähigen Software-Lieferkette: Herausforderungen für Taiwan bei der Einführung von OpenChain](https://bitsea.de/blog/2024/11/aufbau-einer-widerstandsfaehigen-software-lieferkette-herausforderungen-fuer-taiwan-bei-der-einfuehrung-von-openchain/): Entdecken Sie die Herausforderungen, vor denen Taiwan bei der Einführung von OpenChain für Open-Source-Compliance steht. Erfahren Sie mehr über ISO-Standards, frühe Anwender und die Bedeutung der Bewusstseinsbildung für den Aufbau einer widerstandsfähigen Software-Lieferkette. - [Building a Resilient Software Supply Chain: Challenges Taiwan Faces in Adopting OpenChain](https://bitsea.de/blog/2024/11/aufbau-einer-widerstandsfaehigen-software-lieferkette-herausforderungen-fuer-taiwan-bei-der-einfuehrung-von-openchain/): Discover the challenges Taiwan faces in adopting OpenChain for open-source compliance. Learn about ISO standards, early adopters, and the importance of raising awareness to build a resilient software supply chain. - [Immersive open source compliance visualization](https://bitsea.de/blog/2024/11/immersive-open-source-compliance-visualization/): Imagine you could search through every single component of your software like a map – identify risks at a glance,... - [Immersive open source compliance visualization](https://bitsea.de/blog/2024/11/immersive-open-source-compliance-visualisierung/): Imagine you could search through every single component of your software like a map – identify risks at a glance,... - [Immersive Open Source Compliance-Visualisierung](https://bitsea.de/blog/2024/11/immersive-open-source-compliance-visualisierung/): Stellen Sie sich vor, Sie könnten jede einzelne Komponente Ihrer Software wie eine Landkarte durchforsten – Risiken auf einen Blick... - [The LöhnApp: A digital tool to increase efficiency](https://bitsea.de/blog/2024/10/die-loehnapp-ein-digitales-werkzeug-zur-effizienzsteigerung/): The LöhnMethod is your key to holistic success – professionally and privately. More than a calendar system, it offers a... - [The LöhnApp: A digital tool to increase efficiency](https://bitsea.de/blog/2024/10/die-loehnapp-ein-digitales-werkzeug-zur-effizienzsteigerung/): The LöhnMethod is your key to holistic success – professionally and privately. More than a calendar system, it offers a... - [Die LöhnApp: Ein digitales Werkzeug zur Effizienzsteigerung](https://bitsea.de/blog/2024/10/die-loehnapp-ein-digitales-werkzeug-zur-effizienzsteigerung/): Die LöhnMethode ist Ihr Schlüssel zu ganzheitlichem Erfolg – beruflich und privat. Mehr als ein Kalendersystem, bietet sie eine umfassende... - [Digital Operational Resilience Act (DORA): Comprehensive checklist for companies](https://bitsea.de/blog/2024/09/digital-operational-resilience-act-dora-comprehensive-checklist-for-companies/): Ms. Wittman is a lawyer in Munich and a partner at Bitsea. To enhance digital operational resilience, the European Commission... - [Digital Operational Resilience Act (DORA): Comprehensive checklist for companies](https://bitsea.de/blog/2024/09/digital-operational-resilience-act-dora-umfangreiche-checkliste-fuer-unternehmen/): Ms. Wittman is a lawyer in Munich and a partner at Bitsea. To enhance digital operational resilience, the European Commission... - [Digital Operational Resilience Act (DORA): Umfangreiche Checkliste für Unternehmen](https://bitsea.de/blog/2024/09/digital-operational-resilience-act-dora-umfangreiche-checkliste-fuer-unternehmen/): Frau Wittman ist Anwältin in München und Partner von Bitsea. Um die digitale operative Widerstandsfähigkeit zu verbessern, hat die Europäische... - [NIS2 Preparation Checklist for Open Source Software](https://bitsea.de/blog/2024/08/nis2-preparation-checklist-for-open-source-software/): As the implementation deadline for the revised Network and Information Systems Directive (NIS2) approaches, companies across the EU need to... - [NIS2 Preparation Checklist for Open Source Software](https://bitsea.de/blog/2024/08/devorbereitungen-fuer-die-nationale-umsetzungsfrist-der-nis2-richtlinie/): As the implementation deadline for the revised Network and Information Systems Directive (NIS2) approaches, companies across the EU need to... - [Vorbereitungen für die nationale Umsetzungsfrist der NIS2-Richtlinie](https://bitsea.de/blog/2024/08/devorbereitungen-fuer-die-nationale-umsetzungsfrist-der-nis2-richtlinie/): Da die Umsetzungsfrist für die überarbeitete Richtlinie über Netz- und Informationssysteme (NIS2) näher rückt, müssen Unternehmen in der gesamten EU... - [Bisquat2: What is hiding there?](https://bitsea.de/blog/2024/07/bisquat2-what-is-hiding-there/): Today, we are shedding light on a topic that is still all too readily overlooked as the “little sister of... - [Bisquat2: What is hiding there?](https://bitsea.de/blog/2024/07/bisquat2-was-versteckt-sich-denn-da/): Today, we are shedding light on a topic that is still all too readily overlooked as the „little sister of... - [Bisquat2: Was versteckt sich denn da?](https://bitsea.de/blog/2024/07/bisquat2-was-versteckt-sich-denn-da/): Heute beleuchten wir ein Thema, das nach wie vor als „kleine Schwester des Programmierens“ nur zu gerne unter den Tisch... - [The Cyber Resilience Act (CRA) and the Management of Open Source](https://bitsea.de/blog/2024/07/der-cyber-resilience-act-cra-und-das-management-von-open-source/): Open source is everywhere: Hardly any product today can do without digital components, from electric toothbrushes and baby monitors to... ## Webinare - [Awards Ceremony Ludwig 2026](https://en.bitsea.de/blog/webinar/awards-ceremony-ludwig-2026/) - [Preisverleihung Ludwig 2026](https://bitsea.de/blog/webinar/preisverleihung-ludwig-2026/) - [Prioritizing Supply Chain Risk in Time-Bound M&A Reviews – Prashanth Chandrasekar](https://en.bitsea.de/blog/webinar/prioritizing-supply-chain-risk-in-time-bound-ma-reviews-prashanth-chandrasekar/) - [Webinar: From SBOMs to Decisions: Prioritizing Supply Chain Risk in Time-Bound M&A Reviews – Prashanth Chandrasekar (English)](https://bitsea.de/blog/webinar/webinar-from-sboms-to-decisions-prioritizing-supply-chain-risk-in-time-bound-ma-reviews-prashanth-chandrasekar/) - [From SBOMs to Decisions: Prioritizing Supply Chain Risk in Time-Bound M&A Reviews - Prashanth Chandrasekar](https://bitsea.us/blog/webinar/from-sboms-to-decisions-prioritizing-supply-chain-risk-in-time-bound-ma-reviews-prashanth-chandrasekar/) - [Webinar: SBOM or Bust: Automating Compliance for EU CRA & Beyond (Englisch)](https://bitsea.de/blog/webinar/webinar-sbom-or-bust-automating-compliance-for-eu-cra-beyond-englisch/) - [Webinar: SBOM or Bust: Automating Compliance for EU CRA & Beyond](https://bitsea.us/blog/webinar/webinar-sbom-or-bust-automating-compliance-for-eu-cra-beyond/) - [SBOM or Bust: Automating Compliance for EU CRA & Beyond](https://en.bitsea.de/blog/webinar/sbom-or-bust-automating-compliance-for-eu-cra-beyond/) - [CRA-Compliance in der Praxis: Offene Tools helfen KMU, Software-Lieferketten abzusichern](https://bitsea.de/blog/webinar/cra-compliance-in-der-praxis-offene-tools-helfen-kmu-software-lieferketten-abzusichern/) - [Webinar: Überblick über die Rechtslage – SBOM- und OSS-Compliance in den USA, Indien und Europa (Englisch)](https://bitsea.de/blog/webinar/webinar-ueberblick-ueber-die-rechtslage-sbom-und-oss-compliance-in-den-usa-indien-und-europa-englisch/) - [Webinar: Regulation Roundup - Navigating SBOM and OSS Compliance Acoss the US, India and Europe](https://en.bitsea.de/blog/webinar/webinar-regulation-roundup-navigating-sbom-and-oss-compliance-acoss-the-us-india-and-europe/) - [Webinar: Regulation Roundup - Navigating SBOM and OSS Compliance Acoss the US, India and Europe](https://bitsea.us/blog/webinar/webinar-regulation-roundup-navigating-sbom-and-oss-compliance-acoss-the-us-india-and-europe/) - [AI-Generated Code: Legal Risks and How to Reduce Them](https://bitsea.us/blog/webinar/ai-generated-code-legal-risks-and-how-to-reduce-them/) - [KI-generierter Code: Legale Risiken und wie man sie minimiert](https://bitsea.de/blog/webinar/11338/) - [AI-Generated Code: Legal Risks and How to Reduce Them](https://en.bitsea.de/blog/webinar/ai-generated-code-legal-risks-and-how-to-reduce-them/) - [Webinar: Eclipse Foundation Webinar: Anyone who still puts AI-generated code into circulation today has conditional intent to infringe the law – how to limit or at least defer the risk](https://en.bitsea.de/blog/webinar/webinar-eclipse-foundation-webinar-anyone-who-still-puts-ai-generated-code-into-circulation-today-has-conditional-intent-to-infringe-the-law-how-to-limit-or-at-least-defer-the-risk/) - [Eclipse Foundation Webinar: Anyone who still puts AI-generated code into circulation today has conditional intent to infringe the law - how to limit or at least defer the risk](https://bitsea.de/blog/webinar/eclipse-foundation-webinar-anyone-who-still-puts-ai-generated-code-into-circulation-today-has-conditional-intent-to-infringe-the-law-how-to-limit-or-at-least-defer-the-risk/) - [Podcast: AI-Generated Code: Legal Risks and How to Reduce Them](https://en.bitsea.de/blog/webinar/podcast-ai-generated-code-legal-risks-and-how-to-reduce-them/) - [Podcast: AI-Generated Code: Legal Risks and How to Reduce Them (Englisch)](https://bitsea.de/blog/webinar/podcast-ai-generated-code-legal-risks-and-how-to-reduce-them-englisch/) - [OpenChain: A Panel on Generative AI Risks and Management](https://en.bitsea.de/blog/webinar/openchain-webinar-a-panel-on-generative-ai-risks-and-management/) - [OpenChain Webinar: A Panel on Generative AI Risks and Management](https://bitsea.us/blog/webinar/openchain-webinar-a-panel-on-generative-ai-risks-and-management/) - [Eine Diskussionsrunde zu den Risiken und dem Management generativer KI](https://bitsea.de/blog/webinar/eine-diskussionsrunde-zu-den-risiken-und-dem-management-generativer-ki/) - [BFOSS25: Lizenzverletzungen bei KI generierten Code](https://bitsea.de/blog/webinar/bfoss25-lizenzverletzungen-bei-ki-generierten-code/) - [Modern Open Source Risk Management – What You Should Be Doing Now](https://bitsea.us/blog/webinar/modern-open-source-risk-management-what-you-should-be-doing-now/) - [Modern Open Source Risk Management – What You Should Be Doing Now](https://en.bitsea.de/blog/webinar/modern-open-source-risk-management-what-you-should-be-doing-now/) - [Modern Open Source Risk Management – Was Sie jetzt tun sollten](https://bitsea.de/blog/webinar/modern-open-source-risk-management-what-you-should-be-doing-now/) - [OpenChain Webinar Project OCCTET EU the Why, What and How](https://bitsea.us/blog/webinar/openchain-webinar-project-occtet-eu-the-why-what-and-how/) - [OpenChain Webinar Project OCCTET EU the Why, What and How](https://en.bitsea.de/blog/webinar/openchain-webinar-project-occtet-eu-the-why-what-and-how/) - [OpenChain Webinar Project OCCTET EU the Why, What and How](https://bitsea.de/blog/webinar/openchain-webinar-project-occtet-eu-the-why-what-and-how/) - [The Supply Chain Risk you Can't Ignore: A Playbook for Critical Industries](https://bitsea.de/blog/webinar/das-supply-chain-risiko-dass-sie-nicht-ignorieren-duerfen/) - [The Supply Chain Risk you Can't Ignore: A Playbook for Critical Industries](https://bitsea.de/blog/webinar/das-supply-chain-risiko-dass-sie-nicht-ignorieren-duerfen/): Discover how companies in critical industries successfully manage OS risks and challenges in the software supply chain. - [Das Supply Chain Risiko, dass Sie nicht ignorieren dürfen: Ein Leitfaden für kritische Branchen](https://bitsea.de/blog/webinar/das-supply-chain-risiko-dass-sie-nicht-ignorieren-duerfen/): Erfahre wie Firmen in kritischen Branchen OS-Risiken und Herausforderungen in der Software-Supply-Chain erfolgreich bewältigen. - [SBOM Visualization – An Alternative Approach to Reviewing SBOMs](https://bitsea.us/blog/webinar/webinar-sbom-visualization-an-alternative-approach-to-reviewing-sboms/) - [Mitigating Risks in Open Source and Software Supply Chains: A Global Outlook](https://bitsea.de/blog/webinar/risikominderung-in-open-source-und-software-lieferketten-ein-globaler-ausblick/) - [Mitigating Risks in Open Source and Software Supply Chains: A Global Outlook](https://bitsea.de/blog/webinar/risikominderung-in-open-source-und-software-lieferketten-ein-globaler-ausblick/) - [Risikominderung in Open-Source- und Software-Lieferketten: Ein globaler Ausblick](https://bitsea.de/blog/webinar/risikominderung-in-open-source-und-software-lieferketten-ein-globaler-ausblick/) - [SBOM Visualisierung – Ein alternativer Ansatz zur Überprüfung von SBOMs](https://bitsea.de/blog/webinar/webinar-sbom-visualization-an-alternative-approach-to-reviewing-sboms/) - [SBOM Visualization – An Alternative Approach to Reviewing SBOMs](https://en.bitsea.de/blog/webinar/webinar-sbom-visualization-an-alternative-approach-to-reviewing-sboms/) - [OpenChain Webinar 2021](https://bitsea.de/blog/webinar/openchain-webinar-2021/) - [Open Source Exchange](https://bitsea.de/blog/webinar/open-source-exchange/) - [OpenChain M&A Summit 2022](https://bitsea.de/blog/webinar/openchain-ma-summit-2022/) - [AlarmRedux](https://bitsea.de/blog/webinar/alarmredux/) - [Webinar: Hidden risks in software systems](https://bitsea.de/blog/webinar/verborgene-risiken-in-softwaresystemen/) - [Trends in the Use and Security Testing of Open Source Software](https://bitsea.de/blog/webinar/trends-in-der-nutzung-und-security-testing-von-open-source-software/) - [Getting Real About the License Complexity of Linux](https://bitsea.de/blog/webinar/getting-real-about-the-license-complexity-of-linux/) - [OpenChain Webinar 2021](https://bitsea.de/blog/webinar/openchain-webinar-2021/) - [Compliance & Sicherheit in der Open Source Welt](https://bitsea.de/blog/webinar/compliance-sicherheit-in-der-open-source-welt/) - [Open Source Exchange](https://bitsea.de/blog/webinar/open-source-exchange/) - [OpenChain M&A Summit 2022](https://bitsea.de/blog/webinar/openchain-ma-summit-2022/) - [OpenChain Partner Webinar #5 Bitsea](https://bitsea.de/blog/webinar/openchain-partner-webinar-5-bitsea/) - [Info event Open Source Software on 14th April 2023](https://bitsea.de/blog/webinar/infoveranstaltung-open-source-software-vom-14-04-2023/) - [Infoveranstaltung Open Source Software vom 14.04.2023](https://bitsea.de/blog/webinar/infoveranstaltung-open-source-software-vom-14-04-2023/) - [OpenChain Partner Webinar #5 Bitsea](https://bitsea.de/blog/webinar/openchain-partner-webinar-5-bitsea/) - [OpenChain M&A Summit 2022](https://bitsea.de/blog/webinar/openchain-ma-summit-2022/) - [Open Source Exchange](https://bitsea.de/blog/webinar/open-source-exchange/) - [Compliance & Sicherheit in der Open Source Welt](https://bitsea.de/blog/webinar/compliance-sicherheit-in-der-open-source-welt/) - [OpenChain Webinar 2021](https://bitsea.de/blog/webinar/openchain-webinar-2021/) - [Getting Real About the License Complexity of Linux](https://bitsea.de/blog/webinar/getting-real-about-the-license-complexity-of-linux/) - [Trends in der Nutzung und Security Testing von Open Source Software](https://bitsea.de/blog/webinar/trends-in-der-nutzung-und-security-testing-von-open-source-software/) - [Verborgene Risiken in Softwaresystemen](https://bitsea.de/blog/webinar/verborgene-risiken-in-softwaresystemen/) - [AlarmRedux](https://bitsea.de/blog/webinar/alarmredux/) - [Open Source Central: Was Sie Aktuell Über Open Source Security Wissen Sollten](https://bitsea.de/blog/webinar/open-source-central-was-sie-aktuell-ueber-open-source-security-wissen-sollten/) - [Kemp Little & Bitsea Webinar | Open Source Software](https://bitsea.de/blog/webinar/kemp-little-bitsea-webinar-open-source-software/) - [Kemp Little & Bitsea Webinar | Open Source Software](https://bitsea.de/blog/webinar/kemp-little-bitsea-webinar-open-source-software/) - [Open Source Central: Was Sie Aktuell Über Open Source Security Wissen Sollten](https://bitsea.de/blog/webinar/open-source-central-was-sie-aktuell-ueber-open-source-security-wissen-sollten/) ## Events - [Webinar: "Get Ready for the CRA: From Obligation to Opportunity – Your Roadmap to Compliance"](https://en.bitsea.de/blog/events/12248/) - [Webinar: "Fit für den CRA: Von der Pflicht zur Chance – Ihr Fahrplan zur Umsetzung"](https://bitsea.de/blog/events/webinar-fit-fuer-den-cra-von-der-pflicht-zur-chance-ihr-fahrplan-zur-umsetzung/) - [Informationsveranstaltung: EU Cyber Resilience Act](https://bitsea.de/blog/events/informationsveranstaltung-eu-cyber-resilience-act/) - [Webinar: SBOMs or Bust: Automating Compliance for EU CRA & Beyond](https://en.bitsea.de/blog/events/webinar-sboms-or-bust-automating-compliance-for-eu-cra-beyond/) - [Webinar: SBOMs or Bust: Automating Compliance for EU CRA & Beyond](https://bitsea.us/blog/events/11481/) - [Webinar: SBOMs or Bust: Automating Compliance for EU CRA & Beyond](https://bitsea.de/blog/events/webinar-sboms-or-bust-automating-compliance-for-eu-cra-beyond/) - [Bay Area OWASP Treffen](https://bitsea.de/blog/events/bay-area-owasp-treffen/) - [April Bay Area OWASP meetup](https://bitsea.us/blog/events/april-bay-area-owasp-meetup/) - [NKCS Thematic Workshop: “Opportunities and Challenges of Open Source in Cybersecurity”](https://en.bitsea.de/blog/events/nkcs-thematic-workshop-opportunities-and-challenges-of-open-source-in-cybersecurity/) - [NKCS Themenworkshop "Chancen und Herausforderungen von Open Source in der Cybersicherheit"](https://bitsea.de/blog/events/nkcs-themenworkshop-chancen-und-herausforderungen-von-open-source-in-der-cybersicherheit/) - [Cyber Resilience Act Summit 2026](https://en.bitsea.de/blog/events/cyber-resilience-act-summit-2026/) - [Cyber Resilience Act Summit 2026](https://bitsea.de/blog/events/cyber-resilience-act-summit-2026/) - [BSI 21st IT Security Congress](https://en.bitsea.de/blog/events/bsi-21st-it-security-congress/) - [BSI 21. IT Sicherheitskongress](https://bitsea.de/blog/events/bsi-21-it-sicherheitskongress/) - [ASW West 58th General Assembly](https://en.bitsea.de/blog/events/asw-west-58th-general-assembly/) - [ASW West 58. Mitgliederversammlung](https://bitsea.de/blog/events/asw-west-58-mitgliederversammlung/) - [OpenSSF Community Day North America 2026](https://bitsea.us/blog/events/openssf-community-day-north-america-2026/) - [RSAC Conference 2026](https://bitsea.us/blog/events/rsac-conference-2026/) - [Wiesbadener Sicherheitsseminar „Innere Sicherheit“](https://bitsea.de/blog/events/wiesbadener-sicherheitsseminar-innere-sicherheit/) - [Forum Open Source 2026](https://en.bitsea.de/blog/events/forum-open-source-2026/) - [Forum Open Source 2026](https://bitsea.de/blog/events/forum-open-source-2026/) - [Internationale Zuliefererbörse](https://en.bitsea.de/blog/events/internationale-zuliefererborse/) - [Internationale Zuliefererbörse](https://bitsea.de/blog/events/internationale-zuliefererboerse/) - [OpenChain and Friends](https://en.bitsea.de/blog/events/openchain-and-friends/) - [OpenChain and Friends](https://bitsea.de/blog/events/openchain-and-friends/) - [betterCode() GenAI Summit 26](https://en.bitsea.de/blog/events/bettercode-genai-summit-26/) - [betterCode() GenAI Summit 2026](https://bitsea.de/blog/events/bettercode-genai-summit-2026/) - [Webinar: Anyone who still puts AI-generated code into circulation today has conditional intent to infringe the law – how to limit or at least defer the risk](https://en.bitsea.de/blog/events/webinar-anyone-who-still-puts-ai-generated-code-into-circulation-today-has-conditional-intent-to-infringe-the-law-how-to-limit-or-at-least-defer-the-risk/) - [Webinar: Wer heute noch KI-generierten Code in Umlauf bringt, hat die bedingte Absicht, gegen das Gesetz zu verstoßen – wie lässt sich das Risiko begrenzen oder zumindest aufschieben?](https://bitsea.de/blog/events/webinar-wer-heute-noch-ki-generierten-code-in-umlauf-bringt-hat-die-bedingte-absicht-gegen-das-gesetz-zu-verstossen-wie-laesst-sich-das-risiko-begrenzen-oder-zumindest-aufschieben/) - [Revenera Webinar: Regulations Roundup: Navigating SBOM and OSS Compliance Across the US, India, and Europe](https://bitsea.us/blog/events/revenera-webinar-regulations-round-up/) - [BVMW Business Breakfast](https://en.bitsea.de/blog/events/bvmw-business-breakfast/) - [Revenera Webinar: Regulations Roundup: Navigating SBOM and OSS Compliance Across the US, India, and Europe](https://en.bitsea.de/blog/events/revenera-webinar-regulations-round-up/) - [BVMW Business Breakfast](https://bitsea.de/blog/events/bvmw-business-breakfast/) - [Revenera Webinar "Regulations Round-Up: Zusammenfassung der Vorschriften von SBOM- und OSS-Compliance in den USA, Indien und Europa"](https://bitsea.de/blog/events/revenera-webinar-regulations-round-up/) - [Cybersecurity Summit 2026](https://bitsea.de/blog/events/cybersecurity-summit-2026/) - [Cybersecurity Summit 2026](https://en.bitsea.de/blog/events/cybersecurity-summit-2026/) - [FOSS Backstage 2026](https://en.bitsea.de/blog/events/foss-backstage-2026/) - [FOSS Backstage 2026](https://bitsea.de/blog/events/foss-backstage-2026/) - [Tec.Meet.Ing](https://en.bitsea.de/blog/events/tec-meet-ing/) - [Tec.Meet.Ing](https://bitsea.de/blog/events/tec-meet-ing/) - [FSFE Free Software Legal and Licensing Workshop (LLW)](https://en.bitsea.de/blog/events/fsfe-free-software-legal-and-licensing-workshop-llw/) - [FSFE Free Software Legal and Licensing Workshop (LLW)](https://bitsea.de/blog/events/fsfe-free-software-legal-and-licensing-workshop-llw/) - [FOSDEM 2025](https://en.bitsea.de/blog/events/bonn-rhein-sieg-university-of-applied-sciences-company-day/) - [FOSDEM 2026](https://bitsea.de/blog/events/unternehmenstag-hochschule-bonn-rhein-sieg/) ## Jobs # # Detailed Content ## Seiten Produkte - Bitsea Über unsDienstleistungenProdukteRessourcenKontaktJob & KarriereCurator Pro CURATOR PRO TRANSPARENZ FÜR IHRE SOFTWARE-LIEFERKETTE. Schwachstellen erkennen Kontinuierliche Analyse bekannter CVEs CRA Compliance Auditierbare Nachweise & Reports KI-Assistent Vorschläge zur Risikobehinderung SBOM Governance Transparenz über Zulieferketten Automatische Alerts Sofort informiert bei neuen Risiken Priorisierung Fokus auf relevante Schwachstellen What we deliver From baseline product audits to transaction-driven reviews, Bitsea helps organizations identify open source, track obligations, understand vulnerabilities, and build a transparent software bill of materials. M&A The buy and sell-side of technical due-diligence Comprehensive SBOM Create complete and accurate SBOMs in any format Baseline Audit Continuous code scanning to strengthen security and support compliance Vulnerabilities Remediation, supply-chain security, continuous monitoring Situation Die Bedrohungslage im Bereich Cybersecurity hat sich in den vergangenen Jahren dramatisch verschärft. Angriffe auf Software-Lieferketten, Schwachstellen in Open-Source-Komponenten und kompromittierte Abhängigkeiten gehören heute zu den größten Risiken für Unternehmen und Betreiber kritischer Infrastrukturen. Gleichzeitig steigt die Komplexität moderner Softwaresysteme kontinuierlich: Produkte bestehen aus tausenden Komponenten, deren Herkunft, Sicherheitsstatus und regulatorische Auswirkungen oft nur schwer nachvollziehbar sind. Als direkte Reaktion darauf verschärfen Staaten und Regulierungsbehörden weltweit die Anforderungen an Cybersicherheit und Transparenz. Mit Vorgaben wie dem Cyber Resilience Act (CRA) CRA (Cyber Resilience Act)Der Cyber Resilience Act ist eine EU-Verordnung für Produkte mit digitalen Elementen, also insbesondere Software, vernetzte Geräte und digitale Komponenten. Ziel ist es, Cybersecurity bereits bei Entwicklung, Bereitstellung und Wartung solcher Produkte verbindlich zu berücksichtigen. Hersteller müssen unter anderem Sicherheitsrisiken bewerten, Schwachstellen behandeln und für mehr Transparenz entlang der Software-Lieferkette sorgen. Die wichtigsten Pflichten gelten ab dem 11. Dezember 2027; Meldepflichten greifen bereits ab dem 11. September 2026. , NIS2 oder DORA verpflichtet die Europäische Union Unternehmen dazu, Sicherheitsrisiken systematisch zu identifizieren, Schwachstellen kontinuierlich zu überwachen und Compliance nachvollziehbar zu dokumentieren. Gleichzeitig steigt die Komplexität moderner Softwaresysteme kontinuierlich: Produkte bestehen aus tausenden Komponenten, deren Herkunft, Sicherheitsstatus und regulatorische Auswirkungen oft nur schwer nachvollziehbar sind. Als direkte Reaktion darauf verschärfen Staaten und Regulierungsbehörden weltweit die Anforderungen an Cybersicherheit und Transparenz. Mit Vorgaben wie dem Cyber Resilience Act (CRA) CRA (Cyber Resilience Act)Der Cyber Resilience Act ist eine EU-Verordnung für Produkte mit digitalen Elementen, also insbesondere Software, vernetzte Geräte und digitale Komponenten. Ziel ist es, Cybersecurity bereits bei Entwicklung, Bereitstellung und Wartung solcher Produkte verbindlich zu berücksichtigen. Hersteller müssen unter anderem Sicherheitsrisiken bewerten, Schwachstellen behandeln und für mehr Transparenz entlang der Software-Lieferkette sorgen. Die wichtigsten Pflichten gelten ab dem 11. Dezember 2027; Meldepflichten greifen bereits ab dem 11. September 2026. , NIS2 oder DORA verpflichtet die Europäische Union Unternehmen dazu, Sicherheitsrisiken systematisch zu identifizieren, Schwachstellen kontinuierlich zu überwachen und Compliance nachvollziehbar zu dokumentieren. Gleichzeitig steigt die Komplexität moderner Softwaresysteme kontinuierlich: Produkte bestehen aus tausenden Komponenten, deren Herkunft, Sicherheitsstatus und regulatorische Auswirkungen oft nur schwer nachvollziehbar sind. Als direkte Reaktion darauf verschärfen Staaten und Regulierungsbehörden weltweit die Anforderungen an Cybersicherheit und Transparenz. Mit Vorgaben wie dem Cyber Resilience Act (CRA) CRA (Cyber Resilience Act)Der Cyber Resilience Act ist eine EU-Verordnung für Produkte mit digitalen Elementen, also insbesondere Software, vernetzte Geräte und digitale Komponenten. Ziel ist es, Cybersecurity bereits bei... Curator Pro - Bitsea Über unsDienstleistungenProdukteRessourcenKontaktJob & KarriereCurator Pro CURATOR PRO TRANSPARENZ FÜR IHRE SOFTWARE-LIEFERKETTE. Schwachstellen erkennen Kontinuierliche Analyse bekannter CVEs CRA Compliance Auditierbare Nachweise & Reports KI-Assistent Vorschläge zur Risikobehinderung SBOM Governance Transparenz über Zulieferketten Automatische Alerts Sofort informiert bei neuen Risiken Priorisierung Fokus auf relevante Schwachstellen What we deliver From baseline product audits to transaction-driven reviews, Bitsea helps organizations identify open source, track obligations, understand vulnerabilities, and build a transparent software bill of materials. M&A The buy and sell-side of technical due-diligence Comprehensive SBOM Create complete and accurate SBOMs in any format Baseline Audit Continuous code scanning to strengthen security and support compliance Vulnerabilities Remediation, supply-chain security, continuous monitoring Situation Die Bedrohungslage im Bereich Cybersecurity hat sich in den vergangenen Jahren dramatisch verschärft. Angriffe auf Software-Lieferketten, Schwachstellen in Open-Source-Komponenten und kompromittierte Abhängigkeiten gehören heute zu den größten Risiken für Unternehmen und Betreiber kritischer Infrastrukturen. Gleichzeitig steigt die Komplexität moderner Softwaresysteme kontinuierlich: Produkte bestehen aus tausenden Komponenten, deren Herkunft, Sicherheitsstatus und regulatorische Auswirkungen oft nur schwer nachvollziehbar sind. Als direkte Reaktion darauf verschärfen Staaten und Regulierungsbehörden weltweit die Anforderungen an Cybersicherheit und Transparenz. Mit Vorgaben wie dem Cyber Resilience Act (CRA) CRA (Cyber Resilience Act)Der Cyber Resilience Act ist eine EU-Verordnung für Produkte mit digitalen Elementen, also insbesondere Software, vernetzte Geräte und digitale Komponenten. Ziel ist es, Cybersecurity bereits bei Entwicklung, Bereitstellung und Wartung solcher Produkte verbindlich zu berücksichtigen. Hersteller müssen unter anderem Sicherheitsrisiken bewerten, Schwachstellen behandeln und für mehr Transparenz entlang der Software-Lieferkette sorgen. Die wichtigsten Pflichten gelten ab dem 11. Dezember 2027; Meldepflichten greifen bereits ab dem 11. September 2026. , NIS2 oder DORA verpflichtet die Europäische Union Unternehmen dazu, Sicherheitsrisiken systematisch zu identifizieren, Schwachstellen kontinuierlich zu überwachen und Compliance nachvollziehbar zu dokumentieren. Gleichzeitig steigt die Komplexität moderner Softwaresysteme kontinuierlich: Produkte bestehen aus tausenden Komponenten, deren Herkunft, Sicherheitsstatus und regulatorische Auswirkungen oft nur schwer nachvollziehbar sind. Als direkte Reaktion darauf verschärfen Staaten und Regulierungsbehörden weltweit die Anforderungen an Cybersicherheit und Transparenz. Mit Vorgaben wie dem Cyber Resilience Act (CRA) CRA (Cyber Resilience Act)Der Cyber Resilience Act ist eine EU-Verordnung für Produkte mit digitalen Elementen, also insbesondere Software, vernetzte Geräte und digitale Komponenten. Ziel ist es, Cybersecurity bereits bei Entwicklung, Bereitstellung und Wartung solcher Produkte verbindlich zu berücksichtigen. Hersteller müssen unter anderem Sicherheitsrisiken bewerten, Schwachstellen behandeln und für mehr Transparenz entlang der Software-Lieferkette sorgen. Die wichtigsten Pflichten gelten ab dem 11. Dezember 2027; Meldepflichten greifen bereits ab dem 11. September 2026. , NIS2 oder DORA verpflichtet die Europäische Union Unternehmen dazu, Sicherheitsrisiken systematisch zu identifizieren, Schwachstellen kontinuierlich zu überwachen und Compliance nachvollziehbar zu dokumentieren. Gleichzeitig steigt die Komplexität moderner Softwaresysteme kontinuierlich: Produkte bestehen aus tausenden Komponenten, deren Herkunft, Sicherheitsstatus und regulatorische Auswirkungen oft nur schwer nachvollziehbar sind. Als direkte Reaktion darauf verschärfen Staaten und Regulierungsbehörden weltweit die Anforderungen an Cybersicherheit und Transparenz. Mit Vorgaben wie dem Cyber Resilience Act (CRA) CRA (Cyber Resilience Act)Der Cyber Resilience Act ist eine EU-Verordnung für Produkte mit digitalen Elementen, also insbesondere Software, vernetzte Geräte und digitale Komponenten. Ziel ist es, Cybersecurity bereits... Curator Pro - Bitsea Über unsDienstleistungenProdukteRessourcenKontaktJob & KarriereCurator Pro CURATOR PRO TRANSPARENZ FÜR IHRE SOFTWARE-LIEFERKETTE. Schwachstellen erkennen Kontinuierliche Analyse bekannter CVEs CRA Compliance Auditierbare Nachweise & Reports KI-Assistent Vorschläge zur Risikobehinderung SBOM Governance Transparenz über Zulieferketten Automatische Alerts Sofort informiert bei neuen Risiken Priorisierung Fokus auf relevante Schwachstellen What we deliver From baseline product audits to transaction-driven reviews, Bitsea helps organizations identify open source, track obligations, understand vulnerabilities, and build a transparent software bill of materials. M&A The buy and sell-side of technical due-diligence Comprehensive SBOM Create complete and accurate SBOMs in any format Baseline Audit Continuous code scanning to strengthen security and support compliance Vulnerabilities Remediation, supply-chain security, continuous monitoring Situation Die Bedrohungslage im Bereich Cybersecurity hat sich in den vergangenen Jahren dramatisch verschärft. Angriffe auf Software-Lieferketten, Schwachstellen in Open-Source-Komponenten und kompromittierte Abhängigkeiten gehören heute zu den größten Risiken für Unternehmen und Betreiber kritischer Infrastrukturen. Gleichzeitig steigt die Komplexität moderner Softwaresysteme kontinuierlich: Produkte bestehen aus tausenden Komponenten, deren Herkunft, Sicherheitsstatus und regulatorische Auswirkungen oft nur schwer nachvollziehbar sind. Als direkte Reaktion darauf verschärfen Staaten und Regulierungsbehörden weltweit die Anforderungen an Cybersicherheit und Transparenz. Mit Vorgaben wie dem Cyber Resilience Act (CRA) CRA (Cyber Resilience Act)Der Cyber Resilience Act ist eine EU-Verordnung für Produkte mit digitalen Elementen, also insbesondere Software, vernetzte Geräte und digitale Komponenten. Ziel ist es, Cybersecurity bereits bei Entwicklung, Bereitstellung und Wartung solcher Produkte verbindlich zu berücksichtigen. Hersteller müssen unter anderem Sicherheitsrisiken bewerten, Schwachstellen behandeln und für mehr Transparenz entlang der Software-Lieferkette sorgen. Die wichtigsten Pflichten gelten ab dem 11. Dezember 2027; Meldepflichten greifen bereits ab dem 11. September 2026. , NIS2 oder DORA verpflichtet die Europäische Union Unternehmen dazu, Sicherheitsrisiken systematisch zu identifizieren, Schwachstellen kontinuierlich zu überwachen und Compliance nachvollziehbar zu dokumentieren. Gleichzeitig steigt die Komplexität moderner Softwaresysteme kontinuierlich: Produkte bestehen aus tausenden Komponenten, deren Herkunft, Sicherheitsstatus und regulatorische Auswirkungen oft nur schwer nachvollziehbar sind. Als direkte Reaktion darauf verschärfen Staaten und Regulierungsbehörden weltweit die Anforderungen an Cybersicherheit und Transparenz. Mit Vorgaben wie dem Cyber Resilience Act (CRA) CRA (Cyber Resilience Act)Der Cyber Resilience Act ist eine EU-Verordnung für Produkte mit digitalen Elementen, also insbesondere Software, vernetzte Geräte und digitale Komponenten. Ziel ist es, Cybersecurity bereits bei Entwicklung, Bereitstellung und Wartung solcher Produkte verbindlich zu berücksichtigen. Hersteller müssen unter anderem Sicherheitsrisiken bewerten, Schwachstellen behandeln und für mehr Transparenz entlang der Software-Lieferkette sorgen. Die wichtigsten Pflichten gelten ab dem 11. Dezember 2027; Meldepflichten greifen bereits ab dem 11. September 2026. , NIS2 oder DORA verpflichtet die Europäische Union Unternehmen dazu, Sicherheitsrisiken systematisch zu identifizieren, Schwachstellen kontinuierlich zu überwachen und Compliance nachvollziehbar zu dokumentieren. Gleichzeitig steigt die Komplexität moderner Softwaresysteme kontinuierlich: Produkte bestehen aus tausenden Komponenten, deren Herkunft, Sicherheitsstatus und regulatorische Auswirkungen oft nur schwer nachvollziehbar sind. Als direkte Reaktion darauf verschärfen Staaten und Regulierungsbehörden weltweit die Anforderungen an Cybersicherheit und Transparenz. Mit Vorgaben wie dem Cyber Resilience Act (CRA) CRA (Cyber Resilience Act)Der Cyber Resilience Act ist eine EU-Verordnung für Produkte mit digitalen Elementen, also insbesondere Software, vernetzte Geräte und digitale Komponenten. Ziel ist es, Cybersecurity bereits... CRA Guardian (English) - Bitsea About usServicesProductsResourcesContactCareerCRA GuardianOpen Source ManagementSoftware Quality Analysis Services CRA GUARDIAN OUR CYBER RESILIENCE ACT COMPLIANCE READINESS SUITE CRA GUARDIAN Unsere Cyber Resilience Act Compliance Readiness Suite Situation The Cyber Resilience Act (CRA) will fundamentally change the security requirements for manufacturers and suppliers of digital products in the EU. Our CRA Readiness Assessment helps you identify at an early stage whether and to what extent your company is affected and what measures are necessary to comply with the legal requirements. The CRA applies to almost all products with digital elements that are offered on the European market. It distinguishes between different risk classes, which determine the type of conformity procedure required—only a few product categories are exempt. In addition, it is crucial to understand your role in the market: the CRA primarily holds manufacturers accountable, but also places demands on distributors and importers. Only those who clearly define their role can take the appropriate actions: BITSEA CRA GUARDIAN   OUR HOLISTIC APPROACH TO COMPLIANCE Scope Determination of the scope, affected products, and roles. Governance Establish structured governance with clear responsibilities, guidelines, and controls. Risk Management Comprehensive risk management throughout the entire lifecycle—from initial assessment to active vulnerability management. Reporting Obligations & Compliance Ensure transparent incident and vulnerability reporting with complete documentation and evidence. Supply Chain (Supply Chain Security) Make supply chains more transparent with SBOM/VEX, manage third-party risks, and ensure compliance across all suppliers. CRA Quickcheck Are your products affected? Scope Determination of the scope, affected products, and roles. Governance Establish structured governance with clear responsibilities, guidelines, and controls. Risk Management Comprehensive risk management throughout the entire lifecycle—from initial assessment to active vulnerability management. Reporting obligations & compliance Ensure transparent incident and vulnerability reporting with complete documentation and evidence. Supply chain (Supply Chain Security) Make supply chains more transparent with SBOM/VEX, manage third-party risks, and ensure compliance across all suppliers. CRA Quickcheck Are your products affected? IHR WEG ZUR CRA-COMPLIANCE IN 5 EINFACHEN PHASEN YOUR PATH TO CRA COMPLIANCE IN 5 SIMPLE STEPS Phases 1 Assess the Applicability and Classify the Product Impact assessment, role clarification, risk classification, and gap analysis. 2 Implement Technical and Procedural Foundations Risk analysis, security-by-design, policies and KPIs, strategy and governance, testing and release processes, and defined responsibilities. 3 Process Establishment Defining processes, meeting reporting obligations (ENISA), managing timelines and notifications, supplier governance, adapting SLAs, and SBOM management. 4 Demonstrate of Compliance Documentation, assessments, guidance materials, training, and role-based competency development. 5 Finalise Compliance Declaration of conformity, CE marking, market surveillance readiness, and continuous improvement. 1 Assess the Applicability and Classify the Product Impact assessment, role clarification, risk classification, and gap analysis. 2 Implement Technical and Procedural Foundations Risk analysis, security-by-design, policies and KPIs, strategy and governance, testing and release processes, and defined responsibilities. 3 Process Establishment Defining processes, meeting reporting obligations (ENISA), managing timelines and notifications, supplier governance, adapting SLAs, and SBOM management. 4 Demonstrate of Compliance Documentation, assessments, guidance materials, training, and role-based competency development. 5 Finalise Compliance Declaration... CRA Guardian - Bitsea Über unsDienstleistungenRessourcenKontaktJob & KarriereCRA GuardianOpen-Source-ManagementSoftware Qualitätsanalyse Dienstleistungen CRA GUARDIAN UNSERE CYBER RESILIENCE ACT COMPLIANCE READINESS SUITE CRA GUARDIAN Unsere Cyber Resilience Act Compliance Readiness Suite Situation Der CRA wird die Sicherheitsanforderungen an Hersteller und Anbieter digitaler Produkte in der EUgrundlegend verändern. Unser CRA-Readiness Assessment hilft Ihnen, frühzeitig zu erkennen, ob und in welchem UmfangIhr Unternehmen betroffen ist, und welche Maßnahmen erforderlich sind, um die gesetzlichen Vorgaben zu erfüllen. Der CRA gilt für nahezu alle Produkte mit digitalen Elementen, die auf dem europäischen Markt angeboten werden. Er unterscheidet dabei zwischen verschiedenen Risikoklassen, von denen die Art des erforderlichen Konformitätsverfahrens abhängt – nur wenige Produktkategorien sind ausgenommen. Darüber hinaus ist es entscheidend, Ihre Rolle im Markt zu kennen: Der CRA zieht in erster Linie Hersteller zur Verantwortung, stellt jedoch auch Anforderungen an Händler und Importeure. Nur wer seine Rolle klar definiert, kann die entsprechenden Maßnahmen ergreifen: BITSEA CRA GUARDIAN   UNSER GANZHEITLICHER COMPLIANCE ANSATZ Scope Feststellung vom Geltungsbereich, betroffenen Produkten und Rollen - für einen eindeutig abgegrenzten CRA-Scope. Governance Strukturierte Governance mit klaren Verantwortlichkeiten, Richtlinien und Kontrollen etablieren. Risikomanagement Umfassendes Risikomanagement über den gesamten Lebenszyklus - von der initialen Bewertung bis zum aktiven Schwachstellenmanagement. Berichtspflichten & Compliance Transparente Vorfall- und Schwachstellenmeldungen mit vollständiger Dokumentation und Nachweisen sicherstellen. Lieferkette (Supply Chain Security) Lieferketten durch SBOM/VEX transparenter machen, Third-Party-Risiken beherrschen und die Compliance aller Zulieferer sicherstellen. CRA Quickcheck Sind Ihre Produkte betroffen? Scope Feststellung vom Geltungsbereich, betroffenen Produkten und Rollen - für einen eindeutig abgegrenzten CRA-Scope. Governance Strukturierte Governance mit klaren Verantwortlichkeiten, Richtlinien und Kontrollen etablieren. Risikomanagement Umfassendes Risikomanagement über den gesamten Lebenszyklus - von der initialen Bewertung bis zum aktiven Schwachstellenmanagement. Berichtspflichten & Compliance Transparente Vorfall- und Schwachstellenmeldungen mit vollständiger Dokumentation und Nachweisen sicherstellen. Lieferkette (Supply Chain Security) Lieferketten durch SBOM/VEX transparenter machen, Third-Party-Risiken beherrschen und die Compliance aller Zulieferer sicherstellen. CRA Quickcheck Sind Ihre Produkte betroffen? IHR WEG ZUR CRA-COMPLIANCE IN 5 EINFACHEN PHASEN IHR WEG ZUR CRA-COMPLIANCE IN 5 EINFACHEN PHASEN Phasen 1 Anwendungsbereich prüfen und Produkt einstufen Betroffenheitsanalyse, Rollenklärung, Risikoklassifizierung, GAP-Analye 2 Technische und prozesuale Grundlagen implementieren Risikoanalyse, Security by Design, Richtlinien und KPIs, Strategie & Governance, Tests und Releases, Verantwortlichkeiten 3 Prozessuale Etablierung Prozesse definieren, Meldepflichten / Enisa, Fristen & Benachrichtigungen, Steuerung Lieferanten, Anpassung SLAs, SBOM Mangement 4 Nachweis Konformität Dokumentation, Bewertungen, Anleitungen, Schulung und rollenbasiertes Training 5 Abschluss der Compliance Konformitätserklärung, CE Kennzeichnung, Marktüberwachung, Kontinuierliche Verbesserung 1 Anwendungsbereich prüfen und Produkt einstufen Betroffenheitsanalyse, Rollenklärung, Risikoklassifizierung, GAP-Analye 2 Technische und prozesuale Grundlagen implementieren Risikoanalyse, Security by Design, Richtlinien und KPIs, Strategie & Governance, Tests und Releases, Verantwortlichkeiten 3 Prozessuale Etablierung Prozesse definieren, Meldepflichten / Enisa, Fristen & Benachrichtigungen, Steuerung Lieferanten, Anpassung SLAs, SBOM Mangement 4 Nachweis Konformität Dokumentation, Bewertungen, Anleitungen, Schulung und rollenbasiertes Training 5 Abschluss der Compliance Konformitätserklärung, CE Kennzeichnung, Marktüberwachung, Kontinuierliche Verbesserung Benefit Unsere Expertise basiert auf umfangreicher Erfahrung aus dem von der Europäischen Union geförderten Projekt OCCTET (Projekt zur Unterstützung von Firmen bei der Erfüllung von Anforderungen des CRA), der Mitwirkung bei der Bitkom im Arbeitsbereich Open Source, sowie langjährige Erfahrung bei... Orientierung im Open Source Ökosystem_v1 (Englisch (USA)) (English) - Bitsea About usServicesResourcesContactCareer Orientation in the Open Source Ecosystem Association, standards, and safety initiatives. Open source has long been a central component of modern software developmentbut the landscape of associations, standards, and initiatives is complex. This page provides an overview of the most important organisations, standards, and security agencies in the open source environment. The selection includes international committees, political initiatives, and technical standardisations that are relevant for compliance, security, and sustainable open source management. The aim is to provide you with a quick overview—from industry associations such as Bitkom to international standards such as OpenChain and SPDX to security databases such as NVD and EUVD.This allows you to stay up to date on the most important developments, guidelines, and contacts related to open source. Associations & Interest Groups Organisations that connect open source communities, companies, and politics or set guidelines Bitkom Open Source German Digital Association with working groups on open source. OpenChain Cross-industry standard for open source compliance processes (ISO 5230, ISO 18974). Open Source Automation Development Lab Association for the promotion of open source in industrial automation. TODO group Association of open source program managers from large companies. Free Software Foundation Europe Non-profit organisation promoting free software in Europe. Open Source Organisation & Political Initiatives Non-profit or multi-stakeholder organisations that promote open source at the political or social level Software Freedom Conservancy Non-profit organisation that provides legal and organisational support to open source projects. OpenForum Europe Think tank for open digital standards and political advocacy in the EU. Sovereign Tech Agency German agency for the promotion of digital sovereignity and open source techologies. OSI International organisation that manages the definition of "open source" and certifies licences. Security and Standardisation Bodies Institutions and initiatives for security, standardisation, and compliance in the open-source context BSI National authority for IT security and cyber defense in Germany. SPDX Open standard for describing software components and licences.  CyclonDX Standard for Software Bill of Materials (SBOM) with a focus on security. European Union Vulnerability Database EU-wide vulnerability database for harmonising IT security information. National Vulnerability Database US government vulnerability database maintained by NIST. Privacy PolicyImprintGermanEnglish (USA)Copyright 2025 Bitsea GmbH About us VisionTimelineTisaxAssociationsPartnersSustainabilityServices and Solutions Open-Source-ManagementSoftware Quality AnalysisTechnical Project ManagementResources ResearchWebinarsBlog & CommunityEventsLexiconDatasheetsCareer JobsContact Us +49 (0) 2241 8942615 info@bitsea.de Request a demo About usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen-Source-ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlog & CommunityLexiconContactCareerCareerLife at Bitsea Orientierung im Open Source Ökosystem_v1 (Englisch (USA)) (English) - Bitsea About usServicesResourcesContactCareer Orientation in the Open Source Ecosystem Association, standards, and safety initiatives. Open source has long been a central component of modern software developmentbut the landscape of associations, standards, and initiatives is complex. This page provides an overview of the most important organisations, standards, and security agencies in the open source environment. The selection includes international committees, political initiatives, and technical standardisations that are relevant for compliance, security, and sustainable open source management. The aim is to provide you with a quick overview—from industry associations such as Bitkom to international standards such as OpenChain and SPDX to security databases such as NVD and EUVD.This allows you to stay up to date on the most important developments, guidelines, and contacts related to open source. Associations & Interest Groups Organisations that connect open source communities, companies, and politics or set guidelines Bitkom Open Source German Digital Association with working groups on open source. OpenChain Cross-industry standard for open source compliance processes (ISO 5230, ISO 18974). Open Source Automation Development Lab Association for the promotion of open source in industrial automation. TODO group Association of open source program managers from large companies. Free Software Foundation Europe Non-profit organisation promoting free software in Europe. Open Source Organisation & Political Initiatives Non-profit or multi-stakeholder organisations that promote open source at the political or social level Software Freedom Conservancy Non-profit organisation that provides legal and organisational support to open source projects. OpenForum Europe Think tank for open digital standards and political advocacy in the EU. Sovereign Tech Agency German agency for the promotion of digital sovereignity and open source techologies. OSI International organisation that manages the definition of "open source" and certifies licences. Security and Standardisation Bodies Institutions and initiatives for security, standardisation, and compliance in the open-source context BSI National authority for IT security and cyber defense in Germany. SPDX Open standard for describing software components and licences.  CyclonDX Standard for Software Bill of Materials (SBOM) with a focus on security. European Union Vulnerability Database EU-wide vulnerability database for harmonising IT security information. National Vulnerability Database US government vulnerability database maintained by NIST. Privacy PolicyImprintGermanEnglish (USA)Copyright 2025 Bitsea GmbH About us VisionTimelineTisaxAssociationsPartnersSustainabilityServices and Solutions Open-Source-ManagementSoftware Quality AnalysisTechnical Project ManagementResources ResearchWebinarsBlog & CommunityEventsLexiconDatasheetsCareer JobsContact Us +49 (0) 2241 8942615 info@bitsea.de Request a demo About usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen-Source-ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlog & CommunityLexiconContactCareerCareerLife at Bitsea Orientierung im Open Source Ökosystem_v1 (Englisch (USA)) (English) - Bitsea About usServicesResourcesContactCareer Orientation in the Open Source Ecosystem Association, standards, and safety initiatives. Open source has long been a central component of modern software developmentbut the landscape of associations, standards, and initiatives is complex. This page provides an overview of the most important organisations, standards, and security agencies in the open source environment. The selection includes international committees, political initiatives, and technical standardisations that are relevant for compliance, security, and sustainable open source management. The aim is to provide you with a quick overview—from industry associations such as Bitkom to international standards such as OpenChain and SPDX to security databases such as NVD and EUVD.This allows you to stay up to date on the most important developments, guidelines, and contacts related to open source. Associations & Interest Groups Organisations that connect open source communities, companies, and politics or set guidelines Bitkom Open Source German Digital Association with working groups on open source. OpenChain Cross-industry standard for open source compliance processes (ISO 5230, ISO 18974). Open Source Automation Development Lab Association for the promotion of open source in industrial automation. TODO group Association of open source program managers from large companies. Free Software Foundation Europe Non-profit organisation promoting free software in Europe. Open Source Organisation & Political Initiatives Non-profit or multi-stakeholder organisations that promote open source at the political or social level Software Freedom Conservancy Non-profit organisation that provides legal and organisational support to open source projects. OpenForum Europe Think tank for open digital standards and political advocacy in the EU. Sovereign Tech Agency German agency for the promotion of digital sovereignity and open source techologies. OSI International organisation that manages the definition of "open source" and certifies licences. Security and Standardisation Bodies Institutions and initiatives for security, standardisation, and compliance in the open-source context BSI National authority for IT security and cyber defense in Germany. SPDX Open standard for describing software components and licences.  CyclonDX Standard for Software Bill of Materials (SBOM) with a focus on security. European Union Vulnerability Database EU-wide vulnerability database for harmonising IT security information. National Vulnerability Database US government vulnerability database maintained by NIST. Privacy PolicyImprintGermanEnglish (USA)Copyright 2025 Bitsea GmbH About us VisionTimelineTisaxAssociationsPartnersSustainabilityServices and Solutions Open-Source-ManagementSoftware Quality AnalysisTechnical Project ManagementResources ResearchWebinarsBlog & CommunityEventsLexiconDatasheetsCareer JobsContact Us +49 (0) 2241 8942615 info@bitsea.de Request a demo About usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen-Source-ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlog & CommunityLexiconContactCareerCareerLife at Bitsea Datasheets - Bitsea About usServicesResourcesContactCareersResearchWebinarsBlogEventsLexiconDatasheets Resources Datasheets Our data sheets provide you with all the important information at a glance—from technical details to the advantages of our services. Here you will find our latest datasheets, which you can download free of charge. Open Source Management Datasheet Professional sevices for software risk, compliance and die diligence. Download PDFLegal Datasheet Bitsea' s datasheet outlines how we manage open source. It explains how our experts deliver technical due diligences for M&A, monitor cybersecurity, licenses, and create the most detailed SBOMs, and help oranizations securely leverage open source while meeting ISO standards and global regulations. Download PDFSoftware Analysis Datasheet Bitsea's datasheet introduces our advanced software quality audits that uncover hidden risks, technical debt, and architecture flaws before they threaten projects or budgets. It highlights powerful 2D/3D visualizations, ISO-based maintainability checks, and expert recommendations - helping organizations boost security, code quality, and long-term software performance. Download PDFOpen Source Monitor 2025 Chartreport The Open Source Monitor 2025 provides answers. Building on the studies conducted in 2019, 2021, and 2023, the current edition provides a comprehensive overview of the use and prospects of open source in Germany. Download PDF (in German) Privacy PolicyImprintEnglishGermanCopyright 2026 Bitsea US, Inc. About us VisionTimelineTisaxAssociationsPartnersSustainabilityServices and Solutions Open Source ManagementSoftware Quality AnalysisResources ResearchWebinarsBlogEventsLexiconDatasheetsCareers Life at BitseaJobsContact Us +1-510-593-6757 info@bitsea.us Request a demo ResearchWebinarsBlogEventsLexiconDatasheetsAbout usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen Source ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlogLexiconContactCareersCareersLife at Bitsea Datenblätter - Bitsea Über unsDienstleistungenRessourcenKontaktJob & KarriereForschungWebinareBlog & CommunityEventsLexikonDatenblätter Ressourcen Datenblätter Unsere Datenblätter bieten Ihnen alle wichtigen Informationen auf einen Blick – von technischen Details bis hin zu den Vorteilen unserer Dienstleistungen. Hier finden Sie unsere neuesten Datenblätter, die Sie sich kostenlos herunterladen können. Curator Pro Datenblatt Transparenz für Ihre Software-Lieferkette. PDF herunterladenRechtliches Datenblatt Das Datenblatt von Bitsea beschreibt, wie wir Open Source verwalten. Es erläutert, wie unsere Experten technische Due-Diligence-Prüfungen für Fusionen und Übernahmen durchführen, Cybersicherheit und Lizenzen überwachen, äußerst detaillierte SBOMs erstellen und Unternehmen dabei unterstützen, Open Source sicher zu nutzen und gleichzeitig ISO-Standards und globale Vorschriften einzuhalten. PDF herunterladenSoftware Analyse Datenblatt Das Datenblatt von Bitsea stellt unsere fortschrittlichen Software-Qualitätsprüfungen vor, die versteckte Risiken, technische Schulden und Architekturfehler aufdecken, bevor sie Projekte oder Budgets gefährden. Es basiert auf leistungsstarken 2D/3D-Visualisierungen, ISO-basierte Wartbarkeitsprüfungen und Expertenempfehlungen, die Unternehmen dabei helfen, die Sicherheit, die Codequalität und die langfristige Softwareleistung zu verbessern. PDF herunterladenOpen Source Monitor 2025 Chartbericht Der Open Source Monitor 2025 gibt Antworten. Aufbauend auf den Studien der Jahre 2019, 2021, und 2023 liefert die aktuelle Ausgabe eine umfassende Bestandsaufnahme zum Einsatz und den Perspektiven von Open Source in Deutschland. PDF herunterladen DatenschutzImpressumEnglischEnglisch (USA)Copyright 2026 Bitsea GmbH Über uns VisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungen und Lösungen CRA GuardianOpen-Source-ManagementSoftware QualitätsanalyseRessourcen ForschungWebinareBlogEventsLexikonDatenblätterJobs & Karriere Arbeiten bei BitseaJobsKontakt +49 (0) 2241 8942615 info@bitsea.de Vorführungstermin vereinbaren ForschungWebinareBlogEventsLexikonDatenblätterÜber unsÜber unsVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungenDienstleistungenOpen-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcenRessourcenForschungWebinareEventsBlog & CommunityLexikonKontaktJob & KarriereJob & KarriereArbeiten bei Bitsea Bitsea - Bitsea Über unsDienstleistungenRessourcenKontaktJob & Karriere Bitsea - Die Wahrheit liegt im Quellcode News Gründung der Bitsea US, Inc. Die Bitsea GmbH gibt die Übernahme des Auditing Services Teams von Revenera bekannt. Event Für den „Ludwig 2026“ nominiert – Innovation aus Bonn/Rhein-Sieg Di, 09. Juni 2026 im GOP Varieté-Theater Bonn Webinar 21. BSI Kongress CRA-Compliance in der Praxis: Wie offene Werkzeuge KMU bei der Absicherung von SW-Lieferketten unterstützen Forschung OCCTET Ein Werkzeugbaukasten zur Einhaltung des CRA. Bitsea ist spezialisiert auf die Prüfung von Softwaresystemen und identifiziert versteckte Risiken für Unternehmen. Wir unterstützen bei der technischen Due Diligence und beraten Betreiber von kritischer Infrastruktur (KRITIS). CRA Guardian Unsere Cyber Resilience Act Compliance Readiness Suite Mehr erfahrenOpen Source Management Umfassende Beratung zum Einsatz und Management von Open Source Software (OSS). Mehr erfahrenSoftware Qualitätsanalyse Identifizierung verborgener Risiken, Top Level Management Reporting mit einzigartigen Visualisierungen. Mehr erfahrenBrancheneinblicke Blog Shai-Hulud, npm und moderne SW-Lieferketten Blog Open Source Monitor 2025 Blog Die Auswirkungen des CRAs auf die Autoindustrie Blog SBOMs als primärer Compliance-Mechanismus DatenschutzImpressumEnglischEnglisch (USA)Copyright 2026 Bitsea GmbH Über uns VisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungen und Lösungen CRA GuardianOpen-Source-ManagementSoftware QualitätsanalyseRessourcen ForschungWebinareBlogEventsLexikonDatenblätterJobs & Karriere Arbeiten bei BitseaJobsKontakt +49 (0) 2241 8942615 info@bitsea.de Vorführungstermin vereinbaren Über unsÜber unsVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungenDienstleistungenOpen-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcenRessourcenForschungWebinareEventsBlog & CommunityLexikonKontaktJob & KarriereJob & KarriereArbeiten bei Bitsea Bitsea - Open Source Compliance & SBOM Management About usServicesResourcesContactCareers Bitsea specializes in auditing software systems and identifying hidden risks in your code. We deliver the technical due diligence required for internal audits and M&A transactions. Open Source Management Software supply chain risk assessments, SBOMs and M&A technical due diligence. Read moreSoftware Quality Analysis Identification of hidden risks, top-level management reporting Read moreCustomer voices "The audit team reacted within hours when a critical contribution to an open source community required quick turn around on a forensic code scan of a large collection of micro service code. Adding to the complexity, due to budgetary constraints, we required a relatively strong estimate before the work could begin. The team met the deadline and budget estimate which allowed us to meet ours! Great work!" - Dell Technologies News Establishment of Bitsea US, Inc. Bitsea acquires Revenera's auditing services team. Events OpenSSF Community Day Thu, 05/21/2026 in Minneapolis, Minnesota Webinars OpenChain Webinar An OpenChain Webinar on reviewing SBOMs. Research OCCTET A toolkit for compliance with CRA. Privacy PolicyImprintEnglishGermanCopyright 2026 Bitsea US, Inc. About us VisionTimelineTisaxAssociationsPartnersSustainabilityServices and Solutions Open Source ManagementSoftware Quality AnalysisResources ResearchWebinarsBlogEventsLexiconDatasheetsCareers Life at BitseaJobsContact Us +1-510-593-6757 info@bitsea.us Request a demo About usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen Source ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlogLexiconContactCareersCareersLife at Bitsea Bitsea - Bitsea Über unsDienstleistungenRessourcenKontaktJob & Karriere Bitsea - Die Wahrheit liegt im Quellcode News Gründung der Bitsea US, Inc. Die Bitsea GmbH gibt die Übernahme des Auditing Services Teams von Revenera bekannt. Event Cybersecurity Summit 2026 Do, 26.02.2026 ab 15 Uhr, in der Motorworld Köln Webinar Open Chain Webinar Eine Diskussionsrunde zu den Risiken und dem Management generativer KI. Forschung OCCTET Ein Werkzeugbaukasten zur Einhaltung des CRA. Bitsea ist spezialisiert auf die Prüfung von Softwaresystemen und identifiziert versteckte Risiken für Unternehmen. Wir unterstützen bei der technischen Due Diligence und beraten Betreiber von kritischer Infrastruktur (KRITIS). CRA Guardian Unsere Cyber Resilience Act Compliance Readiness Suite Mehr erfahrenOpen Source Management Umfassende Beratung zum Einsatz und Management von Open Source Software (OSS). Mehr erfahrenSoftware Qualitätsanalyse Identifizierung verborgener Risiken, Top Level Management Reporting mit einzigartigen Visualisierungen. Mehr erfahrenBrancheneinblicke Blog Shai-Hulud, npm und moderne SW-Lieferketten Blog Open Source Monitor 2025 Blog Die Auswirkungen des CRAs auf die Autoindustrie Jobs Open Source Compliance Auditor DatenschutzImpressumEnglischEnglisch (USA)Copyright 2026 Bitsea GmbH Über uns VisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungen und Lösungen CRA GuardianOpen-Source-ManagementSoftware QualitätsanalyseRessourcen ForschungWebinareBlogEventsLexikonDatenblätterJobs & Karriere Arbeiten bei BitseaJobsKontakt +49 (0) 2241 8942615 info@bitsea.de Vorführungstermin vereinbaren Über unsÜber unsVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungenDienstleistungenOpen-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcenRessourcenForschungWebinareEventsBlog & CommunityLexikonKontaktJob & KarriereJob & KarriereArbeiten bei Bitsea Blog - Bitsea About usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen Source ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlogLexiconContactCareersCareersLife at BitseaResearchWebinarsBlogEventsLexicon Resources Blog & Community Load more Privacy PolicyImprintEnglishGermanCopyright 2025 Bitsea GmbH About us VisionTimelineTisaxAssociationsPartnersSustainabilityServices and Solutions Open Source ManagementSoftware Quality AnalysisTechnical Project ManagementResources ResearchWebinarsBlogEventsLexiconCareers Life at BitseaJobsContact Us +49 (0) 2241 8942615 info@bitsea.de Request a demo ResearchWebinarsBlogEventsLexiconAbout usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen Source ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlogLexiconContactCareersCareersLife at Bitsea Blog - Bitsea Über unsÜber unsVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungenDienstleistungenOpen-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcenRessourcenForschungWebinareEventsBlog & CommunityLexikonKontaktJob & KarriereJob & KarriereArbeiten bei BitseaForschungWebinareBlog & CommunityEventsLexikon Ressourcen Blog & Community Mehrladen DatenschutzImpressumEnglischEnglisch (USA)Copyright 2025 Bitsea GmbH Über uns VisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungen und Lösungen Open-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcen ForschungWebinareBlogEventsLexikonJobs & Karriere Arbeiten bei BitseaJobsKontakt +49 (0) 2241 8942615 info@bitsea.de Vorführungstermin vereinbaren ForschungWebinareBlogEventsLexikonÜber unsÜber unsVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungenDienstleistungenOpen-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcenRessourcenForschungWebinareEventsBlog & CommunityLexikonKontaktJob & KarriereJob & KarriereArbeiten bei Bitsea Blog - Bitsea Über unsÜber unsVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungenDienstleistungenOpen-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcenRessourcenForschungWebinareEventsBlog & CommunityLexikonKontaktJob & KarriereJob & KarriereArbeiten bei BitseaForschungWebinareBlog & CommunityEventsLexikon Ressourcen Blog & Community Mehrladen DatenschutzImpressumEnglischEnglisch (USA)Copyright 2025 Bitsea GmbH Über uns VisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungen und Lösungen Open-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcen ForschungWebinareBlogEventsLexikonJobs & Karriere Arbeiten bei BitseaJobsKontakt +49 (0) 2241 8942615 info@bitsea.de Vorführungstermin vereinbaren ForschungWebinareBlogEventsLexikonÜber unsÜber unsVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungenDienstleistungenOpen-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcenRessourcenForschungWebinareEventsBlog & CommunityLexikonKontaktJob & KarriereJob & KarriereArbeiten bei Bitsea 404 - Bitsea Über unsDienstleitungenRessourcenKontaktJob & KarriereArbeiten bei BitseaJobs Jobs & Karriere 404 Seite nicht gefunden Der Server kann die von Ihnen angeforderte Datei nicht finden. Die Seite wurde entweder verschoben oder gelöscht, oder Sie haben die falsche URL oder den falschen Dokumentnamen eingegeben. Sehen Sie sich die URL an. Wenn ein Wort falsch geschrieben zu sein scheint, korrigieren Sie es und versuchen Sie es erneut. Wenn das nicht funktioniert, können Sie unsere Suchfunktion oder die Header Navigation nutzen, um das Gesuchte zu finden. SearchSubmitClear DatenschutzImpressumEnglischEnglisch (USA)Copyright 2025 Bitsea GmbH Über uns VisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungen und Lösungen Open-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcen ForschungWebinareBlogEventsLexikonJobs & Karriere Arbeiten bei BitseaJobsKontakt +49 (0) 2241 8942615 info@bitsea.de Vorführungstermin vereinbaren Arbeiten bei BitseaJobsÜber unsÜber unsVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungenDienstleistungenOpen-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcenRessourcenForschungWebinareEventsBlog & CommunityLexikonKontaktJob & KarriereJob & KarriereArbeiten bei Bitsea Software Quality Analysis - Bitsea Services About usServicesResourcesContactCareersOpen Source ManagementSoftware Quality Analysis Services Software Quality Analysis Many of the risks in software systems cannot be seen. This can seriously impact the company's “time-to-market” approach and results in high future costs. Effort to modify the software will increase continuously. Maintainability is proven to be the key driver of total software lifecycle cost (TCO). Risks 67% of software costs arise during maintenance. The main driver is technical debt.Technical debt reflects consequences of insufficient design of a software system. It describes the cost of additional rework caused by choosing an easy solution, instead of using a better future-proof approach. Ignoring maintainability leads to higher costs, greater effort and delays in projects. Bitsea services Bitsea invented a revolutionary approach to visualizing software systems. It allows customers to quickly understand complex software systems.Improve software quality, detect issues early and reduce testing effort. Benefit from independent expert advice. Get a 100% transparent view of your software. Bitsea develops a clear roadmap together with our customers to ensure higher maintainability. Realize up to 50% savings in total cost of ownership (TCO). Our recommendations help to shorten development schedules and can reduce the defect rate by up to 95%. Unique Software Visualizations Easy to understand 2D/3D pictures and graphs give transparency on hidden risks. Bitsea visualizes architecture, component size, dependencies, duplication, complexity, inefficiencies and the lack of performance. Bitsea helps customers to improve their codebases. Top-LevelManagement Reporting Executive summary. Review of software architecture, design and implementation, detection of antipatterns, impact analysis and recommendations. RecommendationCatalog Step-by-step instructions for optimization. A detailed report summarizes identified antipatterns and remediation measures. Prioritizations ensure quick wins. Senior Experts Senior software engineers and software architects with proven track records. Bitsea experts have analyzed more than 100,000,000 lines of codes (LOC) in different business domains in Fortune 500 companies. Technical Debt Bitsea conducts a standardized maintainability assessment based on ISO 25010. Reduce your total cost of ownership (TCO) up to 50%, shorten development cycles by 20%. Maintainability Analysis Independent audit and standardized maintainability assessment based on ISO 25010. Enables easily repeatable comparison. ContinuousAnalysis Customized monitoring integrated into the development process enables customers to detect anomalies early and proactively secure maintainability. Benefits · Independent advice, fair and objective 100% transparent view of the software · Clear roadmap to ensure better maintainability · The total cost of ownership can be reduced by up to 50% · Our recommendations help customers to shorten development schedules and reduce the error rate by up to 95% Contact Privacy PolicyImprintEnglishGermanCopyright 2026 Bitsea US, Inc. About us VisionTimelineTisaxAssociationsPartnersSustainabilityServices and Solutions Open Source ManagementSoftware Quality AnalysisResources ResearchWebinarsBlogEventsLexiconDatasheetsCareers Life at BitseaJobsContact Us 781-784-4653 info@bitsea.us Request a demo Open Source ManagementSoftware Quality AnalysisAbout usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen Source ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlogLexiconContactCareersCareersLife at Bitsea Open Source Management - Bitsea Services About usServicesResourcesContactCareersOpen Source ManagementSoftware Quality Analysis Services OPEN SOURCE MANAGEMENT PROFESSIONAL SERVICES FOR SOFTWARE RISK, COMPLIANCE AND DUE DILIGENCE What we deliver From baseline product audits to transaction-driven reviews, Bitsea helps organizations identify open source, track obligations, understand vulnerabilities, and build a transparent software bill of materials. M&A M&A The buy and sell-side of technical due-diligence Comprehensive SBOM Comprehensive SBOM Create complete and accurate SBOMs in any format Baseline Audit Baseline Audit Continuous code scanning to strengthen security and support compliance Vulnerabilities Vulnerabilities Remediation, supply-chain security, continuous monitoring What we deliver From baseline product audits to transaction-driven reviews, Bitsea helps organizations identify open source, track obligations, understand vulnerabilities, and build a transparent software bill of materials. M&A The buy and sell-side of technical due-diligence Comprehensive SBOM Create complete and accurate SBOMs in any format Baseline Audit Continuous code scanning to strengthen security and support compliance Vulnerabilities Remediation, supply-chain security, continuous monitoring Bitsea® US is a security-focused technology consulting company specializing in software audits, open-source risk assessments, SBOM creation and analysis, vulnerability identification, and technical due diligence. We support internal code audits and M&A transactions by performing in-depth evaluations to uncover hidden risks across software codebases and development environments, including software supply chain security and AI-driven components. For more than two decades, leading companies across automotive, telecommunications, government, financial services, aerospace, and other industries have relied on Bitsea’s expertise to assess, secure, and strengthen the integrity of their technology assets and software ecosystems. PROTECT AGAINST LEGAL, OPERATIONAL, AND CYBERSECURITY RISKS PROTECT AGAINST LEGAL, OPERATIONAL, AND CYBERSECURITY RISKS Organizations depend on open source and AI to build software faster, reduce costs, and accelerate innovation. That value comes with obligations. Whether the code was developed in-house, from open source, or generated by AI, it is crucial to know what is in your software understand how it entered the codebase, and continuously monitor license, IP, and security exposure. Bitsea OSS Chart - Hard Layout Open Source Audit Average number of known OSS Average Number of Open Source Components Discovered During an Audit 25 221 2012 25 236 2013 29 252 2014 8 454 2015 27 560 2016 17 590 2017 29 626 2018 19 670 2019 78 2004 2020 131 2309 2021 149 3677 2022 189 3546 2023 Open Source Audit Average number of known OSS Average number of open source components discovered during an audit 27 560 '16 17 590 '17 29 626 '18 19 670 '19 78 2004 '20 131 2309 '21 149 3677 '22 189 3546 '23 SERVICES MODELED FOR REAL-WORLD SOFTWARE ENVIRONMENTS M&A Audit Services M&A audit services evaluate software assets during acquisitions to identify third-party, licensing, security, and operational risks. They give buyers and sellers clear visibility into what’s in the codebase so they can make informed decisions, negotiate effectively, and plan for post-close integration and remediation. Baseline transaction support for software diligence Targeted forensic review where code requires deeper analysis Findings suitable for remediation, evaluation, negotiation, and post-close planning Baseline Product Audits... Life at Bitsea US - Company Culture & Careers About usServicesResourcesContactCareersLife at BitseaJobs Career Life at Bitsea Interested? Take a look at Jobs TeamAt Bitsea, innovation thrives in a culture built on collaboration, curiosity, and continuous learning. We bring together passionate technologists and creative thinkers to deliver solutions to our clients that reduce risk and ensure business continuity. We value flexibility, inclusivity, and a strong sense of comunity - because great ideas come from empowered teams. Work-Life BalanceWe believe in keeping things smart, flexible, and people-first. Our employees work from home, set healthy boundaries, and believe great work doesn't require burning out. Here, you'll find a strong sense of team, plenty of room to grow, and the freedom to do your best work - without giving up your life outside the screen. Interested? Take a look at Jobs Privacy PolicyImprintEnglishGermanCopyright 2026 Bitsea US, Inc. About us VisionTimelineTisaxAssociationsPartnersSustainabilityServices and Solutions Open Source ManagementSoftware Quality AnalysisResources ResearchWebinarsBlogEventsLexiconDatasheetsCareers Life at BitseaJobsContact Us +1-510-593-6757 info@bitsea.us Request a demo Life at BitseaJobsAbout usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen Source ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlogLexiconContactCareersCareersLife at Bitsea Software Quality Analysis - Bitsea Services About usServicesResourcesContactCareersOpen Source ManagementSoftware Quality Analysis Services Software Quality Analysis Many of the risks in software systems cannot be seen. This can seriously impact the company's “time-to-market” approach and results in high future costs. Effort to modify the software will increase continuously. Maintainability is proven to be the key driver of total software lifecycle cost (TCO). Risks 67% of software costs arise during maintenance. The main driver is technical debt.Technical debt reflects consequences of insufficient design of a software system. It describes the cost of additional rework caused by choosing an easy solution, instead of using a better future-proof approach. Ignoring maintainability leads to higher costs, greater effort and delays in projects. Bitsea services Bitsea invented a revolutionary approach to visualizing software systems. It allows customers to quickly understand complex software systems.Improve software quality, detect issues early and reduce testing effort. Benefit from independent expert advice. Get a 100% transparent view of your software. Bitsea develops a clear roadmap together with our customers to ensure higher maintainability. Realize up to 50% savings in total cost of ownership (TCO). Our recommendations help to shorten development schedules and can reduce the defect rate by up to 95%. Unique Software Visualizations Easy to understand 2D/3D pictures and graphs give transparency on hidden risks. Bitsea visualizes architecture, component size, dependencies, duplication, complexity, inefficiencies and the lack of performance. Bitsea helps customers to improve their codebases. Top-LevelManagement Reporting Executive summary. Review of software architecture, design and implementation, detection of antipatterns, impact analysis and recommendations. RecommendationCatalog Step-by-step instructions for optimization. A detailed report summarizes identified antipatterns and remediation measures. Prioritizations ensure quick wins. Senior Experts Senior software engineers and software architects with proven track records. Bitsea experts have analyzed more than 100,000,000 lines of codes (LOC) in different business domains in Fortune 500 companies. Technical Debt Bitsea conducts a standardized maintainability assessment based on ISO 25010. Reduce your total cost of ownership (TCO) up to 50%, shorten development cycles by 20%. Maintainability Analysis Independent audit and standardized maintainability assessment based on ISO 25010. Enables easily repeatable comparison. ContinuousAnalysis Customized monitoring integrated into the development process enables customers to detect anomalies early and proactively secure maintainability. Benefits · Independent advice, fair and objective 100% transparent view of the software · Clear roadmap to ensure better maintainability · The total cost of ownership can be reduced by up to 50% · Our recommendations help customers to shorten development schedules and reduce the error rate by up to 95% Contact Privacy PolicyImprintEnglishGermanCopyright 2026 Bitsea US, Inc. About us VisionTimelineTisaxAssociationsPartnersSustainabilityServices and Solutions Open Source ManagementSoftware Quality AnalysisResources ResearchWebinarsBlogEventsLexiconDatasheetsCareers Life at BitseaJobsContact Us 781-784-4653 info@bitsea.us Request a demo Open Source ManagementSoftware Quality AnalysisAbout usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen Source ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlogLexiconContactCareersCareersLife at Bitsea Open-Source-Management - Bitsea About usServicesResourcesContactCareerCRA GuardianOpen Source ManagementSoftware Quality Analysis Services Open-Source-Management Open source is everywhere. An efficient open-source-management framework and the use of suitable processes and toolchains are prerequisites for the legally compliant and sustainable use of OSS. Bitsea supports you in all aspects of open-source-management. Companies drive their digital future through open innovation and benefit from shared knowledge and development capacities as well as strategic, open development and innovation alliances. They strengthen their digital sovereignty, reduce the vendor lock-in effect and improve IT security, quality and transparency through Open-Source communities.Experienced developers do not write their code from scratch, but use Open-Source for development. Reasons are to improve productivity, shorten development time and reduce development costs. AI is providing more and more support in the creation of software. Trained by code from Open-Source repositories, High-quality code can be generated at lightning speed.It is important to respect intellectual property and licence requirements. For legally compliant use, all Open-Source components in a software must be known and continuously checked for security vulnerabilities.The European Cyber Resilience Act (CRA) is currently being developed in the EU. With DORA (Digital Operational Resilience Act) and NIS 2 Directive, the European Union has created a financial sector-wide regulation for cyber security, ICT risks and digital operational resilience.An efficient Open-Source-Management framework and the use of suitable processes and tool chains such as Software Composition Analysis (SCA) and Software Asset Management (SAM) are prerequisites for the legally compliant and sustainable use of OSS. Professional management of intellectual property in your software supply chain with existing standards such as ISO 5230 and ISO 5962.Bitsea supports you in all aspects of Open-Source-Management so that you as a company are protected against a lack of compliance and cyber attacks on the software supply chain. Protection against risks ComplianceProtection against legal risks such as third-party intellectual property (IP) and licence obligations.CybersecurityProtection against security gaps and vulnerabilities in software supply chains: Continuous monitoring.Export restrictionsMany components, often with algorithms for encryption, are subject to strict export restrictions with drastic penalties.Artificial Intelligence (AI)AI systems, trained by code fragments from Open-Source repositories, often generate code without regards to and without mentioning copyrights and licences.License changesSome Open-Source projects change the underlying permissive licence to a more restrictive licence when an update is released. This requires continuous monitoring of the components and versions used.Policy protection68% of companies have no internal policy regarding the use of Open- Source. The majority of developers are aware of less than 10% of the Open-Source content in their products (Source: Bitkom Open Source Monitor 2023).Eliminate uncontrolled use of Open-Source to avoid copyright infringement, litigation, security vulnerabilities and operational risks. Meet licence obligations and avoid sanctions or penalties. Bitsea's services Benefit from sustainable Open-Source-Security, -risk and -compliance management.ConsultingBitsea advises customers comprehensively on Open-Source-Strategy, Open-Source-Governance, Open-Source-Processes, toolchains and offers an Open-Source-Program-Office (OSPO) and scanning as a managed service. We offer extensive workshops and training courses to sensitize your teams.DevelopmentBitsea builds and operates Open-Source-Tool-Chains and the associated infrastructure independently of tools and customised to clients needs.... Open-Source-Management - Bitsea Über unsDienstleistungenRessourcenKontaktJob & KarriereCRA GuardianOpen-Source-ManagementSoftware Qualitätsanalyse Dienstleistungen Open-Source-Management Open-Source ist überall. Ein effizientes Open-Source-Management Framework sowie der Einsatz geeigneter Prozesse und Werkzeugketten sind Voraussetzung für einen rechtssicheren und nachhaltigen Einsatz von OSS. Bitsea unterstützt Sie in allen Belangen des Open-Source-Managements. Situation Firmen treiben durch Open Innovation ihre digitale Zukunft voran und profitieren von gemeinsamem Wissen und Entwicklungskapazitäten sowie von strategischen, offenen Entwicklungs- und Innovationsallianzen. Sie stärken ihre digitale Souveränität, reduzieren den Vendor-Lock-in-Effekt und verbessern IT-Sicherheit, Qualität und Transparenz durch Open-Source Communities. Erfahrene Entwickler schreiben ihren Code nicht von Grund auf neu, sondern nutzen Open-Source für die Entwicklung. Die Gründe für den Einsatz liegen in der Verbesserung der Produktivität, der Verkürzung der Entwicklungszeit und in der Reduzierung der Entwicklungskosten. KI unterstützt immer mehr bei der Erstellung von Software. Angelernt durch Code aus Open-Source Repositories lässt sich qualitativ hochwertiger Code blitzschnell erzeugen. Wichtig ist hierbei die Beachtung geistigen Eigentums und von Lizenzvorgaben. Für eine rechtssichere Verwendung müssen in einer Software alle Open-Source Bestandteile bekannt sein und kontinuierlich auf Sicherheitslücken geprüft werden. In der EU entsteht gerade der europäische Cyber Resilience Act (CRA). Mit DORA (Digital Operational Resilience Act) und NIS2 hat die Europäische Union eine finanzsektorweite Regulierung für die Themen Cybersicherheit, IKT-Risiken und digitale operationale Resilienz geschaffen. Ein effizientes Open-Source-Management Framework sowie der Einsatz geeigneter Prozesse und Werkzeugketten wie Software Composition Analysis (SCA) und Software Asset Management (SAM) sind Voraussetzung für einen rechtssicheren und nachhaltigen Einsatz von OSS. Professionalisieren Sie das Management des geistigen Eigentums in Ihrer Software-Lieferkette mit bestehenden Standards wie ISO 5230 und ISO 5962. Bitsea unterstützt Sie in allen Belangen des Open-Source-Managements, damit Sie als Unternehmen vor fehlender Compliance und vor Cyberangriffen auf die Software-Lieferketten geschützt sind. Schutz vor Risiken Compliance Schutz vor rechtlichem Risiko wie dem geistigen Eigentum Dritter (IP) und Lizenzverpflichtungen. Cybersicherheit Schutz vor Sicherheitslücken und Anfälligkeit in Software-Lieferketten: Kontinuierliche Überwachung. Exportrestriktionen Viele Komponenten, oft mit Algorithmen zur Verschlüsselung, unterliegen strengen Exportrestriktionen mit drastischen Strafen. Künstliche Intelligenz (KI) Generierter Code, angelernt von Codefragmenten aus Open-Source Repositories, erzeugt oft Code ohne Beachtung und ohne Nennung von Urheberrechten und Lizenzen. Lizenzänderungen Einige Open-Source-Projekte ändern bei Herausgabe eines Updates die zugrundeliegende permissive Lizenz oftmals zu einer restriktiveren. Dies erfordert eine kontinuierliche Überwachung der genutzten Komponenten und Versionen. Richtlinien Schutz 68 % der Unternehmen haben keine interne Richtlinie bezüglich der Verwendung von Open-Source. Die Mehrheit der Entwickler sind sich über weniger als 10% der Open-Source Anteile in ihren Produkten bewusst (Quelle: Bitkom Open Source Monitor 2023). Eliminieren Sie die unkontrollierte Nutzung von Open-Source, um Urheberrechtsverletzungen, Rechtsstreitigkeiten, Sicherheitslücken und Betriebsrisiken zu vermeiden. Erfüllen Sie Lizenzverpflichtungen und verhindern Sie Sanktionen oder Vertragsstrafen. Bitseas Dienstleistungen Profitieren Sie von einem nachhaltigen Open-Source Sicherheits-, Risiko- und Compliance-Management. Beratung Bitsea berät Kunden umfassend zu Open-Source Strategie, Open-Source Governance, Open-Source Prozessen, Werkzeugketten und bietet ein Open-Source-Program-Office (OSPO) und Scanning als „Managed Service“ an. Zur Sensibilisierung Ihrer Teams bieten wir umfangreiche Workshops und Lehrgänge an. Entwicklung Bitsea baut und betreibt Tool-unabhängig ihre Open-Source Werkzeugketten und die dazugehörige Infrastruktur. Bei Bedarf passen unsere Entwickler Schnittstellen, Werkzeuge oder... Software Qualitätsanalyse - Bitsea Über unsDienstleistungenRessourcenKontaktJob & KarriereCRA GuardianOpen-Source-ManagementSoftware Qualitätsanalyse Dienstleistungen Software Qualitätsanalyse Viele Risiken in Softwaresystemen sind "von außen" nicht sichtbar. Diese können einen gravierenden Einfluss auf den Zeitaufwand haben und können hohe zukünftige Kosten verursachen. Der Aufwand um Software zu modifizieren steigt. Die Wartbarkeit ist erwiesenermaßen der wichtigste Faktor für die Gesamtkosten einer Software über den gesamten Lebenszyklus betrachtet. Risiken 67% der Softwarekosten entstehen bei der Wartung. Haupttreiber ist die technische Schuld. Die technische Schuld in der Softwareentwicklung spiegelt die Folgen eines unzureichenden Designs einer Software wieder. Sie beschreibt die Kosten für zusätzliche Nacharbeit, die durch die Wahl einer einfachen aber weniger wartbaren Lösung verursacht werden, anstatt einen besser zukunftssicheren Ansatz zu verwenden. Das Ignorieren des Qualitätskriteriums "Wartbarkeit" führt zu höheren Kosten, höherem Aufwand und Verzögerungen in Projekten. Bitseas Dienstleistungen Bitsea entwickelte einen revolutionären Ansatz zur Visualisierung von Softwaresystemen. Dieser ermöglicht Kunden, komplexe Softwaresysteme schnell zu verstehen. Verbessern Sie die Softwarequalität, erkennen Sie Fehlerquellen frühzeitig und reduzieren Sie damit den Testaufwand. Profitieren Sie von einer unabhängigen Beratung, fair und objektiv. Sie erhalten eine 100% transparente Sicht auf Software. Bitsea entwickelt zusammen mit Ihnen einen klaren Plan, um eine höhere Wartbarkeit zu gewährleisten. Sie reduzieren damit die Gesamtbetriebskosten um bis zu 50%. Unsere Empfehlungen helfen, die Entwicklungszeitpläne zu verkürzen und können die Fehlerquote um bis zu 95% reduzieren. Einzigartige Software- Visualisierungen Leicht verständliche 2D/3D-Bilder und Diagramme zeigen versteckte Risiken. Bitsea visualisiert Architektur, Komponentengröße, Abhängigkeiten, Duplikate, Komplexität, Ineffizienz und geringe Performance. Bitsea hilft Kunden bei der Verbesserung ihres Quellcodes. Top LevelManagement Gutachten Leicht verständliche 2D/3D-Bilder und Diagramme zeigen versteckte Risiken. Bitsea visualisiert Architektur, Komponentengröße, Abhängigkeiten, Duplikate, Komplexität, Ineffizienz und geringe Performance. Bitsea hilft Kunden bei der Verbesserung ihres Quellcodes. Empfehlungen Schritt für Schritt-Anweisungen für Optimierungen. Ein detaillierter Bericht fasst identifizierte Entwurfsmusterverletzungen zusammen und stellt mögliche Maßnahmen vor. Priorisierungen sorgen für schnelle Erfolge. Senior Experts Für Bitsea arbeiten Software-Ingenieure und -Architekten mit langjähriger Erfahrung. Bitseas Experten haben mittlerweile mehr als 100.000.000 LOC in unterschiedlichsten Bereichen der DAX-Unternehmen analysiert. Technische Schuld Bitsea führt eine standartisierte Bewertung der Wartbarkeit auf Grundlage der ISO 25010 durch. Reduzieren Sie die Gesamtkosten (TCO) um bis zu 20%. Wartbarkeit Unabhängige Audit und standardisierte Bewertung der Wartbarkeit auf der Grundlage von ISO 25010 ermöglichen einen einfachen, wiederholbaren Vergleich. Kontinuierliche Analyse Ein individuelles im Entwicklungsprozess integriertes Monitoring ermöglicht es Kunden Anomalien frühzeitig zu erkennen und Wartbarkeit proaktiv sicherzustellen. Benefit · Unabhängige Beratung, fair und objektiv 100% transparente Sicht auf die Software · Klare Roadmap zur Gewährleistung einer besseren Wartbarkeit · Die Gesamtbetriebskosten können um bis zu 50% gesenkt werden · Unsere Empfehlungen helfen den Kunden, Entwicklungszeitpläne zu verkürzen und können die Fehlerquote um 95% senken Kontakt DatenschutzImpressumEnglischEnglisch (USA)Copyright 2026 Bitsea GmbH Über uns VisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungen und Lösungen CRA GuardianOpen-Source-ManagementSoftware QualitätsanalyseRessourcen ForschungWebinareBlogEventsLexikonDatenblätterJobs & Karriere Arbeiten bei BitseaJobsKontakt +49 (0) 2241 8942615 info@bitsea.de Vorführungstermin vereinbaren CRA GuardianOpen-Source-ManagementSoftware QualitätsanalyseÜber unsÜber unsVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungenDienstleistungenOpen-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcenRessourcenForschungWebinareEventsBlog & CommunityLexikonKontaktJob & KarriereJob & KarriereArbeiten bei Bitsea Events - Bitsea Über unsÜber unsVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungenDienstleistungenOpen-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcenRessourcenForschungWebinareEventsBlog & CommunityLexikonKontaktJob & KarriereJob & KarriereArbeiten bei BitseaForschungWebinareBlog & CommunityEventsLexikon Ressourcen Events 02 12 2. Dezember 2025 Bitkom AK Open Source Bitkom Am 2.12.2025 sowie am 3.12.2025 findet in Nürnberg das Arbeitskreistreffen zum Thema „Retro 2025 und Planung 2026“ statt. Am 2.12.2025 von 12:00 Uhr – 17:00 Uhr. Am 3.12.2025 von 10:00 Uhr – 15:00 Uhr. Es handelt sich um eine hybride Sitzung. 06 11 6. November 2025 Unternehmenstag 2025 H-BRS Hochschule Bonn-Rhein-Sieg Am 06.11.2025 von 10:00 Uhr bis 16:00 Uhr findet der Unternehmenstag der Hochschule Bonn-Rhein-Sieg statt. Wir laden euch herzlich zu unserem Stand „a“ ein und freuen uns auf spannende Gespräche mit euch! Mehr Informationen zum Unternehmenstag 2025 findest ihr hier. 22 10 22./23. Oktober 2025 in Maison de la Poste, Brüssel Code & Compliance Eclipse Foundation Die Eclipse Foundation arbeitet eng mit der ORC-Community zusammen, um ein Programm zu entwickeln, dass die Prioritäten und Bedürfnisse von Maintainern, Open-Source-Führungskräften und institutionellen Stakeholdern widerspiegelt. Registrieren Sie sich hier. 15 10 15. Oktober 2025 ZF User Group meeting ZF Am 15.10.2025 findet das ZF User Group Meeting statt. Mehr Informationen werden folgen. 25 09 25. September 2025 09:00 Uhr – 11:00 Uhr PST / 12:00 Uhr – 14:00 EST Revenera SCA User Group Revenera Nehmen Sie gemeinsam mit Bitsea und anderen Branchenexperten an der SCA User Group teil – einer interaktiven virtuellen Veranstaltung mit dem Schwerpunkt auf dem Management von Risiken durch Open Source, sich wandelnden regulatorischen Anforderungen und praxisnahen Ansätzen zur Stärkung Ihrer Compliance und Sicherheitsstrategie. Registrieren Sie sich hier 18 09 18. September 2025 Bitkom AK Open Source – „Open Source in der Praxis – innovativ, compliant, ökonomisch“ Bitkom Am 18.09.2025 von 10:00 Uhr – 15:00 Uhr findet in Erfurt das 11. Bitkom Forum Open Source zum Thema „Open Source in der Praxis – innovativ, compliant, ökonomisch“ statt. Anmeldung hier. 11 09 11. September 2025 Revenera Webinar: Modern Open Source Risk Management Revenera Mehr Informationen werden folgen. 25 08 25. August 2025 - 27. August 2025 Open Source Summit Europe The Linux Foundation, Amsterdam Mehr Informationen finden Sie hier. 24 06 24. Juni 2025 Bitkom AK Open Source – „Open Source in der Praxis – compliant“ Bitkom Am 24.06.2025 sowie am 25.06.2025 findet in Berlin das Arbeitskreistreffen zum Thema „Open Source in der Praxis – compliant“ statt. Am 24.03.2025 von 12:00 Uhr – 17:00 Uhr. Am 25.03.2025 von 10:00 Uhr – 15:00 Uhr. Es handelt sich um eine hybride Sitzung. 05 06 05. Juni 2025 Innovationstag Mittelstand des BMWK 2025 AiF Projekt GmbH Neue Technologien, innovative Projekte und kreative Ideen als Wegweiser für die Zukunft – Das präsentieren kleine und mittlere Unternehmen am 5. Juni 2025 in Berlin beim Innovationstag Mittelstand des Bundesministeriums für Wirtschaft und Klimaschutz (BMWK). Rund 300 Aussteller vom Start-up bis zum etablierten Familienunternehmen stellen ihre wegweisenden Entwicklungen vor, die mit Unterstützung der themenoffenen Innovationsförderung des BMWK realisiert werden konnten. Auch die Bitesa GmbH ist vor Ort und präsentiert ein besonderes Highlight: Immersive VR-Visualisierung von Software.... Research - Bitsea About usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityDienstleistungenDienstleistungenOpen Source ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlogLexiconContactCareersCareersLife at BitseaResearchWebinarsBlogEventsLexicon Resources Bitsea research activity Bitsea is closely linked with research institutions and universities. Together we develop new products and services. European Union (EU) Research Project A project funded by the EU and critical for any U.S. company to be aware of if they are selling products into the EU that contain "digital elements." Problem The Cyber Resilience Act (CRA) strengthens the cyber resilience of digital products sold in the EU and places new obligations on manufacturers doing business in the EU to ensure product security throughout the entire life cycle. Managing open source correctly is a complex and tedious task. Goal Highly automated tools and processes to sustainably strengthen cybersecurity capabilities and resources while reducing operating costs. Solution Tool-based support to comply with CRA regulations, improve cybersecurity, and automate the handling of open source. Partners Learn moreAuto-VisRev A project funded by the BMWI's Central Innovation Programme (ZIM) to improve software quality and stability Problem Software reviews are very time-consuming and quality largely depends on the skill of individual people. Software quality cannot be seen from the "outside." Goal Improve efficiency and quality of software, enable high quality software for everyone. Solution Standardized visual representation of dynamic software behavior, automated reviews by artificial intelligence/rule engine. Supported by the Federal Ministry for Economic Affairs and Energy Partner Learn more Privacy PolicyImprintEnglishGermanCopyright 2025 Bitsea GmbH About us VisionTimelineTisaxAssociationsPartnersSustainabilityServices and Solutions Open Source ManagementSoftware Quality AnalysisTechnical Project ManagementResources ResearchWebinarsBlogEventsLexiconCareers Life at BitseaJobsContact Us +49 (0) 2241 8942615 info@bitsea.de Request a demo ResearchWebinarsBlogEventsLexiconAbout usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen Source ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlogLexiconContactCareersCareersLife at Bitsea Vision - Bitsea About usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityDienstleistungenDienstleistungenOpen Source ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlogLexiconContactCareersCareersLife at BitseaVisionTimelineTisaxAssociationsPartnersSustainability About us The truth is in the source code. How it all started To the Timeline Big software systems are like a wild wide ocean of bits – our passion is to analyze and visualize software structure. Bitsea helps our customers stabilize and optimize their systems. We analyze, evaluate and optimize your development processes, software architecture and software design. Bitsea performs the technical due diligence associated with internal audits and M&A transactions. We reduce the economic risk by assessing open source components and ensuring license compliance. Bitsea’s references include global Fortune 500 companies in communications, automotive, logistics, retail and aerospace industries. We adhere to the highest standards for information security and have been Tisax-certified since 2020. While a German standard that aligns with ISO 27001, Tisax certification is becoming essential for working with many Original Equipment Manufacturers (OEMs) worldwide. Bitsea is also an active member of the OpenChain Community. We guarantee strictly confidential consulting in the context of technical due diligence for M&A activities. How it all started To the timeline Privacy PolicyImprintEnglishGermanCopyright 2025 Bitsea GmbH About us VisionTimelineTisaxAssociationsPartnersSustainabilityServices and Solutions Open Source ManagementSoftware Quality AnalysisTechnical Project ManagementResources ResearchWebinarsBlogEventsLexiconCareers Life at BitseaJobsContact Us +49 (0) 2241 8942615 info@bitsea.de Request a demo VisionTimelineTisaxAssociationsPartnersSustainabilityAbout usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen Source ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlogLexiconContactCareersCareersLife at Bitsea Tisax - Bitsea Über unsÜber unsVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungenDienstleistungenOpen-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcenRessourcenForschungWebinareEventsBlog & CommunityLexikonKontaktJob & KarriereJob & KarriereArbeiten bei BitseaVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeit Über uns Bitsea ist TISAX-zertifiziert. Das Ergebnis ist für ENX-Mitglieder über das ENX-Portal abrufbar: TISAX Ergebnis anzeigen Vertraulichkeit, Verfügbarkeit und Integrität von Informationen haben für Bitsea einen großen Wert. Wir haben umfangreiche Maßnahmen zum Schutz sensibler Informationen ergriffen. Deshalb folgen wir dem Fragenkatalog zur Informationssicherheit des Verbandes der Automobilindustrie (VDA ISA). Das Assessment wurde 2019 vom TÜV Rheinland durchgeführt und 2022 bestätigt. Die ENX Association unterstützt mit TISAX (Trusted Information Security Assessment Exchange) im Auftrag des VDA die gemeinsame Akzeptanz von Informations­sicherheits­bewertungen in der Automobilindustrie. Die TISAX-Assessments werden von akkreditierten Auditanbietern durchgeführt, die in regelmäßigen Abständen ihre Qualifikation nachweisen. TISAX basiert auf der Norm ISO/IEC 27001. TISAX (Trusted Information Security Assessment Exchange) dient der unternehmensweiten Anerkennung von Informations­sicherheits­bewertungen in der Automobilindustrie und bietet einen gemeinsamen Test- und Austauschmechanismus. Die Ergebnisse bleiben immer unter der Kontrolle der Unternehmen, die sich auditieren lassen. Das Ergebnis ist für ENX-Mitglieder über das ENX-Portal abrufbar: TISAX Ergebnis anzeigen DatenschutzImpressumEnglischEnglisch (USA)Copyright 2025 Bitsea GmbH Über uns VisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungen und Lösungen Open-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcen ForschungWebinareBlogEventsLexikonJobs & Karriere Arbeiten bei BitseaJobsKontakt +49 (0) 2241 8942615 info@bitsea.de Vorführungstermin vereinbaren VisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitÜber unsÜber unsVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungenDienstleistungenOpen-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcenRessourcenForschungWebinareEventsBlog & CommunityLexikonKontaktJob & KarriereJob & KarriereArbeiten bei Bitsea Nachhaltigkeit - Bitsea Über unsDienstleistungenRessourcenKontaktJob & KarriereVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeit Über uns Nachhaltigkeit "Es ist billiger den Planeten jetzt zu schützen, als ihn später zu reparieren" -José Manuel Barosso Nachhaltiges Wirtschaften spielt für Bitsea eine wichtige Rolle: Wir legen großen Wert darauf, den ökologischen Fußabdruck, den wir durch unsere Geschäftstätigkeit hinterlassen, so gering wie möglich zu halten und die Freisetzung klimaschädlicher Co2-Emissionen zu minimieren. Für die Umsetzung unserer Klimaneutralität haben wir Folgendes schon umgesetzt: Im laufendem Betrieb und Rechenzentrum Ökostrom Einsatz von immer mehr Elektrofahrzeugen Weniger Dienstreisen, mehr Webmeetings LED Leuchtmittel Von Tonerkartuschen, Druckerpatronen und Papier Recycling Raumausstattung mit Wassersparsystemen Für ökologische und soziale Zwecke Spenden Für die Mitarbeiter Regionales Obst Mülltrennung DatenschutzImpressumEnglischEnglisch (USA)Copyright 2026 Bitsea GmbH Über uns VisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungen und Lösungen CRA GuardianOpen-Source-ManagementSoftware QualitätsanalyseRessourcen ForschungWebinareBlogEventsLexikonDatenblätterJobs & Karriere Arbeiten bei BitseaJobsKontakt +49 (0) 2241 8942615 info@bitsea.de Vorführungstermin vereinbaren VisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitÜber unsÜber unsVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungenDienstleistungenOpen-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcenRessourcenForschungWebinareEventsBlog & CommunityLexikonKontaktJob & KarriereJob & KarriereArbeiten bei Bitsea Partners - Bitsea About usServicesResourcesContactCareersVisionTimelineTisaxAssociationsPartnersSustainability About us Partners Bitsea works together with great partners: Bitsea is the exclusive services partner for Flexera/Revenera in Software Composition Analysis (SCA), delivering a full range of services including M&A audits, baseline audits, code quality and technical debt assessments, implementation, training, and other SCA-related aspects of technical due diligence. Visit Flexera Bitsea is a certified partner of Revenera and offers Audit services, installations and training. Visit Revenera Anchore provides Software Composition Analysis (SCA) for cloud-native applications. Their offering is an SBOM-powered solution that enables continuous scanning of cloud applications for security and compliance issues. Visit Anchore Privacy PolicyImprintEnglishGermanCopyright 2026 Bitsea US, Inc. About us VisionTimelineTisaxAssociationsPartnersSustainabilityServices and Solutions Open Source ManagementSoftware Quality AnalysisTechnical Project ManagementResources ResearchWebinarsBlogEventsLexiconDatasheetsCareers Life at BitseaJobsContact Us 781-784-4653 info@bitsea.us Request a demo VisionTimelineTisaxAssociationsPartnersSustainabilityAbout usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen Source ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlogLexiconContactCareersCareersLife at Bitsea Tisax - Bitsea About usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen-Source-ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlog & CommunityLexiconContactCareerCareerLife at BitseaVisionTimelineTisaxAssociationsPartnersSustainability About us Bitsea is TISAX certified. The result is available for ENX members via the ENX portal: Retrieve TISAX result We have taken extensive measures on protection of sensitive information. Therefore, we follow the question catalogue of information security of the German Association of the Automotive Industry (VDA ISA). The Assessment was conducted in 2019/2020 by TÜV Rheinland and confirmed in 2025.The ENX Association supports with TISAX (Trusted Information Security Assessment Exchange) on behalf of VDA the common acceptance of Information Security Assessments in the automotive industry. The TISAX Assessments are conducted by accredited audit providers that demonstrate their qualification at regular intervals. TISAX and TISAX results are not intended for general public. TISAX is based on the norm ISO / IEC 27001. TISAX (Trusted Information Security Assessment Exchange) serves company-wide acknowledgement of information security assessments in the automotive industry and provides a common test and exchange mechanism. The results always remain under control of those enterprises which let themselves being audited. The result is available for ENX members via the ENX portal: Retrieve TISAX result  Privacy PolicyImprintGermanEnglish (USA)Copyright 2025 Bitsea GmbH About us VisionTimelineTisaxAssociationsPartnersSustainabilityServices and Solutions Open-Source-ManagementSoftware Quality AnalysisTechnical Project ManagementResources ResearchWebinarsBlog & CommunityEventsLexiconCareer JobsContact Us +49 (0) 2241 8942615 info@bitsea.de Request a demo VisionTimelineTisaxAssociationsPartnersSustainabilityAbout usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen-Source-ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlog & CommunityLexiconContactCareerCareerLife at Bitsea Partners - Bitsea About usServicesResourcesContactCareersVisionTimelineTisaxAssociationsPartnersSustainability About us Partners Bitsea works together with great partners: Bitsea is the exclusive services partner for Flexera/Revenera in Software Composition Analysis (SCA), delivering a full range of services including M&A audits, baseline audits, code quality and technical debt assessments, implementation, training, and other SCA-related aspects of technical due diligence. Visit Flexera Bitsea is a certified partner of Revenera and offers Audit services, installations and training. Visit Revenera Anchore provides Software Composition Analysis (SCA) for cloud-native applications. Their offering is an SBOM-powered solution that enables continuous scanning of cloud applications for security and compliance issues. Visit Anchore Privacy PolicyImprintEnglishGermanCopyright 2026 Bitsea US, Inc. About us VisionTimelineTisaxAssociationsPartnersSustainabilityServices and Solutions Open Source ManagementSoftware Quality AnalysisResources ResearchWebinarsBlogEventsLexiconDatasheetsCareers Life at BitseaJobsContact Us +1-510-593-6757 info@bitsea.us Request a demo VisionTimelineTisaxAssociationsPartnersSustainabilityAbout usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen Source ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlogLexiconContactCareersCareersLife at Bitsea Sustainability - Bitsea About usServicesResourcesContactCareersVisionTimelineTisaxAssociationsPartnersSustainability About us Sustainability "It's cheaper to protect the planet now than to fix it later"-José Manuel Barosso Sustainable business plays an important role for Bitsea: We put great importance to keeping the ecological footprint left by our business activities as small as possible andto minimize the release of climate-damaging Co2 emissions. For the implementation of our climate neutrality, we have already implemented the following: In running operation and data center with green electricity Use of more and more electric cars Fewer business trips, more webmeetings LED illuminants of toner cartridges, printer cartridges and paper Recycling Room equipment with water saving systems for ecological and social purposes Donations for the employees Regional fruits Garbage separation Privacy PolicyImprintEnglishGermanCopyright 2026 Bitsea US, Inc. About us VisionTimelineTisaxAssociationsPartnersSustainabilityServices and Solutions Open Source ManagementSoftware Quality AnalysisResources ResearchWebinarsBlogEventsLexiconDatasheetsCareers Life at BitseaJobsContact Us +1-510-593-6757 info@bitsea.us Request a demo VisionTimelineTisaxAssociationsPartnersSustainabilityAbout usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen Source ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlogLexiconContactCareersCareersLife at Bitsea Nachhaltigkeit - Bitsea Über unsDienstleistungenRessourcenKontaktJob & KarriereVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeit Über uns Nachhaltigkeit "Es ist billiger den Planeten jetzt zu schützen, als ihn später zu reparieren" -José Manuel Barosso Nachhaltiges Wirtschaften spielt für Bitsea eine wichtige Rolle: Wir legen großen Wert darauf, den ökologischen Fußabdruck, den wir durch unsere Geschäftstätigkeit hinterlassen, so gering wie möglich zu halten und die Freisetzung klimaschädlicher Co2-Emissionen zu minimieren. Für die Umsetzung unserer Klimaneutralität haben wir Folgendes schon umgesetzt: Im laufendem Betrieb und Rechenzentrum Ökostrom Einsatz von immer mehr Elektrofahrzeugen Weniger Dienstreisen, mehr Webmeetings LED Leuchtmittel Von Tonerkartuschen, Druckerpatronen und Papier Recycling Raumausstattung mit Wassersparsystemen Für ökologische und soziale Zwecke Spenden Für die Mitarbeiter Regionales Obst Mülltrennung DatenschutzImpressumEnglischEnglisch (USA)Copyright 2026 Bitsea GmbH Über uns VisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungen und Lösungen CRA GuardianOpen-Source-ManagementSoftware QualitätsanalyseRessourcen ForschungWebinareBlogEventsLexikonDatenblätterJobs & Karriere Arbeiten bei BitseaJobsKontakt +49 (0) 2241 8942615 info@bitsea.de Vorführungstermin vereinbaren VisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitÜber unsÜber unsVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungenDienstleistungenOpen-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcenRessourcenForschungWebinareEventsBlog & CommunityLexikonKontaktJob & KarriereJob & KarriereArbeiten bei Bitsea Job & Karriere - Bitsea Über unsDienstleistungenRessourcenKontaktJob & KarriereArbeiten bei BitseaJobs Jobs & Karriere Das Leben bei Bitsea Mehr erfahrenJobs Die meisten Branchen sind heute von IT-Systemen abhängig. Die rasanten Fortschritte in der Softwareentwicklung und -technologie erfordern ausgefeilte und komplexe Entwicklungsprozesse, um mit dem Markt Schritt zu halten. Bitsea ist ein 2008 gegründetes High-Tech-Start-up mit Sitz in Sankt Augustin. Wir analysieren, bewerten und optimieren Software-Entwicklungsprozesse, Software-Architektur und Software-Design und sichern so langfristig die Zukunftsfähigkeit von Software-Produkten. Für viele Top-Unternehmen aus den Bereichen Automotive, Kommunikation, Logistik, Handel und Luft- und Raumfahrt führen wir technische Due Diligence-Prüfungen zur Vorbereitung von Unternehmensübernahmen und im Rahmen von Einkaufsprozessen durch. Wir prüfen die Konformität von Software in Bezug auf Lizenz- und Sicherheitsaudits von Open-Source-Software.Zur Verstärkung und zum weiteren Ausbau unseres Beraterteams an unserem Hauptsitz in Sankt Augustin bei Köln suchen wir: Open Source Compliance Auditor Mehr erfahrenSenior Software Architekten Mehr erfahren DatenschutzImpressumEnglischEnglisch (USA)Copyright 2026 Bitsea GmbH Über uns VisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungen und Lösungen CRA GuardianOpen-Source-ManagementSoftware QualitätsanalyseRessourcen ForschungWebinareBlogEventsLexikonDatenblätterJobs & Karriere Arbeiten bei BitseaJobsKontakt +49 (0) 2241 8942615 info@bitsea.de Vorführungstermin vereinbaren Arbeiten bei BitseaJobsÜber unsÜber unsVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungenDienstleistungenOpen-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcenRessourcenForschungWebinareEventsBlog & CommunityLexikonKontaktJob & KarriereJob & KarriereArbeiten bei Bitsea Resources - Bitsea About usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityDienstleistungenDienstleistungenOpen Source ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlogLexiconContactCareersCareersLife at BitseaResearchWebinarsBlogEventsLexicon Resources We analyze, evaluate and optimize your development processes, software architecture and software design. We take on the technical due diligence associated with internal audits and M&A transactions. Research Read moreWebinars Read moreEvents Read moreBlog & Community Read moreLexikon Mehr erfahren Privacy PolicyImprintEnglishGermanCopyright 2025 Bitsea GmbH About us VisionTimelineTisaxAssociationsPartnersSustainabilityServices and Solutions Open Source ManagementSoftware Quality AnalysisTechnical Project ManagementResources ResearchWebinarsBlogEventsLexiconCareers Life at BitseaJobsContact Us +49 (0) 2241 8942615 info@bitsea.de Request a demo ResearchWebinarsBlogEventsLexiconAbout usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen Source ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlogLexiconContactCareersCareersLife at Bitsea Über uns - Bitsea Über unsÜber unsVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungenDienstleistungenOpen-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcenRessourcenForschungWebinareEventsBlog & CommunityLexikonKontaktJob & KarriereJob & KarriereArbeiten bei BitseaVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeit Über uns Vision Die Wahrheit liegt im Quellcode. Große Softwaresysteme sind wie ein wilder, weiter Ozean von Bits und Bytes - unsere Leidenschaft ist die Analyse und Visualisierung von Softwarestrukturen. Wir helfen unseren Kunden ihre Systeme zu verstehen, zu stabilisieren und zu optimieren. Mehr erfahrenUnsere Geschichte 2008: Entwicklung einer Methodik, um schnell die Wartbarkeit eines Softwaresystems nach ISO 25010 zu bewerten. Mehr erfahrenTisax Bitsea ist TISAX-zertifiziert. Vertraulichkeit, Verfügbarkeit und Integrität von Informationen haben für Bitsea einen großen Wert. Wir haben umfangreiche Maßnahmen zum Schutz sensibler Informationen ergriffen. Deshalb folgen wir dem Fragenkatalog zur Informationssicherheit des Verbandes der Automobilindustrie (VDA ISA). Mehr erfahrenVerbände Bitsea ist Mitglied der Open Source-Arbeitsgruppe und beteiligt sich am OpenChain-Projekt. Mehr erfahrenPartner Bitsea arbeitet intensiv mit folgenden Partnern zusammen: Revenera, Softwareallianz Deutschland, Impac, Softscheck und OSS Engineering Consultants Mehr erfahrenNachhaltigkeit Nachhaltiges Wirtschaften spielt für Bitsea eine wichtige Rolle: Wir legen großen Wert darauf, den ökologischen Fußabdruck, den wir durch unsere Gechäftstätigkeit hinterlassen, so gering wie möglich zu halten. Mehr erfahren DatenschutzImpressumEnglischEnglisch (USA)Copyright 2025 Bitsea GmbH Über uns VisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungen und Lösungen Open-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcen ForschungWebinareBlogEventsLexikonJobs & Karriere Arbeiten bei BitseaJobsKontakt +49 (0) 2241 8942615 info@bitsea.de Vorführungstermin vereinbaren VisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitÜber unsÜber unsVisionUnsere GeschichteTisaxVerbändePartnerNachhaltigkeitDienstleistungenDienstleistungenOpen-Source-ManagementSoftware QualitätsanalyseTechnisches ProjektmanagementRessourcenRessourcenForschungWebinareEventsBlog & CommunityLexikonKontaktJob & KarriereJob & KarriereArbeiten bei Bitsea About us - Bitsea About usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen-Source-ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlog & CommunityLexiconContactCareerCareerLife at BitseaVisionTimelineTisaxAssociationsPartnersSustainability About us Our vision The truth is in the source code. Big software systems are like a wild wide ocean of bits - our passion is to analyze and visualize software structure. We are keen to help our customers stabilize and optimize their systems. Read moreTimeline Development of a methodology to quickly improve the maintainability of a software system according to ISO 25010 Read moreTisax Bitsea is TISAX certified. Confidentiality, availability and integrity of information have great value for Bitsea. We have taken extensive measures on protection of sensitive information. Therefore, we follow the question catalogue of information security of the German Association of the Automotive industry (VDA ISA). Read moreAssociations Bitsea is a member of Open Source Working Group and participates in the OpenChain Project. Read morePartners Bitsea closely cooperates with the following partners: Revenera, Softwareallianz Deutschland, Impac, Softscheck and OSS Engineering Consultants. Read moreSustainability Sustainable business plays an important role for Bitsea: We put great importance to keeping the ecological footprint left by our business activities as small as possible. Read more Privacy PolicyImprintGermanEnglish (USA)Copyright 2025 Bitsea GmbH About us VisionTimelineTisaxAssociationsPartnersSustainabilityServices and Solutions Open-Source-ManagementSoftware Quality AnalysisTechnical Project ManagementResources ResearchWebinarsBlog & CommunityEventsLexiconCareer JobsContact Us +49 (0) 2241 8942615 info@bitsea.de Request a demo VisionTimelineTisaxAssociationsPartnersSustainabilityAbout usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen-Source-ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlog & CommunityLexiconContactCareerCareerLife at Bitsea Contact - Bitsea About usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen-Source-ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlog & CommunityLexiconContactCareerCareerLife at Bitsea Contact us Do you have any questions or are you interested in our services? Please use below contact form for any enquiries or give us a call. Select subject area: Comprehensive open source analysisSoftware-quality analysisTechnical project managementSoftware developmentTrainingData protectionOther Accept data protection references Please leave this field empty. Our Location Show on Google MapsBitsea GmbH Schlossstraße 7 53757 Sankt Augustin +49 (0) 2241 894 2615 hello@bitsea.de How to reach us by plane From the airport Cologne/Bonn, take the S-Bahn S19 on platform 4 to Siegburg/Bonn. From there, take the bus 512 or 513 on bus platform 3 to Birlinghoven Pleistalstraße.Another possibility is to take the S-Bahn S19 to Hennef (Sieg), from there take the bus 516 on bus platform A to Biringhoven Pleistalstraße.Be aware: There are two bus stops at the Pleistalstraße, the second bus stop is the right one. The total travel time is about 50 to 60 minutes depending on the connection and the traffic.Another alternative is driving by taxi from the airport to Birlinghoven, duration approx. 25 minutes, costs approx. 50 euros.We wish you a good journey! How to reach us by car From the South or North: A3 to crossroad Bonn/Siegburg, A560 towards Bonn. Exit Niederpleis (exit 4), take the first circle in Niederpleis towards Birlinghoven. In Birlinghoven, turn right into the Schlossstraße and turn right immediately afterwards, into our driveway.From the West: A4/A59 to A560, towards Frankfurt. Exit Niederpleis (exit 4), take the first circle in Niederpleis towards Birlinghoven. In Birlinghoven, turn right into the Schlossstraße and turn right immediately afterwards, into our driveway.You will find parking spaces behind the house.We wish you a good journey! How to reach us by public transportation Via Cologne or Siegen, take the train RE9, S12 or S19 to Siegburg/Bonn. From there, take the bus 512 or 513 on bus platform 3 to Birlinghoven Pleistalstraße.Another possibility is to take the S-Bahn S19 to Hennef (Sieg), from there take the bus 516 on bus platform A to Birlinghoven Pleistalstraße.Be aware: There are two bus stops at the Pleistalstraße, the second bus stop is the right one. The total travel time is about 50 to 60 minutes depending on the connection and the traffic.Via Bonn, take the tram 66. You can switch to the 516 to Hennef in Vilich-Müldorf or to the 535 to Oberpleis in St. Augustin Zentrum or go to Siegburg and go on as described above.We wish you a good journey! Privacy PolicyImprintGermanEnglish (USA)Copyright 2025 Bitsea GmbH About us VisionTimelineTisaxAssociationsPartnersSustainabilityServices and Solutions Open-Source-ManagementSoftware Quality AnalysisTechnical Project ManagementResources ResearchWebinarsBlog & CommunityEventsLexiconCareer JobsContact Us +49 (0) 2241 8942615 info@bitsea.de Request a demo About usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen-Source-ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlog & CommunityLexiconContactCareerCareerLife at Bitsea Contact - Bitsea About usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen-Source-ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlog & CommunityLexiconContactCareerCareerLife at Bitsea Contact us Do you have any questions or are you interested in our services? Please use below contact form for any enquiries or give us a call. Select subject area: Comprehensive open source analysisSoftware-quality analysisTechnical project managementSoftware developmentTrainingData protectionOther Accept data protection references Please leave this field empty. Our Location Show on Google MapsBitsea GmbH Schlossstraße 7 53757 Sankt Augustin +49 (0) 2241 894 2615 hello@bitsea.de How to reach us by plane From the airport Cologne/Bonn, take the S-Bahn S19 on platform 4 to Siegburg/Bonn. From there, take the bus 512 or 513 on bus platform 3 to Birlinghoven Pleistalstraße.Another possibility is to take the S-Bahn S19 to Hennef (Sieg), from there take the bus 516 on bus platform A to Biringhoven Pleistalstraße.Be aware: There are two bus stops at the Pleistalstraße, the second bus stop is the right one. The total travel time is about 50 to 60 minutes depending on the connection and the traffic.Another alternative is driving by taxi from the airport to Birlinghoven, duration approx. 25 minutes, costs approx. 50 euros.We wish you a good journey! How to reach us by car From the South or North: A3 to crossroad Bonn/Siegburg, A560 towards Bonn. Exit Niederpleis (exit 4), take the first circle in Niederpleis towards Birlinghoven. In Birlinghoven, turn right into the Schlossstraße and turn right immediately afterwards, into our driveway.From the West: A4/A59 to A560, towards Frankfurt. Exit Niederpleis (exit 4), take the first circle in Niederpleis towards Birlinghoven. In Birlinghoven, turn right into the Schlossstraße and turn right immediately afterwards, into our driveway.You will find parking spaces behind the house.We wish you a good journey! How to reach us by public transportation Via Cologne or Siegen, take the train RE9, S12 or S19 to Siegburg/Bonn. From there, take the bus 512 or 513 on bus platform 3 to Birlinghoven Pleistalstraße.Another possibility is to take the S-Bahn S19 to Hennef (Sieg), from there take the bus 516 on bus platform A to Birlinghoven Pleistalstraße.Be aware: There are two bus stops at the Pleistalstraße, the second bus stop is the right one. The total travel time is about 50 to 60 minutes depending on the connection and the traffic.Via Bonn, take the tram 66. You can switch to the 516 to Hennef in Vilich-Müldorf or to the 535 to Oberpleis in St. Augustin Zentrum or go to Siegburg and go on as described above.We wish you a good journey! Privacy PolicyImprintGermanEnglish (USA)Copyright 2025 Bitsea GmbH About us VisionTimelineTisaxAssociationsPartnersSustainabilityServices and Solutions Open-Source-ManagementSoftware Quality AnalysisTechnical Project ManagementResources ResearchWebinarsBlog & CommunityEventsLexiconCareer JobsContact Us +49 (0) 2241 8942615 info@bitsea.de Request a demo About usAbout usVisionTimelineTisaxAssociationsPartnersSustainabilityServicesServicesOpen-Source-ManagementSoftware Quality AnalysisTechnical Project ManagementResourcesResourcesResearchWebinarsEventsBlog & CommunityLexiconContactCareerCareerLife at Bitsea ## Beiträge OpenChain CRA Anforderungen & Checkliste: So wird die Umsetzung des Cyber Resilience Acts greifbar Der europäische Cyber Resilience Act (CRA) verändert grundlegend, wie Hersteller und Softwareanbieter das Thema Cybersicherheit angehen. Während die Verordnung klar definiert, was Unternehmen erreichen müssen, stellen sich viele noch immer dieselbe Frage: Wie setzen wir diese Anforderungen in der Praxis um? Genau hier setzt das OpenChain CRA Requirement & Checklist an. Wir bei der Bitsea GmbH sind stolz darauf, an dieser gemeinschaftlich entwickelten Initiative mitgewirkt zu haben. Gemeinsam mit Expertinnen und Experten aus der Industrie und dem Open-Source-Umfeld haben wir dazu beigetragen, eine praxisnahe Checkliste zu entwickeln, die Unternehmen auf ihrem Weg zur CRA-Compliance unterstützt. Warum das OpenChain CRA Requirement & Checklist wichtig ist Den Cyber Resilience Act zu lesen ist das eine. Seine Anforderungen jedoch über Entwicklungsteams, Produktmanagement, Rechtsabteilungen, Security-Teams und Lieferketten hinweg umzusetzen, ist eine ganz andere Herausforderung. Das OpenChain CRA Requirement & Checklist schließt genau diese Lücke, indem es regulatorische Anforderungen in verständliche und praxisorientierte Maßnahmen übersetzt. Es ersetzt die Verordnung nicht, sondern dient als Implementierungsleitfaden, der Unternehmen dabei unterstützt, ihren aktuellen Reifegrad zu bewerten, fehlende Prozesse zu identifizieren und die nächsten Schritte auf dem Weg zur Compliance festzulegen. Für Unternehmen, die Produkte mit digitalen Elementen entwickeln, bietet die Checkliste einen wertvollen Ausgangspunkt für den Aufbau eines strukturierten und nachhaltigen CRA-Compliance-Programms. Mehr als nur eine Checkliste Eine der größten Stärken des OpenChain Projects war schon immer die Fähigkeit, komplexe Compliance-Themen in praxisnahe Handlungsempfehlungen zu übersetzen. Die CRA-Checkliste folgt genau diesem Ansatz. Sie deckt unter anderem folgende Themenbereiche ab: Governance für Produktsicherheit Sichere Softwareentwicklungsprozesse Schwachstellenmanagement Open-Source-Governance Dokumentationsanforderungen Anforderungen an die Software-Lieferkette Nachweisführung und Rückverfolgbarkeit Anstatt sich ausschließlich auf die rechtliche Interpretation zu konzentrieren, hilft die Checkliste Unternehmen dabei, die operativen Maßnahmen zu verstehen, die für eine CRA-konforme Softwareentwicklung über den gesamten Software-Lebenszyklus hinweg erforderlich sind. Von Anforderungen zur praktischen Umsetzung Eine Checkliste schafft Orientierung – für die tatsächliche Umsetzung benötigen Unternehmen jedoch geeignete Werkzeuge und etablierte Prozesse. Eine wertvolle Ressource in diesem Zusammenhang ist OCCTET, verfügbar unter occtet. eu. OCCTET stellt eine praxisorientierte Open-Source-Toolchain bereit, die Unternehmen bei der Umsetzung der Anforderungen des Cyber Resilience Acts unterstützt. Sie ermöglicht unter anderem den Einsatz von Open-Source-Werkzeugen für Transparenz über Software-Komponenten, Schwachstellenmanagement, Compliance-Nachweise sowie sichere Softwareentwicklungsprozesse. Damit bietet OCCTET einen hervorragenden Einstieg für Unternehmen, die eine Open-Source-basierte Toolchain zur Umsetzung der CRA-Anforderungen evaluieren oder aufbauen möchten. Für Unternehmen, die eine integrierte, professionell unterstützte und skalierbare kommerzielle Lösung benötigen, bietet Bitsea Curator Pro an. Curator Pro unterstützt Unternehmen beim Management von Software Composition, SBOMs, Schwachstellen, Open-Source-Compliance sowie den dazugehörigen Nachweisen über Produkte und Software-Lieferketten hinweg. Durch die Kombination aus automatisierter Analyse, strukturierten Workflows und zentral verwalteten Compliance-Daten unterstützt Curator Pro Unternehmen dabei, wiederholbare und auditierbare CRA-Compliance-Prozesse zu etablieren. Die Lösung eignet sich insbesondere für Unternehmen, die professionellen Support, flexible Bereitstellungsoptionen und eine nahtlose Integration in bestehende Entwicklungs- und Governance-Landschaften benötigen. Gemeinsam bieten das OpenChain CRA Requirement & Checklist, die OCCTET Open-Source-Toolchain und professionelle Lösungen wie Curator Pro unterschiedliche, sich ergänzende Möglichkeiten, regulatorische Anforderungen in konkrete Maßnahmen umzusetzen.... OpenChain CRA Requirement & Checklist: Turning Cyber Resilience Act Compliance into Action The European Cyber Resilience Act (CRA) is transforming the way manufacturers and software providers approach cybersecurity. While the regulation defines what organizations must achieve, many companies are still asking the same question: How do we actually implement these requirements in practice? This is exactly where the OpenChain CRA Requirement & Checklist comes in. At Bitsea GmbH, we are proud to have contributed to this community-driven initiative. Working alongside experts from industry and the open source ecosystem, we helped shape a practical checklist designed to support organizations on their journey towards CRA compliance. Why the OpenChain CRA Requirement & Checklist Matters Reading the Cyber Resilience Act is one thing. Implementing it across development teams, product management, legal departments, security teams, and supply chain partners is something entirely different. The OpenChain CRA Requirement & Checklist bridges this gap by translating regulatory expectations into practical and understandable requirements. Rather than replacing the regulation, it serves as an implementation guide that helps organizations assess their readiness, identify missing processes, and define the next steps towards compliance. For companies developing products with digital elements, it provides a valuable starting point for establishing a structured and sustainable CRA compliance program. More Than Just a Checklist One of the strengths of the OpenChain Project has always been its ability to turn complex compliance topics into practical guidance. The CRA checklist follows the same philosophy. It covers key areas including: Product cybersecurity governance Secure software development processes Vulnerability management Open source software governance Documentation requirements Supply chain considerations Compliance evidence and traceability Instead of focusing solely on legal interpretation, the checklist helps organizations understand the operational activities needed to support compliance throughout the entire software lifecycle. From Requirements to Practical Implementation A checklist provides orientation, but organizations also need practical tools and processes to implement the requirements in their daily engineering environments. A valuable resource in this context is OCCTET, available at occtet. eu. OCCTET provides a practical open source toolchain designed to help companies address CRA-related obligations. It enables organizations to explore how open source tools can support activities such as software component transparency, vulnerability management, compliance evidence, and secure software lifecycle processes. This makes OCCTET a useful starting point for organizations that want to evaluate and build their own open source-based CRA compliance toolchain. For companies that require an integrated, professionally supported, and scalable commercial solution, Bitsea offers Curator Pro. Curator Pro supports organizations in managing software composition, SBOMs, vulnerabilities, open source compliance, and the associated evidence across products and software supply chains. By combining automated analysis, structured workflows, and centralized compliance data, Curator Pro helps organizations implement repeatable, auditable CRA compliance processes. It is ideal for enterprises requiring professional support, flexible deployment, and seamless integration into existing development and governance environments. Together, the OpenChain checklist, the OCCTET open source toolchain, and professional solutions such as Curator Pro provide organizations with different but complementary ways to move from regulatory requirements to practical implementation. Community... OpenChain CRA Requirement & Checklist: Turning Cyber Resilience Act Compliance into Action The European Cyber Resilience Act (CRA) is transforming the way manufacturers and software providers approach cybersecurity. While the regulation defines what organizations must achieve, many companies are still asking the same question: How do we actually implement these requirements in practice? This is exactly where the OpenChain CRA Requirement & Checklist comes in. At Bitsea GmbH, we are proud to have contributed to this community-driven initiative. Working alongside experts from industry and the open source ecosystem, we helped shape a practical checklist designed to support organizations on their journey towards CRA compliance. Why the OpenChain CRA Requirement & Checklist Matters Reading the Cyber Resilience Act is one thing. Implementing it across development teams, product management, legal departments, security teams, and supply chain partners is something entirely different. The OpenChain CRA Requirement & Checklist bridges this gap by translating regulatory expectations into practical and understandable requirements. Rather than replacing the regulation, it serves as an implementation guide that helps organizations assess their readiness, identify missing processes, and define the next steps towards compliance. For companies developing products with digital elements, it provides a valuable starting point for establishing a structured and sustainable CRA compliance program. More Than Just a Checklist One of the strengths of the OpenChain Project has always been its ability to turn complex compliance topics into practical guidance. The CRA checklist follows the same philosophy. It covers key areas including: Product cybersecurity governance Secure software development processes Vulnerability management Open source software governance Documentation requirements Supply chain considerations Compliance evidence and traceability Instead of focusing solely on legal interpretation, the checklist helps organizations understand the operational activities needed to support compliance throughout the entire software lifecycle. From Requirements to Practical Implementation A checklist provides orientation, but organizations also need practical tools and processes to implement the requirements in their daily engineering environments. A valuable resource in this context is OCCTET, available at occtet. eu. OCCTET provides a practical open source toolchain designed to help companies address CRA-related obligations. It enables organizations to explore how open source tools can support activities such as software component transparency, vulnerability management, compliance evidence, and secure software lifecycle processes. This makes OCCTET a useful starting point for organizations that want to evaluate and build their own open source-based CRA compliance toolchain. For companies that require an integrated, professionally supported, and scalable commercial solution, Bitsea offers Curator Pro. Curator Pro supports organizations in managing software composition, SBOMs, vulnerabilities, open source compliance, and the associated evidence across products and software supply chains. By combining automated analysis, structured workflows, and centralized compliance data, Curator Pro helps organizations implement repeatable, auditable CRA compliance processes. It is ideal for enterprises requiring professional support, flexible deployment, and seamless integration into existing development and governance environments. Together, the OpenChain checklist, the OCCTET open source toolchain, and professional solutions such as Curator Pro provide organizations with different but complementary ways to move from regulatory requirements to practical implementation. Community... How the new SBOM standard is transforming software supply chain management and why it is critical for your CRA compliance Bitsea GmbH · July 2026 · Reading time: approx. 8 minutes Introduction: A Standard in Transition The Software Bill of Materials (SBOM) has evolved from a niche topic into a regulatory requirement over the past few years. With the EU Cyber Resilience Act (CRA), a machine-readable software inventory is becoming a prerequisite for bringing products with digital elements to the European market. Organizations that develop, distribute, or integrate software can no longer ignore SBOM requirements. At the same time, the most important SBOM standard continues to evolve: SPDX (System Package Data Exchange), maintained under the umbrella of the Linux Foundation and internationally recognized as ISO/IEC 5962, is taking its next major step forward with version 3. 1. The first Release Candidate (SPDX 3. 1-RC1) was published at the end of January 2026, with the final release expected later this year. At Bitsea, we have closely followed the development of SPDX 3. x from the beginning — and we have continuously aligned Curator Pro, our platform for SBOM management, license compliance, and vulnerability management, with the new data model. In this article, we explain what SPDX 3. 1 brings to the table, what it means for organizations in practice, and how Curator Pro helps you navigate this transition with confidence. From Documents to Knowledge Graphs: What SPDX 3. x Changes at Its Core To understand where SPDX 3. 1 is heading, it is worth taking a brief look back. SPDX 2. x — still the most widely used version in practice today — is built around a document-centric approach: an SPDX document acts as a self-contained “envelope” describing a collection of packages, files, and snippets. This works well for the traditional use case of “one SBOM per release”, but it reaches its limits when information from multiple sources needs to be combined, tracked across different versions, or referenced at a more granular level. SPDX 3. 0 (released in April 2024) fundamentally redesigned this architecture. The new model is element-based: every element — whether a package, file, vulnerability, person, or organization — exists independently, carries a globally unique identifier, and is connected to other elements through typed relationships. A flat software inventory becomes a knowledge graph. The model is further enhanced through profiles that organize the data model around specific use cases: Core, Software, Licensing, Security, Build, AI, Dataset, and Lite. SPDX 3. 1 continues this evolution and significantly expands the standard beyond software alone. The Key New Features in SPDX 3. 1 The SPDX 3. 1 Release Candidate (3. 1-RC1) clearly shows the direction of travel: SPDX is evolving into a universal BOM standard for entire systems. The major enhancements include: Hardware Profile (HBOM): For the first time, SPDX 3. 1 can natively describe hardware components. For manufacturers of embedded systems, IoT devices, and products with digital elements — precisely the target group addressed by the Cyber Resilience Act (CRA) —... How the new SBOM standard is transforming software supply chain management and why it is critical for your CRA compliance Bitsea GmbH · July 2026 · Reading time: approx. 8 minutes Introduction: A Standard in Transition The Software Bill of Materials (SBOM) has evolved from a niche topic into a regulatory requirement over the past few years. With the EU Cyber Resilience Act (CRA), a machine-readable software inventory is becoming a prerequisite for bringing products with digital elements to the European market. Organizations that develop, distribute, or integrate software can no longer ignore SBOM requirements. At the same time, the most important SBOM standard continues to evolve: SPDX (System Package Data Exchange), maintained under the umbrella of the Linux Foundation and internationally recognized as ISO/IEC 5962, is taking its next major step forward with version 3. 1. The first Release Candidate (SPDX 3. 1-RC1) was published at the end of January 2026, with the final release expected later this year. At Bitsea, we have closely followed the development of SPDX 3. x from the beginning — and we have continuously aligned Curator Pro, our platform for SBOM management, license compliance, and vulnerability management, with the new data model. In this article, we explain what SPDX 3. 1 brings to the table, what it means for organizations in practice, and how Curator Pro helps you navigate this transition with confidence. From Documents to Knowledge Graphs: What SPDX 3. x Changes at Its Core To understand where SPDX 3. 1 is heading, it is worth taking a brief look back. SPDX 2. x — still the most widely used version in practice today — is built around a document-centric approach: an SPDX document acts as a self-contained “envelope” describing a collection of packages, files, and snippets. This works well for the traditional use case of “one SBOM per release”, but it reaches its limits when information from multiple sources needs to be combined, tracked across different versions, or referenced at a more granular level. SPDX 3. 0 (released in April 2024) fundamentally redesigned this architecture. The new model is element-based: every element — whether a package, file, vulnerability, person, or organization — exists independently, carries a globally unique identifier, and is connected to other elements through typed relationships. A flat software inventory becomes a knowledge graph. The model is further enhanced through profiles that organize the data model around specific use cases: Core, Software, Licensing, Security, Build, AI, Dataset, and Lite. SPDX 3. 1 continues this evolution and significantly expands the standard beyond software alone. The Key New Features in SPDX 3. 1 The SPDX 3. 1 Release Candidate (3. 1-RC1) clearly shows the direction of travel: SPDX is evolving into a universal BOM standard for entire systems. The major enhancements include: Hardware Profile (HBOM): For the first time, SPDX 3. 1 can natively describe hardware components. For manufacturers of embedded systems, IoT devices, and products with digital elements — precisely the target group addressed by the Cyber Resilience Act (CRA) —... How the new SBOM standard is transforming software supply chain management and why it is critical for your CRA compliance Bitsea GmbH · July 2026 · Reading time: approx. 8 minutes Introduction: A Standard in Transition The Software Bill of Materials (SBOM) has evolved from a niche topic into a regulatory requirement over the past few years. With the EU Cyber Resilience Act (CRA), a machine-readable software inventory is becoming a prerequisite for bringing products with digital elements to the European market. Organizations that develop, distribute, or integrate software can no longer ignore SBOM requirements. At the same time, the most important SBOM standard continues to evolve: SPDX (System Package Data Exchange), maintained under the umbrella of the Linux Foundation and internationally recognized as ISO/IEC 5962, is taking its next major step forward with version 3. 1. The first Release Candidate (SPDX 3. 1-RC1) was published at the end of January 2026, with the final release expected later this year. At Bitsea, we have closely followed the development of SPDX 3. x from the beginning — and we have continuously aligned Curator Pro, our platform for SBOM management, license compliance, and vulnerability management, with the new data model. In this article, we explain what SPDX 3. 1 brings to the table, what it means for organizations in practice, and how Curator Pro helps you navigate this transition with confidence. From Documents to Knowledge Graphs: What SPDX 3. x Changes at Its Core To understand where SPDX 3. 1 is heading, it is worth taking a brief look back. SPDX 2. x — still the most widely used version in practice today — is built around a document-centric approach: an SPDX document acts as a self-contained “envelope” describing a collection of packages, files, and snippets. This works well for the traditional use case of “one SBOM per release”, but it reaches its limits when information from multiple sources needs to be combined, tracked across different versions, or referenced at a more granular level. SPDX 3. 0 (released in April 2024) fundamentally redesigned this architecture. The new model is element-based: every element — whether a package, file, vulnerability, person, or organization — exists independently, carries a globally unique identifier, and is connected to other elements through typed relationships. A flat software inventory becomes a knowledge graph. The model is further enhanced through profiles that organize the data model around specific use cases: Core, Software, Licensing, Security, Build, AI, Dataset, and Lite. SPDX 3. 1 continues this evolution and significantly expands the standard beyond software alone. The Key New Features in SPDX 3. 1 The SPDX 3. 1 Release Candidate (3. 1-RC1) clearly shows the direction of travel: SPDX is evolving into a universal BOM standard for entire systems. The major enhancements include: Hardware Profile (HBOM): For the first time, SPDX 3. 1 can natively describe hardware components. For manufacturers of embedded systems, IoT devices, and products with digital elements — precisely the target group addressed by the Cyber Resilience Act (CRA) —... Wie der neue SBOM-Standard das Software-Lieferketten-Management verändert und warum das für Ihre CRA-Compliance entscheidend ist. Bitsea GmbH · Juli 2026 · Lesezeit: ca. 8 Minuten Einleitung: Ein Standard im Umbruch Die Software Bill of Materials (SBOM) hat sich in den letzten Jahren vom Nischenthema zur regulatorischen Pflicht entwickelt. Mit dem EU Cyber Resilience Act (CRA) wird die maschinenlesbare Stückliste für Software zur Voraussetzung, um Produkte mit digitalen Elementen überhaupt noch auf den europäischen Markt bringen zu dürfen. Wer heute Software herstellt, vertreibt oder integriert, kommt an SBOMs nicht mehr vorbei. Parallel dazu entwickelt sich der wichtigste SBOM-Standard weiter: SPDX (System Package Data Exchange), gepflegt unter dem Dach der Linux Foundation und als ISO/IEC 5962 international anerkannt, steht mit Version 3. 1 vor dem nächsten großen Schritt. Ende Januar 2026 wurde der erste Release Candidate (3. 1-RC1) veröffentlicht. Die finale Version wird im Laufe des Jahres erwartet. Bei Bitsea haben wir die Entwicklung von SPDX 3. x von Anfang an eng verfolgt – und Curator Pro, unsere Plattform für SBOM-Management, Lizenz-Compliance und Schwachstellenmanagement, konsequent auf das neue Datenmodell ausgerichtet. In diesem Artikel erklären wir, was SPDX 3. 1 bringt, was das für Unternehmen konkret bedeutet und wie Curator Pro Sie dabei unterstützt, den Übergang souverän zu meistern. Vom Dokument zum Wissensgraphen: Was SPDX 3. x grundlegend ändert Um SPDX 3. 1 einzuordnen, lohnt ein kurzer Blick zurück. SPDX 2. x – noch immer die im Feld am weitesten verbreitete Version – ist dokumentenzentriert aufgebaut: Ein SPDX-Dokument beschreibt als geschlossener "Umschlag" eine Menge von Paketen, Dateien und Snippets. Das funktioniert gut für den klassischen Anwendungsfall "eine SBOM pro Release", stößt aber an Grenzen, sobald Informationen aus verschiedenen Quellen zusammengeführt, über Versionen hinweg verfolgt oder granular referenziert werden sollen. SPDX 3. 0 (April 2024) hat diese Architektur grundlegend umgebaut. Das neue Modell ist elementbasiert: Jedes Element – ob Paket, Datei, Schwachstelle, Person oder Organisation – existiert eigenständig, trägt eine weltweit eindeutige ID und wird über typisierte Relationen mit anderen Elementen verknüpft. Aus der flachen Stückliste wird ein Graph. Ergänzt wird das Modell durch Profile, die das Datenmodell nach Anwendungsfällen gliedern: Core, Software, Licensing, Security, Build, AI, Dataset und Lite. SPDX 3. 1 führt diesen Weg konsequent weiter – und erweitert den Standard deutlich über reine Software hinaus. Die wichtigsten Neuerungen in SPDX 3. 1 Der Release Candidate 3. 1-RC1 zeigt die Richtung klar: SPDX wird zum universellen BOM-Standard für ganze Systeme. Die zentralen Erweiterungen im Überblick: Hardware-Profil (HBOM): SPDX 3. 1 kann erstmals Hardware-Komponenten nativ beschreiben. Für Hersteller von Embedded-Systemen, IoT-Geräten und Produkten mit digitalen Elementen – also genau die Zielgruppe des CRA – lassen sich Software- und Hardware-Stückliste künftig in einem konsistenten Modell abbilden. Ein einzelnes Element kann dabei gleichzeitig mehrere Rollen einnehmen, etwa als Hardware-Chip und als Träger eines Kryptografie-Algorithmus. Supply-Chain-Profil: Lieferketten-Ereignisse wie Transport, Übergaben und Herkunftsnachweise werden Teil des Standards. Damit rückt SPDX näher an das heran, was Regulierungen wie CRA und NIS-2 eigentlich verlangen: Transparenz über die gesamte Lieferkette, nicht nur über den Quellcode. Safety/Design-Assurance: Anforderungen und Sicherheitsnachweise (im... Software ist zu einem der wertvollsten Vermögenswerte moderner Technologieunternehmen geworden. Daher erfordern Fusionen und Übernahmen im Softwarebereich zunehmend eine sorgfältige Prüfung der Software selbst. In heutigen Technologietransaktionen beschränkt sich die Due Diligence nicht mehr nur auf Finanzunterlagen, Verträge oder Patente. Sie umfasst auch die Überprüfung des Quellcodes, der die Grundlage des zu erwerbenden Produkts bildet. Da moderne Anwendungen stark auf Open-Source-Komponenten basieren, ist das Verständnis ihrer Nutzung ein zentraler Faktor bei der Bewertung von Risiken und Wert in Softwaretransaktionen. In der Praxis enthält die meiste kommerzielle Software heute einen erheblichen Anteil an Open-Source-Code. Bibliotheken, Frameworks, Infrastrukturplattformen und Entwicklungstools stammen häufig aus dem Open-Source-Ökosystem. Diese breite Nutzung bringt große Vorteile für Innovation und Entwicklungsgeschwindigkeit, führt jedoch auch zu rechtlichen und betrieblichen Fragestellungen. Open-Source-Software wird unter Lizenzen veröffentlicht, die bestimmte Verpflichtungen mit sich bringen – etwa hinsichtlich Namensnennung, Lizenzhinweisen oder der Bereitstellung von Quellcode. Bei einer Übernahme muss das erwerbende Unternehmen sicherstellen, dass diese Verpflichtungen eingehalten wurden. Aus diesem Grund sind Open-Source-Audits zu einem festen Bestandteil der Software-Due-Diligence bei Fusionen und Übernahmen geworden. Ein FOSS-Audit umfasst die systematische Analyse einer Codebasis, um Open-Source-Komponenten zu identifizieren, die jeweils geltenden Lizenzen zu bestimmen und zu prüfen, ob die entsprechenden Lizenzbedingungen eingehalten wurden. Ziel ist es nicht, Open Source zu vermeiden – denn sie ist allgegenwärtig –, sondern deren Nutzung zu verstehen und mögliche rechtliche oder operative Risiken zu bewerten. Die Notwendigkeit solcher Analysen ist branchenweit anerkannt. Leitlinien der OpenChain-Initiative der Linux Foundation betonen, dass Organisationen in Softwaretransaktionen in der Lage sein müssen, die in ihren Codebasen enthaltenen Komponenten zu identifizieren und die damit verbundenen Lizenzbedingungen zu verstehen. Eine transparente und aktuelle Übersicht aller Softwarebestandteile, einschließlich Open-Source-Abhängigkeiten, ist heute eine grundlegende Voraussetzung für verantwortungsvolle Software-Governance. Ohne diese Transparenz fällt es Unternehmen schwer, ihre rechtlichen Verpflichtungen im Zusammenhang mit vertriebener oder erworbener Software zu bewerten. Ein FOSS-Audit beginnt in der Regel mit der Identifikation aller im Produkt enthaltenen Open-Source-Komponenten. Moderne Anwendungen greifen häufig auf Hunderte oder sogar Tausende externer Bibliotheken zurück, die oft automatisch über Paketmanager und Build-Systeme eingebunden werden. Automatisierte Scan-Tools kommen zum Einsatz, um diese Komponenten zu erkennen und die entsprechenden Lizenzen zuzuordnen. Anschließend wird analysiert, wie diese Komponenten in das Produkt integriert sind und ob die Lizenzbedingungen eingehalten wurden. Die Einhaltung von Lizenzbedingungen ist einer der sichtbarsten Aspekte der Open-Source-Due-Diligence. Einige Open-Source-Lizenzen, insbesondere sogenannte Copyleft-Lizenzen wie die GNU General Public License, enthalten Verpflichtungen, die unter bestimmten Umständen die Offenlegung des Quellcodes erfordern. Diese Lizenzen sind weit verbreitet und anerkannt, dennoch müssen Unternehmen sicherstellen, dass sie deren Anforderungen erfüllen. Verstöße können zum Verlust von Nutzungsrechten führen und rechtliche Risiken oder aufwendige Nachbesserungen nach sich ziehen. Neben Lizenzfragen spielen auch Sicherheitsaspekte eine wichtige Rolle. Open-Source-Komponenten können bekannte Schwachstellen enthalten, die ein Risiko für das übernehmende Unternehmen darstellen, wenn sie nicht behoben werden. Im Rahmen eines Audits werden identifizierte Komponenten häufig mit Schwachstellendatenbanken abgeglichen, um potenzielle Sicherheitsprobleme zu erkennen. Die Behebung solcher Schwachstellen vor Abschluss einer Transaktion kann das operative Risiko erheblich reduzieren. Auch Fragen des geistigen Eigentums können im Rahmen von Open-Source-Audits relevant werden. In... Software as a Core Asset Software is one of the most valuable assets in modern technology companies. As a result, mergers and acquisitions involving software firms require close examination of the software itself. Today, due diligence goes beyond financial records, contracts, and patents. It also includes reviewing the source code that underpins the product. Because modern applications rely heavily on open source components, companies must understand how they use open source software to assess risk and value. The Prevalence of Open Source Software Most commercial software includes a substantial amount of open source code. Developers rely on libraries, frameworks, infrastructure platforms, and tools from the open source ecosystem. This approach speeds up innovation and development, but it also introduces legal and operational considerations. Open source licenses impose obligations such as attribution, license notices, and, in some cases, source code disclosure. During an acquisition, the buyer must verify that the target company has met these obligations. What a FOSS Audit Involves Open source audits are now a standard part of software due diligence. A FOSS audit systematically analyzes a codebase to identify open source components, determine applicable licenses, and assess compliance. The goal is not to avoid open source software—it is everywhere—but to understand its use and identify potential risks. Industry Expectations and Governance Industry guidance emphasizes the importance of tracking software components and their licenses. Organizations must maintain a clear inventory of all components, including open source dependencies. Without this visibility, companies cannot fully evaluate legal obligations tied to their software. Strong governance practices help ensure responsible and compliant use of open source. How the Audit Process Works A FOSS audit starts by identifying all open source components in a product. Modern applications often depend on hundreds or thousands of external libraries, many added automatically through package managers. Automated tools scan the codebase to detect these components and their licenses. Auditors then review how the components are used and whether the company complies with license terms. License Compliance Risks License compliance is a key focus of open source due diligence. Some licenses, especially copyleft licenses like the GNU General Public License, require companies to share source code under certain conditions. These licenses are widely used, but companies must follow their terms carefully. Non-compliance can terminate license rights and create legal and financial risks. Security Considerations Security is another critical aspect of open source audits. Some components may contain known vulnerabilities. If left unresolved, these issues can expose the acquiring company to risk. Auditors typically check components against vulnerability databases to identify known issues. Fixing these vulnerabilities before closing reduces operational risk. Intellectual Property Concerns Open source audits can also uncover intellectual property issues. Companies may unknowingly use code with unclear licensing or unknown origin. Buyers need to understand where the software comes from and whether the company has the right to use it. Uncertainty in ownership or licensing can reduce the value of the software. Evaluating Governance Practices Modern due diligence also examines how a company manages open source use.... Wir haben großartige Neuigkeiten: Unser Unternehmen wurde für den regionalen Mittelstandspreis „Ludwig 2026“ in der Kategorie Innovation nominiert! Diese Nominierung ist für uns eine besondere Ehre und zugleich eine wertvolle Bestätigung unserer Arbeit der letzten Jahre. Sie zeigt, dass unser Engagement für zukunftsorientierte Technologien und nachhaltige Lösungen wahrgenommen wird – sowohl in der Region als auch darüber hinaus. Unser Beitrag: Innovation mit Open Source und Sicherheit Im Mittelpunkt unserer Arbeit steht die Entwicklung zugänglicher, effizienter und sicherer Lösungen zur Integration von Open Source Software. Gleichzeitig setzen wir uns aktiv dafür ein, die Cybersicherheit und Compliance in Open Source Ökosystemen zu stärken – insbesondere für kleine und mittlere Unternehmen (KMU). Ein wichtiger Bestandteil dieses Engagements ist unsere Mitwirkung am OCCTET-Projekt. Hier arbeiten wir daran, Unternehmen Werkzeuge an die Hand zu geben, mit denen sie regulatorische Anforderungen – wie etwa im Bereich Cybersicherheit – einfacher und effizienter erfüllen können. Unser Ziel ist klar: Wir möchten Innovation nicht nur vorantreiben, sondern auch praktisch nutzbar machen – gerade für den Mittelstand in unserer Region. Verwurzelt in der Region – mit Blick in die Zukunft Als Unternehmen aus der Region Bonn/Rhein-Sieg ist es uns ein besonderes Anliegen, Impulse für die lokale Wirtschaft zu setzen und aktiv an der Gestaltung der digitalen Zukunft mitzuwirken. Die Nominierung für den „Ludwig“ bestärkt uns darin, diesen Weg konsequent weiterzugehen. Preisverleihung im Juni Mit großer Spannung blicken wir nun auf die Preisverleihung am 9. Juni 2026 im GOP Varieté-Theater Bonn. Es ist uns eine Freude, Teil dieses besonderen Abends zu sein und gemeinsam mit anderen innovativen Unternehmen aus der Region ausgezeichnet zu werden. Auch ihr könnt dabei sein! Meldet euch hier an. Der Cyber Resilience Act (CRA) bringt eine subtile, aber tiefgreifende Veränderung in die Art und Weise, wie Hersteller über Open-Source-Software denken müssen. Jahrelang bedeutete die Integration von Free and Open Source Software (FOSS) in Produkte größtenteils, dass man auf die Pflege durch die ursprünglichen Maintainer vertraute, Schwachstellen überwachte und Updates einspielte, sobald Patches verfügbar waren. Unter dem CRA gilt dieses passive Modell nicht mehr. In bestimmten Situationen schafft eine Schwachstelle in einer Open-Source-Komponente nicht nur ein technisches Problem – sie begründet eine gesetzliche Handlungspflicht. In diesem Moment wird ein FOSS-Patch mehr als eine gute Praxis: Er wird zur regulatorischen Pflicht. Von passiver Nutzung zu aktiver Verantwortung Nach Anhang I, Teil II des CRA müssen Hersteller Schwachstellen unverzüglich während der Support-Periode des Produkts beheben. Diese Pflicht gilt für das Produkt in seiner Gesamtheit, einschließlich aller integrierten Komponenten. Die FAQ der Europäischen Kommission präzisiert dies weiter: Wenn ein Hersteller eine Komponente, einschließlich einer FOSS-Komponente, nutzt und eine Schwachstelle entdeckt, muss er diese beheben. Liefert der ursprüngliche Maintainer keinen Fix, ist nicht mehr verfügbar oder wird die Komponente nicht mehr unterstützt, kann der Hersteller nicht einfach auf neue Versionen oder Varianten verweisen. Er muss das Risiko auf andere Weise mindern, z.  B. durch Deaktivierung der Funktionalität, Austausch der Komponente oder die Entwicklung eines eigenen Patches. Dies verändert das Governance-Modell von Open Source in regulierten Produkten grundlegend. Nutzung von FOSS bedeutet nun auch Verantwortung und Pflege. Artikel 13(6): Die Pflicht zur Weitergabe des Fixes Die Änderung hört nicht bei der Behebung auf. Artikel 13(6) führt eine zusätzliche Pflicht ein: Entwickelt ein Hersteller einen Patch für eine Komponente, muss er diesen Patch an die Person oder Organisation weitergeben, die die Komponente pflegt. Diese Regelung stärkt die koordinierte Schwachstellenbehandlung und die Resilienz des Ökosystems. Sie bringt jedoch auch neue rechtliche und operative Überlegungen mit sich. Ein Hersteller, der eine Open-Source-Komponente modifiziert, um CRA-Pflichten zu erfüllen, konsumiert nicht länger nur Code, sondern wird nun unter der Regulierung auch zum „Contributor“. Der Patch ist keine freiwillige Handlung – er kann gesetzlich vorgeschrieben sein. Copyleft trifft Compliance Für Komponenten unter Copyleft-Lizenzen wie GPL, LGPL, AGPL oder MPL wird die Situation noch komplexer. Ein Sicherheits-Patch kann ein abgeleitetes Werk darstellen. Die Verbreitung der modifizierten Komponente – ob in Firmware, Embedded Systems oder als Download-Update – kann entsprechende Veröffentlichungs- und Hinweis-Pflichten auslösen. In vielen Fällen stimmen regulatorische und lizenzrechtliche Anforderungen überein: Beide fördern Transparenz und Zusammenarbeit entlang der Wertschöpfungskette. Aber diese Übereinstimmung ist nicht immer nahtlos. Hersteller müssen prüfen, ob ihre Behebungsstrategie Veröffentlichungspflichten, Vertraulichkeitsfragen oder Exportkontrollanforderungen beeinflusst. Der CRA ersetzt nicht die Open-Source-Lizenzierung. Er arbeitet neben ihr. Das bedeutet, dass Entscheidungen zur Schwachstellenbehebung nun an der Schnittstelle zwischen regulatorischer Compliance und Urheberrecht getroffen werden. Wenn der Support der genutzten Komponenten endet Der CRA behandelt auch Fälle, in denen integrierte Komponenten das Ende ihres Support-Zeitraums erreichen. Hält die Support-Periode des Herstellerprodukts an – in vielen Branchen mindestens fünf Jahre – müssen Schwachstellen in nicht mehr unterstützten Komponenten dennoch behandelt werden. Die Kommissionsleitlinien verdeutlichen: In solchen Fällen kann der Hersteller verpflichtet sein, die... The Cyber Resilience Act (CRA) introduces a subtle but profound shift in how manufacturers must think about open source software. For years, integrating free and open-source software (FOSS) into products largely meant relying on upstream maintainers for fixes, monitoring vulnerabilities, and updating when patches became available. Under the CRA, that passive model no longer holds. In certain situations, a vulnerability in an open-source component does not merely create a technical issue, it creates a legal obligation to act. This is the moment when a FOSS patch becomes more than a good practice. It becomes a regulatory duty. From Passive Consumption to Active Responsibility Under Annex I, Part II of the CRA, manufacturers must address and remediate vulnerabilities without delay during the product’s support period. This obligation applies to the product “in its entirety,” including all integrated components. The European Commission’s FAQ clarifies this further. If a manufacturer integrates a component, including a free and open-source component and identifies a vulnerability, it must address and remediate it. If the original maintainer does not provide a fix, is no longer active, or no longer supports the component, the integrating manufacturer cannot simply point upstream. It must mitigate the risk through other means, such as disabling functionality, replacing the component, or developing a patch itself. This fundamentally changes the governance model of open source in regulated products. Integration now implies stewardship. Article 13(6): The Obligation to Share the Fix The shift does not stop at remediation. Article 13(6) introduces an additional requirement: where a manufacturer develops a patch for a component, it must share that patch with the person or entity maintaining the component. This provision reinforces coordinated vulnerability handling and ecosystem resilience. But it also introduces new legal and operational considerations. A manufacturer that modifies an open-source component to meet CRA obligations is no longer merely consuming upstream code, it is contributing to it under regulatory pressure. The patch is not optional goodwill. The law may require it. Copyleft Meets Compliance For components under copyleft licenses such as GPL, LGPL, AGPL, or MPL, the interaction becomes even more nuanced. A security patch may constitute a derivative work. Distribution of the modified component, whether in firmware, embedded systems, or downloadable updates, may trigger corresponding source code and notice obligations. In many cases, regulatory and licensing requirements will align: both encourage transparency and upstream collaboration. But the alignment is not always seamless. Manufacturers must consider whether their remediation strategy affects distribution obligations, confidentiality concerns, or export control sensitivities. The CRA does not override open source licensing. It operates alongside it. This means vulnerability remediation decisions now sit at the intersection of regulatory compliance and copyright law. When Upstream Support Ends The CRA also addresses scenarios where integrated components reach the end of their support period. Even if the manufacturer continues its product support period—which in many sectors must last at least five years—it still needs to handle vulnerabilities in unsupported components. The Commission’s guidance makes clear that in such cases, the manufacturer may need... The Cyber Resilience Act (CRA) introduces a subtle but profound shift in how manufacturers must think about open source software. For years, integrating free and open-source software (FOSS) into products largely meant relying on upstream maintainers for fixes, monitoring vulnerabilities, and updating when patches became available. Under the CRA, that passive model no longer holds. In certain situations, a vulnerability in an open-source component does not merely create a technical issue, it creates a legal obligation to act. This is the moment when a FOSS patch becomes more than a good practice. It becomes a regulatory duty. From Passive Consumption to Active Responsibility Under Annex I, Part II of the CRA, manufacturers must address and remediate vulnerabilities without delay during the product’s support period. This obligation applies to the product “in its entirety,” including all integrated components. The European Commission’s FAQ clarifies this further. If a manufacturer integrates a component, including a free and open-source component and identifies a vulnerability, it must address and remediate it. If the original maintainer does not provide a fix, is no longer active, or no longer supports the component, the integrating manufacturer cannot simply point upstream. It must mitigate the risk through other means, such as disabling functionality, replacing the component, or developing a patch itself. This fundamentally changes the governance model of open source in regulated products. Integration now implies stewardship. Article 13(6): The Obligation to Share the Fix The shift does not stop at remediation. Article 13(6) introduces an additional requirement: where a manufacturer develops a patch for a component, it must share that patch with the person or entity maintaining the component. This provision reinforces coordinated vulnerability handling and ecosystem resilience. But it also introduces new legal and operational considerations. A manufacturer that modifies an open-source component to meet CRA obligations is no longer merely consuming upstream code, it is contributing to it under regulatory pressure. The patch is not optional goodwill. The law may require it. Copyleft Meets Compliance For components under copyleft licenses such as GPL, LGPL, AGPL, or MPL, the interaction becomes even more nuanced. A security patch may constitute a derivative work. Distribution of the modified component, whether in firmware, embedded systems, or downloadable updates, may trigger corresponding source code and notice obligations. In many cases, regulatory and licensing requirements will align: both encourage transparency and upstream collaboration. But the alignment is not always seamless. Manufacturers must consider whether their remediation strategy affects distribution obligations, confidentiality concerns, or export control sensitivities. The CRA does not override open source licensing. It operates alongside it. This means vulnerability remediation decisions now sit at the intersection of regulatory compliance and copyright law. When Upstream Support Ends The CRA also addresses scenarios where integrated components reach the end of their support period. Even if the manufacturer continues its product support period—which in many sectors must last at least five years—it still needs to handle vulnerabilities in unsupported components. The Commission’s guidance makes clear that in such cases, the manufacturer may need... How a compromise in trusted security tooling rippled through Checkmarx KICS and LiteLLM, exposing the real risk of transitive dependencies. The past several days has been a serious reminder that supply chain attacks do not stop with the first compromised project. What started with a malicious Trivy release appears to have widened into a separate but similar attack involving Checkmarx KICS GitHub Actions and then LiteLLM. Taken together, these events show why teams need to pay closer attention to transitive dependencies, not just the packages they knowingly install. Public reports indicate that TeamPCP, a threat actor active on Telegram, orchestrated this as part of a broader campaign. The Malicious Trivy release v0. 69. 4 on March 19, 2026: The first major incident came from Trivy. On March 19, 2026, attackers pushed a malicious v0. 69. 4 release and tampered with related GitHub Actions. Reports show they injected an “Info-Stealer” that ran in CI/CD workflows, collected sensitive data such as SSH keys, tokens, and environment variables, and exfiltrated it—all while keeping the workflow looking normal. This increased the danger significantly as Trivy was now a trusted security tool operating in a place where high-value credentials often exist. This matters because teams commonly use Trivy in build and release pipelines. When attackers compromise a tool in that position, they can cause damage beyond the tool itself. The real concern is what it had access to when it ran. The Checkmarx KICS Compromise on March 23: On March 23, researchers disclosed a separate but similar compromise of Checkmarx KICS GitHub Actions, where attackers used similar tradecraft with different infrastructure. Whether every detail was identical is less important than the larger pattern. Attackers tampered with trusted automation components to harvest secrets from CI/CD environments. That alone should concern any organization relying heavily on GitHub Actions and other pipeline tooling. Malicious releases in LiteLLM: And then came LiteLLM. On March 24, LiteLLM announced that attackers had published malicious versions 1. 82. 7 and 1. 82. 8 to PyPI. The reported behavior again involved searching for SSH keys, cloud credentials, tokens, and environment variables, then exfiltrating them. What made the LiteLLM incident especially important was the likely relationship with the earlier Trivy compromise. Public reports linked the LiteLLM compromise to credentials that attackers likely exposed using a Trivy scanner on LiteLLM’s CI/CD pipeline. Now this has stopped being a story about just one bad release of a package. It became a story about compromise spreading through the software supply chain. The Transitive Dependency Problem: LiteLLM also makes the transitive dependency problem much easier to see. Not every affected user would necessarily have installed those malicious LiteLLM versions directly. Some environments may have pulled LiteLLM in indirectly through AI tooling, orchestration frameworks, or other upstream dependencies. For example, the popular Python project “dspy,” used for AI workflows and starred over 33,000 times on GitHub, pulls in “LiteLLM” as a transitive dependency. Hence a “pip install dspy” can bring in the malicious litellm package when the intention was... Wie sich eine Sicherheitslücke in einem bewährten Sicherheitstool auf Checkmarx KICS und LiteLLM auswirkte und das tatsächliche Risiko transitiver Abhängigkeiten offenlegte. Die letzten Tage haben uns eindringlich vor Augen geführt, dass Angriffe auf die Lieferkette nicht schon mit dem ersten kompromittierten Projekt enden. Was mit einer bösartigen Trivy-Version begann, scheint sich zu einem separaten, aber ähnlichen Angriff ausgeweitet zu haben, der Checkmarx KICS GitHub Actions und anschließend LiteLLM betraf. Zusammengenommen zeigen diese Ereignisse, warum Teams transitiven Abhängigkeiten mehr Aufmerksamkeit schenken müssen und nicht nur den Paketen, die sie bewusst installieren. Öffentliche Berichte deuten zudem darauf hin, dass dies Teil einer umfassenderen Kampagne ist, die TeamPCP zugeschrieben wird, einem Bedrohungsakteur, der auf Telegram präsent ist. Die bösartige Trivy-Version v0. 69. 4 vom 19. März 2026: Der erste größere Vorfall betraf Trivy. Am 19. März 2026 veröffentlichten Angreifer die bösartige Version v0. 69. 4 und manipulierten die zugehörigen GitHub-Vorgänge. Laut öffentlichen Berichten injizierten sie einen „Info-Stealer“ in CI/CD-Workflows, sammelten sensible Daten wie SSH-Schlüssel, Tokens und Umgebungsvariablen und exfiltrierten diese, während der Workflow normal weiterlief. Dies erhöhte die Gefahr erheblich, da Trivy nun ein vertrauenswürdiges Sicherheitstool war, das an einem Ort eingesetzt wurde, an dem häufig hochwertige Anmeldedaten vorhanden sind. Das ist von Bedeutung, da Trivy häufig in Build- und Release-Pipelines eingesetzt wird. Wenn Angreifer ein Tool in dieser Position kompromittieren, beschränkt sich der Schaden nicht auf das Tool selbst. Die eigentliche Sorge betrifft die Daten und Ressourcen, auf die sie während der Ausführung Zugriff hatten. Der Checkmarx-KICS-Hack am 23. März: Am 23. März machten Sicherheitsforscher einen separaten, aber ähnlichen Angriff bekannt: Angreifer zielten auf Checkmarx-KICS-GitHub-Actions, nutzten ähnliche Methoden und setzten dabei eine andere Infrastruktur ein. Ob alle Details identisch waren, ist weniger wichtig als das übergeordnete Muster. Angreifer manipulierten vertrauenswürdige Automatisierungskomponenten, um geheime Daten aus CI/CD-Umgebungen abzugreifen. Allein dies sollte jedes Unternehmen beunruhigen, das in hohem Maße auf GitHub-Actions und andere Pipeline-Tools setzt. Schädliche Veröffentlichungen bei LiteLLM: Und dann kam LiteLLM. Am 24. März gab LiteLLM bekannt, dass die schädlichen Versionen 1. 82. 7 und 1. 82. 8 auf PyPI veröffentlicht worden waren. Das gemeldete Verhalten umfasste erneut die Suche nach SSH-Schlüsseln, Cloud-Anmeldedaten, Tokens und Umgebungsvariablen sowie deren anschließende Exfiltration. Was den Vorfall bei LiteLLM besonders bedeutsam machte, war der wahrscheinliche Zusammenhang mit dem früheren Trivy-Hack. Öffentliche Berichte verknüpfen die Kompromittierung von LiteLLM mit Anmeldedaten, die Angreifer vermutlich durch einen Trivy-Scanner auf LiteLLMs CI/CD-Pipeline offengelegt haben. Nun handelt es sich nicht mehr nur um eine Geschichte über eine einzige fehlerhafte Veröffentlichung eines Pakets. Es wurde zu einer Geschichte über eine Kompromittierung, die sich über die Software-Lieferkette ausbreitet. Das Problem der transitiven Abhängigkeiten: LiteLLM macht das Problem der transitiven Abhängigkeiten zudem deutlich sichtbarer. Nicht jeder betroffene Nutzer hat diese schädlichen LiteLLM-Versionen unbedingt direkt installiert. In manchen Umgebungen wurde LiteLLM möglicherweise indirekt über KI-Tools, Orchestrierungs-Frameworks oder andere vorgelagerte Abhängigkeiten bezogen. Beispielsweise zieht das beliebte Python-Projekt „dspy“, das für KI-Workflows eingesetzt wird und über 33. 000 Sterne auf GitHub hat, „LiteLLM“ als transitive Abhängigkeit ein. Daher kann ein „pip install dspy“ das bösartige litellm-Paket einbinden,... How a compromise in trusted security tooling rippled through Checkmarx KICS and LiteLLM, exposing the real risk of transitive dependencies. The past several days has been a serious reminder that supply chain attacks do not stop with the first compromised project. What started with a malicious Trivy release appears to have widened into a separate but similar attack involving Checkmarx KICS GitHub Actions and then LiteLLM. Taken together, these events show why teams need to pay closer attention to transitive dependencies, not just the packages they knowingly install. Public reports indicate that TeamPCP, a threat actor active on Telegram, orchestrated this as part of a broader campaign. The Malicious Trivy release v0. 69. 4 on March 19, 2026: The first major incident came from Trivy. On March 19, 2026, attackers pushed a malicious v0. 69. 4 release and tampered with related GitHub Actions. Reports show they injected an “Info-Stealer” that ran in CI/CD workflows, collected sensitive data such as SSH keys, tokens, and environment variables, and exfiltrated it—all while keeping the workflow looking normal. This increased the danger significantly as Trivy was now a trusted security tool operating in a place where high-value credentials often exist. This matters because teams commonly use Trivy in build and release pipelines. When attackers compromise a tool in that position, they can cause damage beyond the tool itself. The real concern is what it had access to when it ran. The Checkmarx KICS Compromise on March 23: On March 23, researchers disclosed a separate but similar compromise of Checkmarx KICS GitHub Actions, where attackers used similar tradecraft with different infrastructure. Whether every detail was identical is less important than the larger pattern. Attackers tampered with trusted automation components to harvest secrets from CI/CD environments. That alone should concern any organization relying heavily on GitHub Actions and other pipeline tooling. Malicious releases in LiteLLM: And then came LiteLLM. On March 24, LiteLLM announced that attackers had published malicious versions 1. 82. 7 and 1. 82. 8 to PyPI. The reported behavior again involved searching for SSH keys, cloud credentials, tokens, and environment variables, then exfiltrating them. What made the LiteLLM incident especially important was the likely relationship with the earlier Trivy compromise. Public reports linked the LiteLLM compromise to credentials that attackers likely exposed using a Trivy scanner on LiteLLM’s CI/CD pipeline. Now this has stopped being a story about just one bad release of a package. It became a story about compromise spreading through the software supply chain. The Transitive Dependency Problem: LiteLLM also makes the transitive dependency problem much easier to see. Not every affected user would necessarily have installed those malicious LiteLLM versions directly. Some environments may have pulled LiteLLM in indirectly through AI tooling, orchestration frameworks, or other upstream dependencies. For example, the popular Python project “dspy,” used for AI workflows and starred over 33,000 times on GitHub, pulls in “LiteLLM” as a transitive dependency. Hence a “pip install dspy” can bring in the malicious litellm package when the intention was... The Federal Office for Information Security (BSI) invites you to the 21st German IT Security Congress from April 15 to 16, 2026 – held virtually and interactively. Under the motto “Cybernation Germany: together, secure, digital,” the event will focus on current trends and challenges in cybersecurity. Bitsea will be participating:On April 16, 2026, from 13:00 to 14:30, Bitsea will give a presentation on the topic:“CRA Compliance in Practice: How Open Tools Support SMEs in Securing Software Supply Chains” Register now for free and gain valuable insights into the latest developments in IT security. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) lädt vom 15. bis 16. April 2026 zum 21. Deutschen IT-Sicherheitskongress ein – virtuell und interaktiv. Unter dem Motto “Cybernation Deutschland: gemeinsam, sicher, digital” stehen aktuelle Trends und Herausforderungen der Cybersicherheit im Fokus. Bitsea ist dabei:Am 16. April 2026 von 13:00–14:30 Uhr hält Bitsea einen Vortrag zum Thema:"CRA Compliance in Practice: How Open Tools Support SMEs in Securing Software Supply Chains"Melden Sie sich jetzt kostenlos an und erhalten Sie wertvolle Einblicke in die neuesten Entwicklungen der IT-Sicherheit. When a Security Incident Happens Outside the EU: Does the CRA Still Apply? The global nature of cybersecurity raises a practical question for manufacturers. If an actor exploits a vulnerability outside the European Union, do the Cyber Resilience Act (CRA) reporting and remediation obligations still apply? The short answer is yes. If a manufacturer places a product on the EU market, the CRA can trigger obligations, no matter where the incident occurs. In other words, when exploitation or discovery happens outside the EU, it can still trigger CRA obligations. To understand why and how, we must examine the CRA’s scope and the broader operation of EU product law. The CRA is Market-Based, Not Geography-Based The CRA is a product regulation. The scope depends on whether a manufacturer places a product with digital elements on the Union market. It does not depend on where the manufacturer is located or where a cybersecurity incident occurs. Recital 15 makes this clear: the Regulation applies to products that manufacturers “make available on the market,” meaning they supply them for distribution or use on the Union market in a commercial activity. The legal trigger is market access, not territorial origin. This reflects the general principles of EU product law as explained in the 2022 Blue Guide. EU harmonisation legislation applies to products that manufacturers place or make available on the EU market, regardless of where they produce them or where events occur later. The decisive question is whether the supplier provides the product within the Union market framework. Once manufacturers place a product on the EU market, it must comply with EU legislation throughout its lifecycle, including CRA cybersecurity obligations. Article 3 CRA: Definitions “Making available on the market’ means the supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge” Cybersecurity Is Inherently Cross-Border The CRA explicitly recognises the cross-border nature of digital risks. Recital 4 emphasises that the cybersecurity of products with digital elements has a “particularly strong cross-border dimension”. Digital vulnerabilities do not respect territorial boundaries. A vulnerability exploited in one jurisdiction may rapidly affect users, networks, and infrastructures in another. Recital 66 goes further. It states that because manufacturers market most digital products across the internal market, any exploited vulnerability in such a product threatens the market’s functioning. Notably, the recital does not limit this to vulnerabilities exploited within the Union. It refers to “any exploited vulnerability” in a product marketed in the internal market. The logic is systemic: when manufacturers sell a product in the EU, an exploited vulnerability anywhere can threaten the internal market’s security and integrity. Reporting Obligations Are Not Territory-Limited Article 14 requires manufacturers to notify actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. Recital 65 explains that reporting ensures authorities receive the information they need to assess risks and coordinate responses. Article 3(42) defines an “actively exploited vulnerability” as... Der CRA orientiert sich am Markt, nicht an der Geografie Der CRA ist eine Produktverordnung und gilt für Produkte mit digitalen Elementen, die Hersteller auf dem Unionsmarkt bereitstellen, unabhängig davon, wo sie sitzen oder wo ein Cybervorfall auftritt. Erwägungsgrund 15 macht dies deutlich: Die Verordnung erfasst Produkte mit digitalen Elementen, die Hersteller auf dem EU-Markt bereitstellen, also für die Verteilung oder Nutzung auf dem Unionsmarkt im Rahmen einer kommerziellen Tätigkeit. Der rechtliche Auslöser ist der Marktzugang, nicht der territoriale Ursprung. Dies entspricht den allgemeinen Prinzipien des EU-Produktsicherheitsrechts, wie im Blue Guide 2022 erläutert. Das EU-Harmonisierungsrecht gilt für Produkte, die Hersteller auf dem EU-Markt bereitstellen oder verfügbar machen, unabhängig davon, wo sie hergestellt wurden oder wo später Ereignisse auftreten. Entscheidend ist, dass Hersteller das Produkt im Rahmen des Unionsmarktes bereitstellen. Sobald ein Produkt auf dem EU-Markt ist, muss es während seines gesamten Lebenszyklus den geltenden EU-Vorschriften entsprechen – einschließlich der Cybersicherheitsanforderungen nach dem CRA. Artikel 3 CRA: Definitionen„Bereitstellung auf dem Markt“ bedeutet die Bereitstellung eines Produkts mit digitalen Elementen zur Verteilung oder Nutzung auf dem Unionsmarkt im Rahmen einer kommerziellen Tätigkeit, unabhängig davon, ob dies gegen Entgelt oder kostenlos erfolgt. Cybersicherheit ist grenzüberschreitend Der CRA erkennt ausdrücklich die grenzüberschreitende Natur digitaler Risiken an. Erwägungsgrund 4 betont, dass die Cybersicherheit von Produkten mit digitalen Elementen eine „besonders starke grenzüberschreitende Dimension“ hat. Digitale Schwachstellen respektieren keine territorialen Grenzen. Eine in einer Jurisdiktion ausgenutzte Schwachstelle kann schnell Benutzer, Netzwerke und Infrastrukturen in anderen Regionen betreffen. Erwägungsgrund 66 geht noch weiter. Da Hersteller die meisten Produkte mit digitalen Elementen im gesamten Binnenmarkt verkaufen, sehen die Behörden jede aktiv ausgebeutete Schwachstelle in diesen Produkten als Bedrohung für die Funktionsfähigkeit des Binnenmarkts. Bemerkenswert ist, dass sich der Erwägungsgrund nicht auf Schwachstellen innerhalb der Union beschränkt. Die Verordnung bezieht sich auf jede ausgebeutete Schwachstelle in einem Produkt, das Hersteller auf dem Binnenmarkt vermarkten. Die Logik dahinter ist systemisch: Wenn ein Hersteller ein Produkt in der EU verkauft, kann eine ausgebeutete Schwachstelle überall die Sicherheit und Integrität des Binnenmarktes bedrohen. Meldepflichten sind nicht territorial begrenzt Artikel 14 legt die Pflicht fest, aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, die die Sicherheit von Produkten mit digitalen Elementen betreffen, zu melden. Erwägungsgrund 65 erklärt, dass die Meldepflichten sicherstellen sollen, dass Behörden die notwendigen Informationen zur Risikobewertung und Koordination von Gegenmaßnahmen erhalten. Eine „aktiv ausgebeutete Schwachstelle“ ist definiert als eine Schwachstelle, für die zuverlässige Hinweise vorliegen, dass ein böswilliger Akteur sie ausgenutzt hat (Artikel 3(42)). Die Definition enthält keinen geografischen Einschränkung. Es ist nicht erforderlich, dass die Ausnutzung innerhalb der Union erfolgt. Erwägungsgrund 66 verstärkt diesen Ansatz, indem ausgebeutete Schwachstellen mit Bedrohungen für den Binnenmarkt verknüpft werden. Wenn ein auf dem EU-Markt bereitgestelltes Produkt eine aktiv ausgebeutete Schwachstelle enthält, ist diese Schwachstelle auch dann relevant, wenn die Ausnutzung zuerst in den USA, Asien oder anderswo erfolgt. Die Meldepflicht des Herstellers tritt in Kraft, sobald er von einer solchen Ausnutzung Kenntnis erlangt (Artikel 14(1); Erwägungsgrund 68). Der Ort des ersten Vorfalls ändert diese Pflicht nicht. Was, wenn der Vorfall nur Nicht-EU-Nutzer betrifft? Ein differenzierteres... Software companies often rely on a familiar distinction: they regulate products, but not services. They have viewed cloud delivery models, subscription-based offerings, and remote processing as business innovations. They have also seen them as ways to reduce regulatory exposure. The EU Cyber Resilience Act (CRA) challenges this assumption. Under the CRA, the key question is not whether a company markets a solution as “SaaS. ” It is whether the solution forms part of a “product with digital elements” that the company places on the market. When remote data processing is essential to a product’s core functionality, the cloud backend may fall within the regulatory scope. The Legal Shift: Remote Data Processing as Part of the Product The CRA defines “remote data processing” as data processing performed at a distance. The manufacturer designs, develops, or oversees it. Without this processing, the product cannot perform one of its functions. This distinction is significant. This means that when a connected device or locally installed software relies on backend infrastructure to function, the remote component counts as part of the product. It is not just an ancillary service. It becomes part of the regulated ecosystem. This blurs the traditional SaaS versus product distinction. A locally installed endpoint agent that works only when connected to the vendor’s cloud may trigger CRA relevance. So can a smart device whose core analytics run remotely or a software product whose main features rely on cloud processing. The architectural choice to move functionality into the cloud does not automatically remove it from regulatory scrutiny. Instead, it shifts the analysis toward whether that functionality is essential. Vulnerability Handling Follows the Architecture Once the manufacturer treats remote processing as part of the product’s functionality, the CRA’s lifecycle obligations come into effect. Manufacturers must address and remediate vulnerabilities without delay, provide security updates where appropriate, and comply with reporting duties in case of actively exploited vulnerabilities or severe incidents. These obligations do not stop at the firmware or the downloadable binary. If the backend service is necessary for the product’s operation, vulnerabilities in that service may have regulatory consequences. This is where is no longer an exemption. A critical flaw in a cloud-based authentication service, a vulnerable backend API, or an exploited open-source component can directly affect a product’s security on the EU market. The exploit may occur outside the EU. Still, the CRA’s reporting and handling obligations can apply if the product is marketed in the Union. Copyleft and the Cloud: A subtle but important convergence The implications extend beyond cybersecurity compliance. For companies that rely heavily on free and open-source software in their backend, integrating remote processing into the product’s core functionality adds complexity. This integration creates an additional layer of challenges. While the CRA does not alter copyright law, it changes how regulators view the boundaries of responsibility. When manufacturers treat remote components as part of the product lifecycle, due diligence, documentation, and vulnerability management obligations also apply to those components. In practice, this brings remote infrastructures closer to... Softwareunternehmen verlassen sich häufig auf eine vertraute Unterscheidung: Produkte sind reguliert, Services nicht. Cloud-Delivery-Modelle, abonnementbasierte Modelle und Remote-Verarbeitung wurden oft nicht nur als geschäftliche Innovationen betrachtet, sondern auch als Wege, regulatorische Risiken zu reduzieren. Der EU Cyber Resilience Act (CRA) stellt diese Annahme infrage. Entscheidend ist nach dem CRA nicht, ob etwas als „SaaS“ vermarktet wird, sondern ob es Teil eines „Produkts mit digitalen Elementen“ ist, das auf dem Markt bereitgestellt wird. Wenn „Remote“-Datenverarbeitung für die Kernfunktionalität eines Produkts wesentlich ist, fällt das Cloud-Backend möglicherweise nicht mehr außerhalb des regulatorischen Rahmens. Der rechtliche Wandel: Remote-Datenverarbeitung als Teil des Produkts Der CRA definiert „Remote-Datenverarbeitung“ als Datenverarbeitung aus der Ferne, für die die Software vom Hersteller oder unter seiner Verantwortung entwickelt wurde, und deren Fehlen das Produkt daran hindern würde, eine seiner Funktionen auszuführen. Diese Formulierung ist bedeutsam: Wenn ein verbundenes Gerät oder ein lokal installiertes Softwareprodukt auf Backend-Infrastruktur angewiesen ist, um wie vorgesehen zu funktionieren, ist die Remote-Komponente nicht nur ein Nebenservice, sondern Teil des regulierten Ökosystems. Dies verwischt die traditionelle Unterscheidung zwischen SaaS und Produkt. Ein lokal installierter Endpoint-Agent, der nur funktioniert, wenn er sich mit der Cloud des Anbieters verbindet, ein Smart Device, das seine Kernanalysen remote durchführt, oder ein Softwareprodukt, das seine Hauptfunktionen in der Cloud verarbeitet, können alle unter den CRA fallen. Die architektonische Entscheidung, Funktionalität in die Cloud zu verlagern, entfernt sie nicht automatisch aus der regulatorischen Prüfung. Vielmehr verschiebt sie die Analyse darauf, ob diese Funktionalität essenziell ist. Schwachstellenmanagement folgt der Architektur Wenn Remote-Verarbeitung als Teil der Produktfunktionalität betrachtet wird, treten die Lifecycle-Verpflichtungen des CRA in Kraft. Hersteller müssen Schwachstellen unverzüglich beheben, Sicherheitsupdates bereitstellen, wo erforderlich, und Meldepflichten bei aktiv ausgenutzten Schwachstellen oder schwerwiegenden Vorfällen erfüllen. Diese Pflichten beschränken sich nicht auf Firmware oder herunterladbare Binärdateien. Wenn der Backend-Service für den Betrieb des Produkts notwendig ist, können Schwachstellen in diesem Service regulatorische Konsequenzen haben. Hier gibt es also keine Ausnahme mehr. Eine kritische Schwachstelle in einem cloudbasierten Authentifizierungsdienst, eine Backend-API-Schwachstelle oder eine ausgenutzte Open-Source-Komponente im serverseitigen Stack kann die Sicherheit des Produkts auf dem EU-Markt direkt beeinträchtigen. Selbst wenn ein Exploit außerhalb der EU auftritt, greifen die Melde- und Handhabungspflichten nach dem CRA, sobald das betroffene Produkt in der Union vermarktet wird. Copyleft und die Cloud: Eine subtile, aber wichtige Konvergenz Die Auswirkungen gehen über die Cybersicherheits-Compliance hinaus. Für Unternehmen, die stark auf Open-Source-Software in ihren Backend-Stacks setzen, fügt die Integration von Remote-Verarbeitung in die Kernfunktionalität des Produkts eine weitere Komplexitätsebene hinzu. Der CRA ändert das Urheberrecht nicht, aber er beeinflusst, wie Regulierungsbehörden die Verantwortungsgrenzen betrachten. Behandeln Hersteller Remote-Komponenten als Teil des Produkts, müssen sie auch für diese Komponenten Due-Diligence-, Dokumentations- und Schwachstellenmanagementpflichten erfüllen. In der Praxis bringt dies Remote-Infrastrukturen auf das Prüfungsniveau, das traditionell für lokalen Code gilt. Organisationen, die SaaS bisher als Möglichkeit zur Reduzierung von Copyleft-Risiken betrachteten, müssen möglicherweise ihre Annahmen neu bewerten. Architektonische Entscheidungen aus Lizenz- oder Vertriebsgründen können nun Compliance- und Risikomanagement-Auswirkungen im Rahmen des Produktsicherheitsrechts haben. Die SBOM-Dimension: Transparenz im Backend Die wohl praktischste Konsequenz betrifft Software Bills of... When a Security Incident Happens Outside the EU: Does the CRA Still Apply? The global nature of cybersecurity raises a practical question for manufacturers. If an actor exploits a vulnerability outside the European Union, do the Cyber Resilience Act (CRA) reporting and remediation obligations still apply? The short answer is yes. If a manufacturer places a product on the EU market, the CRA can trigger obligations, no matter where the incident occurs. In other words, when exploitation or discovery happens outside the EU, it can still trigger CRA obligations. To understand why and how, we must examine the CRA’s scope and the broader operation of EU product law. The CRA is Market-Based, Not Geography-Based The CRA is a product regulation. The scope depends on whether a manufacturer places a product with digital elements on the Union market. It does not depend on where the manufacturer is located or where a cybersecurity incident occurs. Recital 15 makes this clear: the Regulation applies to products that manufacturers “make available on the market,” meaning they supply them for distribution or use on the Union market in a commercial activity. The legal trigger is market access, not territorial origin. This reflects the general principles of EU product law as explained in the 2022 Blue Guide. EU harmonisation legislation applies to products that manufacturers place or make available on the EU market, regardless of where they produce them or where events occur later. The decisive question is whether the supplier provides the product within the Union market framework. Once manufacturers place a product on the EU market, it must comply with EU legislation throughout its lifecycle, including CRA cybersecurity obligations. Article 3 CRA: Definitions “Making available on the market’ means the supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge” Cybersecurity Is Inherently Cross-Border The CRA explicitly recognises the cross-border nature of digital risks. Recital 4 emphasises that the cybersecurity of products with digital elements has a “particularly strong cross-border dimension”. Digital vulnerabilities do not respect territorial boundaries. A vulnerability exploited in one jurisdiction may rapidly affect users, networks, and infrastructures in another. Recital 66 goes further. It states that because manufacturers market most digital products across the internal market, any exploited vulnerability in such a product threatens the market’s functioning. Notably, the recital does not limit this to vulnerabilities exploited within the Union. It refers to “any exploited vulnerability” in a product marketed in the internal market. The logic is systemic: when manufacturers sell a product in the EU, an exploited vulnerability anywhere can threaten the internal market’s security and integrity. Reporting Obligations Are Not Territory-Limited Article 14 requires manufacturers to notify actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. Recital 65 explains that reporting ensures authorities receive the information they need to assess risks and coordinate responses. Article 3(42) defines an “actively exploited vulnerability” as... Software companies often rely on a familiar distinction: they regulate products, but not services. They have viewed cloud delivery models, subscription-based offerings, and remote processing as business innovations. They have also seen them as ways to reduce regulatory exposure. The EU Cyber Resilience Act (CRA) challenges this assumption. Under the CRA, the key question is not whether a company markets a solution as “SaaS. ” It is whether the solution forms part of a “product with digital elements” that the company places on the market. When remote data processing is essential to a product’s core functionality, the cloud backend may fall within the regulatory scope. The Legal Shift: Remote Data Processing as Part of the Product The CRA defines “remote data processing” as data processing performed at a distance. The manufacturer designs, develops, or oversees it. Without this processing, the product cannot perform one of its functions. This distinction is significant. This means that when a connected device or locally installed software relies on backend infrastructure to function, the remote component counts as part of the product. It is not just an ancillary service. It becomes part of the regulated ecosystem. This blurs the traditional SaaS versus product distinction. A locally installed endpoint agent that works only when connected to the vendor’s cloud may trigger CRA relevance. So can a smart device whose core analytics run remotely or a software product whose main features rely on cloud processing. The architectural choice to move functionality into the cloud does not automatically remove it from regulatory scrutiny. Instead, it shifts the analysis toward whether that functionality is essential. Vulnerability Handling Follows the Architecture Once the manufacturer treats remote processing as part of the product’s functionality, the CRA’s lifecycle obligations come into effect. Manufacturers must address and remediate vulnerabilities without delay, provide security updates where appropriate, and comply with reporting duties in case of actively exploited vulnerabilities or severe incidents. These obligations do not stop at the firmware or the downloadable binary. If the backend service is necessary for the product’s operation, vulnerabilities in that service may have regulatory consequences. This is where is no longer an exemption. A critical flaw in a cloud-based authentication service, a vulnerable backend API, or an exploited open-source component can directly affect a product’s security on the EU market. The exploit may occur outside the EU. Still, the CRA’s reporting and handling obligations can apply if the product is marketed in the Union. Copyleft and the Cloud: A subtle but important convergence The implications extend beyond cybersecurity compliance. For companies that rely heavily on free and open-source software in their backend, integrating remote processing into the product’s core functionality adds complexity. This integration creates an additional layer of challenges. While the CRA does not alter copyright law, it changes how regulators view the boundaries of responsibility. When manufacturers treat remote components as part of the product lifecycle, due diligence, documentation, and vulnerability management obligations also apply to those components. In practice, this brings remote infrastructures closer to... One of the frequently asked questions surrounding the Cyber Resilience Act (CRA) concerns legacy products. Manufacturers ask whether they can sell older products in the EU after 11 December 2027 without updates. This blog explores the issue amid evolving CRA standards and upcoming compliance deadlines. CRA Scope and Market Placement The CRA applies to products placed on the market from 11 December 2027 onward. The decisive factor is not the product model’s initial release date, but when each individual unit is placed on the market. Under EU product legislation, compliance obligations attach to each unit supplied for distribution or use in the Union. The Commission’s FAQ confirms this principle, reflecting long-standing guidance in the Blue Guide on EU product rules. In other words, EU law regulates products as individual market events, not as abstract product types. Placing on the Market Under the CRA, a product’s support period starts on the date it is placed on the market, meaning the first sale of each unit. Section 2. 3 of the Blue Guide clarifies that “placing on the market” applies to individual units, not to the product type, whether made as a single item or in series. Implications for Products Before 11 December 2027 This distinction has major implications. Units placed on the market before 11 December 2027 do not need to retroactively meet the CRA’s essential cybersecurity requirements. Products already on the market do not need conformity assessment, CE marking, or updated documentation just because the CRA applies. Exception: From 11 September 2026, Article 14 reporting obligations apply to all in-scope products. If a manufacturer detects an actively exploited vulnerability or severe incident, they must notify authorities, regardless of when the product was first placed on the market. Obligations for Products Placed on the Market After 11 December 2027 The situation changes fundamentally for any unit placed on the market on or after 11 December 2027. From that date forward, every new unit must comply with the CRA in full. This is true even if the product design has not changed since 2015 or earlier. The manufacturer must meet Annex I cybersecurity requirements, implement vulnerability handling, complete the conformity assessment, prepare technical documentation, affix the CE marking, issue an EU declaration of conformity, and define a compliant support period. The age of the product architecture does not provide an exemption. Substantial Modifications: When Legacy Products Re-Enter Scope Another important dimension concerns product modifications. The CRA distinguishes clearly between customization, minor updates, and substantial modifications, and this distinction directly affects whether the Regulation applies. Customer-specific customizations usually do not create a new product or change its purpose, so they do not trigger CRA. Minor updates, like visual improvements or new language support, also do not count as substantial modifications if they do not increase cybersecurity risk. A software or feature update is substantial if it changes the product’s purpose, introduces new hazards, or raises cybersecurity risk. In such cases, even products placed on the market before 11 December 2027 fall under the... Eine der häufigsten Fragen zum Cyber Resilience Act (CRA) betrifft die Handhabe von Altsystemen. Hersteller aus verschiedenen Branchen fragen, ob sie Produkte, die sie vor Jahren entwickelt und auf den Markt gebracht haben, nach dem 11. Dezember 2027 weiterhin in der Europäischen Union verkaufen dürfen, ohne sie anzupassen. Dieser Blog beleuchtet die Thematik im Kontext der sich entwickelnden CRA-Standards und der bevorstehenden Compliance-Termine. Anwendungsbereich des CRA für neue und bestehende Produkte Der CRA gilt für Produkte, die Unternehmen ab dem 11. Dezember 2027 auf den Markt bringen. Dabei kommt es nicht darauf an, wann ein Produktmodell erstmals veröffentlicht wurde, sondern wann ein Unternehmen eine einzelne Einheit auf den Markt bringt. Nach dem EU-Produktsicherheitsrecht bestimmen die Compliance-Verpflichtungen sich für jede einzelne Einheit, die ein Wirtschaftsakteur zur Verteilung oder Nutzung in der Union bereitstellt. Die Europäischen Kommission bestätigt dieses Prinzip in ihren FAQ und stellt es auch in den Leitlinien des Blue Guide zu EU-Produktvorschriften dar. Anders ausgedrückt: Das EU-Recht regelt Produkte als individuelle Marktereignisse, nicht als abstrakte Produkttypen. Unter dem CRA beginnt die allgemeine Supportperiode eines Produkts mit dem Datum der „Markteinführung“, also dem ersten Verkauf der einzelnen Einheit. Wie in Abschnitt 2. 3 des Blue Guide erläutert, bedeutet „Markteinführung“: „Der Begriff bezieht sich auf jede einzelne Produkteinheit und nicht auf einen Produkttyp, unabhängig davon, ob sie einzeln oder in Serie gefertigt wurde. “ Auswirkungen für bestehende Produkte Diese Unterscheidung hat große Konsequenzen. Einheiten, die Unternehmen vor dem 11. Dezember 2027 auf den Markt bringen, müssen die wesentlichen Cybersicherheitsanforderungen des CRA nicht nachträglich erfüllen. Unternehmen müssen diese Produkte nicht erneut einer Konformitätsbewertung unterziehen, nicht mit der CE-Kennzeichnung versehen und auch die technische Dokumentation nicht aktualisieren, nur weil der CRA in Kraft tritt. Es gibt jedoch eine wichtige Ausnahme: Die Meldepflichten nach Artikel 14 gelten ab dem 11. September 2026 für alle Produkte im Anwendungsbereich, einschließlich der bereits auf dem Markt befindlichen. Wenn ein Hersteller von einer aktiv ausgenutzten Sicherheitslücke oder einem schweren Vorfall betroffen wird, besteht unabhängig vom ursprünglichen Markteinführungsdatum eine Meldepflicht. Neue Produkte ab 11. Dezember 2027 Ab dem 11. Dezember 2027 ändert sich die Situation grundlegend. Jede neue Einheit, die ab diesem Datum auf den Markt gebracht wird, muss vollständig den Anforderungen des CRA entsprechen – selbst wenn das Produktdesign seit 2015 oder früher unverändert ist. Der Hersteller muss sicherstellen, dass das Produkt die wesentlichen Cybersicherheitsanforderungen gemäß Anhang I erfüllt, Prozesse zum Umgang mit Schwachstellen während der Supportperiode implementieren, die passende Konformitätsbewertung durchführen, die technische Dokumentation erstellen, die CE-Kennzeichnung anbringen, eine EU-Konformitätserklärung ausstellen und die Supportperiode bestimmen und dokumentieren. Das Alter der Produktarchitektur stellt keine Ausnahme dar. „Wesentliche“ Änderungen: Wann Altsysteme unter den CRA fallen Ein weiterer wichtiger Aspekt betrifft Produktänderungen. Der CRA unterscheidet klar zwischen Anpassungen, kleineren Updates und wesentlichen Änderungen, und diese Unterscheidung beeinflusst direkt die Anwendbarkeit der Verordnung. Typische kundenspezifische Anpassungen eines Standardprodukts lösen in der Regel keine neue Produktdefinition aus und ändern den vorgesehenen Zweck nicht; daher gelten sie nicht automatisch als CRA-relevant. Auch Sicherheitsupdates oder kleinere Funktionsänderungen, wie optische Verbesserungen oder neue Sprachoptionen, gelten... One of the frequently asked questions surrounding the Cyber Resilience Act (CRA) concerns legacy products. Manufacturers ask whether they can sell older products in the EU after 11 December 2027 without updates. This blog explores the issue amid evolving CRA standards and upcoming compliance deadlines. CRA Scope and Market Placement The CRA applies to products placed on the market from 11 December 2027 onward. The decisive factor is not the product model’s initial release date, but when each individual unit is placed on the market. Under EU product legislation, compliance obligations attach to each unit supplied for distribution or use in the Union. The Commission’s FAQ confirms this principle, reflecting long-standing guidance in the Blue Guide on EU product rules. In other words, EU law regulates products as individual market events, not as abstract product types. Defining “Placing on the Market” Under the CRA, a product’s support period starts on the date it is placed on the market, meaning the first sale of each unit. Section 2. 3 of the Blue Guide clarifies that “placing on the market” applies to individual units, not to the product type, whether made as a single item or in series. Implications for Products Before 11 December 2027 This distinction has major implications. Units placed on the market before 11 December 2027 do not need to retroactively meet the CRA’s essential cybersecurity requirements. Products already on the market do not need conformity assessment, CE marking, or updated documentation just because the CRA applies. Exception: From 11 September 2026, Article 14 reporting obligations apply to all in-scope products. If a manufacturer detects an actively exploited vulnerability or severe incident, they must notify authorities, regardless of when the product was first placed on the market. Obligations for Products Placed on the Market After 11 December 2027 The situation changes fundamentally for any unit placed on the market on or after 11 December 2027. From that date forward, every new unit must comply with the CRA in full. This is true even if the product design has not changed since 2015 or earlier. The manufacturer must meet Annex I cybersecurity requirements, implement vulnerability handling, complete the conformity assessment, prepare technical documentation, affix the CE marking, issue an EU declaration of conformity, and define a compliant support period. The age of the product architecture does not provide an exemption. Substantial Modifications: When Legacy Products Re-Enter Scope Another important dimension concerns product modifications. The CRA distinguishes clearly between customization, minor updates, and substantial modifications, and this distinction directly affects whether the Regulation applies. Customer-specific customizations usually do not create a new product or change its purpose, so they do not trigger CRA. Minor updates, like visual improvements or new language support, also do not count as substantial modifications if they do not increase cybersecurity risk. A software or feature update is substantial if it changes the product’s purpose, introduces new hazards, or raises cybersecurity risk. In such cases, even products placed on the market before 11 December 2027 fall under... The EU’s growing focus on SBOMs, highlighted in ENISA’s SBOM Landscape Analysis – Towards an Implementation Guide, is a key step toward greater transparency and resilience in software supply chains. SBOMs are rapidly becoming a central building block for cybersecurity governance under the Cyber Resilience Act (CRA) and related frameworks. From Bitsea’s perspective, this direction is both necessary and overdue. SBOMs provide a shared factual basis for what a product contains, its dependencies, and potential security or compliance risks. Implemented well, they speed up vulnerability assessments, improve incident response, and clarify communication across technical, legal, and organizational teams. They also give regulators and customers a clear view of an organization’s control over its software. Bitsea has also shared feedback with ENISA on practical considerations needed to make SBOM guidance effective in real-world use. Moving from Conceptual SBOMs to Practically Usable Ones One key observation is that SBOMs often describe software at a very high level, focusing primarily on complete components or packages. In practice, however, modern software development frequently involves partial reuse, individual files, directories, or code fragments extracted from larger projects. This form of reuse has direct implications for licensing, copyright attribution, and security exposure. A practically usable SBOM should reflect partial components and fine-grained reuse, instead of assuming that software is always used as complete, versioned packages. Closely related is the widespread informal reuse of code snippets, including those copied from public forums or knowledge-sharing platforms. Such snippets may be subject to copyright, carry licensing obligations, or embed known vulnerabilities. While this type of reuse is rarely intentional non-compliance, it represents a real and recurring risk. Bitsea emphasizes that SBOM guidance should acknowledge this reality and encourage organizations to include it in their software inventory and compliance processes. Beyond Source Code: Accounting for Non-Code Artifacts Another important consideration is that software products rarely consist of source code alone. Documentation, configuration files, images, fonts, media assets, and other non-code artifacts are routinely shipped as part of software distributions. These elements carry their own licensing and IP constraints, creating legal and operational risks. Bitsea recommends expanding SBOMs beyond source code to include such artifacts. A common example is including an open-licensed font in an application, firmware, or documentation. Widely used fonts under the SIL Open Font License (OFL) allow embedding, modification, and redistribution, while requiring copyright notice preservation and restricting reserved font names. AI-Generated Code and Emerging Provenance Risks ENISA’s report acknowledges AI-generated code as a limitation and challenge, but Bitsea believes this topic needs stronger emphasis. In practice, AI-assisted development is already a significant factor in many codebases. AI-generated outputs may closely resemble existing open source components, sometimes without clear attribution or identifiable licensing context. This raises novel questions around provenance, compliance, and risk allocation. At a minimum, SBOM guidance should raise awareness of these risks and recommend measures for identifying and managing AI-assisted or AI-generated code within SBOM-driven workflows. SBOMs and License Compliance: Foundation, Not a Shortcut Organizations must understand SBOMs as foundational data structures, not as a... Der zunehmende Fokus der Europäischen Union auf Software Bills of Materials (SBOMs), zuletzt sichtbar im ENISA-Bericht SBOM Landscape Analysis – Towards an Implementation Guide, stellt einen wichtigen und begrüßenswerten Schritt hin zu mehr Transparenz und Resilienz in Software-Lieferketten dar. SBOMs entwickeln sich rasch zu einem zentralen Baustein der Cybersicherheits-Governance im Rahmen des Cyber Resilience Act (CRA) und verwandter Regelwerke. Aus Sicht von Bitsea ist diese Entwicklung sowohl notwendig als auch überfällig. SBOMs schaffen eine gemeinsame, faktenbasierte Grundlage, um zu verstehen, aus welchen Bestandteilen Softwareprodukte bestehen, wie Abhängigkeiten strukturiert sind und wo Sicherheits- oder Compliance-Risiken entstehen können. Richtig umgesetzt ermöglichen SBOMs schnellere Bewertungen der Auswirkungen von Schwachstellen, eine effektivere Incident Response sowie eine klarere Kommunikation über technische, rechtliche und organisatorische Grenzen hinweg. Darüber hinaus bieten sie Aufsichtsbehörden und Kunden eine konkrete Möglichkeit zu beurteilen, ob ein Unternehmen tatsächlich Kontrolle über seine Softwarelandschaft ausübt. Gleichzeitig hat Bitsea ENISA Rückmeldungen gegeben, in denen praxisrelevante Aspekte hervorgehoben werden, die entscheidend für eine wirksame SBOM-Umsetzung sind. Vom der konzeptionellen SBOM zur praktisch nutzbaren Lösung Eine zentrale Beobachtung ist, dass SBOMs häufig auf sehr abstrakter Ebene beschrieben werden und sich primär auf vollständige Softwarekomponenten oder Pakete konzentrieren. In der Praxis moderner Softwareentwicklung kommt teilweise Code-Wiederverwendung häufig vor, etwa durch einzelne Dateien, Verzeichnisse oder Codefragmente aus größeren Projekten. Diese Form der Wiederverwendung hat unmittelbare Auswirkungen auf Lizenzierung, Urheberrecht und Sicherheitsrisiken. Eine praktisch nutzbare SBOM sollte daher partielle Komponenten und feinkörnige Wiederverwendung abbilden, statt immer vollständige, versionierte Pakete vorauszusetzen. Eng damit verbunden ist die weit verbreitete informelle Wiederverwendung von Codeschnipseln, beispielsweise aus öffentlichen Foren oder Wissensplattformen. Solche Schnipsel können urheberrechtlich geschützt sein, Lizenzpflichten nach sich ziehen oder bekannte Schwachstellen enthalten. Auch wenn diese Art der Wiederverwendung selten aus bewusster Missachtung der Compliance entsteht, stellt sie ein reales und wiederkehrendes Risiko dar. Bitsea hat daher darauf hingewiesen, dass SBOM-Leitlinien diese Realität explizit anerkennen und Organisationen dazu anregen sollten, sie in ihre Softwareinventare und Compliance-Prozesse einzubeziehen. Über den Quellcode hinaus: Berücksichtigung von Nicht-Code-Artefakten Ein weiterer wichtiger Aspekt ist, dass Softwareprodukte in der Regel nicht nur aus Quellcode bestehen. Dokumentation, Konfigurationsdateien, Bilder, Schriftarten, Medieninhalte und andere Nicht-Code-Artefakte werden häufig als Teil von Softwaredistributionen ausgeliefert. Diese Elemente unterliegen oft eigenen Lizenz- und Schutzrechtsregelungen und können sowohl rechtliche als auch operative Risiken mit sich bringen. Bitsea empfiehlt daher, die SBOM-Diskussion über den Fokus auf Quellcode hinaus zu erweitern und diese zusätzlichen Artefakttypen ausdrücklich als Teil der Software Bill of Materials anzuerkennen. Ein typisches Beispiel für ein solches Nicht-Code-Artefakt ist die Einbindung einer Open-Source-Schriftart in eine Anwendung, ein Firmware-Image oder ein Dokumentationspaket. Viele verbreitete Schriftarten stehen unter der SIL Open Font License (OFL), die Einbettung, Modifikation und Weiterverbreitung erlaubt, jedoch bestimmte Bedingungen stellt, etwa die Beibehaltung von Copyright-Hinweisen und Einschränkungen bei der Verwendung reservierter Schriftartnamen. KI-generierter Code Der ENISA-Bericht sieht KI-generierten Code als Herausforderung an, doch aus Sicht von Bitsea sollte dieses Thema stärker betont werden. In der Praxis ist KI-gestützte Softwareentwicklung bereits ein wesentlicher Faktor in vielen Codebasen. KI-generierte Ergebnisse können bestehenden Open-Source-Komponenten sehr ähnlich sein, teilweise ohne klare Attribution oder eindeutig identifizierbaren... The EU’s growing focus on SBOMs, highlighted in ENISA’s SBOM Landscape Analysis – Towards an Implementation Guide, is a key step toward greater transparency and resilience in software supply chains. SBOMs are rapidly becoming a central building block for cybersecurity governance under the Cyber Resilience Act (CRA) and related frameworks. From Bitsea’s perspective, this direction is both necessary and overdue. SBOMs provide a shared factual basis for what a product contains, its dependencies, and potential security or compliance risks. Implemented well, they speed up vulnerability assessments, improve incident response, and clarify communication across technical, legal, and organizational teams. They also give regulators and customers a clear view of an organization’s control over its software. Bitsea has also shared feedback with ENISA on practical considerations needed to make SBOM guidance effective in real-world use. Moving from Conceptual SBOMs to Practically Usable Ones One key observation is that SBOMs often describe software at a very high level, focusing primarily on complete components or packages. In practice, however, modern software development frequently involves partial reuse, individual files, directories, or code fragments extracted from larger projects. This form of reuse has direct implications for licensing, copyright attribution, and security exposure. A practically usable SBOM should reflect partial components and fine-grained reuse, instead of assuming that software is always used as complete, versioned packages. Closely related is the widespread informal reuse of code snippets, including those copied from public forums or knowledge-sharing platforms. Such snippets may be subject to copyright, carry licensing obligations, or embed known vulnerabilities. While this type of reuse is rarely intentional non-compliance, it represents a real and recurring risk. Bitsea emphasizes that SBOM guidance should acknowledge this reality and encourage organizations to include it in their software inventory and compliance processes. Beyond Source Code: Accounting for Non-Code Artifacts Another important consideration is that software products rarely consist of source code alone. Documentation, configuration files, images, fonts, media assets, and other non-code artifacts are routinely shipped as part of software distributions. These elements carry their own licensing and IP constraints, creating legal and operational risks. Bitsea recommends expanding SBOMs beyond source code to include such artifacts. A common example is including an open-licensed font in an application, firmware, or documentation. Widely used fonts under the SIL Open Font License (OFL) allow embedding, modification, and redistribution, while requiring copyright notice preservation and restricting reserved font names. AI-Generated Code and Emerging Provenance Risks ENISA’s report acknowledges AI-generated code as a limitation and challenge, but Bitsea believes this topic needs stronger emphasis. In practice, AI-assisted development is already a significant factor in many codebases. AI-generated outputs may closely resemble existing open source components, sometimes without clear attribution or identifiable licensing context. This raises novel questions around provenance, compliance, and risk allocation. At a minimum, SBOM guidance should raise awareness of these risks and recommend measures for identifying and managing AI-assisted or AI-generated code within SBOM-driven workflows. SBOMs and License Compliance: Foundation, Not a Shortcut Organizations must understand SBOMs as foundational data structures, not as a... Introduction to the Syscall Exception The syscall exception maps closely to how the Linux kernel exposes its user-space interface. The boundary covered by the syscall note primarily consists of the kernel’s user-space API (UAPI), which is implemented through header files intended for inclusion by user programs. These headers live mainly under the include/uapi/ directory (and its architecture-specific counterparts under arch/*/include/uapi/) and define system call numbers, data structures, constants, and ioctl interfaces required to interact with the kernel. The Kernel’s User-Space API (UAPI) These files are explicitly designed to be stable, consumable from user space, and free of kernel-internal implementation details. In contrast, headers under include/linux/ and other internal directories describe kernel-only interfaces and are not part of the syscall exception. While a small number of legacy or compatibility interfaces fall outside /uapi, the guiding principle is consistent: only published, user-facing interfaces required to invoke kernel services via the normal system calls fall within the scope of the syscall note, not kernel-internal APIs or implementation code. Licensing Implications of System Calls People often quote the Linux kernel’s well-known “system call exception,” but they rarely fully understand it. In a short yet consequential licensing note, Linus Torvalds clarified that user programs invoking kernel services through normal system calls do not count as derivative works of the kernel and therefore do not fall under the GPL’s copyleft requirements. This statement was an explicit articulation of authorial intent about where the boundary of the GPL-covered “Program” should lie. Linux designed system calls as a stable, published interface for external and independent software and has taken great care to preserve that stability across versions. Copyright Law and Functional Interfaces This position aligns closely with how copyright law treats software interfaces. Copyright protects expressive elements, not ideas, procedures, or methods of operation, and the U. S. courts have repeatedly struggled to draw clear lines when it comes to software integration. The core legal question is not whether two pieces of software interact, but whether one substantially incorporates protected expression from the other. APIs and system calls generally sit on the functional side of that divide. The long-running uncertainty around “derivative works” in software has left courts with few definitive answers, but analysts conclude that interoperability alone cannot establish derivation, especially when interfaces are designed for that purpose. Case Law Supporting the Syscall Exception Recent case law form a US court reinforces this direction. In Oracle v. Rimini Street, the ninth circuit court explicitly rejected the idea that mere interoperability/interacting makes a work derivative, emphasizing that a derivative work must actually incorporate protected material from the original. This reasoning echoes earlier decisions such as Lotus v. Borland, where functional interfaces were treated as uncopyrightable methods of operation. While these cases do not resolve every GPL boundary question, they strongly support the conceptual distinction that Linux has applied in practice for decades: tightly integrated internal components may trigger copyleft obligations, but published, stable interfaces such as system calls generally do not. Diverging Views in the Copyleft Community It... Die Syscall-Ausnahme orientiert sich eng daran, wie der Linux-Kernel seine Benutzerschnittstelle nach User Space bereitstellt. Der durch die Syscall-Notiz abgedeckte Bereich besteht in erster Linie aus der User-Space-API (UAPI) des Kernels, die über Header-Dateien implementiert ist, die zur Einbindung durch Benutzerprogramme vorgesehen sind. Diese Header befinden sich hauptsächlich im Verzeichnis include/uapi/ (sowie in den architekturspezifischen Gegenstücken unter arch/*/include/uapi/) und definieren Systemaufrufnummern, Datenstrukturen, Konstanten und ioctl-Schnittstellen, die für die Interaktion mit dem Kernel erforderlich sind. Diese Dateien sind ausdrücklich darauf ausgelegt, stabil zu sein, aus dem User Space genutzt zu werden und keine kernelinternen Implementierungsdetails zu enthalten. User-Space-API (UAPI) versus kernelinterne Schnittstellen Im Gegensatz dazu beschreiben Header unter include/linux/ und anderen internen Verzeichnissen ausschließlich kernelinterne Schnittstellen und sind nicht Teil der Syscall-Ausnahme. Auch wenn eine kleine Anzahl von Legacy- oder Kompatibilitätsschnittstellen außerhalb von /uapi liegt, bleibt das leitende Prinzip gleich: Nur veröffentlichte, benutzerseitige Schnittstellen, die erforderlich sind, um Kernel-Dienste über die normalen Systemaufrufe aufzurufen, fallen in den Geltungsbereich der Syscall-Notiz – nicht jedoch kernelinterne APIs oder Implementierungscode. Zweck und Bedeutung der Linux-Systemaufrufausnahme Die bekannte „Systemaufrufausnahme” des Linux-Kernels wird oft zitiert, aber selten vollständig verstanden. In einer kurzen, aber folgenreichen Lizenzanmerkung stellte Linus Torvalds klar, dass Benutzerprogramme, die Kernel-Dienste über normale Systemaufrufe aufrufen, nicht als abgeleitete Werke des Kernels gelten und daher nicht unter die Copyleft-Anforderungen der GPL fallen. Diese Erklärung war eine ausdrückliche Formulierung der Absicht des Autors, wo die Grenze des von der GPL abgedeckten „Programms” liegen sollte. Systemaufrufe wurden als stabile, veröffentlichte Schnittstelle für externe und unabhängige Software konzipiert, und Linux hat große Anstrengungen unternommen, um diese Stabilität über alle Versionen hinweg zu erhalten. Systemaufrufe im Kontext des Urheberrechts Diese Position steht in engem Zusammenhang mit der Behandlung von Software-Schnittstellen im Urheberrecht. Das Urheberrecht schützt Ausdruckselemente, nicht Ideen, Verfahren oder Betriebsmethoden, und die US-Gerichte hatten wiederholt Schwierigkeiten, klare Grenzen in Bezug auf die Software-Integration zu ziehen. Die zentrale rechtliche Frage ist nicht, ob zwei Softwareprodukte miteinander interagieren, sondern ob eines davon wesentliche geschützte Ausdruckselemente des anderen enthält. APIs und Systemaufrufe liegen in der Regel auf der funktionalen Seite dieser Trennlinie. Die seit langem bestehende Unsicherheit in Bezug auf „abgeleitete Werke” in der Software hat nur wenige definitive gerichtliche Antworten hervorgebracht, aber die vorherrschende Analyse deutet darauf hin, dass Interoperabilität allein nicht ausreicht, um eine Ableitung zu begründen, insbesondere wenn Schnittstellen für diesen Zweck entwickelt wurden. Rechtsprechung zu Interoperabilität und abgeleiteten Werken Die jüngste Rechtsprechung eines US-Gerichts bestätigt diese Ausrichtung. Im Fall Oracle gegen Rimini Street lehnte das Berufungsgericht des neunten Bezirks ausdrücklich die Auffassung ab, dass bloße Interoperabilität/Interaktion ein Werk zu einem abgeleiteten Werk macht, und betonte, dass ein abgeleitetes Werk tatsächlich geschütztes Material aus dem Original enthalten muss. Diese Argumentation spiegelt frühere Entscheidungen wie Lotus gegen Borland wider, in denen funktionale Schnittstellen als nicht urheberrechtsfähige Betriebsmethoden behandelt wurden. Diese Fälle klären zwar nicht alle Fragen zu den Grenzen der GPL, stützen jedoch nachdrücklich die konzeptionelle Unterscheidung, die Linux seit Jahrzehnten in der Praxis anwendet: Eng integrierte interne Komponenten können Copyleft-Verpflichtungen auslösen, veröffentlichte, stabile Schnittstellen wie Systemaufrufe hingegen in... Introduction to the Syscall Exception The syscall exception maps closely to how the Linux kernel exposes its user-space interface. The boundary covered by the syscall note primarily consists of the kernel’s user-space API (UAPI), which is implemented through header files intended for inclusion by user programs. These headers live mainly under the include/uapi/ directory (and its architecture-specific counterparts under arch/*/include/uapi/) and define system call numbers, data structures, constants, and ioctl interfaces required to interact with the kernel. The Kernel’s User-Space API (UAPI) These files are explicitly designed to be stable, consumable from user space, and free of kernel-internal implementation details. In contrast, headers under include/linux/ and other internal directories describe kernel-only interfaces and are not part of the syscall exception. While a small number of legacy or compatibility interfaces fall outside /uapi, the guiding principle is consistent: only published, user-facing interfaces required to invoke kernel services via the normal system calls fall within the scope of the syscall note, not kernel-internal APIs or implementation code. Licensing Implications of System Calls People often quote the Linux kernel’s well-known “system call exception,” but they rarely fully understand it. In a short yet consequential licensing note, Linus Torvalds clarified that user programs invoking kernel services through normal system calls do not count as derivative works of the kernel and therefore do not fall under the GPL’s copyleft requirements. This statement was an explicit articulation of authorial intent about where the boundary of the GPL-covered “Program” should lie. Linux designed system calls as a stable, published interface for external and independent software and has taken great care to preserve that stability across versions. Copyright Law and Functional Interfaces This position aligns closely with how copyright law treats software interfaces. Copyright protects expressive elements, not ideas, procedures, or methods of operation, and the U. S. courts have repeatedly struggled to draw clear lines when it comes to software integration. The core legal question is not whether two pieces of software interact, but whether one substantially incorporates protected expression from the other. APIs and system calls generally sit on the functional side of that divide. The long-running uncertainty around “derivative works” in software has left courts with few definitive answers, but analysts conclude that interoperability alone cannot establish derivation, especially when interfaces are designed for that purpose. Case Law Supporting the Syscall Exception Recent case law form a US court reinforces this direction. In Oracle v. Rimini Street, the ninth circuit court explicitly rejected the idea that mere interoperability/interacting makes a work derivative, emphasizing that a derivative work must actually incorporate protected material from the original. This reasoning echoes earlier decisions such as Lotus v. Borland, where functional interfaces were treated as uncopyrightable methods of operation. While these cases do not resolve every GPL boundary question, they strongly support the conceptual distinction that Linux has applied in practice for decades: tightly integrated internal components may trigger copyleft obligations, but published, stable interfaces such as system calls generally do not. Diverging Views in the Copyleft Community It... In September 2025, the npm ecosystem experienced one of the most consequential software supply-chain compromises to date. A self-propagating worm, now commonly referred to as Shai-Hulud, compromised hundreds of npm packages, harvested developer and CI/CD credentials, and used those credentials to spread laterally across the ecosystem by publishing further malicious updates under the identities of legitimate maintainers. Within weeks, a second wave followed, often called “Shai-Hulud 2. 0” which refined the original techniques, removed earlier bottlenecks, and dramatically increased the scale of the attack, ultimately affecting hundreds of packages and tens of thousands of GitHub repositories. How the Attack Worked: Credential Theft and Worm-Like Propagation Researchers have now well documented the technical mechanics of the attack. Attackers commonly gained initial access through phishing or stolen tokens, then injected malicious code into npm packages, often using lifecycle hooks such as preinstall or postinstall scripts. Once executed, the malware searched developer machines and CI environments for secrets, including npm tokens, GitHub personal access tokens, SSH keys, and cloud provider credentials, and exfiltrated them to attacker-controlled GitHub repositories. In many cases, the malware also installed or modified GitHub Actions workflows to establish persistence and continue harvesting secrets over time. The most novel aspect lies in the worm-like propagation mechanism: when the malware found valid npm credentials, it automatically published malicious versions of other packages owned by the compromised maintainer, turning normal package publishing workflows into an amplification vector. Exploiting Trust Assumptions in Modern Software Development What makes Shai-Hulud particularly significant is not merely its scale, but the fact that it did not rely on exploiting a single vulnerability or a novel flaw in npm itself. Instead, it exploited a set of deeply embedded assumptions that underpin modern software development. Developers assume that a package name delivers the code they expect, that legitimate maintainers author published packages, that distributed artifacts match the reviewed source code, and that CI/CD systems serve only the projects they belong to. These assumptions are not accidental; they are what make large-scale reuse of open source software possible. Yet Shai-Hulud demonstrated how easily these assumptions can be weaponized once identity and automation are compromised. Immediate Responses: Dependency Auditing, SBOMs, and Their Limits In the immediate aftermath of the attack, guidance from vendors and public authorities consistently emphasized dependency auditing, version pinning, credential rotation, and the use of lockfiles to identify affected components. This response was appropriate, but it is important to be precise about what these measures can and cannot achieve. Software Bills of Materials (SBOM) and Software Composition Analysis (SCA) tools effectively answer questions such as whether a system contains a given package or version, when someone introduced it, and how widely it propagated across environments. In other words, these tools play an essential role in incident response, scoping, and remediation. Without accurate dependency inventories, many organizations could not determine whether attackers affected them at all. SBOMs as Visibility Infrastructure, Not Preventive Control While SBOMs and SCA do not detect malicious intent in newly published packages, they play a... Im September 2025 widerfuhr dem npm-Ökosystem eine der bislang folgenschwersten Kompromittierungen der Software-Lieferkette. Ein sich selbst verbreitender Wurm, der heute allgemein als Shai-Hulud bezeichnet wird, kompromittierte Hunderte von npm-Paketen, sammelte Entwickler- und CI/CD-Anmeldedaten und nutzte diese Anmeldedaten, um sich im Ökosystem zu verbreiten, indem er unter der Identität legitimer Nutzer weitere bösartige Updates veröffentlichte. Innerhalb weniger Wochen folgte eine zweite Welle, oft als „Shai-Hulud 2. 0” bezeichnet, die die ursprünglichen Techniken verfeinerte, frühere Engpässe beseitigte und den Umfang des Angriffs dramatisch vergrößerte, sodass letztendlich hunderte von Paketen und Zehntausende von GitHub-Repositorys betroffen waren. Wie der Angriff ablief: Diebstahl von Anmeldedaten und wurmartige Verbreitung. Die technischen Mechanismen des Angriffs sind mittlerweile gut dokumentiert. Der erste Zugriff erfolgte über Phishing oder gestohlene Tokens, woraufhin bösartiger Code in npm-Pakete eingeschleust wurde, häufig über Hooks wie Preinstall- oder Postinstall-Skripte. Nach der Ausführung durchsuchte die Malware die Rechner der Entwickler und CI-Umgebungen nach npm-Tokens, persönlichen GitHub-Zugriffstokens, SSH-Schlüssel und Anmeldedaten von Cloud-Anbietern, und schleuste diese in von Angreifern kontrollierte GitHub-repositories. In vielen Fällen installierte oder modifizierte die Malware auch GitHub-Actions-Workflows, um Persistenz zu erreichen und weiterhin „secrets“ zu sammeln. Der neuartigste Aspekt war der wurmartige Verbreitungsmechanismus: Fand die Malware gültige npm-Anmeldedaten, veröffentlichte sie automatisch bösartige Versionen weiterer Pakete des kompromittierten Maintainers und verwandelte reguläre Paketveröffentlichungs-Workflows in einen Verstärkungsvektor. Ausnutzung von Vertrauensannahmen in der modernen Softwareentwicklung Was Shai-Hulud besonders bedeutsam macht, ist nicht nur sein Umfang, sondern auch die Tatsache, dass es nicht auf der Ausnutzung einer einzelnen Schwachstelle oder eines neuartigen Fehlers in npm selbst beruhte. Stattdessen nutzte es eine Reihe tief verwurzelter Annahmen aus, die der modernen Softwareentwicklung zugrunde liegen: Entwickler gehen davon aus, dass ein Paketname zu dem von ihnen erwarteten Code führt, dass veröffentlichte Pakete von ihren legitimen Entwicklern erstellt wurden, dass verteilte Artefakte dem überprüften Quellcode entsprechen und dass CI/CD-Systeme ausschließlich im Dienste des Projekts stehen, zu dem sie gehören. Diese Annahmen sind kein Zufall, sondern ermöglichen die großflächige Wiederverwendung von Open-Source-Software. Shai-Hulud hat jedoch gezeigt, wie leicht diese Annahmen als Waffe eingesetzt werden können, sobald Identität und Automatisierung kompromittiert sind. Sofortmaßnahmen: Abhängigkeitsprüfung, SBOMs und ihre Grenzen Unmittelbar nach dem Angriff betonten Hersteller und Behörden in ihren Leitlinien durchweg die Bedeutung von Abhängigkeitsprüfungen, Versionsfestlegung, Rotation von Anmeldedaten und der Verwendung von Lockfiles zur Identifizierung betroffener Komponenten. Diese Reaktion war in ordnung, aber es ist wichtig, genau zu wissen, was diese Maßnahmen leisten können und was nicht. Software Bills of Materials (SBOM) und Software Composition Analysis (SCA)-Tools sind äußerst effektiv, um Fragen zu beantworten, ob ein bestimmtes Paket oder eine bestimmte Version in einem System vorhanden war, wann es eingeführt wurde und wie weit es sich in den Umgebungen verbreitet hat. Mit anderen Worten: Sie sind für die Analyse von Vorfällen, Bewertung der Auswirkung und die Behebung unerlässlich. Ohne genaue Kenntnisse der Abhängigkeiten wären viele Unternehmen nicht in der Lage gewesen, festzustellen, ob sie überhaupt betroffen waren. SBOMs als Infrastruktur für Transparenz, nicht als präventive Kontrolle SBOMs und SCA erkennen zwar keinen böswilligen Code in neu veröffentlichten Paketen, spielen jedoch eine entscheidende Rolle,... In September 2025, the npm ecosystem experienced one of the most consequential software supply-chain compromises to date. A self-propagating worm, now commonly referred to as Shai-Hulud, compromised hundreds of npm packages, harvested developer and CI/CD credentials, and used those credentials to spread laterally across the ecosystem by publishing further malicious updates under the identities of legitimate maintainers. Within weeks, a second wave followed, often called “Shai-Hulud 2. 0” which refined the original techniques, removed earlier bottlenecks, and dramatically increased the scale of the attack, ultimately affecting hundreds of packages and tens of thousands of GitHub repositories. How the Attack Worked: Credential Theft and Worm-Like Propagation Researchers have now well documented the technical mechanics of the attack. Attackers commonly gained initial access through phishing or stolen tokens, then injected malicious code into npm packages, often using lifecycle hooks such as preinstall or postinstall scripts. Once executed, the malware searched developer machines and CI environments for secrets, including npm tokens, GitHub personal access tokens, SSH keys, and cloud provider credentials, and exfiltrated them to attacker-controlled GitHub repositories. In many cases, the malware also installed or modified GitHub Actions workflows to establish persistence and continue harvesting secrets over time. The most novel aspect lies in the worm-like propagation mechanism: when the malware found valid npm credentials, it automatically published malicious versions of other packages owned by the compromised maintainer, turning normal package publishing workflows into an amplification vector. Exploiting Trust Assumptions in Modern Software Development What makes Shai-Hulud particularly significant is not merely its scale, but the fact that it did not rely on exploiting a single vulnerability or a novel flaw in npm itself. Instead, it exploited a set of deeply embedded assumptions that underpin modern software development. Developers assume that a package name delivers the code they expect, that legitimate maintainers author published packages, that distributed artifacts match the reviewed source code, and that CI/CD systems serve only the projects they belong to. These assumptions are not accidental; they are what make large-scale reuse of open source software possible. Yet Shai-Hulud demonstrated how easily these assumptions can be weaponized once identity and automation are compromised. Immediate Responses: Dependency Auditing, SBOMs, and Their Limits In the immediate aftermath of the attack, guidance from vendors and public authorities consistently emphasized dependency auditing, version pinning, credential rotation, and the use of lockfiles to identify affected components. This response was appropriate, but it is important to be precise about what these measures can and cannot achieve. Software Bills of Materials (SBOM) and Software Composition Analysis (SCA) tools effectively answer questions such as whether a system contains a given package or version, when someone introduced it, and how widely it propagated across environments. In other words, these tools play an essential role in incident response, scoping, and remediation. Without accurate dependency inventories, many organizations could not determine whether attackers affected them at all. SBOMs as Visibility Infrastructure, Not Preventive Control While SBOMs and SCA do not detect malicious intent in newly published packages, they play a... Ein Überblick über die Creative Commons-Lizenzsuite Creative Commons (CC) Lizenzsuite wurde entwickelt, um die Weitergabe kreativer Werke zu vereinfachen und gleichzeitig den Urhebern eine gewisse Kontrolle über die Verwendung ihrer Werke zu ermöglichen. Die Creative Commons Foundation wurde 2001 von Lawrence Lessig, Hal Abelson und Eric Eldred gegründet und hat einen flexiblen rechtlichen Rahmen geschaffen, der die Zusammenarbeit und den offenen Austausch von Ideen fördert. Das Ziel von Creative Commons ist einfach: Menschen dabei zu helfen, Wissen, Kreativität und Innovation frei zu teilen – und gleichzeitig sicherzustellen, dass die Urheber genannt und geschützt werden. Diese Lizenzen sind in Kunst, Wissenschaft und Medien weit verbreitet, haben aber auch Eingang in die Softwareentwicklung gefunden. Zu verstehen, wie CC-Lizenzen funktionieren – und wo sie in die Open-Source-Welt passen –, ist für jeden, der mit gemeinsam genutztem Code arbeitet, von entscheidender Bedeutung. Was bedeuten die Creative-Commons-Lizenzen? Im Folgenden finden Sie eine Übersicht über die wichtigsten Creative-Commons-Lizenzen, ihre Funktionsweise und worauf Sie als Entwickler oder Open-Source-Mitwirkender achten sollten. CC BY (Namensernennung) Als flexibelste der CC-Lizenzen erlaubt CC BY anderen, Ihr Werk zu verbreiten, zu remixen, anzupassen und darauf aufzubauen, sogar für kommerzielle Zwecke, solange sie Sie ordnungsgemäß als Urheber nennen. Bei Software eignet sich dies gut für Documentation, Tutorials, and Code-Schnipsel, bei denen eine breite Wiederverwendung erwünscht ist. Es ermöglicht die Integration Ihres Werks in andere Projekte, einschließlich proprietärer Software, sofern die Urheberschaft angegeben wird. CC BY-SA (Namensnennung – Weitergabe unter gleichen Bedingungen) Diese Lizenz ähnelt CC-BY, enthält jedoch eine wichtige zusätzliche Bedingung: Wenn jemand Ihr Werk verändert, muss er seine Version unter derselben Lizenz weitergeben. Dadurch bleiben Verbesserungen offen und zugänglich, was jedoch bei kommerzieller Software zu Problemen führen kann. Wenn beispielsweise CC BY-SA-Code von einer Website wie Stack Overflow in ein proprietäres Programm integriert wird, muss möglicherweise das gesamte Programm unter CC BY-SA lizenziert werden. Diese „ShareAlike“-Anforderung kann zu Konflikten mit Closed-Source-Modellen führen oder sogar rechtliche Risiken mit sich bringen. Außerdem kann es zu Kompatibilitätsproblemen mit anderen Open-Source-Lizenzen kommen, wie beispielsweise der GPL, die ihre eigenen Vertriebsbedingungen hat. CC BY-ND (Namensnennung – Keine Bearbeitungen) Diese Lizenz erlaubt die Weitergabe, kommerziell oder anderweitig, aber keine Änderungen. Bei Software bedeutet dies, dass andere Ihren Code weitergeben, aber nicht ändern dürfen, was die Zusammenarbeit einschränkt und für Open-Source-Projekte unpraktisch macht. CC BY-NC (Namensnennung – Nicht kommerziell) Diese Lizenz erlaubt es anderen, Ihr Werk zu remixen, anzupassen und darauf aufzubauen, jedoch nicht für kommerzielle Zwecke. Das klingt verlockend, ist jedoch für die Softwareentwicklung oft zu restriktiv. Die Einschränkung „nicht kommerziell” kann verhindern, dass Code in kommerziellen Produkten oder auf umsatzgenerierenden Plattformen verwendet wird, selbst indirekt (wie bei werbefinanzierten Diensten). CC BY-NC-SA (Namensnennung – Nicht kommerziell – Weitergabe unter gleichen Bedingungen) Diese Lizenz kombiniert die Anforderungen „Nicht kommerziell“ und „Weitergabe unter gleichen Bedingungen“. Abgeleitete Werke müssen ebenfalls nicht kommerziell sein und unter denselben Bedingungen lizenziert werden. Sie fördert Offenheit, ist jedoch aufgrund ihrer doppelten Einschränkungen für professionelle Softwareumgebungen ungeeignet, in denen Flexibilität bei der Lizenzierung oder kommerzielle Integration erforderlich ist. CC BY-NC-ND (Attribution–NonCommercial–NoDerivatives) Dies ist die restriktivste Creative-Commons-Lizenz.... An Overview of the Creative Commons License SuiteBy Marcus Lucero, Senior Open Source Analyst at Bitsea The Creative Commons (CC) license suite was designed to make sharing creative work easier while allowing creators to retain some control over how their work is used. Founded in 2001 by Lawrence Lessig, Hal Abelson, and Eric Eldred, the Creative Commons Foundation built a flexible legal framework that encourages collaboration and the open exchange of ideas. The goal of Creative Commons is simple: to help people share knowledge, creativity, and innovation freely—while ensuring that creators are credited and protected. These licenses are widely used across art, academia, and media, but they’ve also found their way into software development. Understanding how CC licenses work—and where they fit in the open-source world, is essential for anyone working with shared code. What the Creative Commons Licenses Mean Below is a breakdown of the main Creative Commons licenses, how they work, and what to watch for if you’re a developer or open-source contributor. CC BY (Attribution) The most flexible of the CC licenses, CC BY lets others distribute, remix, adapt, and build upon your work, even for commercial purposes, as long as they give you proper credit. In software, this works well for documentation, tutorials, and code snippets where broad reuse is encouraged. It allows your work to be integrated into other projects, including proprietary software, provided attribution is given. CC BY-SA (Attribution–ShareAlike) This license is like CC-BY, but adds a key condition: if someone modifies your work, they must share their version under the same license. While this keeps improvements open and accessible, it can cause problems in commercial software. For example, if CC BY-SA code from a site like Stack Overflow is included in a proprietary program, the entire program might need to be licensed under CC BY-SA. This “ShareAlike” requirement can conflict with closed-source models or even create legal exposure. It can also raise compatibility issues with other open-source licenses, such as the GPL, which has its own distribution terms. CC BY-ND (Attribution–NoDerivatives) This license allows redistribution, commercial or otherwise, but doesn’t allow modifications. In software, this means others can share your code but can’t change it, which limits collaboration and makes it impractical for open-source projects. CC BY-NC (Attribution–NonCommercial) This license lets others remix, adapt, and build upon your work, but not for commercial purposes. It sounds appealing, but it’s often too restrictive for software development. The “non-commercial” limitation can prevent code from being used in commercial products or on revenue-generating platforms, even indirectly (like ad-supported services). CC BY-NC-SA (Attribution–NonCommercial–ShareAlike) This combines the non-commercial and ShareAlike requirements. Derivative works must also be non-commercial and licensed under the same terms. It promotes openness, but its dual restrictions make it unsuitable for professional software environments where licensing flexibility or commercial integration is needed. CC BY-NC-ND (Attribution–NonCommercial–NoDerivatives) This is the most restrictive Creative Commons license. It allows sharing with credit, but no modifications or commercial use. For software, this makes it almost entirely unusable, it prevents adapting,... An Overview of the Creative Commons License Suite Creative Commons (CC) designed its license suite to make sharing creative work easier while allowing creators to retain some control over how others use their work. Founded in 2001 by Lawrence Lessig, Hal Abelson, and Eric Eldred, the Creative Commons Foundation built a flexible legal framework that encourages collaboration and the open exchange of ideas. Creative Commons aims to help people share knowledge, creativity, and innovation freely while ensuring that creators receive credit and protection. Artists, academics, and media creators widely use these licenses, and software developers have adopted them as well. Understanding how CC licenses work—and where they fit in the open-source world, is essential for anyone working with shared code. What the Creative Commons Licenses Mean Below is a breakdown of the main Creative Commons licenses, how they work, and what to watch for if you’re a developer or open-source contributor. CC BY (Attribution) The most flexible of the CC licenses, CC BY lets others distribute, remix, adapt, and build upon your work, even for commercial purposes, as long as they give you proper credit. In software, developers can use this for documentation, tutorials, and code snippets where broad reuse is encouraged. It lets others integrate your work into their projects, including proprietary software, as long as they provide proper attribution. CC BY-SA (Attribution–ShareAlike) This license is like CC-BY, but adds a key condition: if someone modifies your work, they must share their version under the same license. While this keeps improvements open and accessible, it can cause problems in commercial software. For example, including CC BY-SA code from a site like Stack Overflow in a proprietary program may require you to license the entire program under CC BY-SA. This “ShareAlike” requirement can conflict with closed-source models or even create legal exposure. It can also raise compatibility issues with other open-source licenses, such as the GPL, which has its own distribution terms. CC BY-ND (Attribution–NoDerivatives) This license allows redistribution, commercial or otherwise, but doesn’t allow modifications. In software, this means others can share your code but can’t change it, which limits collaboration and makes it impractical for open-source projects. CC BY-NC (Attribution–NonCommercial) This license lets others remix, adapt, and build upon your work, but not for commercial purposes. It sounds appealing, but it’s often too restrictive for software development. The “non-commercial” limitation stops developers from using code in commercial products or on revenue-generating platforms, even indirectly through ad-supported services. CC BY-NC-SA (Attribution–NonCommercial–ShareAlike) This combines the non-commercial and ShareAlike requirements. Derivative works must also be non-commercial and licensed under the same terms. It promotes openness, but its dual restrictions prevent developers from using it in professional software environments that require licensing flexibility or commercial integration. CC BY-NC-ND (Attribution–NonCommercial–NoDerivatives) This is the most restrictive Creative Commons license. It allows sharing with credit, but no modifications or commercial use. For software, this makes it almost entirely unusable, it prevents adapting, improving, or integrating code into larger systems. Why CC BY-SA Can Be a... When you work with open source software, you eventually come across a licensing issue that needs fixing. Maybe a GPL component found its way into your proprietary code, or you discovered a library with no clear license at all. That’s where remediation comes in. At Bitsea, we don’t just identify licensing risks, we help you fix them. Our team works directly with engineers and legal teams to clean up code, stay compliant, and keep your release schedule on track. Why Remediation Matters Remediation isn’t just about playing it safe, it’s about protecting your product, your team, and your reputation. Common reasons to remediate include: Strong copyleft licenses like GPL or AGPL that can require you to release your own source code. Commercial licenses you can’t afford or don’t have rights to use. Weak copyleft licenses (like MPL or LGPL) used incorrectly. Attribution requirements that are difficult or impossible to meet (like requiring a homepage link). Code with unknown or missing license information. Basic Ways to Remediate Remove the codeSometimes the simplest fix is to delete the problem component and plan to restore that feature later. Follow the licenseAdd missing notices, release required code or purchase the proper license to stay in compliance. Replace the libraryUse a similar component with a more permissive license, like MIT or Apache. Test it carefully before release. Accept the risk (with caution)In limited cases, you might choose to accept minor risk if the component is widely used and has a low impact. But this should always be a documented, informed decision not a default. More Advanced Options Ask the author for a new licenseIt never hurts to ask. Many open-source developers are open to granting an MIT or commercial license if you reach out directly. Re-engineer through clean room designRecreate the functionality without copying code from the original. It takes time, but it removes the risk completely. Start a new open-source projectIf the existing license is too restrictive, building your own open-source alternative can sometimes be the best long-term move. How Bitsea Helps At Bitsea, remediation is one of our key service areas. We help your organization: Prioritize which issues need attention first. Identify safe and compatible replacement components. Create attributions and notices to stay compliant. Coordinate between engineering and legal teams. Build long-term open-source policies that prevent future issues. Our goal is to make open-source compliance approachable, sustainable, and stress-free — not a roadblock. Questions to Guide Your Team When reviewing your Bitsea audit report, here are some helpful questions to discuss internally:For... all components Is it distributed, and in what form? Has it been modified? Are those changes compliant? Are license terms being followed? Are source links and attributions in place? copied or third-party code What’s the true source of the code? What does it do — is it part of your core IP? Can it be replaced or rebuilt? copyleft licenses (GPL, LGPL, AGPL, etc. ) Is it linked with proprietary code? Is your use compliant? Can you use a permissive or... Wenn Sie mit Open-Source-Software arbeiten, stoßen Sie irgendwann auf ein Lizenzproblem, das behoben werden muss. Vielleicht hat sich eine GPL-Komponente in Ihren proprietären Code eingeschlichen, oder Sie haben eine Bibliothek entdeckt, deren Lizenz überhaupt nicht klar ist. Hier kommt die Remediation ins Spiel. Bei Bitsea identifizieren wir nicht nur Lizenzierungsrisiken, sondern helfen Ihnen auch dabei, diese zu beheben. Unser Team arbeitet direkt mit Ingenieuren und Rechtsteams zusammen, um den Code zu bereinigen, die Compliance zu gewährleisten und Ihren Release-Zeitplan einzuhalten. Warum Remediation wichtig ist Bei der Remediation geht es nicht nur darum, auf Nummer sicher zu gehen, sondern auch darum, Ihr Produkt, Ihr Team und Ihren Ruf zu schützen. Häufige Gründe für eine Nachbesserung sind: Starke Copyleft-Lizenzen wie GPL oder AGPL, die Sie dazu verpflichten können, Ihren eigenen Quellcode zu veröffentlichen. Kommerzielle Lizenzen, die Sie sich nicht leisten können oder für deren Nutzung Sie keine Rechte haben. Schwache Copyleft-Lizenzen (wie MPL oder LGPL), die falsch verwendet werden. Anforderungen zur Namensnennung, die schwer oder unmöglich zu erfüllen sind (z. B. die Angabe eines Links zur Homepage). Code mit unbekannten oder fehlenden Lizenzinformationen. Grundlegende Möglichkeiten zur Remediation Entfernen Sie den CodeManchmal ist die einfachste Lösung, die problematische Komponente zu löschen und diese Funktion später wiederherzustellen. Befolgen Sie die LizenzbedingungenFügen Sie fehlende Hinweise hinzu, veröffentlichen Sie den erforderlichen Code oder erwerben Sie die entsprechende Lizenz, um die Compliance zu gewährleisten. Ersetzen Sie die BibliothekVerwenden Sie eine ähnliche Komponente mit einer freizügigeren Lizenz, wie MIT oder Apache. Testen Sie sie vor der Veröffentlichung sorgfältig. Akzeptieren Sie das Risiko (mit Vorsicht)In begrenzten Fällen können Sie sich dafür entscheiden, ein geringes Risiko zu akzeptieren, wenn die Komponente weit verbreitet ist und nur geringe Auswirkungen hat. Dies sollte jedoch immer eine dokumentierte, fundierte Entscheidung sein und nicht die Standardeinstellung. Weitere fortgeschrittene Optionen Fragen Sie den Autor nach einer neuen LizenzFragen kostet nichts. Viele Open-Source-Entwickler sind bereit, eine MIT- oder kommerzielle Lizenz zu gewähren, wenn Sie sich direkt an sie wenden. Neugestaltung durch Clean-Room-DesignDie Funktionalität neu erstellen, ohne Code aus dem Original zu kopieren. Das kostet Zeit, beseitigt aber das Risiko vollständig. Ein neues Open Source Project startenWenn die bestehende Lizenz zu restriktiv ist, kann es langfristig manchmal die beste Lösung sein, eine eigene Open-Source-Alternative zu entwickeln. Wie Bitsea hilft Bei Bitsea ist die Behebung von Problemen einer unserer wichtigsten Servicebereiche. Wir helfen Ihrem Unternehmen dabei: Prioritäten zu setzen, welche Probleme zuerst angegangen werden müssen. Sichere und kompatible Ersatzkomponenten zu identifizieren. Zuordnungen und Hinweise zu erstellen, um die Compliance zu gewährleisten. Die Zusammenarbeit zwischen den technischen und rechtlichen Teams zu koordinieren. Langfristige Open-Source-Richtlinien zu entwickeln, die zukünftige Probleme verhindern Unser Ziel ist es, die Open-Source-Compliance zugänglich, nachhaltig und stressfrei zu gestalten – und nicht zu einem Hindernis. Fragen zur Anleitung Ihres Teams Bei der Überprüfung Ihres Bitsea-Prüfungsberichts sind hier einige hilfreiche Fragen, die Sie intern besprechen sollten: Für... alle Komponenten Wird es verteilt, und in welcher Fom? Wird es verteilt, und in welcher Form? Werden die Lizenzbedingungen eingehalten? Sind Quellenlinks und Urhebervermerke vorhanden? ... kopierten oder fremden Code... When you work with open source software, you eventually come across a licensing issue that needs fixing. Maybe a GPL component found its way into your proprietary code, or you discovered a library with no clear license at all. That’s where remediation comes in. At Bitsea, we don’t just identify licensing risks, we help you fix them. Our team works directly with engineers and legal teams to clean up code, stay compliant, and keep your release schedule on track. Why Remediation Matters Remediation isn’t just about playing it safe, it’s about protecting your product, your team, and your reputation. Common reasons to remediate include: Strong copyleft licenses like GPL or AGPL that can require you to release your own source code. Commercial licenses you can’t afford or don’t have rights to use. Weak copyleft licenses (like MPL or LGPL) used incorrectly. Attribution requirements that are difficult or impossible to meet (like requiring a homepage link). Code with unknown or missing license information. Basic Ways to Remediate Remove the codeSometimes the simplest fix is to delete the problem component and plan to restore that feature later. Follow the licenseAdd missing notices, release required code or purchase the proper license to stay in compliance. Replace the libraryUse a similar component with a more permissive license, like MIT or Apache. Test it carefully before release. Accept the risk (with caution)In limited cases, you might choose to accept minor risk if the component is widely used and has a low impact. But this should always be a documented, informed decision not a default. More Advanced Options Ask the author for a new licenseIt never hurts to ask. Many open-source developers are open to granting an MIT or commercial license if you reach out directly. Re-engineer through clean room designRecreate the functionality without copying code from the original. It takes time, but it removes the risk completely. Start a new open-source projectIf the existing license is too restrictive, building your own open-source alternative can sometimes be the best long-term move. How Bitsea Helps At Bitsea, remediation is one of our key service areas. We help your organization: Prioritize which issues need attention first. Identify safe and compatible replacement components. Create attributions and notices to stay compliant. Coordinate between engineering and legal teams. Build long-term open-source policies that prevent future issues. Our goal is to make open-source compliance approachable, sustainable, and stress-free — not a roadblock. Questions to Guide Your Team When reviewing your Bitsea audit report, here are some helpful questions to discuss internally:For... all components Is it distributed, and in what form? Has it been modified? Are those changes compliant? Are license terms being followed? Are source links and attributions in place? copied or third-party code What’s the true source of the code? What does it do — is it part of your core IP? Can it be replaced or rebuilt? copyleft licenses (GPL, LGPL, AGPL, etc. ) Is it linked with proprietary code? Is your use compliant? Can you use a permissive or... What CERT-In and SEBI Expect As software supply chain risks escalate globally, India has moved decisively to strengthen its regulatory posture. In recent years, two major regulatory bodies the Indian Computer Emergency Response Team (CERT-In) and the Securities and Exchange Board of India (SEBI) have issued guidelines that place the Software Bill of Materials (SBOM) at the heart of cybersecurity governance, particularly in the financial and public sectors. Together, these mandates represent a paradigm shift in how organizations must track, secure, and manage their software assets. SBOMs: A Strategic Tool for Cybersecurity and Compliance A Software Bill of Materials (SBOM) is a detailed inventory of all components—open source, third-party, and proprietary that constitute a software system. SBOMs provide visibility into the software supply chain, making it possible to identify vulnerabilities, manage licenses, and respond rapidly to security incidents. With modern software often assembled from hundreds of libraries and packages, the SBOM becomes essential for both operational resilience and regulatory compliance. CERT-In’s guidance underscores this by describing the SBOM as a “crucial instrument in contemporary cybersecurity procedures. ” For developers, integrators, and consumers of software, the SBOM enables effective risk management across the entire software lifecycle—from design and development to deployment and runtime. CERT-In Guidelines: SBOM as a National Standard In its July 2025 guidance (v2. 0), CERT-In formalized a comprehensive SBOM framework applicable to government departments, essential service providers, software exporters, and the broader software services industry. These guidelines emphasize that organizations must generate, maintain, and update SBOMs as a mandatory standard practice in all software procurement and development workflows. The CERT-In framework encourages organizations to treat SBOMs not merely as static artifacts, but as living documents that evolve with every patch, upgrade, or configuration change. It introduces six SBOM classifications aligned with different stages of the SDLC—Design, Source, Build, Analyzed, Deployed, and Runtime—and defines multiple SBOM types such as top-level, transitive, delivery, and complete SBOMs. Phased Implementation Roadmap and Operational Requirements CERT-In also introduces a phased implementation roadmap—START, PROGRESS, and ADVANCE—guiding organizations from foundational practices to mature, automated SBOM ecosystems. The framework covers everything from secure SBOM storage and ingestion to vulnerability correlation and license compliance. Unique identifiers (such as Package URLs) are encouraged for improved traceability and interoperability. For sectors such as banking and fintech, CERT-In makes clear that SBOMs must support proactive vulnerability management, vendor risk evaluation, and incident response capabilities. The guidance also requires software consumers to demand SBOMs from vendors during procurement, and it directs developers to deliver accurate and complete SBOMs alongside their software products. SEBI’s SBOM Mandate for Financial Institutions Running parallel to CERT-In’s technical recommendations is a regulatory requirement from SEBI, India’s capital markets regulator. In its Cybersecurity and Cyber Resilience Framework (CSCRF), updated in 2024 and clarified in 2025, SEBI mandates SBOM generation and maintenance for all regulated financial entities (REs), including banks, NBFCs, mutual funds, RTAs, custodians, and clearing corporations. SEBI’s requirement applies to all critical IT systems, broadly defined to include internet-facing apps, client services, core backend systems, and... Angesichts der weltweit zunehmenden Risiken in der Software-Lieferkette hat auch Indien beschlossen, seine Regulierungsmaßnahmen zu verstärken. In den letzten Jahren haben zwei wichtige Aufsichtsbehörden, das Indian Computer Emergency Response Team (CERT-In) und die Securities and Exchange Board of India (SEBI), Richtlinien herausgegeben, die die Software Bill of Materials (SBOM) in den Mittelpunkt der Cybersicherheits-Governance stellen, insbesondere im Finanz- und öffentlichen Sektor. Zusammen stellen diese Vorgaben einen Paradigmenwechsel in der Art und Weise dar, wie Unternehmen ihre Software-Assets verfolgen, sichern und verwalten müssen. SBOMs: Ein strategisches Instrument für Cybersicherheit und Compliance Eine Software-Stückliste (SBOM) ist eine detaillierte Auflistung aller Komponenten – Open Source, von Drittanbietern und proprietär –, aus denen ein Softwaresystem besteht. SBOMs bieten Transparenz in der Software-Lieferkette und ermöglichen es, Schwachstellen zu identifizieren, Lizenzen zu verwalten und schnell auf Sicherheitsvorfälle zu reagieren. Da moderne Software oft aus hunderten von Bibliotheken und Paketen zusammengesetzt ist, wird die SBOM sowohl für die operative Ausfallsicherheit als auch für die Einhaltung gesetzlicher Vorschriften unverzichtbar. Die Leitlinien von CERT-In unterstreichen dies, indem sie die SBOM als „entscheidendes Instrument in modernen Cybersicherheitsverfahren“ beschreiben. Für Entwickler, Integratoren und Verbraucher von Software ermöglicht die SBOM ein effektives Risikomanagement über den gesamten Software-Lebenszyklus hinweg – vom Entwurf und der Entwicklung bis hin zum Betrieb. CERT-In-Richtlinien: SBOM als nationaler Standard In seiner Leitlinie (v2. 0) vom Juli 2025 hat CERT-In ein umfassendes SBOM-Rahmenwerk formalisiert, das für Regierungsbehörden, Anbieter essenzieller Dienste, Software-Exporteure und die gesamte Software-Dienstleistungsbranche gilt. Diese Leitlinien betonen, dass SBOMs als verbindliche Standardpraxis in allen Softwarebeschaffungs- und -entwicklungsworkflows erstellt, gepflegt und aktualisiert werden sollten. Das CERT-In-Framework ermutigt Unternehmen, SBOMs nicht nur als statische Artefakte zu betrachten, sondern als lebendige Dokumente, die sich mit jedem Patch, Upgrade oder jeder Konfigurationsänderung weiterentwickeln. Es führt sechs SBOM-Klassen ein, die auf verschiedene Phasen des SDLC abgestimmt sind – Design, Source, Build, Analyzed, Deployed, and Runtime – und definiert mehrere SBOM-Typen wie Top-Level-, transitive, Liefer- und vollständige SBOMs. CERT-In führt außerdem einen Stufenplan für die Umsetzung ein – START, PROGRESS und ADVANCE –, der Unternehmen von grundlegenden Praktiken zu ausgereiften, automatisierten SBOM-Ökosystemen führt. Das Framework deckt alles ab, von der sicheren Speicherung und Erfassung von SBOMs bis hin zur Korrelation von Schwachstellen und der Einhaltung von Lizenzen. Zur Verbesserung der Rückverfolgbarkeit und Interoperabilität werden eindeutige Identifikatoren (wie Paket-URLs) empfohlen. Für Branchen wie das Bankwesen und Fintech stellt CERT-In klar, dass SBOMs ein proaktives Schwachstellenmanagement, die Bewertung von Lieferantenrisiken und die Fähigkeit zur Reaktion auf Vorfälle unterstützen müssen. Die Leitlinien verpflichten Software-Kunden, bei der Beschaffung aktiv SBOMs von den Anbietern einzufordern, und verlangen von Entwicklern, genaue und vollständige SBOMs zusammen mit ihren Softwareprodukten zu liefern. SEBI-Vorgabe zur SBOM für Finanzinstitute Parallel zu den technischen Empfehlungen von CERT-In gibt es eine regulatorische Anforderung der SEBI, der indischen Kapitalmarktaufsichtsbehörde. In ihrem Cybersecurity and Cyber Resilience Framework (CSCRF), das 2024 aktualisiert und 2025 präzisiert wurde, schreibt die SEBI die Erstellung und Pflege von SBOMs für alle regulierten Finanzunternehmen (REs) vor, darunter Banken, NBFCs, Investmentfonds, RTAs, Verwahrstellen und Clearinggesellschaften. Die Anforderungen der SEBI gelten für alle kritischen IT-Systeme,... As software supply chain risks escalate globally, India has moved decisively to strengthen its regulatory posture. In recent years, two major regulatory bodies the Indian Computer Emergency Response Team (CERT-In) and the Securities and Exchange Board of India (SEBI) have issued guidelines that place the Software Bill of Materials (SBOM) at the heart of cybersecurity governance, particularly in the financial and public sectors. Together, these mandates represent a paradigm shift in how organizations must track, secure, and manage their software assets. SBOMs: A Strategic Tool for Cybersecurity and Compliance A Software Bill of Materials (SBOM) is a detailed inventory of all components—open source, third-party, and proprietary that constitute a software system. SBOMs provide visibility into the software supply chain, making it possible to identify vulnerabilities, manage licenses, and respond rapidly to security incidents. With modern software often assembled from hundreds of libraries and packages, the SBOM becomes essential for both operational resilience and regulatory compliance. CERT-In’s guidance underscores this by describing the SBOM as a “crucial instrument in contemporary cybersecurity procedures. ” For developers, integrators, and consumers of software, the SBOM enables effective risk management across the entire software lifecycle—from design and development to deployment and runtime. CERT-In Guidelines: SBOM as a National Standard In its July 2025 guidance (v2. 0), CERT-In formalized a comprehensive SBOM framework applicable to government departments, essential service providers, software exporters, and the broader software services industry. These guidelines emphasize that organizations must generate, maintain, and update SBOMs as a mandatory standard practice in all software procurement and development workflows. The CERT-In framework encourages organizations to treat SBOMs not merely as static artifacts, but as living documents that evolve with every patch, upgrade, or configuration change. It introduces six SBOM classifications aligned with different stages of the SDLC—Design, Source, Build, Analyzed, Deployed, and Runtime—and defines multiple SBOM types such as top-level, transitive, delivery, and complete SBOMs. Phased Implementation Roadmap and Operational Requirements CERT-In also introduces a phased implementation roadmap—START, PROGRESS, and ADVANCE—guiding organizations from foundational practices to mature, automated SBOM ecosystems. The framework covers everything from secure SBOM storage and ingestion to vulnerability correlation and license compliance. Unique identifiers (such as Package URLs) are encouraged for improved traceability and interoperability. For sectors such as banking and fintech, CERT-In makes clear that SBOMs must support proactive vulnerability management, vendor risk evaluation, and incident response capabilities. The guidance also requires software consumers to demand SBOMs from vendors during procurement, and it directs developers to deliver accurate and complete SBOMs alongside their software products. SEBI’s SBOM Mandate for Financial Institutions Running parallel to CERT-In’s technical recommendations is a regulatory requirement from SEBI, India’s capital markets regulator. In its Cybersecurity and Cyber Resilience Framework (CSCRF), updated in 2024 and clarified in 2025, SEBI mandates SBOM generation and maintenance for all regulated financial entities (REs), including banks, NBFCs, mutual funds, RTAs, custodians, and clearing corporations. SEBI’s requirement applies to all critical IT systems, broadly defined to include internet-facing apps, client services, core backend systems, and systems with access to sensitive... When it comes to managing software security and compliance, understanding and generating Software Bill of Materials (SBOMs) is crucial, especially with the increasing use of third-party and open-source code. The Cybersecurity and Infrastructure Security Agency (CISA) has defined six different types of SBOMs, each linked to different stages of the software development lifecycle (SDLC). Here’s a breakdown of these SBOM types and when they might be useful for your organization. 1. Design SBOM A Design SBOM represents the intended architecture and components of a software product, often created from initial specifications. This SBOM is useful for spotting compatibility issues before acquisition or development begins. However, generating a Design SBOM can be complex, and it might not capture all the necessary details. 2. Source SBOM A Source SBOM is created directly from the development environment and gives insight into the components used during the build process. It highlights vulnerabilities and dependencies, both direct and transient, but may include unused components, which could add unnecessary noise. 3. Build SBOM Produced during the build process, this SBOM offers a more accurate representation of the final software product. By integrating with CI/CD workflows, Build SBOMs ensure trust through digital signing and give greater visibility into compiled components. However, they may require adjustments to the build process and won’t always capture runtime or dynamically linked dependencies. 4. Analyzed SBOM Generated through post-build artifact analysis, an Analyzed SBOM can be especially helpful for legacy systems where development environments no longer exist. It helps verify other SBOMs but may rely on heuristics, which can introduce errors. 5. Deployed SBOM This SBOM captures the inventory of software components as they exist on a deployed system, making it ideal for systems where runtime configurations matter. However, it may not fully reflect what is actually running. 6. Runtime SBOM A Runtime SBOM records only what is actively running in the system, capturing dynamically loaded components and external interactions. While this SBOM type is invaluable for application security, it might not be ideal for copyright or license compliance. Selecting the Right SBOM for Your Organization Choosing the best SBOM type depends on your specific use case and risk profile. If you’re focused on compliance or intellectual property protection, Source and Build SBOMs might be your go-to options. For real-time security insights, Runtime SBOMs offer a dynamic look into your system’s behavior. Whether you’re navigating M&A due diligence or protecting sensitive systems, leveraging the right SBOM tools is key to maintaining security and compliance. Bitsea’s services help you create comprehensive SBOMs to ensure you’re in control of your software components. Want to dive deeper into mastering open-source compliance? Let’s connect—schedule a call with one of our experts today. Source Material CISA. gov. “Types of Software Bill of Materials (SBOM) Documents. ” Types of Software Bill of Material (SBOM) Documents, www. cisa. gov/sites/default/files/2023-04/sbom-types-document-508c. pdf. Accessed 16 Oct. 2024. National Telecommunications and Information Administration. “The Minimum Elements for a Software Bill of Materials” https://www. ntia. doc. gov/files/ntia/publications/sbom _minimum_elements_report. pdf. Accessed 05 Nov. 2024. Wenn es um das Management der Cybersicherheit und Software-Compliance geht, ist das Verständnis und die Erstellung von Software-Stücklisten (SBOMs) von entscheidender Bedeutung, insbesondere angesichts der zunehmenden Verwendung von Code von Drittanbietern und Open Source. Die Cybersecurity and Infrastructure Security Agency (CISA) hat sechs Arten von SBOMs definiert, die jeweils mit verschiedenen Phasen des Softwareentwicklungslebenszyklus (SDLC) verbunden sind. Hier finden Sie eine Übersicht über diese SBOM-Arten und wann sie für Ihr Unternehmen nützlich sein könnten. 1. Design SBOM Eine Design-SBOM repräsentiert die beabsichtigte Architektur und die Komponenten eines Softwareprodukts und wird häufig auf der Grundlage der ursprünglichen Spezifikationen erstellt. Diese SBOM ist nützlich, um Kompatibilitätsprobleme zu erkennen, bevor die Anschaffung oder Entwicklung beginnt. Die Erstellung einer Design-SBOM kann jedoch komplex sein und möglicherweise nicht alle erforderlichen Details erfassen. 2. Source SBOM Eine Source SBOM wird direkt aus der Entwicklungsumgebung erstellt und gibt Einblick in die während des Build-Prozesses verwendeten Komponenten. Sie hebt Schwachstellen und Abhängigkeiten hervor sowohl direkte als auch transitive, kann jedoch auch ungenutzte Komponenten enthalten, die verwirrend sein können. 3. Build SBOM Diese SBOM wird während des Build-Prozesses erstellt und bietet eine genauere Darstellung des endgültigen Softwareprodukts. Durch die Integration in CI/CD-Workflows gewährleisten Build-SBOMs Vertrauen durch digitale Signaturen und bieten mehr Transparenz hinsichtlich der kompilierten Komponenten. Allerdings erfordern sie unter Umständen Anpassungen am Build-Prozess und erfassen nicht immer Laufzeit- oder dynamisch verknüpfte Abhängigkeiten. 4. Analyzed SBOM Eine Analyzed SBOM, die durch eine Analyse der Artefakte nach der Erstellung generiert wird, kann besonders für Legacy-Systeme hilfreich sein, für die keine Entwicklungsumgebungen mehr existieren. Sie hilft bei der Überprüfung anderer SBOMs, kann jedoch auf Heuristiken basieren, die zu Fehlern führen können. 5. Deployed SBOM Diese SBOM erfasst diejenigen Softwarekomponenten, wie sie auf einem bereitgestellten System vorhanden sind, und eignet sich daher ideal für Systeme, bei denen Laufzeitkonfigurationen eine Rolle spielen. Allerdings spiegelt sie möglicherweise nicht vollständig wider, was tatsächlich ausgeführt wird. 6. Runtime SBOM Eine Runtime SBOM erfasst nur das, was aktiv im System ausgeführt wird, und erfasst dynamisch geladene Komponenten und externe Interaktionen. Dieser SBOM-Typ ist für die Anwendungssicherheit von unschätzbarem Wert, für die Einhaltung von Urheberrechts- oder Lizenzbestimmungen jedoch möglicherweise nicht ideal. Auswahl der richtigen SBOM für Ihr Unternehmen Die Wahl des besten SBOM-Typs hängt von Ihrem spezifischen Anwendungsfall und Ihrem Risikoprofil ab. Wenn Sie sich auf Compliance oder den Schutz geistigen Eigentums konzentrieren, sind Source- und Build-SBOMs möglicherweise die richtige Wahl für Sie. Für Echtzeit-Sicherheitsinformationen bieten Runtime-SBOMs einen dynamischen Einblick in das Verhalten Ihres Systems. Ganz gleich, ob Sie sich mit der Due Diligence bei Firmenfusionen und -übernahmen befassen oder sensible Systeme schützen möchten – der Einsatz der richtigen SBOM-Tools ist entscheidend für die Aufrechterhaltung von Cybersicherheit und Compliance. Die Services von Bitsea helfen Ihnen bei der Erstellung umfassender SBOMs, damit Sie die Kontrolle über Ihre Softwarekomponenten behalten. Möchten Sie mehr über die Einhaltung von Open-Source-Compliance erfahren? Nehmen Sie Kontakt mit uns auf – vereinbaren Sie noch heute einen Termin für ein Gespräch mit einem unserer Experten. Quellenangaben: CISA. gov. “Types of Software Bill of Materials (SBOM) Documents.... When it comes to managing software security and compliance, understanding and generating Software Bill of Materials (SBOMs) is crucial, especially with the increasing use of third-party and open-source code. The Cybersecurity and Infrastructure Security Agency (CISA) has defined six different types of SBOMs, each linked to different stages of the software development lifecycle (SDLC). Here's a breakdown of these SBOM types and when they might be useful for your organization. 1. Design SBOM A Design SBOM represents the intended architecture and components of a software product, often created from initial specifications. This SBOM is useful for spotting compatibility issues before acquisition or development begins. However, generating a Design SBOM can be complex, and it might not capture all the necessary details. 2. Source SBOM A Source SBOM is created directly from the development environment and gives insight into the components used during the build process. It highlights vulnerabilities and dependencies, both direct and transient, but may include unused components, which could add unnecessary noise. 3. Build SBOM Produced during the build process, this SBOM offers a more accurate representation of the final software product. By integrating with CI/CD workflows, Build SBOMs ensure trust through digital signing and give greater visibility into compiled components. However, they may require adjustments to the build process and won't always capture runtime or dynamically linked dependencies. 4. Analyzed SBOM Generated through post-build artifact analysis, an Analyzed SBOM can be especially helpful for legacy systems where development environments no longer exist. It helps verify other SBOMs but may rely on heuristics, which can introduce errors. 5. Deployed SBOM This SBOM captures the inventory of software components as they exist on a deployed system, making it ideal for systems where runtime configurations matter. However, it may not fully reflect what is actually running. 6. Runtime SBOM A Runtime SBOM records only what is actively running in the system, capturing dynamically loaded components and external interactions. While this SBOM type is invaluable for application security, it might not be ideal for copyright or license compliance. Selecting the Right SBOM for Your Organization Choosing the best SBOM type depends on your specific use case and risk profile. If you're focused on compliance or intellectual property protection, Source and Build SBOMs might be your go-to options. For real-time security insights, Runtime SBOMs offer a dynamic look into your system's behavior. Whether you're navigating M&A due diligence or protecting sensitive systems, leveraging the right SBOM tools is key to maintaining security and compliance. Bitsea’s services help you create comprehensive SBOMs to ensure you're in control of your software components. Want to dive deeper into mastering open-source compliance? Let's connect—schedule a call with one of our experts today. Source Material CISA. gov. “Types of Software Bill of Materials (SBOM) Documents. ” Types of Software Bill of Material (SBOM) Documents, www. cisa. gov/sites/default/files/2023-04/sbom-types-document-508c. pdf. Accessed 16 Oct. 2024. National Telecommunications and Information Administration. “The Minimum Elements for a Software Bill of Materials” https://www. ntia. doc. gov/files/ntia/publications/sbom _minimum_elements_report. pdf. Accessed 05 Nov. 2024. From Efficiency to Exposure: The Rise of Vibe Coding Today, developers rarely write every line of code from scratch. Most software is built on layers of existing libraries. Traditionally, this meant reusing vetted, attributed, and properly licensed open-source code. Enter “vibe coding” — the practice of using generative AI tools to quickly produce scaffolds, utility functions, or even core business logic. In some organizations, over 60% of new code is now AI-generated. Yet only a small fraction of companies have formal processes to approve these tools or validate their outputs. The result is opaque, hard-to-trace code with unknown licensing, origins, or vulnerabilities. Even worse, many developers cannot distinguish whether a function was generated by AI, copy-pasted from Stack Overflow, or pulled directly from a GPL repository. When asked to complete a sorting algorithm or a math function, GitHub Copilot often produces code nearly identical to existing examples in public repositories. Our own tests have revealed exact matches — but with the license and author information removed. This isn’t accidental. It’s built into the architecture. AI code generation systems are trained on massive datasets of existing code, often without adhering to terms of use or license requirements. And the models themselves are not designed to preserve provenance. “Copilot is not a co-author. It’s a collector — frequently of other people’s work. ” The Legal Shift: From Infringement Theory to Infringement Practice Until recently, the legal risks tied to AI-generated code were largely theoretical. That changed in September 2025, when a German court (Landgericht München I) found OpenAI likely liable for copyright infringement related to song lyrics used in training its models. The court rejected: OpenAI’s argument that users were responsible. Claims invoking EU text and data mining exceptions. Comparisons to U. S. “fair use”. Instead, the court made clear: training on copyrighted material without permission or a license is infringement. Generating content from that training constitutes unauthorized reproduction. This decision could soon lead to formal injunctions and signals that the court may become a hub for similar lawsuits. If this logic extends to source code, Copilot-style models trained on GPL code could face significant legal exposure. Diverging Legal Standards: Europe vs. the United States European courts are increasingly enforcing strict copyright obligations for AI training and outputs. In contrast, the U. S. legal landscape remains more uncertain. Under U. S. copyright law, AI companies often argue that training large language models on publicly available code falls under “fair use. ” However, fair use is a defense, not a license. Its application is fact-specific, unpredictable, and inconsistently applied across courts. Some AI developers rely on it as a shield, but there’s no guarantee that courts will agree. Several ongoing U. S. lawsuits are exploring AI’s potential intellectual property violations. Until clear precedent emerges, organizations using or distributing AI-generated code — particularly if it resembles existing works — face considerable legal uncertainty. To address this, Creative Commons has proposed machine-readable opt-out signals, allowing copyright holders to indicate that their work should not be... Von Effizienz zum Risiko: Der Aufstieg des Vibe Coding Entwickler schreiben nicht jede Zeile Code von Grund auf neu. Die meisten Softwareprogramme nutzen bestehende Bibliotheken. Traditionell bedeutete dies die Wiederverwendung von geprüften, und lizenzierten freien und quelloffenen Codes. Nun kommt „Vibe Coding“ ins Spiel – die Praxis, generative KI-Tools zu verwenden, um schnell Gerüste, Hilfsfunktionen oder sogar zentrale Geschäftslogik zu generieren. Laut Umfragen wird in einigen Unternehmen mittlerweile mehr als 60% des Codes von KI generiert. Aber nur ein Bruchteil der Unternehmen verfügt über Prozesse zur Bewertung dieser Tools oder zur Überprüfung ihrer Ausgaben. Das Ergebnis: undurchsichtiger, nicht nachvollziehbarer Code mit unbekannten Lizenzen, Ursprüngen oder Schwachstellen. Schlimmer noch: Viele Entwickler können nicht erkennen, ob eine Funktion von KI generiert, aus Stack Overflow kopiert oder komplett aus einem GPL-Repository übernommen wurde. Wenn GitHub Copilot aufgefordert wird, einen Sortieralgorithmus oder eine mathematische Funktion zu vervollständigen, generiert es oft Code, der mit bestehenden Beispielen in öffentlichen Repositorys nahezu identisch ist. In eigenen Demonstrationen haben wir die Generierung exakter Übereinstimmungen gezeigt – allerdings ohne Lizenz und Autor. Das ist kein Zufall, sondern liegt in der Architektur der KI begründet: KI-Code-Generierungssysteme werden anhand riesiger Datensätze bestehendes Codes trainiert, oft ohne die Nutzungsbedingungen oder Lizenzverpflichtungen zu „lernen“. Und die Modelle sind nicht darauf ausgelegt, die Herkunft der Quellen zu bewahren. „Copilot ist kein Mitautor. Es ist ein Sammler – oft von den Werken anderer Leute. “ Der rechtliche Wandel: Von der Theorie der Rechtsverletzung zur Praxis der Rechtsverletzung Bis vor kurzem waren die rechtlichen Risiken im Zusammenhang mit KI-generiertem Code weitgehend hypothetisch. Das änderte sich im September 2025, als ein deutsches Gericht (Landgericht München I) OpenAI für wahrscheinlich haftbar für Urheberrechtsverletzungen aufgrund der Verwendung von Songtexten beim Training seiner Modelle befand. Das Gericht monierte: Die Behauptung von OpenAI, dass die Nutzer selbst verantwortlich seien. Argumente, die sich auf Ausnahmen für Text- und Data-Mining in der EU beriefen. Vergleiche mit dem US-amerikanischen „fair use”. Stattdessen stellte das Gericht klar: Das Training mit urheberrechtlich geschützten Daten ohne Genehmigung oder Lizenz ist eine Rechtsverletzung. Und die Generierung von Inhalten auf der Grundlage dieses Trainings ist eine unbefugte Vervielfältigung. Dieser Fall könnte bald zu einer formellen einstweiligen Verfügung führen. Das Gericht signalisierte auch, dass es zu einem Zentrum für ähnliche Klagen werden könnte. Wenn diese Logik auf Quellcode ausgedehnt wird, könnten Copilot-ähnliche Modelle, die mit GPL-Code trainiert wurden, in einen rechtlich freien Fall geraten. Unterschiedliche Rechtslage beim KI-generierten Code in Europa und den USA Während europäische Gerichte beginnen, strenge Urheberrechtsauflagen für das Training und die Ergebnisse von Modellen zu erlassen, bleibt die Situation in den Vereinigten Staaten weiterhin unklar. Nach US-amerikanischem Urheberrecht argumentieren KI-Unternehmen häufig, dass das Training großer Sprachmodelle auf der Grundlage öffentlichen Codes unter die Doktrin der „fairen Nutzung” fällt. Faire Nutzung ist in den USA keine gesetzliche Erlaubnis, sondern eine Verteidigungsstrategie, die sich auf konkrete Fakten stützt, unvorhersehbar ist und von den Gerichten uneinheitlich angewendet wird. Einige KI-Entwickler nutzen sie als Schutzschild für das Training mit urheberrechtlich geschützten Daten, aber es gibt keine Garantie, dass die Gerichte... From Efficiency to Exposure: The Rise of Vibe Coding Developers no longer write every line of code from scratch. Most software is built on layers of existing libraries. Traditionally, this meant reusing vetted, attributed, and licensed Free and Open Source code. Enter "vibe coding" — the practice of using generative AI tools to generate quick scaffolds, utility functions, or even core business logic. Over 60% of code in some organizations is now AI-generated. But only a fraction of companies have processes to approve these tools or vet their output. The result: opaque, untraceable code with unknown licensing, origins, or vulnerabilities. Even worse, many developers can't tell if a function was generated by AI, copy-pasted from Stack Overflow, or copied wholesale from a GPL repository. When prompted to complete a sorting algorithm or a math function, GitHub Copilot often reproduces code that is near-identical to existing examples in public repositories. Our own demonstrations have shown exact matches—but with the license and author stripped away. This is not accidental. It's architectural. AI code generation systems are trained on massive datasets of existing code, often without respecting the terms of use or the license obligations. And the models are not built to preserve provenance. "Copilot is not a co-author. It is a collector—often of other people's work. " The Legal Shift: From Infringement Theory to Infringement Practice Until recently, legal risks around AI-generated code were largely hypothetical. That changed in September 2025, when a German court (Landgericht München I) found OpenAI likely liable for copyright infringement over the use of song lyrics in training its models. The court rejected: OpenAI's claim that the users were responsible. Arguments invoking EU text and data mining exceptions. Comparisons to U. S. "fair use. " Instead, the court made clear: training on copyrighted data without permission or license is infringement. And generating content based on that training is unauthorized reproduction. This case could soon lead to a formal injunction. The court also signalled it could become a center for similar lawsuits. If this logic extends to source code, Copilot-style models trained on GPL code could be in legal free fall. Diverging Legal Standards: Europe vs. the United States While European courts are beginning to impose strict copyright obligations on model training and output, the situation in the United States remains more ambiguous. Under U. S. copyright law, AI companies often argue that training large language models on public code falls under the doctrine of "fair use". Fair use in the U. S. is not a legal permission - it's a defense, one that is fact-specific, unpredictable, and applied inconsistently across courts. Some AI developers rely on it as a shield for training on copyrighted data, but there is no guarantee that courts will agree. There are several ongoing law suits in the US concerning AI and its potential intellectual property rights violations. The U. S. courts have yet to form a consistent view on whether AI training constitutes fair use. Until clear precedent is established, companies using... - Practical recommendations in a nutshell The Bitkom publication Practical Recommendations for Open Source Software (version 3. 3) provides comprehensive guidance for companies and administrations that want to use and help shape open source in a targeted manner. The complete guide is available here as a PDF (currently only in German available). Key Contents at a Glance 1. Importance, Opportunities and Risks The guide starts with a well-founded classification: Open source has long secured a firm place in the IT landscape, driving innovation, transparency, and collaboration. At the same time, it highlights typical challenges—particularly in the areas of security, license compliance, and sustainability. 2. Strategy & Governance Organizations are encouraged to develop a clear open source strategy, e. g. through an Open Source Program Office (OSPO). Different models are presented—from informal governance to foundation-based solutions. The guide also provides advice on corporate contributions to open source projects and on the use of suitable collaboration tools. 3. License Management & Compliance A key focus is the systematic documentation and management of open source licenses in use, including in container environments (“container compliance”). The guide presents methods for interpreting license terms and measures for ensuring license compliance. 4. Software Governance and Project Organization For in-house open source projects, the guide offers recommendations on governance structures, community involvement, and handling intellectual property rights. It also addresses tools for communication, version control, and release processes. 5. Business Models & Ecosystems The guide explains how open source software can serve as the core of business models—through services, SaaS, or dual licensing. It also includes a well-grounded risk assessment and presents common service offerings around open source. 6. Compliance, Tools & Regulation Another chapter deals with technical and legal challenges: including SPDX, license types (including copyleft), common pitfalls in the toolchain (CI/CD, package aggregation), as well as regulatory frameworks such as CRA, DORA, and NIS2, which were explicitly added as new topics. Conclusion Version 3. 3 of the guide provides a well-structured blueprint for the professional use of open source software—from strategy and legal aspects to practical implementation. It serves as a valuable decision-making basis for companies that want to establish open source as a central pillar of their IT. The Bitkom publication Practical Recommendations for Open Source Software (version 3. 3) provides comprehensive guidance for companies and administrations that want to use and help shape open source in a targeted manner. The complete guide is available here as a PDF (currently only in German available). Key Contents at a Glance 1. Importance, Opportunities and Risks The guide starts with a well-founded classification: Open source has long secured a firm place in the IT landscape, driving innovation, transparency, and collaboration. At the same time, it highlights typical challenges—particularly in the areas of security, license compliance, and sustainability. 2. Strategy & Governance Organizations are encouraged to develop a clear open source strategy, e. g. through an Open Source Program Office (OSPO). Different models are presented—from informal governance to foundation-based solutions. The guide also provides advice on corporate contributions to open source projects and on the use of suitable collaboration tools. 3. License Management & Compliance A key focus is the systematic documentation and management of open source licenses in use, including in container environments (“container compliance”). The guide presents methods for interpreting license terms and measures for ensuring license compliance. 4. Software Governance and Project Organization For in-house open source projects, the guide offers recommendations on governance structures, community involvement, and handling intellectual property rights. It also addresses tools for communication, version control, and release processes. 5. Business Models & Ecosystems The guide explains how open source software can serve as the core of business models—through services, SaaS, or dual licensing. It also includes a well-grounded risk assessment and presents common service offerings around open source. 6. Compliance, Tools & Regulation Another chapter deals with technical and legal challenges: including SPDX, license types (including copyleft), common pitfalls in the toolchain (CI/CD, package aggregation), as well as regulatory frameworks such as CRA, DORA, and NIS2, which were explicitly added as new topics. Conclusion Version 3. 3 of the guide provides a well-structured blueprint for the professional use of open source software—from strategy and legal aspects to practical implementation. It serves as a valuable decision-making basis for companies that want to establish open source as a central pillar of their IT. Die Bitkom-Publikation Praxisempfehlungen für Open-Source-Software (Version 3. 3) liefert eine umfassende Orientierung für Unternehmen und Verwaltungen, die Open-Source gezielt einsetzen und mitgestalten wollen. Den vollständigen Leitfaden finden Sie hier als PDF. Die zentralen Inhalte auf einen Blick 1. Bedeutung, Chancen und Risiken Der Leitfaden beginnt mit einer fundierten Einordnung: Open-Source hat längst einen festen Platz in der IT-Landschaft eingenommen und treibt Innovation, Transparenz und Kollaboration voran. Gleichzeitig weist er auf typische Herausforderungen hin – insbesondere zu Sicherheit, Lizenz-Compliance und Nachhaltigkeit. 2. Strategie & Governance Organisationen werden ermutigt, eine klare Open-Source-Strategie zu entwickeln, z. B. über ein Open Source Program Office (OSPO). Es werden unterschiedliche Modelle vorgestellt – von informeller Governance bis hin zu Stiftungslösungen. Zudem gibt es Hinweise zur Beteiligung von Unternehmen in Open-Source-Projekten (Contributions) und zur Nutzung geeigneter Kollaborationstools. 3. Lizenzmanagement & Compliance Ein Schwerpunkt liegt auf der systematischen Erfassung und Verwaltung eingesetzter Open-Source-Lizenzen, auch in Container-Umgebungen (Container-Compliance). Der Leitfaden zeigt Methoden zur Interpretation von Lizenzbestimmungen und Maßnahmen zur Lizenz-Compliance auf. 4. Software-Governance und Projektorganisation Für eigene Open-Source-Projekte liefert der Leitfaden Empfehlungen zur Governance-Struktur, zur Beteiligung der Community und zum Umgang mit geistigen Eigentumsrechten. Auch Werkzeuge zur Kommunikation, Versionskontrolle und Releaseprozessen sind thematisiert. 5. Geschäftsmodelle & Ökosysteme Der Leitfaden erläutert, wie Open-Source-Software als Kern von Geschäftsmodellen dienen kann – etwa durch Services, SaaS oder duale Lizenzierung. Er enthält zudem eine fundierte Risikoabschätzung und zeigt gängige Serviceangebote rund um Open-Source auf. 6. Compliance, Tools & Regulatorik Ein weiteres Kapitel widmet sich technischen und rechtlichen Herausforderungen: darunter SPDX, Lizenztypen (einschließlich Copyleft), typische Stolperfallen in der Toolkette (CI/CD, Paketaggregation) sowie regulatorische Rahmen wie CRA, DORA und NIS2, die explizit neu aufgenommen wurden. Fazit Der Leitfaden Version 3. 3 liefert eine gut strukturierte Blaupause für den professionellen Umgang mit Open-Source-Software – von Strategie über rechtliche Aspekte bis hin zur praktischen Umsetzung. Er eignet sich als wertvolle Entscheidungsgrundlage für Unternehmen, die Open-Source als zentralen Baustein ihrer IT setzen wollen. Open source is no longer a niche topic—in 2025, it is clearer than ever how indispensable open software has become for our digital world. Without open source solutions, large parts of data traffic, many platforms, and even smartphones would come to a standstill. At the same time, the open source community is a key driver of innovation, whether in cloud technologies, artificial intelligence, or security solutions. With the fourth edition of the “Open Source Monitor,” Bitkom provides current figures and assessments on the use of open source software in Germany. Over 1,100 companies were surveyed in a representative sample, supplemented by assessments from around 100 public sector organizations. The result: open source has become an integral part of business and administration. Widespread use—primarily due to concrete advantages Around 75% of companies consciously rely on open source. In the public sector, around two-thirds of authorities use such solutions. The reasons are obvious: open source enables lower costs, customizable software, and the ability to check security aspects yourself. In addition, organizations benefit from an active developer community that constantly provides new features and improvements. More than just technology: digital sovereignty Open source goes far beyond pure cost advantages. Because the source code is openly accessible and allows for customization, it strengthens digital sovereignty: companies and administrations retain control over the software they use—or can regain it. Unsurprisingly, 6 out of 10 companies would like to see the government invest more in open-source software in light of the geopolitical situation. Challenges remain Despite the positive development, there are still obstacles to the use of open source: Shortage of IT specialists Unclear warranty issues Legal uncertainties regarding licenses In addition, many organizations lack a clear strategy: 60% of companies have not yet developed an open source strategy. Conclusion: Strategic action required The Open Source Monitor 2025 makes it clear: open source software is a key building block for innovation, security, and digital independence. However, in order for companies, public administration, and the community to fully exploit its potential, more strategy, responsibilities, and clear goals are needed. Open source is not a sure-fire success—but with targeted investments and smart planning, Germany can strengthen its digital sovereignty and consistently leverage the advantages of open software. Read here the Open Source Monitor 2025 (currently only available in german). Read here the study report Open Source Monitor 2025 (currently only available in german). - The importance of open source for business and administration Open source is no longer a niche topic—in 2025, it is clearer than ever how indispensable open software has become for our digital world. Without open source solutions, large parts of data traffic, many platforms, and even smartphones would come to a standstill. At the same time, the open source community is a key driver of innovation, whether in cloud technologies, artificial intelligence, or security solutions. With the fourth edition of the “Open Source Monitor,” Bitkom provides current figures and assessments on the use of open source software in Germany. Over 1,100 companies were surveyed in a representative sample, supplemented by assessments from around 100 public sector organizations. The result: open source has become an integral part of business and administration. Widespread use—primarily due to concrete advantages Around 75% of companies consciously rely on open source. In the public sector, around two-thirds of authorities use such solutions. The reasons are obvious: open source enables lower costs, customizable software, and the ability to check security aspects yourself. In addition, organizations benefit from an active developer community that constantly provides new features and improvements. More than just technology: digital sovereignty Open source goes far beyond pure cost advantages. Because the source code is openly accessible and allows for customization, it strengthens digital sovereignty: companies and administrations retain control over the software they use—or can regain it. Unsurprisingly, 6 out of 10 companies would like to see the government invest more in open-source software in light of the geopolitical situation. Challenges remain Despite the positive development, there are still obstacles to the use of open source: Shortage of IT specialists Unclear warranty issues Legal uncertainties regarding licenses In addition, many organizations lack a clear strategy: 60% of companies have not yet developed an open source strategy. Conclusion: Strategic action required The Open Source Monitor 2025 makes it clear: open source software is a key building block for innovation, security, and digital independence. However, in order for companies, public administration, and the community to fully exploit its potential, more strategy, responsibilities, and clear goals are needed. Open source is not a sure-fire success—but with targeted investments and smart planning, Germany can strengthen its digital sovereignty and consistently leverage the advantages of open software. Read here the Open Source Monitor 2025 (currently only available in german). Read here the study report Open Source Monitor 2025 (currently only available in german). Do you deliver Electronic Equipment with Radio components to the EU? Then the following new Regulation is relevant for you: The Radio Equipment Directive (RED)1, formally known as Directive 2014/53/EU, is the European Union’s framework for regulating devices that communicate via radio waves. Its main objective is to ensure that radio equipment placed on the EU market is safe, does not interfere with other devices, and uses the radio spectrum efficiently. RED applies to a wide range of electronic devices that use wireless communication, including smartphones, laptops, Wi-Fi routers, wearables, smart home gadgets. Essentially, if a device sends or receives radio signals like Bluetooth, Wi-Fi, mobile data, or GPS, it's likely covered. A key goal of RED is also to ensure that compliant devices can be freely traded across the EU internal market2. On August 1, 2025, the enforcement of the Radio Equipment Directive’s Delegated Act (EU) 2022/30 came into effect, imposing new cybersecurity obligations on manufacturers of radio-enabled products. Alongside this, the EU has resumed work on another significant provision of the same directive. Article 3(3)(i), which may soon lead to software control mechanisms on devices. Together, these developments raise complex legal and technical questions on integrating Free and Open Source Software (FOSS) in the European device market. Understanding Software Freedom and Tivoization Free and Open Source Software (FOSS) is defined not just by access to source code, but by four essential freedoms:3 Freedom 0 – The freedom to run the program as you wish, for any purpose. Freedom 1 – The freedom to study how the program works and change it. Freedom 2 – The freedom to redistribute copies. Freedom 3 – The freedom to distribute modified versions. These freedoms ensure that users have control over the software they use, not just in theory, but in practical, technical terms. 4 However, these freedoms can be undermined by technical barriers, such as preventing users from installing modified software on their devices. To understand the context, it helps to revisit the past. The story of “Tivoization” dates back to the early 2000s, when TiVo, a U. S. manufacturer of digital video recorders, built its devices using the Linux kernel. While TiVo complied with the GPLv2 license by publishing the source code, it also locked its devices in such a way that users could not install modified versions of the software. This hardware-level restriction gave rise to the term "Tivoization" and sparked a philosophical and legal debate about what it means to truly respect software freedom. 5 In response, the Free Software Foundation introduced the GPLv3 license in the year 2007. 6 This version added a critical new clause known as "Installation Information,“ which refers to any methods, procedures, authorization keys, or other information required to install and execute modified versions of the covered work in that User Product from a modified version of its Corresponding Source. This clause means manufacturers must provide users with the necessary information, such as keys or procedures, to install and execute modified versions of the... The Radio Equipment Directive (RED)1, formally known as Directive 2014/53/EU, is the European Union’s framework for regulating devices that communicate via radio waves. Its main objective is to ensure that radio equipment placed on the EU market is safe, does not interfere with other devices, and uses the radio spectrum efficiently. RED applies to a wide range of electronic devices that use wireless communication, including smartphones, laptops, Wi-Fi routers, wearables, smart home gadgets. Essentially, if a device sends or receives radio signals like Bluetooth, Wi-Fi, mobile data, or GPS, it's likely covered. A key goal of RED is also to ensure that compliant devices can be freely traded across the EU internal market2. On August 1, 2025, the enforcement of the Radio Equipment Directive’s Delegated Act (EU) 2022/30 came into effect, imposing new cybersecurity obligations on manufacturers of radio-enabled products. Alongside this, the EU has resumed work on another significant provision of the same directive. Article 3(3)(i), which may soon lead to software control mechanisms on devices. Together, these developments raise complex legal and technical questions on integrating Free and Open Source Software (FOSS) in the European device market. Understanding Software Freedom and Tivoization Free and Open Source Software (FOSS) is defined not just by access to source code, but by four essential freedoms:3 Freedom 0 – The freedom to run the program as you wish, for any purpose. Freedom 1 – The freedom to study how the program works and change it. Freedom 2 – The freedom to redistribute copies. Freedom 3 – The freedom to distribute modified versions. These freedoms ensure that users have control over the software they use, not just in theory, but in practical, technical terms. 4 However, these freedoms can be undermined by technical barriers, such as preventing users from installing modified software on their devices. To understand the context, it helps to revisit the past. The story of “Tivoization” dates back to the early 2000s, when TiVo, a U. S. manufacturer of digital video recorders, built its devices using the Linux kernel. While TiVo complied with the GPLv2 license by publishing the source code, it also locked its devices in such a way that users could not install modified versions of the software. This hardware-level restriction gave rise to the term "Tivoization" and sparked a philosophical and legal debate about what it means to truly respect software freedom. 5 In response, the Free Software Foundation introduced the GPLv3 license in the year 2007. 6 This version added a critical new clause known as "Installation Information,“ which refers to any methods, procedures, authorization keys, or other information required to install and execute modified versions of the covered work in that User Product from a modified version of its Corresponding Source. This clause means manufacturers must provide users with the necessary information, such as keys or procedures, to install and execute modified versions of the software on the device, ensuring that users are not technically prevented from exercising their freedom to modify and reinstall the... - Was sie für FOSS und SBOMs bedeutet Die Funkgeräterichtlinie ,,Radio Equipment Directive” (RED)1, offiziell bekannt als Richtlinie 2014/53/EU, ist der Rechtsrahmen der Europäischen Union für die Regulierung von Geräten, die über Funkwellen kommunizieren. Ihr Hauptziel ist es, sicherzustellen, dass Funkgeräte, die auf den EU-Markt gebracht werden, sicher sind, andere Geräte nicht stören und das Funkfrequenzspektrum effizient nutzen. Die RED gilt für eine Vielzahl von elektronischen Geräten, die drahtlose Kommunikation nutzen, darunter Smartphones, Laptops, WLAN-Router, Wearables und Smart-Home-Geräte. Grundsätzlich gilt: Wenn ein Gerät Funksignale wie Bluetooth, WLAN, mobile Daten oder GPS sendet oder empfängt, fällt es wahrscheinlich unter diese Richtlinie. Ein weiteres wichtiges Ziel der RED ist es, sicherzustellen, dass konforme Geräte im gesamten EU-Binnenmarkt frei gehandelt werden können. 2 Am 1. August 2025 trat die Durchführungsverordnung (EU) 2022/30 zur Funkgeräterichtlinie in Kraft, die Herstellern von funkfähigen Produkten neue Cybersicherheitsverpflichtungen auferlegt. Parallel dazu hat die EU die Arbeit an einer weiteren wichtigen Bestimmung derselben Richtlinie wieder aufgenommen. Artikel 3 Absatz 3 Buchstabe i, der bald dazu führen könnte, dass Hersteller Software auf den Endgeräten strenger kontrollieren müssen. Zusammen werfen diese Entwicklungen komplexe rechtliche und technische Fragen zur Integration von freier und quelloffener Software (FOSS) in den europäischen Gerätemarkt auf. Softwarefreiheit und Tivoisierung verstehen Freie und Open Source Software (FOSS) wird nicht nur durch den Zugang zum Quellcode definiert, sondern durch vier wesentliche Freiheiten:3 Freiheit 0 – Die Freiheit, das Programm nach Belieben und für jeden Zweck auszuführen. Freiheit 1 – Die Freiheit, die Funktionsweise des Programms zu studieren und es zu ändern. Freiheit 2 – Die Freiheit, Kopien weiterzugeben. Freiheit 3 – Die Freiheit, modifizierte Versionen zu verbreiten. Diese Freiheiten gewährleisten, dass Nutzer die Kontrolle über die von ihnen verwendete Software haben, nicht nur in der Theorie, sondern auch in praktischer und technischer Hinsicht. 4 Diese Freiheiten können jedoch durch technische Barrieren untergraben werden, beispielsweise wenn Nutzer daran gehindert werden, modifizierte Software auf ihren Geräten zu installieren. Um den Kontext zu verstehen, ist es hilfreich, einen Blick in die Vergangenheit zu werfen. Die Geschichte der „Tivoisierung“ reicht bis in die frühen 2000er Jahre zurück, als TiVo, ein US-amerikanischer Hersteller von digitalen Videorekordern, seine Geräte auf Basis des Linux-Kernels entwickelte. TiVo hielt sich zwar an die GPLv2-Lizenz, indem es den Quellcode veröffentlichte, sperrte seine Geräte jedoch so, dass die Nutzer keine modifizierten Versionen der Software installieren konnten. Diese Einschränkung auf Hardware-Ebene führte zur Prägung des Begriffs „Tivoisierung“ und löste eine philosophische und rechtliche Debatte darüber aus, was es bedeutet, Softwarefreiheit wirklich zu respektieren. 5 Als Reaktion darauf führte die Free Software Foundation im Jahr 2007 die GPLv3-Lizenz ein. 6 Diese Version enthielt eine wichtige neue Klausel mit dem Titel „Installationsinformationen“, die sich auf alle Methoden, Verfahren, Autorisierungsschlüssel oder sonstigen Informationen bezieht, die erforderlich sind, um modifizierte Versionen des betreffenden Werks in diesem Benutzerprodukt aus einer modifizierten Version seines entsprechenden Quellcodes zu installieren und auszuführen. Diese Klausel verpflichtet Hersteller, den Benutzern die erforderlichen Informationen – etwa Schlüssel oder Verfahren – zur Verfügung zu stellen, damit sie modifizierte Versionen der Software auf dem... On May 21, 2026, the Open Source Security Foundation (OpenSSF) will bring its flagship community event to Minneapolis, co-located with the broader Open Source Summit North America. This one-day gathering continues OpenSSF’s mission of strengthening the open source ecosystem by fostering collaboration among developers, security engineers, researchers, and industry leaders. A Collaborative Hub for Security Innovation OpenSSF Community Day events are known for their highly interactive and practitioner-focused nature. The 2026 edition promises a full day of discussions, technical deep dives, and knowledge sharing centered on improving software supply chain security and resilience. Attendees will explore tools, standards, and best practices that help secure the development and consumption of open source software at scale. The agenda reflects the growing maturity of the field. Sessions span governance, risk, and compliance (GRC), repository security, and automation, alongside emerging challenges such as AI and quantum readiness. A major thematic focus this year is software supply chain transparency, with multiple talks diving into Software Bills of Materials (SBOMs), digital signatures, and vulnerability management. Spotlight Session: From SBOMs to Strategic Decisions Among the notable talks is a session by Prashanth Chandrasekar of Bitsea US, Inc. , titled: “From SBOMs To Decisions: Prioritizing Supply Chain Risk in Time-Bound M&A Reviews. ” This talk highlights a critical evolution in how SBOM data is used. Rather than treating SBOMs as static compliance artifacts, the session focuses on turning them into actionable intelligence—particularly in high-pressure scenarios like mergers and acquisitions. In such contexts, organizations must rapidly assess software risk across complex portfolios, making prioritization essential. The topic aligns closely with broader industry trends. SBOMs are increasingly seen as a foundation for risk-based decision-making, helping organizations identify vulnerable or outdated components, evaluate dependencies, and guide remediation efforts. In M&A scenarios, they can even support due diligence by revealing hidden supply chain risks before deals are finalized. Why This Event Matters As open source continues to underpin modern software, the stakes for securing it have never been higher. Events like OpenSSF Community Day provide a rare opportunity to bridge theory and practice—bringing together the people building tools, defining standards, and applying them in real-world environments. The 2026 Minneapolis edition stands out for its emphasis on actionable security: moving beyond awareness toward measurable, decision-driven outcomes. Whether it’s operationalizing SBOMs, improving compliance architectures, or preparing for next-generation threats, the event showcases how the community is turning collaboration into concrete progress. Final Thoughts OpenSSF Community Day North America 2026 is more than just a conference—it’s a working session for the future of open source security. With thought-provoking talks like Prashanth Chandrasekar’s on SBOM-driven decision-making, attendees can expect practical insights that directly impact how organizations manage risk in an increasingly complex software landscape. For anyone invested in the security of open source—developers, CISOs, or policy leaders—Minneapolis will be the place where ideas turn into action. We cordially invite you to the Cybersecurity Summit 2026 on 26 February from 3 p. m. at Motorworld Cologne. Learn how AI, the Cyber Resilience Act (CRA) and digital sovereignty are inextricably linked. Event content: Secure integration of AI into business processes Requirements of the Cyber Resilience Act (CRA) Strategies for reducing downtime and liability risks The speakers: Prof. Dr. Oliver Weissmann - Axians Information SecurityGmbH/Hochschule Darmstadt Carina Paulsen & Sascha-Matthias Kulawik - digital cuisine GmbH Marko Diepold - adverit compliance GmbH & Co. KG Dr. Andreas Kotulla - Bitsea GmbH At the Cybersecurity Summit, Dr Kotulla will give a concise introduction to the key requirements of the CRA, specifically risk assessment in accordance with Annexes I and II. As a special highlight and real takeaway, Dr Kotulla will present the EU-funded OCCTET. EU project, which helps SMEs prepare for the CRA. Die Plätze sind begrenzt – sichern Sie sich frühzeitig Ihren Platz und gestalten Sie digitale Souveränität aktiv mit! Register here. Wir laden Sie herzlich zum Cybersecurity Summit 2026 am 26. Februar ab 15:00 Uhr in der Motorworld Köln ein. Erfahren Sie wie KI, der Cyber Resilience Act (CRA) und digitale Souveränität untrennbar miteinander verbunden sind. Inhalte des Events: Sichere Integration von KI in Unternehmensprozesse Anforderungen des Cyber Resilience Act (CRA) Strategien zur Senkung von Ausfall- und Haftungsrisiken Die Referenten: Prof. Dr. Oliver Weissmann - Axians Information SecurityGmbH/Hochschule Darmstadt Carina Paulsen & Sascha-Matthias Kulawik - digital cuisine GmbH Marko Diepold - adverit compliance GmbH & Co. KG Dr. Andreas Kotulla - Bitsea GmbH Dr. Kotulla wird beim Cybersecurity Summit eine kompakte Einführung in die zentralen Anforderungen des CRA, speziell in die Risikoprüfung gemäß Anhang I und II geben. Als besonderes Highlight und echtes Takeaway wird Herr Dr. Kotulla das EU-geförderte Projekt OCCTET. EU vorstellen, mit dem KMU`s sich auf den CRA vorbereiten können. Die Plätze sind begrenzt – sichern Sie sich frühzeitig Ihren Platz und gestalten Sie digitale Souveränität aktiv mit! Link zur Anmeldung. Bitsea GmbH, a leading provider of IT services and open source compliance analysis based in Germany, announces the acquisition of Revenera’s Auditing Services team. As part of this strategic expansion, Bitsea has established a new subsidiary in the United States: Bitsea US, Inc. By integrating this experienced team, Bitsea strengthens its international presence and strategically expands its capabilities in software audits and license compliance for enterprise customers in North America. The newly established U. S. entity will be responsible for key functions such as service delivery, customer support, and project execution in the American market. “Through the acquisition of Revenera’s team, we gain not only deep expertise but also long-standing customer relationships and extensive experience in delivering complex audits,” says Andreas Kotulla, Managing Director of Bitsea GmbH. “The founding of Bitsea US is a major milestone in our efforts to expand our services internationally and to support our clients more directly on site. ” The acquisition became effective as of . The entire former Revenera’s auditing services team will continue operating under the Bitsea US, Inc. umbrella, maintaining ongoing projects and supporting new customers. About BitseaBitsea is a specialized IT service provider focused on software analysis, open source compliance, and technical due diligence. Since its founding in 2008, Bitsea has supported companies in the secure and legally compliant use of software throughout development and production processes. Bitsea GmbH, a leading provider of IT services and open source compliance analysis based in Germany, announces the acquisition of Revenera’s Auditing Services team. As part of this strategic expansion, Bitsea has established a new subsidiary in the United States: Bitsea US, Inc. By integrating this experienced team, Bitsea strengthens its international presence and strategically expands its capabilities in software audits and license compliance for enterprise customers in North America. The newly established U. S. entity will be responsible for key functions such as service delivery, customer support, and project execution in the American market. “Through the acquisition of Revenera’s team, we gain not only deep expertise but also long-standing customer relationships and extensive experience in delivering complex audits,” says Andreas Kotulla, Managing Director of Bitsea GmbH. “The founding of Bitsea US is a major milestone in our efforts to expand our services internationally and to support our clients more directly on site. ” The acquisition became effective as of . The entire former Revenera’s auditing services team will continue operating under the Bitsea US, Inc. umbrella, maintaining ongoing projects and supporting new customers. About BitseaBitsea is a specialized IT service provider focused on software analysis, open source compliance, and technical due diligence. Since its founding in 2008, Bitsea has supported companies in the secure and legally compliant use of software throughout development and production processes. Die Bitsea GmbH, ein führender Anbieter von IT-Dienstleistungen und Open-Source-Compliance-Analysen mit Sitz in Sankt Augustin, Deutschland, gibt die Übernahme des Auditing Services Teams von Revenera bekannt. Im Zuge dieser strategischen Erweiterung hat Bitsea eine neue Niederlassung in den Vereinigten Staaten gegründet: Bitsea US, Inc. Mit der Integration des erfahrenen Teams stärkt Bitsea seine internationale Präsenz und erweitert gezielt seine Kompetenz im Bereich Software-Audits und Lizenz-Compliance für Unternehmenskunden in Nordamerika. Die neu gegründete US-Niederlassung wird zukünftig zentrale Aufgaben im Bereich Servicebereitstellung, Kundenbetreuung und Projektabwicklung für den amerikanischen Markt übernehmen. „Mit der Übernahme des Revenera-Teams sichern wir uns nicht nur tiefgreifendes Fachwissen, sondern auch gewachsene Kundenbeziehungen und langjährige Erfahrung in der Durchführung anspruchsvoller Audits“, erklärt Dr. Andreas Kotulla, Geschäftsführer der Bitsea GmbH. „Die Gründung von Bitsea US ist ein bedeutender Meilenstein auf unserem Weg, unsere Dienstleistungen international auszubauen und unsere Kunden noch direkter vor Ort zu unterstützen. “ Die Übernahme wird zum 01. 08. 2025 wirksam. Das übernommene Team wird unter dem Dach von Bitsea US, Inc. weiterarbeiten und dabei bestehende Projekte fortführen sowie neue Kunden betreuen. Über Bitsea:Bitsea ist ein spezialisierter IT-Dienstleister mit Fokus auf Softwareanalysen, Open-Source-Compliance und technische Due-Diligence-Prüfungen. Seit der Gründung im Jahr 2008 unterstützt Bitsea Unternehmen bei der sicheren und rechtskonformen Nutzung von Software in Entwicklungs- und Produktionsprozessen. Open Source Everywhere — And a New Challenge On any given day, tech companies in Europe are shipping products with digital elements. Under the hood, chances are it’s running a wealth of Open Source-code. From encryption libraries to web frameworks, Open Source has become the backbone of digital innovation—indeed, a typical modern software product is often over 90% Open Source by codebase volume 1. This ubiquity of open source is a double-edged sword: it accelerates development, but also brings security and compliance worries. High-profile software supply-chain attacks and vulnerabilities have alarmed regulators, and now the European Union is stepping in with a sweeping new law to bolster cybersecurity. Enter the Cyber Resilience Act (CRA), a regulation that aims to ensure all products with digital elements are cyber-safe by design. For companies both large and small, the CRA is rapidly becoming the defining challenge of the moment. The CRA introduces strict requirements for anyone producing or integrating digital products in the EU 2. It essentially mandates that manufacturers consider cybersecurity in the planning, design, development, production, delivery and maintenance” of products and document all cyber risks 2. Perhaps its most daunting demand is that every software component must be continuously checked for vulnerabilities 2. In practice, this means if you are an SME building a digital product, you need to keep tabs on every Open Source-library, every snippet of code, throughout your product’s lifecycle. You must be able to prove (via audits and paperwork) that you have identified your software’s components and addressed any known security issues before your product hits the market – and even long after, since the CRA calls for ongoing duty to patch vulnerabilities for years. While pure Open Source-projects released by hobbyists aren’t directly governed by the CRA, any commercial use of Open Source in a product brings that code under the compliance umbrella 2. SMEs in the Crosshairs of Compliance For Europe’s small and medium-sized enterprises (SMEs), who have leaned on Open Source to stay competitive, the CRA’s new obligations can feel overwhelming. Suddenly, a startup that was happily cobbling together Open Source-components must inventory every line of code and produce a “cybersecurity certificate” of sorts for their product. They need a Software Bill of Materials (SBOM) that lists all Open Source-components, complete with licenses and vulnerability statuses, and processes to swiftly update or fix any component that goes rogue. Creating a complete and correct SBOM is notoriously difficult and time-consuming 2. It’s not enough to just list declared dependencies from a package manager. What’s required is a deep scan of the codebase to uncover embedded code, transitive dependencies, snippets, and files copied without attribution. These components often sit below the surface, easily missed and skipped in shallow scans. Automated tools exist and can scan your codebase to spit out a list of components, but they are far from perfect. In real projects, Open Source pieces are often deeply embedded: a few files from one library copied here, a utility function borrowed there. These fragments... Open Source ist überall—Und eine neue Herausforderung Täglich bringen europäische Tech-Unternehmen Produkte mit digitalen Komponenten auf den Markt. Im Hintergrund nutzen diese häufig eine Vielzahl von Open Source-Bibliotheken. Von Verschlüsselungsbibliotheken bis hin zu Web-Frameworks: Open Source ist das Rückgrat der digitalen Innovation. Ein typisches modernes Softwareprodukt besteht häufig zu über 90 % aus Open Source (gemessen am Code-Volumen) 1. Diese Allgegenwart von Open Source ist ambivalent: Sie beschleunigt die Entwicklung, wirft aber auch Sicherheits- und Compliance-Fragen auf. Prominente Angriffe auf Software-Lieferketten und Sicherheitslücken haben Regulierungsbehörden alarmiert. Nun greift die Europäische Union mit einem weitreichenden neuen Gesetz ein. Mit dem Cyber Resilience Act (CRA), einer Verordnung, die gewährleisten soll, dass alle Produkte mit digitalen Komponenten von Beginn an cybersicher konzipiert werden. Für Unternehmen jeder Größe stellt der CRA derzeit eine zentrale Herausforderung dar. Der CRA bringt strenge Anforderungen für alle mit sich, die digitale Produkte innerhalb der EU entwickeln oder vertreiben 2. Er verpflichtet Hersteller dazu, Cybersicherheit in Planung, Design, Entwicklung, Produktion, Lieferung und Wartung ihrer Produkte zu berücksichtigen – inklusiver vollständiger Dokumentation sämtlicher Risiken2. Besonders anspruchsvoll ist dabei die Verpflichtung, sämtliche Softwarekomponenten kontinuierlich auf Schwachstellen zu überprüfen2. In der Praxis bedeutet das: Wer als KMU ein digitales Produkt entwickelt, muss die gesamten genutzten Open Source-Bibliotheken und jeden Code-Schnipsel während des gesamten Produktzyklus im Blick behalten. Vor dem Markteintritt – und auch lange danach - muss ein Unternehmen nachweisen können, dass es die verwendeten Komponenten identifiziert und bekannte Schwachstellen behoben hat. Der CRA fordert eine fortlaufende Verpflichtung zur Schwachstellenbehebung über Jahre hinweg. Reine Open Source-Projekte von Hobbyentwicklern fallen nicht direkt unter die Regelung – aber jede kommerzielle Nutzung von Open Source in einem Produkt bringt den Code unter die CRA-Compliance-Pflicht2. KMU im Fadenkreuz der Compliance Insbesondere kleine und mittelständische Unternehmen (KMU) in Europa, die Open Source bislang als klaren Wettbewerbsvorteil genutzt haben, sehen sich nun mit einer neuen, komplexen Realität konfrontiert. Start-ups, die bisher frei Open Source-Komponenten kombinieren konnten, müssen plötzlich eine vollständige Inventarisierung vornehmen – inklusive einer Art „Cybersicherheitszertifikat“ für ihr Produkt. Sie benötigen eine Software Bill of Materials (SBOM) mit allen Open Source-Komponenten, zugehörigen Lizenzen, Sicherheitsstatus und Prozessen zur schnellen Aktualisierung betroffener Komponenten. Die Erstellung einer vollständigen und korrekten SBOM ist jedoch aufwendig und fehleranfällig2. Es reicht nicht aus, deklarierte Abhängigkeiten aus dem Paketmanager aufzulisten. Erforderlich ist ein tiefgehender Scan des gesamten Codebestands, inklusive eingebetteter Komponenten, transitiver Abhängigkeiten, kopierter Dateien oder nicht deklarierter Codeschnipsel. Vieler dieser Komponenten bleiben bei oberflächlichen Scans unentdeckt. Zwar existieren automatisierte Tools zur Codeanalyse, doch diese sind bei weitem nicht perfekt. In realen Projekten sind Open Source-Komponenten oft tief eingebettet: eine Datei von hier, eine Hilfsfunktion dort. Scanner übersehen diese Fragmente häufig oder identifizieren sie falsch2. Umgekehrt gibt es auch Falscherkennungen, bei denen Scanner regulären Code als Open Source markieren – etwa wegen eines Kommentars mit dem Wort „GPL“, der gar keine Lizenz betrifft. Viele Unternehmen greifen daher weiterhin auf manuelle Audits durch Experten zurück, sogenannte Open Source-Auditoren, um die Lücken der Automatisierung zu schließen2. Das kostet Zeit und Geld: Ein deutsches KMU berichtete, dass... Open Source Everywhere — And a New Challenge On any given day, tech companies in Europe are shipping products with digital elements. Under the hood, chances are it’s running a wealth of Open Source-code. From encryption libraries to web frameworks, Open Source has become the backbone of digital innovation—indeed, a typical modern software product is often over 90% Open Source by codebase volume 1. This ubiquity of open source is a double-edged sword: it accelerates development, but also brings security and compliance worries. High-profile software supply-chain attacks and vulnerabilities have alarmed regulators, and now the European Union is stepping in with a sweeping new law to bolster cybersecurity. Enter the Cyber Resilience Act (CRA), a regulation that aims to ensure all products with digital elements are cyber-safe by design. For companies both large and small, the CRA is rapidly becoming the defining challenge of the moment. The CRA introduces strict requirements for anyone producing or integrating digital products in the EU 2. It essentially mandates that manufacturers consider cybersecurity in the planning, design, development, production, delivery and maintenance” of products and document all cyber risks 2. Perhaps its most daunting demand is that every software component must be continuously checked for vulnerabilities 2. In practice, this means if you are an SME building a digital product, you need to keep tabs on every Open Source-library, every snippet of code, throughout your product’s lifecycle. You must be able to prove (via audits and paperwork) that you have identified your software’s components and addressed any known security issues before your product hits the market – and even long after, since the CRA calls for ongoing duty to patch vulnerabilities for years. While pure Open Source-projects released by hobbyists aren’t directly governed by the CRA, any commercial use of Open Source in a product brings that code under the compliance umbrella 2. SMEs in the Crosshairs of Compliance For Europe’s small and medium-sized enterprises (SMEs), who have leaned on Open Source to stay competitive, the CRA’s new obligations can feel overwhelming. Suddenly, a startup that was happily cobbling together Open Source-components must inventory every line of code and produce a “cybersecurity certificate” of sorts for their product. They need a Software Bill of Materials (SBOM) that lists all Open Source-components, complete with licenses and vulnerability statuses, and processes to swiftly update or fix any component that goes rogue. Creating a complete and correct SBOM is notoriously difficult and time-consuming 2. It’s not enough to just list declared dependencies from a package manager. What’s required is a deep scan of the codebase to uncover embedded code, transitive dependencies, snippets, and files copied without attribution. These components often sit below the surface, easily missed and skipped in shallow scans. Automated tools exist and can scan your codebase to spit out a list of components, but they are far from perfect. In real projects, Open Source pieces are often deeply embedded: a few files from one library copied here, a utility function borrowed there. These fragments... New technologies, innovative projects, and creative ideas as guide for the future – that's what small and medium-sized enterprises will showcase on June 5th, 2025, in Berlin at the Innovation Day for SMEs hosted by the Federal Ministry for Economic Affairs and Climate Action (BMWK), under the motto “Shaping the Future Now! ” Around 300 exhibitors will present their groundbreaking developments at this open-air event, all made possible through the BMWK’s broad-based innovation funding. At the event, we will present our immersive VR visualization of software. “Making Software Architecture and Open Source Compliance Tangible,”: visitors can experience our innovative visualizations up close in virtual reality (VR) – an exciting exhibit that demonstrates how complex digital software structures can become intuitive and interactive experiences. Also on the agenda: an International area offering support for global cooperation, guided tours across the exhibition grounds, and a diverse stage program featuring talks on innovation policy, as well as project presentations on topics such as “Innovations for Tomorrow’s Needs,” “Digitalization as a Driver for SMEs,” and “Innovation Culture in Medium-Sized Enterprises. ” We look forward to welcoming you on Thursday, June 5th, at our booth at Tschaikowskistraße 49, 13156 Berlin-Pankow! You can find more information here New technologies, innovative projects, and creative ideas as guide for the future – that's what small and medium-sized enterprises will showcase on June 5th, 2025, in Berlin at the Innovation Day for SMEs hosted by the Federal Ministry for Economic Affairs and Climate Action (BMWK), under the motto “Shaping the Future Now! ” Around 300 exhibitors will present their groundbreaking developments at this open-air event, all made possible through the BMWK’s broad-based innovation funding. At the event, we will present our immersive VR visualization of software. “Making Software Architecture and Open Source Compliance Tangible,”: visitors can experience our innovative visualizations up close in virtual reality (VR) – an exciting exhibit that demonstrates how complex digital software structures can become intuitive and interactive experiences. Also on the agenda: an International area offering support for global cooperation, guided tours across the exhibition grounds, and a diverse stage program featuring talks on innovation policy, as well as project presentations on topics such as “Innovations for Tomorrow’s Needs,” “Digitalization as a Driver for SMEs,” and “Innovation Culture in Medium-Sized Enterprises. ” We look forward to welcoming you on Thursday, June 5th, at our booth at Tschaikowskistraße 49, 13156 Berlin-Pankow! You can find more information here Neue Technologien, innovative Projekte und kreative Ideen als Wegweiser in die Zukunft – Das präsentieren kleine und mittlere Unternehmen am 5. Juni 2025 in Berlin beim Innovationstag Mittelstand des Bundesministeriums für Wirtschaft und Klimaschutz (BMWK) unter dem Motto „Zukunft jetzt gestalten! “ Rund 300 Aussteller stellen bei dem Open-Air-Event ihre wegweisenden Entwicklungen vor, die mit Unterstützung der themenoffenen Innovationsförderung des BMWK realisiert werden konnten. Bei dem Event präsentieren wir unsere Immersive VR-Visualisierung von Software. Unter dem Motto „Software-Architektur und Open Source Compliance greifbar gemacht“ erleben Besucherinnen und Besucher innovative Visualisierungen hautnah in Virtual Reality (VR) – ein spannendes Exponat, das zeigt, wie komplexe digitale Software-Strukturen intuitiv und interaktiv erlebbar werden. Ebenfalls auf der Agenda des Events: eine International Area mit Angeboten zur Unterstützung internationaler Kooperationen, geführte Rundgänge über das Ausstellungsgelände und ein facettenreiches Bühnenprogramm mit Impulsen zu innovationspolitischen Themen sowie Projektvorstellungen zu den Themen „Innovationen für die Bedarfe von morgen“, „Digitalisierung als Impuls für den Mittelstand“ und „Innovationskultur in mittelständischen Unternehmen“. Wir freuen uns, wenn wir auch Sie am Donnerstag, dem 5. Juni, an unserem Stand in der Tschaikowskistraße 49 in 13156 Berlin-Pankow begrüßen dürfen! Weitere Informationen finden Sie hier As cars become more like computers on wheels, cybersecurity is becoming a major concern. With vehicles now connected to the internet and relying heavily on software, protecting them from cyber threats is essential. The Cyber Resilience Act (CRA) is a new European law designed to improve cybersecurity for digital products. While it does not directly apply to cars themselves (since they are already covered by other regulations), it still affects many digital systems within the vehicles. This article explains what the CRA is and how it impacts the automotive industry in simple terms. How Is Cybersecurity Already Regulated in the Automotive Industry? As the automotive industry evolves with advancements like autonomous vehicles and enhanced connectivity, cybersecurity has become a critical concern. Car manufacturers must already follow strict cybersecurity regulations to ensure vehicle safety. Some of the key regulations include: UNECE Regulations R155 and R156: These require vehicle manufacturers to implement Cybersecurity Management Systems (CSMS) and secure over-the-air (OTA) updates. R155 mandates risk management throughout the vehicle lifecycle, ensures cars are protected against hacking, unauthorized access, and other cyber risks. R156 instead focuses on securing software updates. Vehicle General Safety Regulation (EU 2019/2144): This EU law ensures that cars meet certain cybersecurity standards. It references the UN Regulation R155, which requires automakers to implement cybersecurity management systems. ISO/SAE 21434: An international cybersecurity standard for car manufacturers. This standard provides guidelines for managing cybersecurity risks during vehicle development. It emphasizes a structured risk assessment process (TARA) and ensures cybersecurity is integrated throughout the vehicle lifecycle, from design to decommissioning. Together, these regulations form the backbone of automotive cybersecurity, addressing both critical systems and the broader digital components of connected vehicles. These rules mainly focus on safety-critical systems, such as braking and steering. However, they do not fully cover other digital components in vehicles, such as infotainment systems, apps, and third-party software — which is where the CRA comes in. What Is the Cyber Resilience Act (CRA)? The Cyber Resilience Act (CRA) is a new EU regulation designed to improve cybersecurity for all digital products. It requires companies to ensure their software and hardware are secure, regularly updated, and protected against cyber threats. But aren’t vehicles already covered by cybersecurity regulations? Yes, the CRA does not apply to cars themselves, because they are already regulated under EU 2019/2144 and UN R155. However, it does apply to many digital systems and software within vehicles. Which Automotive Systems Are Affected by the CRA? While critical vehicle functions like braking and steering fall under existing regulations, other digital components and software may be subject to the CRA, including: Infotainment and Navigation Systems – Car dashboards that include web browsers, streaming services, and navigation software. Remote Access and Fleet Management Software – Tools that allow remote monitoring or control of vehicles. Over-the-Air (OTA) Update Systems – Software that updates infotainment systems, apps, or other non-critical vehicle functions. Connected Devices and Network Interfaces – Wireless and Ethernet connections that allow external access to the vehicle. Third-Party Apps and... As cars become more like computers on wheels, cybersecurity is becoming a major concern. With vehicles now connected to the internet and relying heavily on software, protecting them from cyber threats is essential. The Cyber Resilience Act (CRA) is a new European law designed to improve cybersecurity for digital products. While it does not directly apply to cars themselves (since they are already covered by other regulations), it still affects many digital systems within the vehicles. This article explains what the CRA is and how it impacts the automotive industry in simple terms. How Is Cybersecurity Already Regulated in the Automotive Industry? As the automotive industry evolves with advancements like autonomous vehicles and enhanced connectivity, cybersecurity has become a critical concern. Car manufacturers must already follow strict cybersecurity regulations to ensure vehicle safety. Some of the key regulations include: UNECE Regulations R155 and R156: These require vehicle manufacturers to implement Cybersecurity Management Systems (CSMS) and secure over-the-air (OTA) updates. R155 mandates risk management throughout the vehicle lifecycle, ensures cars are protected against hacking, unauthorized access, and other cyber risks. R156 instead focuses on securing software updates. Vehicle General Safety Regulation (EU 2019/2144): This EU law ensures that cars meet certain cybersecurity standards. It references the UN Regulation R155, which requires automakers to implement cybersecurity management systems. ISO/SAE 21434: An international cybersecurity standard for car manufacturers. This standard provides guidelines for managing cybersecurity risks during vehicle development. It emphasizes a structured risk assessment process (TARA) and ensures cybersecurity is integrated throughout the vehicle lifecycle, from design to decommissioning. Together, these regulations form the backbone of automotive cybersecurity, addressing both critical systems and the broader digital components of connected vehicles. These rules mainly focus on safety-critical systems, such as braking and steering. However, they do not fully cover other digital components in vehicles, such as infotainment systems, apps, and third-party software — which is where the CRA comes in. What Is the Cyber Resilience Act (CRA)? The Cyber Resilience Act (CRA) is a new EU regulation designed to improve cybersecurity for all digital products. It requires companies to ensure their software and hardware are secure, regularly updated, and protected against cyber threats. But aren’t vehicles already covered by cybersecurity regulations? Yes, the CRA does not apply to cars themselves, because they are already regulated under EU 2019/2144 and UN R155. However, it does apply to many digital systems and software within vehicles. Which Automotive Systems Are Affected by the CRA? While critical vehicle functions like braking and steering fall under existing regulations, other digital components and software may be subject to the CRA, including: Infotainment and Navigation Systems – Car dashboards that include web browsers, streaming services, and navigation software. Remote Access and Fleet Management Software – Tools that allow remote monitoring or control of vehicles. Over-the-Air (OTA) Update Systems – Software that updates infotainment systems, apps, or other non-critical vehicle functions. Connected Devices and Network Interfaces – Wireless and Ethernet connections that allow external access to the vehicle. Third-Party Apps and... As cars become more like computers on wheels, cybersecurity is becoming a major concern. With vehicles now connected to the internet and relying heavily on software, protecting them from cyber threats is essential. The Cyber Resilience Act (CRA) is a new European law designed to improve cybersecurity for digital products. While it does not directly apply to cars themselves (since they are already covered by other regulations), it still affects many digital systems within the vehicles. This article explains what the CRA is and how it impacts the automotive industry in simple terms. How Is Cybersecurity Already Regulated in the Automotive Industry? As the automotive industry evolves with advancements like autonomous vehicles and enhanced connectivity, cybersecurity has become a critical concern. Car manufacturers must already follow strict cybersecurity regulations to ensure vehicle safety. Some of the key regulations include: UNECE Regulations R155 and R156: These require vehicle manufacturers to implement Cybersecurity Management Systems (CSMS) and secure over-the-air (OTA) updates. R155 mandates risk management throughout the vehicle lifecycle, ensures cars are protected against hacking, unauthorized access, and other cyber risks. R156 instead focuses on securing software updates. Vehicle General Safety Regulation (EU 2019/2144): This EU law ensures that cars meet certain cybersecurity standards. It references the UN Regulation R155, which requires automakers to implement cybersecurity management systems. ISO/SAE 21434: An international cybersecurity standard for car manufacturers. This standard provides guidelines for managing cybersecurity risks during vehicle development. It emphasizes a structured risk assessment process (TARA) and ensures cybersecurity is integrated throughout the vehicle lifecycle, from design to decommissioning. Together, these regulations form the backbone of automotive cybersecurity, addressing both critical systems and the broader digital components of connected vehicles. These rules mainly focus on safety-critical systems, such as braking and steering. However, they do not fully cover other digital components in vehicles, such as infotainment systems, apps, and third-party software — which is where the CRA comes in. What Is the Cyber Resilience Act (CRA)? The Cyber Resilience Act (CRA) is a new EU regulation designed to improve cybersecurity for all digital products. It requires companies to ensure their software and hardware are secure, regularly updated, and protected against cyber threats. But aren’t vehicles already covered by cybersecurity regulations? Yes, the CRA does not apply to cars themselves, because they are already regulated under EU 2019/2144 and UN R155. However, it does apply to many digital systems and software within vehicles. Which Automotive Systems Are Affected by the CRA? While critical vehicle functions like braking and steering fall under existing regulations, other digital components and software may be subject to the CRA, including: Infotainment and Navigation Systems – Car dashboards that include web browsers, streaming services, and navigation software. Remote Access and Fleet Management Software – Tools that allow remote monitoring or control of vehicles. Over-the-Air (OTA) Update Systems – Software that updates infotainment systems, apps, or other non-critical vehicle functions. Connected Devices and Network Interfaces – Wireless and Ethernet connections that allow external access to the vehicle. Third-Party Apps and... As cars become more like computers on wheels, cybersecurity is becoming a major concern. With vehicles now connected to the internet and relying heavily on software, protecting them from cyber threats is essential. The Cyber Resilience Act (CRA) is a new European law designed to improve cybersecurity for digital products. While it does not directly apply to cars themselves (since they are already covered by other regulations), it still affects many digital systems within the vehicles. This article explains what the CRA is and how it impacts the automotive industry in simple terms. How Is Cybersecurity Already Regulated in the Automotive Industry? As the automotive industry evolves with advancements like autonomous vehicles and enhanced connectivity, cybersecurity has become a critical concern. Car manufacturers must already follow strict cybersecurity regulations to ensure vehicle safety. Some of the key regulations include: UNECE Regulations R155 and R156: These require vehicle manufacturers to implement Cybersecurity Management Systems (CSMS) and secure over-the-air (OTA) updates. R155 mandates risk management throughout the vehicle lifecycle, ensures cars are protected against hacking, unauthorized access, and other cyber risks. R156 instead focuses on securing software updates. Vehicle General Safety Regulation (EU 2019/2144): This EU law ensures that cars meet certain cybersecurity standards. It references the UN Regulation R155, which requires automakers to implement cybersecurity management systems. ISO/SAE 21434: An international cybersecurity standard for car manufacturers. This standard provides guidelines for managing cybersecurity risks during vehicle development. It emphasizes a structured risk assessment process (TARA) and ensures cybersecurity is integrated throughout the vehicle lifecycle, from design to decommissioning. Together, these regulations form the backbone of automotive cybersecurity, addressing both critical systems and the broader digital components of connected vehicles. These rules mainly focus on safety-critical systems, such as braking and steering. However, they do not fully cover other digital components in vehicles, such as infotainment systems, apps, and third-party software — which is where the CRA comes in. What Is the Cyber Resilience Act (CRA)? The Cyber Resilience Act (CRA) is a new EU regulation designed to improve cybersecurity for all digital products. It requires companies to ensure their software and hardware are secure, regularly updated, and protected against cyber threats. But aren’t vehicles already covered by cybersecurity regulations? Yes, the CRA does not apply to cars themselves, because they are already regulated under EU 2019/2144 and UN R155. However, it does apply to many digital systems and software within vehicles. Which Automotive Systems Are Affected by the CRA? While critical vehicle functions like braking and steering fall under existing regulations, other digital components and software may be subject to the CRA, including: Infotainment and Navigation Systems – Car dashboards that include web browsers, streaming services, and navigation software. Remote Access and Fleet Management Software – Tools that allow remote monitoring or control of vehicles. Over-the-Air (OTA) Update Systems – Software that updates infotainment systems, apps, or other non-critical vehicle functions. Connected Devices and Network Interfaces – Wireless and Ethernet connections that allow external access to the vehicle. Third-Party Apps and... Mit der fortschreitenden Digitalisierung werden Fahrzeuge zunehmend zu „Computern auf Rädern“. In diesem Zusammenhang gewinnt Cybersicherheit erheblich an Bedeutung. Moderne Fahrzeuge sind vernetzt und stark softwarebasiert – ein effektiver Schutz vor Cyberbedrohungen ist daher unerlässlich, um Sicherheit, Funktionalität und Vertrauen nachhaltig zu gewährleisten. Der Cyber Resilience Act (CRA) ist ein neues europäisches Gesetz, das darauf abzielt, die Cybersicherheit digitaler Produkte deutlich zu stärken. Auch wenn Fahrzeuge als Gesamtsysteme nicht unmittelbar unter den CRA fallen – da sie bereits durch sektorspezifische Vorschriften reguliert sind – betrifft das Gesetz dennoch zahlreiche digitale Komponenten und Systeme innerhalb moderner Fahrzeuge. Dieser Artikel erläutert in allgemeinverständlicher Form, worum es beim CRA geht und welche Auswirkungen er auf die Automobilindustrie haben kann. Wie Cybersicherheit in der Automobilindustrie bereits reguliert wird Mit dem Fortschritt hin zu vernetzten und zunehmend autonomen Fahrzeugen gewinnt Cybersicherheit in der Automobilbranche stetig an Bedeutung. Fahrzeughersteller sind bereits heute verpflichtet, umfassende Cybersicherheitsvorgaben einzuhalten, um die Integrität, Sicherheit und Verfügbarkeit ihrer Systeme zu gewährleisten. Zu den zentralen Regelwerken zählen: UNECE Regelungen R155 und R156: Diese Vorschriften verpflichten Fahrzeughersteller zur Implementierung von Cybersicherheits-Managementsystemen (CSMS) sowie zur Gewährleistung sicherer Over-the-Air-Updates (OTA). o R155 verlangt ein kontinuierliches Risikomanagement über den gesamten Fahrzeuglebenszyklus hinweg und schützt vor Hacking, unbefugtem Zugriff und anderen Cyberrisiken. o R156 legt den Fokus auf die Sicherheit und Integrität von Software-Updates. Allgemeine Sicherheitsverordnung für Fahrzeuge (EU 2019/2144): Diese Verordnung stellt sicher, dass Fahrzeuge spezifische Cybersicherheitsanforderungen erfüllen. Sie verweist explizit auf UNECE R155 und fordert die Umsetzung eines CSMS durch die Hersteller. ISO/SAE 21434: Ein international anerkannter Standard zur Cybersicherheit im Automobilbereich. Er definiert Prozesse zur Identifikation und zum Management von Cybersicherheitsrisiken über den gesamten Produktlebenszyklus hinweg – von der Entwicklung bis zur Außerbetriebnahme. Zentrale Elemente sind strukturierte Risikoanalysen (TARA) und die durchgängige Integration von Sicherheitsmaßnahmen. Gemeinsam bilden die genannten Regelwerke das Fundament der Cybersicherheit in der Automobilbranche und adressieren sowohl sicherheitskritische Systeme als auch zentrale digitale Fahrzeugkomponenten. Der Fokus liegt dabei vor allem auf Systemen mit direktem Einfluss auf die Fahrzeugsicherheit – etwa Brems- und Lenksysteme. Digitale Komponenten wie Infotainmentsysteme, Fahrzeug-Apps oder Software von Drittanbietern werden jedoch bislang nur unzureichend erfasst. Genau an dieser Stelle setzt der Cyber Resilience Act (CRA) an und schließt eine bedeutende regulatorische Lücke. Was ist der Cyber Resilience Act (CRA)? Der Cyber Resilience Act (CRA) ist eine neue EU-Verordnung, die darauf abzielt, die Cybersicherheit digitaler Produkte über ihren gesamten Lebenszyklus hinweg zu stärken. Hersteller und Anbieter werden verpflichtet, ihre Hard- und Softwareprodukte sicher zu gestalten, regelmäßige Sicherheitsupdates bereitzustellen und sie wirksam gegen Cyberbedrohungen abzusichern. Aber gelten für Fahrzeuge nicht bereits Cybersicherheitsvorgaben? Ja, Fahrzeuge selbst unterliegen bereits bestehenden Regelungen – insbesondere der EU-Verordnung 2019/2144 sowie der UN-Regelung R155. Der CRA greift jedoch ergänzend für zahlreiche digitale Systeme und Softwarekomponenten innerhalb von Fahrzeugen, die bislang nicht im Fokus der sektorspezifischen Vorschriften stehen. Welche Fahrzeugsysteme fallen unter den Geltungsbereich des Cyber Resilience Act (CRA)? Während sicherheitskritische Fahrzeugfunktionen wie Bremsen und Lenkung bereits durch bestehende Vorschriften abgedeckt sind, betrifft der CRA eine Vielzahl weiterer digitaler Komponenten und Softwarelösungen im Fahrzeugumfeld. Dazu zählen insbesondere:... The Challenges of Maintaining Legacy Software A quick, easy-to-understand overview is what many people want in life. Especially with historically grown software systems. Even the developers themselves need a comprehensive overview of the system from time to time, even if the focus during the development phase and afterwards in the maintenance phase is quite different. Where have monster classes formed? Where are the dependencies getting tangled up? Where are too many classes linked together? Am I at my mental limit or is the code too complex? Such questions can be essential in order to keep older software alive - not as a coma patient, but as an agile, robust pensioner that you only see on Mondays for a coffee party. Introducing Bisquat2: Simplifying Static Analysis Our Bisquat2 manages software regardless of its retirement status. Good experience with static quality analysis is usually gained with continuous use of it. The status of the software is checked at regular intervals, so that aggravations can be dealt with on time. Companies often integrate tools such as Sonarqube into the development process. However, our experience teaches us that many developers are unable to interpret the results correctly, often misinterpret them and generally develop an antipathy towards the constant warnings. To the point where many developers eventually ignore the messages completely and switch them off. We know this from real life, except that you end up dragging yourself to the doctor when the physical warning signals become unmistakable. So why not do the same with highly complex software systems? Bisquat2 is designed to avoid long tool chains and a huge number of consecutive work steps. Upload the code once, select the test tool, check the default values, press the button and off you go. It's like a quick run-through of medical check-ups to locate and eliminate minor ailments. The static analysis provides very good insights into the complexity, dependencies, content and quality of the individual source files through various analyzers and then offers the possibility of gaining a system-wide overview with the antipattern and hotspot analyzers. At the same time, images are generated from the data, which also make it easy for the software layman to understand the problems. Analyzing Content: LOC, NOM, and CR Metrics The content analyzer is responsible for the largest amount of data - the basic structure. The length of the classes (LOC, “Lines Of Code”) and methods, the number of methods (NOM, “Number Of Methods”), the number of remaining “TODO ‘s or ’FIXME ‘s and the comment/code ratio (CR, ’Comment Ratio”) are calculated here. These so-called metrics, such as LOC, NOM and CR, are also calculated by other analysis tools and there are generally recognized threshold values for assessing the quality of software and calculating anti-patterns. If metrics such as LOC or NOM exceed the limit values, it can be assumed that the code is unclear and is usually concentrated in a few oversized classes. If “TODO‘s” or “FIXME’s ” are discovered in the code, this usually indicates incomplete or... The Challenges of Maintaining Legacy Software A quick, easy-to-understand overview is what many people want in life. Especially with historically grown software systems. Even the developers themselves need a comprehensive overview of the system from time to time, even if the focus during the development phase and afterwards in the maintenance phase is quite different. Where have monster classes formed? Where are the dependencies getting tangled up? Where are too many classes linked together? Am I at my mental limit or is the code too complex? Such questions can be essential in order to keep older software alive - not as a coma patient, but as an agile, robust pensioner that you only see on Mondays for a coffee party. Introducing Bisquat2: Simplifying Static Analysis Our Bisquat2 manages software regardless of its retirement status. Good experience with static quality analysis is usually gained with continuous use of it. The status of the software is checked at regular intervals, so that aggravations can be dealt with on time. Companies often integrate tools such as Sonarqube into the development process. However, our experience teaches us that many developers are unable to interpret the results correctly, often misinterpret them and generally develop an antipathy towards the constant warnings. To the point where many developers eventually ignore the messages completely and switch them off. We know this from real life, except that you end up dragging yourself to the doctor when the physical warning signals become unmistakable. So why not do the same with highly complex software systems? Bisquat2 is designed to avoid long tool chains and a huge number of consecutive work steps. Upload the code once, select the test tool, check the default values, press the button and off you go. It's like a quick run-through of medical check-ups to locate and eliminate minor ailments. The static analysis provides very good insights into the complexity, dependencies, content and quality of the individual source files through various analyzers and then offers the possibility of gaining a system-wide overview with the antipattern and hotspot analyzers. At the same time, images are generated from the data, which also make it easy for the software layman to understand the problems. Analyzing Content: LOC, NOM, and CR Metrics The content analyzer is responsible for the largest amount of data - the basic structure. The length of the classes (LOC, “Lines Of Code”) and methods, the number of methods (NOM, “Number Of Methods”), the number of remaining “TODO ‘s or ’FIXME ‘s and the comment/code ratio (CR, ’Comment Ratio”) are calculated here. These so-called metrics, such as LOC, NOM and CR, are also calculated by other analysis tools and there are generally recognized threshold values for assessing the quality of software and calculating anti-patterns. If metrics such as LOC or NOM exceed the limit values, it can be assumed that the code is unclear and is usually concentrated in a few oversized classes. If “TODO‘s” or “FIXME’s ” are discovered in the code, this usually indicates incomplete or... Die Herausforderungen bei der Wartung von veralteter Software Einen schnellen, schön verständlichen Überblick, das ist es, was sich viele im Leben wünschen. Besonders bei historisch gewachsenen Softwaresystemen. Sogar die Entwickler selbst brauchen hin und wieder einen umfangreichen Überblick über das System, auch wenn sich der Fokus während der Entwicklungsphase und danach in der Wartungsphase durchaus unterscheidet. Wo haben sich Monsterklassen gebildet? Wo verheddern sich die Abhängigkeiten? Wo sind zu viele Klassen miteinander verbunden? Bin ich an meiner mentalen Grenze oder ist der Code zu komplex? Solche Fragen können essenziell sein, um ältere Software nicht als Komapatient am Leben zu erhalten, sondern als agilen robusten Rentner, den man nur montags zum Kaffeekränzchen sieht. Wir stellen vor: Bisquat2: Vereinfachte statische Analyse Unser Bisquat2 betreut Software unabhängig von ihrem Rentenstatus. Gute Erfahrung mit statischer Qualitätsanalyse wird meist bei kontinuierlicher Anwendung gemacht. Dabei wird der Status in regelmäßigen Abständen kontrolliert, damit Aggravationen präzise behandelt werden können. Oft integrieren Firmen Tools wie Sonarqube in den Entwicklungsprozess. Unsere Erfahrung lehrt uns hier allerdings, dass viele Entwickler die Ergebnisse nicht richtig interpretieren einschätzen können, oft missdeuten und allgemein eine Antipathie gegen die ständigen Warnungen entfalten. Bis zu dem Punkt, an dem viele Entwickler die Meldungen schließlich vollständig ignorieren und abschalten. Das kennen wir aus dem echten Leben, nur dass man sich dann doch mal zum Arzt schleppt, wenn die körperlichen Warnsignale unüberhörbar werden. Also warum nicht das Gleiche mit hochkomplexen Softwaresystemen machen? Mit Bisquat2 sollen lange Werkzeugketten und Unmengen von aufeinander folgenden Arbeitsschritten vermieden werden. Einmal Code hochladen, Prüfwerkzeug auswählen, noch einmal die Defaultwerte überprüfen, Knopf drücken und los. Quasi ein Schnelldurchlauf der ärztlichen Vorsorge, um kleine Zipperlein zu orten und beseitigen zu können. Die statische Analyse gibt durch verschiedene Analyzer jeweils sehr gute Einblicke zu Komplexität, Abhängigkeiten, Inhalt und Qualität der einzelnen Quelldateien und bietet im Anschluss mit dem Antipattern- und Hotspot-Analyzern die Möglichkeit, sich einen systemweiten Überblick zu verschaffen. Gleichzeitig werden Bilder aus den Daten erzeugt, die auch dem Software-Laien die Problematiken einfach darlegen. Inhaltsanalyse: LOC-, NOM- und CR-Metriken Der Content-Analyzer ist für die größte Datenmenge - der Grundstruktur - verantwortlich. So werden hier die Länge der Klassen (LOC, „Lines Of Code“) und Methoden, die Anzahl der Methoden (NOM, „Number Of Methods“), die Anzahl übrig gebliebener „TODO“s oder „FIXME“s und das Verhältnis Kommentar/Code (CR, „Comment Ratio“) berechnet. Diese sogenannten Metriken wie LOC, NOM und CR, werden auch von anderen Analysewerkzeugen berechnet und es gibt allgemein anerkannte Grenzwerte, um die Qualität von Software einzuschätzen und Antipatterns berechnen zu können. Überschreiten gerade Metriken wie LOC oder NOM die Grenzwerte, kann man davon ausgehen, dass der Code unübersichtlich ist und sich meist in wenigen übergroßen Klassen ballt. Falls „TODO“s oder „FIXME“s im Code entdeckt werden, deutet dies meist auf unvollständigen oder suboptimalen, überflüssigen oder sogar nicht-funktionierenden Code hin. Die Kommentarrate, festgehalten in CR, sollte ausgewogen, heißt nicht zu groß und nicht zu gering, sein. Kommentare sind wichtig für nachfolgende Entwickler, um ein Verständnis für den Code zu gewinnen. Komplexe Stellen verdienen hier natürlich mehr Aufmerksamkeit. Mit einer Gesamtübersicht... Navigating Open-Source-Compliance in 2024: The Critical Role of Scanning Depth and SBOMs In the evolving landscape of cybersecurity and software compliance, the importance of open source compliance cannot be overstated. New regulatory requirements like the Cyber Resilience Act (CRA), the Network and Information Security Directive (NIS2), and the Digital Operational Resilience Act (DORA) have introduced stricter obligations for organizations, especially those operating in the European Union. Meeting these compliance obligations not only mitigates legal risk but also enhances an organization’s security posture. A comprehensive approach to open source compliance starts with the creation of a detailed Software Bill of Materials (SBOM) and a deep, file-based scan to identify all components and licenses within the software. Understanding the importance of an SBOM A is essentially an inventory of all components within a software application, including open source libraries, proprietary code, and third-party tools. An SBOM enables an organization to manage and monitor the risk of open source components by identifying all potential security vulnerabilities and licensing obligations. This level of transparency is crucial not only for compliance but also for risk management and software integrity. A truly effective SBOM must include all assets used along the entire supply chain, encompassing every piece of code integrated from third parties and all dependencies associated with those components. By capturing every aspect of third-party and open source code—along with its dependencies—an SBOM provides a full view of potential risks and obligations, ensuring comprehensive oversight of all components involved in the software product. To meet regulatory expectations, organizations must go beyond merely cataloging high-level components. A thorough SBOM needs to encompass every individual license associated with the software, regardless of whether it is at the top level or embedded within other components. This depth of scanning is essential for identifying the potential risks each license might pose to the organization’s legal and operational security. Why Scanning Depth Matters in Open Source Compliance For an SBOM to be effective, it must capture a complete inventory of licenses associated with each open source component. Incomplete scanning or reliance on top-level license reporting can lead to significant gaps, especially under the stringent requirements of CRA, NIS2, and DORA. Merely reporting the top-level license may overlook subcomponents with their own distinct licenses, which could impose additional obligations or restrictions. A deep snippet scan enables organizations to detect these nuanced licensing requirements within each component. Without such a scan, critical elements—such as code snippets, embedded media, and patches—can go unnoticed, leaving compliance gaps. Conducting a file-based audit that examines each file and its respective license ensures that organizations fully understand the scope of their obligations and avoid unintentional violations. Diving into the Details: Code Snippets and Media Licensing A robust scan should not only detect open source libraries and their respective licenses but also investigate individual code snippets. This is particularly relevant for snippets copied from online sources such as Stack Overflow, which may carry restrictive licenses. Stack Overflow, for example, also has licensing terms that may vary depending on... Open-Source-Compliance im Jahr 2024: Die entscheidende Rolle von Scan-Tiefe und SBOMs Die Welt der Cybersicherheit und Software-Compliance steht an einem Wendepunkt: Neue gesetzliche Regelungen wie der Cyber Resilience Act (CRA), die Network und Information Security Directive (NIS2) und der Digital Operational Resilience Act (DORA) setzen Organisationen, besonders in der Europäischen Union, unter erhöhten Handlungsdruck. Die Zeiten, in denen Open-Source-Compliance ein „Nice-to-have“ war, sind endgültig vorbei – sie ist heute ein essenzieller Bestandteil einer sicheren und rechtskonformen digitalen Infrastruktur. Doch warum ist das so? Compliance bedeutet mehr als das bloße Abhaken gesetzlicher Vorgaben. Sie schützt Unternehmen nicht nur vor rechtlichen Fallstricken, sondern stärkt auch aktiv deren Sicherheitslage. Der Schlüssel liegt in einem umfassenden Ansatz: Der erste Schritt ist die Erstellung einer Software-Stückliste (SBOM), kombiniert mit einem präzisen, dateibasierten Scan, um alle genutzten Komponenten und deren Lizenzen zu identifizieren. Erfahren Sie, warum Open-Source-Compliance der Grundpfeiler moderner Cybersicherheit ist – und wie Sie Ihr Unternehmen fit für die Herausforderungen der neuen regulatorischen Ära machen können. Die Bedeutung einer Stückliste verstehen Eine Software-Stückliste (SBOM) ist im Wesentlichen eine Bestandsaufnahme aller Komponenten innerhalb einer Softwareanwendung, einschließlich Open-Source-Bibliotheken, proprietärem Code von Drittanbietern. Eine SBOM ermöglicht es einer Organisation, das Risiko von Open-Source-Komponenten zu managen und zu überwachen, indem sie alle potenziellen Sicherheitslücken und Lizenzverpflichtungen identifiziert. Diese Transparenz ist nicht nur für die Einhaltung von Vorschriften, sondern auch für das Risikomanagement und die Softwareintegrität von entscheidender Bedeutung. Eine wirklich effektive SBOM muss alle in der gesamten Lieferkette verwendeten Bestandteile umfassen, einschließlich jedes von Dritten integrierten Codes und aller mit diesen Komponenten verbundenen Abhängigkeiten. Durch die Erfassung aller Aspekte von Drittanbieter- und Open-Source-Code – zusammen mit seinen Abhängigkeiten – bietet eine SBOM einen vollständigen Überblick über potenzielle Risiken und Verpflichtungen und gewährleistet eine umfassende Übersicht über alle am Softwareprodukt beteiligten Komponenten. Um die Erwartungen der Aufsichtsbehörden zu erfüllen, müssen Organisationen über die grobe Katalogisierung von Komponenten auf hoher Ebene hinausgehen. Eine gründliche SBOM muss jede einzelne Komponente und Lizenz umfassen, die mit der Software verbunden ist, unabhängig davon, ob sie auf der obersten Ebene oder in andere Komponenten eingebettet ist. Diese Gründlichkeit beim Scannen ist unerlässlich, um die potenziellen Risiken zu ermitteln, die jede Lizenz für die rechtliche und betriebliche Sicherheit der Organisation darstellen könnte. Als Beispiel seien hier Codefragmente von Stack Overflow genannt, die sich in fast jedem Projekt finden. Warum die Scan-Tiefe bei der Open-Source-Compliance wichtig ist Damit eine SBOM effektiv ist, muss sie Lizenzen erfassen, die mit jeder Open-Source-Komponente verbunden sind. Unvollständiges Scannen oder das Vertrauen auf die Top-Level-Lizenz kann zu erheblichen Lücken führen, insbesondere unter den strengen Anforderungen von CRA, NIS2 und DORA. Wenn nur die Top-Level-Lizenz gemeldet wird, können Unterkomponenten mit eigenen Lizenzen übersehen werden, die zusätzliche bekannte Sicherheitslücken oder Verpflichtungen oder Einschränkungen mit sich bringen könnten. Oft finden sich in einem größeren Projekt beispielsweise einzelne Dateien in einer Komponente, die anderen Lizenzen unterliegen oder aus einem anderen Projekt kopiert wurden. Ein tiefgehender Snippet-Scan ermöglicht es Organisationen, diese nuancierten Lizenzanforderungen in jeder Komponente zu erkennen. Ohne einen solchen Scan können kritische Elemente –... Navigating Open-Source-Compliance in 2024: The Critical Role of Scanning Depth and SBOMs In the evolving landscape of cybersecurity and software compliance, the importance of open source compliance cannot be overstated. New regulatory requirements like the Cyber Resilience Act (CRA), the Network and Information Security Directive (NIS2), and the Digital Operational Resilience Act (DORA) have introduced stricter obligations for organizations, especially those operating in the European Union. Meeting these compliance obligations not only mitigates legal risk but also enhances an organization’s security posture. A comprehensive approach to open source compliance starts with the creation of a detailed Software Bill of Materials (SBOM) and a deep, file-based scan to identify all components and licenses within the software. Understanding the importance of an SBOM A As a member of the OpenChain community Bitsea maintains partnerships worldwide. Today we would like to share insights on open source compliance in Taiwan, provided by Claire Cheng. Cheng has been working for the OCF in Taiwan for a long time and advises companies on open source processes and trains customers on the special features of using open source. This article reflects on my three years of work promoting OpenChain at the Open Culture Foundation (OCF), where I focused on understanding and advocating for the project. Despite our efforts, adoption in Taiwan remains limited, with companies often having inconsistent approaches to open-source licensing and lacking strong incentives to adopt ISO 5230 and ISO 18974 without external pressures. I want to document our progress and the challenges we faced to help inform future efforts in OpenChain advocacy. 2 Key ISO Standards Addressing the Open Source Management Problems in OpenChain Project. The Linux Foundation's 2023 survey found that over 90% of organizations use open-source software, as building everything from scratch is impractical. Like food traceability builds trust by making information transparent, the software supply chain needs a system to help vendors manage code and ensure quality. Without this, it’s hard to verify code origins, versions, or compliance with licensing, weakening manufacturers' ability to address security and legal issues. OpenChain, initiated by the Linux Foundation, addresses these challenges by ensuring reliable, consistent management of open-source components across the supply chain. Supported by a global community, it has developed two ISO standards—ISO 5230, which aids compliance with open-source licenses (with 121 certified companies), and ISO 18974, launched in December 2023, to secure open-source software, already adopted by companies like LG, BlackBerry, and Honda. Why Do You Need OpenChain? Today’s specialized supply chains rely on collaboration across multiple suppliers to create competitive products. Each company contributes only a portion, making it essential to track components and ensure compliance. Imagine facing a major security vulnerability: if I can’t quickly verify with my team whether we’re affected, hackers may exploit the issue, risking customer trust. Or, if a customer finds a licensing violation in a component, I’d need to confirm it with the upstream supplier, risking reputation and potential legal issues. OpenChain provides a traceability system for tracking components and ensuring licensing compliance, enabling manufacturers to respond swiftly to security or compliance issues and protect customer trust. Image source: AI-generated As the division of labor in modern industries becomes more complex, the completion of a product is the result of collaboration between various companies or departments. The traceability system of the open-source component enhances management quality and trust in the supply chain. OpenChain in Taiwan: Currently Only Early Adopters Are Considering to Adopt. In 2020, OCF began promoting open source compliance, and by 2022 successfully guided KKCompany to become the first, and currently the only, company in Taiwan to obtain ISO 5230 certification through third-party assistance and approval. Open source compliance is still in the "early adopter" stage in Taiwan. Although a small group within some companies... Als Mitglied der OpenChain-Community pflegt Bitsea weltweit Partnerschaften. Heute möchten wir Ihnen Einblicke in die Open Source Compliance in Taiwan geben, die von Claire Cheng zur Verfügung gestellt wurden. Cheng arbeitet seit langem für die OCF in Taiwan und berät Unternehmen zu Open-Source-Prozessen und schult Kunden zu den Besonderheiten beim Einsatz von Open Source. Dieser Artikel reflektiert meine dreijährige Arbeit zur Förderung von OpenChain bei der Open Culture Foundation (OCF), wo ich mich darauf konzentriert habe das Projekt zu unterstützen und zu bewerben. Trotz unserer Bemühungen ist die Akzeptanz in Taiwan nach wie vor begrenzt, da die Unternehmen oft uneinheitliche Ansätze zur Open-Source-Lizenzierung verfolgen und es ihnen an starken Anreizen fehlt, ISO 5230 und ISO 18974 ohne externen Druck zu übernehmen. Ich möchte unsere Fortschritte und die Herausforderungen, mit denen wir konfrontiert waren, dokumentieren, um künftige Bemühungen in der OpenChain-Interessenvertretung zu unterstützen. 2 wichtige ISO-Standards zur Lösung der Probleme beim Open-Source-Management im OpenChain-Projekt. Eine Umfrage der Linux Foundation aus dem Jahr 2023 ergab, dass über 90 % der Organisationen Open-Source-Software verwenden, da es unpraktisch ist, alles von Grund auf neu zu erstellen. So wie die Rückverfolgbarkeit von Zutaten von Lebensmitteln durch transparente Informationen Vertrauen schafft, benötigt die Software-Lieferkette ein System, das den Anbietern bei der Verwaltung des Codes hilft und die Qualität sicherstellt. Ohne diese ist es schwierig, die Herkunft, die Versionen oder die Einhaltung von Lizenzen zu überprüfen, was die Fähigkeit der Hersteller schwächt, Sicherheits- und Rechtsfragen anzugehen. OpenChain, initiiert von der Linux Foundation, begegnet diesen Herausforderungen, indem es eine zuverlässige, konsistente Verwaltung von Open-Source-Komponenten in der gesamten Lieferkette sicherstellt. Mit Unterstützung einer globalen Gemeinschaft hat OpenChain zwei ISO-Standards entwickelt: ISO 5230, der die Einhaltung von Open-Source-Lizenzen unterstützt (mit 121 zertifizierten Unternehmen), und ISO 18974, der im Dezember 2023 eingeführt wurde, um Open-Source-Software zu sichern, und bereits von Unternehmen wie LG, BlackBerry und Honda übernommen wurde. Warum brauchen Sie OpenChain? Die heutigen spezialisierten Lieferketten sind auf die Zusammenarbeit mehrerer Zulieferer angewiesen, um wettbewerbsfähige Produkte herzustellen. Jedes Unternehmen steuert nur einen Teil bei, weshalb es unerlässlich ist, die Herkunft der Komponenten zu verfolgen und die Einhaltung der Vorschriften sicherzustellen. Stellen Sie sich vor, Sie stehen vor einer großen Sicherheitslücke: Wenn ich nicht schnell mit meinem Team überprüfen kann, ob wir betroffen sind, könnten Hacker das Problem ausnutzen und das Vertrauen der Kunden aufs Spiel setzen. Oder wenn ein Kunde einen Lizenzverstoß in einer Komponente feststellt, müsste ich dies mit dem vorgelagerten Lieferanten prüfen. Dies birgt das Risiko für potenzielle rechtliche Probleme. OpenChain bietet ein System zum Management von Komponenten und zur Sicherstellung der Einhaltung von Lizenzen, sodass Hersteller schnell auf Sicherheits- oder Compliance-Probleme reagieren und das Vertrauen der Kunden schützen können. Bildquelle: KI-generiert Da die Arbeitsteilung in modernen Industrien immer komplexer wird, ist die Fertigstellung eines Produkts das Ergebnis der Zusammenarbeit zwischen verschiedenen Unternehmen oder Abteilungen. Das Rückverfolgungssystem der Open-Source-Komponente verbessert die Managementqualität und das Vertrauen in die Lieferkette. OpenChain in Taiwan: Derzeit ziehen nur Frühanwender eine Einführung in Betracht. Im Jahr 2020 begann OCF, die Einhaltung von Open-Source-Standards zu... As a member of the OpenChain community Bitsea maintains partnerships worldwide. Today we would like to share insights on open source compliance in Taiwan, provided by Claire Cheng. Cheng has been working for the OCF in Taiwan for a long time and advises companies on open source processes and trains customers on the special features of using open source. This article reflects on my three years of work promoting OpenChain at the Open Culture Foundation (OCF), where I focused on understanding and advocating for the project. Despite our efforts, adoption in Taiwan remains limited, with companies often having inconsistent approaches to open-source licensing and lacking strong incentives to adopt ISO 5230 and ISO 18974 without external pressures. I want to document our progress and the challenges we faced to help inform future efforts in OpenChain advocacy. 2 Key ISO Standards Addressing the Open Source Management Problems in OpenChain Project. The Linux Foundation's 2023 survey found that over 90% of organizations use open-source software, as building everything from scratch is impractical. Like food traceability builds trust by making information transparent, the software supply chain needs a system to help vendors manage code and ensure quality. Without this, it’s hard to verify code origins, versions, or compliance with licensing, weakening manufacturers' ability to address security and legal issues. OpenChain, initiated by the Linux Foundation, addresses these challenges by ensuring reliable, consistent management of open-source components across the supply chain. Supported by a global community, it has developed two ISO standards—ISO 5230, which aids compliance with open-source licenses (with 121 certified companies), and ISO 18974, launched in December 2023, to secure open-source software, already adopted by companies like LG, BlackBerry, and Honda. Why Do You Need OpenChain? Today’s specialized supply chains rely on collaboration across multiple suppliers to create competitive products. Each company contributes only a portion, making it essential to track components and ensure compliance. Imagine facing a major security vulnerability: if I can’t quickly verify with my team whether we’re affected, hackers may exploit the issue, risking customer trust. Or, if a customer finds a licensing violation in a component, I’d need to confirm it with the upstream supplier, risking reputation and potential legal issues. OpenChain provides a traceability system for tracking components and ensuring licensing compliance, enabling manufacturers to respond swiftly to security or compliance issues and protect customer trust. Image source: AI-generated As the division of labor in modern industries becomes more complex, the completion of a product is the result of collaboration between various companies or departments. The traceability system of the open-source component enhances management quality and trust in the supply chain. OpenChain in Taiwan: Currently Only Early Adopters Are Considering to Adopt. In 2020, OCF began promoting open source compliance, and by 2022 successfully guided KKCompany to become the first, and currently the only, company in Taiwan to obtain ISO 5230 certification through third-party assistance and approval. Open source compliance is still in the "early adopter" stage in Taiwan. Although a small group within some companies... Imagine you could search through every single component of your software like a map - identify risks at a glance, track down hidden dependencies and effortlessly expose vulnerabilities. This is exactly what a software bill of materials (SBOM) makes possible! This article explains why this “list of ingredients” is indispensable for modern software projects today, especially as open source now accounts for a lion's share of development. Even better: in an innovative research project with the Bonn-Rhein-Sieg University of Applied Sciences, supported by the Federal Ministry for Economic Affairs and Climate Protection, a new type of visualization was developed. This not only allows risks to be identified, but also simulated, so that even complex licensing and compatibility problems become visible. Immerse yourself in the world of SBOM - an exciting journey of discovery through the hidden layers of your software! Put yourself in the shoes of an IT security manager in a hospital. You receive an SBOM for a new patient management system that you are to implement. This SBOM is several hundred pages long and lists thousands of software components, libraries and dependencies. How do you proceed? This question is more difficult than expected, but first: where does an SBOM even come from? Experienced developers do not write their code from scratch, but use existing software, commercial packages and open source for development. The reasons for using open source are to improve productivity, shorten development time and reduce development costs. AI is providing more and more support in the creation of software. High-quality code can be generated at lightning speed using code from open source repositories. We see this across all industries (automotive, embedded, IoT, healthcare, finance,... ), and also across different technologies (Linux, Windows, embedded, containers, SaaS). Even a simple electric toothbrush or a cooking appliance like the Thermomix contain a large amount of open source. Meanwhile, open source has a share of 70%-90% in an average project. It is important to consider a number of risks here: cyber security, respect for intellectual property, licensing requirements (such as publication of code or naming of authors), export restrictions, avoidance of incompatibilities, future-proofing. For legally compliant use, all open source components in a software must be known and continuously checked for security gaps or changes. A software bill of materials (SBOM) specifies the inventory of components used to create a software artifact such as a software application. It is comparable to an ingredient list on a food package: just as one can consult a label to avoid foods that may cause allergies, SBOMs can help organizations or individuals avoid consuming software that could harm them. The concept of the bill of materials is well established in traditional manufacturing as part of supply chain management. A manufacturer uses a bill of materials to track the parts it uses to manufacture a product. If defects are later found in a particular part, the affected products can be easily located using the BOM. A software bill of materials (SBOM) is a formal data... Imagine you could search through every single component of your software like a map - identify risks at a glance, track down hidden dependencies and effortlessly expose vulnerabilities. This is exactly what a software bill of materials (SBOM) makes possible! This article explains why this “list of ingredients” is indispensable for modern software projects today, especially as open source now accounts for a lion's share of development. Even better: in an innovative research project with the Bonn-Rhein-Sieg University of Applied Sciences, supported by the Federal Ministry for Economic Affairs and Climate Protection, a new type of visualization was developed. This not only allows risks to be identified, but also simulated, so that even complex licensing and compatibility problems become visible. Immerse yourself in the world of SBOM - an exciting journey of discovery through the hidden layers of your software! Put yourself in the shoes of an IT security manager in a hospital. You receive an SBOM for a new patient management system that you are to implement. This SBOM is several hundred pages long and lists thousands of software components, libraries and dependencies. How do you proceed? This question is more difficult than expected, but first: where does an SBOM even come from? Experienced developers do not write their code from scratch, but use existing software, commercial packages and open source for development. The reasons for using open source are to improve productivity, shorten development time and reduce development costs. AI is providing more and more support in the creation of software. High-quality code can be generated at lightning speed using code from open source repositories. We see this across all industries (automotive, embedded, IoT, healthcare, finance,... ), and also across different technologies (Linux, Windows, embedded, containers, SaaS). Even a simple electric toothbrush or a cooking appliance like the Thermomix contain a large amount of open source. Meanwhile, open source has a share of 70%-90% in an average project. It is important to consider a number of risks here: cyber security, respect for intellectual property, licensing requirements (such as publication of code or naming of authors), export restrictions, avoidance of incompatibilities, future-proofing. For legally compliant use, all open source components in a software must be known and continuously checked for security gaps or changes. A software bill of materials (SBOM) specifies the inventory of components used to create a software artifact such as a software application. It is comparable to an ingredient list on a food package: just as one can consult a label to avoid foods that may cause allergies, SBOMs can help organizations or individuals avoid consuming software that could harm them. The concept of the bill of materials is well established in traditional manufacturing as part of supply chain management. A manufacturer uses a bill of materials to track the parts it uses to manufacture a product. If defects are later found in a particular part, the affected products can be easily located using the BOM. A software bill of materials (SBOM) is a formal data... Stellen Sie sich vor, Sie könnten jede einzelne Komponente Ihrer Software wie eine Landkarte durchforsten – Risiken auf einen Blick erkennen, versteckte Abhängigkeiten aufspüren und Schwachstellen mühelos entlarven. Genau das macht eine Software-Stückliste (SBOM) möglich! Der Artikel beleuchtet, warum diese „Zutatenliste“ moderner Softwareprojekte heute unverzichtbar ist, vor allem da Open Source mittlerweile einen Löwenanteil in der Entwicklung einnimmt. Noch besser: In einem innovativen Forschungsprojekt mit der Hochschule Bonn-Rhein-Sieg, unterstützt vom Bundesministerium für Wirtschaft und Klimaschutz, wurde eine neuartige Visualisierung entwickelt. Mit dieser lassen sich Risiken nicht nur identifizieren, sondern auch simulieren, sodass selbst komplexe Lizenz- und Kompatibilitätsprobleme sichtbar werden. Tauchen Sie ein in die Welt der SBOM – eine spannende Entdeckungsreise durch die verborgenen Schichten Ihrer Software! Versetzen sie sich in die Lage eines IT-Sicherheitsverantwortlichen in einem Krankenhaus. Sie erhalten eine SBOM für ein neues Patientenmanagementsystem, das Sie implementieren sollen. Diese SBOM ist mehrere hundert Seiten lang und listet tausende von Softwarekomponenten, Bibliotheken und Abhängigkeiten auf. Wie gehen sie vor? Diese Frage ist schwieriger als gedacht, aber zuerst: woher kommt eine SBOM überhaupt? Erfahrene Entwickler schreiben ihren Code nun mal nicht von Grund auf neu, sondern nutzen vorhanden Software, kommerzielle Pakete und Open Source für die Entwicklung. Die Gründe für den Einsatz von Open Source liegen in der Verbesserung der Produktivität, der Verkürzung der Entwicklungszeit und in der Reduzierung der Entwicklungskosten. KI unterstützt immer mehr bei der Erstellung von Software. Angelernt durch Code aus Open-Source Repositories lässt sich qualitativ hochwertiger Code blitzschnell erzeugen. Wir sehen dies über alle Branchen hinweg (Automobil, Embedded, IoT, Healthcare, Finanzen,... ), und auch über die unterschiedlichsten Technologien (Linux, Windows, Embedded, Container, SaaS). Selbst eine einfache elektrische Zahnbürste oder ein Kochgerät wie der Thermomix beinhalten eine große Anzahl an Open Source. Mittlerweile hat Open Source einen Anteil in einem durchschnittlichen Projekt von 70%-90%. Wichtig ist hierbei die Beachtung einiger Risiken: Cybersicherheit, Beachtung geistigen Eigentums, Lizenzvorgaben (wie Veröffentlichung von Code oder Nennung von Urhebern), Exportrestriktionen, Vermeidung Inkompatibilitäten, Zukunftssicherheit. Für eine rechtssichere Verwendung müssen in einer Software alle Open Source Bestandteile bekannt sein und kontinuierlich auf Sicherheitslücken oder Änderungen geprüft werden. Eine Software-Stückliste (Software Bill of Materials, SBOM) spezifiziert das Inventar der Komponenten, die zur Erstellung eines Software-Artefakts wie einer Software-Anwendung verwendet werden. Sie ist vergleichbar mit einer Zutatenliste auf einer Lebensmittelverpackung: So wie man ein Etikett konsultieren kann, um Lebensmittel zu vermeiden, die Allergien auslösen können, können SBOMs Organisationen oder Einzelpersonen helfen, den Konsum von Software zu vermeiden, die ihnen schaden könnte. Das Konzept der Stückliste ist in der traditionellen Fertigung als Teil des Lieferkettenmanagements fest etabliert. Ein Hersteller verwendet eine Stückliste, um die Teile zu verfolgen, die er zur Herstellung eines Produkts verwendet. Werden später Mängel an einem bestimmten Teil festgestellt, lassen sich die betroffenen Produkte anhand der Stückliste leicht auffinden. Eine „Software-Stückliste“ (Software Bill of Materials, SBOM) ist ein formaler Datensatz, der die in Softwareprodukten enthaltenen kommerziellen und freien Softwarekomponenten enthält. Sie macht Abhängigkeiten von Komponenten Dritter transparent und hilft so Herstellern, Sicherheitsforschern und Anwendern bei der Überwachung von Schwachstellen und vielem mehr. Das Bundesamt... The LöhnMethod is your key to holistic success – professionally and privately. More than a calendar system, it offers a comprehensive solution for self-management, project management, information management and personal goal setting. Developed by Prof. Dr. Dr. h. c. mult. Johann Löhn over 40 years ago, tens of thousands of seminar participants have already achieved their goals using this method. The various building blocks of the LöhnMethod work together systematically, like departments in a company, to bring structure and efficiency into your life. Your ‘control centre’? The LöhnApp – the key to your success. Never forget anything. Find everything. Organise better. Achieve your goals. That is the aim of the LöhnMethod. In today's fast-paced world and when balancing work and private life, planning and structure are essential. Both are important factors for keeping track of your projects, achieving your goals and being successful in your professional and private life. What is the LöhnMethod? The LöhnMethod is much more than just a kind of ‘calendar system’. The LöhnMethod is a holistic self-management and problem-solving technique for all individuals who want to expand their professional and private success and strive for the further development of their personal profile. Prof. Dr. Johann Löhn developed the method more than 40 years ago. There are now more than 60,000 users who are convinced users of the LöhnMethod. The LöhnMethod has a total of six building blocks that form the basis for the entire method. They work together holistically in the following way: Objectives (Ziele) -> Doing (Tun) -> Storage (Ablage) -> Stimuli (Impulse) -> Material -> Routines (Routinen). A brief introduction to the LöhnMethod: The figure above shows the individual building blocks that are necessary for your planning. In simplified terms, the building blocks can be seen as departments, and the LöhnApp (or the conventional plan book) as the headquarter of a company, where the work of the departments is coordinated. The following is a brief explanation of the building blocks: Objectives (Ziele): Objectives must be set at certain times and periodically recalled. You must know your goals, be able to define them and sort them into short-/medium-/long-term goals. Doing (Tun): Activities, delegations and deadlines must be planned, coordinated and carried out. Filing (Ablage): Storage center; it contains notes, protocols and other documentation that can be accessed at any time. The filing is to be treated as a dynamic filing that is only accessed by the DOING department. Stimuli (Impulse): Suitable stimuli are used as ‘positive reinforcements’. Material Project sheet, daily activities, future activities, recurring activities, objectives, documentation, register for temporary documentation filing. Routines (Routinen): These are flowcharts and checklists in a predefined structure. This blog article focuses on the LöhnApp, an electronic tool for the Löhn method. If you want to learn more about the LöhnMethod, a basic training course in the LöhnMethod would be a good start. Prof. Dr. Löhn offers basic seminars in which the LöhnMethod with its six building blocks is explained in detail using case studies. The basic seminar is... The LöhnMethod is your key to holistic success – professionally and privately. More than a calendar system, it offers a comprehensive solution for self-management, project management, information management and personal goal setting. Developed by Prof. Dr. Dr. h. c. mult. Johann Löhn over 40 years ago, tens of thousands of seminar participants have already achieved their goals using this method. The various building blocks of the LöhnMethod work together systematically, like departments in a company, to bring structure and efficiency into your life. Your ‘control centre’? The LöhnApp – the key to your success. Never forget anything. Find everything. Organise better. Achieve your goals. That is the aim of the LöhnMethod. In today's fast-paced world and when balancing work and private life, planning and structure are essential. Both are important factors for keeping track of your projects, achieving your goals and being successful in your professional and private life. What is the LöhnMethod? The LöhnMethod is much more than just a kind of ‘calendar system’. The LöhnMethod is a holistic self-management and problem-solving technique for all individuals who want to expand their professional and private success and strive for the further development of their personal profile. Prof. Dr. Johann Löhn developed the method more than 40 years ago. There are now more than 60,000 users who are convinced users of the LöhnMethod. The LöhnMethod has a total of six building blocks that form the basis for the entire method. They work together holistically in the following way: Objectives (Ziele) -> Doing (Tun) -> Storage (Ablage) -> Stimuli (Impulse) -> Material -> Routines (Routinen). A brief introduction to the LöhnMethod: The figure above shows the individual building blocks that are necessary for your planning. In simplified terms, the building blocks can be seen as departments, and the LöhnApp (or the conventional plan book) as the headquarter of a company, where the work of the departments is coordinated. The following is a brief explanation of the building blocks: Objectives (Ziele): Objectives must be set at certain times and periodically recalled. You must know your goals, be able to define them and sort them into short-/medium-/long-term goals. Doing (Tun): Activities, delegations and deadlines must be planned, coordinated and carried out. Filing (Ablage): Storage center; it contains notes, protocols and other documentation that can be accessed at any time. The filing is to be treated as a dynamic filing that is only accessed by the DOING department. Stimuli (Impulse): Suitable stimuli are used as ‘positive reinforcements’. Material Project sheet, daily activities, future activities, recurring activities, objectives, documentation, register for temporary documentation filing. Routines (Routinen): These are flowcharts and checklists in a predefined structure. This blog article focuses on the LöhnApp, an electronic tool for the Löhn method. If you want to learn more about the LöhnMethod, a basic training course in the LöhnMethod would be a good start. Prof. Dr. Löhn offers basic seminars in which the LöhnMethod with its six building blocks is explained in detail using case studies. The basic seminar is... Die LöhnMethode ist Ihr Schlüssel zu ganzheitlichem Erfolg – beruflich und privat. Mehr als ein Kalendersystem, bietet sie eine umfassende Lösung für Selbstmanagement, Projektmanagement, Informationsmanagement und persönliche Zielfindung. Entwickelt von Prof. Dr. Dr. h. c. mult. Johann Löhn vor über 40 Jahren, haben bereits Zehntausende von Seminarteilnehmern mit dieser Methode ihre Ziele erreicht. Mit den verschiedenen Bausteinen der LöhnMethode, die systematisch zusammenwirken wie Abteilungen in einem Unternehmen, bringen Sie Struktur und Effizienz in Ihr Leben. Ihre "Zentrale"? Die LöhnApp – der Schlüssel zu Ihrem Erfolg. Nichts mehr vergessen. Alles wiederfinden. Besser organisieren. Ziele erreichen. Das ist der Anspruch der Löhn-Methode. In der heutigen, schnelllebigen Arbeitswelt und dem Ausbalancieren von Beruf und Privatem ist Planung und Struktur unverzichtbar. Beides sind wichtige Faktoren für den Überblick Ihrer Projekte, die Realisierung Ihrer Ziele und dem Erfolg in Ihrem Berufs- als auch Privatleben. Was ist die Löhn-Methode? Die Löhn-Methode ist weit mehr als eine Art „Kalendersystem“. Die Löhn-Methode ist ein ganzheitliches Selbstmanagement und eine Problemlösungstechnik für alle Personenkreise, die ihren beruflichen und privaten Erfolg ausbauen wollen und die Weiterentwicklung ihres persönlichen Profils anstreben. Prof. Dr. Johann Löhn hat die Methode vor mehr als 40 Jahren entwickelt. Mittlerweile gibt es über 60. 000 Anwender, die von der Löhn-Methode überzeugt sind. Die Löhn-Methode hat insgesamt 6 Bausteine, die die Basis für die gesamte Methode ist. Sie wirken ganzheitlich zusammen in Ziele -> Tun -> Ablage -> Impulse -> Material -> Routinen: Ein kleiner Einstieg in die Löhn-Methode: Die obige Abbildung zeigt die einzelnen Bausteine, die für Ihre Planung notwendig sind. Vereinfacht können die Bausteine als Abteilungen angesehen werden, und die LöhnApp (oder das herkömmliche Planbuch) als Zentrale einer Firma, wo die Arbeit der Abteilungen koordiniert wird. Folgend eine kurze Erläuterung der Bausteine: Ziele: Ziele müssen zu bestimmten Zeiten festgelegt und periodisch wiederkehrend ins Bewusstsein gerufen werden. Sie müssen Ihre Ziele kennen, definieren können und in kurz-/mittel-/langfristige Ziele sortieren. Tun: Aktivitäten, Delegationen und Termine müssen geplant, aufeinander abgestimmt und durchgeführt werden. Ablage Er beinhaltet Notizen, Protokolle und andere Dokumentationen, die jederzeit abgerufen werden können. Die Ablage ist als eine dynamische Ablage zu behandeln, die nur von der Abteilung TUN abgerufen wird. Impulse Als „positive Verstärker“ werden jeweils geeignete Impulse eingesetzt. Material Projektblatt, Tagesaktivitäten, zukünftige Aktivitäten, periodisch wiederkehrende Aktivitäten, Ziele, Dokumentation, Register für temporäre Doku-Ablagen. Routinen Dies sind Ablaufpläne und Checklisten in einer vorgegebenen Struktur. Dieser Blogartikel fokussiert sich auf die LöhnApp, ein elektronisches Hilfsmittel zur LöhnMethode. Falls Sie mehr über die Löhn-Methode erfahren wollen würde sich ein Grundkurs der Lohn-Methode anbieten. Prof. Dr. Löhn bietet Grundseminare an, in welchen die Löhn-Methode mit ihren sechs Bausteinen detailliert mit Fallbeispielen erklärt wird. Das Grundseminar wird mit dem Planbuch durchgeführt. Wenn Sie Interesse an einen Kurs mit Prof. Dr. Löhn haben können Sie sich hier für einen Kurs anmelden oder einen Kurs anfragen. Die Löhnapp Zur Unterstützung der Löhn-Methode hat Bitsea die LöhnApp entwickelt – ein modernes digitales Werkzeug, dass Ihnen dabei hilft, Zeit- und Projektmanagement effektiv umzusetzen. Die App vereint Funktionen, die den Alltag erleichtern und den Überblick über... Ms. Wittman is a lawyer in Munich and a partner at Bitsea. To enhance digital operational resilience, the European Commission has introduced the Digital Operational Resilience Act (Regulation (EU) 2022/2554 - "DORA") as part of its Digital Finance Package 2020. Currently, regulations on digital resilience are scattered across various sector-specific EU laws and guidelines (e. g. , MiF II, CRD, PSD2, Guidelines of the European Supervisory Authorities or “ESA” and other EU Member State banking regulations), creating regulatory gaps and uncertainties that DORA seeks to resolve. Set to take effect on January 17, 2025, DORA imposes new obligations on managing information communication technology (ICT) risks and incidents, which financial institutions across nearly all sectors must follow. Area of application DORA is a significant EU regulation impacting both financial entities and ICT service providers. Critical third-party ICT service providers (CTPPs) will face direct obligations, including compliance with new rules and oversight by financial supervisory authorities. Other ICT service providers, while not directly classified as CTPPs, will still be affected, particularly through their contractual relationships with financial entities, which may require updates to meet DORA's more extensive standards. This means that Financial Services, Tech, and Fintech sectors both within the EU and non-EU entities are impacted if they provide services in the EU that fall under DORA. This could include, for example, non-EU companies performing data analytics for financial institutions in the EU, such as: Credit institutions (banks). Investment firms managing assets or providing financial advice. Managers of alternative investment funds and UCITS management companies overseeing collective investment schemes. Insurance and reinsurance undertakings along with insurance intermediaries that manage risk and distribute policies. Payment institutions and electronic money institutions facilitating electronic payments and issuing digital currency. Account information service providers handling financial data. Crypto-asset service providers involved in cryptocurrency transactions. Trading venues such as stock exchanges. Central securities depositories and central counterparties that manage securities and clear trades. Trade repositories storing transaction data. Securitisation repositories managing data on securitised assets. Data reporting service providers ensuring compliance with reporting regulations. Institutions for occupational retirement provision managing pension schemes. Crowdfunding service providers facilitating peer-to-peer funding. Credit rating agencies that assess creditworthiness. Administrators of critical benchmarks overseeing the reliability of financial benchmarks. Key Requirements under DORA ICT Risk Management: Financial entities must establish comprehensive frameworks for identifying, managing, and reporting ICT risks to ensure resilience in the digital environment. This includes conducting vulnerability assessments, open-source analyses, and network security assessments to identify and mitigate potential risks. Article 7 of DORA requires these entities to document and review ICT-related business functions annually. In accordance with the NIS2 Directive and the Digital Operational Resilience Act (DORA), organizations should implement comprehensive risk management practices, which include maintaining a Software Bill of Materials (SBOM) to identify and address vulnerabilities in all software components, ensuring robust cybersecurity and operational resilience. Know your systems: According to RTS Article 5, ICT asset management procedures must detail the criteria for performing criticality assessments of information assets and ICT assets supporting business functions. This... Ms. Wittman is a lawyer in Munich and a partner at Bitsea. To enhance digital operational resilience, the European Commission has introduced the Digital Operational Resilience Act (Regulation (EU) 2022/2554 - "DORA") as part of its Digital Finance Package 2020. Currently, regulations on digital resilience are scattered across various sector-specific EU laws and guidelines (e. g. , MiF II, CRD, PSD2, Guidelines of the European Supervisory Authorities or “ESA” and other EU Member State banking regulations), creating regulatory gaps and uncertainties that DORA seeks to resolve. Set to take effect on January 17, 2025, DORA imposes new obligations on managing information communication technology (ICT) risks and incidents, which financial institutions across nearly all sectors must follow. Area of application DORA is a significant EU regulation impacting both financial entities and ICT service providers. Critical third-party ICT service providers (CTPPs) will face direct obligations, including compliance with new rules and oversight by financial supervisory authorities. Other ICT service providers, while not directly classified as CTPPs, will still be affected, particularly through their contractual relationships with financial entities, which may require updates to meet DORA's more extensive standards. This means that Financial Services, Tech, and Fintech sectors both within the EU and non-EU entities are impacted if they provide services in the EU that fall under DORA. This could include, for example, non-EU companies performing data analytics for financial institutions in the EU, such as: Credit institutions (banks). Investment firms managing assets or providing financial advice. Managers of alternative investment funds and UCITS management companies overseeing collective investment schemes. Insurance and reinsurance undertakings along with insurance intermediaries that manage risk and distribute policies. Payment institutions and electronic money institutions facilitating electronic payments and issuing digital currency. Account information service providers handling financial data. Crypto-asset service providers involved in cryptocurrency transactions. Trading venues such as stock exchanges. Central securities depositories and central counterparties that manage securities and clear trades. Trade repositories storing transaction data. Securitisation repositories managing data on securitised assets. Data reporting service providers ensuring compliance with reporting regulations. Institutions for occupational retirement provision managing pension schemes. Crowdfunding service providers facilitating peer-to-peer funding. Credit rating agencies that assess creditworthiness. Administrators of critical benchmarks overseeing the reliability of financial benchmarks. Key Requirements under DORA ICT Risk Management: Financial entities must establish comprehensive frameworks for identifying, managing, and reporting ICT risks to ensure resilience in the digital environment. This includes conducting vulnerability assessments, open-source analyses, and network security assessments to identify and mitigate potential risks. Article 7 of DORA requires these entities to document and review ICT-related business functions annually. In accordance with the NIS2 Directive and the Digital Operational Resilience Act (DORA), organizations should implement comprehensive risk management practices, which include maintaining a Software Bill of Materials (SBOM) to identify and address vulnerabilities in all software components, ensuring robust cybersecurity and operational resilience. Know your systems: According to RTS Article 5, ICT asset management procedures must detail the criteria for performing criticality assessments of information assets and ICT assets supporting business functions. This... Frau Wittman ist Anwältin in München und Partner von Bitsea. Um die digitale operative Widerstandsfähigkeit zu verbessern, hat die Europäische Kommission im Rahmen ihres Digital Finance Package 2020 den Digital Operational Resilience Act (Verordnung (EU) 2022/2554 - „DORA“) eingeführt. Derzeit sind die Vorschriften zur digitalen Widerstandsfähigkeit über verschiedene sektorspezifische EU- Gesetze und -Richtlinien verstreut (z. B. MiF II, CRD, PSD2, Leitlinien der Europäischen Aufsichtsbehörden oder „ESAs“ und andere Bankenvorschriften der EU-Mitgliedstaaten), was zu Regulierungslücken und Unsicherheiten führt, die DORA zu beseitigen versucht. Die DORA, die am 17. Januar 2025 in Kraft treten soll, erlegt Finanzinstituten in fast allen Sektoren neue Verpflichtungen für das Management von Risiken und Vorfällen im Bereich der Informations- und Kommunikationstechnologie (IKT) auf, die sie einhalten müssen. Anwendungsbereich DORA ist eine wichtige EU-Verordnung, die sowohl Finanzinstitute als auch IKT- Dienstleister betrifft. Kritische Drittanbieter von IKT-Dienstleistungen (Critical Third Party ICT Service Providers, CTPPs) werden direkten Verpflichtungen unterliegen, einschließlich der Einhaltung der neuen Vorschriften und der Aufsicht durch die Finanzaufsichtsbehörden. Andere IKT-Dienstleister werden zwar nicht direkt als CTPPs eingestuft, sind aber dennoch betroffen, insbesondere durch ihre vertraglichen Beziehungen mit Finanzunternehmen, die möglicherweise aktualisiert werden müssen, um den umfassenderen DORA-Standards zu entsprechen. Dies bedeutet, dass Finanzdienstleister, Technologieunternehmen und Fintechs sowohl innerhalb als auch außerhalb der EU betroffen sind, wenn sie Dienstleistungen in der EU erbringen, die unter DORA fallen. Dies könnte z. B. Nicht-EU-Unternehmen betreffen, die Datenanalysen für Finanzinstitute in der EU durchführen, wie z. B: Kreditinstituten (Banken). Wertpapierfirmen, die Vermögensverwaltung oder Finanzberatung anbieten. Verwalter alternativer Investmentfonds und OGAW-Verwaltungsgesellschaften, die Organismen für gemeinsame Anlagen beaufsichtigen. Versicherungs- und Rückversicherungsunternehmen sowie Versicherungsvermittler, die Risiken verwalten und Versicherungspolicen vertreiben. Zahlungsinstitute und E-Geld-Institute, die elektronische Zahlungen ermöglichen und digitale Währungen ausgeben. Kontoinformationsdienstleister, die Finanzdaten verarbeiten. Anbieter von Kryptoassets, die an Transaktionen mit Kryptowährungen beteiligt sind. Handelsplätze wie Aktienbörsen. Zentralverwahrer und zentrale Gegenparteien, die Wertpapiere verwalten und Transaktionen abwickeln. Transaktionsregister, die Transaktionsdaten speichern. Verbriefungsregister, die Daten über verbriefte Vermögenswerte verwalten. Datenmeldedienstleister, die die Einhaltung der Meldepflichten sicherstellen. Einrichtungen der betrieblichen Altersversorgung, die Pensionspläne verwalten. Crowdfunding-Dienstleister, die Peer-to-Peer-Finanzierungen ermöglichen. Rating-Agenturen, die die Kreditwürdigkeit bewerten. Verwalter kritischer Benchmarks, die die Zuverlässigkeit von Finanz-Benchmarks überwachen. Die wichtigsten Anforderungen im Rahmen von DORA IKT-Risikomanagement: Finanzinstitute müssen einen umfassenden Rahmen für die Identifizierung, das Management und die Berichterstattung von IKT-Risiken schaffen, um ihre Widerstandsfähigkeit im digitalen Umfeld zu gewährleisten. Dazu gehört die Durchführung von Schwachstellenanalysen, Open-Source-Analysen und Bewertungen der Netzwerksicherheit, um potenzielle Risiken zu identifizieren und zu mindern. Nach Artikel 7 der DORA sind diese Stellen verpflichtet, die IKT-bezogenen Geschäftsfunktionen jährlich zu dokumentieren und zu überprüfen. Im Einklang mit der NIS2-Richtlinie und dem Digital Operational Resilience Act (DORA) sollten Organisationen umfassende Risikomanagementpraktiken einführen, einschließlich der Pflege einer Software- Bestandsliste (Software Bill of Materials, SBOM), um Schwachstellen in allen Softwarekomponenten zu identifizieren und zu beheben und so eine robuste Cybersicherheit und betriebliche Widerstandsfähigkeit zu gewährleisten. Kennen Sie Ihre Systeme: Gemäß Artikel 5 der RTS müssen die Verfahren für das Management von IKT-Assets die Kriterien für die Durchführung von Bewertungen der Kritikalität von Informations- und IKT-Assets, die Geschäftsfunktionen unterstützen, detailliert beschreiben. Dies... As the implementation deadline for the revised Network and Information Systems Directive (NIS2) approaches, companies across the EU need to take action to ensure compliance with the directive. NIS2, which came into force on January 16, 2023, replaces the original NIS1 Directive and aims to harmonize and improve cybersecurity across member states. With its broader scope, risk-based approach and focus on supply chain security, NIS2 recognizes the growing cyber threats and the critical importance of protecting essential services and digital infrastructures. Companies have until October 17, 2024 to adapt national laws to NIS2. To prepare effectively, organizations need to understand its applicability, the specific requirements and potential impacts, including how the directive affects the use of open source software and technology. Scope of NIS2 NIS2 significantly expands the scope of its predecessor, NIS1, to cover a wider range of sectors and services that are critical to societal and economic stability. The Directive applies to key sectors such as energy, transport, banking, healthcare, digital infrastructure and public administration, as well as important sectors such as postal services, waste management, food production and digital service providers such as cloud computing, online marketplaces and search engines. Companies operating in these sectors must take stringent cybersecurity measures, conduct regular risk assessments and report significant incidents to national authorities. The expanded scope reflects the increasing interconnectedness of critical infrastructure and the need for robust cybersecurity practices across all sectors of society. However, companies with fewer than 50 employees or an annual turnover or balance sheet of less than 10 million euros are exempt from this regulation. There are exceptions to this exemption if these smaller companies are essential for critical infrastructure or operate in specific high-risk sectors. Application to non-EU companies: The NIS2 also applies to non-EU companies under certain conditions. If a non-EU company operates in a sector covered by NIS2 and provides services within the EU, it must comply with the Directive. This includes companies that provide services to EU citizens or within the EU market. Such non-EU companies must appoint a representative in the EU to ensure compliance with the NIS2 obligations. This representative acts as a liaison with EU regulators and is responsible for the company's compliance with the Directive. Impact on open source software and technology NIS2 places great emphasis on supply chain security and mandates strict cybersecurity standards for organizations that are classified as essential or important. The commercial components can usually be easily identified: Using the list of suppliers, the commercial components are quickly located. This is more difficult with the open source components. This has a direct impact on the use of open source software Increased security requirements: Organizations must ensure that open source technologies meet NIS2 cybersecurity standards. This includes regular updates, vulnerability assessments and timely patch management to minimize the risks associated with open source components. Supply chain security: The policy requires organizations to assess the security practices of their open source software suppliers. This includes evaluating the origin and maintenance of open source projects... As the implementation deadline for the revised Network and Information Systems Directive (NIS2) approaches, companies across the EU need to take action to ensure compliance with the directive. NIS2, which came into force on January 16, 2023, replaces the original NIS1 Directive and aims to harmonize and improve cybersecurity across member states. With its broader scope, risk-based approach and focus on supply chain security, NIS2 recognizes the growing cyber threats and the critical importance of protecting essential services and digital infrastructures. Companies have until October 17, 2024 to adapt national laws to NIS2. To prepare effectively, organizations need to understand its applicability, the specific requirements and potential impacts, including how the directive affects the use of open source software and technology. Scope of NIS2 NIS2 significantly expands the scope of its predecessor, NIS1, to cover a wider range of sectors and services that are critical to societal and economic stability. The Directive applies to key sectors such as energy, transport, banking, healthcare, digital infrastructure and public administration, as well as important sectors such as postal services, waste management, food production and digital service providers such as cloud computing, online marketplaces and search engines. Companies operating in these sectors must take stringent cybersecurity measures, conduct regular risk assessments and report significant incidents to national authorities. The expanded scope reflects the increasing interconnectedness of critical infrastructure and the need for robust cybersecurity practices across all sectors of society. However, companies with fewer than 50 employees or an annual turnover or balance sheet of less than 10 million euros are exempt from this regulation. There are exceptions to this exemption if these smaller companies are essential for critical infrastructure or operate in specific high-risk sectors. Application to non-EU companies: The NIS2 also applies to non-EU companies under certain conditions. If a non-EU company operates in a sector covered by NIS2 and provides services within the EU, it must comply with the Directive. This includes companies that provide services to EU citizens or within the EU market. Such non-EU companies must appoint a representative in the EU to ensure compliance with the NIS2 obligations. This representative acts as a liaison with EU regulators and is responsible for the company's compliance with the Directive. Impact on open source software and technology NIS2 places great emphasis on supply chain security and mandates strict cybersecurity standards for organizations that are classified as essential or important. The commercial components can usually be easily identified: Using the list of suppliers, the commercial components are quickly located. This is more difficult with the open source components. This has a direct impact on the use of open source software Increased security requirements: Organizations must ensure that open source technologies meet NIS2 cybersecurity standards. This includes regular updates, vulnerability assessments and timely patch management to minimize the risks associated with open source components. Supply chain security: The policy requires organizations to assess the security practices of their open source software suppliers. This includes evaluating the origin and maintenance of open source projects... Da die Umsetzungsfrist für die überarbeitete Richtlinie über Netz- und Informationssysteme (NIS2) näher rückt, müssen Unternehmen in der gesamten EU Maßnahmen ergreifen, um die Einhaltung der Richtlinie zu gewährleisten. Die NIS2, die am 16. Januar 2023 in Kraft trat, ersetzt die ursprüngliche NIS1-Richtlinie und zielt darauf ab, die Cybersicherheit in den Mitgliedstaaten zu harmonisieren und zu verbessern. Mit ihrem breiteren Anwendungsbereich, dem risikobasierten Ansatz und dem Fokus auf die Sicherheit der Lieferkette trägt die NIS2 den wachsenden Cyber-Bedrohungen und der entscheidenden Bedeutung des Schutzes wesentlicher Dienste und digitaler Infrastrukturen Rechnung. Unternehmen haben bis zum 17. Oktober 2024 Zeit, ihre nationalen Gesetze an die NIS2 anzupassen. Um sich effektiv vorzubereiten, müssen Unternehmen die Anwendbarkeit der Richtlinie, die spezifischen Anforderungen und die möglichen Auswirkungen verstehen, einschließlich der Frage, wie sich die Richtlinie auf die Verwendung von Open-Source-Software und -Technologie auswirkt. Umfang von NIS2 Die NIS2 erweitert den Anwendungsbereich ihrer Vorgängerin, der NIS1, erheblich und deckt eine größere Anzahl von Sektoren und Dienstleistungen ab, die für die gesellschaftliche und wirtschaftliche Stabilität von entscheidender Bedeutung sind. Die Richtlinie gilt für Schlüsselsektoren wie Energie, Verkehr, Banken, Gesundheitswesen, digitale Infrastruktur und öffentliche Verwaltung sowie für wichtige Sektoren wie Postdienste, Abfallwirtschaft, Lebensmittelproduktion und Anbieter digitaler Dienste wie Cloud Computing, Online-Marktplätze und Suchmaschinen. Unternehmen, die in diesen Sektoren tätig sind, müssen strenge Cybersicherheitsmaßnahmen ergreifen, regelmäßige Risikobewertungen durchführen und bedeutende Vorfälle den nationalen Behörden melden. Der erweiterte Geltungsbereich spiegelt die zunehmende Vernetzung kritischer Infrastrukturen und die Notwendigkeit robuster Cybersicherheitspraktiken in allen Bereichen der Gesellschaft wider. Unternehmen mit weniger als 50 Mitarbeitern oder einem Jahresumsatz oder einer Bilanzsumme von weniger als 10 Millionen Euro sind jedoch von dieser Verordnung ausgenommen. Es gibt Ausnahmen von dieser Ausnahme, wenn diese kleineren Unternehmen für kritische Infrastrukturen unerlässlich sind oder in bestimmten Hochrisikosektoren tätig sind. Anwendung auf Nicht-EU-Unternehmen: Die NIS2 gilt unter bestimmten Bedingungen auch für Nicht-EU-Unternehmen. Wenn ein Nicht-EU-Unternehmen in einem von der NIS2 abgedeckten Sektor tätig ist und Dienstleistungen innerhalb der EU erbringt, muss es die Richtlinie einhalten. Dies gilt auch für Unternehmen, die Dienstleistungen für EU-Bürger oder innerhalb des EU-Marktes erbringen. Solche Nicht-EU-Unternehmen müssen einen Vertreter in der EU benennen, um die Einhaltung der NIS2-Verpflichtungen sicherzustellen. Dieser Vertreter fungiert als Bindeglied zu den EU-Regulierungsbehörden und ist für die Einhaltung der Richtlinie durch das Unternehmen verantwortlich. Auswirkungen auf Open Source Software und Technologie NIS2 legt großen Wert auf die Sicherheit der Lieferkette und schreibt strenge Cybersicherheitsstandards für Organisationen vor, die als wesentlich oder wichtig eingestuft sind. Die kommerziellen Komponenten können in der Regel leicht identifiziert werden: Anhand der Lieferantenliste lassen sich die kommerziellen Komponenten schnell ausfindig machen. Bei den Open-Source-Komponenten ist dies schwieriger. Dies hat direkte Auswirkungen auf die Verwendung von Open-Source-Software: Erhöhte Sicherheitsanforderungen: Organisationen müssen sicherstellen, dass Open-Source-Technologien die NIS2-Cybersicherheitsstandards erfüllen. Dazu gehören regelmäßige Updates, Schwachstellenbewertungen und rechtzeitiges Patch-Management, um die mit Open-Source-Komponenten verbundenen Risiken zu minimieren. Sicherheit der Lieferkette: Die Richtlinie verlangt von Unternehmen, die Sicherheitspraktiken ihrer Open-Source-Software-Lieferanten zu bewerten. Dazu gehört die Bewertung der Herkunft und Wartung von Open-Source-Projekten, um sicherzustellen, dass sie keine Schwachstellen in kritische Systeme einbringen.... Today, we are shedding light on a topic that is still all too readily overlooked as the "little sister of programming". What hardly anyone cared about 20 years ago is to be placed under state control in the immediate future! As we now know, a major focus of Bitsea is checking for hidden risks in software. Many people typically first think about cybersecurity, or generally of outdated or poorly maintained components, as we have seen with Log4J. We have heard already that Bisquat2 is also used to analyze design pattern violations. However, hardly anyone will immediately think of open source and licenses. In the meantime, open source analysis has become the most important pillar of Bitsea. We support our customers in identifying and documenting every component of their software. This is used to create a "Software Bill of Materials" (SBOM). All components are listed in the SBOM with licenses, copyrights and vulnerabilities, allowing the software to be checked for risks. According to the new Cyber Resilience Act (CRA) or the Digital Operational Resilience Act (DORA), all companies that distribute their software commercially or, in the case of DORA, are working in the domain of the financial sector, are obliged to carry out a risk assessment. The basis for this is the SBOM. You can find more detailed information about both regulations here for DORA and here for CRA. The SBOM is an important tool for dealing with difficulties and vulnerabilities in software, i. e. documenting them and communicating them to others. Licenses are tricky. People who have worked in IT in critical infrastructure before know this. Many licenses have certain conditions if associated libraries are used commercially. This may mean that the source code with these licenses must be made publicly accessible. It is understandable that many large corporations and especially medium-sized companies do not want to make their software available to the general public. Just imagine this scenario with a large energy supplier... What's more, you want to be able to sit in your electrified car after the latest software update knowing that its software will remain a company secret for years to come - without outside interference. But now that even well-known manufacturers can no longer do without open source components in their software, as developing everything from scratch is expensive and time-consuming, companies such as Bitsea are being commissioned to find out what is hidden there. Analysis shows that an average software product contains around 80 percent open source code. Fact is, the image of an iceberg with its hidden size under water fits like a glove. Many open source projects supposedly show their licenses on Github, but if you do a deep license analysis, it quickly becomes clear that there is often more going on than meets the eye. In contrast to commercial software, where you (often) know exactly what it contains, open source software is often a difficult-to-comprehend hodgepodge. With Bisquat2, we have primarily developed a tool for analyzing the quality of source code. However,... Today, we are shedding light on a topic that is still all too readily overlooked as the "little sister of programming". What hardly anyone cared about 20 years ago is to be placed under state control in the immediate future! As we now know, a major focus of Bitsea is checking for hidden risks in software. Many people typically first think about cybersecurity, or generally of outdated or poorly maintained components, as we have seen with Log4J. We have heard already that Bisquat2 is also used to analyze design pattern violations. However, hardly anyone will immediately think of open source and licenses. In the meantime, open source analysis has become the most important pillar of Bitsea. We support our customers in identifying and documenting every component of their software. This is used to create a "Software Bill of Materials" (SBOM). All components are listed in the SBOM with licenses, copyrights and vulnerabilities, allowing the software to be checked for risks. According to the new Cyber Resilience Act (CRA) or the Digital Operational Resilience Act (DORA), all companies that distribute their software commercially or, in the case of DORA, are working in the domain of the financial sector, are obliged to carry out a risk assessment. The basis for this is the SBOM. You can find more detailed information about both regulations here for DORA and here for CRA. The SBOM is an important tool for dealing with difficulties and vulnerabilities in software, i. e. documenting them and communicating them to others. Licenses are tricky. People who have worked in IT in critical infrastructure before know this. Many licenses have certain conditions if associated libraries are used commercially. This may mean that the source code with these licenses must be made publicly accessible. It is understandable that many large corporations and especially medium-sized companies do not want to make their software available to the general public. Just imagine this scenario with a large energy supplier... What's more, you want to be able to sit in your electrified car after the latest software update knowing that its software will remain a company secret for years to come - without outside interference. But now that even well-known manufacturers can no longer do without open source components in their software, as developing everything from scratch is expensive and time-consuming, companies such as Bitsea are being commissioned to find out what is hidden there. Analysis shows that an average software product contains around 80 percent open source code. Fact is, the image of an iceberg with its hidden size under water fits like a glove. Many open source projects supposedly show their licenses on Github, but if you do a deep license analysis, it quickly becomes clear that there is often more going on than meets the eye. In contrast to commercial software, where you (often) know exactly what it contains, open source software is often a difficult-to-comprehend hodgepodge. With Bisquat2, we have primarily developed a tool for analyzing the quality of source code. However,... Heute beleuchten wir ein Thema, das nach wie vor als „kleine Schwester des Programmierens“ nur zu gerne unter den Tisch fallen gelassen wird. Was vor 20 Jahren noch kaum jemanden tangierte, soll in unmittelbarer Zukunft unter staatliche Kontrolle gesetzt werden! Wie wir mittlerweile wissen ist ein großer Kernpunkt der Bitsea die Prüfung auf versteckte Risiken in Software. Der erste Gedanke bei vielen ist die Analyse auf Cybersecurity, oder allgemein auf veraltete oder schlecht gewartete Komponenten, wie wir es bei Log4J erlebt haben. Nun haben wir auch schon gehört, dass durch Bisquat2 auch Entwurfsmusterverletzungen analysiert werden. Kaum einer jedoch wird bei diesem Stichpunkt gleich an Open Source und Lizenzen denken. Mittlerweile ist die Open-Source-Analyse das wichtigste Standbein der Bitsea. Unsere Kunden werden dabei unterstützt jegliche Bausteine ihrer Software zu dokumentieren. Damit wird eine „Software Bill of Materials“ (SBOM) erstellt. Alle Komponenten werden in der SBOM mit Lizenzen, Copyrights und Schwachstellen aufgelistet, womit die Software auf gegebene Risiken überprüft werden kann. Gemäß des neuen Cyber Resilience Act (CRA) oder des Digital Operational Resilience Act (DORA) sind alle Firmen, die ihre Software gewerblich vertreiben oder, im Falle DORA, mit dem Finanzsektor verbunden sind, dazu verpflichtet, eine Risikobewertung durchzuführen. Grundlage dafür ist die SBOM. Über beide Regulierungen finden Sie hier für DORA und hier für CRA genauere Informationen. Die SBOM ist ein wichtiges Werkzeug um mit Schwierigkeiten und Schwachstellen in Software umzugehen, also diese zu formulieren und mit anderen zu kommunizieren. Lizenzen sind trickreich. Leute, die zuvor schon im IT-Bereich von kritischer Infrastruktur gearbeitet haben, wissen das. Viele Lizenzen haben bestimmte Bedingungen, wenn ihre Bibliotheken kommerziell benutzt werden. Heißt, der Quellcode mit diesen Lizenzen muss laut Urheber wieder öffentlich zugänglich gemacht werden. Man kann verstehen, dass viele große Konzerne und vor allem mittelständische Betriebe ihre Software nicht der Allgemeinheit zur Verfügung stellen möchten. Man stelle sich dieses Szenario nur an Hand eines großes Energieversorgers vor... Zudem möchte man doch beruhigt in seinem elektrisierten Personenkraftwagen nach dem letzten Softwareupdate sitzen mit dem Wissen, dass dessen Software für die nächsten Jahre unangetastetes Firmengeheimnis bleibt - ohne Einwirkungen von außen. Da nun aber auch namentliche Hersteller auf Open-Source Komponenten in ihrer Software nicht mehr verzichten können, da selber machen teuer und zeitaufwendig ist, werden Firmen wie Bitsea beauftragt, herauszufinden, was sich dort versteckt. Allgemeine Schätzungen gehen davon aus, dass ein durchschnittliches Softwareprodukt circa 80 Prozent Open-Source Code enthält. Fakt ist, dass das Schaubild des Eisberges mit seiner versteckten Größe unter Wasser wie die Faust aufs Auge passt. Viele Open-source Projekte präsentieren vermeintlich ihre Lizenzen auf Github, wenn man jedoch eine tiefe Lizenzanalyse betreibt, wird schnell klar, dass oft mehr im Busch ist als gedacht. Im Gegensatz zu kommerzieller Software, bei der man genau weiß, was sie beinhaltet, ist Open-Source Software häufig ein schwierig zu überblickendes Sammelsurium. Mit Bisquat2 haben wir vorrangig ein Werkzeug zur Qualitätsanalyse des Source Codes entwickelt. Da Lizenzen uns in unserem Arbeitsalltag aber täglich beschäftigen, wollten wir hierzu Hilfsmittel einbauen, die uns unterstützen können. Zur Lizenzanalyse stehen uns bereits sehr gute Werkzeuge zur Verfügung... Open source is everywhere: Hardly any product today can do without digital components, from electric toothbrushes and baby monitors to smartwatches. Less obvious to many users is the security risk that such products pose for the end users. The new European Cyber Resilience Act (CRA) aims to ensure that consumers receive secure products. The regulation was announced in the EU Cybersecurity Strategy 2020 and complements other legislation in this area, in particular the NIS2 framework (second EU directive on network and information security). The CRA agreement was formally adopted by the European Parliament in March 2024. The CRA covers a wide range of requirements for "products with digital elements". These are all the software and hardware products as well as "remote" data processing solutions without which an intended function of the respective product with digital elements could not be performed. The requirements include, among other things: Cybersecurity is considered in the planning, design, development, production, delivery and maintenance phases. All cyber security risks are documented. Manufacturers must actively report exploited vulnerabilities and incidents. After the sale of a product, manufacturers must ensure that any vulnerabilities are effectively eliminated during the expected lifetime of the product or for a period of five years. Clear and understandable instructions for the use of products with digital elements. With the Cyber Resilience Act (CRA), the European Union has created regulation for the topics of cyber security, ICT risks and digital operational resilience. The central requirement is: All components of the software must be continuously checked for security vulnerabilities! Providers of commercial products must fulfill the obligations of the regulation. Open source developers have been excluded from the scope of the regulation. The above obligations only have to be fulfilled if open source is used commercially as part of a "product with digital elements" Example A company called "Amusing Micro Devices Ltd. " installs chips as components of its product. The company must be able to rely on these being designed securely and requires security updates from the supplier "Bizarre Broadband Ltd. " for a certain period of time to ensure security along the supply chain. According to the CRA, Bizarre Broadband Ltd. must prove that it has complied with EU-harmonized cyber security standards during development and production. This is documented via a so-called software bill of materials (SBOM). The supplier must also document any vulnerabilities of which it has become aware. Before placing the chip on the market, the supplier must carry out a conformity assessment procedure, only then may the CE marking be affixed. Amusing Micro Devices Ltd. must also do all this for its part of the supply chain. Both companies must also provide updates and fulfill reporting and information obligations after the chip and product have been placed on the market; Amusing Micro devices Ltd. must ensure that this is also guaranteed for all suppliers with suitable contracts. The SBOM: software bill of materials The commercial components of an SBOM are usually easy to determine: Using the list of suppliers, the... ## Webinare ## Events ## Jobs > Bitsea GmbH – Ihr Partner für nachhaltige, sichere und konforme Softwareentwicklung. Wir bieten maßgeschneiderte Audits, SBOM-Compliance, Lizenz- und Sicherheitsanalysen sowie technische Begleitung bei M&A-Due Diligence, Softwaremodernisierung und Open-Source-Governance.