Category: DevSecOps

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

Jean-Michel BonnetLeave a comment
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

Ori HLeave a comment

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.json, environment.json, truffleSecrets.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)

Jean-Michel BonnetLeave a comment

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

Ori HLeave a comment
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

Jean-Michel BonnetLeave a comment

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 ?

Gitlab France AdminLeave a comment
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

Jean-Michel BonnetLeave a comment
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

Jean-Michel BonnetLeave a comment

 

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

Jean-Michel BonnetLeave a comment

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 ?

Jean-Michel BonnetLeave a comment

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

Gitlab France AdminLeave a comment

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:

Des vulnérabilités dans des applications tierces ont causé le vol de code de GitHub

Jean-Michel BonnetLeave a comment

github vulnerabilities

GitHub a signalé qu’un pirate exploitait apparemment une faille de sécurité ou
erreur humaine sur les applications tierces Travis et Heroku.

La faille de sécurité a exposé les jetons, permettant au pirate de voler les jetons et de les utiliser pour entrer dans des référentiels privés sur GitHub (y compris NPM)
il a donc réussi à télécharger ces référentiels – y compris tout le code et les informations qu’ils contiennent.

Cela signifie que : des vulnérabilités dans des applications tierces ont causé le vol de code de GitHub

Comment pouvez-vous empêcher un piratage similaire de votre dépôt git ?

Il existe plusieurs solutions différentes – et vous devez toutes les mettre en œuvre :

1) Réduire les autorisations

Si vous utilisez GitHub dans le cloud public (github.com) et donnez aux fournisseurs tiers un accès Oauth (le type de jetons volés) –
minimiser les autorisations que vous accordez à des tiers pour accéder à vos informations.

Vous devez également passer en revue les autorisations qu’ils demandent et vous assurer qu’elles ne sont pas trop larges et permissives.

Une erreur courante consiste à accorder des autorisations globales.

Il en va de même lors de l’octroi d’autorisations aux applications GitHub (qui génèrent également des jetons).

2) Ajouter des couches de protection

Vous devriez également envisager de passer à GitHub / GitLab Enterprise sur un serveur privé
(sur site / locataire unique / autogéré) derrière des couches de protection supplémentaires telles que pare-feu, SSO ou accès distant sécurisé,

ou utilisez uniquement des adresses IP autorisées (dans les éditions de cloud public), qui offrent des couches de protection supplémentaires contre les utilisateurs non autorisés du monde entier.

3) Protéger les secrets

Au-delà de cela – il est important que le fournisseur tiers stocke les jetons dans un outil de coffre-fort centralisé – ce qui aurait rendu très difficile pour les pirates d’obtenir les jetons (le rendant presque toujours inaccessible).

Si vous utilisez de tels tiers, vérifiez ou assurez-vous (dans le cadre de votre chaîne d’approvisionnement) qu’ils le stockent dans des outils Vault tels que Akeyless Vault (SaaS et une solution hybride) ou HashiCorp pour les réseaux fermés.

Il en va de même pour toute application qui accorde des autorisations d’accès à des tiers à l’aide de jetons.

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    

Témoignage client : pourquoi Stash Company a choisi les solutions Akeyless

Gitlab France AdminLeave a comment

Gavin Grisamore, the CISO of Stash (an American company from New York that deals with finance and investments) explains in the following recording why they chose the
Secrets Management and Secure Remote Access solutions of Akeyless,
and how it also helps them implement remote access for their employees and how it resolves their “Zero Trust” challenges.

Watch here (6 min.):

Gavin Grisamore, le CISO de Stash (une société américaine de New York qui s’occupe de la finance et des investissements) explique dans l’enregistrement suivant pourquoi ils ont choisi le
Les solutions de gestion des secrets et d’accès à distance sécurisé d’Akeyless,
et comment cela les aide également à mettre en œuvre l’accès à distance pour leurs employés et comment cela résout leurs défis « Zero Trust ».

Regardez ici (6 min.):

Nous avons ajouté des sous-titres  pour votre convenance.

Le texte intégral est disponibleici 

 

Nous représentons officiellement Akeyless en France et dans le monde, et nous sommes spécialisés dans les solutions de l’entreprise et DevSecOps.
Nous serons heureux de répondre à vos questions concernant les solutions Akeyless, et de vous aider à évaluer les produits et sa bonne implantation dans l’organisation.
Pour plus de détails contactez-nous : akeyless@almtoolbox.com ou par téléphone : +33 01 84 17 53 28

Lien utiles:

Sécurité et conformité du code à l’aide de GitLab

Gitlab France AdminLeave a comment

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

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é, et vous permet également d’exécuter certaines actions sur les résultats et les conclusions, et de partager les informations entre toutes les parties prenantes. (ou celui qui est autorisé à le regarder dépend 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.

Il peut être exécuté à la fois à partir d’un serveur GitLab privé (auto-hébergé) ou à partir du 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).

Fonction 

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 dans lequel votre code est expédié
Dependency List Identifiez les composants inclus dans votre projet en accédant à la liste des dépendances (également appelée nomenclature ou nomenclature), 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 par l’application. Les résultats sont ensuite affichés dans la demande de fusion et dans la vue Pipeline.
Ce test est compatible avec les langages de code suivants : C/C++, Apex, .NET, Java, Go, JS, Python, PHP, Swift, TypeScript, NodeJS, etc.
Dynamic Application Security Testing (DAST) Assurez-vous de ne pas être exposé aux vulnérabilités des applications Web telles que l’authentification interrompue, les scripts intersites ou l’injection SQL
Secret Detection Vérification des secrets et des informations d’identification commis involontairement 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 failles de sécurité et des bugs dans votre application que les processus d’assurance qualité traditionnels manquent, prenant en charge
C/C++, Go, Java, JS, Python et d’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 (par exemple, licences GPL, BSD, Apache, MIT, etc.), et approuvez-les ou refusez-les

ALM-Toolbox  est le représentant officiel de GitLab  dans de nombreux pays dont la France ,      Pour plus de détails, contactez-nous :+33(0)1 84 17 53 28,           devops.fr@almtoolbox.com

 

Last update: December 2021