Tu utilises un agent de programmation, un dépôt GitHub ou simplement quelques dépendances npm dans un projet maison ? Ship Safe 9.7 mérite ton attention pour une raison très concrète : l’outil ne décide plus qu’un pipeline est acceptable à partir d’une note moyenne. Depuis sa mise à jour publiée le 5 août, une seule alerte critique peut bloquer la livraison. Ce n’est pas une révolution de laboratoire, c’est un changement de feu tricolore qui peut surprendre dès le prochain lancement automatique.
Ship Safe est un scanner open source lancé localement avec npx. Il inspecte les secrets, les dépendances, les fichiers de configuration, les pipelines et les réglages d’agents IA. Son intérêt dépasse donc le développeur professionnel : si tu fais générer du code par un assistant, si tu héberges un petit service ou si tu publies une application, il peut servir de deuxième paire d’yeux avant la mise en ligne. La limite, évidemment, est qu’un scanner ne comprend pas parfaitement ton projet et peut encore se tromper.
Le score ne décide plus à ta place
Avant la version 9.7, la commande ci pouvait échouer quand le score global passait sous un seuil, par exemple 75. Le problème est classique : une note agrégée peut masquer une alerte grave au milieu d’une longue liste de problèmes moyens. Ship Safe explique que son score finissait par plafonner sur les gros dépôts, au point de donner la même impression à un projet avec quelques dizaines de constats et à un autre beaucoup plus bruyant.
La nouvelle règle est plus lisible : par défaut, ci échoue dès qu’une alerte critique est détectée. Tu peux demander un seuil plus sévère avec --fail-on high, désactiver le blocage avec --fail-on none ou conserver l’ancien comportement avec --threshold 75. Le réglage n’est pas anodin : un pipeline qui passait hier peut donc s’arrêter aujourd’hui sans que ton code ait changé. Avant de paniquer, relance un audit et lis la première alerte au lieu de regarder uniquement la couleur du score.
Visuel : démonstration officielle de l’audit Ship Safe dans le terminal. Source : dépôt GitHub du projet, https://github.com/asamassekou10/ship-safe/blob/main/.github/assets/demo-repl.gif
Un contrôle qui reste local par défaut
La promesse la plus utile de Ship Safe tient en une option : --no-ai. Les agents de vérification, les contrôles de dépendances, la génération du rapport et l’évaluation des règles peuvent fonctionner sur ta machine sans appeler un modèle distant. C’est important si le dépôt contient des informations privées, des fichiers de configuration ou des données de clients. Le projet précise aussi que l’analyse locale ne demande ni compte ni clé API.
Attention au détail qui change tout : les fonctions d’analyse avec un fournisseur d’IA ne sont pas équivalentes au mode local. La classification, l’analyse approfondie et le mode red-team peuvent transmettre des extraits bornés au fournisseur que tu as choisi. Le site officiel décrit le masquage de certains secrets, mais reconnaît que ce filtrage n’est pas une garantie absolue. Si le code ne doit vraiment pas sortir de la machine, utilise --no-ai et vérifie les fichiers générés dans .ship-safe avant de les versionner.
Des règles pour les agents, pas une baguette magique
La version 9.7 corrige aussi plusieurs faux positifs. Des règles qui repéraient mal certains appels, des adresses de confidentialité ou des séquences Unicode ont été recalibrées. Les téléchargements de modèles sans version immuable ni somme de contrôle sont désormais mieux signalés, tout comme certains contournements de listes autorisées pour les outils MCP. Pour un utilisateur, la traduction est simple : le rapport devrait contenir moins de bruit et mieux séparer une faille potentielle d’un simple morceau de texte qui lui ressemble.
Mais le projet documente ses limites. Le score reste un indicateur, pas une certification. Une analyse automatique ne sait pas toujours si une route est réellement accessible, si une dépendance est volontaire ou si une alerte est compensée par une protection ailleurs. Utilise le rapport pour prioriser une vérification humaine, pas pour coller un autocollant « sécurisé » sur ton application et retourner dormir.
Le réglage à vérifier aujourd’hui
Si Ship Safe est déjà installé dans ton pipeline, regarde la commande ci avant la prochaine livraison. Cherche un --threshold existant, ajoute-le explicitement si tu veux conserver le comportement précédent et teste ensuite le nouveau mode par gravité dans une branche. Si tu découvres une alerte critique, ne la supprime pas mécaniquement : vérifie le fichier concerné, la preuve affichée et la possibilité d’un faux positif documenté.
Pour une petite application personnelle, un audit ponctuel avec npx ship-safe audit . --no-ai suffit déjà à repérer des secrets oubliés, une configuration Docker trop permissive ou une dépendance douteuse. Pour un projet plus sérieux, exporte le résultat en SARIF et fais relire les changements par quelqu’un qui connaît le contexte. Le meilleur outil de sécurité est celui qui déclenche une discussion avant la mise en production, pas celui qui distribue des notes rassurantes après la casse.
Ship Safe 9.7 ne rend pas les pipelines plus intelligents par magie : il les rend plus francs. Une faille critique ne se cache plus derrière une moyenne flatteuse, et le mode local permet de commencer sans envoyer ton code dans un nuage quelconque. Vérifie simplement la nouvelle règle avant qu’elle ne vérifie ton projet à ta place : le bouton rouge, lui, ne lit pas les excuses.
Sources
Ship Safe, publication officielle de la version 9.7.0 et changement de règle pour ci, 5 août 2026 : https://github.com/asamassekou10/ship-safe/releases/tag/v9.7.0
Ship Safe, dépôt officiel et documentation des fonctions du scanner open source : https://github.com/asamassekou10/ship-safe
Ship Safe, page officielle sur la sécurité et les flux de données entre analyse locale et fournisseurs IA : https://shipsafecli.com/security
Ship Safe, site officiel et présentation des agents, du mode local et de l’intégration CI : https://shipsafecli.com
—
Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.
No comments yet