Règles QA & conformité ANSSI

Ce document définit les règles de qualité et de sécurité applicables à tout le projet gitrust. Chaque lot doit satisfaire ces règles avant merge.

1. Gates de compilation obligatoires

Toute modification doit passer ces 4 gates sans erreur :

Gate	Commande	Critère
Formatage	`cargo fmt --all -- --check`	Zéro diff
Linting	`cargo clippy --workspace -- -D warnings`	Zéro warning
Tests unitaires	`cargo test --workspace`	100% pass
Build CSS	`npx tailwindcss -i static/css/input.css -o static/css/style.css --minify`	Si templates modifiés

Gates supplémentaires (à mettre en place)

Gate	Outil	Rôle
Audit dépendances	`cargo audit`	Détection CVE dans les deps
Licences & bans	`cargo deny check`	Licences compatibles, pas de crate bannie
Secrets dans le code	Recherche de patterns sensibles	Pas de token/mot de passe en dur

2. Règles de sécurité (ANSSI PA-074)

2.1 Lints Rust obligatoires (déjà en place)

#![forbid(unsafe_code)]                    // core, web, hooks
#![deny(unsafe_code)]                      // git, ssh (FFI nécessaire)
#![deny(clippy::unwrap_used)]
#![deny(clippy::expect_used)]
#![deny(clippy::panic)]
#![deny(clippy::indexing_slicing)]
#![deny(clippy::mem_forget)]

2.2 Checklist sécurité par feature

Avant toute implémentation touchant l'authentification, les secrets ou les permissions, vérifier :

Secrets jamais en clair en base — hash SHA-256 ou bcrypt
Secrets jamais loggés — vérifier tracing::info/debug/warn, Display et Debug impls ne révèlent pas le secret
Comparaison constant-time — subtle::ConstantTimeEq pour toute validation de secret (pas de == sur des hash)
Rate-limiting — endpoint d'authentification protégé
CSRF — token valide sur toute action mutante (POST/PUT/DELETE)
Ownership vérifiée (anti-IDOR) — le user ne peut agir que sur ses propres ressources (vérifier user_id côté serveur)
Expiration obligatoire — tout token/session a une durée de vie max
Audit log — création, révocation, utilisation suspecte tracées
Zeroize — types sensibles implémentent Zeroize/ZeroizeOnDrop
Path traversal — validation des chemins disque (pas de .., /, \)

2.3 Marqueurs SEC-

Le code utilise des commentaires // SEC-XX pour tracer les décisions de sécurité. Tout nouveau contrôle doit être marqué avec le prochain numéro disponible dans sa catégorie :

Préfixe	Catégorie	Exemples
SEC-C	Cryptographie	Timing attack, CSRF, PKCE
SEC-H	HTTP/Headers	X-Forwarded-For, cookies, nonce
SEC-L	Logique métier	Hashing, validation, defaults
SEC-M	Mémoire/sessions	Rate-limit DoS, refresh tokens

3. Tests requis par catégorie

3.1 Matrice de couverture

Catégorie	Quand appliquer	Exemples
Unitaire	Logique pure (validation, parsing, conversion)	`RepoSlug::new("../evil")` → erreur
Intégration	Service avec DB (CRUD, contraintes, transactions)	`PatService::validate` token expiré → None
Handler	Endpoint HTTP (status, redirect, CSRF, auth)	POST sans CSRF → 403
E2E Playwright	Flow utilisateur complet	Créer token → copier → cloner un dépôt
Sécurité négatif	Tout bypass imaginable	Token user A sur ressource user B → 401

3.2 Règles de tests

Tests d'intégration sur vraie DB — pas de mocks pour la couche persistence (les mocks masquent les bugs de migration)
Tests négatifs obligatoires — pour chaque chemin heureux, tester au moins : input invalide, non-authentifié, non-autorisé, expiré, révoqué
Tests E2E en français — cohérent avec l'UI (locale fr-FR)
Pas de sleep() dans les tests — utiliser des retry/poll avec timeout
Données de test isolées — chaque test crée ses propres données (pas de dépendance sur l'ordre d'exécution)

4. Règles de code

4.1 Framework boundary

Ne jamais modifier crates/rustwarden-core/
Réutiliser les services framework avant d'implémenter (auth, users, sessions, ResourceService, i18n, middleware)
Si un service manque, l'étendre côté gitrust (wrappers, trait impls)

4.2 Assets

Zéro CDN — tous les CSS/JS servis depuis static/
La CSP du framework bloque les domaines externes

4.3 Gestion d'erreurs

GitrustError avec IntoResponse pour le mapping HTTP
Pas de .unwrap() / .expect() / panic!() / [index]
Errors utilisateur : messages génériques (pas de leak d'info interne)

4.4 Validation aux frontières

Valider les inputs utilisateur (formulaires, query params, headers)
Ne pas re-valider entre services internes
Newtypes avec validation à la construction (RepoSlug, TeamSlug, Fingerprint, TokenHash)

5. Checklist pré-merge

Avant chaque merge de lot :

cargo fmt --all -- --check passe
cargo clippy --workspace -- -D warnings passe
cargo test --workspace — tous les tests passent
Tests E2E Playwright passent (npm run test:e2e)
CSS rebuild si templates modifiés
Aucun secret en clair dans le code ou les logs
Checklist sécurité §2.2 validée (si applicable)
Pas de modification dans crates/rustwarden-core/

Eric / documentation