Sécurité des applications : ne négligez plus la qualité de vos processus de développement

Les applications devraient toujours être élaborées avec la sécurité bien en tête, tout au long des différents cycles de développement. Ce n’est pourtant pas toujours le cas. Beaucoup d’entreprises ont encore tendance à se contenter des audits, à relever les failles les plus communes dans les applications (injection, failles XSS, …), ou à se reposer sur l’utilisation d’outils génériques tels que les firewalls web. Ces pratiques ne sont plus suffisantes alors que les attaques sur les applications sont de plus en plus ciblées. Pour y remédier, l’aspect sécurité devrait davantage être intégré dans les processus de développement. Voici cinq démarches que vous pourriez entreprendre.

 

1. La pratique des tests automatisés

On parlera notamment de test-driven development (TDD). Cette technique va inciter les développeurs à créer une batterie de tests pour l’application, de manière à ce que le maximum de code soit testé de façon automatisée et répétée. Le TDD va éviter un certain nombre de régressions sur l’application et mettre en évidence les simples erreurs de programmation. Ces tests, répétés à chaque construction de l’application, vont permettre une architecture simple et cohérente, un code concis et structuré. La qualité engendrée renforcera la sécurité au niveau de l’application.

 

2. La réduction des temps de déploiement

Beaucoup d’entreprises ont tendance à travailler en cycles de livraison longs, en déployant leur application tous les six mois par exemple. Cette habitude tend à rigidifier les procédures de tests et de déploiement, nécessitant plusieurs jours pour la correction effective d’une faille. Pour y remédier, la mise en place de pratiques DevOps (visant à rapprocher le développement et l’exploitation) et les méthodologies agiles permettent de raccourcir considérablement ces cycles de livraison. Le processus devra être adapté, afin d’automatiser la compilation, le packaging, le test et le déploiement de l’application.

 

3. L’intégration d’outils d’analyse

Des outils d’analyse de la qualité d’une application devraient également être intégrés et exécutés régulièrement. Les développeurs peuvent ainsi avoir accès à certaines informations, telles que la complexité du code, les dépendances entre les différents composants, le code inutile… L’important est de créer un cycle dans lequel les développeurs améliorent en continu la qualité de l’application.

 

4. La surveillance des dépendances de l’application

Il est rare aujourd’hui de développer une application sur la base de son seul code source. Si la sécurité des différents paquets est généralement bien gérée au niveau système, c’est plus rarement le cas au niveau applicatif. Des composants et frameworks open source sont souvent utilisés, sans que personne ne gère ni ne surveille les failles qui pourraient s’y trouver. Là encore, des outils existent dans les cycles d’intégration continue afin de savoir si les dépendances sont bien mises à jour et si les failles de sécurité sont bien traitées. Mais la meilleure des pratiques consiste à dédier une personne à cette surveillance. Cela peut être un développeur de l’équipe, intéressé par le sujet de la sécurité, ou une cellule dédiée, qui prendra en charge la surveillance de l’ensemble des applications et des dépendances qui y sont associées. Ces mêmes personnes pourront également prendre en charge les revues de code et d’architecture liées à la sécurité.

 

5. L’analyse des comportements suspects

Un certain nombre de plateformes se propose d’analyser les comportements suspects à partir des erreurs remontées par l’application ou par la détection de signatures particulières. Néanmoins, les points de détection sont bien plus efficaces, et le déclenchement des mesures de prévention est mieux proportionné, lorsqu’ils sont implémentés dans l’application elle-même. Le but n’est pas de prévenir une faille, mais d’en empêcher la recherche. Pour ce faire, les comportements nominaux, suspects et dangereux doivent être inventoriés, et pris en compte dès le début du développement.

 

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *