CRA-Schwachstellenüberwachung für Hersteller
Schwachstellen im Blick. Entscheidungen im Griff.
Resilvance überwacht die Softwarekomponenten Ihrer Produkte, priorisiert neue Schwachstellen und dokumentiert jede Prüfung. Ihr Quellcode bleibt in Ihrem Haus.
CRA-Meldepflichten ab 11.09.2026 · Hauptpflichten ab 11.12.2027
Frühzeitig informiert
Neue Schwachstellen und Ausnutzungshinweise werden regelmäßig abgeglichen und den betroffenen Produkten zugeordnet.
Für Audits nachvollziehbar
Prüfläufe, Entscheidungen und Maßnahmen bleiben vollständig dokumentiert.
Darstellung der Anwendung mit Beispieldaten.
So funktioniert es
Ein geführter Prozess vom Komponentenbestand bis zum vorzeigbaren Nachweis.
Produkt und SBOM erfassen
Sie hinterlegen Produkte und eine prüfbare Software-Stückliste. Fehlt die SBOM, unterstützen wir Sie bei der Erstellung.
Laufend überwachen
Resilvance gleicht die verwendeten Komponenten in festgelegten Intervallen mit den angebundenen Schwachstellenquellen ab.
Betroffenheit prüfen
Treffer werden anhand von Version, Plattform, Build, Patch-Stand und ausgeliefertem Umfang geprüft und priorisiert.
Entscheiden und nachweisen
Sie dokumentieren die Herstellerentscheidung, planen Maßnahmen und bereiten erforderliche Meldungen vor.
Ihr Quellcode bleibt im Haus.
Die Analyse der Codebasis erfolgt lokal und ohne Internetzugang. Resilvance erhält nur die von Ihnen geprüfte SBOM beziehungsweise ausgewählte Komponentenangaben. Sie entscheiden, was Ihr Unternehmen verlässt.
- Lokaler, ausschließlich lesender Zugriff auf die Codebasis
- SBOM vor einer Übertragung vollständig prüfbar
- Kein Upload von Quellcode oder Dateipfaden
Für die SBOM-Erstellung setzen wir bei Bedarf ein lokal ausgeführtes Werkzeug ein. Der geplante Self-Service-Scanner wird erst als verfügbar beworben, sobald er ausgeliefert ist.
Was Resilvance im laufenden Betrieb leistet
Komponentenüberwachung
Regelmäßiger Abgleich der tatsächlich eingesetzten Softwarekomponenten mit den angebundenen Schwachstellenquellen.
SBOM-Management
Import, Prüfung und Versionierung von CycloneDX-SPDX-Dateien sowie Zuordnung zu Produkten und Releases.
Bewertung und Priorisierung
Geführte Prüfung von Version, Plattform, Patch-Stand, Build und ausgeliefertem Umfang.
Fristen und Meldungen
Fristenführung und vorbereitete Entwürfe für die gesetzlichen Meldestufen. Freigabe und Einreichung bleiben beim Hersteller.
Benachrichtigungen
Gezielte Hinweise bei neuen Treffern, Ausnutzungshinweisen und fälligen Entscheidungen.
Maßnahmen und Status
Verantwortliche, nächste Schritte, Termine und Bearbeitungsstand werden an einem Ort geführt.
Nachweise und Berichte
Prüfläufe, Bewertungen und Entscheidungen werden revisionsnah dokumentiert und als Bericht exportiert.
Integrationen
geplantVorbereitete Anbindung an Entwicklungs-, Ticket- und Governance-Prozesse. Nur tatsächlich verfügbare Schnittstellen nennen.
Die Frage vor aller Technik
Wer bei Ihnen bemerkt es — und wer schreibt in 24 Stunden die Meldung?
Bei einer in Ihrem Produkt läuft ab dem 11.09.2026 eine 24-Stunden-Frist für die , danach 72 Stunden und ein Abschlussbericht. Die Uhr läuft ab — nicht ab dem Zeitpunkt, an dem der Kollege erreichbar ist, der die Build-Konfiguration im Kopf hat. Und der zweite Meldeauslöser, der , steht in keinem Datenfeed: Er kommt als Kundenanruf.
Der Einstieg
Ein Erstauftrag zum Festpreis — für eine Produktfamilie
Bevor eine laufende Überwachung überhaupt etwas nützt, braucht Ihr Produkt eine Stückliste und Ihr Haus einen Meldeprozess mit Namen darin. Genau das ist der Erstauftrag: ein abgeschlossenes Vorhaben mit einem Prüfbericht als Ergebnis, auslösbar ohne Grundsatzentscheidung — in fünf Schritten.
- Sie brauchen keine fertige Stückliste. Wir erheben sie mit Ihnen — für die meisten Hersteller ist es die erste, die sie je hatten. Richtwert drei bis vier Wochen, ein Kunde nach dem anderen.
- Festpreis, kein Abonnement — und voll anrechenbar, wenn Sie danach in den laufenden Betrieb gehen.
- Der Auftrag steht allein. Kaufen Sie danach nichts mehr, haben Sie trotzdem Stückliste, Prozess und Nachweis. Nur ein Teil lässt sich nicht einmalig erledigen: das laufende Bemerken. Das ist unser Anschlussangebot — nicht die Bedingung.
Stückliste und Produktsteckbrief erheben
Gemeinsam mit Ihnen: enthaltene Komponenten, Zielplattform und Architektur, Distribution und Patch-Stand, Build-Konfiguration, ausgelieferter Umfang und Netzexposition.
Abgleich gegen die Schwachstellenquellen
Das heutige Ist-Bild Ihrer Produktfamilie — ausdrücklich auch dann dokumentiert, wenn kein ausgenutzter Treffer dabei ist.
Die Prüffragen vorab beantworten
Der Prüfpfad einmal je Produktfamilie durchgearbeitet und schriftlich fixiert. Das verwandelt einen 24-Stunden-Notfall in eine Entscheidung von einer halben Stunde.
Meldeprozess auf Papier
Wer bemerkt, wer entscheidet, wer meldet, an wen, in welcher Frist — mit einer real ausgefüllten Frühwarnung für den plausibelsten eigenen Ernstfall.
Prüfbericht als PDF
Ihr vorzeigbares Ergebnis. Der laufende Betrieb ist danach das Angebot, nicht davor.
Für wen das gilt
Hersteller mit eigener Entwicklung — und eine offen benannte Grenze
Wir arbeiten für Maschinen- und Elektronikhersteller, die ihre Software selbst entwickeln, ein bis drei Produktfamilien betreuen und kein eigenes Produkt-Sicherheitsteam haben. Wo die Stückliste heute automatisch entsteht und wo wir sie mit Ihnen erheben, hängt nicht von Ihrer Programmiersprache ab, sondern davon, womit Sie bauen:
Automatisch
Linux-Geräteabbilder aus Yocto, Buildroot oder Debian-Paketen
Diese Bausysteme führen selbst Buch darüber, woher jede Komponente stammt und in welcher Fassung. Die Stückliste entsteht dann weitgehend von allein — auch für Software in C und C++. Übrig bleiben einzelne Rückfragen, keine Untersuchung.
Im Gespräch erhoben
Steuerungsprojekte, Firmware ohne Bausystem, gewachsene Windows-Werkzeuge
Für Siemens, Beckhoff oder Codesys erzeugt unser Werkzeug heute keine Stückliste — die eingebundenen Bibliotheken stehen aber im Projekt selbst und werden in einer begleiteten Online-Sitzung aufgenommen. Es dauert länger, das Ergebnis ist dasselbe.
Die Grenze betrifft das Werkzeug, nicht das Angebot. Nur der Abgleich gegen die Schwachstellenquellen setzt eine vollständige Stückliste voraus. Produktsteckbrief, vorab beantwortete Prüffragen, Meldeprozess und Prüfbericht entstehen aus Fragebogen und Gespräch — und das ist erfahrungsgemäß der Teil, an dem es am meisten fehlt.
Bringen Sie eine Stückliste bereits mit — aus Ihrer Entwicklung, von einem Dienstleister oder von Ihrem Zulieferer —, arbeiten wir damit weiter. Das Format ist ; woher die Datei stammt, ist für die laufende Überwachung ohne Belang.
Die schnellste Klärung im Erstgespräch ist eine einzige Frage: Womit bauen Sie Ihr Geräteabbild?
Ohne Anmeldung
So sieht das Produkt im Alltag aus
Wie die Arbeit im laufenden Betrieb aussieht, können Sie ohne Anmeldung ansehen — zwei Produkte eines fiktiven Maschinenbauers in derselben Anwendung: MaschinenMonitor 4.2.0 mit einem aktiv ausgenutzten Fund und SensorGateway 2.1.0 ohne Befund. Beide stehen in der Produktliste, umschalten können Sie in der Kopfzeile. Die Demo zeigt Übersicht, Produkte, Komponenten, Schwachstellen, Prüfungen, Meldungen, Nachweise und Einstellungen. Funktionen, die eine Vorführung nicht zeigen kann, bleiben sichtbar und sind als gesperrt gekennzeichnet.
Im Demo-Weg werden keine Daten gespeichert. Für den Abgleich verlassen nur einzelne Komponenten-Angaben wie Paketname und Version den Browser — keine Dateipfade, kein Quellcode. Was passiert mit Ihren Daten?
Der Einstieg
Erstprüfung einer Produktfamilie
Wir erheben Produktsteckbrief und SBOM, gleichen den aktuellen Stand mit den Schwachstellenquellen ab und dokumentieren Ihren Prüf- und Meldeprozess. Das Ergebnis ist ein vorzeigbarer Prüfbericht.