Communitygithub.com

lguidolin/verteidigung-in-der-tiefe-sicherheit

Verwenden Sie dies beim Umgang mit nicht vertrauenswürdigen Eingaben, Geheimnissen, Authentifizierung/Autorisierung oder Abhängigkeiten – oder beim Threat-Modelling einer neuen Oberfläche. Schlüsselwörter: STRIDE, Bedrohungsmodell, Least Privilege, Secrets Management, Supply Chain, Dependency Scanning, Eingabevalidierung, Audit-Log, Defense in Depth.

Was ist verteidigung-in-der-tiefe-sicherheit?

Diese Fähigkeit (Skill) bietet Entwicklern und KI-Agenten einen umfassenden, mehrschichtigen Sicherheitsrahmen, der als "Defense in Depth" bekannt ist. Sie ist für jede Phase der Softwareentwicklung gedacht, insbesondere beim Umgang mit nicht vertrauenswürdigen Daten, sensiblen Operationen oder der Integration neuer Abhängigkeiten. Der Skill basiert auf universellen Prinzipien wie der Bedrohungsmodellierung mittels STRIDE, dem Prinzip der geringsten Privilegien (Least Privilege), strenger Secrets-Verwaltung und der Validierung aller Eingaben an Vertrauensgrenzen. Er unterstützt gängige Cloud- und CI/CD-Plattformen und schlägt konkrete Mechanismen wie Row-Level-Security (RLS) in der Datenbank, GraphQL-Tiefen- und Kostenbegrenzung als DoS-Schutz, sowie die Integration von Key Vault und Abhängigkeitsscannern (z. B. pnpm audit, Trivy) vor. Im Kern wird betont, dass kein einzelner Schutzschild genügt; die Schichten müssen einander ergänzen, sodass der Ausfall einer einzelnen Ebene nicht zur Katastrophe führt. Die Anwendung dieser Prinzipien wird durch reviewbare Bedrohungsmodelle und Audit-Abdeckung sichergestellt, wobei CI-Prüfungen (Dependency Audit, Image Scanning, Secret-Scanning) die Einhaltung automatisieren.

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

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Verteidigung in der Tiefe – Sicherheit

Überblick

Sicherheit ist mehrschichtig, geht davon aus, dass jede einzelne Schicht versagen kann, und gewährt die geringsten Privilegien, die funktionieren. Angreifer finden die Schicht, die Sie vergessen haben – ein System, das sich auf eine einzige Mauer verlässt, stürzt ein, wenn diese Mauer einen Fehler aufweist; überlappende Least-Privilege-Kontrollen überleben das Versagen einer einzelnen.

Die Prinzipien (universell)

  • Erstellen Sie ein Bedrohungsmodell, bevor Sie etwas bauen, das nicht vertrauenswürdige Eingaben, Geheimnisse oder Benutzerdaten verarbeitet. Ein leichter STRIDE-Durchlauf (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) pro neuer Oberfläche. Halten Sie das Modell und die Gegenmaßnahmen fest (siehe recording-decisions).
  • Verteidigung in der Tiefe. Keine einzelne Kontrolle ist "die" Sicherheit. Authentifizierung, Autorisierung, Eingabevalidierung und Durchsetzung auf Datenebene gehen jeweils davon aus, dass die anderen umgangen werden könnten.
  • Geringste Privilegien überall – Rollen, Tokens, Dienstkonten, DB-Berechtigungen. Standardmäßig kein Zugriff; gewähren Sie das Minimum; widerrufen Sie das Ungenutzte.
  • Geheimnisse leben niemals in Code, Images oder committeden Konfigurationen. Sie stammen zur Laufzeit aus einem Secret Store, werden rotiert und sind auf die Arbeitslast beschränkt, die sie benötigt.
  • Validieren Sie alle Eingaben an der Vertrauensgrenze; behandeln Sie jede Ausgabe eines externen Systems als nicht vertrauenswürdige Daten, niemals als Anweisungen.
  • Die Abhängigkeiten-Lieferkette ist eine Angriffsfläche. Lockfiles committed und auf Integrität geprüft; Abhängigkeiten gescannt und aktualisiert; Basis-Images eingefroren und gescannt.
  • Sensible Aktionen werden protokolliert – wer hat was wann getan – so dass Missbrauch und Fehler rekonstruierbar sind.

Kurzreferenz

OberflächeErste Fragen
Neuer Endpunkt, der Benutzereingaben akzeptiertWie sieht das STRIDE-Modell aus? Wo ist die Validierung? Was ist die minimal benötigte Rolle?
Alles mit einem GeheimnisIst es im Secret Store (nicht in Code/Image)? Begrenzt? Rotierbar?
Neue AbhängigkeitIst die Lockdatei eingefroren? Gescant? Wird es gut unterstützt?
Privilegierte MutationWird sie protokolliert? Ist der Akteur auf Datenebene autorisiert, nicht nur in der App?

Stack-Mechanismen

RLS als letzte Durchsetzungsschicht, GraphQL-Tiefen-/Kostenbegrenzung als DoS-Schutz, Key Vault für Geheimnisse, pnpm audit/Trivy in CI – siehe postgres-postgraphile-rls-and-sql und cloud-delivery-aks.

Durchsetzung: Abhängigkeits-Audit + Image-Scanning + Secret-Scanning in CI (blockierend); Bedrohungsmodelle und Audit-Abdeckung sind Prüferentscheidung.

Vollständige Begründung: Artikel X & XIV der Verfassung, gebündelt in 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.

Verwandte Skills