Au niveau du produit lui-même
Langages non sûrs pour la mémoire (C, C++, etc.)
Utilisez autant que possible des langages sûrs pour la mémoire, et remplacez progressivement les programmes existants qui ne le sont pas d’ici fin 2025.
Exécution directe de commandes SQL
Utilisez des requêtes paramétrées, des instructions préparées ou un ORM.
Exécution directe de commandes du système d’exploitation
Les entrées utilisateur ne doivent pas constituer la commande elle-même. Au lieu d’exécuter directement une commande, utilisez des fonctions de bibliothèque intégrées ou limitez les entrées aux lettres latines, chiffres et traits de soulignement.
Utilisation de mots de passe trop connus
Il faut faire en sorte de les éviter autant que possible, par exemple de la façon suivante :
- Fournir dès le départ un mot de passe unique.
- Exiger que l’utilisateur crée un mot de passe fort pendant l’installation.
- Définir une limite de temps sur le mot de passe, comme avec la MFA.
- Exiger un accès physique pour obtenir des identifiants fiables.
- Mener des campagnes ou migrer vers des méthodes d’authentification plus sûres.
Laisser en place des vulnérabilités connues
Les vulnérabilités figurant sur cette page doivent être évitées dans leur totalité. Lorsqu’une nouvelle vulnérabilité est signalée, elle doit être corrigée en temps voulu, et il faut avertir les utilisateurs qui ne mettent pas à jour vers une version corrigée.
Bibliothèques open source vulnérables
Il faut signaler le problème de manière responsable aux bibliothèques utilisées et y contribuer. Cela inclut aussi les mesures suivantes :
- Rédiger un SBOM : il montre quelles bibliothèques le logiciel utilise.
- Mesures à appliquer aux bibliothèques open source dont vous dépendez
- Effectuer des audits de sécurité.
- Choisir des projets de qualité, pérennes, bien protégés et bien maintenus. Il est également recommandé de respecter ces principes de sécurité.
- Vérifier en continu s’il existe des vulnérabilités connues.
- Le fournisseur doit disposer à l’avance d’une copie, et il ne faut pas mettre à jour depuis des sources non vérifiées.
- Il faut prendre en compte le coût des mises à jour vers une nouvelle version majeure ou de l’application de correctifs de sécurité.
Si une vulnérabilité n’affecte pas le produit, il faut expliquer publiquement pourquoi elle ne l’affecte pas.
Algorithmes cryptographiques vulnérables ou inconnus (TLS 1.0/1.1, DES, MD5, etc.)
Il faut utiliser des algorithmes récents. En outre, il faut se préparer à utiliser des algorithmes cryptographiques post-quantiques standardisés conformément aux directives du NIST.
Clés secrètes présentes dans le code source
Il faut utiliser un gestionnaire de secrets (Secret Manager) pour permettre au programme de récupérer les clés secrètes en toute sécurité. Il faut aussi vérifier si des clés secrètes sont présentes dans le code source.
Au niveau des fonctions de sécurité
Absence de prise en charge de la MFA (y compris lorsqu’on ne prend en charge que les passkeys)
Sauf pour les situations où le moindre délai est dangereux, comme les dispositifs médicaux d’urgence, il faut par défaut implémenter la MFA directement ou permettre l’usage d’un authentificateur externe. Cela doit être exigé des administrateurs, et les administrateurs doivent à leur tour l’exiger des utilisateurs de l’organisation.
Absence de preuves d’intrusion
- En tant que fonctionnalité très basique, il faut générer des journaux liés aux modifications ou consultations de configuration, à l’historique de connexion et à l’accès aux informations.
- Dans le cas d’un fournisseur cloud, ces journaux doivent être conservés pendant au moins 6 mois et rendus visibles à l’utilisateur, sans coût supplémentaire.
Au niveau des processus et politiques de l’organisation
Absence de publication de CVE
Les vulnérabilités critiques ou susceptibles d’avoir un impact important doivent être rendues publiques immédiatement.
Absence de politique de divulgation des vulnérabilités (VDP)
Il faut publier une politique incluant les éléments suivants :
- Autorisation des tests par le grand public
- Engagement à ne pas engager de poursuites contre les personnes agissant de bonne foi
- Canal de signalement clair
- Bonnes pratiques CVD (Coordinated Vulnerability Disclosure) et normes internationales
Les vulnérabilités signalées doivent être corrigées en temps voulu, par ordre de criticité.
(Dans le cas de l’on-premise) période de support non claire
Il faut communiquer clairement la période de support et fournir des mises à jour de sécurité pendant toute sa durée.
- Exploit en un clic dans KakaoTalk
- GN⁺ : le NIST (Institut national des normes et de la technologie des États-Unis) interdit d’exiger une composition spécifique de caractères dans les mots de passe
- La Maison-Blanche appelle les développeurs à éviter le C et le C++ et à utiliser des langages « memory-safe »
- Pirater ma voiture : Hyundai Ioniq : découverte dans le code source d’un texte chiffré RSA trouvable via Google
7 commentaires
La sécurité, c’est le genre de truc où ça dérape en une seconde… ! (j’ai l’impression d’avoir déjà vu cette expression à l’armée)
Il faut garder l'esprit !
On dirait que ça reparle de ne plus utiliser les ORM...
Il suffit d’utiliser des prepared statements au lieu d’un ORM.
zzz
Il y a toujours des principes, c’est juste difficile de les respecter...
J’aime, je suis d’accord
Exiger des utilisateurs qu’ils créent des mots de passe robustes != imposer la présence de caractères spéciaux, de majuscules et minuscules, et de chiffres
Un mot de passe est robuste dès lors qu’il est simplement suffisamment long.