Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Le département informatique au service des organisations
  3. Sécuriser ses applications propres
Extrait - Le département informatique au service des organisations Stratégie, gouvernance et pilotage
Extraits du livre
Le département informatique au service des organisations Stratégie, gouvernance et pilotage Revenir à la page d'achat du livre

Sécuriser ses applications propres

Des outils pour augmenter la sécurité des développements

Pendant de nombreuses années, l’open source était préconisé pour bien des situations mais assez peu pour les outils de sécurité. Les apports de la communauté IT Security et des développeurs ont finalement permis de faire émerger de nombreux projets open source considérés comme fiables, comme le OWASP le propose. Ainsi, la liste des règles de bonnes pratiques étant désormais partagée par tous et pour tous. Il est fréquent de voir des fournisseurs de solutions proposer une version open source de leurs outils et qui répondent au besoin premier alors que leur différenciateur est quant à lui payant. On peut ainsi dire que l’open source permet l’émergence d’outils de qualité qui se voient complémenter par des technologies propriétaires. La bonne nouvelle est que l’open source couvre l’indispensable.

Que ce soit de l’open source ou du propriétaire, l’important restera toujours d’identifier l’outil qui correspond aux technologies et à la manière de fonctionner de l’organisation. Certains outils sont clairement voués à être utilisés dans un contexte Dev(Sec)Ops, d’autres s’adapteront mieux dans une approche Waterfall.

Chaque...

La sécurité au travers du pipeline

Bien que le nombre d’outils ci-dessus s’avère déjà bien chargé, cette liste est non exhaustive et augmentera dans les prochains mois et années. En effet, de nouveaux outils disposant de nouvelles fonctionnalités, notamment grâce à l’émergence de l’intelligence artificielle, feront leur apparition sur le marché.

Maintenant que nous avons vu cette liste, il reste à les assembler pour proposer un pipeline complet. Prenons un exemple.

1. Durant la phase de développement

Durant la phase de développement, seul le code source est disponible. C’est déjà suffisant pour identifier bien des risques et ainsi minimiser les impacts futurs. Ainsi, les outils de SAST s’avèrent bien utiles dans l’environnement de développement. SonarLint est le connecteur permettant à un environnement de développement de s’intégrer avec SonarQube que nous avons abordé précédemment. Dans ce contexte, c’est directement dans l’environnement que les risques et les failles sont notifiés, durant le développement. Que demander de mieux ?

Le développeur peut également faire tourner l’applicatif sur son poste local. Dans ce cas, il est possible de tester l’application en tant que telle et ses points d’entrée. Certains outils de DAST et d’IAST s’intègrent aisément...

La sécurité des applications avec OWASP

La notion de sécurité est large. Il est donc nécessaire de prendre un certain nombre d’orientations. Tout en restant relativement traditionnel, avec une approche où le développeur est responsable des applications uniquement, le périmètre s’avère déjà étendu. L’Open Web Application Security Project (OWASP), qui se targue d’être indépendant de tout fournisseur de solutions, propose ainsi de la documentation sur les bonnes pratiques et même des solutions à proprement parler. Au terme d’un long travail, l’OWASP a ainsi publié en 2021 une liste de dix risques qui sont toujours d’application aujourd’hui :

  • Contrôle d’accès défaillant : il permet d’accéder à des ressources qui ne devraient pas l’être, telles que des pages ou des bases de données. Lorsqu’il ne s’agit pas d’une configuration trop permissive, des techniques d’injection permettent ainsi d’exploiter une authentification brisée pour donner accès à ces ressources.

  • Exposition de données sensibles : les données sont présentes tant sur le serveur que sur les applications clientes et transitent entre les deux sur le réseau. Elles peuvent être interceptées...

Par où commencer dans la sécurité applicative

Peut-être avez-vous déjà démarré l’intégration de ces outils au sein de votre pipeline CI/CD. Si ce n’est pas le cas, il est temps de s’y mettre, avec ou sans les équipes sécurité. Si ce n’est pas le cas, il est déjà possible de mettre en place un certain nombre de tests afin de minimiser les risques évoqués par l’OWASP. Les équipes sécurité peuvent, en effet, fournir des conseils permettant d’atteindre le meilleur résultat en un minimum de temps mais, dans tous les cas, elles vous remercieront de l’intérêt que vous portez à la sécurité et vous aurez tout leur soutien pour promouvoir de telles initiatives futures. Mais au-delà de se faire des amis, l’intérêt est avant tout de comprendre les fondements de la sécurité, ce qui aura un impact positif sur les livrables fournis aux différents métiers.

Pour le développeur, quoi de plus motivant que d’éviter de devoir résoudre des bogues connus et qui auraient pu être évités et de voir comment les choses évoluent ? Pour le visualiser, il s’agit de mettre en place des tableaux de bord avec le score de vulnérabilité, le nombre de vulnérabilités...