Security capability experiment
Analyse statique pour le code généré par l'IA
A Rust static-analysis tool focused on AI-generated and AI-application code patterns. It combines tree-sitter parsing, source-controlled rules, SARIF output, command-line and editor surfaces, and optional model-assisted triage.
Pont métier ↔ technologie · Security capability experiment
Explores deterministic security analysis for AI-generated and AI-application code.
Il s'agit d'une interprétation du portefeuille et des sources, et non d'une affirmation de client, déploiement, certification ou résultat.
AI-assisted development can increase code volume and repeat insecure patterns faster than conventional review capacity grows.
Keep deterministic parsing and source-controlled rules primary, with model-assisted triage optional and explicitly separate.
Rust crates, tree-sitter parsers, YAML rules, SARIF output, CLI, LSP, CI integration, and selected fixtures.
Findings and unresolved uncertainty return to remediation priority, release criteria, security review, and engineering policy.
Preuves issues du code source
A Rust static-analysis tool focused on AI-generated and AI-application code patterns. It combines tree-sitter parsing, source-controlled rules, SARIF output, command-line and editor surfaces, and optional model-assisted triage.
Le relevé technique détaillé est maintenu en anglais.
Les preuves du dépôt ne constituent pas des preuves client, de déploiement, de certification ou de résultats.
Architecture
Trois couches : intégration CLI et CI, un scanner AST de 210 règles pour certains motifs propres au code généré par IA et aux applications d'IA, et un triage optionnel assisté par modèle qui peut aider à classer les résultats. Aucune ne remplace une revue de sécurité.
Carte des sources uniquement : une couche peut représenter du code implémenté, une frontière d'adaptateur ou une conception documentée. Elle n'affirme pas l'existence d'un service de production configuré.
Les interfaces Rust en ligne de commande, LSP, CI et SARIF servent aux analyses locales et aux analyses dans le flux de revue. Aucun environnement d'exécution universel ni aucune performance à grande échelle ne sont revendiqués.
Scanners AST pour Python, TypeScript, JavaScript, Go. Cinq catégories de règles : patterns de vibe coding, sécurité des agents (définitions d'outils, prolifération des capacités), risques des applications LLM (injection de prompt, sortie non assainie), vulnérabilités des frameworks, mauvaises configurations cloud. Les scanners généralistes et ces règles ne couvrent pas les mêmes surfaces.
Un triage optionnel avec un modèle Mistral, local ou hébergé, peut aider à écarter les faux positifs probables et à reclasser les résultats selon le contexte. Il ne s'exécute que s'il est activé et ne remplace pas une revue de sécurité.
Le problème
Pourquoi le code généré par l'IA est un risque de sécurité
Les assistants IA génèrent du code plus rapidement que les humains ne peuvent le relire. Le vibe coding -- accepter les suggestions de l'IA avec un examen minimal -- est devenu la norme.
L'IA optimisé pour du code fonctionnel, pas pour du code sécurisé. Le même secret en dur, la même concatenation SQL, le même CORS permissif -- repetes dans des milliers de projets.
Les scanners généralistes et les règles centrées sur l'IA ne couvrent pas les mêmes surfaces. Les modèles de prompts, les outils d'agents et le traitement des sorties de modèle gagnent à recevoir des contrôles dédiés, en complément du SAST existant.
Les agents peuvent recevoir des capacités sur les fichiers, les bases de données, le réseau ou le shell. Leurs limites de permissions et les entrées de leurs outils demandent une revue qui va au-delà des contrôles habituels du code applicatif.
Regles
210 regles ciblant cinq domaines de vulnérabilités spécifiques à l'IA
Périmètre source uniquement : une entrée peut décrire du code implémenté, un adaptateur documenté ou un workflow configuré. Elle n'indique pas qu'un service de production est actif.
01
40 regles pour les schemas couramment générés par les assistants de codage IA : secrets en dur dans les prompts, injection SQL par concatenation, exécution de code dangereuse, parametres par défaut non securises, authentification manquante, traversee de chemin, deserialisation non sécurisée et cryptographie faible.
02
30 regles pour le code des agents autonomes : définitions d'outils trop permissives, accès illimite au système de fichiers, exécution de commandes shell à partir d'entrées utilisateur, journalisation d'audit manquante, absence de confirmation avant les actions destructrices, communication inter-agents non sécurisée et vecteurs d'escalade de privileges.
03
40 regles pour les applications LLM en production : entrées utilisateur brutes dans les prompts système, rendu HTML non assaini, exécution de SQL généré par le LLM, clés d'API exposées, détection d'injection de prompts manquante, flux OAuth non securises, utilisation de SDK obsoletes, sorties d'outils non validees et risques d'exfiltration de données d'entraînement.
04
50 regles couvrant 10 frameworks : Express.js, Django, Flask, FastAPI, Spring Boot, Laravel, Rails, Next.js, NestJS et Gin -- couvrant l'exposition du mode debug, les gardes d'authentification manquants, les CORS en joker, l'assignation de masse, les DTOs non valides et les fuites des endpoints actuator.
05
50 regles couvrant 7 plateformes : AWS (15), Terraform (10), Kubernetes (6), GitHub Actions (5), GCP (5), Azure (5), Docker (4) -- couvrant les surpermissions IAM, les buckets publics, le chiffrement desactive, les conteneurs privilegies, les Actions non epinglees et les groupes de sécurité mal configures.
06
Ecrivez des regles personnalisées en YAML -- aucune connaissance de Rust requise. Definissez des types de noeuds AST, des schemas regex, des contraintes de contexte ancetre et des suggestions de correction. Generez de nouvelles regles avec une seule commande.
07
Sortie native SARIF v2.1.0 pour l'intégration avec l'onglet Sécurité de GitHub. Les résultats apparaissent sous forme d'annotations en ligne sur les PR avec severite, suggestions de correction et références. Prend aussi en charge les formats JSON et texte.
08
Un triage optionnel avec Mistral AI ou des modèles Ollama locaux peut aider à écarter les faux positifs probables, à reclasser les résultats selon le contexte et à proposer des corrections. Il s'active avec le flag --ai et ne remplace pas une revue de sécurité.
09
Une interface LSP fournit des diagnostics et certaines actions de code aux éditeurs compatibles. Le comportement dans l'éditeur et la couverture des règles sont à valider dans le flux de travail visé.
10
Le dépôt contient une GitHub Action et un chemin d'intégration en ligne de commande pour la CI. Les autres intégrations de pipeline demandent une configuration et une validation par l'exploitant.
210 règles réparties en 5 catégories
Des règles déterministes repèrent certains patterns propres aux applications d'IA ; un triage optionnel assisté par modèle peut aider à classer les résultats, mais aucune des deux voies ne remplace une revue de sécurité.
Surface du dépôt uniquement : disponibilité, exhaustivité, performance et aptitude opérationnelle exigent une validation distincte.
Clés API codées en dur dans les templates de prompts, SQL via concaténation de chaînes dans les chemins de code 'juste pour la démo,' désérialisation non sécurisée, évaluation de la sortie LLM, secrets logués en niveau INFO. L'ensemble des patterns qui sont livrés quand 'ça marche une fois' l'emporte sur 'ça marche en toute sécurité.'
Définitions d'outils sans validation des paramètres, capacités d'agent qui chevauchent les privilèges admin, absence de limites de débit sur les outils appelables par LLM, préfixes de prompts qui divulguent l'identité du système. L'ensemble qui permet à un jailbreak de se transformer en incident.
Sortie LLM non assainie rendue en HTML, vecteurs d'injection de prompt dans un contexte contrôlé par l'utilisateur, injection indirecte via des documents récupérés, sortie du modèle redirigée vers un shell ou eval, absence de validation du schéma de sortie. L'OWASP-LLM-Top-10 concrétisé.
Exposition de Next.js Server Action sans authentification, contournement de l'injection de dépendances FastAPI, fuite de la chaîne de pensée LangChain, injection SQL via raw() dans Django ORM, rendu de template non sécurisé. Règles spécifiques à chaque framework, pas un suivi de taint générique.
S3 publics avec des préfixes sensibles, rôles IAM avec des actions `*`, permissions cross-account AWS Bedrock, GCP Vertex AI exposé dans un contexte sans compte de service. L'ensemble qui permet à une URL de point de terminaison divulguée de se transformer en exfiltration complète de données.
Technologies
Les technologies citées identifient des dépendances ou des adaptateurs du dépôt ; elles n'affirment ni intégration active ni déploiement.
Code source
Le code source de Achilles AI est disponible sur demande à des fins d'évaluation et de partenariat.
Pour acceder au code source, veuillez signer notre accord de non-divulgation.
Besoin d'aide pour sécuriser du code généré par IA en production ? Nos services de conseil complètent Achilles AI.
Douze à vingt-quatre semaines pour classifier vos systèmes IA par risque, accompagner l'évaluation de conformité pilotée par le fournisseur et constituer les preuves, produire la documentation technique Annexe IV et mettre en place la surveillance post-commercialisation — avec une profondeur particulière sur les catégories à haut risque qui s'appliquent aux déploiements autonomes, industriels et robotiques
Partenariat
Que vous ayez besoin d'un audit de sécurité du code IA pour votre équipe ou que vous souhaitiez explorer un partenariat dans le domaine de l'AppSec.
De la démo à une exploitation fiable. Abonnez-vous pour recevoir de nouvelles lectures sur la Physical AI.
Désabonnez-vous à tout moment. Pas de spam, jamais.