Der Cyber Resilience Act verpflichtet Hersteller digitaler Produkte zu durchgängiger Cybersicherheit — vom ersten Commit bis zum letzten Patch. nAIce ist von der ersten Codezeile an CRA-konform gebaut. Kein nachträgliches Compliance-Label — Sicherheit ist in der Architektur.
Der Cyber Resilience Act (EU-Verordnung 2024/2847) führt verbindliche Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen ein, die im EU-Markt angeboten werden — unabhängig davon, wo sie hergestellt werden. Er deckt den gesamten Produktlebenszyklus ab: von der Entwicklung über den Betrieb bis zum End-of-Life.
Der CRA betrifft Hersteller, Importeure und Händler gleichermaßen und gilt für:
Nicht erfasst sind eigenständige Websites sowie reine SaaS-Dienste ohne Verbindung zu PDEs. Aber: Sobald Ihre Software Teil eines digitalen Produkts ist oder steuert — sind Sie betroffen. Und damit auch der KI-Agent, der darauf läuft.
Die Übergangsfristen sind ambitioniert. nAIce erfüllt die Anforderungen schon heute — so sind wir aufgestellt.
CRA wird EU-Recht. Hersteller müssen schwerwiegende Schwachstellen und aktiv ausgenutzte Sicherheitsvorfälle binnen 24 Stunden an ENISA/BSI melden. nAIce hat automatisierte CVE-Monitoring-Ketten etabliert und testet sie regelmäßig in Incident-Response-Übungen.
Notifizierte Konformitätsbewertungsstellen werden benannt. Für kritische Produkte der Klasse II wird eine unabhängige externe Prüfung verpflichtend. nAIce wird bereits nach Klasse-II-Standard entwickelt — inklusive der dafür erforderlichen Dokumentationstiefe.
Hersteller von Produkten mit erhöhtem Risikopotenzial müssen eine notifizierte Stelle in die Konformitätsbewertung einbeziehen. nAIce ist mit seiner sicherheitskritischen Agent-Architektur darauf vorbereitet — Threat Models, SBOMs und Security-Dokumentation liegen versionskontrolliert bereit.
Alle CRA-Anforderungen gelten nun vollständig und uneingeschränkt. Eine CE-Kennzeichnung ohne CRA-Konformitätsnachweis ist nicht mehr zulässig. Unternehmen, die bis dahin nicht compliant sind, dürfen in der EU nicht mehr in Verkehr bringen. nAIce ist ab Tag 1 CRA-ready — und bleibt es.
Unser CRA-Framework ist kein nachträglich aufgeklebtes Compliance-Label — es ist in die nAIce-Architektur eingewoben. Jede Agent-Entscheidung, jedes Deployment, jedes Update folgt diesen sechs Prinzipien.
Security ist keine Option — sie ist die Architektur. Bedrohungsmodellierung nach STRIDE/LINDDUN vor der ersten Codezeile. Zero-Trust-Architektur als Default. Jeder Agent-Lauf operiert in einer isolierten Sandbox mit Least-Privilege-Prinzip.
Software Bill of Materials (CycloneDX + SPDX) für jeden Release — automatisch generiert und kryptografisch signiert. Jede Dependency ist versioniert, auf CVEs geprüft und lückenlos nachverfolgbar. SLSA Level 3 für Build-Provenienz.
Kontinuierliches CVE-Monitoring mit OWASP Dependency-Check, Trivy und Dependabot. Kritische Schwachstellen werden innerhalb von 72 Stunden gepatcht — mit vollständiger Dokumentation. Automatisierte Benachrichtigung bei sicherheitsrelevanten Updates.
Security-Gates fest in der CI/CD-Pipeline: SAST (Semgrep, CodeQL), Secret Scanning (Gitleaks), Dependency Scanning (Trivy), Container-Scanning. Kein Merge ohne bestandenen Security-Check. Obligatorisches Code Review mit Security-Fokus.
Vollständige technische Dokumentation nach CRA Annex I: strukturierte Risikoanalyse, Sicherheitsarchitektur mit Datenflussdiagrammen, Testreports, SBOM, Update-Policy. EU-Konformitätserklärung versionskontrolliert und auditsicher.
Definierte Support-Zeiträume (5 Jahre Minimum). Automatische, signierte Update-Mechanismen mit Rollback-Fähigkeit. Klare EOL-Kommunikation mit Übergangspfad. Kein Release ohne dokumentierten Patch-Fahrplan.
Ein autonomer KI-Agent braucht weitreichende Zugriffsrechte — und muss trotzdem sicher sein. So löst nAIce diesen Widerspruch.
Jede Agent-Capability wird vor der Implementierung einer STRIDE-Bedrohungsanalyse unterzogen. Welche Angriffsvektoren eröffnet eine neue Fähigkeit? Welche Datenflüsse entstehen? Ergebnis: ein Security-Target-Dokument, das die Sicherheitsanforderungen für jede Komponente verbindlich definiert.
Jeder Agent-Lauf operiert in einer isolierten Sandbox-Umgebung mit eigenen Credentials, Filesystem-Namespace und Netzwerk-Policy. Kein Agent kann auf die Ressourcen eines anderen zugreifen — auch nicht im Fehlerfall. Principle of Least Privilege auf jeder Systemebene.
Bevor ein Agent eine Aktion ausführt — Terminal-Befehl, API-Call, Dateizugriff — durchläuft sie einen Policy-Enforcement-Point. Kritische Operationen erfordern explizite Freigabe. Audit-Log jeder Agent-Aktion mit kryptografischer Integritätssicherung.
Jede nAIce-Version enthält eine maschinenlesbare SBOM (CycloneDX + SPDX), die alle Abhängigkeiten, LLM-Provider-Integrationen und Tool-Bibliotheken dokumentiert. Kryptografisch signiert mit Sigstore Cosign. CVE-Abgleich vor jedem Release.
Automatisierte dynamische Sicherheitstests: OWASP ZAP für API-Endpunkte, Nuclei für Infrastruktur-Scans. Manuelles Penetration Testing bei jedem Major Release. Prompt-Injection-Resilienz wird systematisch getestet — ein einzigartiger Vektor bei KI-Agenten.
Definierte Reaktionszeiten (kritisch: ≤24h, hoch: ≤72h). Automatisierte CVE-Benachrichtigung. Jeder Sicherheitsvorfall wird dokumentiert, analysiert und fließt in die nächste Iteration des Threat Models ein. Quartalsweise Incident-Response-Übungen.
nAIce-Kunden bekommen einen KI-Agenten, der nicht nur autonom arbeitet — sondern auch alle CRA-Anforderungen von Haus aus erfüllt. Sie delegieren an einen Agenten, der Sicherheit nicht als Feature, sondern als Fundament hat.
Ihr KI-Agent ist nachweislich CRA-konform — inklusive aller Dokumente für Audits und Compliance-Nachweise. Kein rechtliches Risiko durch ungepatchte Schwachstellen oder undokumentierte Abhängigkeiten.
CRA-Compliance wird zum Entscheidungskriterium im B2B-Einsatz. Mit einem CRA-konformen KI-Agenten gewinnen Sie Ausschreibungen, bei denen Mitbewerber mit ungeprüften Agenten aussortiert werden.
Compliance ist das Minimum. Unsere Sandbox-Architektur liefert tatsächliche Sicherheit: isolierte Agent-Läufe, auditierbare Aktionen, Schutz vor Prompt-Injection. Getestet im 24/7-Produktivbetrieb.
Mit jedem nAIce-Release erhalten Sie SBOM, Security-Report und Update-Fahrplan. Keine Blackbox. Jede Abhängigkeit dokumentiert und auf Schwachstellen geprüft — bis in die LLM-Provider-Integration.
Definierte Support-Zeiträume und klare Update-Policies — garantiert. Sie wissen genau, wie lange Ihr Agent gepflegt wird, was im Security-Fall passiert und wie der End-of-Life-Prozess aussieht.
Autonome Agenten brauchen Vertrauen. Mit unserer CRA-Architektur können Sie sicher sein: Jede Aktion ist nachvollziehbar, jede Abhängigkeit geprüft, jede Schwachstelle dokumentiert. Delegieren ohne Bauchschmerzen.
Der CRA verlangt eine Software Bill of Materials (SBOM) — eine vollständige, maschinenlesbare Liste aller Komponenten, Bibliotheken und Abhängigkeiten. nAIce liefert das standardmäßig. Inklusive LLM-Provider-Integrationen und Tool-Bibliotheken.
Jede SBOM wird kryptografisch signiert und mindestens 90 Tage in der Pipeline vorgehalten. Kunden erhalten die SBOM zusammen mit jedem Release — maschinenlesbar, versioniert, verifizierbar. Auf Wunsch liefern wir die SBOM auch im VEX-Format (Vulnerability Exploitability eXchange).
Seit Anfang 2024 ist jeder nAIce-Entwicklungsschritt auf CRA-Konformität ausgerichtet — noch bevor die Verordnung in Kraft trat.
Der CRA definiert Mindestanforderungen. nAIce geht in jeder Disziplin darüber hinaus — weil ein autonomer KI-Agent kein Ort für Sicherheits-Kompromisse ist.
| Anforderung (CRA) | Gesetzliches Minimum | nAIce Standard |
|---|---|---|
| Schwachstellen-Meldung | 24h an ENISA/BSI | 24h Meldung + sofortige Kundenbenachrichtigung + priorisierter Patch-Plan |
| SBOM | Auf Anfrage bereitstellen | Mit jedem Release, kryptografisch signiert, CycloneDX + SPDX + optional VEX |
| Support-Dauer | Mindestens 5 Jahre (erwartet) | 5 Jahre Minimum, 10+ für kritische Systeme, EOL-Strategie inklusive |
| Security-Testing | Risikobasiert, Art nicht spezifiziert | SAST + DAST + Container-Scan + manuelles Pentesting bei jedem Major Release |
| Agent-Sicherheit | Nicht adressiert | Sandbox-Isolation + Prompt-Injection-Testing + Audit-Log jeder Aktion |
| Dokumentation | Technische Dokumentation (Annex I) | Annex I + Architekturdokumentation + Threat Model + Test-Reports + Update-Policy |
| Konformitätsbewertung | Selbsterklärung (Klasse I) | Standardmäßig vorbereitet für Klasse II (externe Prüfung durch benannte Stelle) |
| Supply Chain | Dokumentation der Lieferkette | SLSA Level 3 Provenienz + signierte SBOM + Dependency-Graph + CVE-Monitoring |
| Update-Mechanismus | Sicherer Update-Kanal | Signierte Updates + automatische Rollback-Fähigkeit + A/B-gestützte Deployments |
| Meldepflicht-Tests | Keine Vorgabe | Quartalsweise Incident-Response-Übungen mit simulierten CRA-Meldungen |
CRA-Compliance steht und fällt mit den richtigen Werkzeugen in der Pipeline. Das ist unser Stack — erprobt im 24/7-Produktivbetrieb.
Semgrep, CodeQL, SonarQube — für mehrschichtige statische Code-Analyse mit Security-Regelsätzen. Pre-Commit und in der Pipeline. Sprachen: TypeScript, Python, Go.
Trivy, Grype, Dependabot — SBOM-Generierung, CVE-Abgleich und Container-Image-Scans. Automatisiert bei jedem Build. Fails bei Critical.
Gitleaks, GitGuardian — Pre-Commit- und Pipeline-Scans gegen versehentlich committete Secrets. Blockiert den Push, bevor das Secret das Remote-Repo erreicht.
SLSA Level 3 mit Sigstore Cosign — jede SBOM, jedes Container-Image und jedes Release-Artefakt wird kryptografisch signiert.
OWASP ZAP, Nuclei — automatisierte dynamische Sicherheitsscans gegen Staging-Umgebungen. OWASP Top 10, SQLi, XSS, CSRF. Vor jedem Deployment.
Falco, Auditd, Custom Alerts — Echtzeit-Erkennung von anomalem Verhalten in Produktivumgebungen. Direkte Anbindung ans Incident-Response-System.
Was unsere Kunden zum Cyber Resilience Act und zur Sicherheit ihres KI-Agenten wissen wollen.