Pour vous
Fabricant
Articles 13 et 14
alloy-it couvre la chaîne d'approvisionnement logicielle embarquée de bout en bout : surveillez ce que vous avez mis sur le marché, notifiez les autorités lorsqu'une vulnérabilité est activement exploitée, remontez à la version et au Blueprint, et reproduisez le correctif.
Où que vous commenciez, vous retrouvez la même boucle. Les SBOM, le firmware et les environnements de compilation sont des points d'entrée, pas quatre choses à acheter.
01
Inventaire produit et scan continu
Surveillance permanente de tout ce qui constitue un produit mis sur le marché : le SBOM fournisseur, l'inventaire dérivé du firmware, et l'environnement qui l'a construit, pendant toute la durée de vie commerciale du dispositif.
02
Préparation article 14
Lorsqu'un constat est activement exploité dans un produit mis sur le marché, horodatez la première prise de connaissance et préparez le paquet article 14 24 h / 72 h / 14 jours. Copiez le JSON dans l'ENISA SRP / CSIRT national. Alloy ne soumet pas et n'envoie pas automatiquement d'e-mails aux clients.
03
Composant → version → preuves
À partir d'une CVE ou d'un composant, parcourez la chaîne : quelles versions le contiennent, et quel environnement de compilation a produit le binaire. Prêt pour l'audit dans les deux sens.
04
Reconstruire et livrer le correctif
Parce que les environnements de compilation sont des Blueprints versionnés, la chaîne d'outils exacte qui a construit une version concernée peut être reconstruite pour compiler et livrer le correctif, même des années plus tard, sur des dispositifs avec des périodes de support de 10 à 15 ans.
La boucle clôt un incident de bout en bout : surveiller détecte → notifier circonscrit les versions concernées → retracer trouve l'origine → reproduire livre le correctif. La notification aux autorités et les avis clients sont deux chemins de notification distincts.
Pour vous
Articles 13 et 14
Aussi pour vous
Traité comme fabricant
Inventaire vivant, triage, horodatage de prise de connaissance, paquet prêt pour le SRP.
Longues périodes de support, SBOM fournisseur versus firmware, dossiers de preuves.
Produits déjà sur le terrain, version après version, plus distribution optionnelle du SDK.
Pas ce produit
Les mandataires, les importateurs qui n'importent que, les distributeurs, les gardiens open source, les organismes notifiés et les autorités ne sont pas l'acheteur.
Créez des produits et des versions. Téléversez le CycloneDX/SPDX du fournisseur. Scan continu renouvelé et alertes vers la boîte PSIRT.
Téléversez le binaire (analyse à la demande, jamais automatique). Dérivez l'inventaire, comparez au SBOM fournisseur : vérifier, ne pas se contenter de faire confiance.
Blueprints, scan de la chaîne d'outils et provenance : le volet Reproduce quand vous devez reconstruire une version concernée des années plus tard.
Un scanner vous donne des milliers de constats. Ce qu'un évaluateur veut, c'est la décision que vous avez prise pour chacun, et pourquoi.
| CVE | Composant | Sévérité | Exploitée | Décision |
|---|---|---|---|---|
| CVE-2026-1337 | zlib 1.2.11 | CRITICAL | KEV | Concerné |
| CVE-2026-0455 | openssl 3.0.8 | HIGH | — | Non concerné |
| CVE-2025-9902 | busybox 1.35.0 | HIGH | — | En cours d'examen |
| CVE-2025-7710 | libcurl 7.88.1 | MEDIUM | — | Faux positif |
D'une CVE vers les versions qui la portent, et d'une version vers l'environnement qui a produit le binaire.
Lorsque le triage confirme une version concernée, la provenance de compilation pointe vers le Blueprint qui a produit le binaire. Le provisioner open source reconstruit cet environnement pour que vous puissiez livrer une version corrigée dans la surveillance, même des années dans la période de support.
Réservez une démonstration CRA, ou commencez gratuitement avec un produit et vos N derniers SBOM.