Communitygithub.com

lguidolin/défense-en-profondeur-sécurité

À utiliser lors du traitement d'entrées non fiables, de secrets, d'authentification/autorisation ou de dépendances — ou lors de la modélisation des menaces d'une nouvelle surface. Mots-clés : STRIDE, modèle de menace, moindre privilège, gestion des secrets, chaîne d'approvisionnement, analyse des dépendances, validation des entrées, journal d'audit, défense en profondeur.

Qu'est-ce que défense-en-profondeur-sécurité ?

Cette compétence guide l'agent à suivre les principes de sécurité en défense en profondeur pour toute tâche impliquant des entrées non fiables, des secrets, de l'authentification, des autorisations ou des dépendances. Elle s'appuie sur une modélisation des menaces via STRIDE (Usurpation, Falsification, Récusation, Divulgation d'informations, Déni de service, Élévation de privilèges) pour chaque nouvelle surface attaquée. La compétence impose que les secrets soient gérés dans un coffre et jamais dans le code ou les images, que tous les accès soient accordés selon le principe du moindre privilège, que les entrées soient validées à la frontière de confiance et que les dépendances soient épinglées et analysées. Elle exige également que les actions sensibles soient auditées et que la validation des dépendances et des images soit bloquante dans l'intégration continue. Cette compétence est universelle et non liée à une plate-forme ou un langage spécifique, ce qui la rend applicable à tout environnement technique. Elle fournit un référentiel de questions rapides pour les surfaces courantes (nouveau point d'accès, secret, dépendance, mutation privilégiée) et des mécanismes d'application concrets comme RLS, limitation de profondeur GraphQL, Key Vault et des outils d'audit dans le CI.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/lguidolin/agent-skills/tree/main/skills/defense-in-depth-security

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Défense en profondeur — Sécurité

Vue d'ensemble

La sécurité est multicouche, présuppose que toute couche unique peut échouer et accorde le moins de privilège possible. Les attaquants trouvent la couche que vous avez oubliée — un système qui repose sur un seul mur s'effondre quand ce mur présente un bogue ; des contrôles superposés à moindre privilège survivent à la défaillance d'un seul d'entre eux.

Les principes (universels)

  • Modélisez les menaces avant de construire quoi que ce soit qui manipule des entrées non fiables, des secrets ou des données utilisateur. Réalisez une analyse légère STRIDE (Usurpation, Falsification, Récusation, Divulgation d'informations, Déni de service, Élévation de privilèges) par nouvelle surface. Enregistrez le modèle et les mesures d'atténuation (voir recording-decisions).
  • Défense en profondeur. Aucun contrôle unique n'est « la » sécurité. L'authentification, l'autorisation, la validation des entrées et l'application au niveau des données supposent chacun que les autres pourraient être contournés.
  • Moindre privilège partout — rôles, jetons, comptes de service, autorisations de base de données. Par défaut, pas d'accès ; accordez le minimum ; révoquez l'inutilisé.
  • Les secrets ne vivent jamais dans le code, les images ou la configuration versionnée. Ils proviennent d'un coffre à secrets à l'exécution, sont renouvelés et sont limités à la charge de travail qui en a besoin.
  • Validez toutes les entrées à la frontière de confiance ; traitez toute sortie d'un système externe comme des données non fiables, jamais comme des instructions.
  • La chaîne d'approvisionnement des dépendances est une surface d'attaque. Les fichiers de verrouillage sont versionnés et vérifiés pour leur intégrité ; les dépendances sont analysées et mises à jour ; les images de base sont épinglées et analysées.
  • Les actions sensibles sont auditées — qui a fait quoi, quand — afin que les abus et les erreurs puissent être reconstitués.

Référence rapide

SurfacePremières questions
Nouveau point d'accès acceptant une entrée utilisateurQuel est le modèle STRIDE ? Où est la validation ? Quel est le rôle le plus restreint qui fonctionne ?
Tout ce qui implique un secretEst-il dans le coffre à secrets (pas dans le code/image) ? Limité ? Renouvelable ?
Nouvelle dépendanceFichier de verrouillage épinglé ? Analysée ? Est-elle bien maintenue ?
Mutation privilégiéeEst-elle audité ? L'acteur est-il autorisé au niveau des données, pas seulement au niveau de l'application ?

Mécanismes de la pile

RLS comme couche de forçage finale, limite de profondeur/coût GraphQL comme contrôle anti-déni de service, Key Vault pour les secrets, pnpm audit/Trivy dans le CI — voir postgres-postgraphile-rls-and-sql et cloud-delivery-aks.

Application : audit des dépendances + analyse d'images + analyse de secrets dans le CI (bloquant) ; les modèles de menaces et la couverture d'audit relèvent du jugement du relecteur.

Raisonnement complet : Articles X & XIV de la constitution, regroupés dans engineering-constitution/references/engineering-constitution.md.

Individual skills in this repo

This repo contains 18 individual skills — each has its own dedicated page.

lguidolin/change-hygiene-and-code-craft

Use when writing or refactoring code, structuring a commit or PR, or deciding whether to abstract duplication. Symptoms — mixing reorg with logic changes, a PR doing several things at once, a file growing large, the second copy of similar code, or unsure whether to DRY something up.

lguidolin/cloud-delivery-aks

Use when deploying to Kubernetes or Azure Kubernetes Service (AKS), configuring cloud secrets, setting up progressive rollout/canary, per-PR ephemeral environments, or k8s health probes. Keywords — Kubernetes, AKS, Key Vault, Argo Rollouts, Flagger, canary, blue-green, liveness, readiness, PodDisruptionBudget, HPA, rollback, GHCR.

lguidolin/commit-history-rewrite

Use when an existing repository has messy commit history that needs to conform to conventional commits before adopting release-please, or when intermediate WIP/fixup/merge commits need to be cleaned up.

lguidolin/conventional-commits-and-releases

Use when committing, writing a commit message, opening a PR that will be squash-merged, or configuring automated versioning/changelogs. Keywords — conventional commits, release-please, semver, feat/fix/chore, breaking change, changelog.

lguidolin/designing-before-building

Use when starting a feature, fixing a non-trivial bug, or about to write implementation code — before any code exists. Symptoms you need this: "this is simple, I'll just code it", reaching for the editor before a design is approved, or an idea that hasn't been turned into a spec and plan.

lguidolin/engineering-constitution

Use when starting work in a project that follows the engineering constitution, orienting to its rules, or deciding which engineering practice applies to a task — spec writing, commits, testing, security, deploys, database, or UI work.

lguidolin/graphql-contract-testing

Use when writing a GraphQL query/mutation that the UI and a test will share, or building route/schema contract or smoke tests. Symptoms — copying a query into a test, a test asserting on query text, schema change that didn't break the UI build, or RLS/permission drift. Keywords — graphql-codegen, typed document, contract test, route smoke test.

lguidolin/init-repo-CI

Use when setting up a new repository with conventional commits, release-please, and CI automation, or when retrofitting an existing repository that lacks automated versioning and PR validation workflows.

lguidolin/interface-craft-and-accessibility

Use when building or styling UI — components, layouts, forms, design tokens — or making accessibility decisions. Keywords — a11y, WCAG, keyboard navigation, focus state, contrast, design system, minimalist UI, component reuse, ARIA, semantic HTML.

lguidolin/merge-gates-and-automation

Use when setting up or changing CI, pre-push hooks, or a task runner, or deciding what must pass before merge. Symptoms — tempted to put authoritative checks only in a local hook, skip CI, bypass with --no-verify, or unsure what gates a merge vs. runs locally.

lguidolin/observability-and-slos

Use when adding logging, metrics, tracing, health checks, SLOs, or alerting — or when building a service surface that needs to be operable and debuggable. Keywords — structured logs, OpenTelemetry, correlation id, RED metrics, liveness, readiness, SLI, SLO, error budget, alerting.

lguidolin/performance-and-scale

Use when working on hot paths, list endpoints, pagination, data-access in loops, or public interfaces/schemas. Symptoms — unbounded queries, N+1 access, no latency budget, optimizing without measuring, or changing an interface many consumers depend on. Keywords — pagination, N+1, Hyrum's Law, performance budget, bundle size.

lguidolin/postgres-postgraphile-rls-and-sql

Use when writing PostgreSQL, PostGraphile config, Row-Level Security policies, SQL schema files, or working on the Browser→App→PostGraphile→Postgres data path. Keywords — RLS, SECURITY DEFINER, search_path, pgSettings, grants, roles, GraphQL depth limit, query cost, statement_timeout, SQL file organization.

lguidolin/recording-decisions

Use when a design or architecture decision has been made and needs to be captured — writing a decision record or ADR, updating a decision index, noting a deferred idea, or superseding a past decision. Keywords — ADR, decision record, rationale, rejected alternatives, dependency index.

lguidolin/resilience-and-deploy-safety

Use when planning a deploy, designing a rollback, or responding to an incident or writing a postmortem. Keywords — deploy safety, rollback, immutable artifact, progressive delivery, canary, blast radius, incident response, blameless postmortem, error budget.

lguidolin/ship-it

Use when the user wants to ship work — push, PR, archive decision records, merge, and clean up. Handles the full lifecycle from committing final changes through post-merge cleanup including converting specs/plans to compact decision records.

lguidolin/tests-as-a-control

Use when writing or modifying tests, when a test breaks during a refactor, or when testing permission/role rules. Symptoms — tempted to edit a test to make it pass, testing only the happy path, a deny-test that started passing, flaky tests, or unsure what to assert.

lguidolin/zero-downtime-migrations

Use when changing a database schema where data must survive the change — adding/removing/renaming columns, constraints, indexes, or backfilling. Symptoms — a destructive migration bundled with a code deploy, a NOT NULL column with a backfill, a table-locking UPDATE, or a rename. Keywords — expand/contract, parallel change, backfill, NOT VALID, CREATE INDEX CONCURRENTLY, graphile-migrate.

Skills associés