Les scans de sécurité peuvent désormais tourner sur ce nœud
v0.33.0-beta
- Les scans de sécurité peuvent désormais tourner sur ce nœud. L'agent accepte une nouvelle commande de scan et sait exécuter Trivy sur une image ou Semgrep sur le code d'un dépôt, à la demande du hub. Jusqu'ici ces analyses tournaient toutes sur le serveur qui sert vos pages : les sortir de là libère du processeur au moment précis où elles en consommaient le plus. Le rapport est renvoyé tel quel, sans interprétation : c'est le hub qui décide de ce qui est une vulnérabilité, jamais la machine qui exécute le scan.
- L'agent annonce s'il sait scanner. À la connexion, il indique au hub la présence de Trivy et de Semgrep, au même titre que Docker et buildx. Un nœud qui n'a pas l'outil n'est simplement jamais choisi pour ce scan ; installez-le et il sera pris en compte à la reconnexion suivante, sans redémarrer l'agent.
- Un rapport volumineux arrive entier, ou pas du tout. Les rapports de vulnérabilités dépassent régulièrement plusieurs mégaoctets, au-delà de ce qu'une trame accepte. L'agent les compresse automatiquement au-dessus de 256 Ko, ce qui les divise typiquement par dix. Si un rapport reste malgré tout trop volumineux, l'agent le signale explicitement au lieu de le tronquer : un rapport de sécurité amputé de la moitié de ses résultats se lit comme un rapport propre, ce qui est pire qu'un scan manquant.
- Rien ne reste sur la machine après un scan. Le dépôt cloné pour Semgrep est effacé en fin d'analyse, que celle-ci réussisse ou échoue, y compris quand le clone lui-même a échoué. L'identifiant de connexion au registre, quand l'image à analyser est privée, est confiné à un dossier temporaire effacé aussitôt après, et ne passe jamais par la ligne de commande où la liste des processus de la machine l'exposerait. Le jeton d'accès au dépôt n'apparaît dans aucun journal ni aucun message d'erreur.
- Les scans respectent les mêmes plafonds que les builds. Un scan est refusé proprement quand il ferait passer la machine sous sa réserve d'espace disque, exactement comme un build : le hub confie alors l'analyse à une autre machine. L'analyse de code applique par ailleurs les limites de mémoire et de cœurs du nœud, et l'analyse d'image borne sa mémoire de la même façon. Sans ça, un dépôt volumineux pouvait épuiser la mémoire d'un NAS ou d'un PC partagé et emporter avec lui ce qui tournait à côté.
- Un scan interrompu le dit. Si l'agent s'arrête au milieu d'une analyse, le message remonté indique qu'il s'agit d'un redémarrage de la plateforme, et non d'un défaut du code analysé.