10 bonnes pratiques de sécurité pour Maven

Une fois encore, nous vous proposons une fiche pratique consacrée à la sécurité ! Ce mois-ci, découvrez 10 bonnes pratiques pour renforcer la sécurité de vos projets Maven. Maven est sans conteste l’outil de build le plus utilisé dans l’écosystème Java et JVM. *ATTENTION, DIVULGÂCHAGE !* Les résultats de notre enquête sur l’écosystème JVM, qui seront publiés en octobre, montrent que la domination de Maven se poursuit en 2018 et ne semble pas près de s’arrêter : six développeurs sur dix utilisent cet outil de build dans leur projet principal, comme le montre le graphique ci-dessous.

Il s’agit de la cinquième fiche pratique de Snyk cette année (déjà ? que le temps passe vite !). Nous avons déjà créé des fiches sur l’inférence de types en Java, les bonnes pratiques de sécurité sur GitHub, Zip Slip et les 10 bonnes pratiques de sécurité pour Spring Boot. Cet article a été imaginé en Crète, alors que j’étais allongé sur une plage avec le président du projet Apache Maven, Robert Scholte. Nous étions assis sur le magnifique sable doré, nous nous sommes baignés dans les eaux chaudes et splendides de Crète, et nous avons élaboré les 10 conseils de sécurité suivants. Ne dites pas que nous ne faisons jamais rien pour vous !

1. Chiffrez vos secrets

Depuis Maven 2.1.0, il est possible de chiffrer les mots de passe sur des machines de build partagées. Lorsque plusieurs utilisateurs ont accès à une machine partagée, ou qu’un fichier settings.xml est accessible à plusieurs utilisateurs, tous les secrets qu’il contient doivent être chiffrés. Si vous partagez des fichiers settings.xml avec d’autres développeurs, pensez à en retirer les secrets afin que seuls les utilisateurs autorisés puissent déployer des artefacts Maven dans les dépôts, et non toute l’équipe. Ces utilisateurs autorisés doivent disposer d’un fichier settings-security.xml stocké localement dans leur dossier de paramètres Maven ou dans un emplacement privé. Si vos builds s’exécutent dans un emplacement partagé par toute l’équipe, vous devez chiffrer les secrets du fichier settings.xml. Pour cela, vous devez créer un mot de passe principal que vous pourrez stocker et partager de manière appropriée.

Vous pouvez créer le mot de passe principal et les mots de passe des serveurs à l’aide de l’interface de ligne de commande Maven en exécutant la commande suivante :

MacBook-Pro-33:~ simonmaple$ mvn --encrypt-master-password
Master password:
{dDwpv7c3ZvAHBuXJjZrmz6nUaPrLK5Rt7F1n1N1FdZc=}

Une fois créé, enregistrez-le dans votre fichier ~/.m2/settings-security.xml comme suit :

<settingsSecurity> <master>{dDwpv7c3ZvAHBuXJjZrmz6nUaPrLK5Rt7F1n1N1FdZc=}</master> </settingsSecurity>

Vous pouvez maintenant créer un mot de passe de serveur en exécutant la commande suivante :

MacBook-Pro-33:~ simonmaple$ mvn --encrypt-password
Password:
{155kWnu2OdgHXof80X5kjyzhX/hAQbxNFCZtSE6aR7c=}

Enregistrez-le dans votre fichier settings.xml comme suit :

<server> <id>my.server</id> <username>smaple</username> <password>Simon reset this password on 2019-03-11, expires on 2019-04-11 {155kWnu2OdgHXof80X5kjyzhX/hAQbxNFCZtSE6aR7c=}</password> </server>

Pour en savoir plus, consultez la documentation Maven sur le stockage des secrets dans le fichier settings.xml.

2. N’utilisez pas de mots de passe dans l’interface de ligne de commande

Dans l’exemple précédent, nous avons montré la bonne manière d’ajouter des secrets à vos fichiers de configuration. Il existe aussi une mauvaise manière, et nous voulons nous assurer que vous la connaissez pour pouvoir l’éviter ! Une ancienne option des commandes de l’interface de ligne de commande présentées ci-dessus permet de saisir un mot de passe directement sur la ligne de commande pour les deux commandes de chiffrement, comme dans l’exemple suivant :

MacBook-Pro-33:~ simonmaple$ mvn --encrypt-master-password P@ssw0rd

"10 Même si cette méthode fonctionne et chiffre vos secrets, ne saisissez jamais vos secrets en texte brut sur une ligne de commande. Ils sont enregistrés dans l’historique de la console et peuvent facilement être récupérés.

3. Utilisez toujours HTTPS

Les dépôts Maven peuvent être locaux ou distants. Vos dépôts locaux, généralement situés dans le répertoire ~/.m2/repository/ de votre machine, contiennent des versions en cache des projets que vous avez précédemment téléchargés. Les dépôts distants peuvent être Maven Central ou un dépôt configuré par votre organisation avec Artifactory ou un outil similaire. Pour connaître les dépôts utilisés par votre build, consultez l’élément correspondant dans votre fichier pom.xml. Comme pour la plupart des communications aujourd’hui, il est essentiel d’utiliser HTTPS lorsque vous vous connectez à des services tiers. Les dépôts Maven ne font pas exception. Vérifier que vous communiquez bien avec les serveurs auxquels vous souhaitez vous connecter réduit le risque d’attaques de l’homme du milieu, ou plus précisément de vulnérabilités liées au téléchargement de ressources via un protocole non sécurisé.

Pour éviter ces risques, communiquez toujours avec les dépôts via HTTPS, même si le dépôt est hébergé par votre propre organisation. Pour ce faire, vérifiez que les éléments et de votre fichier pom.xml utilisent https dans leurs URL.

4. Vérifiez l’état de vos dépendances

L’intégration de dépendances tierces à nos applications est extrêmement courante, et les développeurs le font souvent sans trop se poser de questions, au-delà de « est-ce que ça fonctionne ? ». Pourtant, il est tout aussi important de vérifier que la dépendance est suffisamment saine avant de l’intégrer à notre application. Voici quelques critères permettant d’évaluer l’état d’un projet dont vous envisagez de dépendre :

Nombre de contributeurs actifs - Les projets open source maintenus par une ou deux personnes seulement peuvent présenter des risques, car ils dépendent souvent d’une seule personne pour les mises à jour et les versions. Une équipe de contributeurs réduit considérablement ce risque.

Politiques de sécurité documentées - En indiquant aux utilisateurs comment signaler les problèmes de sécurité, vous augmentez les chances que le projet en soit informé. De même, un mécanisme permettant aux utilisateurs d’être avertis des problèmes de sécurité et de leurs correctifs dès leur publication leur permet d’utiliser les dépendances de manière plus sûre.

Mises à jour et versions régulières - Vérifiez que les projets dont vous dépendez sont activement développés. Cela facilitera d’abord le développement futur de votre propre projet, puisque vous saurez que vos dépendances resteront à jour avec les fonctionnalités du langage, etc. Mais du point de vue de la sécurité, il est important de savoir que les problèmes signalés seront traités rapidement.

5. Recherchez les vulnérabilités connues

Les attaquants ciblent de plus en plus les dépendances open source : la réutilisation de bibliothèques leur offre de nombreuses victimes potentielles lorsqu’ils cherchent à exploiter une vulnérabilité connue. Il est important de vérifier qu’aucune vulnérabilité connue ne se trouve dans l’arbre complet des dépendances de votre application.

Des outils comme Snyk peuvent analyser les artefacts de build Maven et signaler les dépendances présentant des vulnérabilités connues. Un tableau de bord vous fournit la liste des vulnérabilités présentes dans les packages que vous intégrez via votre fichier pom.xml.

L’outil propose également des conseils de correction, qu’il s’agisse de mises à niveau de versions ou de correctifs créés par l’équipe de sécurité de Snyk. Si vous connectez votre outil de gestion du code source, par exemple GitHub, Bitbucket ou GitLab, vous pouvez corriger automatiquement vos problèmes de sécurité à l’aide d’une pull request ou merge request. Snyk continue de protéger votre environnement en testant automatiquement toutes les futures pull requests et merge requests à l’aide de webhooks, afin de s’assurer que d’autres développeurs n’introduisent pas de nouvelles vulnérabilités dans le projet.

Snyk est disponible via une interface web et une interface de ligne de commande. Vous pouvez donc facilement l’intégrer à votre environnement CI et le configurer pour interrompre votre build Maven lorsque des vulnérabilités dépassent le seuil de gravité que vous avez défini.

Vous pouvez utiliser Snyk gratuitement pour vos projets open source ou pour vos projets privés, avec un nombre limité de tests par mois.

6. Vérifiez les sommes de contrôle

Une somme de contrôle permet de détecter les erreurs susceptibles d’avoir été introduites lors du transfert ou du stockage des données. Il est important de vérifier les sommes de contrôle des dépendances de chacun de vos projets. Elles servent souvent à vérifier l’intégrité des données. Même si elles ne suffisent pas à confirmer l’authenticité de vos dépendances, elles constituent une vérification supplémentaire utile. Dans Maven 4, la vérification des sommes de contrôle de chaque dépendance sera activée par défaut. En attendant, utilisez l’option -C dans vos commandes Maven pour activer cette vérification : le build échouera si les sommes de contrôle ne correspondent pas.

$ mvn -C install // fail if checksums don’t match

$ mvn -c install // warn if checksums don’t match

7. N’utilisez pas de propriétés pour les mots de passe

Dans Maven, les propriétés servent couramment de variables de substitution dans les fichiers pom.xml. Vous pouvez définir une propriété, que nous appellerons my.property, dans l’exemple de fichier pom.xml ci-dessous :

<properties>
  <my.property>value</my.property>
</properties>

Vous pouvez ensuite référencer la propriété my.property partout dans ce fichier pom.xml à l’aide de la notation ${my.property}. Cette fonctionnalité est très pratique, mais elle facilite aussi le stockage de mots de passe destinés à être utilisés ailleurs. Ce faisant, vous stockez bien sûr des mots de passe en texte brut, que vous risquez de partager avec toute l’équipe. Il est préférable d’encourager les plugins à utiliser les entrées de serveur de votre fichier settings.xml.

8. Utilisez les développeurs et les rôles Maven

Comme l’a montré le rapport sur la sécurité de l’open source, il est important de fournir aux utilisateurs les informations nécessaires pour signaler un problème de sécurité. Les dépôts GitHub qui décrivent une procédure de signalement des vulnérabilités ont plus de trois fois plus de chances de recevoir des rapports de bugs de sécurité que ceux qui n’en ont pas.

Dans le fichier pom.xml de Maven, vous pouvez ajouter une balise developers contenant les coordonnées des contacts sécurité, au cas où quelqu’un aurait besoin de contacter un membre de votre équipe au sujet d’un problème de sécurité. Vous pouvez voir ci-dessous un exemple où j’ajoute Danny, notre référent sécurité interne.

<developers>
    <developer>
      <id>grander</id>
      <name>Danny Grander</name>
      <email>danny@snyk.io</email>
      <organization>Snyk</organization>
      <organizationUrl>https://snyk.io</organizationUrl>
      <roles>
        <role>security</role>
      </roles>
    </developer>
  </developers>
  ...
</project>

Dans l’idéal, utilisez une adresse e-mail générique, telle que security@yourdomain.com. Ainsi, si le contact sécurité venait à ne plus être disponible, le message arriverait tout de même dans une boîte de réception surveillée.

9. Restez à jour

Comme toujours, les mises à jour de sécurité sont intégrées aux versions récentes. Essayez donc de suivre les nouvelles versions de Maven. Vous réduirez ainsi le risque d’utiliser une version qui contient une faille de sécurité. Évitez tout particulièrement Maven 3.0.4, qui contient un problème de sécurité critique empêchant la vérification des certificats lors des connexions HTTPS. Pour obtenir la version la plus récente de Maven, rendez-vous sur la page de téléchargement de Maven.

10. Consultez les bulletins de sécurité

L’équipe Maven vous informe des problèmes de sécurité dans des bulletins publiés sur le site Apache Maven. Lorsque l’équipe de sécurité de Snyk a récemment découvert de nombreux cas de vulnérabilité Zip Slip, l’équipe Apache (qui a travaillé sans relâche avec nous pour éliminer les cas de Zip Slip dans les projets Apache) a publié un bulletin sur le site Apache Maven, comme ci-dessous :

Pensez à vous inscrire à la liste de diffusion announce@maven.apache.org et/ou à suivre @ASFMavenProject sur Twitter pour connaître les dernières actualités du projet Apache Maven.

Voilà qui conclut nos 10 bonnes pratiques de sécurité pour Apache Maven. Pensez à télécharger cette fiche pratique et à l’afficher à proximité pour garder la sécurité de vos builds à l’esprit !

TÉLÉCHARGER LA FICHE PRATIQUE !

Pensez à imprimer cette fiche pratique et à l’afficher quelque part pour vous rappeler les bonnes pratiques à suivre lorsque vous développez avec Maven.