Vous avez confiance en vos compétences en matière de développement, suffisamment pour savoir que les applications que vous avez créées ne sont pas totalement exemptes de failles de sécurité et de configuration. Vous avez également fait des recherches sur le vaste écosystème d'outils d'analyse disponibles et vous avez peut-être été submergé par l'ampleur du choix. Quel est le bon "portefeuille" d'outils de sécurité des applications open-source pour identifier les vulnérabilités dans vos dépendances, vos configurations d'Infrastructure as Code (IaC), vos conteneurs et bien plus encore ?
Pour vous mettre sur la bonne voie, nous allons couvrir 10 catégories essentielles d'outils d'analyse de code et de sécurité, et recommander 9 projets OSS, avec juste les informations essentielles dont vous avez besoin pour commencer :
- Comment cette analyse contribue à la sécurité de votre application.
- Quel projet open-source vous pouvez installer et comment l'exécuter.
- Vous avez le choix entre quelques alternatives (lorsqu'elles sont disponibles).
Vous disposerez ainsi d'une méthode simple pour analyser vos applications afin de détecter les problèmes de sécurité critiques dans le code et les configurations en nuage. Qu'est-ce qu'il ne faut pas aimer ?
La configuration et la gestion ne sont pas toutes roses, mais nous y reviendrons plus tard.
Ce dont vous avez besoin
Apportez simplement votre poste de travail local, qu'il s'agisse d'un ordinateur de bureau ou d'un ordinateur portable - peu importe que vous utilisiez macOS, Windows ou Linux.
Un environnement de développement est facultatif mais recommandé. Pour faire fonctionner cette suite d'outils d'analyse open-source, vous devrez installer un grand nombre de logiciels que vous ne souhaiteriez pas avoir sur votre système d'exploitation de base, ce qui nécessiterait des mises à jour plus importantes, polluerait votre autocomplétion et vous contraindrait à utiliser des outils spécifiques qui pourraient ne pas fonctionner pour l'ensemble de vos projets. Un environnement de développement conteneurise et isole, dans une certaine mesure, tous les outils spécifiques au développement du reste de votre système d'exploitation.
Heureusement, vous pouvez choisir parmi d'excellents outils open-source :
- Avec Docker, vous pouvez créer un nouveau conteneur vide nommé
devenv-01comme suit :docker run --name devenv-01 -it ubuntu:24.04 sh - Avec Daytonaqui est livré avec de nombreuses "piles incluses" pour les flux de travail de développement :
daytona créer --code - Ou avec Distroboxqui intègre n'importe quelle distribution Linux dans votre terminal et vous permet d'installer des logiciels.
L'avantage d'un environnement de développement est qu'une fois que vous avez terminé avec une "pile" particulière, vous pouvez supprimer le conteneur en toute sécurité sans affecter votre poste de travail.
#1 : Gestion de la posture de sécurité dans le nuage (CSPM)
Comment le CSPM contribue-t-il à la sécurité des applications ?
CSPM vous aide à renforcer la sécurité et la conformité de vos environnements en nuage. En surveillant continuellement 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 classent par ordre de priorité en fonction de leur criticité et proposent des recommandations pour y remédier. Avec le CSPM, vous vous appropriez davantage les lignes de base et les garde-fous qui vous empêchent ou empêchent d'autres personnes de mettre en production des applications vulnérables, 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 CloudSploitvous aurez d'abord besoin de Node.js pour télécharger ses dépendances et lancer le moteur.
git clone https://github.com/aquasecurity/cloudsploit.git
cd cloudsploit
npm install
Ensuite, vous devez configurer CloudSploit avec des permissions de lecture sur votre compte cloud, avec la prise en charge de AWS, L'azur, PCGet Oracle. Suivez les instructions de votre fournisseur de cloud, en utilisant la commande config_example.js fichier comme modèle, pour créer un config.js avec tous les détails dont vous aurez besoin pour lancer votre premier diagnostic complet et obtenir des résultats en JSON.
./index.js --collection=file.json config.js
#2 : Analyse de la composition logicielle (SCA) des dépendances des logiciels libres
Comment le SCA contribue-t-il à la sécurité des applications ?
Vos applications ont inévitablement une grande arborescence de dépendances open-source sur lesquelles vous vous appuyez désormais, depuis votre cadre d'interface utilisateur jusqu'aux bibliothèques d'aide que vous utilisez dans une seule LOC, comme un validateur pour les adresses e-mail. L'ACS 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 permanence. Comme vos outils SCA vous informent des nouvelles vulnérabilités et des mesures correctives, vous aurez la certitude que votre chaîne d'approvisionnement en logiciels libres reste une aide, et non un obstacle, à la productivité.
Installez et exécutez vos projets OSS SCA : Syft + Grype
Pour les SCA gérés localement, vous aurez besoin de Syft pour créer une nomenclature logicielle (SBOM) et de Grype pour analyser cette nomenclature à la recherche de vulnérabilités connues. Comme Syft et Grype sont produits par la même équipe, ils prennent en charge de nombreuses méthodes d'installation, mais recommandent chacun leur propre ligne de conduite :
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 un SBOM pour votre conteneur, en remplaçant <YOUR-IMAGE> avec une image dans un registre de conteneurs configuré ou dans un répertoire local.
syft <YOUR-IMAGE> -o syft-json=sbom.syft.json
Vous obtiendrez un sbom.syft.json dans votre répertoire de travail, que vous pouvez ensuite introduire dans Grype.
grype sbom:path/to/syft.json -o json
Grype imprime ensuite un résumé de la vulnérabilité dans le format ci-dessous, y compris des détails sur la gravité et des 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 SCA - elle n'offrira pas une parité de fonctionnalités 1:1, mais elle sera plus que suffisante pour vous permettre de démarrer.
#3 : Détection des secrets
Comment la détection des secrets contribue-t-elle à la sécurité des applications ?
A outil de détection des secrets analyse votre code et vos configurations à la recherche d'informations d'identification que vous ne souhaitez pas exposer publiquement. Ces secrets peuvent inclure des clés d'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 bien plus encore. processus pénible pour les supprimer de votre historique Git - mieux vaut les détecter rapidement et prendre des mesures avant d'effectuer un commit.
Installez et exécutez votre projet de détection des secrets OSS : Gitleaks
Gitleaks analyse vos dépôts pour détecter la présence de secrets codés en dur, passés ou présents, en analysant les journaux Git. Ses détecter identifie les secrets qui ont déjà été commis, tandis que le comportement protéger analyse les modifications non validées pour vous éviter de commettre des erreurs.
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 base qui vous donnera des résultats uniquement pour l'exposition de nouveaux secrets.
gitleaks detect --report-path gitleaks-report.json
Lors des invocations suivantes, vous devez faire référence à votre gitleaks-report.json pour rechercher dans les journaux Git uniquement les secrets ajoutés depuis la création du rapport de base.
gitleaks detect --baseline-path gitleaks-report.json --report-path findings.json
Votre findings.json contiendra des détails sur le hash du commit et l'auteur de chaque fuite potentielle, ce qui vous aidera à vous concentrer sur les correctifs.
Alternatives et mises en garde
Malheureusement, il n'y a pas beaucoup d'options au-delà de Gitleaks. D'autres projets de détection de secrets en code source ouvert ont été lancés il y a plusieurs 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 pour l'analyse des secrets de programme partenaire d'analyse des secrets de GitHubCe programme permet d'identifier les utilisateurs qui transfèrent accidentellement vos formats de jetons secrets dans l'un de leurs dépôts.
#4 : Tests statiques de sécurité des applications (SAST)
Quelle est l'utilité de SAST ?
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éfectueuse qui pourrait rendre votre application vulnérable. Pensez aux attaques par injection SQL, aux possibilités de scripts intersites (XSS), aux débordements de mémoire tampon, etc. En vérifiant les bases de données populaires de CVE connus, un outil SAST solide vous donnera l'assurance que vous ne laissez pas d'importantes failles de sécurité sur la table - et certains proposent même des suggestions de correction automatique pour une remédiation rapide.
Installez et exécutez votre projet OSS SAST : Semgrep
Semgrep analyse votre code, trouve les bogues et applique les normes de code établies à chaque invocation, avec un support pour plus de 30 langages. Par souci de simplicité, nous nous concentrons sur l'interface de programmation Semgrep, qui n'est qu'un élément d'un écosystème complexe de produits.
La façon la plus universelle d'installer le CLI Semgrep est avec Python/pip.
python3 -m pip install semgrep
Exécutez votre première analyse pour créer un rapport des failles et vulnérabilités au niveau du code sous la forme d'un fichier JSON.
semgrep scan --json --json-output=semgrep.json
Alternatives et mises en garde
Le monde des SAST regorge d'opportunités - si Semgrep ne vous convient pas, découvrez des alternatives spécifiques aux langues comme Bandit (Python), Gosec (Go), ou Brakeman (Ruby on Rails) pour commencer.
#5 : Tests dynamiques de sécurité des applications (DAST)
Comment DAST contribue-t-il à la sécurité des applications ?
Contrairement à SAST, 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 que de la reproduction des approches qu'un attaquant pourrait adopter contre votre déploiement de production. Les outils DAST vérifient les CVE connus dans les frameworks et les bibliothèques que vous utilisez et testent si les utilisateurs connectés peuvent accéder à des données sensibles en raison de permissions non respectées ou de "combinaisons toxiques" de vulnérabilités multiples qui exposent votre application à des conséquences bien plus graves.
Installez et exécutez votre projet OSS DAST : Nuclei
Nuclei est un scanner de vulnérabilités communautaire qui utilise des modèles pour envoyer des requêtes à l'application que vous souhaitez sécuriser et qui tourne 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 à tester avec votre application.
Vous avez besoin Go sur votre poste de travail local pour installer Nuclei.
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest
À partir de là, la façon la plus simple d'utiliser Nuclei est de spécifier une cible unique - votre application fonctionnant 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 proxy Zed Attack Proxy (ZAP) est un fantastique scanner activement entretenu par une équipe mondiale d'experts en sécurité et de développeurs. Cependant, contrairement aux autres produits de cette liste, ZAP est une application graphique par défaut. Il existe des options pour utiliser votre terminalIl existe des options pour utiliser votre terminal, mais elles ne sont pas exactement les plus conviviales pour les développeurs par rapport aux autres processus que vous avez suivis jusqu'à présent.
#6 : Analyse de l'infrastructure en tant que code (IaC)
Comment l'analyse IaC contribue-t-elle à la sécurité des applications ?
Aujourd'hui, la plupart des équipes utilisent des outils IaC tels que Terraform, CloudFormation et les diagrammes Helm de Kubernetes "de base" pour fournir des services cloud de manière déclarative, contrôlée par version et reproductible. Les scanners IaC identifient les vulnérabilités dans ces blueprints JSON ou YAML pour vous empêcher de déployer un état non sécurisé en production.
Installez et exécutez votre projet de numérisation OSS IaC : Checkov
Checkov analyse de nombreux types de code IaC - configurations Terraform, diagrammes Helm, fichiers Docker, etc. - à la recherche d'erreurs de configuration 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 les opportunités actuels de vos déploiements dans le 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 lancer Checkov dans votre répertoire de travail (ou dans un autre répertoire où vous avez stocké des fichiers IaC) et obtenir un fichier JSON en sortie.
checkov --directory . -o json
#7 : Numérisation de l'image du conteneur
Comment l'analyse des images de conteneurs contribue-t-elle à la sécurité des applications ?
Nous aimons les conteneurs parce qu'ils font abstraction d'une grande partie de la complexité, mais chaque fois que vous construisez une image de conteneurelle peut hériter des vulnérabilités de son image de base ou de ses dépendances. Les scanners d'images de conteneurs découvrent les vulnérabilités dans vos images de base et vos fichiers Docker, quelle que soit la profondeur de l'arbre des dépendances, afin de vous empêcher de déployer involontairement une application exploitable.
C'est également ainsi que sont nées les vulnérabilités des images de conteneurs.
Installez et exécutez votre projet de numérisation 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 CVE, de problèmes IaC et de mauvaises configurations, de la présence de secrets, et bien plus encore. L'équipe Aqua Security, qui est à l'origine du 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.
En accord avec les autres mécanismes d'installation recommandés jusqu'à présent, nous recommandons d'utiliser le script de Trivy pour installer directement 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, vous avez déjà installé Grype sur votre station de travail locale depuis la section précédente sur SCA, et il fonctionne parfaitement pour analyser les 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 gros bémols : premièrement, il ne fonctionne qu'avec les déploiements AWS et deuxièmement, il ne s'agit pas d'un logiciel libre comme le reste de nos recommandations, ce qui signifie qu'il s'accompagne de nouveaux coûts mensuels.
#8 : Analyse des licences de logiciels libres
Comment l'analyse des licences open-source contribue-t-elle à la sécurité des applications ?
La légalité de l'utilisation de logiciels libres dans vos produits commerciaux n'est pas une chose que vous vérifiez une fois avec les équipes juridiques ou de conformité et que vous oubliez. Les projets de logiciels libres changent de licence plus fréquemment que vous ne le pensez, ce qui vous oblige à payer pour une version d'entreprise, à chercher une alternative ou à mettre en open source une partie de votre code privé. Les scanners de licences identifient les changements et vous aident à passer les audits de sécurité grâce à une nomenclature logicielle prête à l'emploi.
Installez et exécutez votre projet d'analyse de licences OSS : Syft
Comme pour Grype dans la dernière étape, vous avez déjà installé Syft sur votre station de travail locale et vous avez peut-être même un SBOM existant depuis la mise en place de votre intégration SCA avec Grype. Si ce n'est pas encore le cas, vous pouvez rapidement en créer un nouveau en référençant une image de conteneur à partir d'un registre configuré, ou d'un chemin sur votre station de travail locale.
syft <YOUR-IMAGE> -o syft-json=sbom.syft.json
syft /path/to/image -o syft-json=sbom.syft.json
En fonction de la complexité de votre image et de la profondeur des dépendances, vous pouvez obtenir un fichier SBOM de quelques milliers de lignes. Dans toute cette sortie JSON, vous cherchez dans le fichier artefacts pour le tableau licences de chaque paquetage et dépendance sur lesquels votre image de conteneur s'appuie.
{
"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",
…Grâce à ces informations regroupées dans un seul et même tableau de bord, vous serez en mesure d'analyser vos obligations en matière de licences pour détecter les changements que vous pourriez devoir 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'un système de analyse des licences qui vous présente des résultats d'opinion sur le risque associé aux projets dans votre arbre de dépendance open-source.
#9 : Détection des logiciels malveillants
Comment la détection des logiciels malveillants contribue-t-elle à la sécurité des applications ?
Les scanners de logiciels malveillants vous aident à identifier une menace qui a pris de l'ampleur ces dernières années : les logiciels malveillants injectés par des pirates dans les paquets de dépendances. La récente tentative de porte dérobée de tentative de porte dérobée zx en est un exemple fantastique et effrayant. Les scanners de logiciels malveillants détectent ces attaques de la chaîne d'approvisionnement logicielle avant même que vous ne fusionniez votre code, ce qui vous évite d'avoir à apporter des correctifs coûteux et urgents une fois que le CVE est rendu public.
Installez et exécutez votre projet OSS de détection de logiciels malveillants : Phylum
L'outil CLI de PhylumL'outil CLI de Phylum vous permet de soumettre vos fichiers de verrouillage à leur API pour l'analyse des dépendances, ce qui diffère légèrement des autres outils open-source que nous recommandons ici - l'analyse n'a pas lieu sur votre poste de travail local. En effet, l'analyse ne s'effectue pas sur votre poste de travail local. Au lieu de cela, vous devez enregistrer un compte auprès de Phylum pour vous authentifier auprès de leur service.
Commencez par installer Phylum localement.
curl https://sh.phylum.io | sh
Enregistrez ensuite votre compte et lancez votre première analyse - Phylum devrait identifier le fichier de verrouillage que vous utilisez.
phylum auth register
phylum auth login
phylum init
phylum analyze --json
L'analyse de Phylum fournit un résultat complet, en commençant par un vrai ou faux selon que votre projet passe ou non la vérification des logiciels malveillants de Phylum. Sous le tableau des 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 permettant de comprendre quelles vulnérabilités sont dues à vos dépendances et lesquelles sont intégrées directement 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 de la fin de vie (EOL)
En quoi la détection de la fin de vie des applications contribue-t-elle à la sécurité des applications ?
Plus vous incluez de frameworks, de bibliothèques et de runtimes dans votre application, plus vous avez d'opportunités de vous appuyer dangereusement sur 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 runtime EOL lisent votre arbre de dépendances à travers les lockfiles, même ceux qui se trouvent dans des 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 contenant des informations sur la fin de vie de plus de 300 outils et plateformes, dont beaucoup font partie intégrante du fonctionnement et de la sécurité de votre application. Au lieu d'explorer d'obscurs sites de documentation ou de parcourir des listes de diffusion pour découvrir quand une version spécifique de votre dépendance n'est plus maintenue, vous pouvez rapidement mettre des dates autour des mises à jour nécessaires afin de prioriser vos efforts pour l'avenir.
La manière la 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, cadres de travail, outils de déploiement et CLIs pour les services en nuage.
En tant que développeur, vous souhaiterez peut-être une approche plus centrée sur l'interface de programmation pour explorer les données de fin de vie de vos principaux runtimes et bibliothèques - endoflife.date dispose d'une API simple qui produit des données JSON, que vous pouvez également ajouter à un fichier local pour référence ultérieure.
curl --request GET \N-
--url https://endoflife.date/api/nginx.json \N-
--header 'Accept : application/json' \N-
>> eol.json
Un nouveau problème : gérer toutes les données relatives à l'analyse du code et à la sécurité des applications
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 utiliser sur vos projets et branches stockés localement pour obtenir de bien meilleures garanties de sécurité avant validation. Prends ça, shift left !
Cependant, votre avenir n'est pas instantanément irréprochable. Cette nouvelle boîte à outils est assortie d'une importante mise en garde : vos outils ne parlent pas ensemble, et seulement autour de votre application.
Vous êtes toujours dans l'obligation de le faire :
- Configurez individuellement chaque outil. Prenons une option simple, comme une liste d'autorisation de certains répertoires ou dépendances que vous ne souhaitez pas analyser, 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 prive d'un temps précieux pour ce que vous voulez réellement faire : mettre en œuvre des correctifs.
- Exécuter chaque analyseur pour chaque dépôt et chaque branche. Même si vous avez un seul repo et deux branches-
principaletdev-soit près de 20 opérations pour rechercher des vulnérabilités. Dans l'idéal, vous exécutez ces scanners avant d'apporter des modifications à une application distante, ce qui signifie de nombreuses opérations répétées tout au long de la journée.
Il existe bien sûr des moyens de simplifier cela. Vous pouvez écrire un script pour enchaîner ces scanners open-source et les exécuter manuellement ou en tant que hook Git avant validation. Cela vous permet de gagner du temps au niveau du terminal, mais ne génère qu'une sortie JSON plus rapide - vous êtes toujours obligé de comprendre. ce queet si vous pouvez toujours pousser vos changements et (finalement) créer votre demande de traction. - Traverser des tableaux JSON massifs pour obtenir des informations. Ces outils produisent souvent des résultats de plusieurs milliers de lignes. L'exhaustivité est une bonne chose, mais qui a le temps d'explorer des dizaines ou des centaines de problèmes de sécurité potentiels, en espérant comprendre chacun d'entre eux suffisamment bien pour en saisir la gravité ?
Au fil du 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. - Comprendre ce qui a changé entre les passages. L'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 construisez. Si vous ne pouvez pas savoir rapidement si vous avez corrigé une certaine vulnérabilité ou si vous n'êtes pas informé de l'introduction d'une nouvelle vulnérabilité 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.jsonest un excellent outil autonome, ou vous pouvez essayergit diff --no-index file1.json file2.jsonpour les fichiers qui n'ont pas été déposés dans votre dépôt Git. - Agréger, stocker et partager les données en vue d'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 de votre liste TODO. De plus, les résultats de vos efforts d'analyse ne doivent 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 d'outil similaire en cours d'exécution en ce moment.
Vous devrez explorer les plates-formes de données qui rassemblent toutes ces informations en un seul endroit - un autre élément d'infrastructure à héberger vous-même ou à payer pour cela. - Créez des tickets dans Jira ou GitHub. Vous ou un pair devez faire remonter chaque vulnérabilité identifiée dans un ticket pertinent contenant tout le contexte nécessaire et les remèdes possibles. C'est la seule façon d'assurer la transparence de la sécurité, de faire collaborer vos pairs 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, à parcourir.
- Classez les tickets par ordre de priorité en fonction de leur gravité. Inonder vos référentiels de tickets est un cauchemar pour la gestion de projet. C'est une version différente mais tout aussi douloureuse de la fatigue des alertes : Comment savoir sur quoi se concentrer en premier ? Si vos outils OSS ne peuvent pas vous aider à déterminer la gravité, vous devrez passer du temps à faire ces déterminations vous-même, ce qui peut impliquer des années de connaissances en matière de sécurité que vous ne pouvez tout simplement pas raccourcir.
- Gérez le cycle de vie de chaque outil OSS. Qu'il s'agisse de maintenir vos outils à jour, d'essayer de développer l'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 avez peut-être une meilleure posture de sécurité que jamais, mais à quel prix pour votre posture dans le monde réel ?
- S'inquiéter et se demander ce qui se passera si le projet perd son mainteneur. Si vos dépendances et vos moteurs d'exécution peuvent arriver en fin de vie et créer des problèmes, il en va de même pour les outils et les 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 maintenance qui ne sont pas viables à 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 sur les outils de développement tourne autour d'un seul concept : l'expérience du développeur (DX). Plus l'expérience du développeur est bonne, plus l'outil sera intégré, utilisé, apprécié et défendu. Soyons honnêtes : l'expérience de développement de cet outil d'analyse OSS géré localement n'est pas particulièrement bonne. Vous êtes pleinement propriétaire de votre processus et de vos données, mais au prix de coûts et d'un investissement en temps exceptionnels. Combien êtes-vous prêt à payer pour une sécurité applicative avancée ?
Les outils de sécurité open-source sont étonnants - nous avons même construit un pare-feu d'application web pour protéger de manière autonome les applications Node.js contre les attaques courantes et critiques, mais pour l'analyse continue de la sécurité et la correction des vulnérabilités, il doit y avoir un autre moyen. Peut-être même une méthode qui s'appuie sur cette fantastique base OSS.
Une nouvelle solution de sécurité pour les applications : Aikido
Aikido intègre tous ces projets open-source et bien plus encore.
Au lieu d'exécuter plus de 10 outils à chaque fois que vous vous apprêtez à valider vos derniers changements, il vous suffit d'ajouter vos dépôts, images Docker et fournisseurs de 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 ainsi des nouvelles vulnérabilités tout en signalant les vulnérabilités existantes qui se cachent dans votre base de code depuis des mois ou des années.
Mieux encore, tous les résultats, le contexte et les remèdes possibles sont agrégés et stockés en un seul endroit - le tableau de bord Aikido - afin que vous n'ayez jamais à vous soucier de l'analyse JSON, de la fusion de plusieurs sources de données ou de l'achat d'une plateforme de gestion de données onéreuse pour créer une source de vérité. Nous avons même construit 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 l'intervention d'un chercheur en sécurité spécialisé en 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 priorisés. Grâce au contexte, à la documentation et aux corrections automatiques suggérées, n'importe quel membre de votre équipe peut prendre en charge le problème et le résoudre rapidement et de manière exhaustive.
La sécurité des applications serait bien pire sans ces outils open-source et bien d'autres. C'est indiscutable. Mais le mode de fonctionnement des outils de développement - sur votre poste de travail local, dans votre terminal - signifie qu'ils sont à la fois infiniment flexibles et intrinsèquement isolés. Le principe du "ça a marché sur ma machine" s'applique toujours ici, mais avec un verbiage différent :
Si vous êtes à la recherche d'une autre solution, 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 de d'essayer Aikido gratuitement.
Si vous choisissez la voie du logiciel libre, vous avez notre soutien et notre respect... mais pendant que vous ajoutez de nouveaux outils et dépendances à vos flux de travail, vous devriez vraiment laisser le Web Application Firewall d'Aikido protéger de manière autonome et continue vos applications Node.js contre les vulnérabilités les plus vicieuses. Le meilleur DX, après tout, c'est quand l'outil fait vraiment tout le travail à votre place.
.svg)
.jpg)
.jpg)
.jpg)
.jpg)
