CRA-Nachweise je Produkt pflegen: SBOM, bekannte Schwachstellen und technische Dokumentation

• Einstufung anhand der Anhänge III und IV, das daraus folgende Konformitätsbewertungsverfahren und Ihre Begründung.
• Version, Inverkehrbringen und Unterstützungszeitraum des angebotenen Produkts.
• Die SBOM dieser Version sowie bekannte Schwachstellen ihrer Komponenten und deren Bearbeitung.
• Dokumente: technische Dokumentation (Anhang VII), Cybersicherheitsrisikobewertung, Nutzerinformationen (Anhang II), EU-Konformitätserklärung (Anhang V) und eine Richtlinie zur koordinierten Offenlegung von Schwachstellen.
• Ein externer Meldeweg und ein Sicherheitskontakt.

Erzeugen Sie die SBOM dort, wo die Software gebaut wird, und übermitteln Sie sie automatisch an die Produktakte. Attesly nimmt CycloneDX- und SPDX-Dateien per Upload, als eingefügten Text oder über die API aus Ihrer CI-Pipeline entgegen.

• Das Original bleibt erhalten: Die eingereichte Datei wird mit einem nummerierten Importbeleg und einer Prüfsumme aufbewahrt. Spätere Importe ersetzen frühere Dateien nicht.
• Bekannte Schwachstellen werden abgeglichen: Komponenten mit einer Package-URL werden beim Import und bei manuellen erneuten Scans mit OSV.dev abgeglichen.
• Keine Quellcodeanalyse: Attesly liest die SBOMs Ihrer Werkzeuge. Es analysiert weder Quellcode noch Binärdateien.

Die SBOM ist ein Punkt der CRA-Checkliste; auch die übrigen Punkte brauchen ihre Nachweise.

Mit jeder neuen Version stellen sich dieselben Fragen: Entspricht die SBOM noch dem Produkt auf dem Markt? Welche Befunde behebt die Version? Wirkt sich die Änderung auf die Konformität aus? Ob eine wesentliche Änderung nach Artikel 3 Nummer 30 vorliegt, müssen Sie nachvollziehbar beurteilen können. Halten Sie die Antworten beim Produkt fest, statt sie nur in einer Versionsankündigung per E-Mail zu belassen.

• SBOM-Importe sind nummeriert. So bleibt der Komponentenbestand jeder Version auch nach dem nächsten Import nachvollziehbar.
• Befunde nennen die Version mit der Fehlerbehebung, zusammen mit Ihrer Bewertung.
• Dokumente sind versioniert und mit ihrer Sprache versehen. Frühere Versionen bleiben im Verlauf erhalten.
• Der Unterstützungszeitraum behält seine Begründung: Die bei der Festlegung berücksichtigten Informationen werden mit dem Zeitraum dokumentiert.

Fiktives Beispiel mit dem erfundenen Demohersteller Northwind Robotics und seinem NW-200 Edge Controller.

1. Nach dem Erstellen der NW-200-Firmware 2.3 wird die CycloneDX-Datei an die Produktakte übermittelt. Die Datei bleibt mit ihrem Importbeleg erhalten; die Komponentenliste wird aktualisiert.
2. Der Abgleich mit OSV.dev findet eine bekannte Schwachstelle in einer Komponente. Das Team dokumentiert seine Bewertung und die Version, in der die Behebung vorgesehen ist.
3. Firmware 2.4 enthält die Behebung. Das Team aktualisiert die Produktversion, kennzeichnet den Befund als in 2.4 behoben und begründet, warum das Update eine reguläre Sicherheitskorrektur und keine wesentliche Änderung darstellt.
4. Die technische Dokumentation erhält eine neue Version. Die vorherige bleibt im Verlauf erhalten.
5. Einführer und Händler sehen die öffentliche Vertrauensseite des Produkts ein, statt Dateien per E-Mail anzufordern.

Der Reifegrad in Attesly fasst anhand Ihrer eigenen Angaben zusammen, wie vollständig eine Produktakte ist. Er hilft, Lücken zu finden, und ersetzt keine Konformitätsbewertung.

Attesly unterstützt Dokumentation und Arbeitsabläufe. Es zertifiziert keine Produkte, ist keine notifizierte Stelle und erteilt keine Rechtsberatung. Informieren Sie sich über Tarife und Preise, vereinbaren Sie ein Gespräch oder lesen Sie, wie Sie eine Meldung nach Artikel 14 vorbereiten.