L’article analyse les UserNamespaces dans Kubernetes, une fonctionnalité présentée comme révolutionnaire mais souvent mal comprise. L’auteur souligne que ces espaces de noms réduisent l’impact d’une évasion de container en mappant l’UID 0 (root dans le container) vers un utilisateur non privilégié sur l’hôte, limitant ainsi les dégâts en cas de compromission. Cependant, il critique les promesses exagérées des infographies, qui présentent cette fonctionnalité comme une solution miracle contre les risques de sécurité, alors qu’elle ne couvre qu’un scénario spécifique (l’escape de container).

L’auteur détaille les cas d’usage concrets des UserNamespaces, comme l’exécution de builds sans privilèges (Buildah, Podman rootless) ou la gestion de legacy systems (Postfix, Dovecot) nécessitant des UID fixes. Il rappelle aussi que cette fonctionnalité ne remplace pas les bonnes pratiques de sécurité, comme le multi-tenancy ou la gestion des vulnérabilités kernel, et que son efficacité dépend d’une configuration rigoureuse. Les UserNamespaces sont utiles, mais leur adoption doit s’inscrire dans une stratégie globale.

Enfin, l’article met en garde contre une confiance excessive dans cette fonctionnalité, soulignant que les risques de sécurité applicative (mauvaise configuration, secrets exposés) ou opérationnelle (mauvaise gestion des ressources) restent critiques. L’auteur conclut que les UserNamespaces sont une avancée, mais qu’ils ne doivent pas occulter les priorités réelles en matière de sécurité Kubernetes.

L’article met en garde contre la pratique dangereuse curl | bash, souvent présentée comme une méthode d’installation simple, notamment dans des documentations officielles. Cette méthode, qui consiste à télécharger et exécuter directement un script depuis Internet, expose à des risques de sécurité majeurs. En effet, le script exécuté peut différer de celui consulté, car le serveur peut adapter sa réponse en fonction du contexte (navigateur, curl, adresse IP, etc.), exploitant ainsi les particularités du pipeline Unix où bash commence à exécuter le script avant même qu’il ne soit entièrement téléchargé.

L’auteur souligne que même l’utilisation de HTTPS ne protège pas contre cette menace, car il garantit uniquement l’intégrité du transport et l’authenticité du serveur, mais pas l’honnêteté du contenu servi. Un serveur malveillant peut ainsi fournir un script inoffensif lors d’une visualisation directe, tout en injectant un code malicieux lors d’une exécution via curl | bash. Des techniques comme la détection du comportement typique d’un pipeline (par exemple, en insérant une commande lente comme sleep) permettent à un serveur de distinguer une exécution directe d’une exécution via curl | bash, renforçant ainsi le risque d’exécution de code non désiré.

Proxelar est un proxy MITM (Man-in-the-Middle) programmable écrit en Rust, conçu pour intercepter, inspecter et modifier le trafic HTTP/HTTPS. Il permet de transformer les requêtes et réponses en temps réel via des scripts Lua, offrant ainsi un outil puissant pour le débogage d'API, l'analyse de services tiers ou le test d'applications mobiles. Le projet propose plusieurs modes de fonctionnement (proxy avant/arrière) et des interfaces variées (terminal, TUI interactive, interface web).

Parmi ses fonctionnalités clés, Proxelar inclut l'interception automatique des connexions HTTPS grâce à une autorité de certification intégrée, ainsi qu'un système de filtrage avancé pour analyser les requêtes. Il prend en charge l'inspection des flux WebSocket et permet une installation simplifiée du certificat racine via une page dédiée. Le projet est distribué sous licence MIT et peut être installé via Cargo, Homebrew ou Docker.

Le dépôt GitHub du projet met en avant des contributions actives, avec des mises à jour régulières et une documentation en constante amélioration, incluant des exemples de scripts Lua pour personnaliser le comportement du proxy.

Shannon est un pentester IA autonome en white-box conçu par Keygraph pour tester la sécurité des applications web et de leurs APIs. Il analyse le code source pour détecter des vecteurs d’attaque, puis exécute des exploits réels (injections, contournements d’authentification, SSRF, XSS) afin de valider les vulnérabilités avant leur mise en production. Seules les failles avec un proof-of-concept fonctionnel sont rapportées.

L’outil comble un vide en automatisant les tests de pénétration, souvent limités à une fois par an, pour les aligner sur le rythme des déploiements modernes. Disponible via npx @keygraph/shannon, il s’intègre facilement aux pipelines CI/CD et utilise une architecture éphémère pour limiter les risques.

Le projet, sous licence AGPL-3.0, est open source et propose des fonctionnalités avancées comme un CLI via monorepo, une intégration Docker, et une gestion structurée des vulnérabilités. Il cible les équipes cherchant à réduire leur exposition aux risques de sécurité entre deux audits manuels.

Ce dépôt GitHub propose une collection de bonnes pratiques pour sécuriser l'utilisation du gestionnaire de paquets npm, face aux risques croissants d'attaques par la chaîne d'approvisionnement. Il met l'accent sur des mesures comme la désactivation des scripts post-installation, l'installation avec délai pour éviter les dépendances vulnérables, et l'utilisation d'outils comme npq ou Socket Firewall pour renforcer la sécurité lors des installations. Une section est dédiée à la prévention des attaques par confusion de dépendances, un vecteur d'attaque récurrent exploitant les lacunes des gestionnaires de paquets.

Le guide couvre également des pratiques pour le développement local sécurisé, comme éviter les secrets en clair dans les fichiers .env, et des recommandations pour les mainteneurs de paquets npm, incluant l'activation de la double authentification (2FA) et l'utilisation de l'authentification OIDC pour les publications. Il aborde aussi la vérification de la santé des paquets via des bases de données comme celle de Snyk et la méfiance envers le registre officiel npmjs.org.

Enfin, il propose des solutions pour différents gestionnaires de paquets (npm, pnpm, Bun, Yarn) et inclut des outils automatisés comme Snyk, Dependabot ou Renovate pour gérer les mises à jour de dépendances de manière sécurisée.

Hadrian est un framework open source dédié à la sécurité des API, conçu pour détecter les vulnérabilités du Top 10 OWASP, notamment celles liées à l'autorisation (BOLA, BFLA) et à l'authentification. Il automatise les tests en utilisant des rôles prédéfinis (admin, user, guest) et des templates YAML, sans nécessiter de code personnalisé.

L'outil se distingue par son approche en trois phases (configuration, attaque, vérification) pour confirmer les vulnérabilités, ainsi que par son support multi-protocoles (REST, GraphQL, gRPC). Il propose aussi des rapports adaptés aux pipelines CI/CD et une intégration optionnelle avec des LLM pour réduire les faux positifs.

Disponible sous licence Apache 2.0, Hadrian inclut 30 templates couvrant les risques majeurs de l'OWASP, avec des fonctionnalités comme le throttling adaptatif ou la compatibilité avec des proxys comme Burp Suite.

L’article de Bearstech alerte sur les risques liés à l’intégration massive des grands modèles de langage (LLMs) dans les processus de développement logiciel, soulignant un paradoxe entre gain de productivité et explosion de la dette technique. L’adoption généralisée de l’IA générative, motivée par des impératifs de rapidité, entraîne une production de code souvent mal maîtrisé, augmentant la complexité des systèmes et rendant leur maintenance et leur sécurisation plus difficiles.

Les conséquences incluent des difficultés accrues pour appliquer des correctifs de sécurité, un coût élevé pour le débogage et l’audit, ainsi qu’une baisse de productivité pour les développeurs expérimentés. Les LLMs, en validant les biais initiaux des utilisateurs, peuvent aussi fausser la qualité des solutions proposées, aggravant les vulnérabilités des systèmes.

Enfin, l’article met en garde contre l’illusion d’une productivité durable, rappelant que le "vibe coding" – dépendre entièrement de l’IA pour coder – fragilise la sûreté des infrastructures IT, notamment dans les entreprises françaises.

Ce guide de GitLab explique comment sécuriser les conteneurs à chaque étape de leur cycle de vie grâce à différentes méthodes de container scanning. L’objectif est de détecter les vulnérabilités dès leur apparition, que ce soit lors de la construction de l’image ou en production, afin d’éviter les risques liés aux dépendances externes (OS, bibliothèques, etc.). GitLab propose cinq approches de scanning, dont le pipeline-based Container Scanning, qui analyse les images via Trivy lors des pipelines CI/CD pour bloquer les images vulnérables avant déploiement.

L’article détaille notamment l’activation du pipeline-based Container Scanning, soit via une configuration automatique via une merge request, soit manuellement en ajoutant un template dans le fichier .gitlab-ci.yml. Il est possible de personnaliser le scan en ciblant une image spécifique ou en filtrant les vulnérabilités selon leur gravité (ex. uniquement les vulnérabilités High ou plus). Les résultats s’affichent directement dans les merge requests, avec des détails sur la sévérité, les paquets concernés et les correctifs disponibles.

Une attaque de type supply chain a compromis brièvement la bibliothèque JavaScript Axios en mars 2026 via le piratage du compte npm d’un mainteneur, permettant la publication de versions malveillantes intégrant une dépendance piégée qui installait un cheval de Troie (RAT) multiplateforme lors d’un simple npm install, exposant potentiellement les environnements de développement et les pipelines CI/CD sans modification directe du code applicatif. L’incident, actif seulement quelques heures mais à fort impact en raison de la popularité d’Axios, illustre la fragilité des chaînes d’approvisionnement logicielles et pousse à adopter des mesures comme le gel ou le filtrage des dépendances récentes, la rotation des secrets, l’audit des systèmes et une sécurisation renforcée des comptes et pipelines pour limiter ce type de compromission

CORS est souvent mal compris : ce n’est pas un mécanisme qui protège une API contre des attaques, mais une sécurité implémentée par le navigateur pour empêcher des sites malveillants d’effectuer des requêtes en utilisant les données ou la session d’un utilisateur à son insu. Concrètement, le serveur répond normalement aux requêtes, mais le navigateur bloque l’accès à la réponse côté JavaScript si les en-têtes CORS ne sont pas autorisés, ce qui signifie qu’une API reste accessible en dehors du navigateur (via curl, serveur backend, etc.) et doit donc être sécurisée par d’autres moyens comme l’authentification. L’idée clé est que CORS sert à protéger les utilisateurs contre des abus cross-origin (comme le CSRF), pas à restreindre l’accès réel à une API, d’où l’importance de ne pas le considérer comme une barrière de sécurité côté serveur.

OpenCVE est une plateforme d'intelligence sur les vulnérabilités (CVE) conçue pour centraliser et simplifier la gestion des alertes et du suivi des vulnérabilités. Elle agrège les données de multiples sources (MITRE, NVD, RedHat, CISA, etc.), permet de filtrer et prioriser les CVE selon divers critères (CVSS, EPSS, KEV, etc.), et offre des tableaux de bord personnalisables, un suivi par projet, des notifications avancées (email, Slack, webhook) et des rapports quotidiens alimentés par l'IA. Disponible en SaaS ou en on-premise, OpenCVE propose plusieurs formules (gratuite, Starter, Pro, Enterprise) adaptées aux besoins des équipes SecOps, avec des options comme l'export CSV, les logs d'audit et une gestion illimitée pour les grandes organisations. Une solution open source (2,3k étoiles GitHub) pour sécuriser ses actifs plus efficacement.

Bagel est un outil CLI cross-platform (Linux, macOS, Windows) qui analyse la posture sécurité des postes de travail des développeurs en détectant les configurations risquées (clés SSH sans passphrase, Git SSL désactivé, etc.) et les secrets exposés (tokens, credentials cloud) sans jamais exfiltrer leurs valeurs. Développé en Go par BoostSecurity.io, il génère un rapport JSON structuré avec des remédiations actionnables, comparable à Lynis mais adapté aux outils de dev (Git, npm, IDEs, etc.). Ce guide explique son installation, l’interprétation des findings (priorisés par sévérité), et son intégration en CI via le mode --strict. Idéal pour les équipes DevSecOps souhaitant automatiser la détection des risques sur les environnements locaux.

Le dépôt GitHub “How-To-Secure-A-Linux-Server” est un guide évolutif destiné aux administrateurs souhaitant renforcer la sécurité d’un serveur Linux à travers une approche de défense en profondeur couvrant plusieurs couches du système. Il explique notamment comment sécuriser l’accès distant via SSH (clés, configuration renforcée, authentification à deux facteurs), limiter les privilèges des utilisateurs et mettre en place des protections réseau comme un pare-feu UFW, ainsi que des outils de détection d’intrusion et de surveillance tels que Fail2Ban, PSAD ou des solutions d’audit et de contrôle d’intégrité des fichiers. L’objectif est de rassembler dans une seule ressource des pratiques courantes de durcissement et de surveillance pour réduire les risques d’intrusion, de vol de données ou d’utilisation abusive du serveur exposé à Internet.

Cet article transcrit un webinaire de Bearstech sur le "Linux Hardening", une approche pragmatique pour sécuriser les serveurs Linux. Il souligne que Linux n'est pas sécurisé par défaut et nécessite des mesures supplémentaires comme la configuration stricte des accès, la limitation des services, la sécurisation du réseau, et la gestion rigoureuse des logs et sauvegardes. Bearstech privilégie Debian pour sa stabilité et la qualité de ses mises à jour. L'article aborde aussi l'authentification SSH, la gestion des mots de passe, le blocage des tentatives de connexion, l'accès root, l'utilisation de bastions SSH, et l'importance des logs pour la traçabilité et la sécurité.

Cet article explique comment sécuriser une connexion SSH en utilisant des clés publiques/privées, en désactivant l'authentification par mot de passe et en installant fail2ban. Il détaille les étapes pour générer une paire de clés (préférentiellement avec l'algorithme ed25519), les copier sur le serveur, ajuster les permissions et configurer PuTTY pour Windows. Une manipulation simple mais efficace pour protéger son serveur contre les attaques par force brute.

Richard Dern décrit une solution créative pour bloquer les indésirables sur son site statique en combinant Caddy et OPNsense. Son architecture réseau, bien que traditionnelle, utilise un reverse-proxy Caddy sur OPNsense pour gérer les accès internet. Il a défini des comportements suspects (tentatives d'accès à des fichiers inexistants, requêtes POST inappropriées, scans de scripts d'administration) et mis en place un script Python qui analyse les logs de Caddy, ajoute les IPs suspectes à un alias de firewall sur OPNsense, et génère un flux RSS pour l'informer. Cette solution évite les stacks complexes comme ELK et les notifications en temps réel, tout en restant simple et efficace.

Ce tutoriel explique comment sécuriser l'envoi d'e-mails en utilisant les protocoles SPF, DKIM et DMARC. Il détaille les failles du protocole SMTP et comment ces trois mécanismes complémentaires, basés sur le DNS, permettent de vérifier l'identité des expéditeurs et de lutter contre le spam et le phishing. Le tutoriel aborde la configuration de chaque protocole, leurs limites et leurs synergies, avec des exemples de syntaxe pour les enregistrements DNS.

Un détecteur de monoxyde de carbone analyse en continu l’air ambiant afin d’y mesurer la concentration de ce gaz toxique, incolore et inodore, et déclenche une alarme lorsque le niveau dépasse un seuil dangereux. La plupart des appareils utilisent un capteur électrochimique : au contact du CO, une réaction chimique produit un courant électrique proportionnel à la concentration du gaz, que l’électronique interne interprète pour décider de l’alerte. D’autres technologies existent, comme des capteurs optiques ou à semi-conducteurs, mais toutes reposent sur le même principe : surveiller la présence de CO issu d’une combustion incomplète et avertir rapidement les occupants pour prévenir une intoxication.

L’article explique qu’une application qui récupère des URLs fournies par des utilisateurs (pour des aperçus de liens, webhooks ou flux RSS) peut être vulnérable à des attaques de type SSRF, où un attaquant force le serveur à accéder à des ressources internes comme 127.0.0.1 ou l’endpoint de métadonnées AWS. Pour appliquer facilement le principe de programmation défensive avec Symfony, il suffit d’envelopper le client HTTP existant avec un décorateur comme NoPrivateNetworkHttpClient, qui bloque automatiquement les requêtes vers les réseaux privés sans modifier le reste du code. Cette approche illustre comment Symfony HttpClient permet d’ajouter des protections de sécurité simples et réutilisables grâce à son architecture basée sur des décorateurs.

PMG (Package Manager Guard) est un outil de sécurité open-source qui protège les développeurs contre les attaques de la chaîne d'approvisionnement via des paquets malveillants. Il agit comme une couche intermédiaire de sécurité autour des gestionnaires de paquets standards (npm, pip, etc.) en analysant les paquets pour détecter les logiciels malveillants avant leur installation, en les exécutant dans un bac à sable pour empêcher les modifications du système, et en auditant chaque événement d'installation. Facile à installer et à configurer, PMG fonctionne en arrière-plan et bloque immédiatement les paquets malveillants détectés. Il offre des fonctionnalités telles que la protection contre les paquets malveillants, le bac à sable, l'analyse des dépendances et la journalisation des événements.