Aperçu du code sécurisé

Il y a une question que doit se poser tout développeur, qu'il soit diplômé ou vétéran. Et la réponse est importante. Elle est devenue encore plus importante dans un monde agile, car elle aura un impact direct sur votre réussite dans le domaine du génie logiciel et sur la valeur que vous apporterez à votre prochain employeur.

C'est la question à un million de dollars. En fait, c'est la question à plusieurs millions de dollars !

Vous engagez-vous à m'aider à coder en toute sécurité ?

Le coût moyen d'une violation de données s'élève aujourd'hui à 3,6 millions de dollars. La probabilité que votre entreprise soit victime d'une violation de données cette année est d'une sur quatre. Compte tenu de ces faits, je partage les frustrations de nombreuses personnes qui constatent que les développeurs ne sortent pas de l'université avec des compétences en matière de codage sécurisé et que la sécurité est inscrite dans leur ADN.  

Pourquoi ? Le génie logiciel est une profession encore relativement jeune. L'accent a été mis sur l'enseignement de la construction rapide de codes, de leur élégance et de leur fonctionnalité, mais l'attention portée à la sécurisation des codes a été très limitée. Le rythme d'évolution des méthodologies, des technologies, des langages et des opportunités ne fait qu'exacerber ces lacunes en matière de compétences.

Nous n'allons pas changer le système académique rapidement, donc les développeurs et les entreprises devraient s'attendre à ce que les développeurs aient besoin d'apprendre des compétences de codage sécurisées sur le terrain. Dans certaines professions, vous pouvez apprendre en faisant des erreurs, mais pour d'autres, ce n'est pas une option. Il en va de même pour la cybersécurité.

Les faits montrent que nous n'avons pas non plus été très performants en matière de formation à la sécurité des développeurs en cours d'emploi. La plupart des grandes failles de sécurité dans le monde sont dues à des erreurs de codage qui permettent aux pirates d'obtenir des privilèges sur les réseaux informatiques, ce qui leur permet d'accéder à des données précieuses et de les récolter. Le rapport Verizon Data Breach Investigation Report (DBIR) 2017 montre que 30 % de toutes les violations sont directement causées par des faiblesses dans la sécurité des applications web et cette conclusion est constante dans le rapport DBIR depuis 2013.

L'enquête mondiale 2017 sur les compétences DevSecOps, publiée en août 2017, a confirmé ce que nous savions déjà : si 65 % des professionnels DevOps estiment qu'il est très important d'avoir des connaissances en DevSecOps lorsqu'on entre dans l'informatique, 70 % d'entre eux pensent qu'ils ne reçoivent pas la formation nécessaire par le biais de l'enseignement formel pour réussir dans le monde DevSecOps d'aujourd'hui.

Près de 40 % des responsables du recrutement interrogés ont déclaré que les employés les plus difficiles à trouver sont les développeurs haut de gamme polyvalents ayant des connaissances suffisantes en matière de tests de sécurité. 70 % des personnes interrogées ont déclaré que la formation en matière de sécurité qu'elles avaient reçue n'était pas adaptée à leur poste actuel. En fait, moins de 4 % des personnes interrogées ont déclaré qu'elles avaient eu l'occasion de se former.

J'ai pu le constater de mes propres yeux lorsque j'ai travaillé pendant près de dix ans avec plusieurs équipes de pirates informatiques professionnels. Avec une régularité tragique, nous nous sommes introduits dans de grandes entreprises, des start-ups et des services gouvernementaux, en trouvant toujours les mêmes faiblesses.

C'est pourquoi les développeurs doivent s'exprimer lorsqu'ils sont embauchés. Si votre futur employeur ne prend pas au sérieux votre formation à la sécurité des développeurs, vous devriez réfléchir au type d'entreprise que vous envisagez de rejoindre.

La deuxième question que vous devez vous poser est de savoir comment ils prévoient de dispenser la formation. Sera-t-elle pratique et interactive ? Une formation à la sécurité des développeurs sur les vulnérabilités qui utilise des diapositives, des vidéos, des animations cliquables ou des discussions abstraites a peu de chances de vous aider directement dans votre codage. Ces formations vous permettront-elles de vous tenir continuellement au courant des dernières vulnérabilités ? Existe-t-il une guilde ou une communauté de sécurité auprès de laquelle vous pouvez apprendre ? Existe-t-il des experts en sécurité auxquels vous pouvez faire appel si vous avez besoin d'aide ?

Un engagement envers vos compétences en matière de codage sécurisé nécessite un apprentissage continu par le biais de défis pratiques dans des cadres de codage spécifiques et en vous confrontant à différentes vulnérabilités dans de multiples scénarios. Vous ne pouvez tout simplement pas apprendre les injections SQL à partir d'un seul exemple. Vous devez être exposé à de multiples exemples de différents types afin d'apprendre à reconnaître ces modèles de codage dangereux.

L'un de nos clients a demandé à ses développeurs de relever un seul défi (5 minutes) chaque jour pendant deux mois. Il a testé leurs compétences avant et après la période de formation et a observé une augmentation de 60 % des capacités de codage sécurisé sur un groupe de centaines de développeurs. Cela signifie que moins de ressources sont consacrées à la recherche et à la correction de bogues de sécurité à un stade ultérieur du cycle de vie et que d'importantes économies sont réalisées à long terme. Cela signifie que les pirates n'utiliseront pas votre code pour compromettre les données de votre entreprise.

Il y avait 11 millions de développeurs professionnels dans le monde en 2014, selon une étude d'IDC. En 2015, Burning Glass a constaté que pas moins de 7 millions d'emplois nécessitaient des compétences en codage et que les emplois dans le domaine de la programmation augmentaient en moyenne 12 % plus vite que le marché.

Il existe de nombreux emplois dans le domaine des logiciels. Prenez donc position et choisissez des employeurs qui s'engagent à prendre soin de leur sécurité, de votre sécurité et de celle de leurs clients. Par extension, choisissez des entreprises qui investissent en vous.

Il y a une question que doit se poser tout développeur, qu'il soit diplômé ou vétéran. Et la réponse est importante. Elle est devenue encore plus importante dans un monde agile, car elle aura un impact direct sur votre réussite dans le domaine du génie logiciel et sur la valeur que vous apporterez à votre prochain employeur.

C'est la question à un million de dollars. En fait, c'est la question à plusieurs millions de dollars !

Vous engagez-vous à m'aider à coder en toute sécurité ?

La semaine dernière, j'ai fait des recherches sur les vulnérabilités de Java Spring afin de mettre à jour nos lignes directrices en matière de codage sécurisé. J'ai passé en revue les défis existants sur notre plateforme et j'en ai remarqué quelques-uns concernant les XSS par l'affichage de paramètres d'url dans les pages JSP. L'exemple de code incorrect ressemblerait à ce qui suit :

   <input type="text" name="username" value="${param.username}">

La solution correcte consistait à supprimer complètement le paramètre URL et la description mentionne qu'il est également possible d'échapper le paramètre URL de la bonne manière.

Maintenant, mon travail consiste à formuler la ligne directrice sur le codage sécurisé d'une manière qui soit claire pour les développeurs et qui les restreigne le moins possible tout en continuant à écrire du code sécurisé. Dans ce cas, je préférerais laisser les développeurs conserver la fonctionnalité prévue et leur recommander de le faire de manière sécurisée en échappant le paramètre URL. De cette manière, le code ne contient plus de vulnérabilité XSS. L'exemple ci-dessus peut être sécurisé comme suit :

   <input type="text" name="username" value="${fn:escapeXml(param.username)}">

C'était notre ligne de conduite en matière de codage sécurisé pendant quelques jours, jusqu'à ce que je tombe sur une page de l'OWASP sur l'injection de langage d'expression. Cette page décrit comment le langage d'expression Spring (SpEL) peut être utilisé de manière abusive à des fins d'injection avec un impact sérieux, y compris l'exécution de code à distance. Il m'incombait de déterminer s'il pouvait y avoir des cas où un code adhérant à notre directive de codage sécurisé pouvait encore être affecté par cette vulnérabilité. J'ai donc écrit une application de test rapide pour évaluer les expressions SpEL, et j'ai testé les entrées avec et sans échappement Xml pour voir si je pouvais trouver des scénarios qui ne seraient pas pris en compte. Et c'est ce que j'ai fait, il y a des expressions malveillantes qui ne contiennent aucun caractère pris en compte par XmlEscape. J'ai publié la démo de travail sur notre github, que vous pouvez trouver ici.

Et bien sûr, j'ai mis à jour notre ligne directrice sur le codage sécurisé, qui se lit désormais comme suit : "N'affichez pas et n'évaluez pas les paramètres d'URL en utilisant le langage d'expression Spring (SpEL).

L'impact global de ce problème est élevé, pour les raisons suivantes : - Un attaquant pourrait modifier et invoquer des fonctionnalités sur le serveur d'application. - Accès non autorisé aux données et aux fonctionnalités, ainsi que détournement de compte et exécution de code à distance. - Problèmes de confidentialité et d'intégrité en cas d'attaque réussie.

https://www.owasp.org/index.php/Expression_Language_Injection

Les problèmes de sécurité identifiés en 2016 sur le site web d'Equifax n'ont toujours pas été résolus. Identifier le problème est une étape, mais le résoudre est un défi encore plus grand. Il faut du temps et des compétences pour retourner dans le code, comprendre le contexte et résoudre les problèmes.

Il est clair que les développeurs d'Equifax étaient très stressés et que de nombreuses vulnérabilités connues n'ont pas été corrigées. Malheureusement, ce manque d'action a eu la pire réponse possible.

La sécurité doit être intégrée dès le départ et les développeurs doivent disposer des compétences, de la formation et des outils in-IDE pour minimiser l'écriture des vulnérabilités connues. La résolution des problèmes identifiés nécessite des connaissances spécifiques en matière de langage et de framework. Le principe général de la correction d'un problème XSS reste le même, mais la mise en œuvre réelle dépend des cadres en place.

Si vous souhaitez suivre une formation interactive sur la manière de résoudre les problèmes XSS dans Struts, consultez le site : https://portal.securecodewarrior.com/#/simple-flow/web/xss/reflected/java/struts

En 2016, un chercheur en sécurité a découvert une vulnérabilité courante connue sous le nom de cross-site scripting (XSS) sur le site web principal d'Equifax, selon un tweet d'un chercheur répondant au nom de x0rz. Ces bogues XSS permettent aux attaquants d'envoyer des liens spécialement conçus aux clients d'Equifax et, si la cible clique dessus et se connecte au site, son nom d'utilisateur et son mot de passe peuvent être révélés au pirate.

https://www.forbes.com/sites/thomasbrewster/2017/09/08/equifax-data-breach-history/#552ab1c9677c

La semaine dernière, il a été rapporté que la violation des données d'Equifax pouvait être due à une vulnérabilité dans le plugin REST d'Apache Struts. L'ancienne version du plugin est vulnérable aux attaques par exécution de code à distance lorsqu'elle est utilisée avec le gestionnaire XStream pour traiter les charges utiles XML. La cause est la désérialisation de données non fiables, qui est un type de vulnérabilité bien connu. La vulnérabilité, officiellement reconnue comme CVE-2017-9805, a été corrigée par Apache le 5 septembre dans la version 2.5.13 de Struts. Elle a ensuite été annoncée et clairement documentée dans la documentation d'Apache Struts.

Une simple mise à jour vers la version la plus récente de Struts peut protéger l'application contre cette attaque, alors pourquoi les entreprises ne procèdent-elles pas immédiatement à cette mise à jour ? Le problème des vulnérabilités liées à la désérialisation est que les routines exploitées sont souvent celles sur lesquelles repose le code de l'application. Dans ce cas, l'application du nouveau correctif Struts pourrait avoir des effets secondaires, comme le mentionne la documentation sur la vulnérabilité : "Il est possible que certaines actions REST cessent de fonctionner en raison des restrictions par défaut appliquées aux classes disponibles." Il est très probable que s'assurer que l'application continue à fonctionner sur des versions plus récentes de Struts prenne un certain temps.

Les pirates n'ont cependant pas besoin d'autant de temps pour commencer à abuser des vulnérabilités publiées, et nous pouvons déjà voir certains exploits publiés. Un module Metasploit a été ajouté le 8 septembre, soit trois jours après qu'Apache a corrigé la vulnérabilité. Reporter votre correctif n'est manifestement pas une bonne idée !

La solution consiste à mettre en œuvre une solution de contournement proposée par Apache, ce qui pourrait être fait dans un délai plus court. Un outil de sécurité avec des règles de codage configurables pour appliquer cette solution de contournement ou même l'appliquer automatiquement accélérerait grandement ce processus.

Vous voulez en savoir plus sur la manière d'identifier et de sécuriser le code qui contient la désérialisation de données non fiables ? Visitez le portail Secure Code Warrior pour une explication claire et un défi de formation.

La vulnérabilité concerne la manière dont Struts analyse ce type de données et les convertit en informations pouvant être interprétées par le langage de programmation Java. Lorsque la vulnérabilité est exploitée avec succès, un code malveillant peut être caché à l'intérieur de ces données et exécuté lorsque Struts tente de les convertir.

https://qz.com/1073221/the-hackers-who-broke-into-equifax-exploited-a-nine-year-old-security-flaw/

Une fois de plus, la cause première du piratage d'Equifax est une vulnérabilité d'application web. Ce type de vulnérabilités existe depuis plus d'une décennie, mais il est toujours d'actualité. Chaque développeur devrait recevoir les outils nécessaires pour éviter d'introduire ces problèmes en premier lieu, grâce à une formation et à des conseils en temps réel lors du développement du code.

Equifax a déclaré avoir découvert la faille le 29 juillet. "Les criminels ont exploité une vulnérabilité de l'application d'un site web américain pour accéder à certains fichiers", a déclaré l'entreprise.

Lire la suite : La société d'évaluation du crédit Equifax déclare que l'incident de cybersécurité pourrait potentiellement affecter 143 millions de consommateurs américains.

Dans cet article de blog, nous allons :

• Démonstration de la recherche et de la mise en correspondance d'annotations
• Annotations Amen à l'aide de modèles mustache

Sensei permet de faire correspondre les modèles de code problématiques et de les modifier en fonction des implémentations convenues. Dans cet exemple, j'utilise @Disabled sans paramètre comme modèle de code problématique.

Annotation de test désactivé

Les tests désactivés sans raison précise peuvent s'avérer problématiques à long terme, car nous oublions pourquoi nous les avons désactivés.

@Disabled
   void thisTestMethodHasNoDisabledReason(){
    Assertions.fail("This test is disabled and should not run");
    }

Le risque est qu'au fil du temps, la base de code évolue, que le test désactivé ne soit pas mis à jour en fonction de l'objectif du code et qu'il finisse par devenir redondant et non pertinent, voire qu'il ne soit jamais réactivé.

Lors des revues de code, nous soulignons souvent qu'il est judicieux d'ajouter une description explicative en tant que paramètre d'annotation.

@Disabled ("Disabled to demonstrate adding a reason")
    void thisTestMethodHasDisabledReason(){
   Assertions.fail("This test is disabled and should not run");
   }

Une recette Sensei

Nous pouvons écrire une recette pour détecter quand @Disabled est ajouté sans explication et une solution rapide qui nous rappelle d'ajouter la raison réelle expliquant pourquoi nous l'avons désactivé.

Lorsque je pense à ce que je vais faire, je dois le faire :

• correspond à l'annotation Disabled sans aucun paramètre
• modifiez l'annotation Disabled pour qu'elle contienne un paramètre avec le texte du marqueur "TODO : ajoutez une description ici"

Créer une recette d'alerte

J'utilise Alt+Enter pour créer une nouvelle recette.

Ajoutez ensuite le texte descriptif de base dans les informations générales.

En faisant de la règle un avertissement, tout code correspondant est mis en évidence mais n'apparaît pas comme une erreur flagrante.

Trouver l'annotation

Dans l'éditeur de recettes, je modifie la recherche pour qu'elle corresponde à une annotation.

Cela permet de mettre en évidence toutes les annotations dans l'aperçu.

Ceci fait, je souhaite filtrer sur le type d'annotation.

Je pourrais simplement utiliser Disabled, mais je qualifie complètement la classe avec le package afin qu'elle ne corresponde qu'à l'annotation de JUnit 5. Comme le code source est affiché dans la prévisualisation, je peux facilement copier et coller ce texte à partir du code réel afin d'éviter les fautes de frappe.

Je souhaite ensuite ne faire correspondre que les annotations sans paramètres, et je peux utiliser l'interface graphique pour ce faire.

c'est-à-dire la recherche :

search:
  annotation:
    type: "org.junit.jupiter.api.Disabled"
    without:
       parameters:
          - {}

Créer une action de réécriture rapide

Pour ma correction rapide, j'utiliserai une action de réécriture.

J'utilise la fonctionnalité Show Variables pour afficher les variables de Mustache et prévisualiser leur contenu.

J'ajoute ensuite le code supplémentaire nécessaire à la création du commentaire de marqueur de lieu.

c'est-à-dire QuickFix :

availableFixes:
 - name: "Add a todo comment parameter"
   actions:
   - rewrite:
      to: "{{{ . }}}(\"TODO: add a description here\")"
      target: "self"

Sensei en action

Nous avons créé une courte vidéo montrant le processus de création de recettes en action.

Résumé

Lors de l'élaboration d'un correctif rapide de réécriture, il est plus facile de rechercher l'élément de code que l'on souhaite réécrire, car il s'agit alors de l'entité propre sur laquelle on peut agir.

Dans cet exemple, j'ai utilisé une action de réécriture pour modifier l'annotation. La réécriture est une action à usage général qui peut s'appliquer à n'importe quel élément de code et constitue une bonne option par défaut à explorer.

Exécuter les inspections IntelliJ à partir de l'intégration continue

IntelliJ IDEA offre des fonctionnalités pour aider à améliorer notre codage, au sein de l'IDE lorsque vous écrivez du code sous forme d'intentions. Les intentions peuvent être utilisées en batch pour inspecter le code à la recherche de modèles à travers la source et même s'étendre à l'analyse en ligne de commande ou être ajoutées à l'intégration continue. Cet article couvre les fonctionnalités d'IntelliJ et l'extension avec des Intentions personnalisées créées dans Sensei.

‍

IntelliJ Inspections

La fonction Inspections d'IntelliJ permet d'afficher la plupart des erreurs qui sont signalées dynamiquement dans l'IDE lors du codage, par exemple.

• détecter les classes abstraites qui peuvent être converties en interfaces,
• l'identification des champs de classe redondants qui peuvent être locaux,
• un avertissement concernant l'utilisation de méthodes obsolètes,
• etc.

Ces inspections mettent en évidence le code qui correspond dans l'IDE à des actions d'intention qui ont souvent un correctif rapide associé.

La mise en évidence en temps réel par l'IDE lorsque le code correspond à une inspection peut nous aider à améliorer notre codage de manière dynamique. Après avoir identifié le problème dans le code, l'utilisation des actions d'intention d'IntelliJ pour corriger rapidement le code peut renforcer les meilleurs modèles.

Profil d'inspection

Les inspections peuvent être exécutées par lots à partir de l'IDE, de la ligne de commande ou dans le cadre d'un processus d'intégration continue.

La clé pour travailler avec les inspections IntelliJ en tant que lot est l'utilisation d'un profil d'inspection.

IntelliJ a deux profils d'inspection par défaut : un stocké dans le projet, et un stocké dans l'IDE.

De nouveaux profils d'inspection peuvent être créés pour configurer des plugins ou des cas d'utilisation spécifiques.

• Exécutez uniquement l'analyse en temps réel de Checkstyle
• Exécutez un ensemble spécifique de règles Sensei
• Exécuter les contrôles HTML
  

Les inspections d'un profil peuvent être activées ou désactivées à partir des préférences d'IntelliJ. La boîte de dialogue Préférences est également un moyen facile de connaître la gamme d'inspections disponibles.

L'icône "outil" vous permet de dupliquer un profil et d'en créer un nouveau pour collecter un ensemble spécifique de règles.

Exécuter un profil d'inspection dans l'IDE

Les profils d'inspection peuvent être exécutés à partir de l'IDE en utilisant le menu `Analyze \ Inspect Code...`.

La fonctionnalité d'analyse vous permet de contrôler le champ d'application de l'inspection, par exemple l'ensemble du projet, y compris ou non les sources de test, ou un ensemble spécifique de fichiers. 

Vous pouvez également gérer les profils d'inspection à partir d'ici pour créer ou configurer un profil particulier.

En cliquant sur [OK] dans la boîte de dialogue "Specify Inspection Scope", IntelliJ lancera toutes les inspections sélectionnées dans le profil dans le périmètre défini.

IntelliJ va rapporter les résultats de l'exécution des inspections dans l'onglet `Inspection Results`.

Le plugin Sensei de Secure Code Warrior vous permet de créer des recettes de correspondance de code personnalisées. Sensei s'intègre étroitement à IntelliJ pour rendre ces recettes personnalisées aussi naturelles à utiliser que les actions d'intention d'IntelliJ. Cela signifie qu'elles sont chargées dans IntelliJ en tant qu'inspections et qu'elles peuvent être regroupées, activées et désactivées à l'aide de profils d'inspection. La création d'un profil d'inspection personnalisé et l'utilisation de la fonctionnalité Analyze Inspect Code est la méthode recommandée pour exécuter les recettes Sensei en masse dans un projet.

Exécution d'un profil d'inspection à partir de la ligne de commande

IntelliJ a la capacité d'exécuter des inspections à partir de la ligne de commande comme documenté par JetBrains :

- https://www.jetbrains.com/help/idea/working-with-the-ide-features-from-command-line.html

J'utilise principalement macOS, et je peux exécuter une seule instance d'IntelliJ à partir de la ligne de commande avec :

open -na "IntelliJ IDEA CE.app"

Pour faciliter l'exécution, je l'ajoute à un script de commande shell.

vi /usr/local/bin/idea

Le contenu du script provient de la documentation officielle fournie par IntelliJ.

#!/bin/sh
open -na "IntelliJ IDEA CE.app" --args "$@"

Je l'ai ensuite rendu exécutable afin de simplifier le processus d'inspection en ligne de commande.

chmod 755 /usr/local/bin/idea

La documentation officielle d'intellij décrit la forme générale de la commande d'inspection comme suit :

idea inspect <project> <inspection-profile> <output></output></inspection-profile></project>
[<options>]</options>

Dans la pratique, je qualifie pleinement les chemins et je n'ai besoin d'aucune option :

idea inspect /Users/user/GitHub/sensei-blog-examples /Users/user/GitHub/sensei-blog-examples/.idea/inspectionProfiles/senseiprofile.xml /Users/user/GitHub/sensei-blog-examples/scan-results

Ceci exécute toutes les inspections que j'ai ajoutées au `senseiprofile` et rapporte les résultats dans le dossier `scan-results`.

Visualisation des résultats de l'inspection

Nous pouvons rapporter ces résultats à partir de l'intégration continue, comme nous le verrons plus loin.

Nous pouvons également les visualiser dans IntelliJ lui-même en utilisant la fonction "Analyse \Voir les résultats de l'inspection hors ligne...\N".

Les résultats sont alors chargés dans l'onglet "Résultats de l'inspection".

Ceci est officiellement documenté sur le site de JetBrains :

- https://www.jetbrains.com/help/idea/command-line-code-inspector.html#inspection-results

Cela peut être utilisé au cours d'un processus d'examen du code si l'exécution de la ligne de commande a été incorporée dans un processus d'intégration continue et que les examinateurs souhaitent vérifier le contexte source complet de l'une des entrées du résultat de l'inspection.

Profils d'inspection dans l'intégration continue

Lorsque l'on ajoute l'inspection en ligne de commande à l'intégration continue, on souhaite idéalement qu'un rapport soit généré automatiquement et plusieurs options s'offrent à nous.

TeamCity offre une prise en charge immédiate des profils d'inspection dans l'intégration continue.

- https://www.jetbrains.com/help/teamcity/inspections.html

Le plugin Jenkins Warnings NG supporte la sortie de la ligne de commande d'IntelliJ Inspections comme l'un des formats de rapport.

- https://github.com/jenkinsci/warnings-ng-plugin

- https://github.com/jenkinsci/warnings-ng-plugin/blob/master/SUPPORTED-FORMATS.md

Des projets communautaires comme `idea CLI Inspector` existent pour supporter l'utilisation des profils d'inspection dans d'autres outils de CI, c'est-à-dire

- https://github.com/bentolor/idea-cli-inspector

L'avenir des profils d'inspection dans un processus de CI semble encore plus prometteur avec l'introduction du projet Qodana de JetBrains. Le projet Qodana est une version headless d'IntelliJ avec des actions Github officielles et des images Docker.

- https://github.com/JetBrains/Qodana

Qodana est actuellement en version bêta, mais l'équipe de Sensei la surveille afin qu'elle devienne une plateforme officiellement prise en charge pour l'exécution des règles Sensei dans le cadre de l'intégration continue.

Résumé

Les actions d'intention nous permettent de renforcer les modèles de codage et de les corriger rapidement dans l'IDE lorsque nous commettons des erreurs pendant le codage.

Les profils d'inspection nous permettent de les rassembler en profils qui peuvent être exécutés par lots en tant qu'action d'analyse et d'inspection du code. Cela peut s'avérer utile si nous rencontrons un modèle et que nous voulons vérifier si nous ne l'avons pas oublié ailleurs dans notre code.

Les profils d'inspection peuvent être exécutés à partir de la ligne de commande et même incorporés dans les processus d'intégration continue, ce qui permet d'appliquer le modèle "faire confiance, mais vérifier" et de détecter tout dérapage accidentel.

Tout ce qui précède est intégré dans les fonctionnalités d'IntelliJ et JetBrains améliore son processus d'intégration continue avec l'introduction de Qodana.

Sensei Les recettes sont chargées dans IntelliJ pour agir en tant qu'actions d'intention natives et être rassemblées dans des profils d'inspection pour prendre en charge la vérification par lots via Inspect Code et le support d'intégration continue fourni par la fonctionnalité officielle d'exécution en ligne de commande de JetBrains.

---

Vous pouvez installer Sensei à partir d'IntelliJ en utilisant "Preferences \ Plugins" (Mac) ou "Settings \ Plugins" (Windows) puis en recherchant simplement "sensei secure code".

Si vous voulez essayer d'exécuter un projet dans IntelliJ à partir de la ligne de commande, le projet utilisé dans ce billet peut être trouvé dans le dépôt `sensei-blog-examples` dans le compte GitHub Secure Code Warrior . Un exercice pour le lecteur est de créer un profil qui exécutera seulement les règles Sensei . Essayez-le :

https://github.com/securecodewarrior/sensei-blog-examples

En savoir plus sur Sensei