QA-Regeln und ANSSI-Konformität

Dieses Dokument definiert die Qualitäts- und Sicherheitsregeln, die für das gesamte Gitrust-Projekt gelten. Jeder Stapel muss diese Regeln vor dem Zusammenführen erfüllen.

1. Obligatorische Kompilierungsgates

Jede Änderung muss diese 4 Tore ohne Fehler passieren:

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

Zusätzliche Tore (zu installieren)

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. Sicherheitsregeln (ANSSI PA-074)

2.1 Obligatorische Rost-Lints (bereits vorhanden)

#![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 Sicherheitscheckliste nach Funktion

Überprüfen Sie vor jeder Implementierung, die sich auf Authentifizierung, Geheimnisse oder Berechtigungen auswirkt:

  • [ ] 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 SEC-Marker

Der Code verwendet „//SEC-XX“-Kommentare, um Sicherheitsentscheidungen zu verfolgen. Jedes neue Steuerelement muss mit der nächsten verfügbaren Nummer in seiner Kategorie gekennzeichnet werden:

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. Erforderliche Tests nach Kategorie

3.1 Abdeckungsmatrix

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 Testregeln

  1. Integrationstests auf echter Datenbank – keine Mocks für die Persistenzschicht (Mocks verbergen Migrationsfehler)
  2. Negative Tests erforderlich – testen Sie für jeden glücklichen Pfad mindestens: Eingabe ungültig, nicht authentifiziert, nicht autorisiert, abgelaufen, widerrufen
  3. E2E-Tests auf Französisch – im Einklang mit der Benutzeroberfläche (Gebietsschema „fr-FR“)
  4. Kein „sleep()“ in Tests – verwenden Sie Wiederholung/Abfrage mit Zeitüberschreitung
  5. Isolierte Testdaten – jeder Test erstellt seine eigenen Daten (keine Abhängigkeit von der Ausführungsreihenfolge)

4. Kodexregeln

4.1 Rahmengrenze

  • Niemals ändern crates/rustwarden-core/
  • Framework-Dienste vor der Implementierung wiederverwenden (Authentifizierung, Benutzer, Sitzungen, ResourceService, i18n, Middleware)
  • Wenn ein Dienst fehlt, erweitern Sie ihn auf der Gitrust-Seite (Wrapper, Impls-Funktion).

4.2 Vermögenswerte

  • Kein CDN – alle CSS/JS werden von „static/“ bereitgestellt
  • Framework CSP blockiert externe Domänen

4.3 Fehlerbehandlung

  • „GitrustError“ mit „IntoResponse“ für HTTP-Mapping
  • Kein .unwrap() / .expect() / panic!() / [index]
  • Benutzerfehler: allgemeine Nachrichten (kein internes Informationsleck)

4.4 Grenzvalidierung

  • Benutzereingaben validieren (Formulare, Abfrageparameter, Header)
  • Führen Sie keine erneute Validierung zwischen internen Diensten durch
  • Neue Typen mit Konstruktionsvalidierung („RepoSlug“, „TeamSlug“, „Fingerprint“, „TokenHash“)

5. Checkliste vor dem Zusammenschluss

Vor jeder Stapelzusammenführung:

  • [ ] 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/