Bienvenue sur notre blog.

Selon IBM et Ponemon, le coût moyen d'une violation de données est de 4,35 millions de dollars ! Il n'est donc pas étonnant que les entreprises ressentent le besoin d'investir massivement dans la cybersécurité. Pour les entreprises de technologie juridique, qui traitent quotidiennement un grand nombre de données sensibles sur leurs clients, les enjeux sont encore plus importants. Au-delà de l'impact financier immédiat, une violation de données peut causer une grave atteinte à la réputation qui est souvent beaucoup plus difficile à réparer, ce qui fait de la cybersécurité une priorité absolue pour les professionnels du droit. À mesure que le monde numérique évolue, les stratégies de protection des informations sensibles doivent également s'adapter à des menaces de plus en plus sophistiquées.

ELTA, l'association européenne de la Legal Tech, a réuni certains des plus grands experts en cybersécurité d'aujourd'hui dans une salle de réunion numérique. Roeland Delrue, cofondateur et directeur de la recherche chez Aikido Security, Aidas Kavalis, cofondateur et chef de produit chez Amberlo, Wouter Van Respaille, cofondateur et directeur technique chez Henchman et Michiel Denis, responsable de la croissance chez Henchman partagent leur expertise et leurs idées sur la façon d'installer un cadre de cybersécurité solide pour les entreprises de la LegalTech.

L'importance croissante de la cybersécurité

Quelles sont les normes fondamentales de cybersécurité que toute application de technologie juridique devrait respecter, et comment ces normes ont-elles évolué avec les menaces émergentes ? Roeland Delrue, cofondateur et directeur de la recherche chez Aikido Security, souligne que le développement d'une application juridique sécurisée commence par le code.

1. Les programmeurs écrivent l'application en code. La première couche de sécurité consiste à s'assurer que le code lui-même est sécurisé
2. Une fois que le code est prêt, il est généralement expédié dans des conteneurs - qui représentent la deuxième couche qui doit être scannée et surveillée.
3. La troisième couche est l' environnement en nuage dans lequel l'application est déployée.

Vient ensuite la quatrième couche, les domaines (login.com ou app.com) par lesquels les utilisateurs accèdent à l'application.

Conformité et contrôle continu

Wouter Van Respaille, cofondateur et directeur technique de Henchman, a souligné l'importance de la conformité aux normes industrielles telles que ISO 27001 et SOC 2. Ces certifications ne sont pas de simples cases à cocher ; elles indiquent que le fournisseur prend la sécurité au sérieux. Il a fait remarquer que les entreprises qui n'ont pas ces certifications pourraient ne pas disposer des ressources nécessaires ou ne pas s'engager en faveur de la sécurité.

Au-delà de la conformité, la surveillance continue et les approches créatives telles que les programmes de récompense des bogues sont cruciales. Ces programmes font appel à des hackers éthiques qui testent continuellement le système, offrant ainsi une couche de sécurité supplémentaire par rapport aux outils d'analyse traditionnels. M. Van Respaille décrit l'approche adoptée par Henchman : "Aikido scanne en permanence notre infrastructure et notre code. En outre, nous utilisons Intigriti pour la chasse aux bogues, ce qui implique un collectif de pirates sociaux qui sondent et explorent nos systèmes de manière créative. Comparée aux outils d'analyse traditionnels, cette approche est beaucoup plus innovante. Nous utilisons également Phished pour envoyer des simulations d'hameçonnage à tous nos employés, afin de les sensibiliser à l'hameçonnage et à la sécurité tout en ajoutant une touche de gamification. En tant qu'entreprise gérant un flux incessant de données sensibles, il est important d'avoir ces partenariats plutôt que de tout faire soi-même.

La cybersécurité étant un sujet complexe, Aidas Kavalis, cofondateur et responsable des produits chez Amberlo, souligne qu'il est judicieux de faire appel à un tiers pour évaluer les fournisseurs. "Un expert dans le domaine peut vous aider à découvrir des choses auxquelles vous n'auriez jamais pensé. Même si une norme ISO27001 ou SOC 2 est mise en œuvre, comment être sûr que le certificat correspond à la réalité ? Un professionnel aide à poser les bonnes questions et à s'assurer que les bonnes choses sont vérifiées dès le départ.

Les données juridiques sont très sensibles et précieuses

Les panélistes s'accordent à dire que les applications de technologie juridique sont confrontées à des défis de cybersécurité uniques par rapport à d'autres applications web, étant une cible privilégiée pour les pirates informatiques, au même titre que les institutions financières. Les données juridiques, tout comme les données financières, sont très sensibles et précieuses. "La différence est que les institutions financières gèrent de l'argent, alors que les cabinets d'avocats gèrent des informations sur leurs clients, qui peuvent parfois causer plus de dégâts en cas de violation. Récemment, il y a eu plusieurs attaques où des cabinets d'avocats ont été piratés, ce qui a conduit à un ciblage individuel de leurs clients. C'est pourquoi je pense que les cabinets d'avocats font définitivement partie des secteurs les plus à risque", déclare M. Kavalis.

M. Delrue recommande vivement de tenir compte de la valeur des données que vous traitez, car elle a une incidence sur le niveau de sécurité requis : "Par exemple, il y a une grande différence entre un fournisseur de technologie juridique qui se contente d'examiner les contrats sans les stocker et un fournisseur qui détient les contrats réels de nombreux clients. Plus vous détenez de données sensibles, plus vous devenez une cible attrayante pour les pirates informatiques, qui cherchent à extorquer de l'argent par le biais de ransomwares ou en vendant les données. Par conséquent, que vous soyez un fournisseur ou un consommateur de legaltech, vous devez évaluer la sensibilité et la valeur de vos données pour des acteurs malveillants potentiels. Si vos données ont une grande valeur, il est essentiel de mettre en œuvre des mesures de cybersécurité plus rigoureuses que celles d'une entreprise moyenne."

Évaluation de la sécurité des technologies juridiques

Lorsqu'ils évaluent la sécurité des produits de technologie juridique, les cabinets d'avocats doivent également tenir compte de la sensibilité et du volume des données qu'ils traitent et s'assurer que les applications disposent des mesures de sécurité nécessaires.

En tant que fournisseur de technologie juridique, Kavalis reçoit trois demandes de la part de ses clients :

1. Les certifications ISO ou SOC 2, ainsi que les questionnaires de conformité au GDPR.
2. Évaluation externe de la cybersécurité : Les grands cabinets d'avocats demandent souvent des sessions techniques, au cours desquelles ils font appel à des experts externes pour examiner en profondeur Amberlo et vérifier si la technologie et les politiques mises en place sont adéquates.
3. Et de temps en temps, des incidents de sécurité. "Heureusement, nous n'avons pas connu d'incidents de sécurité majeurs jusqu'à présent, ce que je considère comme une réussite importante. Depuis que nous avons lancé Amberlo en 2017, nous avons vu des tentatives quotidiennes d'intrusion dans nos systèmes à partir de certains lieux de piratage bien connus", explique Kavalis.

Il est facile de vérifier si une entreprise est conforme aux normes ISO 27001 ou SOC 2. Toutefois, M. Delrue insiste sur l'importance de comprendre ce que ces certifications impliquent. M. Delrue considère les certifications ISO 27001 ou SOC 2 comme un raccourci pour remplir un long questionnaire sur la sécurité, où ⅔ des cases peuvent être cochées automatiquement. Toutefois, certaines choses ne sont pas couvertes par les certifications, comme l'analyse des logiciels malveillants, qui n'est pas couverte par SOC2, par exemple. Dans certains cas, les certifications ISO standard ne suffisent donc pas et il peut être utile d'ajouter des questions plus approfondies.

Sur site ou hébergé dans le nuage ?

Avec les progrès rapides apportés par le GPT et d'autres technologies d'IA, l'évaluation de la technologie dans les cabinets d'avocats est devenue de plus en plus cruciale. Cependant, il y a toujours eu un débat entre l'hébergement sur site et l'hébergement dans le cloud. Voyons d'abord ce que cela signifie :

• Logiciel sur site : les clients possèdent physiquement les serveurs et y hébergent leurs applications.
• Le nuage privé : les clients adoptent Microsoft Azure, Google Cloud Platform ou AWS où ils exécutent toutes les applications à l'intérieur de leur réseau.
• Le nuage : les applications fonctionnent entièrement sur le nuage et les clients adaptent ensuite cette technologie.

"Je ne veux pas me faire renverser par une voiture, alors je reste chez moi pour toujours. Ou bien je peux aller quelque part, et quand je traverse la rue, je regarde d'abord à gauche et à droite pour m'assurer que je suis en sécurité".

M. Van Respaille utilise cette analogie pour comparer l'informatique sur site à l'informatique dématérialisée. Selon lui, rester sur place est dépassé. "Cela signifie que vous serez exclus d'un grand nombre d'innovations. Je conseille à tous les cabinets d'avocats d'adopter pleinement le nuage, mais de l'aborder de manière réfléchie. Sachez qu'il existe des listes de contrôle de sécurité. Il n'est pas nécessaire qu'elles soient très complexes ou qu'elles demandent beaucoup de ressources ; un questionnaire de base peut suffire pour évaluer les outils que vous souhaitez adopter. Cette approche crée une première couche de sécurité et vous permet de comprendre clairement ce que vous achetez. En résumé, "Optez pour le full cloud, mais sachez quels outils vous allez adopter".

Si certaines normes sont respectées, M. Delrue considère que la solution sur site est une option légitime : "Si vous disposez d'un programme sur site de premier ordre avec des responsables de la sécurité dédiés qui savent comment gérer ce programme sur site, il s'agit alors d'une option viable." Cependant, il pense que la sécurité de haute qualité sur site est rare. "Si vous avez affaire à des fournisseurs de services en nuage très professionnels et que vous ne disposez pas des ressources internes pour gérer votre système sur site, il est probablement plus sûr d'opter pour la version en nuage, car il existe de nombreux risques de sécurité sur site. Il s'agit donc essentiellement d'une évaluation des risques : où voulez-vous que le risque se situe, et qui voulez-vous pour gérer ce risque ?

"Très souvent, le système sur site devient un point de défaillance unique", ajoute M. Adias. "Si un périmètre est violé, cela signifie souvent que tous les autres systèmes sont également facilement accessibles. J'ai rarement vu une approche stratifiée de la cybersécurité sur site, où chaque application est isolée dans une zone de sécurité distincte.

De l'idée au déploiement

Bien entendu, les fournisseurs de technologies juridiques devraient intégrer des normes et des mesures de sécurité dès le départ, avant même que le produit ne soit construit.

"Cela commence par l'ordinateur portable du développeur de logiciels. Le développeur écrit le code, et c'est là que l'on peut faire le premier contrôle. C'est ce que fait Aikido", explique M. Delrue. "Qu'il s'agisse de code, de conteneurs, de nuage, de domaine, à chaque étape du cycle de vie du développement, Aikido peut effectuer des contrôles de sécurité. Cependant, être trop strict peut ralentir considérablement le processus de développement. C'est pourquoi Delrue conseille d'utiliser intelligemment la catégorisation des risques des vulnérabilités et des problèmes de sécurité (faible, moyen, élevé, critique). "Si vous commencez à les bloquer à un niveau moyen, vous allez ralentir le développement : ils seront arrêtés à chaque étape à cause d'un contrôle de sécurité qui doit être corrigé. Parfois, il est un peu plus facile de ne bloquer que les "problèmes critiques" et de régler les "problèmes élevés" plus tard, de manière ciblée.

Tout au long du cycle de développement, vous pouvez effectuer différents contrôles afin d'adopter une posture de sécurité adéquate. Dans le monde des produits de sécurité, on parle de "déplacement vers la gauche". "Cela signifie qu'il est possible d'attraper quelqu'un plus tôt dans le cycle, ce qui rend la correction plus facile que lorsque le produit est déjà en ligne avec le client, car à ce moment-là, le mal est fait. Car à ce moment-là, le mal est fait". explique M. Delrue.

À une époque où les violations de données peuvent coûter des millions et où les réputations ne tiennent qu'à un fil, il est clair que la cybersécurité n'est plus une option pour les entreprises de technologie juridique, c'est une nécessité. Que vous soyez en train de débattre entre le cloud et le système sur site ou d'évaluer une nouvelle solution technologique, n'oubliez pas qu'à l'ère numérique, la seule chose qui coûte plus cher que d'investir dans la cybersécurité, c'est de ne pas investir dans ce domaine.

Aikido Security est désormais disponible sur la place de marché de Drata Integration ! C'est une excellente nouvelle, car naviguer dans le paysage réglementaire actuel de la cybersécurité est un peu comme marcher sur une corde raide dans un ouragan. Les cyber-menaces évoluent, tout comme les réglementations conçues pour les contrôler. Les entreprises se retrouvent aujourd'hui aux prises avec une liste croissante d'exigences de conformité, toutes plus strictes les unes que les autres.

Dans cet article, nous allons voir comment l'intégration d'Aikido et de Drata peut vous aider à atteindre la conformité SOC 2 et ISO 27001:2022.

Que font l'Aïkido et le Drata ?

Commençons par nous familiariser avec ces deux plateformes de sécurité.

Que fait l'Aïkido ?

Aikido est la plateforme de sécurité pour les développeurs. Aikido centralise tout le code nécessaire et les scanners de sécurité dans le cloud en un seul endroit. Créée par des ingénieurs pragmatiques, nous donnons la priorité aux solutions open-source et à l'expérience des développeurs dans ce que nous construisons et comment nous le faisons. Nous nous concentrons sur ce qui est important, afin que vous ne soyez pas gêné par ce qui ne l'est pas. Gagnez des clients, progressez sur le marché, et réussissez la mise en conformité.

Aikido rend la sécurité simple pour les PME et réalisable pour les développeurs, sans jargon industriel, sans paperasserie et, franchement, sans BS.

Que fait Drata ?

Drata est une plateforme d'automatisation de la sécurité et de la conformité qui surveille en permanence et recueille des preuves des contrôles de sécurité d'une entreprise tout en rationalisant les flux de travail de conformité de bout en bout pour assurer la préparation à l'audit. L'équipe de Drata excelle dans l'utilisation de l'automatisation pour aider les entreprises de toute taille à atteindre et maintenir la conformité, par exemple en se préparant à SOC 2 ou ISO 27001:2022.

Comment fonctionne l'intégration de l'Aïkido et des Drata ?

L'intégration d'Aikido à Drata envoie automatiquement les preuves SOC 2 et ISO 27001:2022 directement à Drata via l'intégration API. Chaque jour, Aikido crée un rapport PDF et le synchronise en tant que "preuve externe" vers Drata(voir ici). Aikido crée également un contrôle avec le code 'AIKIDO' et lie les exigences SOC2 et ISO27001:2022 pertinentes. Aikido s'assure que vos informations sur les vulnérabilités sont toujours à jour. Cela permet une évaluation précise des risques et une remédiation efficace.

Tous les logiciels Aikido peuvent être intégrés à Drata. Mais, bien sûr, vous aurez également besoin d'une licence Drata pour utiliser les services de préparation à l'audit de Drata.

Où puis-je trouver les intégrations ?

Sur Aikido, l'intégration avec Drata est ici! Dans la liste des intégrations de Drata, vous pouvez trouver Aikido sous "Vulnerability Scanning", "CSPM" (Cloud Security Posture Management), et "Security Questionnaire". Vous pouvez connecter Aikido comme scanner de vulnérabilité directement depuis votre tableau de bord Drata.

Couvrir les exigences techniques de la gestion des vulnérabilités pour la conformité

Que vous soyez en mission pour vous conformer à SOC 2 ou à ISO 27001:2022, vous devrez mettre en œuvre des mesures techniques de gestion de la vulnérabilité. Qu'est-ce que cela implique ? Identifier les vulnérabilités réelles de votre base de code. Ensuite, les classer par ordre de priorité et les traiter.

Étape 1 : Procéder à une évaluation des risques de votre base de code

Analysez vos systèmes. Identifiez les faiblesses et les vulnérabilités que les attaquants pourraient exploiter, en laissant Aikido analyser votre application.

Étape 2 : Établir un ordre de priorité parmi vos vulnérabilités

Classez les vulnérabilités identifiées en fonction de leur gravité et de leur impact potentiel sur vos systèmes. La priorité doit être donnée aux vulnérabilités ayant le plus d'impact.

Étape 3 : S'attaquer aux vulnérabilités

Mettre en œuvre des correctifs. Mettre à jour les logiciels. Modifier la configuration de vos systèmes.

Étape 4 : Test d'efficacité

Après avoir remédié à vos vulnérabilités, vous devez vérifier si vos solutions ont fonctionné. La meilleure approche consiste à effectuer un pentest. Revenez à l'étape 3 si nécessaire. NB : les pentests ne sont pas obligatoires pour SOC 2 ou ISO27001:2022.

Étape 5 : Contrôle continu

Les étapes ci-dessus ne sont pas des étapes uniques. Une surveillance continue est essentielle pour maintenir des systèmes sains et identifier les menaces et les vulnérabilités émergentes. Pour ce faire, il est essentiel d'analyser régulièrement votre base de code à l'aide d'un programme de gestion des vulnérabilités.

Aikido automatise votre processus de gestion des vulnérabilités

La mise en œuvre manuelle de ce processus est laborieuse mais possible. Nous recommandons plutôt d'utiliser une plateforme de gestion des vulnérabilités facile à utiliser, telle qu'Aikido. Voyons comment Aikido procède pour les 5 étapes ci-dessus.

Étape 1 : Vérifiez votre défense - procédez à une évaluation des risques de votre base de code

Aikido se connecte à votre code et à votre infrastructure cloud, puis procède automatiquement à une évaluation des risques. Il analyse en profondeur vos systèmes, identifiant les vulnérabilités potentielles qui pourraient être exploitées par des attaquants. Aikido est sans agent, ce qui vous permet d'obtenir une vue d'ensemble en 30 secondes. Le résultat est un gain de temps et d'argent considérable : fini les heures perdues à installer des logiciels coûteux ou à configurer et maintenir des outils gratuits à code source ouvert.

Étape 2 : Identifier les menaces réelles - classer les vulnérabilités par ordre de priorité

Une fois l'évaluation des risques terminée, Aikido permet à votre cerveau de se reposer en classant les vulnérabilités par ordre de priorité. Obtenir une longue liste de toutes les vulnérabilités de votre système pourrait être accablant, c'est exactement ce qu'Aikido ne fait pas ! Au lieu de cela, Aikido déduplique et trie automatiquement les vulnérabilités et vous fournit les vulnérabilités qui comptent vraiment et qui sont exploitables. Vous pouvez désormais vous concentrer sur les vulnérabilités les plus critiques.

Etape 3 : Faire tomber vos adversaires - s'attaquer aux faiblesses

Bien que le traitement des vulnérabilités soit souvent une tâche manuelle, Aikido enlève la pression et la rend plus facile que jamais. Vous voulez faire un PR en un seul clic ? C'est désormais possible grâce à l'autofixation d'Aikido ! De plus, Aikido s'intègre parfaitement aux outils que vous utilisez déjà, qu'il s'agisse d'implémenter des correctifs, de mettre à jour des logiciels ou d'effectuer des changements de configuration.

Étape 4 : Obtenez votre ceinture noire - testez votre efficacité

Nous vous conseillons d'effectuer un pentest pour vérifier l'efficacité des correctifs mis en œuvre. Pourquoi est-ce important ? Il valide l'efficacité des mesures de sécurité et garantit que vos systèmes sont robustes face aux attaques potentielles. Ni SOC 2 ni ISO 27001:2022 n'imposent un pentest, mais ils sont recommandés. Aikido travaille avec plusieurs agences de pentest, mais vous êtes libre de choisir le consultant de votre choix.

Étape 5 : Rester en sécurité - surveillance continue

Comment maintenir des systèmes sécurisés ? Aikido maintient votre défense grâce à une surveillance continue, bien sûr ! Toutes les 24 heures, Aikido scanne votre environnement pour détecter les nouvelles vulnérabilités et les nouveaux risques. En restant proactif dans l'identification et la résolution des vulnérabilités et menaces émergentes grâce à l'analyse des vulnérabilités d'Aikido, vous avez l'esprit tranquille, que vous vous prépariez à SOC 2 et ISO 27001:2022 ou que vous poursuiviez vos activités quotidiennes comme si de rien n'était.

Les capacités impressionnantes d'Aikido permettent aux entreprises de répondre aux exigences de gestion des vulnérabilités techniques pour la conformité SOC 2 et ISO 27001:2022. Ce faisant, vous établissez un environnement sécurisé qui protège vos données et votre infrastructure.

Avantages : l'intégration de l'aïkido et du drata accroît l'efficacité et permet de réaliser des économies

Aikido automatise le processus de suivi

Aikido est un pilote automatique qui transforme la gestion des vulnérabilités techniques - il surveille en permanence tout en fonctionnant de manière transparente en arrière-plan. Lorsqu'il détecte un problème important, vous recevez une notification.

Dites adieu aux faux positifs

Les plateformes de sécurité traditionnelles vous surchargent souvent avec toutes les vulnérabilités détectées. Si celles-ci sont envoyées à Drata, vous devez encore trier et éliminer les faux positifs. Cependant, la mission d'Aikido depuis le début a été d'éliminer ces faux positifs. Ainsi, le moteur de tri automatique avancé d'Aikido filtre efficacement le bruit et n'envoie que les vulnérabilités légitimes à Drata. Cela vous permet de vous concentrer sur les menaces réelles et de gagner un temps précieux.

Réduire les dépenses de sécurité

Le secteur de la sécurité souffre souvent de stratégies de tarification complexes et agressives, et les entreprises qui ont besoin de solutions de sécurité en pâtissent à leur tour. Certains systèmes facturent en fonction du nombre d'utilisateurs, ce qui peut compromettre la sécurité car les développeurs peuvent partager des comptes. De plus, cela peut vite s'avérer très coûteux pour les grandes équipes ! D'autres proposent une tarification basée sur la quantité de code, ce qui peut également s'avérer rapidement coûteux.

Aikido s'affranchit de ces normes en proposant un modèle de tarification clair et forfaitaire. A partir de 314$ par mois et par organisation, la stratégie tarifaire d'Aikido vous permet d'économiser environ 50% par rapport aux solutions existantes.

Aikido + Drata = grande victoire

Regardons la réalité en face : pour mettre en œuvre la norme SOC 2 ou ISO 27001:2022, vous devrez faire plus qu'une simple gestion technique des vulnérabilités. Nous aimerions que ce soit aussi simple, mais ce n'est pas le cas ! Vous aurez besoin d'une solution logicielle globale de mise en conformité de la sécurité. Une plateforme telle que Drata automatise les processus de conformité complexes et fastidieux afin de s'assurer que vous êtes prêt pour un audit.

Mais avec Aikido qui s'occupe de votre gestion des vulnérabilités et qui fournit des preuves à Drata grâce à notre intégration, vous gagnez du temps ! Cela rend tous les aspects de la gestion des vulnérabilités techniques aussi faciles que possible.

Qu'attendez-vous ? Essayez Aikido gratuitement aujourd'hui (l'inscription prend 30 secondes) et accélérez votre mise en conformité.

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 :

1. Avec Docker, vous pouvez créer un nouveau conteneur vide nommé devenv-01 comme suit : docker run --name devenv-01 -it ubuntu:24.04 sh
2. Avec Daytonaqui est livré avec de nombreuses "piles incluses" pour les flux de travail de développement : daytona créer --code
3. Ou avec Distrobox, qui 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 ?

Le 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 CloudSploit, vous 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, depuis votre cadre d'interface utilisateur jusqu'aux bibliothèques d'aide que vous utilisez dans une seule LOC, comme un validateur d'adresses électroniques. L'ACL 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 SBOM à 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 ?

Un 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 d'autres choses encore. Une fois qu'ils sont transférés dans un dépôt public, vous devrez passer par un processus pénible pour les supprimer de votre historique Git - mieux vaut les détecter tôt et prendre des mesures avant de les livrer.

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 behavior scans uncommitted changes to prevent you from making mistakes in the first place.

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 open-source de détection de secrets ont des années d'existence depuis le dernier commit, 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 GitHub secret scanning partner program, qui identifie lorsque vos utilisateurs livrent accidentellement vos formats de jetons secrets à 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 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 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 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 vous lancer dans l'aventure.

#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 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à, 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

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 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 éliminent une grande partie de la complexité, mais chaque fois que vous construisez une image de conteneur, elle peut hériter des vulnérabilités de son image de base ou des dépendances du paquet. 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, gère 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 open-source 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 OSS changent de licence plus fréquemment que vous ne le pensez, ce qui vous oblige à payer pour une version 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é avec 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'une fonction d'analyse des licences qui vous présente des résultats d'opinion sur le risque associé aux projets de votre arbre de dépendances 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 dans les paquets de dépendances par les attaquants. La récente 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 Phylumvous 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. 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 :

1. 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.
   
2. Exécuter chaque analyseur pour chaque dépôt et chaque branche. Même si vous avez un seul repo et deux branches-principal et dev -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.
   
3. 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.
   
4. 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.json est un excellent outil autonome, ou vous pouvez essayer git diff --no-index file1.json file2.json pour les fichiers qui n'ont pas été déposés dans votre dépôt Git.
   
5. 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.
   
6. 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.
   
7. 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.
   
8. 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 ?
   
9. 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 incroyables - 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 remédiation aux vulnérabilités, il doit y avoir une autre façon de faire. 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'un autre moyen, qui remplace tout le fardeau de la construction de cette boîte à outils open-source par une plateforme qui est déjà construite sur les mêmes projets, envisagez 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.

Peut-être envisagez-vous la certification AICPA SOC 2 ? Aikido a récemment fait l'objet d'un audit pour vérifier que notre système et la conception de nos contrôles de sécurité répondent aux exigences SOC 2 de l'AICPA. Parce que nous avons beaucoup appris sur les normes SOC 2 au cours de notre audit, nous avons voulu partager quelques idées qui pourraient être utiles à quelqu'un qui entame le même processus.

Lisez nos meilleurs conseils pour la mise en conformité avec la norme ISO 27001:2022.

Type 1 vs. type 2

La première chose à comprendre est qu'il existe deux types de certification SOC 2: SOC 2 Type 1 et SOC Type 2. Si vous commencez seulement à penser à la certification SOC, le type 1 peut être une bonne première étape. Elle est plus rapide à obtenir et les exigences ne sont pas aussi élevées. Le rapport de type 1 est également moins coûteux que le rapport de type 2.

La différence réside dans le fait qu'il ne couvre pas la surveillance sur une période prolongée. Vos mesures de cybersécurité ne sont vérifiées qu'à un moment précis lors d'un audit SOC 2 de type 1. En revanche, le processus de certification SOC de type 2 teste vos contrôles de sécurité sur une période donnée. En effet, l'audit de type 1 teste la conception de vos contrôles de sécurité, tandis que l'audit de type 2 teste également leur efficacité opérationnelle.

Note : Vous pouvez également vous renseigner sur le rapport ISAE3402 de type I. Il s'agit de l'alternative européenne. Il s'agit de l'alternative européenne, mais dans la pratique, la plupart des entreprises ne s'en préoccupent pas. Optez donc pour le rapport SOC 2, à moins que vous ne sachiez déjà que vous avez besoin du rapport européen.

Critères des services fiduciaires SOC 2

Un auditeur SOC utilisera généralement cinq critères de services fiduciaires pour évaluer la conformité des entreprises au SOC 2 :

• Sécurité: protéger les données et les systèmes contre les accès non autorisés.
• Disponibilité: s'assurer que les données des clients sont accessibles en cas de besoin.
• Confidentialité: veiller à ce que les informations confidentielles soient suffisamment protégées.
• Vie privée: protéger les informations personnelles.
• Intégrité du traitement: garantir que les systèmes traitent les données de manière précise et fiable.

Toutes les entreprises n'ont pas besoin d'inclure les cinq critères. Une partie de la préparation de votre audit SOC 2 consiste à déterminer les critères que vos clients exigeront.

Il existe également d'autres critères spécifiques à chaque secteur d'activité. Par exemple, un fournisseur de services en nuage aura des exigences plus strictes en matière de cryptage des données de ses clients, tandis que les prestataires de soins de santé devront protéger les informations relatives à la santé.

Nos 5 meilleurs conseils pour la certification SOC 2

1. On ne peut pas vraiment devenir "conforme" à la norme SOC 2

Contrairement à la norme ISO 27001, il n'est pas possible d'atteindre le niveau de conformité SOC 2. Il s'agit d'un rapport qu'un client potentiel peut demander afin d'évaluer le niveau de sécurité de l'entreprise. Le client doit décider lui-même si l'entreprise est suffisamment sûre pour faire des affaires avec lui.

Vous obtiendrez un rapport SOC 2 démontrant la conformité aux critères spécifiés, mais cela ne signifie pas que vous passez de la non-conformité à la conformité. Cela n'enlève rien à sa valeur pour vos partenaires commerciaux. Ils savent ce dont ils ont besoin et exigeront souvent un rapport d'audit SOC 2.

Par exemple, SOC 2 n'exige pas nécessairement la réalisation d'un pentest, mais celui-ci est fortement recommandé pour ISO 27001. Vanta, l'une des principales plateformes de contrôle de conformité SOC 2, recommande de considérer SOC 2 comme une barre à franchir pour être considéré comme ayant atteint les normes de sécurité essentielles. Mais vous pourriez faire un effort supplémentaire une fois que vous aurez franchi cette barre, et vos clients apprécieront probablement cette assurance supplémentaire.

En ce sens, votre rapport de conformité SOC 2 signifie que vous avez convaincu l'auditeur que votre entreprise répond aux critères des services fiduciaires SOC 2.

2. Le type 2 est basé sur une période d'observation de la conformité

Les rapports SOC 2 de type 2 vérifient votre posture de sécurité sur une période d'observation appelée fenêtre d'audit. Vous pouvez choisir une fenêtre allant de trois mois à une année complète. Ce rapport est beaucoup plus approfondi que le rapport SOC 2 de type 1, ce qui signifie que les parties prenantes et les clients potentiels sont davantage rassurés quant aux systèmes de sécurité et à la sécurité des données.

Vous devrez consulter votre auditeur pour choisir la fenêtre d'audit. Elle peut dépendre de facteurs tels que les exigences réglementaires, les attentes des clients ou le caractère récent de vos cadres et contrôles de sécurité.

3. SOC 2 vs. ISO 27001 : si vos clients potentiels se trouvent aux États-Unis, SOC 2 est fait pour vous !

Les entreprises américaines demandent généralement plus souvent des rapports SOC 2, tandis que les entreprises européennes ont tendance à s'appuyer davantage sur la norme ISO 27001. Cela s'explique par le fait que SOC 2 est une norme américaine. Si vous le pouvez, obtenez les deux. C'est ce que nous avons fait, puisque nous sommes également devenus conformes à la norme ISO 27001 en 2023. Si vous ne pouvez pas faire les deux, choisissez en fonction de l'endroit où se trouvent vos clients ou prospects.

Si vos clients se trouvent aux États-Unis, il y a de fortes chances qu'ils recherchent votre rapport SOC 2.

4. Nous vous recommandons de travailler avec un auditeur aux États-Unis.

Si vous êtes basé en Europe, il existe de nombreux auditeurs SOC. Ils sont probablement très bons, mais si vous voulez qu'une entreprise américaine se fie à votre rapport, il est judicieux de faire appel à un auditeur SOC 2 tiers aux États-Unis.

5. Utiliser un système sécurisé pour permettre aux clients de demander votre rapport SOC 2

Vous devez faire en sorte que les clients puissent facilement demander votre rapport SOC 2, mais ne le faites pas trop facilement. Les pirates informatiques pourraient l'utiliser pour identifier les points faibles de votre sécurité.

N'utilisez pas le courrier électronique et utilisez un outil qui permet de suivre ce qu'il advient du rapport une fois qu'il a été téléchargé. Vous devez savoir qui le demande, savoir quand il a été demandé et même envisager un filigrane ou une protection par mot de passe. La meilleure approche consiste à utiliser un accord de confidentialité.

L'aïkido et la conformité permanente à la norme SOC 2

Maintenant que nous avons terminé notre propre parcours SOC 2, Aikido Security remplit tous les critères des services de confiance SOC 2. Nous avons également établi des partenariats avec des plateformes de contrôle de conformité (telles que Vanta, Drata, Secureframe et Thoropass) afin de synchroniser régulièrement les données sur les contrôles de sécurité actuels et de s'assurer qu'Aikido et ses clients maintiennent une position de sécurité solide.

Demandez notre rapport SOC 2 Type 2

Vous pouvez demander le certificat SOC 2 Type 2 d'Aikido sur notre centre de confiance.

Si vous envisagez de vous faire certifier SOC 2 et que vous avez encore des questions, contactez-moi sur LinkedIn et je me ferai un plaisir de discuter du processus avec vous de manière plus détaillée.

Vous savez que votre dernière application web est intrinsèquement vulnérable à toutes sortes d'attaques. Vous savez également que la sécurité des applications ne sera jamais parfaite, mais vous pouvez faire en sorte qu'elle soit meilleure demain qu'elle ne l'était hier.

Le problème est que, que vous utilisiez des outils de sécurité de niveau entreprise (c'est-à-dire coûteux et complexes) ou que vous ayez rassemblé une poignée de projets open-source dans un pipeline CI/CD ou des crochets de commit Git et que vous espériez le meilleur, votre boîte à outils ne peut pas vous aider à voir :

• Comment votre application peut être vulnérable en raison de pratiques de programmation moins qu'idéales, de dépendances non sécurisées, etc.
• Où les vulnérabilités se cachent très probablement, jusqu'à des LOC uniques ou des entrées dans votre système de gestion de la sécurité. package.json fichier.
• Pourquoi vous devez corriger certaines vulnérabilités immédiatement et pourquoi d'autres sont moins prioritaires.

Aikido existe pour rendre la sécurité des applications pertinente et efficace pour les développeurs qui ont besoin d'appliquer les bons correctifs de sécurité rapidement et de retourner à la livraison du code. Tout comme nous le faisons dans notre plateforme de sécurité centrée sur le développeur, nous allons réduire le bruit autour des vulnérabilités courantes et nous concentrer sur trois détails essentiels :

• Le TL;DR, qui vous en apprendra juste assez pour avoir peur... et les bons mots-clés pour poursuivre votre recherche d'éducation.
• Une réponse concise à la question "Est-ce que cela me concerne ?" avec un oui ou un non clair (✅ ou 🙅) et une brève explication.
• Des conseils rapides en réponse à la question "Comment puis-je résoudre ce problème ?" qui n'impliquent pas d'outils coûteux ou de refontes onéreuses.

#1 : Injection SQL && Injection NoSQL

TL;DR : Cette vulnérabilité classique est rendue possible par une entrée utilisateur non nettoyée et non validée, ce qui permet aux attaquants d'exécuter des requêtes directement dans votre base de données. À partir de là, ils peuvent extraire des données, modifier des enregistrements ou les supprimer à volonté, ce qui annule complètement toutes les autres mesures de sécurité que vous avez mises en place pour votre application.

Cela me concerne-t-il ?

• ✅ si votre application interagit à tout moment avec une base de données SQL ou NoSQL. Les attaques par injection existent depuis des décennies, et les attaques automatisées commenceront immédiatement à sonder vos points de terminaison avec des exploits courants.
• 🙅 si vous n'avez pas de contenu dynamique basé sur des enregistrements de base de données. Cela peut être dû au fait que vous êtes entièrement côté client, que vous utilisez un générateur de site statique (SSG) ou que vous effectuez un rendu côté serveur avec une base de données mais que vous n'acceptez jamais d'entrées de la part des utilisateurs.

Comment y remédier ? Avant toute chose, il convient d'assainir et de valider toutes les données saisies par l'utilisateur afin d'éliminer les caractères ou les chaînes de caractères indésirables. Utilisez des bibliothèques et des frameworks open-source qui permettent des requêtes paramétrées, et ne concaténé jamais l'entrée utilisateur dans une requête de base de données. Si vous utilisez Node.js, pensez à notre moteur de sécurité open-source Runtime, qui vous protège de manière autonome contre les attaques par injection SQL/NoSQL et bien plus encore.

#2 : Les scripts intersites (XSS)

TL;DR : XSS est une autre attaque par injection qui permet à un attaquant d'envoyer un script malveillant à une autre personne, ce qui peut permettre de recueillir ses informations d'authentification ou des données confidentielles.

Cela me concerne-t-il ?

• ✅ si votre application accepte les données de l'utilisateur et les restitue ailleurs sous forme de contenu dynamique.
• 🙅 si vous n'acceptez aucune entrée de la part de l'utilisateur.

Comment le réparer ? Comme pour les attaques par injection SQL/NoSQL, vous devez valider les données saisies par l'utilisateur lorsque vous les incluez dans la chaîne de caractères href des balises d'ancrage pour s'assurer que le protocole n'est pas utilisé. javascript. Soyez prudent lorsque vous utilisez des méthodes JavaScript telles que innerHTML ou de React dangereusementSetInnerHTMLqui peut exécuter arbitrairement n'importe quel code intégré dans la chaîne pendant la sortie. Quelle que soit votre approche, désinfectez la sortie HTML à l'aide d'outils de désinfection open-source tels que DOMPurify pour n'envoyer à vos utilisateurs que du HTML propre et non exécutable.

#3 : Falsification de requête côté serveur (SSRF)

TL;DR : Les attaques SSRF se produisent lorsqu'un acteur malveillant abuse de votre application pour interagir avec son réseau sous-jacent, l'exploitant comme un proxy pour accéder à des services potentiellement plus vulnérables ou plus lucratifs.

Cela me concerne-t-il ?

• si votre application s'interface avec un autre service ou API qui effectue une opération spécifique avec les données de l'utilisateur, même si vous avez utilisé des listes d'autorisations pour restreindre le trafic entre des points d'extrémité connus et fiables.
• 🙅 si vous êtes vraiment statique.

Comment y remédier ? Bien qu'une expression rationnelle pour valider les adresses IP ou les noms d'hôtes soit un bon début, elle est généralement sujette à des contournements tels que l'encodage octal. Deux solutions plus fiables sont d'utiliser une liste d'autorisation et l'analyseur d'URL natif de votre plateforme pour restreindre l'entrée aux seuls hôtes sûrs et connus, et de désactiver les redirections dans les requêtes de récupération. En fonction de votre plateforme, vous pouvez également vous appuyer sur des projets open-source, comme ssrf-req-filter pour Node.js, pour refuser correctement les requêtes adressées à des hôtes internes.

#4 : Traversée de chemin

TL;DR : Cette faille de sécurité permet aux attaquants d'accéder aux fichiers et aux répertoires de votre serveur web en référençant les fichiers à l'aide de la fonction ../ ou même des chemins d'accès absolus. En utilisant des tactiques sournoises comme le double encodage, les attaquants peuvent utiliser des hiérarchies de dossiers et de fichiers spécifiques au cadre ou des noms de fichiers communs pour trouver des informations précieuses.

Cela me concerne-t-il ?

• ✅. Votre application fonctionne sur un serveur web et inclut des références au système de fichiers - il n'est pas possible de contourner ce problème.

Comment y remédier ? La première étape consiste à supprimer du répertoire racine de votre serveur web tous les fichiers sensibles, comme ceux qui contiennent des variables d'environnement ou des secrets, et à mettre en place une procédure visant à prévenir d'autres dérapages.

de ne jamais stocker de fichiers sensibles, tels que ceux contenant des variables d'environnement ou des secrets, dans le répertoire racine de votre serveur web. De même, ne stockez pas ces fichiers dans un dossier destiné à être accessible au public, comme le dossier /statique et /public dossiers d'un Projet Next.js. Enfin, les bandes ../ les séparateurs de chemin et leurs variantes codées à partir des données de l'utilisateur.

Runtime fonctionne également très bien pour la traversée des chemins... c'est tout dire.

#5 : Injection d'entité eXterne XML (XXE)

TL;DR : Les attaques XXE exploitent une faiblesse des analyseurs XML qui permet à des entités externes, référencées par une définition de type de document (DTD), d'être récupérées et traitées sans validation ni assainissement. Le type et la gravité de l'attaque sont limités principalement par les compétences de l'attaquant et par les autorisations et la sécurité du système d'exploitation de votre fournisseur d'infrastructure.

Cela me concerne-t-il ?

• ✅ si vous analysez XML pour quelque raison que ce soit, y compris les flux d'authentification unique utilisant SAML.
• 🙅 si vous n'avez pas à gérer le XML dans votre application !

Comment résoudre ce problème ? Désactivez la résolution des DTD externes dans votre analyseur XML. Vous ne pouvez probablement pas refuser complètement les DTD, car il est normal que certaines charges utiles XML en contiennent, mais ne laissez pas votre analyseur XML faire quoi que ce soit avec elles.

#6 : Désérialisation

TL;DR : Les attaquants peuvent envoyer des données malveillantes par le biais d'une fonction de désérialisation intégrée à votre application (comme unserialize() de node-serialize) pour exécuter du code à distance, lancer un déni de service ou même créer un reverse shell.

Cela me concerne-t-il ?

• ✅ si votre application désérialise des données directement à partir de l'interaction avec l'utilisateur ou par le biais de fonctions/services d'arrière-plan comme les cookies, les formulaires HTML, les API tierces, la mise en cache, et plus encore.
• 🙅 si vous utilisez une application entièrement statique sans aucun des éléments ci-dessus.

Comment y remédier ? En général, évitez de désérialiser les données d'entrée de l'utilisateur (c'est-à-dire les données non fiables). Si vous devez le faire, n'acceptez que les données provenant d'utilisateurs authentifiés et autorisés sur la base de signatures, de certificats et de fournisseurs d'identité de confiance.

#7 : Injection de Shell/injection de commande

TL;DR : Votre application transmet les données de l'utilisateur directement au shell sous-jacent du système d'exploitation sur lequel votre serveur web et votre application s'exécutent, ce qui permet aux attaquants d'exécuter des commandes arbitraires ou de parcourir le système de fichiers, souvent avec des privilèges suffisants pour extraire des données ou basculer vers un autre système.

Cela me concerne-t-il ?

• ✅ si votre application interagit directement avec le système de fichiers ou l'interpréteur de commandes, comme une commande UNIX telle que chat.
• 🙅 si vous utilisez déjà une API ou une méthode du framework pour passer en toute sécurité des arguments à la commande que vous devez exécuter, ou si vous n'avez pas besoin d'interagir avec le système de fichiers/le shell, comme dans un SSG.

Comment le réparer ? Évitez d'accepter les données de l'utilisateur directement dans les commandes ou de les appeler directement. Utilisez plutôt l'API/méthode de votre framework, comme child_process.execFile() dans Node.js, qui vous permet de passer des arguments dans une liste de chaînes. Même avec cette protection, exécutez toujours vos applications avec le minimum de privilèges nécessaires pour la logique métier requise, afin d'empêcher un attaquant de "s'échapper" du serveur web et d'accéder aux éléments suivants racine-uniquement des dossiers et des fichiers.

Et oui, nous sommes de retour pour un dernier rappel amical à ajouter Temps d'exécution à n'importe quel projet Node.js en une seule commande (npm add @aikidosec/runtime || yarn install @aikidosec/runtime) pour protéger instantanément votre application contre les attaques courantes par injection de commandes ou de shell.

#8 : Inclusion de fichiers locaux (LFI)

TL;DR : Les attaques LFI consistent à tromper votre application en exposant ou en exécutant des fichiers sur le système qui exécute votre serveur web, ce qui permet aux attaquants d'extraire des informations ou d'exécuter du code à distance. Alors que la traversée de chemin ne permet aux attaquants que de lire des fichiers, les attaques LFI exécutent ces fichiers à l'intérieur de votre application, ce qui vous expose à une liste de vulnérabilités de sécurité telles que l'exécution de code à distance (RCE).

Cela me concerne-t-il ?

• ✅ si votre application utilise le chemin d'un fichier comme entrée utilisateur.
• 🙅 si votre application ne demande pas aux utilisateurs de fournir des chemins d'accès pour effectuer une action.

Comment le réparer ? Vérifiez toujours les entrées de l'utilisateur afin d'éviter les méthodes de traversée de chemin évoquées ci-dessus. Si vous devez inclure des fichiers sur le système de fichiers local au-delà de ceux que l'on trouve généralement dans les fichiers "sûrs" de type /public ou /statique utilisez une liste de noms de fichiers et d'emplacements que votre application est autorisée à lire et à exécuter.

#9 : Prototype de pollution

TL;DR : Le présent Vulnérabilité spécifique à JavaScript permet à un attaquant de manipuler les objets globaux de votre application à l'aide de la fonction __proto__. Le nouvel objet est ensuite hérité dans l'ensemble de votre application, ce qui peut leur donner accès à des données confidentielles ou accroître leurs privilèges.

Cela me concerne-t-il ?

• ✅ si vous utilisez JavaScript.
• 🙅 si vous utilisez autre chose que JavaScript !

Comment le réparer ? Commencez par assainir les clés à partir des entrées utilisateur à l'aide de listes d'autorisations ou d'une bibliothèque d'aide open-source. Vous pouvez étendre votre protection en utilisant Object.freeze() pour empêcher les modifications d'un prototype, ou même en utilisant la fonction --disable-proto=delete offert avec Node.js.

#10 : Redirections ouvertes

TL;DR : Dans ce vecteur courant d'hameçonnage, les attaquants créent une URL personnalisée telle que https://www.example.com/abc/def?&success=true&redirectURL=https://example.phishing.com pour tromper votre application et rediriger les utilisateurs peu méfiants vers un site web malveillant. En outre, les attaquants peuvent enchaîner les redirections avec d'autres vulnérabilités pour obtenir un impact encore plus important, conduisant à des prises de contrôle de comptes et bien plus encore.

Cela me concerne-t-il ?

• ✅ si votre application redirige les utilisateurs vers une autre page/vue après avoir effectué une action, par exemple en les envoyant à exemple.app/dashboard après une authentification réussie.
• 🙅 si vous vivez encore cette vie statique.

Comment y remédier ? Tout d'abord, supprimez les redirections basées sur des paramètres de votre application et remplacez-les par des redirections fixes basées sur une liste de domaines et de chemins de confiance vers lesquels vous pouvez rediriger les utilisateurs après qu'ils aient effectué des actions spécifiques. Cela risque de dégrader légèrement l'expérience de l'utilisateur, mais il s'agit d'un compromis valable pour améliorer la sécurité de l'application, et non pas d'un compromis qui laisse les utilisateurs vous blâmer pour les dépenses étranges figurant sur leur relevé de carte de crédit.

Quelle est la prochaine étape pour la sécurité de votre application ?

Si vous vous sentez dépassé par l'ampleur des attaques et par tout le travail nécessaire pour vous en protéger, sachez que vous n'êtes pas seul.

Personne ne s'attend à ce que vous résolviez vous-même tous ces problèmes de sécurité et toutes ces vulnérabilités possibles. Les attaques par injection SQL existent à elles seules depuis des décennies, et les gens continuent de trouver des CVE dans des applications, des frameworks et des bibliothèques sophistiqués. Cela ne veut pas dire que vous devez prendre ces problèmes de sécurité avec un grain de sel - si votre projet répond aux ✅ de l'un de ces 10 principaux problèmes de sécurité des applications, vous devez commencer à prendre des mesures.

Tout d'abord, inscrivez-vous à Aikido pour commencer à vous concentrer sur les véritables menaces qui pèsent sur la sécurité de votre application. En deux minutes, et gratuitement, vous pouvez analyser les référentiels et obtenir des détails pertinents ainsi que des remèdes guidés pour les vulnérabilités les plus critiques en fonction de l'architecture spécifique de votre application et des fonctionnalités, fonctions et bibliothèques d'aide que vous avez mises en œuvre. Avec Aikido, vous réduirez le champ d'application à ce qui est important et mettrez en œuvre des correctifs intelligents plus rapidement, tout en étant informé instantanément des nouveaux problèmes de sécurité introduits dans vos derniers commits.

Ensuite, ajoutez Runtime, notre moteur de sécurité intégré open-source, à vos applications Node.js. Runtime protège instantanément et de manière autonome vos applications contre diverses attaques par injection, pollution de prototype et traversée de chemin en les bloquant au niveau du serveur, mais sans le coût et la complexité des pare-feu d'application web ou des plateformes de gestion de la sécurité des applications basées sur des agents. Runtime vous donne l'assurance que votre application et vos utilisateurs sont à l'abri de ces problèmes de sécurité courants, mais il peut également transmettre des données en temps réel à Aikido pour vous donner une visibilité sur les vecteurs d'attaque actuels afin de vous aider à prioriser les correctifs.

Vous partez maintenant du bon pied, avec une vision plus claire de la situation :

• Les vulnérabilités de votre application sont plus nombreuses que vous ne le pensiez.
• Où vous devez concentrer votre temps et votre attention pour résoudre d'abord les problèmes les plus critiques.
• Pourquoi la sécurité des applications et l'analyse des vulnérabilités ne sont pas un effort ponctuel, mais un processus continu, rendu beaucoup plus facile grâce à l'Aïkido.
  

TL;DR nous avons levé beaucoup d'argent et nous sommes prêts à nous lancer dans l'aventure.

Nous avons levé 17 millions de dollars pour apporter une sécurité "no BS" aux développeurs. Nous sommes heureux d'accueillir Henri Tilloy de Singular.vc à bord, qui est à nouveau rejoint par Notion Capital et Connect Ventures. Ce tour de table intervient seulement 6 mois après que nous ayons levé 5,3 millions de dollars de fonds d'amorçage. C'est rapide.

Nous avons fondé Aikido parce que les développeurs ont un problème. Les exigences en matière de sécurité et de conformité ne sont plus réservées aux grandes entreprises - elles sont désormais une nécessité croissante pour les entreprises de toutes tailles, en particulier les PME qui cherchent à gagner des clients et à se développer. Les normes de conformité telles que SOC2, ISO 27001, CIS, HIPAA et la future directive européenne NIS 2 deviennent des exigences de base pour les sociétés de logiciels, en particulier celles qui vendent aux entreprises ou qui traitent des données sensibles, comme dans les domaines de la santé ou de la finance.

Mais ce fardeau de conformité croissant retombe souvent sur les épaules des développeurs, dont on attend désormais qu'ils jouent le rôle d'experts en sécurité. C'est pourquoi nous avons créé Aikido, la plateforme tout-en-un qui rassemble tous les scanners de sécurité du code et du cloud nécessaires dans une interface simple et conviviale, en s'appuyant sur ce que l'open source a de mieux à offrir. Nous sommes freemium, en libre-service et ouverts sur ce qui se trouve sous le capot et combien cela vous coûtera.

Nous sommes un challenger outsider dans l'industrie de la sécurité établie et très soudée, qui a longtemps été dominée par des entreprises américaines et israéliennes dirigées par des vétérans de l'industrie. Certes, il existe des outils de sécurité depuis trente ans, mais nous partons d'une position très différente. Nous construisons une plateforme de sécurité où l'acheteur est l'utilisateur. Comme c'est souvent le cas, le RSSI est l'acheteur, mais c'est un pauvre développeur qui est l'utilisateur.

Nous avons déjà été ce pauvre développeur. Nous avons ressenti la frustration de travailler avec des outils de sécurité anciens et encombrants qui nous font perdre du temps et de l'argent. En tant que directeurs techniques, nous avons nous-mêmes perdu des centaines d'heures sur des alertes de sécurité non pertinentes. Nous savons que ces outils ressemblent à l'intérieur du cockpit d'un F-16. Nous savons qu'ils vous donnent l'impression d'être stupide, que vous êtes tellement submergé par la complexité et les fausses alertes que les gens arrêtent de les vérifier. Nous comprenons qu'un développeur veuille simplement résoudre les problèmes et passer à la construction de fonctionnalités amusantes.

Nous sommes ravis de travailler avec Henri et Singular. C'est l'un des premiers investisseurs qui nous a semblé comprendre le produit et ne pas nous considérer uniquement comme une feuille de calcul. Il pense que nous avons "une approche incroyablement unique de la sécurité" car nous sommes "simples, open-source, et faciles à mettre en place et à utiliser, et pourtant Aikido coche les cases des exigences de conformité et de sécurité de l'entreprise en une seule fois". (Nous l'aimons aussi pour ses belles citations et ses compliments).

Moins d'un an après notre lancement, nous sommes déjà utilisés par plus de 3 000 organisations et 6 000 développeurs individuels. Le fait que Visma nous ait choisis pour sécuriser l'ensemble de son portefeuille de plus de 175 entreprises a été un événement majeur et a confirmé que nous étions sur la bonne voie (même si nous n'en doutions pas ;)). Nous avons 30 % de nos clients aux États-Unis et nous visons maintenant une plus grande expansion internationale pour aider les développeurs et les PME à faire de la sécurité une réalité.

Ce nouveau financement de 17 millions de dollars de la série A nous permettra d'approfondir notre plateforme et de propulser Aikido sur la scène mondiale, en rendant la sécurité simple pour les PME et réalisable pour les développeurs sans le jargon de l'industrie, la paperasserie et, franchement, la BS.

Vous voulez nous rejoindre?