FerroSCA

Un serveur SBOM / SCA et de gestion des vulnérabilités natif Rust. Il ingère des SBOM CycloneDX et SPDX, score les findings avec CVSS et EPSS, et sert les résultats via une REST API. Il s’exécute comme un seul processus Rust — pas de JVM, pas de couche front-end séparée, pas de couche worker séparée — démarre en moins d’une seconde et embarque son dashboard dans le même binaire. AMI Amazon Linux 2023 durcie (arm64 / Graviton).

FerroSCA ingère les SBOM CycloneDX 1.4 / 1.5 / 1.6 (JSON et XML) et SPDX 2.2 / 2.3, corrèle les composants avec les données publiques de vulnérabilités (NVD JSON 2.0, OSV, flux d’advisories publics et catalogue CISA KEV), score les findings avec CVSS v2 / v3 / v4 et EPSS, évalue les politiques et expose les résultats via une REST API. Il prend en charge les identifiants Package URL 0.6 et CPE 2.3, le matching sensible à la distro pour les images de base Alpine / Debian / Ubuntu, un moteur de politiques avec 30+ conditions et la détection de licences SPDX. Les notifications passent par Email et Webhook. L’authentification est local-user (clés API SHA3-256), OIDC et LDAP (gated), avec TLS via rustls et ACL au niveau projet sur les mutations. L’API est une REST API native FerroSCA (standard), plus une édition compatible filaire Dependency-Track REST API v1 en opt-in (dtrack-compat) pour la migration. Périmètre honnête : l’API Dependency-Track couvre 100% des chemins mais environ 69% du deep-schema (symétrie de présence, pas fidélité au niveau champ) — jamais commercialisée comme 100% compatible filaire ni drop-in ; MySQL est exclu, et la topologie Marketplace prise en charge est single-node. Ingénierie : #![forbid(unsafe_code)] dans chaque crate, clippy propre à -D warnings, aucun unwrap() dans le code de production, gate cargo deny, SBOM CycloneDX + self-VDR en CI, et parsers testés par fuzzing.

Fonctionnement

1. 1

   Ingère les SBOM et leur attribue un score

   FerroSCA ingère les SBOM CycloneDX 1.4 / 1.5 / 1.6 (JSON / XML) et SPDX 2.2 / 2.3, met en corrélation les composants avec NVD JSON 2.0, OSV, les flux d'avis publics et la CISA KEV, et attribue un score aux résultats avec CVSS v2 / v3 / v4 et EPSS. Il prend en charge les identifiants Package URL 0.6 et CPE 2.3, ainsi que la mise en correspondance prenant en compte la distribution pour Alpine / Debian / Ubuntu.

2. 2

   Sert depuis un processus unique

   Les résultats sont fournis via une API REST et le tableau de bord est intégré dans le même binaire. Il s'exécute en tant que processus Rust unique — sans JVM, sans couche front-end distincte ni couche de workers distincte —, démarre en moins d'une seconde et consomme moins d'environ 256 MB de RAM au repos. Il comprend un moteur de politiques avec 30+ conditions et la détection de licences SPDX.

3. 3

   API native + une édition compatible DT

   Par défaut, il fournit une API REST native de FerroSCA, et pour la migration, vous pouvez opter pour une édition compatible au niveau du protocole avec l'API REST v1 de Dependency-Track (dtrack-compat). L'authentification se fait par utilisateur local (clés d'API SHA3-256), OIDC et LDAP (restreint) ; TLS via rustls ; ACL au niveau du projet pour les mutations ; notifications par Email et Webhook.

Points forts

Cas d'usage

FAQ