Dépendances, journalisation et processus
La sécurité n'est pas un contrôle unique. Ces points concernent le code que vous n'avez pas écrit (vos dépendances) et les habitudes qui maintiennent une application sûre après la mise en production.
Liste de contrôle
- Figez et analysez les dépendances. Commitez un fichier de verrouillage (lockfile) et lancez un scanner de vulnérabilités (ainsi que l'audit de votre plateforme) dans la CI. Mettez à jour les paquets connus comme vulnérables.
- Surveillez les paquets hallucinés. Les outils d'IA importent parfois un paquet qui n'existe pas ; les attaquants enregistrent ces noms avec des logiciels malveillants (« slopsquatting »). Vérifiez que chaque dépendance est bien la bonne, réelle et prévue, avant de l'installer.
- N'exécutez pas aveuglément du code ou des étapes de compilation non fiables. Un dépôt téléchargé ou un script postinstall généré peut exécuter du code arbitraire. Relisez avant de lancer.
- Journalisez les événements de sécurité, pas les secrets. Enregistrez les connexions, les échecs, les déclenchements de limite de débit et les actions d'administrateur à des fins d'audit. Ne journalisez jamais les mots de passe, les jetons, les clés ou les numéros de carte complets.
- Gérez les erreurs sans rien divulguer. Interceptez les exceptions, renvoyez un message générique, et ne conservez les traces de pile et les requêtes que dans les journaux serveur.
- Maintenez une analyse statique dans la CI. Des outils comme Semgrep détectent les erreurs d'injection et d'autorisation avant leur fusion.
- Testez comme un attaquant. Votre suite de tests doit inclure des cas de données invalides et d'accès non autorisé, et pas seulement le scénario nominal. Une fois la suite réussie, lancez un scanner en boîte noire (par exemple OWASP ZAP) sur l'URL déployée.
- Faites appel à une revue indépendante. Un audit interne passe à côté de certaines failles, surtout les angles morts de l'auteur. Avant un lancement plus large, faites réaliser un test d'intrusion externe, et envisagez de vous aligner sur une norme comme OWASP ASVS.
- Pour les fonctionnalités d'IA, testez la couche du modèle. Si votre application place du contenu non fiable dans un prompt, soumettez-la à un exercice de red team pour détecter les injections de prompt et les fuites de données entre utilisateurs ou locataires. La sécurité réelle reste dans le code (limitez chaque outil et chaque requête à l'utilisateur courant), jamais dans les consignes du prompt.
- Prévoyez un plan de retour arrière. Conservez des sauvegardes dont vous avez réellement testé la restauration, ainsi qu'un plan de rotation des secrets et de révocation des sessions en cas de fuite.
Comment tester
- Lancez votre audit de dépendances et un scan de secrets dans la CI, et lisez les résultats.
- Pointez un scanner en boîte noire sur l'environnement de préproduction.
- Demandez à quelqu'un qui n'a pas écrit le code d'essayer de le casser.