Cette page est traduite de la documentation anglaise. Les commandes, identifiants et exemples sont inchangés. Runtime 7.24.4 · SDK 2.6.7. Source anglaise

Politique de sécurité

Versions prises en charge

Seule la dernière ligne de version mineure reçoit les correctifs de sécurité. Passez à la mineure en cours avant de signaler une vulnérabilité contre une ligne plus ancienne.

Signaler une vulnérabilité

Nous prenons la sécurité au sérieux. Si vous découvrez une vulnérabilité, signalez-la de façon responsable :

1. Contact privé : utilisez le canal de contact AutomatosX pour demander une voie confidentielle de signalement. N’incluez ni détails d’exploitation ni identifiants dans les messages publics de la communauté.
2. Discord : signalez-la sur notre Discord : https://discord.gg/gf9UyPxaN2

Nous accuserons réception de votre signalement sous 6 jours ouvrés et vous tiendrons informé de l’avancement vers un correctif.

Remarque : nous n’acceptons pas les rapports de sécurité générés par une IA. En soumettre un entraîne un bannissement du projet. Veillez à ce que votre rapport contienne des étapes de reproduction précises et démontre un impact réel.

Modèle de menace

Vue d'ensemble

ax-code est un assistant de programmation fondé sur l’IA, qui s’exécute localement sur votre machine. Il fournit un système d’agents ayant accès à des outils puissants, dont l’exécution de shell, les opérations sur les fichiers et l’accès au Web.

Le défaut d’isolation du runtime est full-access (bac à sable désactivé), avec des écritures illimitées sur le système de fichiers et un accès au réseau. C’est une posture de commodité pour des projets locaux de confiance, pas une frontière de sécurité. Choisissez workspace-write ou read-only avant d’utiliser AX Code avec des dépôts non fiables ou des charges sans surveillance.

Bac à sable d'isolation de l'exécution

ax-code inclut un bac à sable d’isolation de l’exécution qui restreint ce à quoi l’agent peut accéder. Trois modes sont disponibles :

Propriétés essentielles :

• Comportement par défaut — AX Code démarre en full-access, sauf si --sandbox, AX_CODE_ISOLATION_MODE ou la configuration définit un autre mode
• Mode restreint recommandé — utilisez workspace-write pour les dépôts non fiables ou d’équipe ; il confine les écritures à l’espace de travail et désactive le réseau par défaut
• Application au niveau des outils — tous les outils de mutation (bash, edit, write, apply_patch) et les outils réseau (webfetch, websearch, codesearch) vérifient la politique d’isolation avant de s’exécuter
• Chemins protégés — les répertoires .git et .ax-code sont toujours protégés contre l’écriture, même en mode écriture dans l’espace de travail
• Invites d’escalade — dans les modes restreints, une violation d’isolation ouvre une boîte d’approbation au lieu d’échouer en silence ; l’utilisateur peut autoriser une fois l’opération bloquée sans changer sa configuration
• Contrôle par la CLI — --sandbox read-only, --sandbox workspace-write, --sandbox full-access
• Variable d’environnement — AX_CODE_ISOLATION_MODE

Backends d'isolation

{
  "isolation": {
    "mode": "workspace-write",
    "network": false,
    "backend": "auto"
  }
}

Ou définissez AX_CODE_ISOLATION_BACKEND=os|auto|app.

L’isolation du système pour bash refuse les écritures hors des racines de l’espace de travail et refuse le réseau lorsque network: false. Les contrôles de la couche applicative s’exécutent toujours. Sur les plateformes sans Seatbelt ni bubblewrap, utilisez backend: "app", ou un conteneur ou une machine virtuelle.

Sécurité du serveur

• Localhost seulement par défaut — le serveur s’attache à 127.0.0.1 et reste inaccessible depuis le réseau
• Mot de passe exigé pour l’accès réseau — s’attacher à 0.0.0.0 ou à toute adresse autre que localhost exige que AX_CODE_SERVER_PASSWORD soit défini ; le serveur refuse de démarrer sans cela
• Authentification de base imposée — lorsque AX_CODE_SERVER_PASSWORD est défini, l’authentification HTTP Basic est exigée sur tous les points d’API
• CORS configurable — des origines supplémentaires autorisées peuvent être indiquées via --cors

Stockage des identifiants

Les clés d’API des fournisseurs sont chiffrées au repos en AES-256-GCM, avec une dérivation de clé PBKDF2, et stockées dans le répertoire de données local d’AX Code (~/.local/share/ax-code/) avec des permissions de fichier réservées à l’utilisateur (0600).

La clé de chiffrement est dérivée d’attributs de la machine locale (nom d’hôte, plateforme, architecture). Cela protège contre une divulgation hors ligne occasionnelle (par exemple un partage de fichier accidentel), mais cela ne protège pas contre un attaquant déterminé qui a accès à l’hôte. Ce n’est pas équivalent à un trousseau du système ni à un stockage de secrets adossé au matériel.

Les jetons OAuth de MCP, les secrets client et les jetons d’accès ou de renouvellement de compte sont aussi chiffrés au repos par le même mécanisme. Les métadonnées non sensibles (URL des serveurs, horodatages d’expiration, adresse e-mail, identifiants de compte) restent en clair.

Vérification des artefacts de version

L’installateur Bash (install) et l’installateur PowerShell de Windows (install.ps1) vérifient avec Minisign les archives de version GitHub téléchargées, avant l’extraction. Les archives de version et le script d’installateur PowerShell lui-même portent des signatures détachées. La clé publique de version AX Code épinglée est :

RWSlDu++afxCz01OqhYWhfo8+L8pVbSYXJBEb2zoWBuK0WACIzbGVZRO

Chaque installateur télécharge l’artefact .minisig qui correspond à l’archive choisie et échoue en position fermée si la vérification échoue. Si minisign n’est pas déjà dans PATH, les installateurs téléchargent les archives officielles Minisign 0.12 épinglées depuis https://download.ax-code.com/vendor/minisign/0.12/, contrôlent le SHA-256 de l’archive, puis contrôlent de nouveau l’exécutable extrait avant de le mettre en cache. Un binaire minisign déjà dans PATH est l’outil de l’opérateur et n’est pas rehaché. Ne définissez AX_CODE_SKIP_MINISIGN_VERIFY=1 que lorsque vous acceptez volontairement un téléchargement de version invérifiable.

La ligne de commodité irm …/install.ps1 | iex ne vérifie pas le script d’installateur avant l’exécution. Pour une installation sensible, téléchargez install.ps1 et install.ps1.minisig, vérifiez le script avec Minisign, puis exécutez-le localement (voir Canaux d’installation et de runtime).

Les mainteneurs doivent conserver la clé secrète Minisign chiffrée. Pour signer une version en local sur macOS, stockez la phrase secrète dans le Trousseau plutôt que dans un fichier en clair :

security add-generic-password -U -a ax-release -s ax-minisign -w

L’outillage de version lit automatiquement cette entrée du Trousseau lorsque AX_CODE_MINISIGN_PASSWORD n’est pas défini.

Le flux de publication GitHub piloté par étiquette signe les archives avant l’envoi. Il exige ces secrets de dépôt :

AX_CODE_MINISIGN_SECRET_KEY_B64
AX_CODE_MINISIGN_PASSWORD

AX_CODE_MINISIGN_SECRET_KEY_B64 doit être le contenu, encodé en base64, de la clé secrète Minisign chiffrée ax.minisign.key (le chemin local peut être un lien symbolique vers ax.sec). Le flux l’écrit dans un fichier de clé temporaire 0600, vérifie la clé publique épinglée, signe chaque archive de version et envoie les artefacts .minisig correspondants avec les archives.

Pour les archives CLI macOS, le flux exige et importe le certificat Apple Developer ID au moyen de ces secrets de dépôt :

APPLE_CERTIFICATE
APPLE_CERTIFICATE_PASSWORD
APPLE_TEAM_ID
APPLE_API_KEY_B64
APPLE_API_KEY_ID
APPLE_API_ISSUER

Dans ce chemin, les bibliothèques natives empaquetées sont signées avec l’identité Developer ID Application importée, le ZIP macOS est soumis au service de notarisation d’Apple, puis le ZIP inchangé est protégé par la signature Minisign détachée. Les archives ZIP ne peuvent pas être agrafées : la notarisation doit donc avoir lieu avant l’envoi de l’artefact et avant la génération de .minisig. Les constructions de version échouent en position fermée si une donnée d’identification de signature ou de notarisation Apple manque.

Historique des clés de signature des versions

La clé de signature des versions a été tournée pour la dernière fois le 2026-07-19. L’installateur et le flux de publication n’épinglent que la clé actuelle : les archives signées avec une clé retirée échouent donc à la vérification. Après une rotation, les mainteneurs doivent signer de nouveau les archives de versions historiques avec script/resign-release-assets.ts, afin que chaque version publiée se vérifie avec la clé épinglée, sans faire confiance aux clés retirées.

Pour signer de nouveau et renvoyer les artefacts .minisig d’une version existante avec la clé actuelle :

tsx script/resign-release-assets.ts --tag v5.5.0 --key-dir ~/signkey

Périmètre

Dans le périmètre

Hors périmètre

Capacités de sécurité pour l'entreprise

AX Code est conçu pour l’entreprise, avec les mesures de durcissement suivantes :

• Permissions fines : jeux de règles propres à l’agent et fondés sur des motifs (allow/deny/ask). L’agent de sécurité est en lecture seule par défaut. Les règles sont évaluées au niveau du projet, de l’agent et des listes approuvées.
• Pistes d’audit de session : chaque appel d’outil, chaque décision de permission et chaque changement de fichier est enregistré dans SQLite, avec des instantanés. La relecture, le fork et l’export sont pris en charge pour les revues de conformité.
• Refactorisation déterministe (DRE) : impact_analyze, refactor_plan et refactor_apply (worktree fantôme, plus lint, vérification de types et tests) fournissent des changements auditables et réversibles.
• Gestion des identifiants : chiffrement AES-256-GCM de toutes les clés et de tous les jetons. Isolation par répertoire via InstanceState.
• Application du bac à sable sur choix explicite : isolation applicative avec analyse des commandes bash (tree-sitter). Choisissez workspace-write ou read-only pour faire respecter les frontières du bac à sable ; les chemins protégés (.git, .ax-code) s’appliquent dans les modes sous bac à sable.
• Durcissement du serveur : localhost seulement par défaut ; accès distant protégé par mot de passe, avec authentification Basic.
• Intelligence et analyse du code : détection intégrée des secrets et des valeurs en dur, analyse d’impact des dépendances.

Retour de programmation assisté par CodeQL

Le dépôt exécute CodeQL comme couche d’analyse de sécurité en arrière-plan pour les demandes de fusion, les poussées vers dev, les analyses planifiées et les lancements manuels. CodeQL ne fait pas partie du chemin LSP en direct ni de l’intelligence de code ; c’est une source de preuves plus lente et plus profonde pour les constats de flux de données, de taint et de qualité de sécurité, qu’il vaut mieux traiter une fois les changements de sources stabilisés.

Le flux actuel analyse :

• Le code de runtime JavaScript et TypeScript, ainsi que le TUI, le SDK, l’intégration et les scripts.
• Les flux GitHub Actions et les actions composites locales.
• Les crates Rust sous crates/, avec une construction Cargo manuelle, afin que le code de l’extension native et du TUI soit extrait de façon cohérente.

L’expérience prévue pour les développeurs est la suivante :

1. Les auteurs de demandes de fusion reçoivent les alertes CodeQL dans l’analyse de code GitHub, à côté de la vérification de types, des tests déterministes, de l’analyse de dépendances OSV et des gardes de structure du dépôt.
2. Les mainteneurs trient les premiers résultats avant de faire de CodeQL une barrière de fusion stricte, afin que les nouveaux constats soient utiles plutôt que bruités.
3. Les futurs flux de revue et de débogage d’AX Code pourront ingérer le SARIF CodeQL ou les alertes d’analyse de code GitHub comme preuves de sécurité explicites, avec des champs de provenance tels que source: "codeql", l’identifiant de règle, la gravité, le fichier, la ligne, la trace de flux de données et le SHA du commit analysé.
4. Les preuves CodeQL doivent apparaître à côté du security_scan local, de hardcode_scan, des diagnostics LSP et de l’analyse d’impact appuyée sur le graphe, et non comme un remplacement caché de l’un d’eux.

Lorsque vous ajoutez des requêtes CodeQL personnalisées, préférez les frontières de sécurité propres au dépôt aux contrôles larges de style lint. Les cibles à forte valeur comprennent les chemins d’évasion du bac à sable, l’exécution de commandes avec des arguments non assainis, la traversée de chemin autour du confinement de l’espace de travail, la propagation de secrets ou d’environnement vers les processus enfants, et l’absence de validation des routes du serveur.

Pour une gouvernance d’entreprise complète (RBAC, politique comme code, export SIEM, audit cryptographique), intégrez AX Trust (élément de feuille de route).

Voir docs/guides/sandbox.md pour la configuration de l’isolation et le comportement à l’exécution.