Für Sie
Hersteller
Artikel 13 und 14
Eine Plattform. Eine CRA-Schleife.
alloy-it deckt die Embedded-Software-Lieferkette durchgängig ab: Sie überwachen, was Sie ausgeliefert haben, benachrichtigen Behörden, wenn etwas aktiv ausgenutzt wird, verfolgen zurück bis zum Release und Blueprint und reproduzieren den Fix.
Die vier Fähigkeiten
Wo immer Sie starten: Sie landen in derselben Schleife. SBOMs, Firmware und Build-Umgebungen sind Einstiege, nicht vier separate Käufe.
01
Überwachen
Produktinventar und kontinuierlicher Scan
Dauerhafte Überwachung von allem, was ein ausgeliefertes Produkt ausmacht: das Hersteller-SBOM, das aus der Firmware abgeleitete Inventar und die Umgebung, die es gebaut hat, über die gesamte Marktlebensdauer des Geräts.
02
Behörden benachrichtigen
Bereitschaft für Artikel 14
Wird ein Fund in einem ausgelieferten Produkt aktiv ausgenutzt, halten Sie die erste Kenntnis fest und bereiten das 24h-/72h-/14-Tage-Paket nach Artikel 14 vor. JSON in ENISA SRP / nationales CSIRT kopieren. Alloy reicht nicht ein und sendet keine automatischen Kunden-E-Mails.
03
Zurückverfolgen
Komponente → Release → Nachweis
Von einem CVE oder einer Komponente die Kette entlang: welche Releases enthalten sie, und welche Build-Umgebung hat die Binary erzeugt. Auditfähig in beiden Richtungen.
04
Reproduzieren
Neubau und Fix ausliefern
Weil Build-Umgebungen versionierte Blueprints sind, lässt sich die exakte Toolchain, die ein betroffenes Release gebaut hat, rekonstruieren, um den Fix zu bauen und auszuliefern, auch Jahre später, bei Geräten mit 10 bis 15 Jahren Unterstützungszeitraum.
Die Schleife schließt einen Vorfall von Ende zu Ende: Überwachen erkennt → Benachrichtigen grenzt betroffene Releases ein → Zurückverfolgen findet den Ursprung → Reproduzieren liefert den Fix. Behördenmeldung und Kundenavise sind getrennte Notify-Pfade.
Gebaut für den Hersteller im Sinne der Verordnung
Ebenfalls für Sie
Wesentliche Veränderung
Als Hersteller behandelt
Die Teams in dieser Organisation
Nicht dieses Produkt
Bevollmächtigte, Einführer, die nur einführen, Händler, Open-Source-Stewards, notifizierte Stellen und Behörden sind nicht der Käufer.
Wie Artefakte in die Schleife gelangen
Produkte / SBOMs
Produkte und Releases anlegen. Hersteller-CycloneDX/SPDX hochladen. Kontinuierliches erneutes Scannen und Alerts an den PSIRT-Posteingang.
Firmware
Die Binary hochladen (Analyse auf Abruf, nie automatisch). Inventar ableiten, mit dem Hersteller-SBOM vergleichen, prüfen, nicht nur übernehmen.
Build-Umgebung
Blueprints, Toolchain-Scan und Provenance: der Reproduce-Zweig, wenn Sie ein betroffenes Release Jahre später neu bauen müssen.
Triage entscheidet, was tatsächlich im Produkt steckt
Ein Scanner liefert Tausende Funde. Was ein Prüfer will, ist die Entscheidung zu jedem einzelnen Fund und die Begründung.
alloy-it · GW-4200 Gateway · v2.4.1 · Triage
| CVE | Komponente | Schweregrad | Ausgenutzt | Entscheidung |
|---|---|---|---|---|
| CVE-2026-1337 | zlib 1.2.11 | CRITICAL | KEV | Betroffen |
| CVE-2026-0455 | openssl 3.0.8 | HIGH | — | Nicht betroffen |
| CVE-2025-9902 | busybox 1.35.0 | HIGH | — | In Prüfung |
| CVE-2025-7710 | libcurl 7.88.1 | MEDIUM | — | Falsch positiv |
Jede Entscheidung trägt eine Begründung und eine Historie. Dieses Protokoll ist der Nachweis, nicht die Scan-Ausgabe.
Trace back, in beide Richtungen
Von einem CVE hinunter zu den Releases, die es enthalten, und von einem Release zurück zu der Umgebung, die die Binary erzeugt hat.
Registry und Provisioner: der Neubau-Pfad
Bestätigt die Triage ein betroffenes Release, zeigt die Build-Provenance auf den Blueprint, der die Binary erzeugt hat. Der Open-Source-Provisioner rekonstruiert diese Umgebung. So bringen Sie ein gepatchtes Release wieder in die Überwachung, auch Jahre in den Unterstützungszeitraum hinein.
Die Plattform an Ihren Produkten sehen
Buchen Sie einen CRA-Walkthrough, oder starten Sie kostenlos mit einem Produkt und Ihren letzten N SBOMs.