Sujet : security
-
Surveiller l'expiration des certificats TLS sur chaque point d'accès, pas seulement sur le site web principal
Un certificat expiré est une panne dont l'heure est exactement prévisible : sonder depuis l'extérieur la date notAfter de chaque certificat réellement présenté (web, API, messagerie, interfaces internes, répartiteurs de charge), alerter assez tôt pour permettre un renouvellement manuel, et vérifier les certificats intermédiaires comme le certificat final.
-
Vérifier qu'une connexion TLS a réellement négocié X25519MLKEM768
Distinguer la présence d'une capacité post-quantique du groupe sélectionné sur une connexion TLS réelle, à partir des détails du navigateur, d'OpenSSL, de curl et des observations côté serveur.
-
Journaux d'audit : quoi consigner, comment les garder intacts et qui peut les lire
Un journal d'audit indique qui a fait quoi, sur quel objet, quand et avec quel résultat ; l'application l'alimente pour chaque action pertinente pour la sécurité, le sépare des journaux de débogage, le protège contre les altérations en transférant rapidement ses entrées vers un stockage en ajout seul ou à écriture unique, et n'en autorise la lecture que dans le cadre d'accès restreints et consignés.
-
Corriger les failles KEV du noyau Linux : vérifier chaque CVE dans le paquet de la distribution et le noyau actif
Suivre séparément cinq failles du noyau exploitées. Utiliser les correctifs de paquets propres à la distribution et vérifier soit le noyau démarré, soit la couverture explicite par livepatch ; une mesure d’atténuation pour un sous-système ne résout pas les failles des autres.
-
Un secret a été committé : pourquoi supprimer le fichier ne suffit pas, et dans quel ordre réagir
Un identifiant poussé dans un dépôt Git persiste dans l'historique, les forks, les clones, les caches et les journaux de CI. Réécrire l'historique réduit l'exposition future mais ne peut pas rappeler les copies déjà faites ; la première étape consiste donc à révoquer et faire tourner l'identifiant, puis à nettoyer l'historique, puis à vérifier s'il a été utilisé.
-
Les permissions des fichiers Unix et l’umask
Chaque fichier possède des bits de lecture, d’écriture et d’exécution pour le propriétaire, le groupe et les autres, ainsi que les bits setuid, setgid et sticky ; les permissions des nouveaux fichiers dépendent de l’umask du processus. Les secrets doivent être dans des fichiers en mode 0600, les répertoires nécessitent le droit d’exécution pour être traversés et les services doivent s’exécuter sous un utilisateur dédié.
-
System Integrity Protection et Signed System Volume : ce qu'ils protègent et pourquoi il ne faut pas les désactiver
SIP interdit même à root de modifier les chemins système protégés ou d'intervenir sur les processus protégés ; le Signed System Volume scelle cryptographiquement tout le volume système et le vérifie à chaque démarrage. Ensemble, ils expliquent pourquoi /usr/local est accessible en écriture mais pas /usr, et pourquoi désactiver SIP n'est pas une solution légitime à une erreur de permissions.
-
Concevoir des limites de débit qui protègent le service et informent le client
Limiter selon l'identité que l'on peut vérifier (compte, préfixe réseau), utiliser des compteurs atomiques dans des fenêtres fixes ou glissantes, répondre 429 avec Retry-After, garder des budgets séparés pour les lectures, les écritures et les inscriptions, et publier les limites effectives.
-
Politique sudo en fichiers drop-in dans /etc/sudoers.d, vérifiée avec visudo -c
Ajouter une règle ciblée sous forme de fichier distinct dans /etc/sudoers.d, validé par visudo avant prise d'effet, rend la politique sudo auditable et évite qu'une erreur de syntaxe ne prive tout le monde d'accès. Cette méthodologie traite aussi du risque des règles NOPASSWD trop larges et de l'endroit où sudo journalise ses décisions.
-
Lier l’identité de publication npm et PyPI aux artefacts de version approuvés
La publication de confiance par OIDC supprime les jetons de publication stockés, mais sa sécurité dépend toujours du workflow autorisé. Séparer la construction de la publication, protéger les approbations et vérifier l’identité de l’artefact sans considérer sa provenance comme un verdict sur l’absence de code malveillant.
-
Étude de cas d'un service de téléversement de fichiers : tickets directs vers le stockage, analyse asynchrone et quotas
Une étude de conception pour des téléversements qui contournent les serveurs d'application : un ticket qui réserve un quota et renvoie une URL de téléversement signée, une étape de finalisation qui vérifie l'objet stocké, un worker d'analyse qui le promeut ou le supprime, des règles de cycle de vie pour les téléversements abandonnés, et un modèle de statut qui explique chaque objet stocké.
-
Prévenir les attaques de type cross-site scripting par l'encodage en sortie
Échapper les données pour le contexte exact dans lequel elles sont insérées (texte HTML, attribut, JavaScript, URL, CSS), utiliser un moteur de templates qui échappe par défaut, ne jamais construire du HTML par concaténation de chaînes, et s'appuyer en complément sur une CSP stricte.
-
Cisco Secure Email Gateway et SD-WAN Manager : vérifier les correctifs et préserver les preuves de compromission
Tenir des dossiers de remédiation distincts pour l’analyseur de messagerie et SD-WAN Manager. Vérifier les correctifs effectivement installés, préserver les preuves avant toute restauration perturbant le fonctionnement et suivre la démarche d’investigation propre à chaque produit.
-
Les services de liens courts à identifiants séquentiels reçoivent plus de requêtes d'énumération que ceux à identifiants aléatoires
Hypothèse : un raccourcisseur d'URL dont les clés sont un compteur encodé en base62 permet à quiconque de parcourir tous les liens, alors que des clés aléatoires de longueur fixe font échouer la plupart des essais ; la proposition est que les services séquentiels voient une part plus élevée de requêtes portant sur des clés existantes émises par des clients qui n'ont jamais reçu le lien, et que la part de réponses 404 ne permet pas à elle seule de distinguer les deux cas.
-
Préparer la gestion des vulnérabilités CRA d’un fabricant : réception, preuves et délais de notification
Une proposition de protocole de préparation relie la réception des signalements de vulnérabilités et les dossiers de composants à la décision de notification au titre du CRA. Elle distingue l’obligation de notification déjà applicable en 2026 des exigences plus larges de gestion des vulnérabilités applicables en décembre 2027.
-
La spécification Standard Webhooks face à l'en-tête HMAC de Shopify et au jeton secret partagé de GitLab
La spécification Standard Webhooks définit les en-têtes webhook-id, webhook-timestamp et webhook-signature, un secret en base64 préfixé par whsec_ dont les octets décodés servent de clé HMAC, et une signature v1,<base64> calculée sur « {id}.{timestamp}.{payload} » ; les jetons de signature de GitLab (GitLab 19.0, disponibles en GA dans la 19.1) l'implémentent à l'identique. Shopify envoie à la place un HMAC en base64 du corps brut dans X-Shopify-Hmac-SHA256, et l'ancien X-Gitlab-Token de GitLab est un simple secret partagé, pas un HMAC.
-
Détecter la falsification de paquets RPM installés avec rpm -V
rpm -V compare les fichiers installés aux sommes de contrôle, permissions et propriétaires enregistrés lors de l'installation du paquet ; ses codes d'une lettre indiquent précisément ce qui a changé. Cette méthodologie explique comment lire cette sortie et en rappelle les limites en tant que contrôle d'intégrité.
-
La politique de même origine (Same-Origin Policy) : ce qu'est une origine et ce qu'elle isole
Une origine est le triplet schéma, hôte et port d'une URL. Un script peut lire et modifier des documents, du stockage et des réponses de même origine ; les lectures cross-origin sont bloquées par défaut, tandis que les écritures cross-origin telles que les soumissions de formulaire et l'intégration telle que les images et les scripts sont généralement autorisées. CORS assouplit les lectures ; des défenses contre le CSRF restent nécessaires.
-
Après l'arrivée d'un signalement de vulnérabilité : accuser réception, évaluer, corriger en privé, divulguer
Une fois qu'un signalement atteint le contact sécurité du projet, le travail est une séquence datée : accuser réception rapidement, classer (fonctionne comme prévu, bug, demande de fonctionnalité, vulnérabilité), convenir d'un embargo avec la personne qui signale, développer le correctif en privé, obtenir un identifiant CVE, puis publier une version et un avis nommant les versions concernées et corrigées, et créditant la personne à l'origine du signalement. Le guide des mainteneurs de l'OpenSSF et les recommandations de divulgation de GitHub décrivent ce processus ; cet article le condense pour un projet compté entre un et cinq mainteneurs.
-
Isoler les actions d'un agent dans une sandbox : frontières de système de fichiers, de réseau et d'identifiants
Un agent qui exécute des commandes ou du code devrait le faire à l'intérieur d'une frontière qui limite les fichiers qu'il peut toucher, les hôtes qu'il peut atteindre et les secrets qu'il peut lire ; conteneurs aux capacités réduites avec un profil seccomp, noyaux en espace utilisateur tels que gVisor, réseau refusé par défaut et identifiants de courte durée à portée limitée en sont les briques.
Lisible par machine : JSON