Intégration des outils SAST dans DevSecOps

Temps de lecture : 8 minutes

Les équipes de développement de logiciels sont constamment poussées à fournir des systèmes logiciels plus complexes, notamment des systèmes cyberphysiques, dans des délais plus courts et avec moins de ressources. Dans le même temps, le coût des échecs augmente, car les logiciels sont souvent intégrés dans des chaînes commerciales plus vastes et plus complexes, comme dans le cas des chaînes IoT edge-to-cloud, ou de l'interaction entre les composants dans un déploiement de réseau intelligent ou un cas d'utilisation automobile. Les équipes tentent en permanence d'améliorer leurs outils, leurs méthodologies et leurs processus, et c'est de là qu'est né DevOps, la combinaison du développement logiciel et des opérations système pour s'assurer que le développement logiciel ne se fait pas dans le vide, mais en combinaison avec les équipes qui exploitent ces systèmes dans le monde réel.

L'étape suivante dans cette amélioration des méthodes de développement logiciel est DevSecOps, où la sécurité est incluse comme une partie essentielle du processus de développement. On réalise ici qu'une défaillance de sécurité est la même, voire pire, qu'une défaillance de qualité. Les défauts dans les produits mis en service ont un impact sur les résultats financiers ainsi que sur la réputation de l'entreprise. C'est encore pire si une analyse a posteriori détermine que ces défauts auraient pu être facilement évités. DevSecOps est donc l'intégration au niveau de l'équipe des équipes qui créent le logiciel, l'exploitent et le sécurisent.

Cet article examine le rôle des outils de test de sécurité des applications statiques (SAST) et en particulier CodeSecure CodeSonar et comment ils peuvent être utilisés dans DevSecOps et les pipelines de développement continu pour améliorer la qualité et la sécurité et, finalement, rendre les équipes plus compétitives pour devenir leaders sur le marché.

Les équipes participant au DevOps n'oublient pas intentionnellement la sécurité, mais comme toute autre méthode de développement, à moins qu'elle ne fasse partie des exigences et de la culture de développement, cela n'est pas réalisé. Cela conduit les équipes logicielles soit à ignorer la sécurité, soit à la déléguer à la fin de l'effort de développement, ce qui signifie que les gens essaient de « s'attaquer » à la sécurité à la fin. Et comme le dira tout professionnel de la sécurité : « La sécurité doit être intégrée dès le début, et non ajoutée aux dernières étapes du développement du produit. » Ou en d’autres termes : « Payez-moi maintenant, ou bien plus plus tard ».

De plus, l’une des principales raisons pour lesquelles il faut intégrer la sécurité dans les processus agiles et continus est de s’appuyer sur les connaissances accumulées au fil du projet. Il n’est pas raisonnable d’attendre des équipes de développement logiciel qu’elles comprennent toute leur surface d’attaque, par exemple, au début du projet. L’intégration de la sécurité dans les opérations quotidiennes permet d’accumuler de l’expertise et des connaissances. Il est essentiel de commencer tôt.

Dans cette optique, DevSecOps est souvent illustré comme suit sur le  diagramme DevOps  – la sécurité à chaque étape du cycle :

Il y a deux considérations importantes lors de l’ajout de sécurité à DevOps. Le premier est la sécurité du code, ce qui signifie que lorsque le code est développé, la sécurité du code lui-même doit être continuellement examinée et évaluée. La seconde est la sécurité en tant que code, en d’autres termes, les exigences de sécurité doivent faire partie du processus dès le début.

Examinons ces deux concepts un peu plus en détail.

De nombreuses équipes commencent leur parcours vers la sécurité en adoptant des directives ou des normes de codage telles que MISRA ou les directives CERT, ce qui est un bon début, car cela améliore la sécurité du code dès le départ. Cependant, une norme de codage en elle-même n'évite pas les problèmes de mémoire, par exemple. Selon une étude récente de Microsoft, 70 % des vulnérabilités de sécurité actuelles sont causées par des vulnérabilités de mémoire. Les vulnérabilités de mémoire peuvent ici être causées par une simple erreur de calcul, qui conduit à un dépassement de mémoire tampon, ou par un chemin plus complexe où une variable est corrompue par une entrée provenant de l'extérieur qui est utilisée sans être nettoyée. Pour trouver ces problèmes dans le code, une analyse plus sophistiquée est nécessaire, comme l'analyse du flux de données et l'exécution abstraite.

Une approche intéressante issue de la pratique DevSecOps est le concept de traiter la sécurité de la même manière que le code ; elle est guidée par les exigences, ce qui conduit à la mise en œuvre de contrôles de sécurité, puis à la validation par des tests, et nécessite bien sûr une documentation. C'est l'un des principaux moyens d'intégrer la sécurité dans DevOps et un bon moyen d'intégrer la sécurité dans la culture de développement et de permettre aux équipes de développement de communiquer en utilisant un langage familier. Il est certain que les implémentations de sécurité qui aboutissent à un code réel avec des tests associés peuvent être automatisées de la même manière que les autres codes. Les outils d'automatisation s'appliquent ici comme le ferait tout outil fonctionnant avec des exigences, des tests, de la documentation, etc.

L'automatisation est l'un des principaux locataires du DevOps. Rien ne doit dépendre d'étapes manuelles, car elles peuvent être facilement négligées, par accident ou par intention malveillante. SAST peut être utilisé dès que le code est disponible dans un projet et automatise la conformité du codage et la détection automatique des défauts et vulnérabilités. En fait, dès qu'il est saisi par un développeur, le plus tôt sera le mieux. Dans le cas de code hérité, tiers et existant, SAST peut être utilisé sur ces produits avant même de démarrer le projet en cours, généralement exécuté avant l'analyse dynamique, DAST qui nécessite un code fonctionnel, des cas de test et un environnement de test.

SAST se présente sous toutes sortes de formes et de tailles, certains se concentrent sur les normes de codage, d'autres, des outils plus avancés, vont au-delà des normes de codage et explorent le flux de données, le flux de contrôle et les techniques d'exécution abstraites pour trouver des défauts dans le code source qui résultent de la programmation ou erreurs de logique. Ces outils avancés contribuent à assurer la sécurité du code et à créer la sécurité en tant que code.

Les processus d'intégration et de déploiement continus s'appuient sur l'automatisation pour en tirer les avantages. Sans progression efficace tout au long du cycle, la nature continue des processus amplifie les inefficacités. Tout nouveau code comporte des bugs, le défi auquel les équipes sont confrontées est de les supprimer le plus tôt possible avec le moins d'efforts possible. SAST améliore la sécurité et la qualité du code dès le début du processus et aide le développeur à le faire aussi facilement que possible, idéalement en l'intégrant dans son environnement de développement.

La plupart des équipes DevSecOps ont mis en place une forme de flux de travail dans laquelle un développeur peut développer du code dans son environnement de développement préféré (qu'il s'agisse de VI, Emacs, Microsoft VS Code ou Visual Studio, ou de l'un des nombreux environnements basés sur Eclipse). Le codage signifie ici la création de code, sa compilation, ses tests unitaires et son débogage. Dans le cadre de cet environnement, le développeur a généralement la possibilité de lancer une build. Certains projets effectuent des compilations locales sur le bureau du développeur, tandis que d'autres ont des serveurs de build plus formalisés et « verrouillés ». Une fois qu'un élément de travail est terminé, il est soumis et fusionné dans la base de code principale. Des tests automatiques, à la fois dynamiques et statiques, sont intégrés à ce flux de travail. Il existe généralement une forme de test de bon sens ou de test de fumée avant que les modifications ne soient autorisées à revenir dans la base de code principale.

De nombreuses intégrations d'outils sont nécessaires pour que tous ces flux de travail fonctionnent correctement. De la gestion des exigences et du suivi des défauts (des outils comme JIRA), à l'automatisation de la construction (des outils comme Jenkins), aux tests automatisés et bien plus encore.

SAST s'intègre parfaitement à presque toutes les chaînes d'outils d'automatisation de logiciels et à toutes les méthodologies et processus de développement. Cela est principalement dû au fait qu'ils peuvent être utilisés localement par les développeurs sur leur bureau pour un retour d'information instantané et pour analyser une version complète, que ce soit toutes les heures ou à tout moment.

De plus, ces outils sont totalement autonomes car ils ne nécessitent aucune interaction avec les testeurs ou les développeurs. Ils sont applicables chaque fois qu'il est judicieux de vérifier les bugs et les vulnérabilités de sécurité dans le code :

• Développer : c'est le moment critique pour détecter toute nouvelle vulnérabilité de sécurité, dès que les développeurs écrivent un nouveau code (ou des cas de test) avant même qu'il ne soit soumis à un système de build ou de contrôle logiciel. CodeSonar, par exemple, présente ces vulnérabilités immédiatement dans l'IDE du développeur, comme un avertissement du compilateur, en fournissant des mesures correctives simples et exploitables (comme l'évaluation des vulnérabilités, les causes profondes et les traces de contrôle et de flux de données). Le délai d'exécution est important ici, le retour d'information doit être rapide, de sorte que le développeur ne soit pas embourbé en attendant la fin des builds. L'intégration dans l'IDE est importante ici car elle réduit la charge cognitive du développeur de logiciels. Il n'a pas besoin de quitter son environnement de développement préféré et peut examiner et évaluer le résultat de l'analyse statique directement dans son IDE. SAST est également essentiel dans cette phase pour garantir le respect des normes de codage sécurisées. Les violations de la norme de codage et les pratiques de codage potentiellement dangereuses sont signalées pour que les développeurs puissent enquêter.
• Test : C'est ici que toutes les modifications de tous les développeurs sont rassemblées pour des tests plus complets, SAST joue un rôle important dans ce processus. Le temps d'exécution dans cette phase est moins critique, c'est pourquoi SAST fournit une analyse plus approfondie nécessitant plus de temps de calcul, par exemple pour détecter des problèmes de concurrence ou des flux de données corrompus, ou passer plus de temps à effectuer une analyse de pointeur.
• Déploiement : SAST peut être utilisé pour analyser les binaires et les bibliothèques déployables. CodeSonar, par exemple, prend en charge l'analyse de code binaire pour le code C/C++ qui détecte les mêmes types de vulnérabilités que l'analyse source. Il s'agit d'une bonne pratique pour détecter les bogues introduits lors de la création et du déploiement des livrables.
• Révision : SAST fournit des rapports et des analyses que les équipes logicielles peuvent utiliser pour évaluer les avertissements individuels, mais également des évaluations de plus haut niveau de la qualité et de la sécurité des applications. Les rapports du SAST doivent faire partie de l’évaluation et de la planification du cycle pour chaque cycle.

Ces intégrations dans le cycle DevSecOps sont illustrées ci-dessous :

CodeConar de CodeSecure a la capacité unique d'effectuer une analyse statique avancée sur le code binaire. Cela offre des avantages supplémentaires au processus d'intégration continue, en particulier lors de l'intégration de binaires tiers ou de bibliothèques héritées. Si le code source n'est pas facilement disponible, cela n'empêche pas la capacité de détecter les bugs et les vulnérabilités de sécurité. En outre, l'analyse binaire peut être utilisée par les équipes de sécurité pour effectuer une analyse « boîte noire » des livrables du produit.

Profondeur de l'analyse

Toutes les équipes de développement de logiciels n’ont pas la même préférence pour SAST. Le fait est que tous ces types d’outils souffrent d’un certain degré d’imprécision. Tous les avertissements signalés par un outil ne sont pas exploitables, certains sont des faux positifs, ce qui signifie que l’outil émet un avertissement par erreur. Le contraire d’un faux positif est un faux négatif, un problème réel dans le code source que l’outil néglige. Certains développeurs, en particulier dans le secteur du développement de logiciels en entreprise, préfèrent les outils d’analyse statique avec un faible taux de faux positifs. Ils ne veulent pas voir d’avertissements qui ne sont pas des problèmes graves. Il est intéressant de noter qu’il existe une relation inverse entre les faux positifs et les faux négatifs. Un faible taux de faux positifs s’accompagne généralement d’un taux de faux négatifs plus élevé. Le coût d’un faux négatif est qu’un problème peut se retrouver dans la base de code, peut-être lors des tests, mais il se retrouve souvent dans les systèmes déployés.

Pour les projets logiciels critiques en matière de sûreté et de sécurité, il est clairement inacceptable de manquer des défauts importants ou des vulnérabilités de sécurité. Les développeurs travaillant sur ces projets préfèrent consacrer plus de temps à analyser les avertissements, même si certains peuvent s'avérer être des faux positifs ou des problèmes moins critiques. Manquer un problème et expédier un logiciel défectueux peut entraîner des pannes de courant, des avions ou des voitures écrasés, ou un dysfonctionnement d'équipements de santé critiques. Pour les logiciels critiques en matière de sûreté et de sécurité, un faible taux de faux négatifs est bien plus important qu’un faible taux de faux positifs.

CodeSonar est un SAST spécifiquement axé sur ces projets critiques en matière de sûreté et de sécurité.

RÉSUMÉ

De toute évidence, le SAST joue un rôle important dans DevSecOps et constitue un élément important de l'adaptation des pratiques de sécurité dans un pipeline d'intégration et de déploiement continu. Alors que les équipes logicielles commencent à intégrer la sécurité dans leur DevOps, des outils tels que CodeSonar sont faciles à adopter et font partie du pipeline d'automatisation. En détectant les vulnérabilités à un stade précoce et en les empêchant d'accéder aux étapes ultérieures du pipeline, cela se traduit par une réduction des correctifs de sécurité à un stade avancé.

SAST est un élément important de la chaîne d'outils d'automatisation du développement logiciel qui fournit une détection supplémentaire des vulnérabilités de sécurité, l'application des normes de codage et une assurance de sécurité complémentaire aux tests et à l'analyse dynamique. CodeSonar apporte en particulier l'avantage supplémentaire de l'analyse binaire pour l'évaluation de la sécurité par boîte noire des bibliothèques et exécutables tiers.