Ressourcen
Beispiel-Prozessbeschreibungen
Ausgearbeitete Beispiele der Dokumente, die ein CRA-Audit sehen will — so geschrieben, wie ein kleiner Hersteller sie tatsächlich schreiben würde.
Wie die Dokumente zusammenhängen
Der Satz ist geschichtet: Die Prozesse oben legen fest, was geschehen muss, die Richtlinien darunter fixieren die Regeln einmal für das ganze Unternehmen, und alles weiter unten ist ein Nachweis, der beim Befolgen entsteht. Die Pfeile sind die Querverweise der Dokumente selbst — wählen Sie ein Dokument, um zu sehen, worauf es aufbaut und was auf ihm aufbaut.
SDL-PROC-001
CRA-Aligned Software Development Process
Fünf Phasen und vier Gates: jede CRA-Pflicht abgebildet auf eine Aktivität, eine verantwortliche Rolle und den Nachweis, den sie erzeugt — samt Traceability-Tabelle, die zeigt, was noch nicht abgedeckt ist.
Verweist auf (12)
Wird referenziert von (9)
Konventionen für Dokument-IDs
Jedes Dokument trägt eine ID, und sie zitieren einander darüber — das macht den Satz als Ganzes lesbar. Das Schema ist ACMEs eigene Dokumentenlenkung; der CRA schreibt den Inhalt der technischen Dokumentation vor, nicht deren Nummerierung.
DOMAIN–TYPE–NUMBERSDL-STD-022 · REG-REC-020 · SEC-RA-S300Domäne — welches Managementsystem zuständig ist
- SDL
- Secure Development Lifecycle — wie Produkte entstehen
- PSM
- Product Security Management — Schwachstellenbehandlung und Betreuung nach dem Release
- SEC
- Sicherheitsartefakte für genau ein Produkt
- ENG
- Engineering-Nachweise und Entscheidungen aus der Entwicklung
- REG
- Regulatorische Festlegungen — Einstufung, Konformitätsroute, Bevollmächtigter
- QM
- Qualitätsmanagement — Organisation und Rollen
- CON
- Verträge und Einkauf
- LEG
- Recht
Typ — um welche Art Dokument es sich handelt
- POL
- Policy — verbindliche Regeln, keine Schritte
- PROC
- Prozess — geordnete Schritte mit Rollen und Gates
- STD
- Standard — technische Regeln, die einzuhalten sind
- TMP
- Methode und Vorlage — wie ein Dokument entsteht, samt Blankoformular
- CHK
- Checkliste — je Release ausgefüllt
- REC
- Nachweis — Beleg, dass etwas zu einem Datum geschehen ist
- LST
- Register — lebende Daten, laufend aktualisiert
- ORG
- Organisationsmatrix — Rollen und Vertretungen
- CLS
- Klauselwerk — Vertragstext für Lieferanten
- RA · TM · DES
- Risikobewertung, Bedrohungsmodell, Designdokument — die produktbezogenen Artefakte
Nummern, Produkte und Revisionen
- Nummern werden je Domäne vergeben, in Blöcken nach Typ; die Lücken sind ACMEs Dokumente, die hier nicht veröffentlicht sind. Erst die vollständige ID identifiziert ein Dokument, nicht die Nummer allein.
- Produktartefakte enden auf den Produktcode statt auf eine Nummer — SEC-RA-S300 ist die Risikobewertung für den SensorNode S300, weil es je Produktlinie genau eine gibt. Ihr Lebenszyklus steckt in der Version: v0.1 ist die Basislinie vor der Entwicklung, v1.0 die Release-Fassung, und jede Version wird aufbewahrt, weil v0.1 selbst Teil der technischen Dokumentation nach Anhang VII ist.
- Die Revision verrät, wie sich ein Dokument verhält: Rev. 1.0 ist ein gelenktes Dokument, dessen Änderungen freigegebene Ereignisse sind, ein lebendes Register trägt eine ganzzahlige Revision, und ein Jahresnachweis wird neu ausgestellt statt überarbeitet.
Vollständige, realistische Dokumente eines fiktiven Herstellers mit 45 Beschäftigten. Jedes hat eine eigene Seite, sodass Sie es aus TRA Studio heraus verlinken können.
Hier beginnen: die Prozesse
Der Entwicklungsprozess von Anfang bis Ende — einmal als CRA-Phasen- und Gate-Plan, einmal als V-Modell nach IEC 62443-4-1 — dazu die Schwachstellenbehandlung, die über den gesamten Unterstützungszeitraum läuft. Jedes weitere Dokument unten ist ein Nachweis, den einer von ihnen erzeugt.
SDL-PROC-001
CRA-Aligned Software Development Process
Fünf Phasen und vier Gates: jede CRA-Pflicht abgebildet auf eine Aktivität, eine verantwortliche Rolle und den Nachweis, den sie erzeugt — samt Traceability-Tabelle, die zeigt, was noch nicht abgedeckt ist.
SDL-PROC-004
V-Model Secure Development Process
Dieselben Pflichten als V gezeichnet, entlang der Praktiken aus IEC 62443-4-1: vier Spezifikationsebenen abwärts, vier Verifikationsebenen aufwärts, jede mit dem Test benannt, der sie schließt — mit Diagramm, Gate-Kriterien und den Delta-Regeln dafür, wann eine Änderung Sie den linken Ast wieder hinunterzwingt.
PSM-PROC-002
Vulnerability Handling Process
Eingangskanäle mit Reaktionszeiten, CVSS-basierte Behebungsklassen und der Meldeweg nach Art. 14 — wo die 24-Stunden-Uhr bei plausiblen Hinweisen anläuft, nicht erst bei fertiger Analyse.
PSM-PROC-003
Vulnerability Handling — Detailed Operating Procedure
Die Schritt-für-Schritt-Fassung von PSM-PROC-002: die Fähigkeiten, die vorhanden sein müssen, bevor die erste Meldung eintrifft, dann jeder Schritt vom Eingang bis nach dem Release, mit Ergebnis und dem Nachweis, der aufbewahrt wird.
Unternehmensweite Richtlinien und Standards
Einmal geschrieben, von jedem Produktdossier referenziert.
SDL-POL-001
Security Development Lifecycle Policy
Der unternehmensweite SDL, auf den jedes Produktdossier verweist: sechs Phasen, Rollen, risikobasiertes Tailoring und Regeln für sichere Voreinstellungen.
SDL-POL-005
Third-Party & Open-Source Component Policy
Komponenten wie Lieferanten behandelt: K.-o.-Kriterien bei der Auswahl, Freigabeprozess und die Pflichten, die über den gesamten Unterstützungszeitraum laufen.
SDL-STD-022
Support Period & Security Update Policy
Sieben Jahre für die Industrielinien, Sicherheitsupdates kostenlos und getrennt von Funktionen, signierte und rollback-geschützte Auslieferung — und was am Ende des Supports geschuldet ist.
SDL-STD-034
Default Credential Policy
Keine universellen Standardpasswörter: Zugangsdaten je Gerät oder erzwungene Einrichtung beim ersten Gebrauch — und was das der Fertigungslinie abverlangt.
SDL-STD-020
Secure Coding Standard
Eine MISRA-Teilmenge mit echtem Abweichungsverfahren, verbotene Konstrukte durch die Pipeline statt durch Erinnerung durchgesetzt, Secret-Scanning über die Branch-Historie — und ein Briefing für Reviewer sicherheitsrelevanter Änderungen.
SDL-STD-021
SDL Tailoring Rules
Wie viel Prozess welcher Release-Typ bekommt, entschieden vor Entwicklungsbeginn — dazu die kurze Liste, die nie tailorbar ist, und die fünf Fragen, die entscheiden, ob eine Änderung eine wesentliche Veränderung ist.
SDL-STD-025
Release Signing & Key Management
Die Schlüsselhierarchie, Vier-Augen-Signatur ohne Notfall-Umgehung, und warum der zweite Prüfslot auf dem Gerät über den Unterschied zwischen Rückholung per Funk und Rückruf entscheidet.
CON-CLS-007
Supplier Security Clause Set
Die Vertragsklauseln, die eine zugekaufte Komponente über das ganze Produktleben betreubar halten: 72-Stunden-Schwachstellenmeldung, Patch-Frist mit Datum, 24 Monate EOL-Vorlauf, SBOM je Release und ein Escrow, das Sie tatsächlich auslösen können.
Unterstützende Register und Vorlagen
Die Dokumente, auf die die Richtlinien verweisen — dort stehen die Skalen, Fristen und Listen tatsächlich.
PSM-LST-001
Product & Support Register
Welche Produkte je Hardwarerevision noch unterstützt werden und welche Firmware-Zweige noch Fixes erhalten — die Nachschlagequelle, mit der jede Triage beginnt, und der Nachweis dessen, was Sie vor Jahren veröffentlicht haben.
SDL-TMP-010
Risk Assessment Method & Template
Verankerte 4×4-Skalen, die Schwellen, die darüber entscheiden, ob ein Risiko eine Designmaßnahme oder einen Absatz bekommt, und die Versionsregel, die belegt, dass die Bewertung vor dem Design-Freeze lag.
SDL-TMP-011
Threat Modeling Method & Template
STRIDE je Element auf einem Datenflussdiagramm, mit einer Hardware-Entwicklerin im Raum — denn bei eingebetteten Produkten sind die interessanten Funde meist physisch, und jede Bedrohungszeile muss in einer Anforderung enden.
QM-ORG-003
Role Matrix & Deputies
Wer welche Rolle innehat, wer vertritt und welche Kombinationen verboten sind — das Dokument, das jede Vier-Augen-Regel anderswo auch dann ausführbar macht, wenn jemand im Urlaub ist.
LEG-LST-002
Software Licence Whitelist
Ja, Rechtsabteilung fragen oder nein — in fünf Minuten, im Moment der Komponentenauswahl. Einschließlich der Frage, warum LGPL und signierte, statisch gelinkte Firmware in direktem Widerspruch stehen.
Vorentwicklung je Produkt (SensorNode S300)
Die Entscheidungen und Bewertungen, die ein Hersteller dokumentieren muss, bevor die Architektur eingefroren wird.
REG-REC-020
CRA Product Classification Determination
Ein Produkt geprüft gegen Anhang III und Anhang IV, mit der Begründung je Kategorie und dem Auslöser für eine erneute Bewertung.
REG-REC-021
Conformity Assessment Route Decision
Warum Modul A greift, was es verpflichtend macht — und der Rückfallplan über eine notifizierte Stelle samt Vorlaufzeiten.
SEC-RA-S300
Product Risk Assessment (v0.1, pre-development)
Die Risiko-Basislinie vor der Entwicklung, die die Hardwareauswahl einschränkt — und die Regel, dass jede Version aufbewahrt wird.
SEC-TM-S300
Threat Model (STRIDE, pre-development)
Dokumentierte Methodik, Vertrauensgrenzen, Inventar der Angriffsfläche, Bedrohungsakteure und die daraus abgeleiteten Anforderungen.
ENG-REC-031
EOL Check: Tools and Dependencies
Jede Komponente geprüft gegen den Horizont des Unterstützungszeitraums, mit Auflagen, Migrationsrhythmus und einem K.-o.-Fall.
ENG-REC-032
Storage Encryption Feasibility (Data at Rest)
Ein gemessener Vergleich zweier MCUs gegen eine grundlegende Anforderung — und der Nachweis, der die teurere Hardware noch vor dem Layout erzwingt.
ENG-DES-033
Minimal Attack-Surface Design Plan
Schnittstelle für Schnittstelle früh entschieden: entfernen oder deaktivieren — samt Folgen für Mechanik und Fertigung.
Release- und Konformitätsnachweise
Die Nachweise, die je Release und je Jahr entstehen.
SDL-CHK-030
Secure-by-Default Release Checklist
Eine ausgefüllte Release-Gate-Checkliste gegen die Werksvoreinstellung, samt dokumentierter Abweichung und Risikoakzeptanz.
SDL-REC-002
Internal SDL Conformity Review
Der Jahresnachweis, der Prozesskonformität ohne externes Zertifikat belegt, samt Aufbau eines Konformitätsdossiers je Release.
REG-REC-019
EU Authorised Representative (Art. 19)
Eine Anwendbarkeitsfeststellung für einen in der EU ansässigen Hersteller und ein schriftliches Mandat für den Fall außerhalb der EU.
Die Beispieldokumente und Projektpläne sind bewusst nur auf Englisch veröffentlicht: Sie sind Vorlagen zum Übernehmen, und eine Übersetzung wäre nicht die Fassung, mit der Sie am Ende arbeiten.
Fiktives Beispiel. Die ACME Embedded GmbH, ihre Produkte, Nachweise und Dokument-IDs sind zur Veranschaulichung erfunden. Nutzen Sie das als strukturelles Vorbild, nicht als unverändert zu übernehmende Vorlage — und nicht als Rechtsberatung.