Scan SCA

Ce qui se passe lors d'un scan SCA

1. Lire la cible. Le scanner lit des manifestes et des lockfiles tels que package-lock.json, poetry.lock ou Cargo.lock, ou décompresse une image de conteneur.
2. Établir la liste des composants. Il résout ce qu'il a trouvé en noms et en versions, en incluant généralement les dépendances transitives.
3. Rapprocher les données. Chaque composant est recherché dans des sources telles que la GitHub Advisory Database, OSV et la NVD, et sa licence est comparée à votre politique.
4. Produire le rapport. Les résultats sont classés par sévérité, généralement avec une version corrigée. En CI, une politique peut faire échouer le job.

Pour la pratique plus large dont cela relève, voir qu'est-ce que l'analyse de la composition logicielle.

Où exécuter les scans SCA

Un seul scan à un seul endroit laisse des lacunes. Chaque étape répond à une question différente, c'est pourquoi la plupart des équipes en exécutent plusieurs.

Où	À quoi il répond	Ce qui lui échappe
Poste du développeur ou IDE	Ce paquet peut-il être ajouté sans risque ?	Tout ce sur quoi le développeur ne le lance pas
Pull request	Ce changement ajoute-t-il un risque connu ?	Les nouveaux avis de sécurité sur du code qui n'a pas changé
Build CI	Que contient la release ?	Tout ce que le scanner ne peut pas voir dans le build
Registre de conteneurs	Que contient cette image ?	Le code compilé et les outils de build qui ne laissent aucune trace
Après la release	Ce que nous avons livré est-il touché par quelque chose de nouveau ?	Rien, si l'enregistrement de ce qui a été livré est complet

La dernière ligne est celle que la plupart des programmes négligent. Un nouvel avis de sécurité touche une version livrée il y a des mois, et aucune pull request ne déclenchera de scan pour lui.

Comment lire les résultats d'un scan SCA

Un premier scan d'un vrai projet renvoie souvent des centaines de résultats. Traitez-les dans cet ordre :

1. Commencez par ce qui est exploité. Un résultat figurant dans le catalogue KEV de la CISA passe avant un score CVSS plus élevé sans exploitation connue. Voir comment prioriser les vulnérabilités.
2. Vérifiez qu'il s'applique. Les dépendances de développement ne sont pas livrées. Certains outils ajoutent l'analyse d'atteignabilité pour vérifier si le code vulnérable peut effectivement être appelé.
3. Corrigez au bon niveau. Pour un résultat transitif, la correction se situe généralement dans le paquet qui l'entraîne, ce que montre un graphe de dépendances.
4. Consignez ce que vous ne corrigerez pas. Un résultat que vous avez décidé d'accepter doit en préciser la raison, sinon la personne suivante refait le travail. VEX est la manière standard de le consigner.

Pourquoi un scan sans résultat ne signifie pas un logiciel sain

• Il voit ce qui est déclaré. Un scanner lit les fichiers qui se trouvent devant lui : un dépôt qui ne commite aucun lockfile lui donne donc peu de matière, et le code récupéré par un hook d'installation n'apparaît jamais.
• Il voit ce que vous lui montrez. L'image de base, les outils de build et les GitHub Actions de votre pipeline sont distincts du manifeste de votre application.
• Il ne connaît que ce qui est publié. Un nouveau paquet malveillant n'a pas encore d'avis de sécurité.
• La liste n'est pas le build. Les builds résolvent les versions au moment de leur exécution : ce que le scan a lu et ce que contient la release peuvent donc différer.

Ce sont des limites du scan lui-même, commercial ou open source. CRACI a trouvé des paquets vulnérables que Snyk et Aikido n'avaient pas signalés, parce que ces composants n'avaient jamais figuré dans ce qu'ils avaient scanné.

Scanners gratuits et commerciaux

Les options gratuites couvrent bien les bases. Les alertes Dependabot sont fournies avec GitHub, OWASP Dependency-Check et Trivy sont open source, et Grype s'associe au générateur de SBOM Syft. Les outils commerciaux ajoutent la politique, la priorisation, l'atteignabilité et le workflow à l'échelle de nombreuses équipes. Le comparatif des meilleurs outils SCA en couvre 13, et ce guide montre pourquoi les générateurs gratuits se contredisent.

Scan SCA et enregistrement au build

CRACI n'est pas un scanner, et vous n'avez pas à renoncer au vôtre. C'est un runner GitHub Actions qui enregistre chaque paquet récupéré par chaque job, à tous les niveaux de l'arbre, y compris les paquets restaurés depuis les caches CI, puis continue de réévaluer les SBOM de ce qui a été livré à mesure que de nouvelles vulnérabilités sont publiées. Votre scanner couvre les pull requests et les postes des développeurs. CRACI couvre le build et tout ce qui suit. Consultez la place de CRACI à côté de vos outils SCA.

Scan SCA : questions fréquentes

Qu'est-ce qu'un scan SCA ?

Un scan SCA lit les manifestes, les lockfiles ou l'image de conteneur d'un projet, détermine quels composants open source il utilise et les confronte aux données de vulnérabilité et de licence.

Le SCA est-il la même chose que le scan de dépendances ?

Presque. Le scan de dépendances consiste généralement à rechercher les vulnérabilités connues des dépendances. SCA est le terme le plus large et couvre aussi les licences, les paquets obsolètes et la production d'un inventaire tel qu'une SBOM.

Quand faut-il exécuter les scans SCA ?

Sur les pull requests, pour empêcher l'entrée de nouveaux risques ; dans le build CI, pour décrire la release ; et en continu après la release, car de nouveaux avis de sécurité touchent des logiciels déjà livrés.

Combien de temps dure un scan SCA ?

Généralement de quelques secondes à quelques minutes, car il lit des métadonnées au lieu d'analyser tout votre code. Il est donc réaliste de le lancer sur chaque pull request.

Pourquoi les scanners SCA donnent-ils des résultats différents ?

Chacun a ses propres règles sur ce qu'il faut lire, sur la façon de nommer les composants et sur les données de vulnérabilité à utiliser. Un même commit peut produire des listes de composants et des résultats différents.

Le scan SCA détecte-t-il les malwares ?

Le rapprochement avec les avis de sécurité ne détecte une release malveillante qu'une fois l'avis publié. Les outils qui analysent le comportement des paquets peuvent en repérer certaines plus tôt. Un nouveau paquet malveillant n'a aucun avis de sécurité le jour de son apparition.