Audit de sécurité

Notre page À propos indique que notre processus d'audit de sécurité est documenté. Voici le document : ce qui a été audité, ce qu'il a trouvé, et comment chaque constat a été clos.

Périmètre

En février 2026, Odysseus a fait l'objet d'un audit de sécurité interne formel multi-locataire couvrant 268 fichiers source Go et 383 fichiers TypeScript répartis sur 14 composants — le plan de contrôle, l'agent du nœud, le tableau de bord, et chaque sous-système qui touche les limites des locataires.

Ce qu'il a trouvé

Source : docs/core/07-security.md:11 et audit/EXECUTION_PLAN.md:4,6,15.

Comment cela a été corrigé

Les 184 constats ont tous été clos via un plan d'exécution maître unique, organisé en six vagues à jalons — Vague 0 (Urgence) à Vague 5 (Vérification) — chacune déverrouillant la suivante uniquement une fois son propre jalon validé. Le travail au sein d'une vague se déroule en parallèle entre les composants ; le travail entre les vagues est séquentiel, de sorte qu'un correctif de la Vague 3 ne pouvait pas commencer avant la validation du jalon de la Vague 2. Le plan est explicite : les constats des vagues ultérieures ne pouvaient pas être traités en avance, même par quelqu'un ayant du temps libre : « NE PAS lire en avance… et commencer à travailler sur des éléments de phases ultérieures qui appartiennent à une vague future » (audit/EXECUTION_PLAN.md:78).

Comment cela a été vérifié

Neuf suites de tests de sécurité dédiées exercencent la posture post-remédiation, chacune nommée d'après la classe de défaillance qu'elle protège :

Suite	Fichier
Contournement de l'authentification	pkg/api/auth_bypass_test.go
Vérification de conformité	pkg/api/compliance_verification_test.go
Isolation des conteneurs	pkg/api/container_isolation_test.go
Isolation inter-locataires	pkg/api/cross_tenant_isolation_test.go
Isolation de l'infrastructure	pkg/api/infrastructure_isolation_test.go
Isolement des locataires (général)	pkg/api/isolation_test.go
Régression de performance	pkg/api/performance_regression_test.go
Escalade de rôle	pkg/api/role_escalation_test.go
Isolement des locataires (portée API)	pkg/api/tenant_isolation_test.go

Des constats que vous pouvez retracer, pas seulement compter

Chaque constat porte un identifiant — CRIT-01, HIGH-04, et ainsi de suite, défini par composant — et cet identifiant apparaît à nouveau en commentaire sur la ligne qui le corrige, de sorte que l'affirmation « ceci a été corrigé » est vérifiable plutôt qu'assertée. Par exemple :

• pkg/vault/approle.go:2 — // SECURITY FIX (CRIT-02): Per-tenant AppRole management replaces the shared…
• pkg/vault/approle.go:25 — // SECURITY FIX (HIGH-04): Namespace enables per-tenant Vault namespace isolation.
• pkg/api/container_ops.go:227,304,341,390,436 — cinq sites d'appel distincts, chacun portant // SECURITY FIX (HIGH-02): Mandatory tenant ownership verification

Le plan d'exécution fait des renvois croisés avec ces mêmes identifiants entre les composants lorsqu'un correctif en dépend d'un autre — par exemple Consul CRIT-01 (remove legacy) -> Vault CRIT-03 (tenant paths) -> Vault CRIT-01 (API scoping) -> Agent CRIT-02 (tenant ownership) (audit/EXECUTION_PLAN.md:143-144) — de sorte que la chaîne de dépendances qui a motivé l'ordre des vagues fait elle-même partie du registre public, et non pas d'une affirmation que nous vous demandons de prendre sur parole.

État

Terminé. Les 184 résultats ont été corrigés à travers les six vagues ; chaque porte est fermée (audit/EXECUTION_PLAN.md:6). Il ne s'agit pas d'un effort de remédiation en cours que nous décrivons de manière optimiste — il est terminé, et ce que vous lisez est le dossier clos de celui-ci.

Pour ce que les contrôles résultants font au quotidien, voir Sécurité. Pour savoir comment la piste d'audit elle-même prouve qu'elle n'a pas été altérée après coup, voir Conformité.