Guide DIY : « Construire ou acheter » votre boîte à outils de scan de code OSS et de sécurité des applications

Vous êtes confiant dans vos compétences en développement—suffisamment confiant pour savoir que les applications que vous avez développées ne sont pas totalement exemptes de failles de sécurité et de configuration. Vous avez également exploré le vaste écosystème d'outils de scanning disponibles et avez peut-être été submergé par l'énorme volume de choix. Quel est le bon « portefeuille » d'outils de sécurité d'applications open source pour identifier les vulnérabilités dans vos dépendances, vos configurations Infrastructure as Code (IaC), vos conteneurs, et plus encore ?

Pour vous mettre sur la bonne voie, nous aborderons 10 catégories essentielles d'outils d'analyse de code et de sécurité, et recommanderons 9 projets OSS, avec uniquement les informations essentielles dont vous avez besoin pour démarrer :

• Comment cette analyse contribue à la sécurité de votre application.
• Quel projet open-source vous pouvez installer et comment l'exécuter.
• Quelques alternatives (lorsqu'elles sont disponibles) parmi lesquelles vous pouvez choisir.

Avec cela, vous aurez un chemin direct pour scanner vos applications à la recherche de problèmes de sécurité critiques dans le code et les configurations cloud. Que demander de plus ?

Eh bien, la partie configuration et gestion n'est pas toujours rose, mais nous y reviendrons plus tard.

Ce dont vous aurez besoin

Apportez simplement votre poste de travail local, qu'il s'agisse d'un ordinateur de bureau ou portable — peu importe si vous utilisez macOS, Windows ou Linux.

Un environnement de développement est facultatif mais recommandé. Pour exécuter cette suite d'outils de scan open source, vous devrez installer de nombreux logiciels que vous ne souhaitez peut-être pas sur votre système d'exploitation de base, nécessitant des mises à jour plus importantes, polluant votre auto-complétion et vous liant à des outils spécifiques qui pourraient ne pas fonctionner sur tous vos projets. Un environnement de développement conteneurise et isole, dans une certaine mesure, tous vos outils spécifiques au développement du reste de votre système d'exploitation.

Heureusement, vous disposez d'excellents outils open-source parmi lesquels choisir :

1. Avec Docker, vous pouvez démarrer un nouveau conteneur minimaliste nommé devenv-01 comme suit : docker run --name devenv-01 -it ubuntu:24.04 sh
2. Avec Daytona, qui est livré avec de nombreuses « batteries incluses » pour les workflows de développement : daytona create --code
3. Ou avec Distrobox, qui intègre n'importe quelle distribution Linux dans votre terminal, vous permettant d'installer des logiciels

Ce qui est formidable avec un environnement de développement, c'est qu'une fois que vous avez terminé avec une "stack" particulière, vous pouvez supprimer le conteneur en toute sécurité sans impacter votre poste de travail.

#1 : Gestion de la posture de sécurité du cloud (CSPM)

Comment le CSPM contribue-t-il à la sécurité des applications ?

Le CSPM vous aide à renforcer la sécurité et la conformité de vos environnements cloud. En surveillant en permanence vos applications et leurs services en amont par rapport aux meilleures pratiques de l'industrie et à vos politiques internes, les outils CSPM évaluent les problèmes, les priorisent en fonction de leur criticité et proposent des recommandations de remédiation. Avec le CSPM, vous prenez davantage en charge les bases de référence et les garde-fous qui vous empêchent, vous ou d'autres, de promouvoir des applications vulnérables en production, tout en éliminant les mauvaises configurations et les rôles d'utilisateur trop permissifs.

Installez et exécutez votre projet OSS CSPM : CloudSploit

Pour installer CloudSploit, vous aurez d'abord besoin de Node.js pour télécharger ses dépendances et exécuter le moteur.

git clone https://github.com/aquasecurity/cloudsploit.git
cd cloudsploit
npm install

Ensuite, vous devez configurer CloudSploit avec des autorisations de lecture pour votre compte cloud, avec la prise en charge de AWS, Azure, GCP, et Oracle. Suivez les instructions de votre fournisseur cloud, en utilisant le config_example.js fichier comme votre modèle, pour créer un config.js fichier avec tous les détails dont vous aurez besoin pour exécuter votre premier diagnostic complet et obtenir les résultats au format JSON.

./index.js --collection=file.json config.js

#2 : analyse de la composition logicielle (SCA) des dépendances open source

Comment le SCA contribue-t-il à la sécurité des applications ?

Vos applications ont inévitablement un vaste arbre de dépendances open source sur lesquelles vous comptez désormais, depuis votre framework d'interface utilisateur jusqu'aux bibliothèques d'aide que vous utilisez dans une seule ligne de code (LOC), comme un validateur d'adresses e-mail. La SCA est comme une vérification des antécédents de la famille élargie de votre code, identifiant les vulnérabilités de sécurité et les problèmes de licence non pas une seule fois, mais en continu. Étant donné que vos outils SCA vous informent des nouvelles vulnérabilités et des remédiations, vous aurez l'assurance que votre chaîne d'approvisionnement open source reste une aide, et non un obstacle, à la productivité.

Installez et exécutez vos projets OSS SCA : Syft + Grype

Pour le SCA exécuté localement, vous aurez besoin de Syft pour créer un Software Bill of Materials (SBOM) et de Grype pour analyser ce SBOM à la recherche de vulnérabilités connues. Étant donné que la même équipe développe Syft et Grype, ils prennent en charge de nombreuses méthodes d'installation mais recommandent leurs commandes en une ligne respectives :

curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

Avec Syft installé sur votre poste de travail local, vous pouvez créer une SBOM pour votre conteneur, en remplaçant <YOUR-IMAGE> avec une image dans un registre de conteneurs configuré ou un répertoire local.

syft <YOUR-IMAGE> -o syft-json=sbom.syft.json

Vous vous retrouverez avec un sbom.syft.json dans votre répertoire de travail, que vous pourrez ensuite alimenter dans Grype.

grype sbom:path/to/syft.json -o json

Grype affiche ensuite un résumé des vulnérabilités au format ci-dessous, incluant les détails de gravité et les informations sur les correctifs connus, que vous pouvez utiliser pour guider votre processus de priorisation et de remédiation.

{
"vulnerability": {
   ...
 },
"relatedVulnerabilities": [
   ...
 ],
"matchDetails": [
   ...
 ],
"artifact": {
   ...
 }
}

Alternatives et mises en garde

Trivy est une alternative OSS solide pour la SCA — il n'offrira pas une parité de fonctionnalités 1:1 sur toute la ligne, mais il sera plus que suffisant pour vous lancer.

#3 : détection de secrets

Comment la détection de secrets contribue-t-elle à la sécurité des applications ?

Un outil de détection de secrets analyse votre code et vos configurations à la recherche de credentials que vous ne souhaitez pas exposer publiquement. Ces secrets peuvent inclure des clés API, des jetons d'accès à des fournisseurs tiers, des mots de passe pour des bases de données en amont, des certificats, des clés de chiffrement, et plus encore, et une fois qu'ils sont poussés vers un dépôt public, vous devrez passer par un processus douloureux pour les supprimer de votre historique Git — mieux vaut les détecter tôt et agir avant de commettre.

Installez et exécutez votre projet OSS de détection de secrets : Gitleaks

Gitleaks scanne vos dépôts à la recherche de secrets codés en dur, passés ou présents, en analysant les logs Git. Son détecter le comportement identifie les secrets qui ont déjà été commités, tandis que le protéger le comportement scanne les modifications non commitées pour vous éviter de faire des erreurs dès le départ.

Pour un contrôle maximal, nous recommandons d'installer Gitleaks à partir des sources.

git clone https://github.com/gitleaks/gitleaks.git
cd gitleaks
make build

La première fois que vous exécutez Gitleaks, vous pouvez créer un rapport de référence pour n'obtenir des résultats que pour les nouvelles expositions de secrets.

gitleaks detect --report-path gitleaks-report.json

Lors des invocations ultérieures, vous devriez référencer votre gitleaks-report.json fichier pour scanner les logs Git à la recherche uniquement des secrets ajoutés depuis la création de votre rapport de référence.

gitleaks detect --baseline-path gitleaks-report.json --report-path findings.json

Votre findings.json fichier contiendra des détails sur le hachage de commit et l'auteur de chaque fuite potentielle, vous aidant ainsi à vous concentrer sur les corrections.

Alternatives et mises en garde

Malheureusement, il n'y a pas beaucoup d'options au-delà de Gitleaks. D'autres projets open source de détection de secrets n'ont pas eu de commit depuis des années — ce qui n'inspire pas vraiment confiance pour protéger les applications sur lesquelles vous travaillez aujourd'hui. Si vous êtes un fournisseur de services, vous pouvez vous inscrire au programme de partenariat de GitHub pour la détection de secrets, qui identifie lorsque vos utilisateurs commettent accidentellement vos formats de jetons secrets dans l'un de leurs dépôts.

#4 : Tests de sécurité des applications statiques (SAST)

Comment le SAST aide-t-il ?

Le SAST est le peigne fin des outils de sécurité des applications, analysant votre base de code ligne par ligne pour vérifier la syntaxe, la structure ou la logique défectueuses qui pourraient rendre votre application vulnérable. Pensez aux attaques par injection SQL, aux opportunités de cross-site scripting (XSS), aux dépassements de tampon, et plus encore. En vérifiant par rapport aux bases de données populaires de CVEs connus, un outil SAST solide vous donnera l'assurance que vous ne laissez pas de failles de sécurité majeures sur la table — et certains offrent même des suggestions de correctifs automatiques pour une remédiation rapide.

Installez et exécutez votre projet OSS SAST : Semgrep

Semgrep analyse votre code, détecte les bugs et applique les standards de code établis à chaque invocation, avec la prise en charge de plus de 30 langages. Par souci de simplicité, nous nous concentrons sur Semgrep CLI, qui n'est qu'une partie d'un écosystème de produits complexe.

La manière la plus universelle d'installer Semgrep CLI est via Python/pip.

python3 -m pip install semgrep

Effectuez votre première analyse pour créer un rapport des failles et vulnérabilités au niveau du code sous forme de fichier JSON.

semgrep scan --json --json-output=semgrep.json

Alternatives et mises en garde

Le monde du SAST regorge d'opportunités — si Semgrep ne vous convient pas, découvrez des alternatives spécifiques à certains langages comme Bandit (Python), Gosec (Go), ou Brakeman (Ruby on Rails) pour bien démarrer.

#5: Tests de sécurité des applications dynamiques (DAST)

Comment le DAST contribue-t-il à la sécurité des applications ?

Contrairement au SAST, le DAST simule les vulnérabilités couramment exploitées contre votre application dans un environnement réel. Il s'agit moins de la syntaxe et de la structure du code que vous avez écrit et bien plus de la reproduction des approches qu'un attaquant pourrait adopter contre votre déploiement en production. Les outils DAST vérifieront les CVE connues dans les frameworks et bibliothèques que vous utilisez et testeront si les utilisateurs connectés peuvent accéder à des données sensibles en raison de permissions défaillantes ou de « combinaisons toxiques » de multiples vulnérabilités qui exposent votre application à des conséquences bien pires.

Installez et exécutez votre projet DAST OSS : Nuclei

Nuclei est un scanner de vulnérabilités piloté par la communauté qui utilise des modèles pour envoyer des requêtes à l'application que vous souhaitez sécuriser, exécutée dans un environnement local. Vous pouvez écrire des modèles personnalisés en utilisant YAML, mais la communauté Nuclei dispose également d'une vaste bibliothèque de modèles préconfigurés pour tester votre application.

Vous avez besoin de Go sur votre poste de travail local pour installer Nuclei.

go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

À partir de là, le moyen le plus simple d'exécuter Nuclei est de spécifier une seule cible – votre application s'exécutant localement dans un environnement de développement – et de tirer parti de la bibliothèque de modèles, que Nuclei active par défaut.

nuclei -u localhost:5678 -je nuclei-report.json

Alternatives et mises en garde

Le Zed Attack Proxy (ZAP) est un scanner fantastique activement maintenu par une équipe mondiale d'experts en sécurité et de développeurs. Cependant, contrairement aux autres de cette liste, ZAP est une application graphique par défaut. Il existe des options pour utiliser votre terminal, mais elles ne sont pas exactement les plus conviviales pour les développeurs comparées aux autres processus que vous avez suivis jusqu'à présent.

#6 : Analyse de l'Infrastructure as Code (IaC)

Comment l'analyse IaC contribue-t-elle à la sécurité des applications ?

Votre code n'est que la moitié de l'équation pour la mise en production — aujourd'hui, la plupart des équipes utilisent des outils IaC comme Terraform, CloudFormation et les charts Helm Kubernetes « de base » pour provisionner des services cloud de manière déclarative, versionnée et reproductible. Les scanners IaC identifient les vulnérabilités dans ces plans JSON ou YAML afin de vous empêcher de déployer un état non sécurisé en production.

Installez et exécutez votre projet d'analyse IaC OSS : Checkov

Checkov analyse de nombreux types de code IaC — configurations Terraform, charts Helm, Dockerfiles, et plus encore — à la recherche de mauvaises configurations courantes et de vulnérabilités de sécurité potentielles. Avec plus de 1 000 contrôles de politique intégrés pour AWS, GCP et Azure, l'outil vous aide rapidement à comprendre les risques et opportunités actuels de vos déploiements cloud en quelques minutes.

L'équipe recommande d'installer Checkov localement via le gestionnaire de paquets de Python.

python -m pip install checkov

Vous pouvez ensuite exécuter Checkov sur votre répertoire de travail (ou un autre répertoire où vous avez stocké des fichiers IaC) et obtenir un fichier JSON en sortie.

checkov --directory . -o json

#7: Analyse d'images de conteneurs

Comment l'analyse d'images de conteneurs contribue-t-elle à la sécurité des applications ?

Nous apprécions les conteneurs car ils abstraient une grande partie de la complexité, mais chaque fois que vous construisez une image de conteneur, elle peut hériter de vulnérabilités de son image de base ou de ses dépendances de package. Les scanners d'images de conteneurs découvrent les vulnérabilités dans vos images de base et Dockerfiles, quelle que soit la profondeur de l'arbre de dépendances, pour vous empêcher de déployer involontairement une application exploitable.

Et c'est ainsi que sont nées les vulnérabilités des images conteneurs.

Installez et exécutez votre projet d'analyse d'images de conteneurs OSS : Trivy

Trivy est un scanner de sécurité polyvalent capable d'analyser vos images de conteneurs à la recherche de vulnérabilités connues avec des CVE, de problèmes et de mauvaises configurations IaC, de la présence de secrets, et plus encore. L'équipe Aqua Security, qui est derrière le projet open source Trivy, maintient une base de données publique d'informations sur les vulnérabilités, recueillies auprès de plus d'une douzaine de sources de données.

Conformément aux autres mécanismes d'installation recommandés jusqu'à présent, nous recommandons d'utiliser le script de Trivy pour une installation directe depuis la dernière version de GitHub.

curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin v0.51.1

Par défaut, Trivy analyse les images de conteneurs à la recherche de vulnérabilités, de mauvaises configurations et de secrets contre toute image de conteneur que vous spécifiez, avec des résultats au format JSON standard.

trivy image --format json --output trivy-result.json <YOUR-IMAGE>

Alternatives et mises en garde

Si vous avez suivi jusqu'ici, vous avez déjà Grype installé sur votre poste de travail local depuis la section précédente sur le SCA, et il fonctionne parfaitement pour l'analyse d'images de conteneurs avec un SBOM créé par Syft. Si vous êtes sur AWS, c'est un autre endroit où Amazon Inspector peut s'avérer utile pour faire d'une pierre deux coups.

Amazon Inspector est également une option, mais avec deux réserves importantes : premièrement, il ne fonctionne qu'avec les déploiements AWS, et deuxièmement, ce n'est pas un logiciel open source comme le reste de nos recommandations, ce qui signifie qu'il entraîne de nouveaux coûts mensuels.

#8 : Analyse des licences open source

Comment l'analyse des licences open source contribue-t-elle à la sécurité des applications ?

La légalité de l'utilisation de logiciels open-source dans vos produits commerciaux n'est pas quelque chose que vous vérifiez une seule fois avec les équipes juridiques ou de conformité pour ensuite l'oublier. Les projets OSS modifient leurs licences plus fréquemment que vous ne l'imaginez, vous obligeant soit à payer pour une version entreprise, à chercher une alternative, soit à rendre open-source une partie de votre code privé. Les scanners de licences identifient les changements et vous aident à passer les audits de sécurité avec un Software Bill of Materials (SBOM) prêt à l'emploi.

Installez et exécutez votre projet OSS de scan de licences : Syft

Comme avec Grype à l'étape précédente, vous avez déjà Syft installé sur votre poste de travail local et vous pourriez même avoir un SBOM existant suite à la configuration de votre intégration SCA avec Grype. Si ce n'est pas encore le cas, vous pouvez rapidement en créer un nouveau soit en référençant une image de conteneur depuis un registre configuré, soit un chemin sur votre poste de travail local.

syft <YOUR-IMAGE> -o syft-json=sbom.syft.json
syft /path/to/image -o syft-json=sbom.syft.json

Selon la complexité de votre image et la profondeur des dépendances, vous pourriez obtenir un fichier SBOM de plusieurs milliers de lignes. Dans toute cette sortie JSON, vous recherchez dans le artefacts tableau pour le licences les valeurs de chaque package et dépendance sur lesquels votre image de conteneur repose.

{
"artifacts":[
   {
"id":"cdd2655fffa41c69",
"name":"alpine-baselayout",
"version":"3.4.3-r2",
"type":"apk",
"foundBy":"apk-db-cataloger",
"locations":[
       …
     ],
"licenses":[
       {
"value":"GPL-2.0-only",
"spdxExpression":"GPL-2.0-only",
"Type":"declared",
         …

Avec ces détails regroupés dans un seul SBOM, vous pourrez analyser vos obligations de licence pour les changements que vous pourriez avoir à apporter en aval ou les migrations que vous devriez commencer à préparer. Vous disposerez également d'une ressource de référence pour le prochain audit de sécurité auquel vous serez soumis.

Alternatives et mises en garde

Trivy, mentionné pour la première fois dans la section précédente, dispose d'une fonction d'analyse de licence qui vous présente des résultats argumentés sur les risques associés aux projets de votre arbre de dépendances open source.

#9 : Détection de malwares

Comment la détection de malwares contribue-t-elle à la sécurité des applications ?

Les scanners de malwares vous aident à identifier une menace qui a pris de l'ampleur ces dernières années : les malwares injectés dans les paquets de dépendances par des attaquants. La récente tentative de backdoor zx en est un exemple fantastique, et effrayant. Les scanners de malwares détectent ces attaques de la chaîne d’approvisionnement logicielle avant même que vous ne mergeiez votre code, vous évitant ainsi d'avoir à effectuer des corrections coûteuses et urgentes une fois que la CVE est rendue publique.

Installez et exécutez votre projet OSS de détection de malwares : Phylum

Les outils CLI de Phylum vous permettent de soumettre vos fichiers de verrouillage (lockfiles) à leur API pour une analyse des dépendances, ce qui diffère légèrement des autres outils open-source que nous recommandons ici – l'analyse ne se fait pas sur votre poste de travail local. Au lieu de cela, vous devez créer un compte Phylum pour l'authentification avec leur service.

Commencez par installer Phylum localement.

curl https://sh.phylum.io | sh

Ensuite, enregistrez votre compte et exécutez votre première analyse — Phylum devrait identifier le lockfile que vous utilisez.

phylum auth register
phylum auth login
phylum init
phylum analyze --json

L'analyse de Phylum fournit un résultat complet, commençant par un true ou faux résultat basé sur la réussite de votre projet au contrôle de malware de Phylum. Sous le tableau de rejets pour chaque dépendance, vous trouverez une description détaillée de la vulnérabilité et des conseils de remédiation de la communauté OSS. Cela vous permet d'agréger les résultats de vos tests SAST, DAST et SCA, vous donnant les moyens de comprendre quelles vulnérabilités sont dues à vos dépendances et lesquelles sont directement intégrées dans le code que vous avez écrit.

{
"is_failure": true,
"incomplete_packages_count": 2,
"help": "...",
"dependencies": [
   {
"purl": "pkg:npm/next@13.5.6",
"registry": "npm",
"name": "next",
"version": "13.5.6",
"rejections": [
       {
"title": "next@13.5.6 is vulnerable to Next.js Server-Side Request Forgery",
"source": {
"type": "Issue",
"tag": "HV00003FBE",
"domain": "vulnerability",
"severity": "high",
         ...

#10 : Détection runtime de fin de vie (EOL)

Comment la détection des runtimes EOL contribue-t-elle à la sécurité des applications ?

Plus vous incluez de frameworks, de bibliothèques et de runtimes dans votre application, plus il y a d'opportunités d'être exploité dangereusement contre des versions obsolètes ou des dépendances non maintenues. Ceci est particulièrement critique pour les runtimes directement exposés à l'internet public. Les détecteurs de runtimes EOL lisent votre arbre de dépendances via les lockfiles – même ceux dans les conteneurs – pour vous alerter bien à l'avance afin que vous puissiez vous préparer aux mises à jour ou aux migrations.

Installez et exécutez votre projet OSS : endoflife.date

endoflife.date est une base de données d'informations EOL concernant plus de 300 outils et plateformes, dont beaucoup sont essentielles au fonctionnement et à la sécurité de votre application. Au lieu d'avoir à explorer des sites de documentation obscurs ou à parcourir des listes de diffusion pour découvrir quand une version spécifique de votre dépendance n'est plus maintenue, vous pouvez rapidement planifier les mises à niveau nécessaires afin de prioriser vos efforts futurs.

Le moyen le plus simple de découvrir les données EOL est d'explorer le site, en accordant une attention particulière à vos langages de programmation, bases de données, frameworks, outils de déploiement et CLI pour les services cloud.

En tant que développeur, vous pourriez préférer une approche plus centrée sur la CLI pour explorer les données EOL de vos principaux runtimes et bibliothèques. endoflife.date propose une API simple qui génère des données JSON, que vous pouvez également ajouter à un fichier local pour référence ultérieure.

curl --request GET \
 --url https://endoflife.date/api/nginx.json \
 --header 'Accept: application/json' \
>> eol.json

Un nouveau problème : Gérer toutes vos données de scan de code et de sécurité applicative

Si vous avez suivi jusqu'ici, vous avez construit une boîte à outils pratique d'outils d'analyse de code et de configuration open source. Vous êtes prêt à les exécuter sur vos projets et branches stockés localement pour de bien meilleures garanties de sécurité avant le commit. À vous de jouer, shift left !

Votre avenir, cependant, n'est pas instantanément sans faille. Cette nouvelle boîte à outils s'accompagne d'une mise en garde importante : vos outils ne communiquent pas entre eux, et seulement autour de votre application.

Vous êtes toujours tenu de :

1. Configurez chaque outil individuellement. Prenons une option simple, comme une liste blanche de certains répertoires ou dépendances que vous ne souhaitez pas scanner, car ils ne sont pas pertinents pour la sécurité de votre environnement de production. Vous devrez apprendre les arguments de chaque outil CLI en lisant la documentation et en effectuant des tests, ce qui vous fait perdre un temps précieux que vous pourriez consacrer à ce que vous voulez réellement faire : implémenter des correctifs.
   
2. Exécutez chaque scanner sur chaque dépôt et branche. Même si vous avez un seul dépôt et deux branches—principal et dev — cela représente près de 20 opérations pour scanner les vulnérabilités. Idéalement, vous exécutez ces scanners avant de pousser des modifications vers un dépôt distant, ce qui implique de nombreuses opérations répétées tout au long de votre journée.
   
   Il existe bien sûr des moyens de simplifier cela. Vous pouvez écrire un script pour chaîner ces scanners open source afin de les exécuter manuellement ou comme un hook Git de pré-commit. Cela vous fait gagner du temps dans le terminal, mais ne fait qu'accélérer la génération de la sortie JSON — vous êtes toujours responsable de la compréhension Quoia changé et si vous pouvez toujours pousser vos modifications et (finalement) créer votre pull request.
   
3. Parcourir d'énormes tableaux JSON pour en tirer des informations. Ces outils produisent souvent des sorties de milliers de lignes. L'exhaustivité est bonne, mais qui a le temps d'explorer des dizaines ou des centaines de problèmes de sécurité potentiels, en espérant comprendre chacun suffisamment bien pour en saisir la gravité?
   
   Avec le temps, vous aurez besoin d'un moyen plus intuitif de lire les résultats que des lignes JSON non formatées, comme l'importation dans Google Sheets ou la création d'une application simple pour visualiser les résultats.
   
4. Comprendre ce qui a changé entre les exécutionsL'analyse de sécurité a deux objectifs. Premièrement, vous aider à identifier les problèmes existants dans votre code et votre configuration. Deuxièmement, vous empêcher d'introduire de nouvelles vulnérabilités au fur et à mesure que vous développez. Si vous ne pouvez pas rapidement vérifier si vous avez corrigé une certaine vulnérabilité ou si vous n'êtes pas averti lorsqu'une nouvelle s'introduit dans votre code, tout cet effort est une perte de temps.
   
   Une option consiste à incrémenter ou horodater vos fichiers JSON de sortie, puis à utiliser des outils CLI pour les comparer. diff file1.json file2.json est un excellent outil autonome, ou vous pouvez essayer git diff --no-index file1.json file2.json pour les fichiers non commités dans votre dépôt Git.
   
5. Agréger, stocker et partager les données pour une analyse à long terme. Comme nous l'avons déjà dit, l'analyse de sécurité est une opération continue, et non un élément ponctuel sur votre liste de tâches. De plus, les résultats de vos efforts d'analyse ne devraient pas être enfermés sur votre poste de travail local — vos pairs voudront connaître les vulnérabilités les plus pertinentes pour ce qu'ils ont construit, même s'ils n'ont pas un ensemble d'outils similaire en cours d'exécution à ce moment-là.
   
   Vous devrez explorer des plateformes de données qui regroupent toutes ces informations en un seul endroit — encore une autre pièce d'infrastructure à auto-héberger ou à payer.
   
6. Créer des tickets dans Jira ou GitHub. Vous ou un collègue devez escalader chaque vulnérabilité identifiée dans un ticket pertinent contenant tout le contexte nécessaire et les remédiations possibles. C'est le seul moyen d'assurer la transparence de la sécurité, d'inciter vos collègues à collaborer et de créer le journal d'audit que vos normes de conformité pourraient exiger. Aucun de ces outils ne prend en charge l'intégration avec votre plateforme de tickets, vous devrez donc créer ces tickets manuellement — et il pourrait y en avoir des dizaines, voire des centaines, à traiter.
   
7. Prioriser ces tickets en fonction de leur gravité. Inonder vos dépôts de tickets est un cauchemar pour la gestion de projet. C'est une version différente mais tout aussi pénible de la fatigue d'alerte : comment savoir sur quoi se concentrer en premier ? Si vos outils OSS ne peuvent pas vous aider avec la gravité, vous devrez passer du temps à faire ces déterminations vous-même, ce qui pourrait impliquer des années de connaissances en sécurité que vous ne pouvez tout simplement pas contourner.
   
8. Gérer le cycle de vie de chaque outil OSS. Qu'il s'agisse de maintenir vos outils à jour, d'essayer de construire une automatisation, ou d'intégrer les exécutions et les résultats dans votre pipeline CI/CD, vous êtes désormais responsable de l'efficacité à long terme de votre boîte à outils. Vous pourriez avoir une meilleure posture de sécurité que jamais, mais à quel prix pour votre posture réelle ?
   
9. Inquiétez-vous et demandez-vous ce qui se passe si le projet perd son mainteneur. Si vos dépendances et runtimes peuvent atteindre la fin de vie (EOL) et créer des problèmes, il en va de même pour les outils et plateformes dont dépend votre environnement de développement local. Malheureusement, les projets open source sont souvent construits sur des modèles de financement et de mainteneur qui ne sont pas durables à long terme. Vous pouvez toujours utiliser des projets stagnants ou abandonnés dans votre CLI, mais lorsque vous essayez d'améliorer la sécurité de votre application, ils ne vous aideront pas à découvrir de nouvelles vulnérabilités ou méthodes d'attaque.

La conversation actuelle dans l'outillage des développeurs tourne autour d'un concept unique : l'expérience développeur (DX). Plus la DX est bonne, plus un outil a de chances d'être intégré, utilisé, valorisé et promu. Et soyons honnêtes, la DX de cette boîte à outils de scan OSS exécutée localement n'est pas particulièrement excellente. Vous maîtrisez entièrement votre processus et vos données, mais à des coûts et un engagement de temps exceptionnels. Combien êtes-vous prêt à payer pour une sécurité applicative avancée ?

Les outils de sécurité open source sont incroyables — nous avons même construit un pare-feu applicatif pour protéger de manière autonome les applications Node.js contre les attaques courantes et critiques — mais pour l'analyse de sécurité continue et la remédiation des vulnérabilités, il doit y avoir une autre voie. Peut-être même une qui soit construite sur cette fantastique fondation OSS.

Une nouvelle solution de sécurité applicative : Aikido

Aikido remplace toutes ces solutions open source ponctuelles par une plateforme de sécurité de bout en bout.

Au lieu d'exécuter plus de 10 outils chaque fois que vous vous apprêtez à commettre vos dernières modifications, il vous suffit d'ajouter vos dépôts, images Docker et fournisseurs cloud à Aikido une seule fois pour une analyse complète. Aikido s'exécute automatiquement en arrière-plan pour une analyse continue ou dans votre pipeline CI/CD pour des recommandations ciblées à chaque pull request, vous protégeant des nouvelles vulnérabilités tout en signalant celles existantes qui se cachent dans votre codebase depuis des mois ou des années.

Mieux encore, tous les résultats, le contexte et les remédiations possibles sont agrégés et stockés en un seul endroit — le tableau de bord Aikido — de sorte que vous n'avez jamais à vous soucier de l'analyse de JSON, de la fusion de multiples sources de données, ou de dépenser pour une plateforme de gestion de données coûteuse afin de créer une source de vérité. Nous avons même développé des règles personnalisées et une « colle » spéciale entre ces projets open source pour découvrir des corrélations et des résultats qui nécessiteraient autrement un chercheur en sécurité spécialisé interne.

Aikido s'intègre également à vos plateformes de gestion des tâches et de messagerie, comme GitHub et Slack, pour créer des tickets pré-triés et pré-priorisés. Avec tout le contexte, la documentation et les autofixes suggérés, n'importe quel membre de votre équipe peut prendre en charge le problème et le mener à bien jusqu'à la remédiation rapidement et de manière exhaustive.

La sécurité des applications serait dans une bien pire posture sans ces outils open source et bien d'autres. C'est indiscutable. Mais la façon dont les outils de développement fonctionnent – sur votre poste de travail local, dans votre terminal – signifie qu'ils sont à la fois infiniment flexibles et intrinsèquement isolés. Le mème « ça marchait sur ma machine » s'applique toujours ici, juste avec une formulation différente :

Si vous cherchez une autre voie, qui remplace tout le fardeau de la construction de cette boîte à outils open source par une plateforme déjà construite sur les mêmes projets, envisagez d'essayer Aikido gratuitement.

Si vous choisissez la voie OSS, vous avez nos félicitations et notre respect… mais pendant que vous superposez de nouveaux outils et dépendances dans vos workflows, vous devriez vraiment laisser le pare-feu applicatif d'Aikido protéger de manière autonome et continue vos applications Node.js, même contre les vulnérabilités les plus vicieuses. La meilleure DX, après tout, c'est quand l'outil fait vraiment tout le travail difficile pour vous.