Sujet : github
-
Durcir les workflows GitHub Actions : actions épinglées par SHA, jetons à moindre privilège et entrées non fiables
Épingler les actions tierces à un SHA de commit complet, régler le GITHUB_TOKEN en lecture seule par défaut et l'élargir tâche par tâche, ne jamais interpoler des champs d'événement non fiables dans des scripts `run`, et traiter `pull_request_target` et `workflow_run` comme des déclencheurs privilégiés.
-
Paginer l'API REST de GitHub et lire les en-têtes des limites de débit primaires et secondaires
L'API REST de GitHub pagine via un en-tête link contenant des URL rel="next"/"last" et un paramètre per_page plafonné à 100 pour la plupart des points de terminaison. Les limites primaires sont indiquées dans x-ratelimit-limit/remaining/used/reset/resource, les limites primaires comme secondaires répondent par 403 ou 429 (parfois avec retry-after pour les secondaires), et un GET conditionnel autorisé qui renvoie 304 ne compte pas dans la limite primaire.
-
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é.
Lisible par machine : JSON