Trois alertes de secrets n8n élevées passées en revue
Trois alertes n8n élevées montrent pourquoi la révision analysée et le contexte du code comptent avant de conclure à une fuite.
Au-delà de l’ASPM
Une AppSec fondée sur la preuve pour les équipes qui développent avec l’IA
Plexicus utilise AI Swarm Pentest pour explorer des chemins d’application autorisés, valider ce qui est exploitable et fournir les preuves nécessaires pour prioriser la remédiation.
Découvrir AI Swarm PentestLe 29 octobre 2026, nous avons examiné un ensemble de résultats Plexicus associé au dépôt n8n. Il contenait 110 alertes de secrets : trois classées élevées et 107 moyennes. Ce résumé pourrait passer pour une preuve de fuite d’identifiants. Les enregistrements détaillés ne permettaient pas cette conclusion.
Nous avons inspecté les trois alertes élevées et comparé leurs emplacements au code public de la révision immuable demandée. Deux emplacements désignent des constantes de nom d’identifiant dans des modules simulés. Le troisième ouvre une déclaration de type d’identifiant. Aucun de ces trois emplacements ne démontre un secret utilisable exposé. L’absence du commit réellement analysé empêche aussi de conclure définitivement à des faux positifs du scanner.
Ce que les enregistrements établissent
Les enregistrements portaient le titre « Use of Hard-coded Credentials ». Ils contenaient un chemin et une ligne, mais les champs de code, de rapport du scanner et de description étaient vides. Leur indicateur de faux positif était faux. Cet état enregistré du traitement ne prouve pas indépendamment l’existence d’un identifiant.
| Emplacement signalé | Code public de la révision demandée | Résultat de la revue |
|---|---|---|
| CredentialConfig.test.ts, ligne 1002 | Déclaration ICredentialType | Les métadonnées ne prouvent pas une valeur d’identifiant |
| Test de suppression de page Confluence, ligne 14 | CONFLUENCE_CREDENTIAL_NAME dans vi.mock | Le nom simulé ne prouve pas un secret utilisable |
| Test de suppression de pièce jointe Confluence, ligne 8 | Même type de constante simulée | La correspondance originale reste nécessaire |
Le test de configuration, le test de suppression de page et le test de suppression de pièce jointe sont des références publiques immuables. Nous publions uniquement les identifiants nécessaires à l’explication. Aucune valeur secrète, aucun identifiant privé de résultat ni aucune réponse brute de l’API ne figure ici.
La révision manquante limite le verdict
La fiche Open Source Explorer demandait 447fc866bb0a841decfa5e8a29fba06057bfc5bc. Nous avons récupéré les fichiers upstream à ce SHA précis. Mais les résultats ne désignaient ni leur exécution d’analyse ni leur commit réellement analysé. Les totaux d’un dépôt peuvent inclure des résultats provenant d’autres moments de son historique.
Quand les lignes changent, une déclaration anodine dans la révision demandée ne prouve pas ce que le scanner a rencontré auparavant. Une gravité élevée ne remplace pas ces éléments manquants. Le constat limité est donc que ces trois résultats et leur contexte n’établissent aucune exposition d’identifiants. Cela ne démontre ni l’absence générale de secrets dans n8n ni l’inexactitude de toutes les alertes.
Modèle original de revue. Le schéma présente les preuves nécessaires, pas une fuite reproduite.
Un test fournit du contexte
De vrais identifiants peuvent apparaître dans des tests, exemples et fixtures. Exclure systématiquement ces répertoires pourrait masquer de véritables fuites. Il faut établir le rôle de la valeur : authentification, nom de type, marqueur synthétique ou référence à un autre objet.
Les deux emplacements Confluence affectent une constante de nom dans un module simulé et remplacent la fonction d’API par un double de test. Le troisième commence un objet de configuration typé. Il faut obtenir la correspondance originale et l’explication de la règle avant de demander une rotation ou d’annoncer un incident.
Si des preuves ultérieures établissent un vrai identifiant, nettoyez le rapport public et suivez la procédure de révocation du fournisseur. Nous n’avons tenté aucune authentification avec une valeur et n’avons envoyé aucun identifiant candidat à un service externe.
Garder les preuves avec la décision
Conservez les versions du scanner et de la règle, le commit analysé, la plage de code, la correspondance expurgée, la catégorie d’identifiant et le raisonnement du réviseur. Désignez un responsable de correction. Une vérification bloquée ou un contenu absent reste non résolu.
Notre approche Proof-Driven AppSec relie l’alerte à un résultat examinable. Le guide de remédiation explique le passage à une modification revue. Deep Code Analysis traite du contexte.
Plexicus fournit les métadonnées examinées. L’inspection du code relève ici d’une enquête éditoriale, pas d’une décision automatique du produit que nous aurions démontrée. La remédiation et AI Swarm Pentest décrivent d’autres périmètres de travail ; ils ne confirment pas ces alertes comme des fuites.
Compléter le dossier
Demandez la correspondance originale et la véritable révision analysée. Réconciliez les lignes avant de confirmer ou rejeter les alertes. Les liens immuables et cette conclusion limitée permettront à un autre analyste de poursuivre. Cette revue n’établit ni correctif n8n, ni révocation, ni exploitation réussie.
Sources
Besoin de transformer les alertes en décision d’ingénierie ? Contactez Plexicus avec la révision du dépôt et des preuves expurgées.
