Checkmarx : intégrer la sécurité dans son code

Cet article fait partie du dossier

Frédéric Patouly

La sécurité applicative est un enjeu pour les développeurs et les entreprises. Checkmarx est un des acteurs majeurs de ce marché avec l’ambition de couvrir l’ensemble des besoins : du design aux tests finaux. Pour ce faire, l’éditeur édite plusieurs solutions : CxCodeBashing, CxCast, CxSCA, AppSec Accelerator, KICS. Ces outils s’intègrent tout naturellement dans le DevOps et le DevSecOps et bien entendu avec l’outillage du développeur.

Que l’on parle de secure by design, de sécurité applicative, de DevSecOps, l’objectif est le même : trouver et réduire les failles et vulnérabilités. Notre approche : il ne faut pas changer l’environnement et les outils du développeur, mais plutôt s’y insérer.

Les outils

Pour faire de la sécurité dans le code, il faut tout d’abord disposer d’outils d’analyses de code. Ces outils permettent de vérifier la conformité du code avec règles de programmation et les bonnes pratiques. Cette analyse permet de mettre en évidence les incohérences, le code mort et les vulnérabilités potentielles.

Il ne faut pas oublier que les vulnérabilités peuvent apparaître à différents niveaux : le code, les couches techniques utilisées par l’application (frameworks, librairies, API, etc.). Il est important d’analyser l’ensemble des composants externes et notamment les composants open source. Sur la partie Ops de DevOps, il y a aussi l’Infrastructure as Code qui se généralise. Or, ce code d’infrastructure a aussi besoin d’être analysé. Chechmarx propose KICS. Avec un outil tel que CxCodebashing, il s’agit de mieux comprendre les vulnérabilités, ce qui les crée et comment les corriger pour réduire la surface d’attaque et mieux sécuriser son code.

Comme dans le CI/CD, il est possible d’automatiser une partie de ses tests et d’analyses de codes même si le développeur reste la clé. Mais le code devenant de plus en plus complexe, avec la multiplication des couches, il faut automatiser.

Il y a quelques années, les tests de sécurité se réalisaient tardivement dans le projet. Le DevSecOps doit réduire les cycles et réaliser les tests de sécurité et de vérification du code le plus tôt possible. C’est la notion de Secure by Design.

Généraliser les tests à l’ensemble du projet n’est pas forcément une bonne chose, par contre, cibler où le faire peut-être un avantage : par exemple quand on introduit un nouveau code, de nouvelles fonctions dans un code stable. Rajouter du code, c’est potentiellement introduire une faille, un bug. Par exemple, on peut mettre en place un scan d’un pull request, tout en gardant les vérifications durant les builds.

Aider le développeur

Un développeur peut développer sur une branche locale puis la soumettre au tech lead. Le tech lead doit pouvoir une vue sur ce commit pour le rejeter ou l’accepter. Valider un code à l’aveugle, sans logs ou métriques, est dangereux.

Pour le tech lead, ces contrôles lui permettent de voir l’état du code et les failles potentielles. Le scan va pouvoir inspecter l’Infrastructure as Code, les librairies, le code. Chaque anomalie sera remontée dans les logs et les rapports.

La nouvelle plateforme Checkmarx AST va aider les équipes techniques dans la quête de la qualité du code ! Elle se présente sous la forme d’un portail. Son but est simple : lancer des scans sur des projets. Ils peuvent être dans des référentiels GIT ou importer dans l’outil. 

Le projet importé, nous pouvons lancer le scan. Un des avantages de la plateforme est d’être capable d’aller vérifier le code source Git d’une API, d’une framework. Car la vulnérabilité n’est pas uniquement dans son code !

Une fois le scan réalisé, la plateforme génère des rapports et des métriques. Les vulnérabilités sont classées selon la dangerosité de la faille. Le développeur peut réduire en priorité les vulnérabilités hautes. Par exemple, l’outil est capable de détecter si votre app fonctionne uniquement en mode root (par exemple : lorsque l’on exécute un docker file sans spécifier de users). Les failles sont classées en trois niveaux : bas, moyen et élevé. Grâce à cet outil, vous visualisez rapidement les différentes librairies utilisées : les versions, les failles connues, etc. Bref, grâce à cet outillage, nous aurons une vision d’ensemble de votre projet et des piles techniques.

Avec un outil de type SAST, nous allons plus dans le code pour comprendre la vulnérabilité et où elle est dans le code. Pratique et rapide.

S’exercer, c’est apprendre !

CodeBashing est un service permettant de se former à la sécurité by design et de s’exercer. L’outil propose des entraînements avec des leçons. Plus vous progressez, plus vous gagnez des points. CodeBashing permet de s’entraîner et de progresser dans les bonnes pratiques. L’outil propose des leçons sur les failles, les frameworks, les langages. Et on rentre concrètement dans le code pour être au plus proche de la faille.

Frédéric Patouly (régional director France et Bénélux - Checkmarx)