Comment SonarQube stoppe les attaques de la chaîne d’approvisionnement comme le malware PyPI LiteLLM dans les pipelines DevOps

tableau de bord sca sonarqube

SonarQube offre une puissante analyse de composition logicielle (SCA) pour analyser les dépendances à la recherche de malwares et de vulnérabilités, bloquant ainsi les menaces telles que la récente compromission de PyPI litellm avant qu’elles n’infiltrent votre environnement de développement.

Ce pilier du DevSecOps s’intègre parfaitement aux pipelines CI/CD, idéal pour les projets Python vulnérables aux attaques de la chaîne d’approvisionnement. Ci-dessous, nous fournissons également des exemples d’intégration avec GitHub Actions et GitLab CI.

Pourquoi les attaques de la chaîne d’approvisionnement ciblent-elles les équipes DevOps ?

Les attaquants exploitent les dépôts publics comme PyPI avec du typosquattage ou des téléversements malveillants, comme on l’a vu avec la porte dérobée .pth de LiteLLM qui a échappé aux analyses de base.
Les téléchargements directs depuis ces sources contournent la sécurité traditionnelle, injectant des malwares dans les builds Docker, les clusters Kubernetes ou les runners GitHub / GitLab.

Pourquoi SonarQube anéantit-il les risques de la chaîne d’approvisionnement ?

Les attaques de la chaîne d’approvisionnement – pensez aux paquets PyPI malveillants qui volent des identifiants – exploitent des dépendances tierces.

La fonction Advanced Security de SonarQube analyse les fichiers manifestes tels que requirements.txt en les comparant aux bases de données de vulnérabilités et aux listes de paquets malveillants de l’OpenSSF.

  • Signale des problèmes bloquants pour les malwares connus, faisant échouer automatiquement les builds via les portes de qualité.
  • Trace les flux de données avec le SAST pour repérer les chemins d’exploitation dans les dépendances.
  • Génère des SBOM pour une visibilité complète sur les dépendances transitives.

Lors de l’attaque litellm (v1.82.7/1.82.8), SonarQube aurait détecté la charge utile d’exfiltration d’identifiants pendant l’analyse, alertant instantanément votre équipe.

Détection de malwares dans les environnements de développement

SonarQube 2026.1+ détecte explicitement les paquets malveillants dans PyPI, npm et bien d’autres, en les traitant comme des incidents critiques – et non comme de simples vulnérabilités.

Défenses clés :

  • Le blocage CI/CD en temps réel empêche la fusion de code corrompu.
  • Les informations fournies par les mainteneurs via Tidelift réduisent le bruit lié aux faux positifs.
  • L’édition Serveur auto-hébergée convient aux configurations isolées (air-gapped), s’alignant sur les flux de travail DevOps des entreprises.

Fini les dépendances malveillantes qui s’infiltrent en production ! Les portes de qualité garantissent des pipelines propres à chaque commit.

Avantages de l’intégration

Intégrez les analyses dans vos pipelines CI/CD pour une sécurité shift-left, en phase avec votre approche DevSecOps et vos besoins de systèmes isolés via le serveur SonarQube auto-hébergé.
Réduit les faux positifs grâce à des informations sur l’exploitabilité et des données vérifiées par les mainteneurs via l’intégration de Tidelift.

Intégration GitHub Actions : Exemple étape par étape

Intégrez SonarQube dans vos GitHub Actions pour une sécurité shift-left sur les dépôts Python.
Voici un workflow YAML éprouvé sur le terrain :

textname: SonarQube Scan
on: [push, pull_request]
jobs:
sonarqube:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0 # For accurate analysis

- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: '3.11'

- name: Install dependencies
run: |
python -m pip install --upgrade pip
pip install -r requirements.txt

- name: SonarQube Scan
uses: SonarSource/sonarqube-scan-action@v3
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}

- name: Quality Gate Check
run: |
# Optional: Wait for Quality Gate (Enterprise feature)
curl -f -u ${{ secrets.SONAR_TOKEN }}: \
"${{ secrets.SONAR_HOST_URL }}/api/qualitygates/project_status?projectKey=${{ secrets.SONAR_PROJECT_KEY }}"

Conseils de configuration :

  1. Générez le SONAR_TOKEN dans SonarQube > Mon compte > Sécurité.
  2. Ajoutez des secrets au dépôt GitHub : SONAR_TOKEN, SONAR_HOST_URL (votre serveur SonarQube), SONAR_PROJECT_KEY.
  3. Configurez des portes de qualité pour bloquer les paquets malveillants ou les problèmes SCA de haute gravité.

Cela fait échouer les PR présentant des risques similaires à litellm, maintenant ainsi la sécurité de votre chaîne d’approvisionnement.

Intégration GitLab CI : Exemple étape par étape

Tirez parti de votre expertise GitLab avec l’intégration native de SonarQube pour une sécurité GitOps optimale. Ajoutez ceci à votre fichier .gitlab-ci.yml :

stages:
- test
- sonar

variables:
SONAR_TOKEN: $SONAR_TOKEN
SONAR_HOST_URL: $SONAR_HOST_URL
GIT_DEPTH: 0 # Shallow clone for full history

sonar-scan:
stage: sonar
image: python:3.11
script:
- pip install --upgrade pip
- pip install -r requirements.txt
- /usr/bin/sonar-scanner
-Dsonar.projectKey=my-python-project
-Dsonar.sources=.
-Dsonar.python.coverage.reportPaths=coverage.xml # Optional
only:
- main
- merge_requests
allow_failure: false # Fail on quality gate violation

Conseils de configuration :

  1. Installez le plugin SonarQube GitLab ou utilisez l’image Docker.
  2. Stockez SONAR_TOKEN et SONAR_HOST_URL en tant que variables CI/CD (Paramètres du projet > CI/CD > Variables).
  3. Activez la décoration des Merge Requests pour obtenir des commentaires Sonar en ligne.
  4. Les portes de qualité bloquent automatiquement les MR contenant des dépendances malveillantes comme le malware litellm.

Cela applique le SCA à chaque exécution de pipeline, idéal pour vos piles Kubernetes/GitOps.

Sécurité Shift-Left pour les architectes DevOps

Pour les équipes GitOps, DevOps ou Kubernetes, le SCA de SonarQube Enterprise fournit des évaluations d’exploitabilité et garantit la conformité des licences. Associez-le à GitHub / GitLab pour des portes de qualité automatisées qui s’adaptent aux projets à l’échelle américaine et européenne.

Astuce de pro : Épinglez les dépendances (litellm<1.82.7) après l’analyse, puis revérifiez. Cela réduit le MTTR de plusieurs jours à quelques minutes.

Points clés à retenir pour un DevOps sécurisé

SonarQube transforme votre environnement de développement en une forteresse renforcée contre les menaces de la chaîne d’approvisionnement, des malwares PyPI aux vulnérabilités OSS. Idéal pour les architectes DevOps gérant la conformité US/UE, il évolue de l’auto-hébergement vers le cloud sans friction dans les flux de travail.

Voulez-vous bloquer le prochain LiteLLM ?
Contactez-nous pour obtenir un essai et assainir vos dépôts dès aujourd’hui.

ALM-Toolbox est le seul distributeur de SonarSource (éditeur de SonarQube, SonarCloud et SonarLint) en Israël et dans d’autres pays,
fournissant des services gérés, du support, des formations, du conseil DevOps / CI/CD, ainsi que des licences pour SonarQube et une variété d’outils complémentaires de développement et DevOps.
Pour plus de détails, contactez-nous à l’adresse sonarqube@almtoolbox.com ou par téléphone au 866-503-1471 (États-Unis / Canada) ou au +31 85 064 4633

Liens utiles :

Comment GitLab aide à prévenir les attaques de la chaîne d’approvisionnement et l’intrusion de malwares dans les environnements de développement

gitlab devsecops appsec alm-toolbox

L’utilisation de GitLab comme plateforme DevOps de bout en bout vous aide à prévenir les attaques de la chaîne d’approvisionnement (comme la récente compromission de PyPI litellm) et à bloquer l’intrusion de malwares dans votre environnement en appliquant des contrôles directement dans le pipeline CI/CD, le flux de dépendances et la couche d’identité.

Voici comment cela se traduit concrètement par rapport à votre modèle de menace.

Remarque : La mise en œuvre de ces pratiques nécessite une instance GitLab (Auto-hébergée ou SaaS) et un abonnement GitLab Ultimate.
De plus, une compréhension de base des concepts DevOps, DevSecOps ou AppSec est recommandée.
Si vous avez besoin d’aide concernant les licences ou l’implémentation technique, n’hésitez pas à contacter notre équipe à gitlab@almtoolbox.com ou à nous appeler.

1. Bloquer les dépendances malveillantes ou vulnérables

Lorsqu’un paquet comme litellm est empoisonné et publié sur PyPI, GitLab peut réduire ou empêcher l’impact via :

  • Analyse des dépendances (Dependency Scanning) : Inspecte automatiquement vos fichiers requirements.txt, package-lock.json, etc., et signale les paquets compromis ou présentant des vulnérabilités connues (y compris ceux extraits de PyPI) dans chaque pipeline.
  • Nomenclature logicielle (SBOM) et graphe de dépendances : GitLab peut générer une nomenclature logicielle et suivre quels projets dépendent de quelles versions ; vous pouvez ainsi bloquer ou corriger à chaud les versions dangereuses avant qu’elles n’atteignent la production.
  • Proxy / Pare-feu de dépendances : Si vous utilisez le proxy de GitLab pour votre flux PyPI/NPM/etc., vous pouvez restreindre les versions autorisées et imposer l’utilisation exclusive de sources amont « approuvées ».

Impact pratique : Même si quelqu’un écrit pip install litellm dans un fichier requirements.txt, GitLab peut faire échouer la tâche ou bloquer la compilation si la version installée figure dans votre politique de vulnérabilités/liste blanche.

2. Sécuriser le pipeline CI/CD lui-même

L’attaque de type litellm a mis en évidence un modèle où des bibliothèques malveillantes dans le CI/CD exfiltrent des jetons et des secrets ; GitLab atténue ce risque par :

  • La protection du fichier .gitlab-ci.yml et des variables :
    • L’exigence de branches protégées, des modifications du fichier .gitlab-ci.yml contrôlées par des CODEOWNERS, et un accès strict basé sur les rôles afin que les attaquants ne puissent pas injecter de tâches malveillantes.
    • L’utilisation de variables protégées et de secrets masqués pour que seuls les pipelines approuvés puissent y accéder.
  • La sécurisation des runners :
    • L’utilisation de « runners protégés » et de runners par projet afin que le piratage d’un projet n’accorde pas un accès étendu à l’ensemble de votre CI/CD.
  • La détection des secrets : Analyse les commits et les requêtes de fusion pour détecter les clés API, les jetons ou les secrets validés accidentellement ; cela évite qu’ils n’arrivent dans la branche principale.

Impact pratique : Si un attaquant parvient à injecter un script malveillant dans une tâche, une portée plus stricte des variables et l’isolement des runners limitent les données qu’il peut voler ou sa capacité à se propager.

3. Empêcher l’intrusion de code de type malware dans votre environnement

GitLab agit comme une « barrière » avant que le code et les artefacts n’atteignent la production :

  • L’intégration de la sécurité en amont (Shift-left) dans chaque pipeline :
    • Les analyses SAST (vulnérabilités au niveau du code), DAST (à l’exécution), des conteneurs et de la conformité des licences s’exécutent dans chaque tâche afin de détecter très tôt les schémas de type cheval de Troie, les portes dérobées ou les codes à l’apparence malveillante.
  • Des barrières d’approbation avant le déploiement :
    • Vous pouvez imposer des approbations, des barrières basées sur les analyses de sécurité et « exiger la réussite du pipeline » pour les environnements de production, afin qu’un commit ou une dépendance malveillante ne puisse pas être déployé silencieusement.
  • La traçabilité et les journaux d’audit :
    • GitLab garde une trace de chaque modification, fusion, exécution de pipeline et déploiement, ce qui facilite la recherche de l’origine d’un malware (par exemple, via un paquet installé par tox) et permet de revenir en arrière ou de le bloquer.

Impact pratique : Toute modification de « type malware » (par exemple, un nouveau paquet qui commence à appeler des terminaux de communication étranges ou à modifier des fichiers) doit soit être interceptée par une analyse, soit bloquée par une politique, soit laisser une piste d’audit claire que vous pouvez suivre.

4. Identité, accès et contrôles Zero-Trust

Les attaques de la chaîne d’approvisionnement reposent souvent sur le vol d’identifiants et des rôles trop permissifs. GitLab vous aide via :

  • Un RBAC granulaire et l’A2F : Imposez l’authentification à double facteur, des rôles selon le principe du moindre privilège, et des approbations pour les modifications en production.
  • Les commits signés et les auteurs vérifiés : Exigez des commits signés par GPG et vérifiez qui a réellement poussé le code ; GitLab peut rejeter les auteurs non signés ou non fiables, réduisant ainsi l’usurpation d’identité.
  • Une journalisation prête pour l’audit : Vérifiez qui a modifié le pipeline, quelles dépendances ont été ajoutées et quels environnements ont été touchés après un incident.

Impact pratique : Cela empêche plus efficacement un attaquant de pirater le compte d’un développeur ou d’injecter du code corrompu sans être rapidement détecté.

Comment cela s’applique-t-il à vous si vous êtes un architecte DevOps / DevSecOps ?

En tant qu’utilisateur de GitLab, vous pouvez :

  • Traiter GitLab comme le moteur de politiques central pour :
    • Les versions de dépendances autorisées.
    • Les analyses de sécurité requises.
    • Les branches et les environnements protégés.
  • Utiliser l’analyse des dépendances + la SBOM + les approbations de GitLab pour :
    • Détecter et bloquer les paquets empoisonnés comme litellm (même s’ils ne figurent pas encore dans les bases de données CVE).
    • Appliquer le « blocage des dépendances ayant un niveau CVE ou violant les politiques » dans les barrières des requêtes de fusion.

ALM Toolbox a aidé des centaines de clients à prendre en charge GitLab, à choisir l’édition et la licence GitLab appropriées, ainsi qu’à planifier la mise en œuvre et le déploiement du produit.
Nous sommes partenaires officiels de GitLab depuis 2016 et détenons les titres décernés par l’entreprise GitLab :

Selected Partner, GitLab Hero et « GitLab Champion » ainsi que des certifications professionnelles officielles GitLab après avoir réussi les examens de qualification.
Récemment, nous avons également été sélectionnés par le cabinet d’études STKI comme « GitLab Selected Partner » pour 2025.
Vous pouvez nous contacter par e-mail à l’adresse gitlab@almtoolbox.com ou nous appeler :

866-503-1471 (États-Unis / Canada) ou +01 84 17 53 28

Liens connexes :

Comment Socket aide à prévenir les attaques de la chaîne d’approvisionnement et l’intrusion de malwares dans les environnements de développement

socket logo

Socket.dev offre une sécurité proactive pour les dépendances open source en analysant le code et le comportement des paquets pour bloquer les menaces que les scanners de vulnérabilités traditionnels ne détectent pas.

Comprendre les risques liés aux attaques de la chaîne d’approvisionnement

Les attaques de la chaîne d’approvisionnement ciblent vos dépendances de développement, en injectant des malwares via des paquets piratés ou des mises à jour malveillantes. Socket.dev analyse le code des paquets en temps réel, détectant plus de 70 signaux d’alarme (red flags) tels que le code offusqué, l’exfiltration de données et les appels d’API à privilèges (par exemple, l’accès au système de fichiers ou eval()).

Cela permet de bloquer les menaces avant qu’elles n’entrent dans votre environnement, y compris dans les versions mineures où les CVE (Common Vulnerabilities and Exposures) ne les repèrent pas.

Prévention des attaques de la chaîne d’approvisionnement

Socket surveille les changements de dépendances en temps réel, comme dans les fichiers package.json, et détecte les infiltrations telles que les paquets piratés ou compromis avant qu’ils n’atteignent votre environnement. Il signale les mises à jour suspectes, notamment l’ajout soudain d’API à privilèges (par ex. accès au système de fichiers, appels réseau, child_process, eval()) dans des versions mineures ou des correctifs. Cela prévient les attaques visant le processus de développement lui-même, où les modifications malveillantes contournent la détection basée sur les CVE.

Blocage des malwares

Socket recherche plus de 70 signaux d’alarme dans des catégories telles que les risques de la chaîne d’approvisionnement, les malwares, le code caché et les problèmes de qualité dans les écosystèmes JavaScript, Python et Go. Il bloque le code offusqué ou minifié, l’exécution dynamique de code à distance, l’exfiltration de données (par ex., l’envoi d’identifiants via HTTP) et la télémétrie vers des domaines suspects. À titre d’exemple, on peut citer le blocage de paquets comme “fiinquant” (exec offusqué) ou “codapt” (récupération distante de JS) alors même qu’ils étaient en ligne sur les registres.

socket litellm detection

Socket a détecté le dernier malware Pypi litellm (mars 2026) – vous pouvez voir ici comment il empêche le téléchargement d’une version infectée

Réponse à la détection de malwares

Dès la détection, Socket génère des alertes exploitables contenant des détails sur la menace (par ex., “Backdoor” ou “Infostealer”) et bloque le téléchargement du paquet via son proxy Firewall s’il est configuré – empêchant ainsi complètement l’installation.
En mode CLI (socket scan ou socket install), il s’arrête avec un code non nul, ce qui fait échouer l’étape du pipeline.

Les avantages de l’intégration avec la CI/CD

Socket.dev s’intègre aux principales plateformes de CI/CD grâce à son interface en ligne de commande (CLI) et à ses jetons d’API, permettant d’effectuer des analyses de sécurité dans les pipelines et de bloquer les fusions lorsqu’il est intégré aux outils de CI ou via des règles de protection des branches.

Voici quelques exemples :

1) Intégration à GitHub Actions

Socket offre une prise en charge native de GitHub Actions via son CLI (socketcli) et des workflows dédiés.
Il analyse les dépendances lors des requêtes d’extraction (PR) et des exécutions CI, en créant des rapports ou en bloquant les modifications à risque.

2) Intégration à GitLab CI

Socket propose une intégration directe à GitLab CI via des commandes CLI dans les pipelines .gitlab-ci.yml.
La documentation officielle fournit les étapes de configuration, y compris l’utilisation de jetons d’API pour analyser les manifestes et bloquer les risques liés à la chaîne d’approvisionnement.

Il analyse les dépendances pendant les demandes de fusion (MR) et les exécutions CI, en créant des rapports ou en bloquant les modifications à risque.

3) Intégration à Jenkins CI

L’intégration de Jenkins est disponible via le CLI de Socket.
Utilisez-le dans vos pipelines Jenkins (par ex., Jenkinsfile) en installant l’image Docker/CLI, en configurant des variables d’environnement telles que SOCKET_CLI_API_TOKEN, et en exécutant les étapes socket install ou socket scan.

ALM Toolbox est le distributeur officiel des solutions Socket. Nous vous accompagnons dans la mise en œuvre de Socket, le choix des licences adaptées à vos besoins, l’intégration avec les outils de CI et l’application des meilleures pratiques DevSecOps et AppSec.
Pour plus de détails, essayer Socket ou obtenir un devis – contactez-nous :
socket@almtoolbox.com ou par téléphone : 866-503-1471
(États-Unis / Canada) ou +31 85 064 4633

Liens connexes :

Docker démocratise la sécurité des conteneurs : les images durcies sont désormais gratuites

images docker durcies

Dans une démarche significative destinée à remodeler le paysage du DevSecOps, l’entreprise Docker a annoncé que son catalogue d’« Images Durcies » (Hardened Images) est désormais gratuit et open source.
Auparavant proposée comme une offre premium réservée aux abonnements d’entreprise, cette transition vise à établir un nouveau standard de sécurité pour la chaîne logistique logicielle.

Pour les équipes DevOps, les responsables R&D et les RSSI (CISO), cette annonce marque un tournant critique :
La « sécurité par défaut » n’est plus une fonctionnalité de luxe, mais une brique de base standard.

Voici une analyse de ce que cela signifie pour votre infrastructure et comment naviguer dans cette nouvelle offre étagée.

Que sont les « Images Durcies » ?

En bref, les Images Durcies sont des images de conteneurs qui ont été agressivement minimisées et sécurisées pour une utilisation en production.

Contrairement aux images de base standard (comme une image générique ubuntu ou node), qui sont souvent surchargées de shells, de gestionnaires de paquets et de bibliothèques inutilisées, les images durcies suivent une approche « distroless » ou minimaliste. Elles éliminent tout ce qui n’est pas strictement nécessaire au fonctionnement de l’application.

Les caractéristiques techniques clés incluent :

  • Surface d’attaque réduite : En supprimant les composants non essentiels (comme bash, apt ou apk), les points d’entrée potentiels pour les attaquants sont réduits jusqu’à 95 %.
  • Non-Root par défaut : Ces images sont configurées pour s’exécuter en tant qu’utilisateur non privilégié, atténuant ainsi le risque d’attaques par évasion de conteneur.
  • Provenance certifiée : Elles sont fournies avec une provenance SLSA (Supply-chain Levels for Software Artifacts) de niveau de construction 3, garantissant que le processus de compilation est infalsifiable.
  • Transparence : Chaque image est livrée avec une nomenclature logicielle (SBOM) signée cryptographiquement et des données transparentes sur les vulnérabilités (CVE).

Qu’est-ce que cela signifie pour les utilisateurs ?

La décision de Docker de rendre ces images open source sous la licence Apache 2.0 démocratise l’accès à une sécurité de haut niveau.

  1. Standardisation de la sécurité de la chaîne logistique :

Pour les RSSI, cela élimine la friction liée à la justification du budget pour des images de base sécurisées. Les équipes de développement peuvent désormais s’appuyer immédiatement sur des fondations sûres sans délais d’approvisionnement. Cela relève efficacement le « seuil minimal » de la sécurité des conteneurs : même les petites startups peuvent désormais déployer avec la même rigueur que les grandes entreprises.

  1. Efficacité opérationnelle pour le DevOps :

Pour les experts DevOps, cela réduit le labeur de maintenance des « golden images » personnalisées. Au lieu de construire et de corriger vos propres images de base minimales à partir de zéro, vous pouvez vous fier au catalogue maintenu par Docker. Cela renvoie la responsabilité de la correction de l’OS de base (par exemple, pour les couches Alpine ou Debian) à Docker, permettant à votre équipe de se concentrer sur la logique applicative.

  1. Adoption sans friction :

Parce que ces images sont construites sur des fondations familières comme Alpine et Debian, elles sont conçues comme des solutions de remplacement immédiates (drop-in). La migration nécessite généralement des changements minimes aux Dockerfiles existants, bien que les développeurs doivent tenir compte de l’absence de shell lors du débogage (nécessitant des conteneurs de débogage éphémères).

Qu’est-ce qui est fourni gratuitement ?

Le niveau « Gratuit » est substantiel et couvre les besoins de la plupart des cas d’usage généraux de développement et de production.

  • Accès au catalogue complet : Plus de 1 000 images durcies et graphiques Helm sont disponibles gratuitement.
  • Métadonnées de sécurité : Vous obtenez un accès complet aux SBOM, aux rapports de vulnérabilité et aux données de provenance SLSA.
  • Licence Open Source : Les images sont sous licence Apache 2.0, permettant une large utilisation et modification sans verrouillage propriétaire (vendor lock-in).

Mises à jour de build : Les images sont continuellement scannées et mises à jour par Docker pour maintenir le nombre de CVE proche de zéro.

Qu’est-ce qui est payant ? (La différence Entreprise)

Bien que les bits soient gratuits, les garanties et les fonctionnalités de conformité restent payantes. Les responsables R&D et les RSSI dans les industries réglementées devront toujours se tourner vers le niveau Entreprise.

Les principaux différenciateurs du modèle payant incluent :

Fonctionnalité Niveau Gratuit Niveau Entreprise
SLA pour les correctifs Mises à jour au mieux (Best effort) SLA de remédiation de 7 jours pour les CVE critiques (avec une feuille de route vers 24 heures)
Conformité Sécurité Standard Versions compatibles FIPS et prêtes pour DoD STIG
Personnalisation Images standards Personnalisation sécurisée tout en maintenant la provenance
Support Hérité Aucun Support du cycle de vie étendu (ELS) : Correctifs jusqu’à 5 ans après la fin de vie en amont

Conclusion :

La décision de Docker reconnaît qu’en 2026, la sécurité ne peut pas être un bonus ; elle doit être la norme.
En rendant les images durcies gratuites, Docker permet aux organisations de sécuriser leur chaîne logistique en amont (« left of boom »). Pour la plupart des utilisateurs, le niveau gratuit est une mise à niveau évidente par rapport aux images standard.
Cependant, pour les entreprises nécessitant une conformité réglementaire stricte (FedRAMP, HIPAA) ou des SLA de correction garantis, le modèle commercial reste essentiel.

À propos d’ALM Toolbox :
ALM Toolbox est un « Partenaire Privilégié » officiel de Docker dans de nombreux pays, et possède une vaste expérience avec les produits Docker, tant sur le plan professionnel/technologique que commercial (vente de licences et gestion optimisée des coûts de licence).
L’entreprise propose une large gamme de solutions autour du produit, incluant la conception et la mise en place d’environnements, des services gérés sur cloud privé, du conseil, de la vente de licences, l’intégration avec des outils complémentaires (tels que GitHub, GitLab, Jenkins, SonarQube, Argo, Bitbucket, Azure DevOps, Kubernetes), de la formation, et plus encore.
Pour plus de détails, contactez-nous : docker@almtoolbox.com
ou appelez-nous : +33 01 84 17 53 28

Liens connexes :

L’attaque Shai-Hulud sur NPM expliquée

Mise à jour de novembre 2025 : Plus loin dans l’article, une explication de la deuxième attaque (« Shai‑Hulud 2.0 »)

Une cyberattaque de grande envergure visant l’écosystème NPM a débuté le 16 septembre 2025.
L’attaque a été surnommée « Shai-Hulud ».
L’attaque, qui est une évolution d’un incident précédent datant d’environ une semaine,
se propage comme un ver (worm) auto-réplicable,
et infecte des paquets populaires, y compris ceux de Nx et CrowdStrike.

Dune Sandworm

Les principaux risques incluent le vol d’identifiants cloud (cloud credentials) et de clés de plateformes majeures,
l’auto-propagation via des comptes de développeur NPM (NPM developer accounts) compromis,
et la fuite de plus de 700 dépôts GitHub (GitHub repositories) publics.

Quelles sont les implications ? Et quelles actions entreprendre ?

Notez que les machines infectées sont considérées comme entièrement compromises (fully compromised) !
Il est recommandé de prendre des mesures immédiates, telles que l’analyse des paquets open source à l’aide d’outils SCA,
la suppression ou le verrouillage (pinning) des paquets à des versions sûres,
la réactualisation des autorisations d’accès aux dépôts externes,
et d’envisager la réinstallation des systèmes affectés.

À plus long terme, il est recommandé de prendre des mesures préventives supplémentaires, telles que l’utilisation d’outils de gestion des secrets (Secrets management),
l’activation d’alertes pour les paquets infectés, le durcissement des images (hardening), et plus encore.
Cette alerte souligne que la sécurité de la chaîne d’approvisionnement (supply chain security) s’étend désormais au-delà des CVE traditionnels et inclut également les informations d’identification,
les autorisations et les vulnérabilités CI/CD, ce qui nécessite une consultation urgente avec les équipes de sécurité.

Si vous avez besoin d’une aide immédiate pour résoudre ce problème, grâce à nos connaissances pratiques combinant DevSecOps / DevOps
et la protection du code et des applications, contactez-nous :
appsec@almtoolbox.com ou par téléphone : 072-240-5222

Écoutez ici une brève explication sur le sujet (2 minutes) :

Une explication plus approfondie sur le sujet (19 minutes) :

Les explications enregistrées ci-dessus concernent la première vague de l’attaque (septembre 2025)

Mise à jour importante : Shai‑Hulud 2.0 – Une nouvelle vague d’attaques depuis le 24/11/2025

Fin novembre 2025, une nouvelle vague améliorée de l’attaque a été identifiée, connue dans la communauté sous le nom de Shai‑Hulud 2.0 ou
« Sha1‑Hulud: The Second Coming », au cours de laquelle de nouvelles versions malveillantes ont été implantées dans des centaines de paquets NPM supplémentaires, avec des centaines de nouvelles versions utilisées par des dizaines de milliers de projets.
Cette vague est considérée comme une continuation directe de la campagne de septembre, mais avec des capacités de propagation, d’automatisation et de destruction plus avancées, et elle est toujours considérée comme un événement actif et en cours.​

Quoi de neuf dans la deuxième vague ?

Dans la version 2.0, l’attaque utilise des scripts d’installation (install / preinstall lifecycle scripts) et de nouveaux fichiers de charge utile (payload) comme setup_bun.js et bun_environment.js, qui permettent d’exécuter du code malveillant dès la phase d’installation et sans interaction supplémentaire de la part du développeur. La charge utile pénètre beaucoup plus profondément dans l’environnement CI/CD : elle crée des fichiers tels que cloud.jsonenvironment.jsontruffleSecrets.json et tente même d’injecter un fichier de workflow pour obtenir un point d’ancrage persistant dans GitHub Actions.​

De plus, la nouvelle attaque enregistre les machines infectées en tant que runners GitHub auto-hébergés (self-hosted GitHub runners) sous le nom de SHA1HULUD, ce qui permet à l’attaquant d’exécuter du code à sa guise au sein de l’infrastructure CI/CD de l’organisation sur la durée et de manière relativement discrète. Dans certains cas, une capacité de suppression et de perturbation des dépôts et des pipelines a également été documentée, de sorte qu’une tentative pour « éteindre » l’attaque pourrait entraîner de graves dommages au code et à l’infrastructure.​

Étendue actualisée de l’impact

Comparée à la première vague, la seconde a considérablement élargi la portée de l’infection, avec des centaines de paquets NPM uniques infectés (en fait, près de 800), totalisant plus de 20 millions de téléchargements hebdomadaires,
et plus de 25 000 à 28 000 dépôts GitHub exposés à des secrets divulgués.

Plusieurs organisations connues, y compris de grandes entreprises SaaS et des projets open source populaires,
ont signalé rétrospectivement avoir été touchées et ont dû procéder à une rotation massive de leurs secrets et à une restauration complète de leur environnement CI/CD.​

Le nouveau ver n’est plus limité à NPM : des rapports font état de tentatives de propagation à d’autres écosystèmes comme Maven, en utilisant les mêmes techniques de vol de secrets, d’enregistrement de runners malveillants et de publication de dépôts dédiés sur GitHub pour la collecte d’informations. Tout cela renforce la compréhension qu’il s’agit d’une campagne d’attaque de la chaîne d’approvisionnement large et continue, et non d’un événement isolé ou ponctuel.​

Mise à jour de la liste des risques

En plus des risques déjà décrits dans l’article original (vol d’identifiants cloud, fuite de dépôts GitHub, etc.), la vague actuelle ajoute plusieurs points importants :

  • Transformation de l’environnement CI/CD lui-même en un point de contrôle persistant pour l’attaquant, y compris des runners malveillants et des workflows dérobés (backdoored).​
  • Automatisation étendue du « worming » – une tentative systématique d’infecter davantage de paquets, de dépôts et d’organisations en utilisant des identifiants volés précédemment.​
  • Capacités d’escalade de privilèges (Privilege Escalation) dans les environnements Docker et exécution dans les environnements Linux, Windows et macOS, tout en tentant de s’échapper des conteneurs vers le système d’exploitation hôte.​

Par conséquent, une machine ou un pipeline exposé à Shai‑Hulud 2.0 est considéré non seulement comme « entièrement compromis », mais aussi comme une base potentielle pour une propagation ultérieure à l’intérieur et à l’extérieur de l’organisation !​

Recommandations d’action mises à jour :

En plus des recommandations existantes ci-dessus (analyse SCA, épinglage à des versions sûres, actualisation des autorisations, réinstallations, etc.), il est recommandé d’ajouter les actions suivantes :

  1. Effectuer une rotation agressive de tous les secrets stockés dans les environnements CI/CD, GitHub/GitLab, les clouds AWS/Azure/GCP et les registres de paquets – même en l’absence d’indication certaine d’une compromission.​
  2. Effectuer un examen complet des pipelines CI de GitHub Actions / GitLab, y compris la détection de workflows inconnus (par exemple, ceux liés à des événements de discussion ou à de nouveaux runners), et leur suppression immédiate.​
  3. Durcir la gestion des runners : limiter les runners auto-hébergés, surveiller les noms/étiquettes suspects (par exemple SHA1HULUD) et appliquer le principe de moindre privilège sur chaque runner.​
  4. Utiliser des outils de SCA et de Secrets Scanning dédiés, capables de détecter également les schémas de vers et les comportements suspects (scripts au moment de l’installation, déclencheurs inhabituels dans les pipelines, etc.), et pas seulement les CVE standards.​
  5. Envisager sérieusement d’utiliser des registres privés / proxys internes avec une liste blanche (allowlist), agissant comme un pare-feu,
    afin de réduire la dépendance directe à l’égard du registre NPM public et d’empêcher le téléchargement de versions infectées en temps réel.​

Liens utiles :

Vous avez d’autres questions ?

Contactez-nous pour toute question, y compris les tarifs, les devis et plus encore : devops.fr@almtoolbox.com  ou appelez-nous : +33 1 84 17 53 28 , 866-503-1471 (États-Unis / Canada) ou +31 85 064 4633 (International)

L’article a été publié pour la première fois en septembre 2025. Dernière mise à jour : décembre 2025.

L’image ci-dessus a été initialement mise en ligne sur YouTube sous une licence CC BY.

Développement de Code Sécurisé (2026)

L’article suivant explique brièvement le concept de Code Sécurisé et passe en revue les solutions que nous proposons dans ce domaine.

code sécurisé

En plus des outils de développement et des solutions DevOps, nous proposons une variété de solutions de Développement de Code Sécurisé
et une assistance pour la sécurisation des applications cloud (AppSec).
Nous fournissons une solution de bout en bout incluant la spécification, la planification, l’aide au choix des outils appropriés, l’implémentation, l’intégration aux outils et processus de développement, le support / services gérés, et les licences.
L’article suivant détaille les outils, les services et les formations que nous offrons.

Pour plus de détails, veuillez nous contacter : devsecops@almtoolbox.com ou par téléphone :
+33 01 84 17 53 28 /  ou 866-503-1471 (Canada)

Table des matières :

  • Qu’est-ce que le Code Sécurisé ?
  • Liste des outils de développement de code sécurisé que nous distribuons et supportons
  • Liste des services et solutions que nous proposons autour du développement de code sécurisé
  • Formation au développement de code sécurisé

Qu’est-ce que le Code Sécurisé ?

Le code sécurisé est un ensemble de pratiques visant à développer des logiciels de manière sûre et sécurisée, en tant que partie intégrante du processus de développement lui-même (plutôt que séparément),
garantissant que la sécurité de l’information est intégrée tout au long du cycle de vie du développement (plutôt qu’à la fin uniquement).

Le développement de code sécurisé a plusieurs objectifs, notamment :

  • Détection rapide des bugs (« Shift Left »)
  • Protéger les utilisateurs de l’application que nous développons
  • Code sécurisé pour la défense contre les utilisateurs non autorisés
  • Protéger les processus de développement, de construction (build) et d’intégration du produit

Liste des outils de développement de code sécurisé que nous distribuons et supportons :

Nous pouvons vous aider à choisir les outils les mieux adaptés à vos besoins, en fonction de vos exigences, de votre environnement et de votre budget.

  1. SonarQube (Analyse statique de code, SAST, assistance à l’écriture de code propre et sécurisé en 29 langages).
    Nous proposons également du support et des services gérés. Plus d’infos ici.
  2. GitLab + GitLab CI (Une suite d’outils de code sécurisé intégrée au processus de développement :
    SAST, DAST, API, SCA, Détection de secrets, Analyse de conteneurs, Fuzzing)
    Nous proposons également du support et des services gérés. Plus d’infos ici.
  3. HashiCorp Vault (Gestion des secrets)
  4. AppScan (Solution DAST pour la sécurité des applications, incluant la sécurité des API)
  5. HashiCorp Consul (Solution de Service Discovery et Service Mesh)
  6. Vault Plus (Solution de gestion des secrets basée sur l’open source Vault)
  7. Sysdig (Surveillance et sécurité pour conteneurs et Kubernetes ; option Prometheus géré)
  8. Fossa (Solution SCA pour la gestion des vulnérabilités et la conformité des licences pour les bibliothèques open source)
  9. Socket Dev (Solution SCA pour la gestion des vulnérabilités, la détection de malwares et la création de SBOM)
  10. Docker – Permet la conteneurisation de vos applications (avec Docker Desktop) ;
    Recherche et partage d’images prêtes à l’emploi (via Docker Hub) ; Détection de vulnérabilités dans les images (via Docker Scout) et plus encore
  11. SourceGraph (Solution qui fournit des alertes sur les vulnérabilités du code et permet une correction automatique sur l’ensemble de la base de code)
  12. SonarCloud (Solution SaaS/Cloud pour l’analyse statique du code)
  13. SonarLint (Plugin gratuit pour IDE)
  14. Solutions de Gestion des Secrets (Sur site / SaaS / Hybride)
  15. HashiCorp Boundary – Accès distant sécurisé – (Remplacement moderne du VPN)
  16. LastPass – Gestion de mots de passe
  17. Mattermost (Chat sécurisé pour les environnements de développement / alternative à Slack et WhatsApp)
  18. GitHub Advanced Security (Suite d’outils de développement sécurisé au-dessus de GitHub)
  19. Atlassian Guard (anciennement Access) – Solution d’accès sécurisé et SSO pour Jira, Confluence, Bitbucket et les modules complémentaires Atlassian
  20. Azul (Mises à jour de sécurité Java et support Java)
  21. Terraform (Inclut la détection de dérive / Drift Detection)
  22. Spacelift – Un produit pour les développeurs et les équipes de sécurité qui identifie la dérive (Drift) dans Terraform, AWS CloudFormation et Pulumi, et propose des parcours de remédiation

Pour plus de détails, veuillez nous contacter : devsecops@almtoolbox.com ou par téléphone :
+33 01 84 17 53 28 /  ou 866-503-1471 (Canada)

Liste des services et solutions que nous proposons autour du développement de code sécurisé :

  1. Planification et construction de processus de développement, processus DevOps et processus CI/CD incluant le développement sécurisé
  2. Assistance au développement de code sécurisé autour de GitLab (y compris la version gratuite) – Incluant les processus CI et Secure CI
  3. Assistance au développement de code sécurisé autour de GitHub – Incluant les processus CI et Secure CI
  4. Développement de processus sécurisés autour de git (tels que la protection des dépôts contre les utilisateurs non autorisés)
  5. Implémentation via des outils SCM tels que GitHub, GitLab, Bitbucket, SonarQube
  6. Implémentation via des outils d’analyse de code/app tels que SonarQube, SonarCloud, GitLab, Fossa, Vault
  7. Implémentation via des outils CI tels que GitHub Actions, GitLab CI/CD, Azure DevOps, Jenkins
  8. Variété de solutions pour la gestion des secrets
  9. Solution gérée pour la gestion des secrets utilisant HashiCorp Vault
  10. Solution pour la gestion des mots de passe organisationnels telle que LastPass, 1Password
  11. Solutions d’accès distant sécurisé basées sur VPN ou nouvelle génération (telle que Boundary)
  12. Service géré pour votre environnement SonarQube (auto-hébergé / Self-hosted) ou dans le cloud
  13. Service géré pour votre environnement GitLab (auto-hébergé / Self-hosted) ou dans le cloud
  14. Service géré pour votre environnement GitHub (auto-hébergé / Self-hosted) ou dans le cloud
  15. Services de détection de dérive (Drift Detection)

Pour plus de détails, veuillez nous contacter : devsecops@almtoolbox.com ou par téléphone :
+33 01 84 17 53 28 /  ou 866-503-1471 (Canada)

Formation au développement de code sécurisé :

Nous proposons une variété de formations sur ce sujet – contactez-nous : devsecops@almtoolbox.com ou par téléphone : +33 01 84 17 53 28 /  ou 866-503-1471 (Canada)

Dernière mise à jour : décembre 2025. Cet article a été publié pour la première fois en mai 2021.

Vue d’ensemble actualisée sur Socket – Une solution moderne pour prévenir les attaques sur la chaîne d’approvisionnement logicielle

Logo de la plateforme Socket Security
Logo Socket

Voici une revue actualisée que j’ai préparée sur la solution de la société Socket Security pour prévenir les attaques sur la chaîne d’approvisionnement logicielle et les applications.

Socket Security : Vue d’ensemble

La société Socket Security se positionne comme une plateforme de sécurité de la chaîne d’approvisionnement (Supply Chain Security) avec une approche “Developer-first” (orientée développeur), s’attaquant directement au problème des dépendances Open Source malveillantes et dangereuses.

Alors que le code moderne repose souvent à plus de 90 % sur du code Open Source, la proposition de valeur centrale de Socket est la suivante : protéger les applications non seulement contre les CVE connues, mais aussi contre les paquets (Packages) qui se comportent comme des malwares (logiciels malveillants, c’est-à-dire du code dont le but est de nuire), avant même qu’une vulnérabilité ne soit publiée.

Que propose Socket et comment protège-t-il les applications ?

La plateforme est construite autour de plusieurs composants clés :

  • Une GitHub App qui analyse les Pull Requests.
  • Un outil CLI puissant qui enveloppe les gestionnaires de paquets (Package Managers) tels que npm, yarn, pnpm et pip.
  • Socket Firewall” – Un proxy qui se place avant les gestionnaires de paquets pour bloquer les dépendances malveillantes au moment de l’installation (Install time).

Ensemble, ces outils offrent aux équipes AppSec et Platform une couverture tout au long du SDLC : dans les PRs, lors du développement local et dans le CI/CD.

Comment fonctionne la solution Socket ?

“Sous le capot”, Socket ne se contente pas de vérifier les CVE ; elle analyse le contenu et le comportement des dépendances. Leur moteur d’analyse statique interne examine le code tiers à la recherche de capacités dangereuses
(accès au réseau, au système de fichiers, au Shell, accès aux variables d’environnement), d’obfuscation de code, de scripts d’installation et de télémétrie.
Cette analyse est combinée aux métadonnées du paquet et aux signaux comportementaux des mainteneurs, tels que les changements de propriétaire ou les modèles de publication suspects.

L’entreprise indique qu’elle suit actuellement plus de 70 signaux d’alerte (“red flags”) dans divers écosystèmes,
et avertit des problèmes tels que les malwares, le typosquatting, le code caché et l’extension abusive des permissions (Permission Creep) avant qu’une PR ne soit fusionnée ou qu’un paquet ne soit installé.

Capacités SCA traditionnelles et intégrations

De plus, Socket fournit une couche de capacités SCA traditionnelles :

  • Analyse des CVE.
  • Génération de SBOM (via cdxgen en CLI).
  • Détection de licences (License detection) pour plus de 2 000 licences.
  • Application de la conformité des licences (License Compliance) basée sur des Policies intégrées aux workflows GitHub.

Les intégrations incluent les IDE (comme JetBrains, VS Code),
les systèmes CI/CD (comme Jenkins, CircleCI, Azure DevOps),
les outils SCM (comme GitHub, GitLab, Bitbucket) et les SIEM comme Splunk et Datadog,
ce qui facilite relativement l’ajout de Socket à une chaîne d’outils DevSecOps existante.

Différenciation par rapport aux outils SCA et AppSec traditionnels

Socket adopte une position claire vis-à-vis de l’ancien paysage (Legacy) : les scanners de vulnérabilités traditionnels (comme Snyk ou Dependabot) sont définis comme des outils de recherche de CVE réactifs, tandis que les outils d’analyse statique sont perçus comme trop “bruyants” (générant trop de faux positifs) pour être appliqués de manière réaliste sur des milliers de lignes de code tiers.

La différenciation de Socket repose sur plusieurs points :

  1. Priorité au comportement (Behavior-first) et non aux CVE : Au lieu d’attendre une CVE, le système vérifie le comportement du paquet à la recherche d’indicateurs de compromission (Indicators of Compromise), y compris un comportement suspect lors de l’installation et l’accès à des API sensibles dans les dépendances terminales (Leaf dependencies) qu’un développeur pourrait ne jamais appeler directement.
  2. Analyse des canaux auxiliaires (Side-channel) et des mainteneurs : Des signaux tels qu’une propriété instable, de nouveaux mainteneurs soudains, ou des modèles de publication de nouvelles versions sur d’anciennes versions majeures sont des entrées de premier ordre, souvent ignorées par les outils SCA génériques ou traitées uniquement comme des métadonnées.
  3. Blocage en ligne (Inline) via Socket Firewall : L’entreprise commercialise le pare-feu comme une approche unique : au lieu de faire du “scraping” de la sortie du gestionnaire de paquets, il intercepte le trafic réseau en tant que proxy HTTP/HTTPS et applique les Policies à cet endroit, bloquant les dépendances malveillantes avant qu’elles n’atteignent les machines des développeurs ou les systèmes de Build.
  4. Analyse d’atteignabilité (Reachability) via Coana : L’acquisition de Coana en 2025 apporte des capacités de pointe en Reachability Analysis à la plateforme pour filtrer les vulnérabilités qui ne sont pas réellement “atteignables” par le code de l’application, avec une réduction revendiquée allant jusqu’à 80 % des faux positifs et une correction beaucoup plus rapide.

En outre, Socket propose des résumés de vulnérabilités basés sur l’IA (via des intégrations avec Anthropic/OpenAI), offrant ainsi une solution “Next-gen SCA” qui aspire à remplacer totalement le SCA traditionnel plutôt que de simplement le compléter.

À propos de l’entreprise :

L’entreprise a été fondée en 2021 par Feross Aboukhadijeh, un mainteneur Open Source reconnu et ancien conférencier en sécurité Web à l’Université de Stanford. Elle a rapidement gagné la confiance des développeurs et des leaders en sécurité.
Socket a levé 65 millions de dollars à ce jour, incluant un tour de table de série B de 40 millions de dollars en octobre 2024 mené par Abstract Ventures.

Données d’adoption et d’utilisation de Socket :

  • Fin 2024 : Prise en charge de 6 langages de programmation, protection de plus de 7 500 organisations et 300 000 dépôts GitHub, détection/blocage de plus de 100 attaques sur la Supply Chain chaque semaine.
  • Décembre 2025 : Croissance prévue à plus de 10 000 organisations, et un effectif approchant les 100 personnes.

L’équipe de recherche de l’entreprise expose régulièrement des campagnes malveillantes actives sur npm, PyPI, Go et Rust, et leurs découvertes sont couvertes par les médias technologiques.

De plus, Socket a été reconnue dans la liste Cyber 60 de Fortune et a rejoint le TC54 pour aider à façonner les normes SBOM, CycloneDX et PURL, ce qui la positionne comme un acteur clé dans l’écosystème de la gouvernance de la chaîne d’approvisionnement.

Objectifs et plans de Socket pour les années à venir

La mission déclarée de Socket est de “sécuriser les chaînes d’approvisionnement logicielles mondiales” et d'”innover dans la sécurité de l’Open Source”.
Sur la base des déclarations publiques et de la direction du produit, on peut s’attendre à :

  1. Extension de la couverture de l’écosystème : Prise en charge de plus de langages et de gestionnaires de paquets.
  2. Précision accrue et moins de “bruit” : Intégration complète de la Reachability de Coana, de sorte que chaque découverte de vulnérabilité inclura le contexte d’atteignabilité par défaut.
  3. Blocage plus proactif : Alors que les contrôles de type pare-feu et les expériences “Safe Package Manager” deviennent la norme pour l’installation des dépendances, et non plus seulement un module complémentaire.
  4. Leadership dans les standards et le SBOM : Activité au sein du TC54 et travail autour de CycloneDX et PURL, qui devraient devenir des fonctionnalités centrales du SBOM et des politiques dans le produit.
  5. Poursuite de la recherche et outils communautaires : Maintien d’une stratégie de publication de recherches sur les menaces et d’offre d’outils gratuits (comme la GitHub App pour l’Open Source) pour gagner le partage et la sympathie de la communauté des développeurs.

En résumé :

Socket sert de plateforme de Next-gen SCA et de Supply Chain Security,
comblant l’écart du “Paquet Malveillant” laissé par les outils focalisés uniquement sur les CVE plus anciens,
tout en unifiant les capacités de gestion des vulnérabilités, des licences, du SBOM et de la Reachability en une seule plateforme axée sur les développeurs de logiciels.

Nous sommes les représentants officiels des solutions Socket (ALMToolbox), et nous fournissons de l’aide pour le choix des licences adaptées, l’implémentation et plus encore. Pour plus de détails, pour essayer le produit et obtenir des tarifs – contactez-nous :
socket@almtoolbox.com ou par téléphone : +972-72-240-5222

Liens pertinents :

Nous célébrons 10 ans de support GitLab

Ce mois-ci marque une étape importante pour nous : dix ans d’accompagnement de GitLab à travers des services professionnels et gérés pour des équipes du monde entier.

Au fil des ans, nous avons acquis une expertise approfondie et pratique du produit GitLab (notamment le contrôle de version, l’intégration continue et le déploiement continu, ainsi que la sécurité), du code (fonctionnement interne) et de l’architecture. Cette expertise repose sur une équipe dédiée de cinq experts GitLab, chacun cumulant en moyenne neuf ans d’expérience. (Cela représente-t-il 45 ans d’expérience cumulée ?)

Voici un bref retour sur notre parcours avec GitLab :

  • 2015 : Nous avons commencé à prendre en charge GitLab pour toutes ses éditions et tous ses types de déploiement, en complément des services Git et GitHub, dans le cadre de notre engagement envers l’écosystème Git au sens large.
  • Fin 2016 : Nous sommes devenus partenaire mondial officiel de GitLab.
  • 2017-2019 : Nous avons été nommés partenaire GitLab n° 1 en Europe pendant trois années consécutives.
  • 2017 – aujourd’hui : Reconnu comme expert GitLab, puis comme partenaire GitLab Select.
  • 2020 : Honoré comme Héros GitLab et lancement de notre plateforme complémentaire, Git Marketplace.
  • 2021 – aujourd’hui : Reconnu comme Champion GitLab.
  • 2024 – aujourd’hui : Nommé seul « Partenaire GitLab Select » par STKI, cabinet de conseil indépendant qui évalue et classe les partenaires sur le marché local.

Dix ans plus tard, notre passion pour GitLab et l’écosystème DevOps/DevSecOps est plus forte que jamais. Nous sommes fiers d’accompagner des centaines d’organisations en tant que conseillers de confiance, les aidant à développer des logiciels plus rapides, plus sûrs et plus intelligents.

Vivement les dix prochaines années d’innovation et de collaboration avec GitLab !

Besoin d’une assistance GitLab de qualité ? Contactez-nous: gitlab.fr@almtoolbox.com

Liens utiles:

Qu’est-ce que Docker Business ?

Docker Business

Docker Business est l’un des principaux niveaux d’abonnement de la solution Docker, il ajoute des couches de sécurité supplémentaires à l’offre de base de Docker.
Une question fréquente que nous recevons est : « Quelles sont les fonctionnalités spéciales disponibles uniquement dans Docker Business ? »

Nous avons donc préparé un résumé rapide pour vous.

Remarque : Vous souhaitez une liste entièrement détaillée de toutes les fonctionnalités et capacités de nos différents plans ? Envoyez-nous simplement un e-mail – nous sommes heureux de vous aider ! (Voir les coordonnées ci-dessous).

Voici les principales fonctionnalités de Docker Business :

1. Hardened Docker Desktop:

Applique de manière centralisée les politiques de sécurité et les garde-fous (guardrails), tels que les paramètres et les restrictions sur les registries et les images, sur Docker Desktop et renforce l’isolement – sans interrompre les workflows des développeurs.

2. Single Sign-On (SSO):

Permet aux utilisateurs de s’authentifier sur Docker Desktop et Hub en utilisant l’IdP de votre entreprise ; prend en charge SAML et Microsoft Entra (OIDC), avec la vérification de domaine et une application à l’échelle de l’organisation.

3. SCIM user provisioning:

Automatise la gestion du cycle de vie depuis votre IdP vers Docker – provisionnement, mises à jour, dé-provisionnement et mappages d’équipes – afin que l’appartenance à l’organisation reste synchronisée sans administration manuelle.

Image and Registry Access Management :
Restreint les registries auxquels les développeurs peuvent accéder et les classes d’images qu’ils peuvent extraire (pull), par exemple, les Official Images ou les Verified Publisher, réduisant ainsi l’exposition à des sources non fiables.

4. Provisionnement d’utilisateurs SCIM:

Restricts which registries developers can access and which image classes they may pull (e.g., Official Images, Verified Publisher), reducing exposure to untrusted sources.

5. Desktop Insights Dashboard:

Fournit une visibilité au niveau de l’organisation sur l’adoption et l’utilisation de Docker Desktop, avec des filtres par plage de dates et une exportation CSV pour soutenir la conformité (compliance), la planification de la capacité et l’optimisation des licences.

6. Enhanced Container Isolation (ECI):

Ajoute des défenses plus robustes – user-namespace remapping, protected mounts, contrôles syscall plus stricts – de sorte que même les containers avec des privilèges ne peuvent pas compromettre la VM de Docker Desktop ou l’hôte, avec un changement minimal de workflow.

De plus, Docker a récemment commencé à proposer les Docker Hardened Images (DHI) : ce sont des images de containers qui sont sécurisées (et allégées) par défaut, conçues spécifiquement pour les environnements de production modernes. Pour en savoir plus, lisez ici ou contactez-nous.

Notre société (ALM Toolbox) représente officiellement Docker en tant que « Preferred Partner ».
Nous aidons nos clients à résoudre des problèmes DevOps complexes liés au DevOps et à l’infrastructure sur laquelle il s’exécute, y compris git, les containers, Postgres, Redis, NginX, Prometheus, Grafana, Kubernetes, Terraform, Elastic et plus encore.
Pour plus de détails, contactez-nous : docker@almtoolbox.com ou appelez-nous :
866-503-1471 (États-Unis / Canada) ou +31 85 064 4633 (International) + 33 1 84 17 53 28 (Europe)

Liens utiles:

Nous représentons Fossa en France

Fossa logo

Nous sommes heureux d’annoncer que nous avons été choisis pour représenter officiellement les solutions de la société Fossa en France. Nous proposons désormais le support, l’intégration aux processus de développement et CI/CD, une aide au choix de la licence adaptée aux besoins de votre organisation, la vente de licences, l’intégration avec des outils complémentaires (tels que GitHub / GitLab, Bitbucket, SonarQube, Jira, Azure DevOps Jenkins et plus encore), des services managés (Managed Services) et bien plus encore.

Les solutions de Fossa offrent des fonctionnalités d’Analyse de la Composition Logicielle (SCA) et de protection pour votre code (code sécurisé) et vos applications, en réduisant les risques liés à l’utilisation de l’open source. Cela concerne aussi bien les risques de sécurité de l’information et la détection de vulnérabilités dans le code tiers que vous utilisez, que les risques liés à une utilisation incorrecte et illégale du code open source d’autrui (Conformité des Licences) qui ne respecte pas les règles de licence du code.

Le produit prend actuellement en charge 35 langages de programmation et frameworks, parmi lesquels : Java, C, C++, C#, GoLang, Python, JS et plus encore.

Fossa propose une « Analyse d’Atteignabilité » (Reachability Analysis) – un rapport qui sait se concentrer sur les zones de code les plus vulnérables et où le risque de pénétration est le plus grand.

Le produit prend en charge plusieurs cas d’usage, notamment :

  1. Gestion des Vulnérabilités
  2. Conformité des Licences
  3. Gestion des SBOM (Nomenclature Logicielle)
  4. Solution SCA Complète
  5. Atténuation des Risques en Amont (« Shift-Left »)
  6. Due Diligence
  7. Conformité Continue et Automatisée

La solution peut être installée en auto-hébergement (self-managed / self-hosted / on-premises), que ce soit sur un réseau fermé ou dans le cloud. Le produit de base inclut plusieurs fonctionnalités disponibles dans l’édition gratuite (Free Edition). Au-delà de l’édition gratuite, des éditions commerciales (Business / Enterprise Editions) sont disponibles moyennant des frais.

Il est également possible de connecter Fossa à des outils d’Intégration Continue (CI) afin de contrôler les processus de développement et de CI/CD, comme le blocage des fusions de code (merges) qui ne répondent pas à un certain seuil de qualité. Il est aussi possible de connecter Fossa à Jira pour l’ouverture automatique de tickets de bugs.

Vous souhaitez plus d’informations ?

Pour une démonstration, vous pouvez nous contacter par e-mail ou par téléphone : devops.fr@almtoolbox.com ou au 33(0)1 84 17 53 28 ,vous pouvez également nous contacter pour recevoir les instructions d’installation.

Un bref aperçu de Fossa (3 minutes):

Sécurité et conformité du code avec GitLab

 

gitlab logo security devsecops

Outre le contrôle de version et le CI/CD, GitLab propose également une variété de tests de sécurité sur votre code propriétaire (code que vous développez) ou sur le code externe que vous utilisez (c’est-à-dire open source), ainsi que des capacités de conformité du code – pour vous aider à vous assurer que vous faites l’utilisation appropriée et légale de toutes les bibliothèques open source et des extraits de code.

En fait, dans GitLab, vous pouvez également exécuter les tests sur le code lui-même, puis tout voir à l’aide d’un tableau de bord central qui montre tout organisé.
Le tableau de bord de GitLab vous permet également d’exécuter certaines actions sur les résultats et les découvertes, et de partager les informations entre toutes les parties prenantes (ou quiconque est autorisé à les regarder en fonction des autorisations).

gitlab security dashboard
Tableau de bord de sécurité de GitLab (vue au niveau du groupe). Cliquez pour agrandir.

Les tests peuvent être exécutés à partir de GitLab CI (l’outil CI/CD intégré fourni avec GitLab) et peuvent également être connectés à d’autres outils CI tels que Jenkins.

Les tests peuvent être exécutés même si le code se trouve dans un autre outil SCM (tel que git, GitHub, Bitbucket, etc.).

Certains des tests sont dynamiques, ce qui signifie qu’ils ne s’exécutent pas sur le code lui-même, mais sur l’application ou le site Web qui exécute le code.

Les tests peuvent être exécutés à la fois depuis un serveur GitLab privé (auto-hébergé) ou depuis le cloud / SaaS (par exemple, gitlab dot com).

Vous pouvez voir ici un aperçu des fonctionnalités d’analyse de sécurité pertinentes :

Remarque : la plupart des fonctionnalités ici nécessitent une licence GitLab Ultimate. Si vous avez besoin d’un devis, contactez-nous (nos coordonnées sont ci-dessous).

Feature

Description

Container Scanning Exécutez une analyse de sécurité pour vous assurer que les images Docker de votre application ne présentent aucune vulnérabilité connue dans l’environnement où votre code est livré.
Dependency List Identifiez les composants inclus dans votre projet en accédant à la liste des dépendances (également appeléeBill of Material ou BOM), qui est souvent demandée par les équipes de sécurité et de conformité.
Dependency Scanning Protégez votre application des vulnérabilités qui affectent les dépendances dynamiques en détectant automatiquement les bogues de sécurité bien connus dans vos bibliothèques incluses.
Static Application Security Testing (SAST) Recherche de code source vulnérable ou de bogues de sécurité bien connus dans les bibliothèques incluses dans l’application. Les résultats sont ensuite affichés dans la demande de fusion et dans la vue Pipeline.
Ce test prend en charge les langages de code suivants:  C/C++, Apex, .NET, Java, Go, JS, Python, PHP, Swift, TypeScript, NodeJS et plus.
Dynamic Application Security Testing (DAST) Assurez-vous que vous n’êtes pas exposé aux vulnérabilités des applications Web telles que l’authentification cassée, les scripts intersites ou l’injection SQL.
Secret Detection Vérification des secrets et des informations d’identification involontairement commis dans le code git et l’historique.
API Fuzzing Testez les API dans vos applications pour trouver les vulnérabilités et les bogues qui manquent aux processus d’assurance qualité traditionnels.
Coverage Fuzzing Trouvez des vulnérabilités de sécurité et des bogues dans votre application que les processus d’assurance qualité traditionnels manquent, prenant en charge
C/C++, Go, Java, JS, Python et autres langages de code.
Security Dashboard Gagnez en visibilité sur les correctifs prioritaires en identifiant et en suivant les tendances des risques de sécurité dans l’ensemble de votre organisation.
License Compliance Vérifiez que les licences de vos dépendances sont compatibles avec votre application(e.g. GPL, BSD, Apache, MIT licenses etc.), et les approuver ou les refuser.

 

ALMtoolbox est le  représentant officiel de GitLab, Hashicorp  en France et dans d’autres pays.

Contactez pour toute question, un devis ou même une license d’évaluation:
par email  devops.fr@almtoolbox.com ou +33 1 84 17 53 28
 Nous fournissons des conseils GitLab, la migration, aidons les clients à choisir les licences les mieux adaptées, un hébergement privé, un support de qualité et rapide, le développement de modules complémentaires GitLab et nous soutenons et vendons une variété d’outils DevSecOps et ALM.

 

First release: December 2021
 

 

Nouveau : Bibliothèque VOD des webinaires DevOps

devops webinars video on demand

Nous avons récemment organisé les vidéos que nous avons enregistrées au fil des ans dans une “bibliothèque” centralisée de VOD (Video On-Demand).
Nous l’avons classé par produits, tags, langue et date d’enregistrement (à votre convenance).

N’hésitez pas à trouver ce qui vous intéresse le plus et regardez !

>>>>La bibliothèque DevOps VOD est disponible ici

 

ALM-Toolbox est un distributeur officiel de SonarQube,GitLab et autres, offre du conseils, des licences SonarQube et SonarCloud, la mise en œuvre, la formation et aide les clients à intégrer SonarQube aux flux commerciaux et aux pipelines CI/CD.
Contactez-nous pour toute question, y compris les prix et les devis : sonarqube@almtoolbox.com ou appelez-nous : 866-503-1471 (USA/Canada) ou +33 (0)1 84 17 53 28

Quelles sont les différences entre les éditions SonarQube ?

Last update: April 2023 (published first at June 2021)

On nous demande souvent quelles sont les différences entre les versions de SonarQube.
D’après les questions, il est clair que les options de licence ne sont pas si claires et assez déroutantes, j’ai donc décidé d’écrire les points essentiels et de mettre un peu d’ordre.

Legende

Dans l’article suivant, j’explique les différences, et d’ailleurs nous avons récemment créé un fichier automatique qui vous permet de voir facilement toutes les fonctionnalités du produit, en détail et par éditions (vous pouvez donc utiliser des filtres et voir par exemple quelles fonctionnalités sont uniquement dans les éditions Developer / Enterprise ; quelles fonctionnalités ne sont pas dans une certaine édition, etc.) . Vous pouvez nous envoyer un e-mail (sonarqube@almtoolbox.com) et obtenir cette fichier automatique.

sonarqube-excel
Cliquez pour agrandir. Envoyez-nous un e-mail pour obtenir la feuille de calcul complète.

Principales différences dans les éditions SonarQube

SonarQube Editions

Dans cet article, j’explique les principales différences entre les éditions SonarQube.

SonarQube a été construit dans un modèle “Open Core”, ce qui signifie qu’il s’agit d’une source ouverte construite par couches : chaque couche contient l’ancienne couche plus des fonctionnalités supplémentaires :

  • L’édition communautaire (gratuite) est la base
  • Ensuite, vous avez Developer Edition en couche additionnelle
  • Puis l’Enterprise Edition en plus
  • Et enfin l’édition Data Center en plus

Voire l’illustration sur le côté droit.

Voyons les principales fonctionnalités qui sont ajoutées dans chaque édition (couche).

Qu’y a-t-il dans l’édition communautaire ?

Cette édition est open source gratuite et offre les éléments suivants :

1. Noyau de SonarQube et plus de 60 plugins.
Vous avez une variété de plugins conçus pour SonarQube (certains sont gratuits tandis que vous devez payer pour d’autres). Vous pouvez également créer vos propres plugins (et nous pouvons le créer pour vous).

2. Numérisation des langages de code (analyse de code statique)

L’édition communautaire prend en charge une analyse de base de 16 langues :
Java, Javascript, C#, Terraform, Kubernetes, TypeScript, Kotlin, Ruby, Go, Scala, Flex, Python, PHP, HTML, CSS, XML, VB.NET

3. Analyse de la branche master (principale)

Scannez la branche git master (principale).

Notez que vous ne pouvez pas analyser d’autres branches (par exemple, les branches de fonctionnalités) à l’aide de l’édition de la communauté, vous ne pouvez donc pas appliquer la méthodologie “Shift Left” à l’aide de cette édition.

4. SonarLint

SonarLint vous aide à recevoir des notifications sur les problèmes de code et les bogues, en temps réel, dans l’IDE des développeurs (par exemple IntelliJ / VS Code) – ce qui les aide à développer plus de “code propre”.
Remarque : SonarLint ne peut pas être configuré dans cette version (vous pouvez le faire dans l’édition Developer comme expliqué ci-dessous)

Édition développeur vs édition communautaire

L’édition développeur offre tout dans l’édition communautaire PLUS :

  1. Branch Analysis

Vous pouvez analyser toutes les branches de votre choix (plutôt que la branche principale uniquement), ce qui vous permet de détecter les problèmes beaucoup plus tôt, avant même que le code ne soit fusionné en amont avec les branches principales.

  1. Demande d’extraction Décoration  & Analyse

Cela vous permet d’intégrer SonarQube à vos outils de contrôle de version et d’ajouter l’analyse SonarQube et une porte de qualité à vos demandes d’extraction (ou demandes de fusion) dans l’interface de votre fournisseur ALM / DevOps, y compris GitLab, GitHub, Bitbucket et Azure DevOps.
Il vous aide à obtenir un retour rapide (des résultats de l’analyse) dans le tableau de bord.

Illustration: Pull (Merge) request decoration with SonarQube and GitLab
Illustration : Pull (Merge) décoration de requête avec SonarQube et GitLab. Cliquez pour agrandir

3. Analyse de la sécurité du code /Fonctionnalités

Analyse de sécurité avec une variété de règles pour chaque langue de code (notre feuille de calcul spécifie le nombre de règles dont vous disposez pour chaque langue)

Remarque : l’édition communautaire (gratuite) ne recherche pas les failles de sécurité

4. Fonctionnalités  SonarLint supplémentaires

Dans cette version, il est possible de configurer et de recevoir des notifications intelligentes (non disponible dans l’édition gratuite de la communauté),
donc si vous (en tant que développeur) utilisez SonarLint via votre IDE, vous pouvez configurer et recevoir des notifications.
Par exemple : Vous pouvez recevoir un message si vous n’avez pas passé les Quality Gates.

Remarque : SonarLint dans l’édition communautaire (gratuite) n’analyse pas les langues qui ne sont pas prises en charge dans la version gratuite (par exemple, C, C++ et autres, comme indiqué ci-dessous)

5. Prise en charge de plus de Languages:

L’Edition  Enterprise analyse également les langages de code suivants :

  1. Apex (of Salesforce)
  2. Cobol
  3. PL/1
  4. RPG
  5. VB 6 (Visual Basic)


L’Edition   Enterprise prend en charge 29 languages de code au total.

L’Edition  Enterprise  vs Edition  Developer

  1. Prise en charge de plus de langages

L’ Edition Enterprise  analyse également les langages de code suivants :

  1. Apex (of Salesforce)
  2. Cobol
  3. PL/1
  4. RPG
  5. VB 6 (Visual Basic)

L’ Edition Enterprise prend en charge 29 langages de code au total.

2. Portefeuille et reporting

Cette fonctionnalité est utile lorsque vous avez de nombreux projets. Il vous montre l’état des projets de haut niveau (ce qui est souvent nécessaire aux responsables du développement, aux chefs d’équipe, aux CTO, etc.).

Cela vous permet également d’agréger les projets par groupes afin de visualiser les informations et de les rendre beaucoup plus claires et lisibles.

Fonctionnalités pertinentes ici :

  • Agrégation de projets. Par exemple, vous pouvez décider quoi regrouper selon des critères que vous décidez, par ex. langage codé commun ; projets hérités; groupes ; équipes etc…
  • Vous pouvez automatiser le rapport et l’envoyer par e-mail (sous forme de rapport PDF)
Regarder une démo (2 min) :

3. Rapports de sécurité

Les rapports de sécurité sont disponibles uniquement dans l’édition Enterprise.
Ces rapports vous aident à obtenir des commentaires plus rapidement et à corriger les vulnérabilités de sécurité beaucoup plus rapidement.
SonarQube vous aide à voir votre posture de sécurité selon les normes OWASP Top 10 et CWE Top 25.

Par exemple:

Security Reports
Rapports de sécurité

4. Point d’accès de sécurité + vulnérabilités de sécurité

Les hotspots de sécurité sont des zones de code où SonarQube met en évidence les extraits de code suspects que les développeurs doivent vérifier (car il peut y avoir des vulnérabilités).

Voir un exemple (cliquez pour agrandir):

Security Hotspot
Security Hotspot

Cette fonctionnalité permet également d’améliorer les compétences de développement des développeurs et de les responsabiliser : au fur et à mesure qu’ils écrivent du code et découvrent les points chauds, ils découvrent les risques de sécurité et les meilleures pratiques pour les prévenir.

Les vulnérabilités de sécurité nécessitent une attention immédiate. SonarQube fournit une description détaillée et met en évidence le code pertinent, ce qui aide à comprendre quel est le risque dans le code donné.
Par exemple (cliquez pour agrandir):

Identify the problematic code
Identifiez le code problématique et fournissez une solution sur la façon de le résoudre (dans ce cas : utilisez une longueur de clé qui fournit suffisamment d’entropie contre les attaques par force brute. Pour l’algorithme RSA, elle doit être d’au moins 2 048 bits)

5. Traitement parallèle des rapports d’analyse

Vous permet de gérer les analyses et les rapports en parallèle. Ceci est utile si vous devez exécuter de nombreuses analyses et rapports.
Vous pouvez exécuter jusqu’à 10 nœuds de calcul en parallèle.

6.Licence  Staging

À l’aide de l’édition Enterprise, vous pouvez obtenir une licence supplémentaire pour configurer un environnement de test/de test.

Ceci est utile lorsque SonarQube fait partie d’un système critique et/ou utilise des plugins, et que vous souhaitez le tester (en tant qu’exécution “à sec”) avant de mettre à niveau le serveur réel (afin d’atténuer les risques et d’assurer un temps d’arrêt minimal et une mise à niveau réussie) .

Edition Data Center   vs Enterprise

L’Edition Data Center Edition vous offre une haute disponibilité pour les déploiements massifs (mondiaux).
La haute disponibilité est obtenue en ajoutant de la redondance à chaque nœud du système.

  1. Redondance des composants

  2. Résilience des données


  3. Évolutivité horizontale

FAQ:

  • Q : Quel est le prix de SonarQube ?
    R : La tarification de SonarQube dépend de plusieurs paramètres :
    Type d’édition (comme expliqué ci-dessus dans l’article);
    Le nombre de lignes de code dont vous disposez
    Que vous preniez le support client
    Contactez-nous pour obtenir les prix et les devis exacts : sonarqube@almtoolbox.com ou appelez nous.
  • Q : J’utilise un langage de code pris en charge par l’édition communautaire (gratuite) (par exemple, Java ou C#). Cela signifie-t-il que j’obtiens toutes les fonctionnalités de SonarQube ?
    R : Non. Si vous utilisez l’édition gratuite, vous avez accès aux fonctionnalités disponibles uniquement dans l’édition communautaire gratuite.
    Par exemple : si vous utilisez Java (qui est disponible dans l’édition gratuite), vous n’obtiendrez pas d’analyse des règles de sécurité ; Aucune analyse de branche ; Aucun rapport, etc.

ALM-Toolbox est un distributeur officiel de SonarQube et offre du conseils, des licences SonarQube et SonarCloud, la mise en œuvre, la formation et aide les clients à intégrer SonarQube aux flux commerciaux et aux pipelines CI/CD.
Contactez-nous pour toute question, y compris les prix et les devis : sonarqube@almtoolbox.com ou appelez-nous : 866-503-1471 (USA/Canada) ou +33 (0)1 84 17 53 28

Liens utiles:

GitLab CI et l’integration Akeyless Vault

Vous pouvez utiliser la gestion des secrets Akeyless Vault dans GitLab et GitLab CI.

gitlab akeylesss logosLe code placé dans GitLab ou GitLab CI/CD nécessite des secrets afin d’exécuter correctement l’accès aux diverses ressources.
En intégrant GitLab CI à Akeyless Vault, vous n’auriez pas besoin de garder des secrets codés en dur dans le code GitLab
référentiel tels que les informations d’identification de nom d’utilisateur et de mot de passe, les clés API, les jetons et les certificats.

Vous voulez en savoir plus et comment nous pouvons vous aider:

ALM-Toolbox fournit des solutions ALM et DevSecOps et peut vous aider à protéger vos référentiels et vos environnements logiciels/cloud.

Contactez-nous : devsecops@almtoolbox.com   ou +33(0)1 84 17 53 28    

Utile: