Tous les articles
-
Détecter les tests de sécurité qui s'exécutent accidentellement avec une autorité d'administrateur
S'assurer qu'un test de sécurité exerce bien l'identité à faible privilège prévue, et non une valeur par défaut privilégiée du dispositif de test. Cette méthode originale vérifie l'autorité effective avant de faire confiance à une assertion de refus d'accès ou à un flux utilisateur réussi.
-
Valeurs par défaut sécurisées et conception à échec fermé
Le principe des valeurs par défaut à sécurité intégrée de Saltzer et Schroeder fonde l'accès sur une permission explicite, de sorte qu'une erreur refuse plutôt qu'elle n'accorde ; appliqué aujourd'hui, cela signifie une autorisation qui refuse par défaut, une configuration qui refuse de démarrer lorsqu'un paramètre de sécurité manque, et des chemins d'erreur qui ferment l'accès plutôt que de l'ouvrir.
-
Bases de la récupération pour les applications à base de LLM : découpage en fragments, identifiants de passage et citation de ce qui a été récupéré
La génération augmentée par récupération fournit au modèle des passages récupérés ; les décisions qui comptent sont la façon dont les documents sont découpés, le contexte que porte chaque fragment, et la façon dont la réponse renvoie à un passage précis afin qu'un lecteur puisse le vérifier.
-
Runbooks pour l'exploitation : des marches à suivre qu'une personne extérieure peut exécuter en pleine nuit
Un runbook par service répond, dans cet ordre : ce que fait le service, comment reconnaître en une minute s'il est en bonne santé, quelles sont les pannes connues avec leur symptôme, la commande de diagnostic et la contre-mesure, quelles actions sont sûres, lesquelles sont dangereuses, et qui escalader et quand ; il est vérifié par une personne qui ne l'a pas rédigé.
-
Faire correspondre une affirmation de revue de code au comportement modifié précis qu'elle étaye
Construire une carte de revue compacte qui empêche des contrôles réussis mais sans rapport d'être utilisés comme preuve pour un comportement nouvellement modifié.
-
Trouver les ports en écoute et le processus associé avec ss
`ss -tulpn` liste tous les sockets TCP/UDP en écoute avec le processus propriétaire ; l'adresse de liaison indique si l'exposition est locale uniquement, étendue à tout le réseau ou en double pile. Bien lire cette adresse permet de distinguer un service voulu d'un service exposé par erreur.
-
Comptes de service selon les familles d'OS : le moindre privilège pour les services d'arrière-plan propres à un agent
Chaque OS permet d'exécuter un service sans connexion interactive ni mot de passe géré à la main : utilisateurs système Linux avec shell nologin ou DynamicUser= de systemd, comptes virtuels et comptes de service gérés de groupe (gMSA) sous Windows, utilisateurs de démons sous macOS. Choisir le plus restreint est essentiel pour tout ce qu'un agent installe pour s'exécuter sans surveillance.
-
Canoniser les URL sans en changer le sens
Utiliser une clé de comparaison définie par l'application tout en conservant l'URL de requête exacte, lorsque la normalisation risque d'altérer l'acheminement ou les signatures.
-
Attribuer les droits d'accès selon le principe du moindre privilège
Chaque identité — personne, service, agent — ne reçoit que les droits que sa tâche normale exige, et seulement pour la durée où elle en a besoin : un rôle de base de données propre à chaque service avec des GRANT limités au nécessaire, des processus sans root et dotés de capabilities isolées plutôt que d'une toute-puissance, une élévation temporaire pour les personnes, un nettoyage régulier.
-
Verrous distribués et baux de leader : expiration, jetons de barrière et ce qu'un verrou ne peut pas promettre
Un verrou distribué est un bail qui expire ; un processus mis en pause par un ramasse-miettes, une contention CPU ou un réseau retardé peut continuer d'agir après que son bail est passé à quelqu'un d'autre. Seul un jeton de barrière strictement croissant, vérifié par la ressource protégée, rend un tel verrou sûr pour la correction ; un verrou utilisé simplement pour éviter un travail en double demande moins.
-
Éventail spéculatif : poser toutes les questions à un modèle de décision en une seule requête et décider dans le code
Comme TypeSafe évalue toutes les questions d'une requête en parallèle sur un même état, le modèle documenté consiste à envoyer en un seul appel toutes les questions dont un flux de travail pourrait avoir besoin, y compris celles qui ne comptent que sur certaines branches, et à laisser le code ignorer les réponses non pertinentes ; le livre de recettes du fournisseur rapporte, sur son propre exemple, qu'une requête groupée est 12,2 fois moins chère et 10,0 fois plus rapide que des appels séquentiels.
-
Vérifier les signatures des webhooks GitHub : X-Hub-Signature-256, comparaison à temps constant et identifiants de livraison
GitHub signe chaque livraison de webhook avec un HMAC-SHA256 calculé sur le corps brut de la requête et l'envoie sous la forme sha256=<hex digest> dans l'en-tête X-Hub-Signature-256. Le récepteur doit recalculer ce condensat à partir des octets exacts reçus, le comparer avec une fonction à temps constant et utiliser X-GitHub-Delivery pour reconnaître les événements relivrés ; l'ancien en-tête X-Hub-Signature (HMAC-SHA1) n'est conservé que pour la compatibilité.
-
Prendre en charge plusieurs lignes de version : quels correctifs vont où
Une politique de support est un tableau des lignes de version, chacune avec un statut (fonctionnalités, correctifs, sécurité uniquement, fin de vie) et une règle indiquant quelles classes de correctifs sont rétroportées vers quelles lignes. Python maintient une série avec des versions correctives pendant deux ans, puis des versions sécurité uniquement pendant trois ans de plus ; Django rétroporte les correctifs critiques vers la dernière version de fonctionnalités, et les correctifs de sécurité et de perte de données vers les deux dernières plus les lignes à support à long terme ; Rust ne prend en charge que la dernière version stable. Un petit projet a intérêt à publier le tableau et à se limiter par défaut à la promesse la plus étroite qu'il peut tenir.
-
Tenir un registre de preuves pour les réponses à sources multiples
Faire correspondre chaque affirmation significative à une section source, une version et une incertitude, afin que les contradictions restent visibles pendant la synthèse.
-
Transformer un bug en test de régression
Avant la correction, le bug est reproduit sous forme de test automatique qui échoue pour la raison signalée ; la correction le fait passer au vert, et le test reste en place comme sentinelle. Avec pytest, ce test unique peut être rejoué isolément (`--lf`), et un bug dont la correction est différée est documenté par `xfail(strict=True)`, afin qu'une disparition silencieuse soit détectée.
-
Le temps de séchage du linge à l'intérieur suit l'écart entre la température ambiante et le point de rosée de plus près que la seule humidité relative
Hypothèse : le National Weather Service décrit le point de rosée comme la température à laquelle l'air doit être refroidi pour atteindre 100 % d'humidité relative, et note que l'humidité relative peut induire en erreur, car un même chiffre correspond à des quantités d'humidité différentes selon la température ; la proposition est que, pour des charges humides similaires pesées à intervalles sur le même séchoir intérieur, le temps jusqu'à une masse stable est mieux ordonné d'un jour à l'autre par l'écart entre la température ambiante et le point de rosée que par l'humidité relative, dans une comparaison au sein d'un même foyer ; aucun résultat n'est revendiqué.
-
Construire des données de test avec des builders : valeurs par défaut valides, écarts nommés
Un builder de données de test fournit, pour chaque entité, un objet standard valide, et ne laisse le test définir que les champs dont dépend son assertion. On lit ainsi dans le test ce qui compte, et une nouvelle colonne obligatoire ne change qu'un seul endroit au lieu de cent tests. La démarche se distingue des fixtures partagées et de l'Object Mother, dont Martin Fowler décrit le couplage étroit.
-
Changer les politiques cryptographiques système sur RHEL avec update-crypto-policies
La politique cryptographique système de RHEL définit les algorithmes et versions de protocole proposés par défaut par OpenSSL, GnuTLS, NSS, libkrb5 et OpenSSH. Elle se modifie en une seule commande, sans éditer la configuration de chaque application. Cette méthodologie couvre l'affichage, la définition et le test d'une politique, ainsi que la raison pour laquelle les services déjà en cours d'exécution doivent être redémarrés pour la prendre en compte.
-
Zones Solaris : ce que contrôle la zone globale et en quoi les zones de noyau diffèrent des zones non globales
La zone globale administre toutes les zones non globales ; hors listage et aide, les sous-commandes de zoneadm et zonecfg exigent la zone globale et une autorisation adaptée. Une zone de noyau exécute son propre noyau, avec son propre niveau de mise à jour, alors qu'une zone non globale partage celui de la zone globale.
-
Unreal Lumen : choisir le tracing et la qualité en fonction de la scène à rendre
Comment évaluer l'éclairage indirect dynamique et les réflexions de Lumen à partir de la représentation de tracing, de la structure de la scène, de la scalabilité et de tests visuels reproductibles.
Lisible par machine : JSON