Cyber Resilience Act veröffentlicht
EU Cyber Resilience Act veröffentlicht
Heute wurde der EU Cyber Resilience Act (CRA) veröffentlicht. Damit sind seine Gültigkeit und der Zeitplan festgeschrieben, da sich aus dem Veröffentlichungsdatum die entsprechenden Daten für die Umsetzung ergeben: Beginn der tatsächlichen Gültigkeit – also der Zeitpunkt, ab dem jeder Software-Hersteller oder Vertreter eines solchen, der in der EU eine Software auf den Markt bringt, sich konform verhalten muss – ist der 11. Dezember 2027.
Genauer: Die Regelungen, insbesondere Art. 13 sowie Anhang I und II, gelten für alle Produkte mit digitalen Elementen, die ab diesem Termin in der EU auf den Markt kommen. Für Produkte, die vor diesem Termin auf den Markt kommen oder gebracht wurden, gelten die Anforderungen, sobald sie nach dem Termin wesentliche Änderungen erfahren, s. Art. 69 II CRA. Die Berichtserfordernisse aus Art. 14 sind jedoch für alle Produkte bereits ab dem 11. September 2026 zu bedienen, unabhängig vom Termin des Markteintritts (Art. 69 III CRA).
Von jetzt an zählt die Übergangsfrist, bis zu der sich Software-Anbieter mit den neuen Anforderungen auseinandersetzen, bzw. diese umsetzen müssen. Die Umsetzung ist stellenweise nicht trivial und erfordert einiges an organisationalem Wandel, bspw. die Aufnahme ggf. noch nicht vorhandener Risikoanalysen und -bewertungen in den Release-Prozess, die Deklaration von Unterstützungszeiträumen oder den Aufbau geeigneter Schwachstellen-Management-Prozesse.
– soweit nicht anders dargestellt, beziehen sich im Folgenden alle Verweise auf den Text des CRA –
Sie wollen klären, welche Anforderungen der CRA an Ihre Organisation stellt?
Sprechen Sie unverbindlich mit unserem Experten!
Für wen ist der Cyber Resilience Act von Bedeutung?
Der CRA betrifft grundsätzlich alle, die ein Produkt mit digitalen Elementen, also einer Software-Unterstützung bereitstellen. Allerdings schränkt er seine Gültigkeit auch gegenüber bereits anderweitig regulierten Gruppen ein. So werden Produkte, die sich nur im Automotive-Bereich, im Marine- oder Aviation-Umfeld bewegen oder der Medical Device Regulation unterliegen, ausgenommen. Es ist jedoch anzunehmen, dass eine Dual-Use-Möglichkeit, also eine Nutzbarkeit in anderen, nicht regulierten Bereichen, die Gültigkeit auch wieder herstellen wird.
Rollen der Akteure
Weiterhin ist die Rolle des Handelnden relevant für die Beurteilung der Gültigkeit. Konzeptuell versucht die Regulierung den Nutznießer der wirtschaftlichen Transaktion in die Verantwortung zu nehmen, der innerhalb der EU das Geschäft abbildet. Was bedeutet das?
Im einfachen Fall stellt ein europäischer Anbieter ein Produkt mit digitalen Elemente her, welches in den regulierten Bereich (s.o.) fällt. Somit steht der Anbieter direkt in der Pflicht, die CRA-Anforderungen für sein Produkt zu erfüllen, beispielsweise ein Hersteller für Stereoanlagen oder Musikboxen, die Musik-Streaming unterstützen oder eine Werkzeugmaschine, welche per Fernüberwachung gewartete werden kann.
Sitzt der Hersteller des Produktes außerhalb der EU, gehen diese Pflichten an seinen Stellvertreter über, den „Inverkehrbringer“. Dies kann ein Händler, ein Partner oder ein Implementierungspartner sein, eben der nächste wirtschaftliche Nutznießer. Interessant ist, dass dieser auch für die Einhaltung der Pflichten bei der Herstellung bürgen muss. Das bringt eine komplett neues Haftungsregime für bspw. Lizenzverkäufer amerikanischer Software mit sich!
Open Source
Sobald Open Source ins Spiel kommt, wird die Kette etwas unklarer. Aber der CRA kennt und berücksichtigt das Open Source Konzept. Der eigentliche Urheber einer Open Source Lösung bleibt von den Anforderungen verschont. Nimmt ein Akteur jedoch eine Open Source Lösung und nutzt sie wirtschaftlich, sei es durch Support-Verträge, treffen ihn die Regelungen analog zu denen eines Anbieters. Beispielsweise ist eine SUSE im Sinne des CRA verantwortlich für die von ihr bereitgestellte Distribution.
Ausnahmen gibt es nur für sogenannte Stewards. Diese haben weniger scharfe Anforderungen zu erfüllen. Diese Rolle wurde für die sogenannten Foundations (Eclipse, Cloud native, etc.) geschaffen, da sie zwar eine Form des Inverkehrbringers darstellen, jedoch keine mit einem herkömmlichen Software-Anbieter vergleichbaren, wirtschaftlichen Vorteile aus der Bereitstellung und Verbreitung ziehen. Um als Steward zu gelten, ist eine Anerkennung erforderlich.
Was sind die wesentlichen Neuerungen?
Der leitende Gedanke hinter dem CRA ist die Verbesserung der Sicherheitslage für die Konsumenten von Software. Da heutzutage fast alles von und mit Software gesteuert wird, bzw. ausgestattet ist, sind Cyber-Angriffe fast überall möglich. Jede Komponente, die durch eine Internetverbindung, ein WLan oder auch eine Near-Field-Kommunikation wie ZigBee oder Bluetooth zählt zur potentiellen Angriffsoberfläche – neu-deutsch: Attack Surface- und ist daher mit Bedacht zu nutzen, bzw. bereitzustellen.
Der Anbieter einer Software im europäischen Markt hat daher zukünftig folgende Anforderungen zu erfüllen:
- Bereitstellen eines Software Bill of Materials (SBOM), s. Anhang I
- Regelmäßiges Durchführen einer Risikobetrachtung der Sicherheitsrisiken sowie deren Aufnahme in die Dokumentation, s Art. 13, III und IV
- Erstellen einer Konformitätserklärung, s. Art. 13 XII, bzw. Art. 28 I sowie Anhang IV
- Bereitstellen einer CE-Kennzeichnung, s. Art. 12 XII, bzw. Art. 30 I
- Definition einer zu erwartenden Lebensdauer des Produktes und die Bereitstellung kostenloser Sicherheits-Updates innerhalb dieses Zeitraumes, s. Art. 13 VIII ff
- Einfordern umfangreicher Meldepflichten (gem. Art. 14)
- Mitteilung aktiv ausgenutzter Schwachstellen innerhalb von 24h an die European Network and Information Security Agency (ENISA) über eine noch zu schaffende Meldeplattform (vermutlich analog der bereits im Telekom-Umfeld bestehenden Lösung)
- Ergänzend hierzu eine Präzisierung der Einschätzung sowie der Maßnahmen innerhalb von 72h
- Information der Nutzer des Produktes sowie die von diesen zu ergreifenden Maßnahmen, s. Art. 14 VIII.
Wie kann TrustSource helfen?
- Einheitliche Plattform für Software Analyse, Compliance & Release-Management
- Integriertes Risiko-Management
- Automatisiertes Schwachstellen-Management
- Durchgängige, CRA-konforme Dokumentation
- CSAF-konforme Meldungen
- Einheitlicher Schwachstellen-Meldeprozess
- Umsetzungsunterstützung
Was sind die Auswirkungen der Nicht-Einhaltung?
Jedes Gesetz ist zunächst nur die Deklaration einer Verhaltensvorgabe. Was ist jedoch die Folge, wenn man sich nicht der Vorgabe gemäß verhält? Welche Risiken drohen den Anbietern?
Mit Veröffentlichung werden die Mitgliedsstaaten beauftragt, eine Stelle zu benennen, die für die Aufsicht in dem jeweiligen Land verantwortlich ist. In Deutschland wird dies nach aller Voraussicht das BSI sein. Dieses wiederum kann dann im Verdachtsfall entsprechende Prüfungen durchführen, bzw. beauftragen. Werden dabei Missstände festgestellt, führt dies in der Regel zur Aufforderung der Nachbesserung, kann jedoch auch entsprechend sanktioniert werden. Der CRA sieht folgende, mögliche Sanktionen vor:
- Bei Verstoß gegen grundlegende Sicherheitsanforderungen (Anhang I) bis zu 15 Mil. EUR oder, bei Unternehmen, bis zu 2,5% des weltweiten Jahresumsatzes im vorangegangenen Geschäftsjahr. (s. Art. 64 II)
- Bei Verstoß gegen Pflichten, die der CRA auferlegt, bis zu 10 Mil. EUR oder – für Unternehmen – bis zu 2% des ww Umsatzes (Vorjahr) (s. Art. 64 III)
- Für unrichtige, unvollständige oder irreführende Meldungen gegenüber den Behörden, bis zu 5 Mil. EUR, bzw. 1% des Jahresumsatzes für Unternehmen (s. Art. 64 IV)
Darüber hinaus besteht die Möglichkeit, bei nachhaltiger Nicht-Konformität die Verbreitung des Produktes einzuschränken, bzw. es vom Markt zu nehmen, s. bspw. Art. 58 II.
Sie sind sich nicht sicher, was das für Ihre Organisation bedeutet?
Sprechen Sie unverbindlich mit einem unserer Experten!
TrustSource zeigt OpenSSF Scorcards an
Hier klicken, um das Bild zu vergrößern
In unserer Komponentendatenbank, in der wir Meta- und Clearing-Informationen zu Komponenten sammeln, haben wir die Open Source Security Foundation (OpenSSF) Scorecard ergänzt. Diese erlaubt es, den Sicherheitsstatus von Open-Source-Projekten zu erkennen. Der Score, der vom OpenSSF-Projekt der Linux Foundation im Jahr 2020 eingeführt wurde und derzeit regelmäßig für etwa 1 Million Open-Source-Projekte auf Github ausgewertet wird, ist ein aggregierter Wert, der die vom Open-Source-Projekt getroffenen Sicherheitsmaßnahmen widerspiegelt. Er kann als Anhaltspunkt dafür verwendet werden, wie sehr Sie den Sicherheitsbemühungen eines bestimmten Projekts vertrauen können, ohne es weiter zu evaluieren.
Was sagt die Scorecard aus?
Der Wert oder die Punktzahl der Scorecard ist das Ergebnis von sechzehn Prüfungen, die die Best Practise der sicheren Softwareentwicklung widerspiegeln. Sie umfassen die Bereiche Entwicklung, Tests, Wartung und Schwachstellen, aber auch Code- und Build-Management. Auf der Grundlage eines umfassenden Satzes Best Practises durchsuchen die Tests das Code-Repository nach Belegen dafür, dass die Praktiken vom Projekt aktiv angewendet werden.
Derzeit sind 18 Tests verfügbar, von denen 16 über die API zugänglich sind. Eine ausführliche Dokumentation der Tests ist hier zu finden. Jeder Test wird mit einer Punktzahl zwischen 0 und 10 bewertet, wobei 10 die bestmögliche Punktzahl darstellt. Die Testergebnis und einem Risiko gewichtet ergeben zusammen eine Gesamtpunktzahl.
In einigen Fällen, kann es sein, dass Tests aufgrund von Projekt-Setups nicht anwendbar sind. Beispielsweise könnte es sein, dass ein Projekt keine Pakete über Github bereitstellt. Dadurch wird der Test auf Pakete nicht anwendbar sein, da die aktuelle Implementierung noch keinen Mechanismus zur Überprüfung anderer Paketmanager bietet.
Wenn Sie jedoch eine Entscheidung treffen wollen, ob Sie eine bestimmte Komponente einsetzen wollen oder nicht, hilft Ihnen die Durchführung eines Scorecard-Tests – oder ein Blick auf die Komponente in unserer Datenbank – dabei, einen Eindruck zu bekommen, welchen Aufwand Sie in die Absicherung der Komponente investieren müssen. Je höher die Punktzahl, desto mehr Vertrauen können Sie in die Komponente setzen.
Was sagt die Scorecard NICHT aus?
Bitte verstehen Sie eine hohe Punktzahl aber nicht als Garantie für eine sichere Komponente! Auch eine niedrige Punktzahl deutet nicht unmittelbar auf eine schwache oder fehlerhafte Komponente hin! Es wäre schlicht falsch, anzunehmen, dass eine niedrige Punktzahl ein Hinweis auf eine anfällige Komponente ist! Derzeit sind die Tests noch nicht umfänglich und prüfen nur auf ein Set ihnen bekannter Sicherheitswerkzeuge. Auch werden nur die im Repository sichtbaren Informationen geprüft. Bleiben diese auf einem Entwickler- oder CI-System und finden nicht den Weg in das Git-Repository, tauchen sie auch nicht im Testergebnis auf!
Die Punktzahl gibt an, welche Schritte das Projekt unternimmt, um sicherzustellen, dass der von ihm bereitgestellte Code bewährten Praktiken folgt und daher mit hoher Wahrscheinlichkeit frei von Fehlern und Schwachstellen ist. Aber es ist eben keine Garantie! Wenn alles gut läuft, alle Tests 10 zurückgeben, kann es immer noch vorkommen, dass eine Schwachstelle in einer vorgelagerten Komponente auftritt, die für das Projekt selbst nicht einfach oder gar nicht zu beheben bzw. zu umgehen ist.
Verwenden Sie die Punktzahl als Indikator. Aber machen Sie die Entscheidung, ob Sie eine Komponente verwenden wollen oder nicht, primär von ihrer Funktionalität abhängig und nicht von der Punktzahl. Sie werden – vor allem in diesen frühen Tagen, in denen der Score noch nicht weit verbreitet ist – noch viele gute Projekte mit geringen Scores finden.
Was kommt als Nächstes?
Wir empfehlen, dies Scorecards als Indikator für eine Eignungsbeurteilung hinzuzuziehen, da sie einen Hinweis darauf geben, wie stark Sie sich auf Ihre vorgelagerten Komponenten verlassen können. Zudem lässt sich über eine historische Betrachtung der Veränderung des Scores eine Tendenz erkennen, die eine interesante Aussage über das Projekt und seine Einstellung zu den Best Practises erkennen lässt. Wir werden Anfang kommenden Jahres genügend Werte gesammelt haben, um diese „Tendenz“ auswerten zu können.
Da TrustSource alle KomponentenIhrer Lösung kennt, wird es nun auch möglich sein, mehr aus den einzelnen Scores in Bezug auf das Projekt zu machen. Ein einfacher Durchschnittswert wäre sinnlos. Aufgrund der Menge der Komponenten wäre ein Durchschnittswert irgendwo bei einer bedeutungslosen 5 zu erwarten. Aber wir experimentieren derzeit mit Quantilen oder Top-10- und Low-10-Durchschnitten sowie dem Verhältnis von Nicht-bewerteten Komponenten zu bewerteten Komponenten.
Außerdem werden wir einen Service anbieten, mit dem man seine eigenen Komponenten oder nicht geprüfte Open Source Repositories überprüfen kann, indem man – wie beim DeepScan einfach eine URL angibt oder auch die Scorecard auf nicht-Github-Projekte überträgt. Wenn wir erfolgreich sind, werden wir unsere Entwicklungen in OpenSSF einbringen.
Sie wollen mehr über SBOMs oder OpenSSF Coding Best Practises erfahren? Kontaktieren Sie uns!
TrustSource @ IIOT SBOM in Antwerpes
Wir sehen uns am 10. November auf der IIOT SBOM !
Vielen Dank an @LSEC – Leaders In Security – für die Einladung, über #SBOM #DevSecOps und die kommenden Herausforderungen aus Perspektive der IT Security zu sprechen. @Jan wird in seinem Vortrag „Getting the SBOM right, and then?“ auf die Herausforderungen rund um die Erstellung von SBOMs eingehen und wie man diese auf der Automatisierungsseite angehen kann. Des Weiteren wird er sich mit der Lebenszyklus-Perspektive befassen, d.h. was nach der Erstellung von SBOMs kommt. Dabei wird er auch über die Arbeit der #LinuxFoundation #OpenChain Automation-Arbeitsgruppe berichten und zu einer neuen Art von SBOM-Benutzergruppe einladen, die Best Practices für die Definition von SBOMs umreißt.
Wir freuen uns auf tolle Gespräche und darauf, noch mehr über die Herausforderungen zu erfahren, mit denen Sie bei der Erstellung von SBOMs in der IIOT-Welt konfrontiert sind.
Bis übermorgen in Antwerpen!
Nachlese
(22.11.22) Vielen Dank noch einmal für die vielen interessanten Vorträge und animierenden Gespräche! Es hat Spaß gemacht, mit den Teilnehmern und Referenten sich auszutauschen und Ideen und Anforderungen zu diskutieren. Die Vorträge sind auf der Seite von IIOT SBOM als Videos verfügbar. Jan’s Vortrag haben wir hier verlinkt.
Der erste Teil beschäftigt sich mit SBOMs, was gehört rein, wie kann man sie ablegen, Formate, etc.,Der zweite teil beschäftigt sich mit den Themen Automatisierung und was lässt sich mit den generierten Informationen anfangen. Die Zweiteilung des Vortrages ergab sich aus der Agenda, welche auch die Koordination mit Vortragenden aus anderen Zeitzonen erforderte.
TrustSource und SCANOSS wollen künftig enger zusammenarbeiten
TrustSource und SCANOSS wollen zukünftig enger zusammenarbeiten
Im Vorfeld des Open Source Summit Europe 2022 haben SCANOSS – Anbieter der vermutlich größten Datenbank für Open Source Informationen – und TrustSource – die Automationslösung für Prozesse im Bereich Open Chain Security und Compliance – vereinbart, künftig enger zusammenzuarbeiten.
Im Zuge der Arbeiten im Kontext der OpenChain Tooling Workgroup wurde das Open Source Compliance Capability Modell entwickelt. Dieses Modell beschreibt die unterschiedlichen Kompetenzen und Fähigkeiten, die für eine umfängliche Abwicklung von Open Source Compliance erforderlich sind. „SCANOSS hat das >Snippet-Scanning< mit der ersten Open-Source-Lösung standardisiert, die von Open-Source-Communities wie OSS Review Toolkit aufgenommen wurde.“, berichtet Jan Thielscher, der die Arbeitsgruppe derzeit koordiniert. „Das ist genau der Bereich, aus dem wir (TrustSource) uns bisher herausgehalten haben. Zusammen mit der unglaublichen Informationsbasis, die SCANOSS für die Identifikation von Snippets aufgebaut hat, können wir durch eine engere Zusammenarbeit den letzten weißen Flecken auf unserer Capability Map schließen.“
Derzeit ist es bereits möglich, Scan-Ergebnisse, die mit Hilfe der SCANOSS-Workbench oder dem SCANOSS-CLI erzeugt werden, in TrustSource zu importieren und somit in den von TrustSource verwalteten Compliance-Prozess zu überführen. SCANOSS-Nutzer erhalten somit die Möglichkeit, Ergebnisse nicht nur in Form eines Audit-Ergebnisses vorliegen zu haben, sondern in den regulären Kontext eines unternehmensweiten Portfolio-Managements einzubinden. Die TrustSource-Benutzer profitieren zunächst von der Möglichkeit, die zusätzlichen Erkenntnisse von SCANOSS zu nutzen. In Kürze werden auch die erweiterten Erkenntnisse wie Export-Controls, etc., die SCANOSS bereitstellen kann, in TrustSource zu verwalten bzw. deren Einhaltung zu monitoren sein.
„Das macht die Sache dann rund.“, meint Jan Thielscher. „Natürlich stellen unzureichende Metadaten, nicht deklarierte Lizenzen oder unklare Commiter-Situationen auch weiterhin Herausforderungen für die OSPOs dar, aber der Großteil der Aufgaben lässt sich durch die hohe Integration und die vielen Berichte, die aufgrund der hohen Integration einfach möglich sind, schon weitgehend automatisiert abbilden. Und da liegt der immense Effizienzgewinn!“
Treffen Sie uns auf dem Open Source Summit in Dublin @ B.19
Lernen Sie mehr über das Open Chain Tooling Workgroup Capability Modell, TrustSource und wie viel Prozess-Automation auch in dem Bereich Open Source Compliance bereits möglich ist.
Openchain - Umfrage zu Open Source
Openchain - Umfrage zur Opensource Nutzung
Die Openchain Workgroup der Linux Foundation, die in den letzten Jahren vor allem den Standard ISO 5230 – Open Source Compliance geprägt hat, hat ein Umfrage über den Einsatz und Umgang von Open Source in Unternehmen erarbeitet. Als internationale Erhebung soll sie helfen die Arbeit der Organisation zu fokussieren und den teilnehmenden Unternehmen eine Möglichkeit geben, sich selbst in Bezug auf Open Source zu reflektieren. Die Ergebnisse der Umfrage werden unter Creative Commons zero (CC-0) lizenzesiert und lassen sich somit frei verwenden.
Als Unterstützer der Openchain Initiative rufen wir unsere Kunden und Partner auf, die Umfrage zu unterstützen und damit den Pool an Informationen anzureichern. Die Umfrage erfordert ca. 10 Minuten Zeit und kann unter diesem Link erreicht werden.
Free Known Vulnerability Search - TrustSource Vulnerability Lake bietet vielfältige Unterstützung bei der Suche nach Bekannten Schwachstellen
TrustSource Vulnerability Lake Search
Sowohl Software-Entwickler als auch Security-Researcher kennen die Herausforderung, Bekannte Schwachstelle Open Source Komponenten zuzuordnen. Die CPE (Common Platform Enumeration) codes stellen zwar ein standardisiertes Schema für die Bezeichnung von Schwachstellen zur Verfügung, jedoch wurde die Nomenklatur ursprünglich für Hersteller-Software entwickelt und passt nur leidlich auf den Kontext von Open Source Komponenten, denen oft eine eindeutige „Organisation“ fehlt.
Das führt zu Problemen in der Auffindbarkeit und bei der korrekten Zuordnung. Einmal gewinnt der Projektname, z.Bsp. „kubernetes:kubernetes“ ein anderes Mal ist es die organisierende Foundation, bspw.: „apache:http„. Manchmal gehen die Projekte auch im Laufe der Zeit durch unterschiedliche Organisationen, wie das weitverbreitete Spring-Framework. Dann finden sich Informationen unter „pivotal_software:spring_framework“ und ab 2019 unter „vmware:spring_framework„, was aufgrund der Nebenläufigkeit von Versionen noch auf Jahre viel Irritationen mit sich bringen wird.
Und, um noch eines drauf zu setzen, dann gibt es ja noch die Herausforderungen mit den Projektnamen selbst: „npmjs“ oder lieber „npm_js“ oder doch „npmjs:npm„?
Die TrustSource Vulnerability Lake-Search dreht den Spieß um: Sie stellt Suchoptionen zur Verfügung, um in den vorhandenen CPEs zu suchen und somit die zu beachtenden Keys zu finden.
Mit Hilfe von TrustSource Vulnerability Alert kann ich meine kritischen Komponenten im Schlaf überwachen!!
TrustSource Vulnerability Alert
Mit Hilfe des TrustSource Vulnerability Alerts bleiben Sie stets auf dem Laufenden. Die mit der oben beschriebenen Suche gefundenen Bezeichner lassen sich abonnieren. Registrierte Benutzer – die Registrierung ist kostenfrei und einfach bspw. per GitHub-Account möglich – können die Begriffe auf eine Liste setzen. Diese Listen werden alle paar Stunden mit den Updates aus aktualisierten Quellen, wie der NVD abgeglichen. Finden sich Updates oder neue Einträge erhält der Abonnent eine eMail mit einem Link auf die neuen Informationen.
TrustSource Kunden erhalten diese Funktionalität automatisch auf alle in den Software Bill of Materials (SBOMs) ihrer Lösung(en) angewendet. Die TrustSource-Scanner ermitteln die SBOMs während Ihre Anwendung gebaut wird und kennen daher alle Abhängigkeiten, auch die transitiven. Zudem können Sie in TrustSource selbst auch Infrastrukturkomponenten dem Projekt hinzufügen, und somit die gefährdeten Libraries, die nicht im eigenen Quellcode vorkommen, identifizieren.
Die Kommunikation der Vulnerability Alerts kann entweder per Mail an die entsprechenden Projektteilnehmer oder in die systemeigene Inbox erfolgen. Letzteres ist insbesondere erforderlich, um Fehlschläge aufgrund von Abwesenheiten oder anderen Filtern asynchroner Kommunikation zu entgehen.
Um die einfache Integration in umstehende Systeme zu ermöglichen, stehen alle diese Funktionen auch via API zur Verfügung. Die Nutzung des API ist jedoch kostenpflichtig und nicht Bestandteil der freien Pläne.
Um eine schnelle Einordnung der Kritikalität zu ermöglichen, zeigt TrustSource stets neben der Beschreibung der CVE bzw., deren Zuordnung zu den OS-Komponenten auch die Informationen zu dem Angriffsvektor sowie die Kritikalität in CVSS-Werten (Common Vulnerability Scoring System, Details s. hier ).
TrustSource Life Cycle Alarm
Aus diesen Fähigkeiten ergibt sich noch eine weitere Leistung, die TrustSource seinen Kunden zu Verfügung stellt: Den Life-Cycle-Alarm.
Die Verpflichtung eines Software-Herstellers seine Kunden über Bekannte Schwachstellen zu informieren, endet nicht mit der Auslieferung der Software, sie beginnt zumeist erst dann. Das gilt für Gerätehersteller noch mehr. Je weniger Möglichkeit besteht, den Kunden für zeitnahe Updates zu , motivieren, desto komplexer wird die Situation.
Tauchen im Laufe der Zeit _nach_ der Veröffentlichung der Software, Bekannte Schwachstellen in den verwendeten Komponenten auf, ist es im Sinne ordnungsgemäßer Informationsversorgung an dem Hersteller, seine Kunden zu informieren. Diese Verpflichtung findet bereits im Bereich der Medizinprodukte (MDR) Anwendung und wird sich sicherlich auch auf weitere Bereiche ausdehnen.
TrustSource erlaubt es, SBOMs, die zu einem Release freigegeben wurden, festzuhalten und somit einer fortlaufenden Kontrolle zu unterziehen. JederPatch oder Release-Stand, der auf einem Kundenprodukt erzeugt wurde, lässt sich nachhalten und entsprechend alarmieren.
Es klingt interessant aber Sie sind sich nicht sicher, ob es Ihrem Bedarf entspricht?
Oder wollen Sie sich lieber erst einmal selbst durch einen kostenfreien Test Einblick verschaffen?
Neue Features in TrustSource v2.5
Wir haben wieder einiges in die Feature-Kiste gelegt!
Freuen Sie sich mit uns und probieren Sie es am bensten gleich aus!
New Features:
- Neue Rolle Portfolio Manager und Portfolio Overview eingeführt:
Auf Kundenwunsch wurde eine Rolle Portfoli-Manager eingeführt, der stets den Blick auf die Gesamtheit der Themen haben kann. Hierzu wurde eine explizite Portfolio-Übersicht gebaut, die mit es ermöglicht innerhalb von nur drei Klicks aus der Portfolio-Overview kritische Komponenten zu identifizieren. - Neue Suchmöglichkeiten für Vulnerability Lake:
Es ist nun auch möglich nach CPEs oder Komponentenbezeichnern zu suchen und bei Eignung diese zu abonnieren. Somit lassen sich unterschiedliche Bezeichnungen oder Quellen einfach verfolgen. - Möglichkeit, Vulnerability-Beschreibungen direkt anzeigen zu lassen (Get Details):
Erlaubt es, die Beschreibung einer Vulnerability direkt anzuzeigen, um nicht den Screen wechseln zu müssen. Somit lassen sich Entscheidungen direkt im Kontext treffen.
- Vulnerabilities für Infrastruktur-Komponenten:
Mit Hilfe des Vulnerability-Lakes ist es nun auch besser möglich, die Bekannten Schwachstellen für die Infrastruktur-Komponenten besser aufzulösen und in der Anwendung detailliert darzustellen. - Automatisches Beheben der Legal Todos mit Hilfe des Notice File
Es gibt nun die Möglichkeit den Notice-File auch ohne Approval als vorab-Version zu erzeugen. Alle Obligations, die mit dem Notice-File erschlagen werden, setzt TrustSource nun automatisch auf „erledigt“ und verweist auf den Notice File. Das erspart sehr viel Pflegearbeit. - Interoperabilität: Suppport für alle CycloneDX SBOMs
Wir haben CycloneDX aufgenommen. Sowohl in den Core für manuelle Uploads von Modulen oder 3rd-Party-Software, als auch via API. Somit ist nun neben SPDX auch CycloneDX vollumfänglich über beide Kanäle möglich, was die Integration mit fast allen Scannern ermöglicht. In dem Zuge wurde auch ein Import API für SPDX (v2.2+) erzeugt. - Darstellung der Abhängigkeiten mit Hilfe eines SunBurst-Diagrams für mehr Übersichtlichkeit.
- CMake-Integration: Mit Hilfe dieses neuen Scanners lassen sich auch C-Make gebaute Projekte problemlos scannen und and die Plattform für die weitere Analyse übertragen.
Improvements:
- Attack-Vector-Repräsentation wurde entzerrt und leserlicher gestaltet
- Seit der Hinzunahme zusätzlicher Quellen war der Deep-Link zur NVD unpraktikabel. wir haben daher eine interne Repräsentation bereitgestellt. Diese wird sich in den kommenden Wochen auch noch ein paar Mal leicht verändern.
- Ladezeiten größerer Scans optimiert und verkürzt
- Vulnerability Alert Mails enthalten nun passende Deep-Links, damit die neuen Informationen direkt angesprungen werden können.
- Interne Optimierungen im Bereich des Vulnerability-Assignments.
- Änderungen in den Rahmenbedingungen wirken nicht mehr nur noch auf die Analyse und die Ergebnisse, auch der Notice File wird nun angepasst.
- Neues Intro für neue Benutzer.
- Verbesserungen für die Verwaltung von Komponenten (Component Manager)
- ts-node-client updated, um mit neueren Node-Versionen arbeiten zu können.
- Tagging Capabilities verbessert, insbesondere für Komponenten, Projekte und Module, um ein das Filtern zu vereinfachen.
- Verbesserte Sortierungsmöglichkeiten in der CompDB
- Chronik der Legal Settings hinzugefügt. Somit lassen sich auch ältere Zustände wieder zurückholen.
Freies Open Source Compliance Basics Training bereitgestellt
Seit Jahren tauchen im Kontext Open Source immer wieder die gleichen Fragen auf:
- Darf ich open source in geschäftlich genutzten Anwendungen verwenden?
- Welche Folgen hat die Verwendung von open source?
- Ist die GPL eine „giftige“ Lizenz?
- Was bedeuten für uns in Europa die amerikanischen Lizenzen?
Die Irritation trifft vor allem Entwickler, die sich in vorderster Front mit der Nutzung bzw. dem Einsatz von Open Source konfrontiert sehen. Nun sind Informatiker selten auch gleichzeitig Juristen und auch wenn sich Jura und Informatik in vielen Aspekten ähneln, so ist es doch nicht trivial, eine Lizenz ohne juristische Vorkenntnisse zu interpretieren.
Um diese Lücke überwinden zu helfen, haben wir ein grundlegendes Open Source Compliance Basics – Training zur Verfügung gestellt. Das Training führt in die Thematik ein, schildert kurz die Hintergründe und gibt Einblick in die wesentlich Gestaltungsaspekte von Lizenzen. In dem frei verfügbaren, self-paced Online-Trainingskurs wurden mehr als 4 Stunden Videomaterial, Präsentationen und Quizzes verarbeitet.
Der Teilnehmer erhält in dem Kurs einen Überblick über:
- Die Motivation und Hintergründe von Open Source Compliance,
- Die Herausforderungen, die Open Source Compliance zu mehr als dem einfachen Erstellen einer Liste machen,
- Lösungskonzepte, die helfen, eine Standard-konforme Open Source Compliance in einem Unternehmen zu verankern,
Die in englischer Sprache gehaltenen Vorträge sind in kleine, kurze Häppchen eingeteilt, sodass sie sich auch zwischendurch gut verarbeiten lassen.
Den direkten Zugang finden Sie hier auf der Seite unter Trainings.
Alles neu macht der Mai - TrustSource 2.0 kommt!
TrustSource 2.0 kommt mit neuem Look & Feel
Wir freuen uns, am Freitag, den 7.5.2021 die Version 2.0 in Betrieb zu nehmen. Da es über die letzten Updates etwas voll geworden ist, in der Liste der Features, haben wir den Navigationsbereich in Gruppen zusammengefasst. Diese sind nach den Phasen der Wertschöpfung organisiert, was hilft, sich schneller zu orientieren: Analysen im Bereich Inbound, Schwachstellen-Informationen und Projektmanagement-Aufgaben im Internal-Bereich oder Notice-File-Generierung im Outbound-Bereich.
Mehr Fokus bei der Arbeit
Weiterhin helfen wir unseren Kunden sich zu fokussieren. Gerade in größeren Organisationen mit umfangreichem Projektportfolio wird es wichtig, sich schnell und gezielt zu bewegen. Mit Hilfe der „Pin to Dashboard„-Funktion lassen sich Projekte direkt auf das Dashboard heften, sodass ein direkter Einstieg mit wenigen Klicks möglich wird. Ebenfalls in dieses Segment fällt die Möglichkeit, Projekte und Module mit Tags zu versehen. Tabellenansichten lassen sich mit Hilfe von Tags filtern, was schnell für mehr Sichtbarkeit sorgt. In späteren Ausbaustufen, werden die Tags auch in den Berichten und anderen Übersichten nutzbar sein.
Neues Import-API für CycloneDX SBOMs
Auch haben wir den Entwicklungen am Markt Rechnung getragen und den sich immer schneller etablierenden Standard CycloneDX aufgenommen. Es ist nun möglich, CycloneDX-Dokumente zu importieren. Somit sind auch alle CycloneDX-kompatiblen Scanner für die Arbeit mit TrustSource nutzbar. Die Dokumente müssen nur an das neue API /import/scan/cyclonedx übertragen werden.
Vulnerability Lake
Um unseren Benutzern die tägliche Arbeit zu vereinfachen, haben wir eine vollständige Replik der NVD-Daten aufgenommen. Alle zwei Stunden aktualisiert, können Sie nun die CVEs durchsuchen, nach Organisation, Produkt und Versionen (CPEs) recherchieren – aus TrustSource heraus oder über unsere API. Es ist unser Ziel, den Datenpool sukzessive zu vergrößern und dieses wertvolle Wissen auf Knopfdruck verfügbar zu machen. Derzeit arbeiten wir an einem Matching der CPEs auf pURLs, um die Identifikation von CVEs zu betroffenen Komponenten zu optimieren.
Verbesserungen
Darüber hinaus werden wir auch eine Reihe von Verbesserungen einführen
- Es wird nun möglich sein, zwischen dem Scan – den Rohdaten, die von einem beliebigen Scanner oder dem CycloneDX SBOM-Upload in TrustSource eingebracht werden – und der analysierten Abhängigkeitsansicht hin und her zu springen. Dies wird helfen, die Abhängigkeitshierarchie besser zu verstehen.
- Wir haben die Geschwindigkeit beim Laden des Analyse-Auswahlelementes verbessert. Täglich gescannte, aber lange Zeit geänderte Projekte neigten dazu, eine erhebliche starke Latenz zu erzeugen.
- DeepLinks aus der DeepScan-Ergebnisansicht in das Repository werden nun auch für spezifische branches unterstützt
- Die Light-Integration via eMail zu on-premises Jira-Systemen wird nun unterstützt. Die Option lässt sich projektspezifisch konfigurieren.
Fehlerbehebungen
Die folgenden Fixes werden zur Verfügung gestellt:
- Das Löschen von Lizenz-Alias in einer nicht sequentiellen Reihenfolge erzeugt keine leeren Aliase mehr
- Verhinderung eines internen Fehlers, wenn Modul- oder Komponentennamen bei Scans ungewöhnlich lang waren
- Die Datumsdarstellung in Safari funktionierte manchmal nicht korrekt
- Einige Anpassungen an den Komponenten-Crawlern und der Speicherung der Ergebnisse reduzieren die Menge der fehlerhaften Daten
Sie wollen mehr über SBOMs oder OpenSSF Coding Best Practises erfahren? Kontaktieren Sie uns!
Open Source Compliance im Kontext von CI/CD
In den letzte Jahren hat sich Continuous Integration und Deployment (CI/CD)- die ständige Integration von Änderungen, deren automatisiertes Testen und Ausbringen – als Best Practise etabliert. Die gesteigerte Qualität und die Produktivitätsverbesserungen, die sich hierdurch erzielen lassen, sind enorm und sollten daher von jedem Entwicklungsteam angestrebt werden. Gleichzeitig wächst jedoch auch die Herausforderung im Bereich Open Source eine solide Dokumentation und rechtliche Compliance herzustellen.
Durch das kontinuierlich neue Bauen von Lösungen kann sich auch kontinuierlich die Zusammensetzung der Lösung ändern. Da der Anteil an Dritt-Software (OpenSource-Komponenten) stetig zunimmt, wird mit dem neuen Bau auch die Wahrscheinlichkeit größer, dass sich die Zusammensetzung der automatisch hinzugezogenen Dritt-Software ändert. Das Upgrade der Komponente X von Version 1.5.7 auf 1.5.8 kann bereits neue Lizenzverpflichtungen auslösen.
Leider kann eine strikte Versionskontrolle alleine diese Problematik nicht auflösen, da immer wieder das Schließen von identifizierten Schwachstellen (Vulnerabilities) und anderen Fehlerbehebungen Versions-Upgrades in allen Ebenen erforderlich machen wird. Daher stellt sich die Frage, wie sich die Compliance (1) auch in diesem dynamischen Kontext sicherstellen lässt.
Branching-Konzept als Lösungsbaustein
Um diese Frage zu beantworten, ist es erforderlich, sich zunächst mit dem Prozedere des Entwicklungsteams vertraut zu machen. Leider lässt sich immer wieder feststellen, dass es keine generell einheitlich definierte Vorgehensweise gibt. Dabei ist die Branching-Strategie des Entwicklungsteams essentiell für den richtigen Ansatzpunkt einer Open Source Compliance.
Mit Git-Flow (2), Github-Flow (3) und Gitlab-Flow (4) stehen drei anerkannte, aber zunächst unterschiedlich anmutende Handlungsanweisungen zur Verfügung. Die Varianten unterscheiden sich jedoch weniger, als es auf den ersten Blick erscheint.
Im Git-Flow bleibt der Master unantastbar die Version, die sich auch im Produktivsystem findet. Hierdurch verspricht man sich, ein einfaches Rollback auf eine ältere Version, sollte das Deployment 2 PROD einer neuen Version fehlschlagen. Ausgehend von dem Develop-Branch werden einzelne Feature-Branches erzeugt und jeweils wieder auf den Develop-Branch zusammengeführt, um das parallele Entwickeln durch mehrere „Feature“-Teams an dem Develop-Objekt zuzulassen. Atlassian ergänzt in der Beschreibung zudem noch den Umgang mit Hot-Fixes und Releases.
Wesentlich einfacher erscheint der Github-Flow. Einen Teil der Vereinfachung erfährt das Modell jedoch aufgrund der Verlagerung des Masters auf die Rolle des (im Git-Flow) Develop-Branch. Das vereinfacht das Verständnis, da die meisten Werkzeuge #master als Default-Branch verwenden und somit der Entwickler im Default auf dem richtigen Branch arbeitet. Unbeantwortet bleiben im GitHub-Flow jedoch die Fragen nach dem Merge in umfangreicheren Projekten, die sich aus mehreren Modulen zusammensetzen. Damit ist man dann schnell wieder bei einem Release-Branch, wie ihn der Git-Flow kennt.
GitLab hat dies in seiner Flow-Darstellung noch einmal aufgegriffen und explizite Umgebungs-Branches eingeführt, bspw. PROD, PRE-PROD, die solche umgebungspezifischen Assemblies abbilden. Die Bedeutung solcher Varianten sollte jedoch dank dynamischer, bzw umgebungsspezifischer Container-Konfiguration sukzessive abnehmen.
Inwiefern sich das als geeignet erweist, mag nur der jeweilige Projektkontext bewerten. Aus unserer Erfahrung ist ein Failback im Kontext eines Zero-Downtime-Deployments eher weniger ein Thema, das irgendwelche Repositories betrifft. Man würde für ein Rollback sicher auch nicht auf das Soruce-Repository zurückgreifen wollen, sondern lieber die bereits gefertigten Artefakte aus einem Binary-Repository holen. Daher empfehlen wir den Verzicht auf den Git-Flow-„Master“ zugunsten eines „DEV-Masters“ im Sinne des GitHub-Flows.
Die Entscheidung, ob man noch unterschiedliche „Release“-Versionen aufhebt, ergibt sich dann aus der Deployment-Philosophie bzw. dem Geschäftsszenario. Im SaaS-Kontext ist die Dringlichkeit für Release-Branches eher geringer. Wird Software hingegen verteilt, bspw. auf Geräte, die nicht beliebig für Updates zur Verfügung stehen, ist das ein essentieller Schritt für die nachhaltige Wartung. Auf jeden Fall empfehlen wir unabhängig vom gewählten Flow eindringlich die Nutzung von Binary-Repositories, um das ewige Neubauen der Artefakte nach erfolgreichem Test und Dokumentation weitgehend zu unterbinden.
Unabhängig vom gewählten Flow emfpehlen wir stets die Nutzung von Binary-Repositories
Umgang mit Multi-Modul-Projekten
Unbeleuchtet bei all diesen Themen bleibt die Frage nach den „Multi-Modul-Projekten“. Zwar werden diese durch Modularisierungstrends wie Micro-Service-Architekturen mit der Zeit weniger werden, jedoch lässt sich nicht alles endlos teilen und nicht alle Commons lassen sich stets auflösen.
Die Frage nach der richtigen Granularität des Repository-Schnitts wird fall-, bzw. projektspezifische zu beantworten sein. Daher wird es um so wichtiger, auf Seiten der Composistion Analysis ein System zu haben, das hier vollkommene Flexibilität bietet. Wir haben TrustSource daher so konzipiert, dass es beliebige Granularitäten unterstützt. Dazu kennt es die Konstrukte „Projekt“, „Modul“ und „Komponente“.
Die Idee des Projektes ist es, ein Entwicklungsvorhaben zu klammern. Es bildet den Container, in den alles projektspezifische reinkommt: Rahmenbedingungen, allgemeine Berechtigungen, alle zugehörigen Artefakte, Infrastrukturelemente etc.
Das TrustSource-Projekt ist nur eine Klammer für eine Menge an Delivery-Artefakten.
Die Module bilden entweder einzelne Deployment- oder Build-Artefakte. Dabei kann ein Modul entweder das Ergebnis eines Builds oder eine eigenständige Drittkomponente sein. Als Build versteht sich in dem Kontext alles, was im Zuge der Eigenentwicklung gebaut wird. Das kann wiederum ein einzelnes Artefakt oder ein Multi-Komponenten Projekt (bspw. EAR) sein.
Die einzelnen Komponenten, die — auch transitiv — zum Bauen eines Moduls angezogen werden, löst der der Scanner während des Bauens auf und überträgt die Stückliste an TrustSource (s. nebenstehende Grafik). Dabei kann das /SCAN-API, welches die Information entgegennimmt, auch Informationen zu „Branch“ und „Tag“ aufnehmen. Dies hilft später, die Eingaben wiederzufinden.
Zudem unterstützt TrustSource die Verwaltung von Drittprodukten. Das können Komponenten sein, die nicht beim Bauen auftauchen, wie ein MySQL- oder JBoss-Server, eine Bild-Datei (Ressourcen) oder eine gekaufte Library. Diese lassen sich über die Mechanismen Infrastruktur Management (für Open Source-Komponenten) oder COTS-Management (für kommerzielle 3rd Party) verwalten und organisieren und einem Projekt manuell als eigenständige Module hinzufügen.
Das Modul ist also die Klammer der Informationen für ein Build-Artefakt. Es enthält den Teil der rechtlichen Informationen, die modulspezifisch sind, die Architekturposition, Zugriffsrechte etc.. Soweit Letztere nicht für das jeweilige Modul explizit geändert werden, sind sie bereits durch das übergeordnete Projekt gesetzt.
Beispiel
Nachstehendes Bild zeigt die Struktur eines Workplace-Servers. Dieser besteht aus einem Frontend- und einem Backend-Modul, die beide in einem Projekt-Repository abgelegt sind. Der Workplace-Server benötigt zudem einen Tomcat 8.5 und einen MySQL-Server als Ausführungsinfrastruktur. Diese beiden Module sind als Infrastruktur-Module hinzugefügt. Sie werden nicht gebaut, sind aber Bestandteil der Anwendung und entsprechend in die Compliance-Betrachtung einzubeziehen.
Dabei ist es egal, ob die Frontend und Backend-Module aus dem gleichen Repository kommen oder aus unterschiedlichen. Das Ergebnis in TrustSource sieht unverändert aus.
Interessant wird jetzt die Release-Strategie. Liegt die Release-Version auf Anwendungs-Ebene (äußeres Kästchen), wird es also immer nur eine Version der Anwendung geben, sind alle Module jeweils nachzuziehen, um mit der Release-Version Schritt zu halten, oder es muss eine Kombination unterschiedlicher Sub-Release zu dem Gesamt-Release geben. Zum Beispiel würde sich die Version 2.0.0 der Anwendung aus den Versionen Tomcat 8.5, MySQL 5.1 und Frontend 2.0.5 sowie Backend 1.5.16 konstituieren.
Für diesen Fall gibt es seitens des Repository nur dann eine Entsprechung, wenn ein GitLab-artiges Repository für die Produktionsumgebung gepflegt wird, in welches die unterschiedlichen Stände eingebracht werden. Es wird in diesem Kontext erforderlich – wie in allen Multi-Komponenten-on-premises-Projekten ohnehin – einen Release-Brach aufzusetzen, um das Zusammenspiel von Frontend und Backend zu testen, bevor sie ausgebracht werden.
Einbindung der Compliance in den CI/CD-Flow
Als Scan wird das Ergebnis des Scanners bezeichnet, welcher lokal oder auf dem Build-Server ausgeführt wird. Er erzeugt die Struktur inklusive Abhängigkeiten und überträgt diesen „Scan“ mit Hilfe des gleichnamigen API an TrustSource. Dort übernimmt der Scan-Processor den Scan, gleicht die gefundenen Informationen mit der internen Komponentendatenbank ab und bindet den Input an das zugehörige Modul.
Hierdurch entsteht der Kontext. Das Projekt und das Modul halten Rahmenbedingungen, welche für das Projekt bzw. Modul gelten sollen. Das betrifft die Kommerzialisierung sowie andere relevante Aspekte, wie bspw. den Schutzbedarf von IP. Diese Information zusammen mit den Komponenten und Lizenz-Informationen werden dann an den Legal-Check-Service übergeben, welcher die sich aus den Rahmenbedingungen und den Lizenzen ergebenden Verpflichtungen (Obligations) ableitet.
In der Detail-Ansicht findet der Benutzer letztendlich die Summe aller dieser Schritte, das Analyse-Ergebnis. Um eine engere Bindung zwischen dem Quellcode und der Management-Welt herzustellen, stellt TrustSource die Felder „branch“ und „tag“ in dem API /SCAN bereit. Somit lassen sich mehrere Zustände eines Moduls problemlos auseinanderhalten.
Wichtig für das Verständnis der weiteren Schritte ist es, zu verstehen, dass der SCAN die Struktur des Quellcodes wiedergibt. Dieser ist zunächst unbewertet. Erst das in der Detail-Ansicht dargestellte Analyse-Ergebnis ist eine Interpretation vor dem Hintergrund der zum Analysezeitpunkt gültigen Rahmenbedingungen! Daher gilt:
- Jeder Upload erzeugt einen neuen SCAN
- Ein SCAN wird in der Regel einem MODUL zugeordnet, wodurch er seine Rahmeninformationen erhält
- Jedes MODUL gehört zu genau einem PROJEKT – bis auf das systemeigene Sammelmodul „Unassigned“, hier findet sich alles, was nicht automatisch zugeordnet werden kann
- Jeder SCAN erzeugt mindestens ein ANALYSEERGEBNIS (automatisiert)
- Ein MODUL kann beliebig viele ANALYSEERGEBNISSE haben
- Ein SCAN kann beliebig oft an TrustSource übertragen werden, die Zuordnung zu einem MODUL lässt sich bei der Übertragung festlegen
Scans zuordnen
Aus dieser Menge an Fakten lassen sich beliebige Szenarien zusammenstellen. So kann jeder Entwickler an das Ziel-Modul seine Scans schicken und diese mit Hilfe von Branches und Tags differenzieren. Um eine direkte Zuordnung zwischen Code und Analyse-Information herzustellen, könnte man die Commit-ID als Tag anlegen.
Will ein Entwickler seine Experimente nicht in dem allgemeinen und für das gesamte Projekt ersichtlichen Modul einbringen, kann er eine eigene Projekt/Modul-Konstellation anlegen und die rechtlichen Einstellungen aus dem ursprünglichen Projekt kopieren. Somit kann er in seiner Version herumprobieren, ohne den allgemeinen Stack zu belasten.
Andererseits kann es auch sinnvoll sein, sämtliche Branches in dem Modul zu halten, um einen guten Überblick über die Veränderungen zu erhalten. Mit Hilfe des Branch-Selektors im User-Interface lässt sich jede Version direkt auswählen und einsehen.
Approvals einordnen
Doch was ist nun ein Approval? Das Approval ist ein administrativer Schritt, der es dem Projektleiter und den Entwicklern ermöglichen soll, sich von der Domänen-fremden Aufgabe der rechtlichen Begutachtung ihrer Leistung frei zu zeichnen. Hierzu bereitet TrustSource alle Unterlagen für eine Prüfung auf und stellt diese einem rechtlich gebildeten – im TrustSource-Sprech, dem Compliance Manager – zur Verfügung. Dieser muss dann nur noch die Vollständigkeit bzw. Eignung prüfen, wobei ihn TrustSource auch unterstützt, und kann dann eine Freigabe erteilen.
Die Approvals finden idealerweise nicht nach jedem Scan statt, sondern nur vor Merge-Schritten. Dabei sind der Umfang und die Häufigkeit organisationsspezifisch festzulegen. Im Regelfall erfolgt ein Merge in einem vergleichbaren Kontext wie in nachstehender Abbildung gezeigt. Dabei ist es unerheblich, ob es sich um einen Pull-request oder einen richtigen Merge handelt. Ist der zu integrierende Inhalt von einem für seinen Umfang vollständigen Notice-File versehen, kann dieser Inhalt auch in den zusammengeführten Baum übernommen werden und hält die Gesamtdokumentation somit vollständig.
Die obige Darstellung ist um die Scans und die Generierung der Notice Files erweitert. Wir empfehlen, die Notice-Files als Bestandteil einer Definition of Done aufzunehmen. TrustSource verfügt über einen Notice-File Generator. Dieser sammelt sämtliche vorhandenen Informationen und zeigt, welche Informationen noch fehlen, um den Notice-File zu vervollständigen.
Wir empfehlen, vor jedem Merge einen Notice-File zu erzeugen. So ist jeweils nur das Delta zum bisherigen Bestand zu ergänzen
Alle ergänzten Daten stehen ab dem Zeitpunkt der Ergänzung allen Projekten zur Verfügung. Somit sind allgemeine Informationen nur einmal zu erfassen. Das reduziert die Clearing-Aufwände erheblich
Die tatsächliche Gestaltung der Abläufe wird in jedem Unternehmen, vermutlich sogar in jedem Projekt, etwas anders verlaufen. Eine allgemeingültige Darstellung zu verordnen, ist daher weder sinnvoll, noch empfehlenswert. Die Wahrscheinlichkeit, dass sie mehr schadet als nutzt, ist einfach zu hoch. Auch kann es sinnvoll sein, das Vorgehen im Zeitablauf anzupassen. Wird ein Modul nur noch angepasst, ist ein weniger differenziertes Vorgehen empfehlenswert, als wenn mehrere Teams gleichzeitig an den Elementen arbeiten. Wird jedoch vor jedem Merge ein Notice-File erzeugt, ist jeweils nur as Delta zum bereits bestehenden Notice-File zu ergänzen und sowohl der Arbeitsaufwand als auch die spätere Herausforderung für die Compliance-Prüfung halten sich in Grenzen.
Literaturhinweise:
(1) Welche Herausforderungen die Compliance beantworten muss, findet sich in dem Artikel „Aktuelle Herausforderungen der Open Source Compliance“.
(2) Git-Flow: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
(3) GitHub-Flow: https://guides.github.com/introduction/flow/
(4) GitLab-Flow: https://about.gitlab.com/2014/09/29/gitlab-flow/
(5) s. https://github.com/dotnet/corefx/