Invite d'examen de la sécurité de la migration

--- name: revue-securite-migrations description: Examine les migrations de schéma de base de données (SQL brut ou généré par ORM à partir de Rails, Django, Alembic, Prisma, Knex, Laravel, Flyway) pour les risques de production avant leur déploiement - DDL verrouillant les tables, réécritures complètes de tables, perte de données, changements cassants pour le code applicatif en cours d'exécution, et chemins de rollback manquants - et propose des réécritures sûres sans temps d'arrêt. À utiliser lorsqu'un diff ou une PR ajoute ou modifie des fichiers de migration, lorsque l'utilisateur demande "cette migration est-elle sûre ?", ou avant de déployer des changements de schéma sur une base PostgreSQL ou MySQL très sollicitée. --- # Revue de Sécurité des Migrations Vous examinez les migrations de schéma comme le ferait un DBA senior prudent avant un déploiement en production. L'objectif est un verdict clair plus un SQL concret et plus sûr - pas une leçon générique sur les bases de données. ## Fichiers dans cette compétence - `scripts/scan_migration.py` - scanner heuristique rapide pour les instructions SQL risquées - `references/risk-catalog.md` - dangers opération par opération et modèles sûrs - `references/expand-contract.md` - garder l'ancien et le nouveau code applicatif fonctionnels pendant le déploiement - `templates/review-report.md` - le format de rapport que vous devez produire - `examples/example-review.md` - une revue complète et travaillée pour calibrer le ton et la profondeur ## Flux de travail ### 1. Trouver les migrations concernées - Si vous examinez une branche ou une PR : `git diff --name-only origin/main...HEAD` et conservez les fichiers sous les dossiers de migration (`migrations/`, `db/migrate/`, `alembic/versions/`, `prisma/migrations/`, `database/migrations/`, `db/migration/`). - Sinon, utilisez les fichiers ou le SQL pointés par l'utilisateur. - Notez quelles migrations sont nouvelles par rapport à celles déjà appliquées dans un environnement. Ne suggérez jamais de modifier une migration appliquée ; proposez une nouvelle migration de suivi. ### 2. Établir le contexte Déterminez, à partir des fichiers de configuration, docker-compose, ou en demandant à l'utilisateur : - Le moteur et la version majeure (par exemple PostgreSQL 15, MySQL 8.0). Le comportement des verrous en dépend. - La taille approximative et le trafic d'écriture de chaque table concernée. - Comment fonctionnent les déploiements : les migrations sont-elles exécutées avant, pendant, ou après le déploiement du nouveau code ? Si la taille ou le trafic est inconnu, supposez que la table est grande et très sollicitée, et dites-le. ### 3. Obtenir le vrai SQL Le code ORM masque ce qui s'exécute réellement. Rendez d'abord le SQL : | Framework | Commande | |-----------|---------| | Django | `python manage.py sqlmigrate <app> <migration>` | | Rails | `rails db:migrate` sur une base de test, puis inspectez le diff `db/structure.sql` | | Alembic | `alembic upgrade <from>:<to> --sql` | | Prisma | lisez `prisma/migrations/<name>/migration.sql` | | Laravel | `php artisan migrate --pretend` | | Knex | exécutez sur une base de test avec `DEBUG=knex:query` et copiez le SQL journalisé | | Flyway / Liquibase | le fichier `.sql` ou `liquibase update-sql` | Enregistrez le SQL rendu dans un fichier temporaire s'il ne s'agit pas déjà d'un fichier `.sql`. ### 4. Exécuter le scanner ```bash python3 scripts/scan_migration.py --dialect postgres path/to/migration.sql python3 scripts/scan_migration.py --dialect mysql db/*.sql ``` Il affiche `file:line [SEVERITY] RULE message` et sort avec le code 1 si une constatation HIGH existe. Traitez sa sortie comme des pistes, pas comme le verdict : il utilise des regex, peut manquer du SQL dynamique, et ne peut pas connaître les tailles de tables. ### 5. Examiner chaque instruction manuellement Pour chaque instruction, utilisez `references/risk-catalog.md` pour répondre : 1. Quel verrou prend-elle, et pour combien de temps (instantané, scan de table, ou réécriture complète) ? 2. Peut-elle perdre ou corrompre des données ? Est-ce intentionnel et sauvegardé ? 3. Va-t-elle faire la queue derrière de longues transactions ? `lock_timeout` (Postgres) ou `lock_wait_timeout` (MySQL) est-il défini pour échouer rapidement au lieu de bloquer tout le trafic ? 4. S'exécute-t-elle dans une transaction où elle ne doit pas (par exemple `CREATE INDEX CONCURRENTLY`) ? 5. Les grands backfills de données sont-ils traités par lots et séparés du DDL ? ### 6. Vérifier la compatibilité applicative Pendant un déploiement progressif, l'ancien et le nouveau code s'exécutent en même temps contre le nouveau schéma. Suivez `references/expand-contract.md` : - Recherchez dans le codebase (`rg -n '<column_or_table_name>'`) chaque objet renommé, supprimé, ou retypé, y compris le SQL brut, les sérialiseurs, et les requêtes d'analyse. - Signalez tout changement que le code actuellement déployé ne peut pas tolérer. ### 7. Vérifier le chemin de rollback - Une migration de descente existe-t-elle, et restaure-t-elle réellement l'état précédent ? - Les suppressions et les changements de type avec perte sont à sens unique : exigez une sauvegarde ou un plan par étapes. ### 8. Rédiger le rapport Remplissez `templates/review-report.md` exactement. Correspond à la profondeur de `examples/example-review.md`. Pour chaque constatation HIGH ou MEDIUM, donnez un SQL de remplacement ou un code de migration qui atteint le même état final en toute sécurité, divisé en étapes de déploiement ordonnées si nécessaire. ## Verdicts - **SAFE** - aucun verrou bloquant sur les grandes tables, aucune perte de données, rétrocompatible. - **SAFE WITH CHANGES** - peut être livré une fois les réécritures listées appliquées. - **UNSAFE** - provoquerait des temps d'arrêt, une perte de données, ou des erreurs dans le code en cours d'exécution tel qu'écrit. ## Règles - N'exécutez jamais vous-même des migrations contre des bases de production ou partagées. - Ne modifiez pas les fichiers de migration sauf si l'utilisateur le demande ; proposez des changements dans le rapport. - Soyez précis : nommez la table, le verrou, et le mode de défaillance. Évitez les conseils génériques. - Si vous n'êtes pas sûr d'un comportement spécifique à une version, dites-le et suggérez de tester sur une copie de taille production avec `\timing` / `EXPLAIN` et une surveillance des verrous. FILE:references/risk-catalog.md # Catalogue des Risques : Opérations de Migration Courantes Les noms de verrous sont PostgreSQL. ACCESS EXCLUSIVE bloque toutes les lectures et écritures ; SHARE bloque les écritures ; SHARE UPDATE EXCLUSIVE ne bloque ni l'un ni l'autre. ## Le problème de la file de verrous (s'applique à tout ce qui suit) Même un ALTER TABLE "instantané" nécessite brièvement ACCESS EXCLUSIVE. Si une longue requête ou une session inactive en transaction détient la table, l'ALTER attend - et chaque nouvelle requête fait la queue derrière. Un changement de 1 ms peut provoquer une panne de plusieurs minutes. Commencez toujours les migrations risquées par : ```sql SET lock_timeout = '5s'; -- échouer rapidement, réessayer plus tard SET statement_timeout = '15min'; -- limite supérieure facultative ``` Équivalent MySQL : `SET SESSION lock_wait_timeout = 5;` (verrous de métadonnées). ## Opérations PostgreSQL | Opération | Risque | Modèle sûr | |-----------|------|--------------| | `CREATE INDEX` | Verrou SHARE : écritures bloquées pendant toute la construction | `CREATE INDEX CONCURRENTLY`, hors transaction ; en cas d'échec, supprimez l'index INVALID et réessayez. Rails : `disable_ddl_transaction!` ; Django : `atomic = False` | | `DROP INDEX` | ACCESS EXCLUSIVE | `DROP INDEX CONCURRENTLY` | | `ADD COLUMN` nullable, sans défaut | Instantané | Sûr (définissez quand même lock_timeout) | | `ADD COLUMN ... DEFAULT <constante>` | Instantané sur PG 11+, réécriture avant 11 | Sûr sur 11+ | | `ADD COLUMN ... DEFAULT now()/random()/gen_random_uuid()` | Défaut volatil : réécriture complète de la table | Ajoutez une colonne nullable, backfill par lots, puis définissez le défaut | | `ADD COLUMN ... NOT NULL` sans défaut | Échoue sur une table non vide | Ajoutez nullable, backfill, puis appliquez NOT NULL (ci-dessous) | | `ALTER COLUMN ... SET NOT NULL` | Scan complet sous ACCESS EXCLUSIVE | `ADD CONSTRAINT c CHECK (col IS NOT NULL) NOT VALID` ; `VALIDATE CONSTRAINT c` ; puis `SET NOT NULL` (PG 12+ saute le scan) ; supprimez `c` | | `ALTER COLUMN ... TYPE` | Généralement réécriture complète + reconstruction d'index sous ACCESS EXCLUSIVE | Sûr uniquement si binaire-coercible (varchar(n) vers n plus grand ou vers text). Sinon nouvelle colonne + double écriture + backfill + échange | | `ADD FOREIGN KEY` | Verrouille les deux tables pendant la validation de toutes les lignes | `ADD CONSTRAINT ... NOT VALID`, puis `VALIDATE CONSTRAINT` dans une étape séparée | | `ADD CHECK` | Scan sous ACCESS EXCLUSIVE | Même modèle NOT VALID + VALIDATE | | `ADD UNIQUE` / `ADD PRIMARY KEY` | Construit l'index sous verrou | `CREATE UNIQUE INDEX CONCURRENTLY idx ...` ; puis `ADD CONSTRAINT ... UNIQUE USING INDEX idx` | | `RENAME COLUMN` / `RENAME TO` | Instantané, mais casse le code en cours d'exécution | Expand/contract (voir expand-contract.md) | | `DROP COLUMN` | Instantané, mais irréversible ; l'ancien code le sélectionnant génère une erreur | Supprimez toutes les références de code et déployez d'abord ; puis supprimez | | `DROP TABLE` / `TRUNCATE` | Perte de données irréversible | Confirmez la sauvegarde et zéro lecteur ; envisagez de renommer en `_deprecated` d'abord | | `ALTER TYPE ... ADD VALUE` | Nouvelle valeur inutilisable dans la même transaction ; aucune transaction du tout avant PG 12 | Mettez-la dans sa propre migration | | `VACUUM FULL` / `CLUSTER` / `REINDEX` | Réécriture complète sous ACCESS EXCLUSIVE | `REINDEX CONCURRENTLY` (PG 12+), `pg_repack` pour la fragmentation | | Gros `UPDATE` / `DELETE` | Verrous de ligne longs, pic WAL, retard de réplica | Traitez par lots par clé primaire (1k-10k lignes), validez par lot, exécutez hors de la migration DDL | ## Notes MySQL 8.0 (InnoDB) - Indiquez toujours l'algorithme pour que MySQL génère une erreur au lieu de copier silencieusement la table : `ALTER TABLE t ADD COLUMN c INT, ALGORITHM=INSTANT;` ou `ALTER TABLE t ADD INDEX i (c), ALGORITHM=INPLACE, LOCK=NONE;` - `ADD COLUMN` est INSTANT sur 8.0.12+ (dernière position) et 8.0.29+ (n'importe quelle position). - Les changements de type `MODIFY` / `CHANGE COLUMN` utilisent ALGORITHM=COPY : écritures bloquées. - Pour les grandes tables avec des changements COPY uniquement, utilisez `gh-ost` ou `pt-online-schema-change`. - Le DDL n'est pas transactionnel dans MySQL : une migration multi-instructions échouée laisse le schéma à moitié appliqué. Gardez une instruction DDL par migration. FILE:references/expand-contract.md # Expand / Contract : Changements de Schéma Rétrocompatibles Pendant un déploiement progressif, les anciennes et nouvelles versions de l'application s'exécutent côte à côte. Si les migrations s'exécutent avant que le nouveau code ne soit en ligne, l'ancien code doit fonctionner avec le nouveau schéma. S'ils s'exécutent après, le nouveau code doit fonctionner avec l'ancien schéma. Expand/contract rend chaque étape compatible avec les deux. ## Les trois phases 1. **Expand** - ajoutez uniquement de nouvelles structures (colonnes, tables, index). Rien n'est supprimé ou renommé. L'ancien code ignore les ajouts. 2. **Migrate** - déployez le code qui écrit à la fois dans les anciennes et nouvelles structures, backfill des lignes existantes par lots, puis basculez les lectures vers la nouvelle structure. 3. **Contract** - une fois qu'aucun code déployé ne touche l'ancienne structure, supprimez-la dans une migration séparée et ultérieure. Chaque phase est son propre déploiement. Ne combinez jamais expand et contract dans une seule migration. ## Recettes ### Renommer une colonne (`users.name` en `users.full_name`) 1. Migration : ajoutez `full_name` nullable. 2. Code : écrivez à la fois `name` et `full_name` ; lisez `name`. 3. Backfill `full_name = name` par lots où `full_name IS NULL`. 4. Code : lisez `full_name` ; continuez à écrire les deux. 5. Code : arrêtez d'écrire `name`. (Rails : ajoutez `name` à `ignored_columns` ici.) 6. Migration : supprimez `name`. ### Changer un type de colonne (`orders.amount` int en numeric) Comme le renommage : ajoutez `amount_numeric`, double écriture, backfill, basculez les lectures, supprimez l'ancien. Un déclencheur peut gérer les doubles écritures si les changements d'application sont difficiles. ### Rendre une colonne NOT NULL 1. Code : écrivez toujours une valeur. 2. Backfill des lignes NULL par lots. 3. Migration : CHECK ... NOT VALID, VALIDATE, SET NOT NULL (voir risk-catalog.md). ### Supprimer une colonne ou une table 1. Code : supprimez chaque lecture et écriture (recherchez les modèles ORM, le SQL brut, les vues, les rapports, les jobs ETL, et les autres services partageant la base de données). 2. Déployez et attendez au moins un cycle de version complet. 3. Migration : supprimez. Faites d'abord une sauvegarde ou un instantané des données si cela compte. ### Diviser ou déplacer une table Créez la nouvelle table, double écriture, backfill, basculez les lectures, arrêtez les anciennes écritures, supprimez. ## Questions de compatibilité à répondre pour chaque changement - Un code déployé fait-il `SELECT *` ou mappe-t-il toutes les colonnes (les ORM mettent souvent en cache la liste des colonnes au démarrage et échouent quand l'une disparaît) ? - Une insertion de l'ancien code échoue-t-elle parce qu'une nouvelle colonne est NOT NULL sans défaut ? - D'autres services, jobs cron, tableaux de bord BI, ou réplicas lisent-ils cette table ? - Le déploiement peut-il être annulé vers la version de code précédente sans migration de descente ? Si la réponse à la dernière question est "non", le changement n'est pas rétrocompatible. FILE:templates/review-report.md # Revue de Sécurité des Migrations : <nom de la migration ou titre de la PR> **Verdict :** SAFE | SAFE WITH CHANGES | UNSAFE **Moteur :** <par exemple PostgreSQL 15> | **Fichiers examinés :** <nombre> **Hypothèses :** <tailles de tables, trafic, ordre de déploiement - marquez tout ce qui est deviné> ## Résumé <2-4 phrases : ce que fait la migration, le plus grand risque, et quoi changer.> ## Constatations | # | Sévérité | Fichier:Ligne | Instruction | Risque | |---|----------|-----------|-----------|------| | 1 | HIGH | <chemin:ligne> | `<SQL court>` | <verrou / perte de données / casse l'ancien code> | ### 1. <Titre court de la constatation> - **Ce qui se passe :** <verrou pris, durée, qui est bloqué, ou ce qui casse> - **Pourquoi c'est important ici :** <taille de table, trafic, code qui en dépend> - **Alternative sûre :** ```sql -- SQL de remplacement ou code de migration, dans l'ordre d'exécution ``` <Répétez pour chaque constatation HIGH et MEDIUM. Regroupez les constatations LOW dans une liste.> ## Compatibilité Applicative - <Chaque objet renommé / supprimé / retypé et où le code l'utilise encore> - <Ou : "Aucune référence de code affectée - vérifié avec rg pour X, Y."> ## Plan de Rollback - <La migration de descente restaure-t-elle l'état ? Qu'est-ce qui est irréversible ?> - <Sauvegarde ou instantané requis avant l'exécution : oui/non> ## Séquence de Déploiement Recommandée 1. <Étape de migration ou de déploiement de code> 2. <...> ## Sortie du Scanner ``` <collez la sortie de scripts/scan_migration.py, ou notez les faux positifs> ``` FILE:examples/example-review.md # Exemple de Revue **Entrée :** PR "Ajouter le suivi du statut de commande" avec une migration Rails pour PostgreSQL 15. `orders` a ~40M de lignes et reçoit des écritures constantes. Les migrations s'exécutent avant le nouveau code. ```sql -- rendu depuis db/migrate/20261002_add_status_to_orders.rb ALTER TABLE orders ADD COLUMN status varchar NOT NULL DEFAULT 'pending'; ALTER TABLE orders RENAME COLUMN shipped_on TO shipped_at; CREATE INDEX index_orders_on_status ON orders (status); ALTER TABLE orders ADD CONSTRAINT fk_orders_carrier FOREIGN KEY (carrier_id) REFERENCES carriers (id); ``` **Scanner :** 3 HIGH (rename, index-not-concurrent, fk-validated), 1 MEDIUM (no-lock-timeout). --- # Revue de Sécurité des Migrations : Ajouter le suivi du statut de commande **Verdict :** UNSAFE **Moteur :** PostgreSQL 15 | **Fichiers examinés :** 1 **Hypothèses :** orders ~40M de lignes, trafic d'écriture élevé (de l'utilisateur) ; carriers est petite. ## Résumé Ajoute une colonne de statut de commande, renomme `shipped_on`, indexe le statut, et ajoute une clé étrangère vers carriers. La colonne de statut elle-même est sûre sur PG 15, mais le renommage cassera l'application en cours d'exécution, et l'index et la FK bloqueront les écritures sur `orders` pendant des minutes. Divisez en trois migrations et utilisez des variantes concurrentes / NOT VALID. ## Constatations | # | Sévérité | Fichier:Ligne | Instruction | Risque | |---|----------|-----------|-----------|------| | 1 | HIGH | rendered.sql:3 | `RENAME COLUMN shipped_on` | L'ancien code génère une erreur au déploiement | | 2 | HIGH | rendered.sql:4 | `CREATE INDEX ... (status)` | Écritures bloquées pendant la construction | | 3 | HIGH | rendered.sql:5 | `ADD ... FOREIGN KEY` | Scan de validation complet sous verrou | | 4 | MEDIUM | rendered.sql:1 | pas de `lock_timeout` | Les ALTER peuvent faire la queue et bloquer le trafic | ### 1. Le renommage de colonne casse le code en cours d'exécution - **Ce qui se passe :** le renommage est instantané, mais les serveurs d'application encore sur l'ancienne version interrogent `shipped_on` et échouent avec `column does not exist` jusqu'à la fin du déploiement. - **Pourquoi c'est important ici :** `rg -n shipped_on` trouve 7 références, y compris `app/serializers/order_serializer.rb` et le rapport nocturne `reports/fulfillment.sql`. - **Alternative sûre :** expand/contract. Ajoutez `shipped_at`, double écriture, backfill par lots, basculez les lectures, puis supprimez `shipped_on` dans une version ultérieure. ### 2. La construction d'index bloque les écritures - **Alternative sûre** (migration séparée, `disable_ddl_transaction!`) : ```sql CREATE INDEX CONCURRENTLY index_orders_on_status ON orders (status); ``` ### 3. La clé étrangère valide 40M de lignes sous verrou - **Alternative sûre :** ```sql SET lock_timeout = '5s'; ALTER TABLE orders ADD CONSTRAINT fk_orders_carrier FOREIGN KEY (carrier_id) REFERENCES carriers (id) NOT VALID; -- migration suivante (ne prend que SHARE UPDATE EXCLUSIVE sur orders) : ALTER TABLE orders VALIDATE CONSTRAINT fk_orders_carrier; ``` **LOW :** aucun. Notez que `ADD COLUMN ... DEFAULT 'pending'` est uniquement des métadonnées sur PG 11+. ## Compatibilité Applicative - `shipped_on` : 7 références de code plus un rapport SQL ; doit rester jusqu'à la phase de contract. ## Plan de Rollback - La migration de descente supprime `status` (perte de données acceptable : nouvelle colonne). Le renommage est réversible. - Aucune sauvegarde requise pour cet ensemble de changements une fois le renommage supprimé. ## Séquence de Déploiement Recommandée 1. Migration A : `SET lock_timeout` ; ajoutez `status` ; ajoutez `shipped_at` ; ajoutez FK NOT VALID. 2. Migration B (sans transaction) : créez l'index de statut en concurrent. 3. Migration C : validez la FK. Déployez le code qui écrit en double `shipped_on`/`shipped_at`. 4. Backfill `shipped_at` ; basculez les lectures ; version ultérieure supprime `shipped_on`. FILE:scripts/scan_migration.py #!/usr/bin/env python3 """Scanner heuristique pour SQL risqué dans les fichiers de migration (PostgreSQL / MySQL). Utilisation : python3 scan_migration.py [--dialect postgres|mysql] FILE [FILE ...] Codes de sortie : 0 = aucune constatation HIGH, 1 = constatations HIGH, 2 = erreur d'utilisation.""" import re, sys F = re.I | re.S COLDEF = r"(?:\([^)]*\)|[^,(])*" # une définition de colonne, permettant numeric(10,2) RULES = [ # (sévérité, id de règle, dialecte ou None pour les deux, regex, message) ("HIGH", "drop-table", None, r"^DROP\s+TABLE\b", "Perte de données irréversible ; confirmez la sauvegarde et zéro lecteur"), ("HIGH", "truncate", None, r"^TRUNCATE\b", "Perte de données irréversible"), ("HIGH", "drop-column", None, r"^ALTER\s+TABLE\b.*\bDROP\s+(COLUMN\b|(?!CONSTRAINT|INDEX|KEY|PRIMARY|FOREIGN|CHECK|DEFAULT|NOT|IDENTITY|EXPRESSION)\w)", "Perte de données ; le code déployé le lisant échouera - supprimez d'abord les références de code"), ("HIGH", "rename", None, r"^ALTER\s+TABLE\b.*\bRENAME\b", "Casse le code en cours d'exécution ; utilisez expand/contract"), ("HIGH", "type-change", "postgres", r"^ALTER\s+TABLE\b.*\bALTER\s+(COLUMN\s+)?\S+\s+(SET\s+DATA\s+)?TYPE\b", "Généralement une réécriture complète de table sous ACCESS EXCLUSIVE"), ("HIGH", "type-change", "mysql", r"^ALTER\s+TABLE\b.*\b(MODIFY|CHANGE)\s+(COLUMN\s+)?\S+", "La redéfinition de colonne utilise généralement ALGORITHM=COPY (écritures bloquées)"), ("HIGH", "index-not-concurrent", "postgres", r"^CREATE\s+(UNIQUE\s+)?INDEX\s+(?!CONCURRENTLY)", "Bloque les écritures pendant la construction ; utilisez CREATE INDEX CONCURRENTLY"), ("MEDIUM", "drop-index-not-concurrent", "postgres", r"^DROP\s+INDEX\s+(?!CONCURRENTLY)", "Prend ACCESS EXCLUSIVE ; utilisez DROP INDEX CONCURRENTLY"), ("HIGH", "fk-validated", "postgres", r"^ALTER\s+TABLE\b(?!.*\bNOT\s+VALID\b).*\b(FOREIGN\s+KEY|REFERENCES)\b", "Valide toutes les lignes en verrouillant les deux tables ; ajoutez NOT VALID, puis VALIDATE"), ("MEDIUM", "check-validated", "postgres", r"^ALTER\s+TABLE\b(?!.*\bNOT\s+VALID\b).*\bADD\s+(CONSTRAINT\s+\S+\s+)?CHECK\b", "Scan complet sous verrou ; ajoutez NOT VALID, puis VALIDATE"), ("MEDIUM", "set-not-null", "postgres", r"\bSET\s+NOT\s+NULL\b", "Scan complet sous ACCESS EXCLUSIVE ; validez d'abord un CHECK (col IS NOT NULL)"), ("HIGH", "add-not-null-no-default", None, r"^ALTER\s+TABLE\b.*\bADD\s+(COLUMN\s+)?(?!" + COLDEF + r"\bDEFAULT\b)" + COLDEF + r"\bNOT\s+NULL\b", "Échoue sur les tables non vides (ou les insertions de l'ancien code échouent) ; ajoutez nullable, backfill, puis appliquez"), ("MEDIUM", "volatile-default", "postgres", r"^ALTER\s+TABLE\b.*\bADD\b.*\bDEFAULT\s+(now|random|clock_timestamp|gen_random_uuid|uuid_generate_v\d)\s*\(", "Le défaut volatil réécrit la table ; ajoutez nullable, backfill, puis définissez le défaut"), ("MEDIUM", "unique-without-index", "postgres", r"^ALTER\s+TABLE\b(?!.*\bUSING\s+INDEX\b).*\bADD\s+(CONSTRAINT\s+\S+\s+)?(UNIQUE|PRIMARY\s+KEY)\b", "Construit l'index sous verrou ; créez-le CONCURRENTLY, puis ADD CONSTRAINT ... USING INDEX"), ("MEDIUM", "mysql-no-algorithm", "mysql", r"^(ALTER\s+TABLE|CREATE\s+(UNIQUE\s+)?INDEX)\b(?!.*\bALGORITHM\s*=)", "Indiquez ALGORITHM=INSTANT|INPLACE, LOCK=NONE pour que MySQL refuse une copie bloquante"), ("HIGH", "dml-no-where", None, r"^(UPDATE|DELETE)\b(?!.*\bWHERE\b)", "Touche chaque ligne dans une transaction ; traitez par lots"), ("LOW", "dml-in-migration", None, r"^(UPDATE|DELETE|INSERT)\b.*\bWHERE\b", "Changement de données dans la migration ; traitez par lots si la table est grande"), ("MEDIUM", "table-rewrite", "postgres", r"^(VACUUM\s+FULL|CLUSTER|REINDEX\s+(?!.*CONCURRENTLY))", "Réécrit sous ACCESS EXCLUSIVE ; utilisez REINDEX CONCURRENTLY ou pg_repack"), ("LOW", "enum-add-value", "postgres", r"^ALTER\s+TYPE\b.*\bADD\s+VALUE\b", "Nouvelle valeur inutilisable dans la même transaction ; gardez-la dans sa propre migration"), ] def statements(sql): """Génère (numéro_de_ligne, instruction) après suppression des commentaires. Division naïve par ';'.""" sql = re.sub(r"/\*.*?\*/", lambda m: re.sub(r"[^\n]", " ", m.group()), sql, flags=re.S) sql = re.sub(r"--[^\n]*", "", sql) pos = 0 for part in sql.split(";"): stripped = part.lstrip() line = sql.count("\n", 0, pos + len(part) - len(stripped)) + 1 pos += len(part) + 1 if stripped.strip(): yield line, " ".join(stripped.split()) def scan(path, dialect): text = open(path, encoding="utf-8", errors="replace").read() stmts, out = list(statements(text)), [] for line, st in stmts: for sev, rid, dia, rx, msg in RULES: if (dia is None or dia == dialect) and re.search(rx, st, F): out.append((sev, f"{path}:{line} [{sev}] {rid}: {msg}\n > {st[:110]}")) has_ddl = any(re.match(r"(ALTER|CREATE\s+(UNIQUE\s+)?INDEX|DROP)\b", s, re.I) for _, s in stmts) timeout = "lock_timeout" if dialect == "postgres" else "lock_wait_timeout" if has_ddl and timeout not in text.lower(): out.append(("MEDIUM", f"{path}:1 [MEDIUM] no-lock-timeout: DDL sans {timeout} ; il peut faire la queue et bloquer tout le trafic")) if re.search(r"\bCONCURRENTLY\b", text, re.I) and re.search(r"^\s*(BEGIN|START\s+TRANSACTION)\b", text, re.I | re.M): out.append(("HIGH", f"{path}:1 [HIGH] concurrently-in-transaction: CONCURRENTLY ne peut pas s'exécuter dans un bloc de transaction")) return out def main(argv): dialect = "postgres" if len(argv) >= 2 and argv[0] == "--dialect": dialect, argv = argv[1].lower(), argv[2:] if dialect not in ("postgres", "mysql") or not argv: print(__doc__, file=sys.stderr) return 2 try: findings = [f for p in argv for f in scan(p, dialect)] except OSError as e: print(f"error: {e}", file=sys.stderr) return 2 for _, text in findings: print(text) counts = {s: sum(1 for f in findings if f[0] == s) for s in ("HIGH", "MEDIUM", "LOW")} print(f"\n{len(argv)} fichier(s) scanné(s) : {counts['HIGH']} HIGH, {counts['MEDIUM']} MEDIUM, {counts['LOW']} LOW") print("Heuristique uniquement : confirmez chaque constatation contre references/risk-catalog.md.") return 1 if counts["HIGH"] else 0 if __name__ == "__main__": sys.exit(main(sys.argv[1:]))