Nous souhaitons déployer nos applications plus rapidement certes, mais de manière qualitative et sécurisée. Dans un contexte de plus en plus agile, les méthodes d’audit de sécurité manuelles (tests intrusifs, revue de code) ne sont plus suffisantes, et ne permettent plus de s’adapter à la vélocité des processus de déploiement continu.

Il faut donc automatiser tout ça pour permettre de garder la cadence en évitant de livrer n’importe quoi en production 🙈

Commençons par le commencement

So you say you want application security 
But you don't want to test your code

Les stratégies et les outils permettant d’appliquer des politiques et des actions sécuritaires dans nos workflows sont nombreux, mais par quoi devons-nous commencer ?

Nous pourrions commencer par des tests unitaires de sécurité que nous avons souvent tendance à mettre de côté 😔. C’est probablement le bon endroit pour tester la gestion des droits et du système RBAC de l’application. On a beau avoir des couches de WAF, ceux-ci ne pourront pas empêcher l’exploitation d’une vulnérabilité intrinsèque à la gestion des droits dans l’application.

Ne pas divulguer ses secrets

Il est important de garder ses mots de passe et ses clés pour soi, et d’éviter de les divulguer dans les logs, les réponses serveurs ou encore dans les commits au risque de s’en mordre les doigts 😬

Des outils comme gitleaks ou encore truffleHog peuvent rendre un grand service dans ce domaine. Ils permettent de scanner des répertoires locaux ou vos repos git (ou encore ceux du voisin 😇) à la recherche de secrets. Nous pouvons simplement les intégrer dans nos pipelines CI pour, par exemple, refuser toute pull request suspecte.

Dans la jungle (terrible jungle) des librairies

Il y a une librairie pour à peu près tout et c’est super 👍. Evidemment, vous l’avez deviné, tout n’est pas bon à prendre. Un mauvais choix de librairie ou de version pourrait permettre à un attaquant l’exploitation des vulnérabilités associées en provoquant un déni de service, d’accéder à des informations sensibles, de manipuler des données, de contourner des restrictions de sécurité, d’élever ses privilèges ainsi que de prendre le contrôle du système. Et cela pourrait vous couter cher.

Il est donc impératif de détecter les CVE des librairies utilisées dans votre projet. Des solutions dites SCA (Software Composition Analysis) permettent de scanner vos dépendances et de vous retourner les CVE connues. Ces outils se basent sur leurs bases de données de vulnérabilités, et leur qualité en dépend fortement.

On peut citer entre autres : BlackDuck, Sonatype Lifecycle ou encore Jfrog Xray. Pour ceux qui préfèrent les solutions open-source : OWASP Dependancy Check

Le loup est dans la bergerie

Notre propre code peut être source de failles de sécurité. Des failles qui pourraient permettre des attaques XSS, des injections de codes, le vol de données. Voici deux manières de le tester :

La méthode dite ‘whitebox’ analyse le code source sans l’exécuter et permet de trouver et corriger des vulnérabilités intrinsèques à notre application. Cette méthode est aussi connue sous le nom de SAST (Static Application Security Testing). Plusieurs solutions SAST existent sur le marché : Checkmarx, Veracode, Micro Focus… Dans le monde open-source, plusieurs projets OWASP proposent des alternatives aux solutions commerciales. SonarQube, très utilisé dans la gestion de la qualité de code, permet également de détecter certaines vulnérabilités dans le code source de votre application.

MR decoration with SCA results

La méthode dite ‘blackbox’ consiste à exécuter l’application pour y injecter des requêtes malicieuses afin de détecter des éventuelles vulnérabilités (XSS, SQL injection, LFI). C’est ce qu’on appelle le DAST pour Dynamic Application Security Testing.

Le DAST permet également de révéler les problématiques de sécurités à l’exécution (runtime), qu’on ne pourrait détecter via une analyse de code. Par exemple des problématiques de configuration ou d’authentification.

Le projet OWASP Zap est très intéressant il consiste en un proxy entre le client et l’application qui injecte du flux malicieux dans cette dernière.

Notons enfin qu’il est important d’intégrer ces deux méthodes d’analyse dans les pipelines CI car elles sont complémentaires. Le DAST ne sait pas détecter des erreurs de codes, le SAST ne sait pas détecter les erreurs liées à l’exécution ou à l’environnement.

Conclusion

La sécurité continue reste avant tout du bon sens, qu’on peut apporter par petites briques. L’avantage de l’intégrer dans les pipelines d’intégration continue est de respecter un principe important : le “shift left”.

L’idée est qu’il est plus facile, plus rapide et moins couteux de détecter et de corriger les problèmes de securité au plus tôt dans le cycle de vie de l’application. Alors il vaut mieux refuser une PR que de bloquer une MEP 😉

Recevez notre Study Guide

Bravo ! Vous avez été jusqu’au bout de l’article :) Pour aller plus loin, recevez notre Study Guide Kubernetes contenant la sélection de références concoctée pour vous par nos experts.