SDLC : bonnes pratiques pour un développement sécurisé

Par:
ftonic

mer, 17/08/2022 - 12:30

SDLC, SDL, SSDLC, nous parlons de la même chose : faire un développement logiciel sécurisé et intégration la sécurité dans le cycle de développement. Adaptez cette approche, c’est éviter les mauvaises surprises en déploiement et en production. Aujourd’hui, nous parlerons plutôt de secure by design (sécurité par conception). Basiquement, Il s’agit d’avoir un niveau de sécurité, trouver les failles / vulnérabilités / bugs le plus tôt possible et gagner du temps, conformité avec les réglementations, réduire l’écart entre l’infosec et la sécurité dans les apps.

Les recommandations s’appliquent à tous les langages et à tous les dévs. Certaines recoupent le  TOP 10 de l’OWASP. Il n’existe pas un mais de nombreux Secure Coding Guidelines. Chacun adapte comme il le veut.  

Les 10 recommandations de base peuvent se résumer ainsi :

1 valider les entrées : c’est le minimum que tout développeur doit faire. Autoriser uniquement les chaines autorisées. Quand le champ est un champ date, on peut saisir qu’une date à un format strictement défini. 

2 tenir compte des warnings des compilateurs : les avertissements du compilateur peuvent servirent. Ne pas hésiter à introspecter le code pour comprendre le warning et le réduire.

3 créer des pratiques d’architectures pour inclure la sécurité : les langages, les plateformes (ex. : cloud public) proposent des bonnes pratiques de sécurité et des recommandations. 

4 faire simple : éviter la complexité. Pourquoi faire compliquer quand on peut faire simple ?

5 accès refusé par défaut : si un accès est refusé par défaut ne contournez pas la gestion des accès. Autorisez uniquement ce qui est autorisé par défaut

respecter et appliquer le principe du moindre privilège : là encore, ne passez pas outre les privilèges. N’imposez pas une élévation des privilègesToute modification des accès doit être encadrée 

7 toutes les données doivent être nettoyées et saines avant d’être envoyés à d’autres apps ou systèmes

8 défense profonde : la sécurité, et particulièrement le secure by design, se fait à plusieurs niveaux. La défense profonde se pense et s’applique à tous les éléments de votre environnement et de l’app. 

9 utiliser des pratiques de qualité : les bonnes pratiques et les règles de codage sont les bases du secure by design pour réduire la surface d’attaque et réduire au maximum les failles communes

10 bref : adopter les pratiques d’une programmation sécurisée par défaut !

Ces pratiques permettent de réduire certaines failles de l’OWASP.

A cela, nous pourrions rajouter :

- Bonne implémentation et gestion de l’authentification / identification : par exemple, on évite de laisser en clair des clés ou les données de connexion (et ne me dites que vous ne l’avez jamais fait)

- Crypter les données et chiffrer les sessions réseaux quand cela est nécessaire

- Gérer les exceptions (oui, oui, c’est toujours d’actualité)

- N’oubliez pas les logs

- Etre à jour dans les outils, les libs, les frameworks, les serveurs

- Nettoyer votre code : un code propre et bien structuré évite la confusion et les effets de bords

Bref, nous ne réinventons rien du tout. Il s’agit avant tout de bon sens et de bonnes pratiques au quotidien. Globalement, nous trouvons souvent des pratiques communes quel que soit le langage. Nous vous proposons quelques réflexions par langage. 

Java :

  • Utiliser uniquement des libs éprouvées et actives
  • Toujours chiffrer les données critiques et les hasher
  • Filtrer les données
  • Gérer les logs et les exceptions
  • Prévenir les injections

 C# :

  • Ne pas utiliser du code partiellement sécurité / vérifié (partiel trusted code
  • Ne pas utiliser remote .Net
  • Ne pas utiliser DCOM

RUST :

  • Utiliser une toolchain stable
  • Vérifier les dépendances et les versions des dépendances
  • Vérifier tout le code unsafe et retirer le
  • Respecter les conventions de noms
  • Utiliser type error

Angular :

  • Utiliser CSP
  • Prévenir le XSS et le XSSI
  • Etre à jour
  • Charger des templates de manière sécurisée

Flutter :

  • Etre à jour
  • Obfuscation du code
  • Sécuriser les clés API
  • Réduire et contrôle les flux réseaux
  • Limiter les permissions
  • Utiliser l’authentification du terminal

PHP :

  • Etre à jour
  • Eviter de charger les fichiers des frameworks côté serveur
  • Valider les entrées utilisateurs
  • Limiter les accès aux répertoires
  • Vérifier la configuration SSL
  • Coder les URL
  • Refuser l’ajout des fichiers venant des utilisateurs

Python :

  • Toujours nettoyer et sécuriser les données externes
  • Scanner et inspecter le code
  • Prudence quand vous chargez des packages
  • Vérifier les dépendances
  • Mettre à jour la version de Python
  • DEBUG=FALSE en production !
  • Prudence sur le formatage des string
  • Désérialiser avec prudence
  • Limiter les privilèges

Go :

  • Utiliser des modules GO officiels
  • Scanner les dépendances
  • Utiliser les packages crypto standard
  • Utiliser avec prudence la reflection
  • Etre à jour

A découvrir dans le hors série 100 % sécurité & développeur disponible dès le 9 septembre !

Une source à lire : https://wiki.sei.cmu.edu/confluence/display/seccode/Top+10+Secure+Coding+Practices