OWASP Non-Human Identities Top 10 2025 : les identités qui n’ont pas de visage

C’est le Top 10 le moins connu de l’OWASP et l’un des plus directement actionnables. Son objet : les identités non humaines — comptes de service, clés d’interface de programmation, jetons, certificats, identités de charges de travail — c’est-à-dire la population qui, dans un système d’information moderne, dépasse de loin celle des humains et ne reçoit presque jamais la même attention. Publié en 2025, il classe dix risques codés NHI1 à NHI10, ordonnés selon l’exploitabilité, la prévalence, la détectabilité et l’impact.

→ Lire l’explication complète de la marmotte

Les dix risques de l’édition 2025

Code	Titre officiel	Traduction
NHI1:2025	Improper Offboarding	Désactivation incorrecte en fin de vie
NHI2:2025	Secret Leakage	Fuite de secrets
NHI3:2025	Vulnerable Third-Party NHI	Identité non humaine tierce vulnérable
NHI4:2025	Insecure Authentication	Authentification non sécurisée
NHI5:2025	Overprivileged NHI	Identité non humaine surprivilégiée
NHI6:2025	Insecure Cloud Deployment Configurations	Configurations de déploiement cloud non sécurisées
NHI7:2025	Long-Lived Secrets	Secrets à longue durée de vie
NHI8:2025	Environment Isolation	Isolation des environnements
NHI9:2025	NHI Reuse	Réutilisation d’identité non humaine
NHI10:2025	Human Use of NHI	Usage humain d’une identité non humaine

NHI1 en tête : ce qui ne part jamais

La première place va à la désactivation manquée : des identités non humaines — comptes de service, clés d’accès — ne sont pas désactivées ou supprimées quand elles cessent d’être nécessaires. Le référentiel ajoute la précision qui fait la gravité : les services dépréciés et non surveillés peuvent rester vulnérables, et les identités qui leur sont associées restent exploitables pour atteindre des systèmes et des données sensibles.

Le choix de cette entrée en première position est un bon diagnostic du terrain. La création d’une identité machine est triviale et distribuée : n’importe quel développeur génère une clé pour faire marcher une intégration. Sa suppression n’est la responsabilité de personne, elle ne déclenche aucun processus, et elle n’a aucune date. Un humain qui quitte l’entreprise sort d’un annuaire ; un script qui n’a plus d’objet continue d’exister jusqu’à ce que quelqu’un se demande à quoi il sert, c’est-à-dire jamais. Le site traite ce mécanisme dans les comptes de service Git, identités jamais révoquées et les comptes orphelins.

Deux entrées sur la durée de vie, et elles ne disent pas la même chose

NHI7, les secrets à longue durée de vie, vise les clés, jetons, clés de chiffrement et certificats dont la date d’expiration est trop lointaine ou inexistante. L’argument du référentiel est d’une simplicité désarmante : si un secret compromis est à longue durée de vie, il donne à l’attaquant un accès sans aucune contrainte de temps. La compromission n’est donc pas un événement mais un état, et sa durée est un paramètre qu’on choisit à la création.

NHI9, la réutilisation, vise un autre axe : employer la même identité pour plusieurs applications, services ou composants, même déployés ensemble. Une identité réutilisée transforme une compromission locale en accès à tout ce qui partage l’identifiant, et elle détruit au passage la traçabilité — les journaux montrent une action, pas le composant qui l’a faite.

NHI8, l’isolation des environnements, est la variante la plus coûteuse de NHI9 : réutiliser les mêmes identités entre développement, test, préproduction et production. Le référentiel insiste sur le couple test/production, et pour cause : l’environnement de test est celui dont les accès sont les plus larges, les journaux les plus pauvres et les mots de passe les plus partagés. Une identité commune entre les deux est une passerelle que l’architecture n’a pas prévue.

Les contre-mesures relèvent du cycle de vie des secrets : le coffre à secrets et l’enregistrement des accès, l’architecture de gestion de secrets distribuée et le cycle de vie des jetons.

NHI2 et NHI4 : les deux entrées qu’on croit connaître

NHI2, la fuite de secrets, vise la sortie d’identifiants sensibles vers des espaces de stockage non prévus, tout au long du cycle de développement. Le référentiel en donne trois exemples précis, et l’ordre n’est pas innocent : codés en dur dans le code source, stockés en clair dans des fichiers de configuration, envoyés sur des applications de discussion publiques. Le troisième est le plus fréquent et le moins outillé : on détecte un secret dans un dépôt, on ne le détecte pas dans une conversation d’équipe, où il reste indexé et consultable par tout nouvel arrivant. La prévention des secrets dans le code source couvre le premier cas.

NHI4, l’authentification non sécurisée, ne parle pas de mots de passe faibles mais de méthodes dépréciées. Les développeurs intègrent des services internes et externes, ces services exigent une authentification, et certaines des méthodes proposées sont obsolètes, vulnérables à des attaques connues ou considérées comme faibles au regard des pratiques actuelles. Le piège est que ces méthodes continuent de fonctionner : rien n’alerte, la connexion réussit, et le service tiers les propose encore dans sa documentation parce que retirer une méthode d’authentification casse des clients. L’inventaire à tenir n’est donc pas celui des identités mais celui des mécanismes par lesquels elles s’authentifient.

NHI6 : OIDC vaut mieux qu’une clé statique, à condition de valider les revendications

Cette entrée mérite d’être lue en détail parce qu’elle corrige une idée reçue. Les chaînes d’intégration et de déploiement continus doivent s’authentifier auprès des services cloud, et deux méthodes existent : des identifiants statiques, ou le protocole OpenID Connect. Les identifiants statiques peuvent fuir par un dépôt, un journal ou un fichier de configuration, et s’ils sont compromis ils offrent un accès persistant et souvent privilégié à la production. OIDC est la meilleure option — et le référentiel ne s’arrête pas là.

Si les jetons d’identité ne sont pas validés correctement, ou s’il n’y a pas de conditions strictes sur leurs revendications, des utilisateurs non autorisés peuvent exploiter ces faiblesses pour obtenir l’accès. C’est le piège exact de la configuration en vigueur dans beaucoup d’organisations : une relation de confiance établie avec le fournisseur d’identité de la forge, sans restriction sur le dépôt, la branche ou l’environnement qui demande le jeton. N’importe quel dépôt de la forge peut alors réclamer le rôle. Migrer d’une clé statique vers OIDC sans resserrer les conditions des revendications déplace le problème sans le réduire — et le déplace vers un mécanisme que l’équipe comprend moins bien. Les identifiants de chaîne d’intégration traitent ce point.

NHI10 : l’humain qui emprunte l’identité de la machine

La dernière entrée de la liste est la plus humaine, et c’est peut-être la plus répandue. Pendant le développement et la maintenance, des développeurs ou des administrateurs se servent d’une identité non humaine pour des tâches manuelles qui devraient passer par leur identité personnelle, avec les privilèges appropriés.

Le référentiel nomme les deux conséquences, et la seconde est la pire. La première est l’élévation de privilège : l’identité machine est souvent plus puissante que celle de la personne, puisqu’elle a été dimensionnée pour un automatisme. La seconde est l’absence d’audit et de responsabilité, l’activité humaine devenant indistinguable de l’automatisme. C’est le point de bascule : à partir de là, aucune détection comportementale ne fonctionne, puisqu’il n’y a plus de comportement de référence. Une identité machine utilisée par des humains a, par construction, un profil d’activité erratique — ce qui est exactement le signal qu’on voulait surveiller.

NHI3 et NHI5 : le tiers et le privilège

NHI3 porte sur les identités non humaines tierces, massivement intégrées au flux de développement : extensions d’environnement de développement, services externes en mode logiciel à la demande. Si une extension tierce est compromise — par une vulnérabilité ou par une mise à jour malveillante —, elle peut servir à voler les identifiants locaux ou à abuser des permissions accordées. C’est le même mécanisme que l’abus de chaîne de dépendances, appliqué aux droits plutôt qu’au code.

NHI5 porte sur le surprivilège, et son intérêt est d’être l’entrée qui amplifie toutes les autres. Une identité surprivilégiée ne cause aucun incident par elle-même ; elle décide seulement de l’ampleur du prochain. Les causes sont connues : un rôle copié d’un autre service, un caractère générique posé pour débloquer une livraison, l’absence de mécanisme qui réduise un privilège une fois l’urgence passée. L’accès juste-à-temps et les modèles de contrôle d’accès couvrent les contre-mesures.

Pourquoi cette liste compte à côté des référentiels agentiques

Voici l’articulation que peu de documents posent, et qui rend ce référentiel particulièrement utile aujourd’hui : un agent d’intelligence artificielle est une identité non humaine. Il s’authentifie, il détient des secrets, il reçoit des privilèges, il agit au nom de quelqu’un, et il ne part jamais en retraite.

Les dix entrées s’y appliquent donc directement, et plusieurs s’y appliquent en pire. NHI5, le surprivilège, rencontre un acteur qui décide seul de l’outil qu’il appelle. NHI9, la réutilisation, rencontre une flotte d’agents qui partagent souvent un même jeton de service. NHI10, l’usage humain d’une identité machine, rencontre sa symétrie exacte — l’agent qui agit sous l’identité d’un humain, ce qui pose la même question d’audit dans l’autre sens. Le Top 10 des applications agentiques traite cette question en propre sous le code ASI03, l’abus d’identité et de privilèges, et renvoie explicitement au présent référentiel. Le site traite le sujet dans les identités des agents logiciels.

Un mot sur la maturité, puisque c’est la règle de la famille : le projet est classé Incubator par l’OWASP, le niveau le plus bas de ses quatre paliers, et son classement repose sur le jugement de son équipe plutôt que sur des données mesurées. Il porte en revanche une ambition que les autres n’ont pas — fournir, en plus de la description des risques, des pratiques de prévention et des scénarios de réponse à incident. La façon de citer ces documents est traitée dans la page chapeau des Top 10 de l’OWASP. Et comme pour les autres : ce n’est pas une norme, et pour l’articulation avec une obligation réelle, c’est la rubrique Normes qui porte le sujet.

🐝 Ce qui arrive si on s’en passe

Sans processus de fin de vie pour les identités machines, une clé créée pour une migration terminée depuis des années reste valide : le service qu’elle servait n’est plus mis à jour, plus personne ne le surveille, et il reste le chemin le plus court vers les données. Sans date d’expiration sur les secrets, une compromission cesse d’être un événement pour devenir un état permanent, et sa détection ne change rien tant que le secret n’est pas révoqué. Sans identité distincte par composant, un conteneur périphérique compromis ouvre tout ce qui partage son jeton, et les journaux montrent une action sans dire qui l’a faite. Sans conditions strictes sur les revendications d’un jeton OIDC, n’importe quel dépôt de la forge obtient le rôle de production, et la migration qui devait supprimer les clés statiques a élargi la surface. Sans interdiction de l’usage humain des identités machines, l’activité d’une personne devient indistinguable de celle d’un automatisme : il n’existe plus de comportement de référence, donc plus aucune anomalie à détecter.

🦫 Explication de la marmotte 🍫

Dans un système informatique, les humains ne sont pas les seuls à s’identifier. Les programmes le font aussi : un script de sauvegarde, une chaîne de fabrication logicielle, un service qui interroge un autre service. Chacun possède une sorte de carte d’identité — une clé, un jeton, un certificat — et ces identités sont aujourd’hui beaucoup plus nombreuses que celles des personnes. Une association internationale de spécialistes publie depuis 2025 la liste des dix problèmes de sécurité les plus courants à leur sujet.

Le premier problème de la liste est aussi le plus simple : ces identités ne sont jamais supprimées. Quand une personne quitte l’entreprise, une procédure ferme son compte. Quand un programme cesse d’être utile, rien ne se passe : sa clé reste valide, et le programme lui-même n’est plus mis à jour. Il devient une porte ouverte que personne ne regarde.

D’autres problèmes concernent la durée : une clé sans date d’expiration donne à qui la vole un accès sans limite de temps. La réutilisation : la même clé employée par plusieurs programmes fait qu’une seule intrusion ouvre tout, et qu’on ne peut plus savoir lequel a agi. Et le mélange : employer les mêmes clés pour les environnements de test et pour le vrai service crée un passage entre les deux.

Un problème est plus inattendu. Il arrive qu’une personne utilise la clé d’un programme pour faire une tâche à la main, parce que c’est plus pratique et que cette clé a plus de droits. L’activité humaine devient alors impossible à distinguer de l’activité automatique, et toute surveillance basée sur les habitudes cesse de fonctionner.

Enfin, un point d’actualité : un assistant d’intelligence artificielle capable d’agir est, pour un système informatique, exactement une identité de ce genre. Il s’authentifie, détient des secrets, reçoit des droits, et il ne prend jamais sa retraite.

Pages voisines

La citent

OWASP Non-Human Identities Top 10 2025 : les identités qui n'ont pas de visage

Elle cite

: les deux pages se citent l’une l’autre.