Je suis sûr que vous conviendrez que, dans le monde numérique d’aujourd’hui, la majorité des applications sur lesquelles nous travaillons nécessitent un certain type d’informations d’identification – pour se connecter à une base de données avec un nom d’utilisateur/mot de passe, pour accéder à des programmes informatiques via des jetons autorisés ou des clés API pour invoquer des services pour l’authentification.

Les informations d’identification, ou parfois simplement appelées « secrets », sont des informations confidentielles au niveau de l’utilisateur ou du système qui doivent être soigneusement protégées et accessibles uniquement aux utilisateurs légitimes. Nous savons tous à quel point il est important de protéger ces actifs pour éviter les abus et les violations de compte.

Une confrontation avec la réalité : à quelle fréquence faites-vous des efforts proactifs pour protéger ces actifs ? Rarement, je dirais.

L’une des pires erreurs qu’un développeur puisse commettre en matière de sécurité des applications est de publier accidentellement des informations confidentielles sur Internet. Étonnamment, les secrets et les informations d’identification sont accidentellement divulgués plus souvent que vous ne le pensez, et il existe des outils intelligents qui analysent les référentiels publics à la recherche de secrets commis.

Avec pour mission de permettre aux développeurs de prendre le contrôle de leur propre intégrité de code, SonarLint, une extension IDE gratuite et open source de SonarSource, a récemment annoncé une nouvelle fonctionnalité pour son logiciel qui vise à aider les développeurs à identifier et à prévenir les fuites d’informations d’authentification au niveau de l’utilisateur ou du système AWS avant qu’elles ne soient engagées dans un référentiel et divulguées à partir de la source locale de l’utilisateur. code ou fichiers.

Cela vous semble-t-il intéressant ? Continuez à lire pour en savoir plus.

Premièrement – pourquoi vous devriez vous en soucier

Prenons un moment pour regarder un peu en arrière et voir pourquoi cette nouvelle fonctionnalité SonarLint serait si importante et utile pour tout développeur.

Quelque part dans votre vie, vous avez peut-être utilisé une carte de crédit pour acheter en ligne et avez immédiatement reçu un appel de la société émettrice de la carte de crédit vous demandant si vous aviez l’intention de procéder à l’achat. Si vous l’avez fait, pas de problème, tout va bien. Sinon, une activité frauduleuse a été détectée juste avant la fin de la transaction, ce qui vous évite, à vous et à votre société émettrice de carte de crédit, la complexité d’un compte compromis après coup.

Il en va de même pour le développement de code.

Il peut y avoir une connexion récurrente à une base de données basée sur le cloud dans le cadre du processus de développement et de livraison du code, ou vous pouvez avoir besoin d’informations d’identification pour accéder à une API d’une société tierce.

Dans ce processus, il est possible que vous ayez temporairement codé en dur les informations d’identification pour en faciliter l’utilisation, ou qu’un collègue ait ajouté des informations confidentielles pour un test local rapide, puis ait accidentellement enregistré ces fichiers dans un référentiel public. Et… ces changements temporaires sont désormais permanents… Aïe ! Même avec la suppression après coup du code, il est toujours possible que quelqu’un ait fait une copie de votre secret avant le nettoyage.

La prochaine chose que vous savez, quelqu’un a compromis le compte, ou pire encore, cette petite faille de sécurité a fourni à quelqu’un un petit point de départ pour une violation d’infrastructure plus importante.

Les violations de ce type sont plus courantes et potentiellement catastrophiques que vous ne le pensez. Il y a eu un certain nombre d’articles de presse au cours de la dernière année mettant en évidence des incidents où des utilisateurs malveillants ont volé des clés d’API intégrées dans des référentiels de code source publics tels que GitHub et BitBucket. Débordement de pile, Uber et plus récemment Shopify sont des exemples d’incidents de sécurité très médiatisés où des secrets éparpillés dans des fichiers publiquement visibles ont fait des ravages. Imaginez les dommages que cela aurait pu faire à la réputation de la marque.

L’erreur humaine continuera de se produire, mais en effectuant les bonnes vérifications au bon moment, l’erreur peut être évitée en premier lieu. Le cas précédent illustre comment l’exposition de « secrets » détectés au point d’introduction pertinent, par exemple pendant la programmation ou juste avant de valider votre code, aurait pu éviter beaucoup de problèmes.

Le meilleur endroit pour détecter et résoudre ces problèmes dans votre workflow de développement est au tout début de celui-ci, c’est-à-dire dans votre environnement de développement intégré IDE. Il y a beaucoup de grandes entreprises qui ont appris cette leçon à la dure.

Règles avancées qui détectent les secrets AWS dans l’IDE

Avec l’ajout récent de nouvelles règles de détection des secrets du cloud, SonarLint protège les informations d’authentification AWS et les informations d’identification Amazon Marketplace Web Service (MWS) contre les fuites publiques. Consultez les règles qui protègent les jetons d’authentification MWS, la clé d’accès AWS, l’ID de clé et les jetons de session.

SonarLint protège vos informations d’identification contre les fuites publiques en agissant comme votre première ligne de défense. En signalant les problèmes au point d’introduction (c’est-à-dire en déplaçant la détection des problèmes plus à gauche), vous pouvez prendre des mesures immédiates et empêcher la fuite en premier lieu.

Ceci est important car les comptes compromis peuvent avoir non seulement des ramifications individuelles ou au niveau des ressources, telles que la possibilité de piratage de compte, mais également des conséquences négatives pour la confidentialité de vos clients. Par exemple, les jetons MWS compromis peuvent être utilisés pour obtenir un accès illicite à des bases de données contenant des informations sur les clients telles que les numéros de carte de crédit, les e-mails, les adresses de livraison et les enregistrements de vente des commerçants.

Avec SonarLint installé dans votre IDE, ces règles de détection « secrètes » vous permettront de détecter la présence de ces informations d’identification au premier point d’entrée, c’est-à-dire dans le code source ou dans des fichiers indépendants de la langue (par exemple, xml, yaml, json) avant de s’engager dans le repo.

En plus d’identifier de tels problèmes, SonarLint est également en mesure de fournir des conseils clairs sur la façon de les résoudre. Vous disposez alors d’une flexibilité totale pour prendre des mesures et traiter le code signalé ; vous rapprochant un peu plus de la livraison de code sécurisé.

Démarrer dans votre IDE

Cette fonctionnalité est actuellement prise en charge dans les IDE populaires tels que VS Code, IntelliJ IDEA, PyCharm, CLion, WebStorm, PHPStorm et Rider, avec Visual Studio, Eclipse, etc.

Pour commencer à sécuriser votre base de code, vous pouvez télécharger SonarLint pour VS Code ou SonarLint pour vos IDE JetBrains. Ou si vous utilisiez déjà SonarLint dans votre IDE, vous pouvez simplement mettre à jour le plug-in vers la version la plus récente pour activer cette fonctionnalité.

Dans une prochaine étape, la société prévoit également d’étendre la fonctionnalité de détection des « secrets » à d’autres fournisseurs de cloud public. À l’avenir, vous pouvez vous attendre à ce que SonarLint prenne en charge davantage de fournisseurs de cloud, de produits SaaS et de fournisseurs de bases de données.

Les développeurs qui utilisent d’autres solutions SonarSource – SonarQube ou SonarCloud pour fournir un code de qualité et sécurisé peuvent étendre leur expérience de sécurité du code à leur IDE. En installant SonarLint gratuitement, non seulement ils peuvent immédiatement bénéficier de fonctionnalités puissantes telles que la détection des secrets, mais également améliorer la qualité globale du code et la sécurité de leur base de code en partageant les règles et les paramètres d’analyse de SonarQube ou SonarCloud vers SonarLint pour fusionner toute l’équipe de développement sur une définition unique de la santé du code.