Supply chain IA, attention à l'intégration d'adapters LoRA malveillants

Les LLM (Large Language Model), qu’ils soient fournis par OpenAI, Anthropic ou Meta, sont le plus souvent entraînés avec des données générales et publiques issues d’internet. Dans certains domaines (finance et médecine par exemple) ou contextes d’entreprises, une spéclialisation du modèle est nécessaire pour le rendre plus pertinent.

Pour réaliser cette étape de fine-tuning, 2 options sont disponibles :

Construction d’un agent IA au service de la cybersécurité défensive

L’évolution de l’intelligence artificielle et son intégration dans la cybersécurité ouvrent la voie à de nouveaux usages pouvant impacter positivement la posture de sécurité des entreprises tout en limitant l’impact sur les équipes. Très plébiscitée dans le cadre d’activités offensives (pentest, bug bounty par exemple), l’IA trouve aussi sa place sur le plan défensif en favorisant une détection au plus tôt des vulnérabilités ainsi qu’une contextualisation aidant à la priorisation.

La place des outils dans l'intégration de la sécurité dans les projets

Lorsque le sujet de l’intégration de la sécurité dans les projets (aka DevSecOps) est abordé, la mise en place d’outils de scan (statique, dynamique, dépendances, etc.) au sein du cycle de développement logiciel (SDLC) apparait très souvent comme la réponse la plus simple.

Les outils, une solution magique ?

Intégrer un outil de sécurité est une opération qui peut sembler rapide, peu couteuse (modulo les éventuels coûts de licence) et et utile pour automatiser une partie de la sécurité des applications sans trop impacter la vélocité des équipes de développement.

Quelle matière utiliser pour générer un SBOM ?

Le SBOM, pour Software Bill Of Material, représente l’ensemble des dépendances intégrées à une application (nom, version, etc.). Cette liste est notamment intéressante pour suivre les versions et vulnérabilités présentes dans ces dépendances et en assurer les montées de versions. Elle peut même devenir obligatoire en cas d’applicabilité du Cyber Resilience Act par exemple. Les 2 formats les plus communs pour représenter un SBOM sont CycloneDX et SPDX.

Les certificats TLS

Les certificats TLS (Transport Layer Security), anciennement SSL (Secure Sockers Layer), font partie de notre quotidien sans que nous nous en rendions compte ou que nous sachions comment ils fonctionnent. Que ce soit pour de la simple navigation sur internet ou le paiement d’articles sur des sites e-commerce, ils permettent d’assurer un certain niveau de sécurité sur ces transactions.

La sécurisation des échanges sur internet reposant en grande partie sur ces certificats, comprendre leur fonctionnement est essentiel pour les mettre en place correctement lors de la mise à disposition d’une application.

Stocker les secrets utilisés par une application

Dans une application, il est souvent nécessaire d’utiliser des secrets. Ces secrets peuvent servir à se connecter à une base de données, à accéder à une API distante, chiffrer/signer des données, etc.

2 questions se posent :

• Comment/Où stocker ces secrets ?
• Comment mettre à jour facilement un secret utilisé par plusieurs applications ?

Le moyen le plus facile de mettre à disposition ces mots de passe est de les enregistrer dans les fichiers de configuration de l’application nommés par environnement (appsettings.dev.json, appsettings.prod.json, etc.) et de pousser ensuite tous ces fichiers dans le repository git.

Gestion des analyses de sécurité avec DefectDojo

Lors de la vie d’une application, des tests de sécurité (manuels et/ou automatisés) sont réalisés. Pour réaliser ces tests, des pentesteurs et/ou des outils rentrent en jeux pour détecter des vulnérabilités. Une fois ces problèmes remontés dans des rapports souvent statiques, il est nécessaire d’assurer un suivi de ces vulnérabilités pour suivre et maitriser l’état de santé d’une application sur l’aspect sécurité.

Pour faciliter cette gestion, des outils d’agrégation/gestion de vulnérabilités comme DefectDojo, ThreadFix ou CodeDX permettent rendre cette tâche plus facile.

Analyse des dépendances (SCA - Sofware Component Analysis)

Les dépendances tierces représentent en moyenne 80% du code d’une application (Gartner). Au même titre que le code écrit par les développeurs de l’application, une porte d’entrée dans une de ces librairies peut compromettre la sécurité du système. Ainsi, en plus des vulnérabilités présentes dans le code écrit par les développeurs de la dite application, il faut s’assurer que ces dépendances embarquées ne contiennent pas de CVE.

Afin de vérifier ces dépendances, l’outil d’analyse doit les lister et déduire les versions utilisées. Cette tâche peut s’avérer complexe lorsque les versions des librairies ne sont pas définies explicitement dans les fichiers de configurations (packages.json, pom.xml, etc) ou que l’arbre des dépendances inclue plusieurs fois la même librairie avec des versions différentes. Il n’est pas rare de retrouver des versions différentes entre plusieurs outils d’analyse de dépendances.

Tests de sécurité automatisés

Les chaînes de CI/CD permettent une industrialisation de la production logicielle en testant, packageant et déployant les applications automatiquement. Dans ces chaînes automatiques, l’aspect sécurité est régulièrement mis de côté et les tests associés sont bien souvent manuels.

Les tests automatiques de sécurité peuvent être catégorisés en 2 familles, le SAST (Static Application Security Testing) qui analyse de manière statique le code produit par les développeurs ou les fichiers de configuration paramétrés par les administrateurs système alors que le DAST (Dynamic Application Security Testing) fait des tests sur une application ou un serveur déployé et accessible. Si le SAST apparait en début de chaîne, sur le poste des développeurs ou sur l’outil d’intégration continue, le DAST intervient quant à lui en fin de chaîne lorsque l’application a été packagée et déployée sur un environnement.

OpenSAMM, modèle de maturité pour le développement d'applications sécurisées

OpenSAMM (Software Assurance Maturity Model) est un des projets “Flagship” de l’OWASP (Open Web Application Security Project) permettant d’évaluer, définir et mettre en place une stratégie de sécurité pour les applications.

Le projet propose de découper le développement logiciel en 4 domaines divisés en 12 sous-domaines. On retrouve globalement les différentes étapes du SDLC.

Fonctionnement

Chaque sous domaine est divisé en 4 niveaux de maturité.

• 0 : Niveau implicite de départ
• 1 : Compréhension initiale et mise en place de pratiques de sécurité
• 2 : Amélioration de l’efficacité/efficience des pratiques de sécurité
• 3 : Maîtrise complète des pratiques de sécurité

Pour chaque sous-domaine, plusieurs éléments sont associés à chaque niveau de maturité :