CRACI vs Medcrypt

En bref

Medcrypt est une entreprise de cybersécurité des dispositifs médicaux. Sa plateforme, Medcrypt Security Intelligence (MSI), associe un logiciel à une équipe d'anciens examinateurs de la FDA pour préparer, auditer et maintenir le dossier de cybersécurité d'un dispositif. La promesse de sa page d'accueil est « Get your cybersecurity submission approved. The first time. » Helm, son produit de gestion des SBOM et des vulnérabilités, fait partie de MSI et se vend aussi séparément.

CRACI est un runner GitHub Actions qui enregistre les dépendances que chaque job a réellement récupérées et produit la SBOM à partir de cet enregistrement, avec un état de complétude. Il réévalue ensuite les SBOM surveillées à mesure que paraissent les avis de sécurité, et les équipes sécurité trient les résultats et les envoient à l'équipe chargée de la correction. CRACI ne prépare ni n'examine de dossiers pour la FDA. Pour la SBOM et le suivi post-marché des vulnérabilités des logiciels que vous construisez, CRACI remplace Helm, en partant du build lui-même.

En un coup d'œil

Ce que Medcrypt fait bien

• Une expertise FDA en interne. Les vérifications, les audits et les modèles de MSI sont conçus par une équipe qui, selon les termes de Medcrypt, comprend des « former FDA reviewers and authors of the guidance itself. » Le plan MSI inclut 15 heures de conseil par an avec eux, et la plateforme analyse les dossiers de soumission pour repérer ce qu'un examinateur signalerait. Pour une première soumission 510(k) ou PMA, c'est une aide que CRACI ne propose pas.
• Tout le dossier, pas seulement la SBOM. MSI couvre la modélisation des menaces, l'évaluation des risques de cybersécurité, la génération de documents (en bêta), les réponses aux lettres de déficience et, en option, les tests d'intrusion via des partenaires sélectionnés.
• Le travail post-marché après l'autorisation. MSI inclut une surveillance continue des vulnérabilités et l'adhésion à MedISAO, qui selon Medcrypt apporte des alertes de vulnérabilités propres aux dispositifs, un programme de divulgation coordonnée des vulnérabilités et des mises à jour réglementaires. Sa page plateforme le dit sans détour : « Section 524B made post-market cybersecurity a legal duty. »
• Helm est conçu pour les fabricants de dispositifs. Helm classe les résultats à l'aide des données EPSS, CISA KEV, ExploitDB et Metasploit, réévalue en masse les vulnérabilités selon le contexte de chaque dispositif, reporte les remédiations d'une version de produit à l'autre et utilise des règles d'alias pour faire correspondre les composants aux entrées de la NVD. Il exporte des SBOM CycloneDX et SPDX, des rapports VEX et VDR, et un format Medcrypt FDA SBOM.
• Un acteur établi dans sa niche. Medcrypt a été fondé en 2016, est passé par Y Combinator et annonce $36.4M de financement, avec des investisseurs tels que Johnson & Johnson Innovation, Intuitive Ventures et Dexcom Ventures. Il indique que plus de 140 fabricants de dispositifs médicaux lui font confiance, dont 13 du top 50.
• Des tarifs publiés. MSI coûte $35,000 par gamme de produits et par an, avec un nombre illimité d'utilisateurs, facturé annuellement.

Ce qui distingue CRACI

Il produit la SBOM, à partir du build

Helm travaille avec les SBOM que vous lui fournissez. Vous envoyez ou créez des fichiers CycloneDX ou SPDX, ou une GitHub Action Helm envoie un fichier SBOM depuis votre workflow (la documentation indique qu'elle prend en charge CycloneDX JSON aujourd'hui). Pour les équipes sans SBOM, la documentation de Helm renvoie à des générateurs open source, à la création manuelle, à des services d'experts ou à un outil de génération Medcrypt disponible sur demande. La liste de composants que Helm surveille vient donc toujours d'un scanner ou d'un fichier construit à la main.

CRACI exécute le job. Vous définissez runs-on sur craci, et un proxy qui comprend les paquets enregistre le trafic vers les sources de paquets pendant le build : npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et les sources Git, ainsi que les presets de téléchargement. Les preuves de dépendances suivent les caches CI : un paquet restauré depuis un cache figure donc toujours dans l'enregistrement. Chaque SBOM indique son niveau de complétude, par job et par cache : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded.

Les builds pour Linux embarqué

Si votre dispositif exécute une image Yocto, la comparaison est directe. La documentation de Helm montre comment activer la sortie SPDX propre à Yocto et l'envoyer. CRACI exécute BitBake sur des runners allant jusqu'à 32 vCPU et 96 GB de RAM. Lors d'un build comparatif de core-image-sato, la SBOM de CRACI contenait chaque composant de la sortie SPDX propre à Yocto, 88 de plus, comme les paquets de l'hôte et les GitHub Actions, et une package URL pour chacune des 653 versions de crates Rust que Yocto liste sans en donner.

Des réponses post-marché tirées de l'historique des builds

Lorsqu'une nouvelle vulnérabilité apparaît, la question post-marché est de savoir quelles versions livrées la contiennent, et depuis combien de temps. CRACI conserve chaque build passé et sa SBOM, dans la limite de la période de conservation, et montre quels builds contenaient la dépendance vulnérable, directe ou transitive : vous connaissez ainsi la période pendant laquelle vous avez été exposé. Sa vue d'inventaire montre quelles versions logicielles sont déployées dans quels produits. Des policy gates peuvent arrêter un build ultérieur qui contient encore une CVE précise.

Le contrôle de ce que le build peut joindre

Comme CRACI est le runner, il applique une politique de trafic sortant : refus ou autorisation par défaut, avec 24 presets de sources logicielles intégrés et des sources personnalisées typées, validée avant le démarrage du job et qui bloque tout en cas d'échec. Il envoie une alerte en cas de violation de la politique. Medcrypt n'exécute pas votre build : ce point sort donc de son périmètre.

Au titre de la section 524B de la FDA

Au titre de la section 524B, une soumission pour un dispositif cyber doit inclure une SBOM « including commercial, open-source, and off-the-shelf software components » et un plan de surveillance et de traitement des vulnérabilités post-marché. Les deux produits touchent à ces exigences de manières différentes.

Medcrypt travaille sur la soumission elle-même : le modèle de menaces, l'évaluation des risques, les documents, l'audit au regard de ce que signalent les examinateurs de la FDA, et la réponse si la FDA envoie une lettre de déficience. Sa page de tarifs précise : « FDA is what the platform covers today. »

CRACI fournit des preuves issues du build : une SBOM de ce que le build a réellement utilisé, exportée en CycloneDX ou SPDX, et une surveillance continue de cette SBOM après la release, avec tri et routage vers l'équipe chargée de la correction. CRACI ne rédige, n'examine ni ne soumet de documentation pour la FDA, et il ne rend pas un dispositif conforme. Le plan et la soumission restent le travail du fabricant. Pour comprendre comment cela s'inscrit dans le travail d'une équipe de sécurité produit, consultez ce que fait un PSIRT et CRACI pour les équipes PSIRT.

Lequel choisir, et quand

• Vous préparez une première soumission ou répondez à une lettre de déficience. Medcrypt. D'anciens examinateurs de la FDA, des audits de soumission et la modélisation des menaces sont sa raison d'être, et CRACI ne fait rien de tout cela.
• Vous avez besoin de gérer les SBOM et les vulnérabilités des logiciels que vous construisez dans GitHub Actions. CRACI. Il produit la SBOM dans chaque build et la surveille : il n'y a donc ni générateur distinct à exécuter ni étape d'envoi à maintenir.
• Vous avez besoin de chiffrement, de gestion de clés ou d'identité des appareils sur le terrain. Guardian de Medcrypt couvre la sécurité côté appareil. CRACI travaille sur le build, pas sur l'appareil.
• Vos builds s'exécutent dans GitLab CI ou Jenkins. Helm propose une API, une GitHub Action et une extension Azure DevOps pour envoyer les SBOM. CRACI prend en charge GitHub Actions aujourd'hui, avec GitLab CI et Jenkins sur la roadmap.

Remplacer Helm par CRACI

Pour les logiciels de dispositifs construits dans GitHub Actions, CRACI couvre ce pour quoi Helm existe : il produit la SBOM dans chaque build, réévalue les SBOM surveillées à mesure que de nouvelles vulnérabilités sont publiées, agrège les résultats de l'ensemble des builds et des dépôts, prend en charge VEX, et permet aux équipes sécurité de trier les résultats et d'envoyer chacun à l'équipe chargée de la correction. Vous pouvez aussi ajouter les SBOM de vos fournisseurs, afin que les composants achetés soient surveillés aux côtés de vos propres builds.

Sachez précisément à quoi vous renoncez. Helm classe les résultats à l'aide de renseignements sur les exploits tels qu'EPSS et CISA KEV, propose des conseils de remédiation par IA, fait correspondre les composants avec des règles d'alias, suit les données de fin de support et exporte des rapports VDR et le format Medcrypt FDA SBOM. Et rien du travail de soumission de MSI, de ses heures de conseil ou de l'adhésion à MedISAO n'a d'équivalent chez CRACI. Si votre besoin principal est de faire accepter une soumission par la FDA, Medcrypt est conçu pour cela.

Vous comparez d'autres outils pour les équipes de sécurité produit ? Consultez le comparatif des outils PSIRT.