Tout ce que fait Stateward, et comment l’utiliser

Stateward est une sécurité autonome pour tout votre code. Il analyse chaque changement pour les vulnérabilités, les dépendances risquées, les secrets exposés, les mauvaises configurations d’infrastructure et de conteneurs, les risques de licence et de fin de vie, et les défaillances propres au code écrit par IA. Il est conçu pour la façon dont le code s’écrit aujourd’hui : rapide, assistée par IA, et pleine d’interactions entre fichiers qu’un scanner de diff isolé ne voit pas.

1. 01

   Connectez un dépôt

   Installez Stateward comme une app sur GitHub ou GitLab et accordez un accès en lecture seule aux dépôts de votre choix. Aucun pipeline à reconstruire et rien à exécuter en CI.

2. 02

   Ouvrez une pull request

   Stateward analyse la prochaine pull request automatiquement et publie les findings en ligne, chacun avec une sévérité, une explication et, quand c’est possible, un correctif en un clic.

3. 03

   Ou analysez depuis le terminal ou votre IDE

   Créez une clé API dans la console, puis lancez l’analyseur en ligne de commande en CI ou appelez Stateward depuis un IDE agentique via l’intégration éditeur. Le même moteur, avant même qu’une PR existe.

4. 04

   Agir et bloquer

   Appliquez les correctifs proposés, triez ce que vous acceptez, exportez les preuves, et bloquez la CI sur un seuil de sévérité que vous contrôlez.

• App de l’hébergeur de code (GitHub, GitLab)

  La surface par défaut. Stateward s’installe en lecture seule, analyse chaque pull ou merge request en ligne, et publie un statut de check réussi ou échoué. Aucun changement de pipeline, aucun agent en CI.

• Console web

  Lancez des audits à la demande d’une branche, parcourez les findings par sévérité et par source, gérez dépôts et politique, suivez coût et usage, et administrez votre organisation.

• Analyseur en ligne de commande

  Analysez n’importe quel chemin depuis un terminal ou un job CI, écrivez du SARIF, et sortez en non-zéro au-dessus d’un seuil de sévérité pour faire échouer un build sur un vrai risque. Fonctionne aussi en hook de pre-commit.

• Intégration éditeur & agent (MCP)

  Les IDE agentiques comme Cursor et Claude Code peuvent appeler Stateward sur le code qu’ils génèrent, en ligne, avant qu’une pull request existe. Les vérifications déterministes rapides sont gratuites ; l’audit profond puise dans vos crédits.

• Blocage en CI

  Ajoutez une seule étape d’analyse dans GitHub Actions, GitLab CI, Azure Pipelines ou Jenkins. La sévérité de blocage se règle par dépôt dans la console, vous n’avez donc pas à la coder en dur dans chaque pipeline.

Une seule couche, toute la surface. Chaque classe ci-dessous s’exécute en contexte, mappée à un CWE, avec un correctif proposé quand il s’applique.

• Exposition de source maps

  Le détecteur de source maps de Stateward le signale dans la pull request, avant toute livraison : un artefact *.map commité, un //# sourceMappingURL= résiduel dans un bundle livré, et les configs de build qui émettent des maps de production sur Vite, webpack, Next.js, Create React App, Vue et Rollup. Il ignore les maps désactivées et les fichiers .d.ts.map, pour ne pas crier au loup.

• Bugs de logique & d’exactitude écrits par de vrais humains

  C’est pour cela que Stateward a été conçu. Son audit profond multi-agents adverse reformule ce que chaque fonction est censée garantir, ses invariants, puis attaque ces hypothèses comme le ferait un auditeur senior, sur tout le code. Il fait émerger les bugs d’exactitude et de sûreté qu’aucun scanner à signatures ne cherche : épuisement de plage, calculs monétaires en flottant, hypothèses d’ordre et de concurrence, invariants métier qui se brisent en silence.

• Secrets en dur & identifiants exposés

  Stateward scanne chaque diff au commit pour les formats de jetons connus et les chaînes à forte entropie, masque la valeur (il ne réaffiche ni ne stocke jamais un secret), et le signale avant qu’il n’atteigne une branche partagée. Avec la vérification activée, il teste en direct les clés GitHub, Stripe et Slack auprès du fournisseur et escalade une clé confirmée active en critique. Les findings suivent un état : une fuite corrigée reste close et se rouvre en cas de régression.

• Dépendances vulnérables & malveillantes

  Stateward vérifie chaque dépendance ajoutée ou modifiée contre les avis OSV.dev sur npm, PyPI, crates.io, Maven, Go, RubyGems, Composer et NuGet, et, avec la base de connaissances activée, vous dit si le code vulnérable est réellement atteignable, pas seulement présent dans le lockfile. Il signale aussi les runtimes en fin de vie (Node, Python, …) qui ne reçoivent plus de correctifs, et exporte un SBOM CycloneDX ainsi qu’un VEX indiquant quelles CVE sont réellement exploitables.

• Typosquatting & paquets « slopsquattés »

  Le moteur supply-chain de Stateward signale les noms à distance de typo d’un paquet populaire, les paquets inexistants sur le registre (hallucinés/slopsquattés) et les sources hors-registre (git+, file:, http:), puis analyse le comportement publié de chaque paquet ajouté : hooks install/postinstall qui exécutent du code réseau/exec/obfusqué, ou du code d’installation sans dépôt source, la forme de malware par confusion de dépendances que les bases de CVE manquent.

• Mauvaise configuration de l’infrastructure-as-code

  Stateward analyse les lignes Terraform et Kubernetes ajoutées pour l’ingress ouvert, les ressources et ACL publiques, l’absence de chiffrement, les jokers IAM, l’absence de logs et les conteneurs privilégiés / en réseau hôte, léger en dépendances, limité au diff, dans la pull request.

• Images de conteneurs non sécurisées

  Stateward signale les images de base :latest/non taguées, l’exécution en root, les ADD distants, les secrets-en-couche, les pipe-to-shell et les téléchargements non sécurisés sur les lignes de Dockerfile qu’une PR ajoute, et analyse l’image de base elle-même pour les CVE connues afin qu’un paquet OS vulnérable soit attrapé avant la mise en production.

• Attaques de pipeline CI/CD

  Le moteur CI/CD de Stateward inspecte GitHub Actions et GitLab CI pour l’injection de script, les références mutables, les permissions trop larges et les secrets-en-run, à chaque modification de vos fichiers de pipeline.

• Risque de licence copyleft & source-available

  Stateward signale les licences copyleft et source-available à deux endroits : votre propre code (identifiant SPDX, champ license de manifeste ou fichier LICENSE, limité au contexte de déclaration, attentif aux limites de mots pour que LGPL ≠ GPL) et, la partie que les équipes oublient, les licences de chaque dépendance ajoutée, résolues depuis le registre et vérifiées contre une politique de licences par dépôt que vous contrôlez (refus AGPL/GPL/SSPL/BUSL par défaut). Un seul endroit pour garder tout le patrimoine légalement propre ; les licences alimentent aussi le SBOM.

• Code généré par IA non sécurisé

  Stateward cible spécifiquement les schémas de défaillance du code écrit par IA, avec des packs de revue adverse par langage et des vérifications spécifiques à l’IA pour les dépendances hallucinées, les défauts trop permissifs et les surfaces d’injection de prompt, la catégorie que tous les acteurs établis ont manquée.

• Vulnérabilités inter-fichiers qu’un scanner de diff ne voit pas

  Stateward construit une base de connaissances de votre code, graphe d’appels, frontières de confiance, atteignabilité des dépendances, et audite la tranche atteignable du changement, faisant apparaître le chemin inter-fichiers que le diff cache.

Choisissez un langage pour voir ce que Stateward y vérifie, les écosystèmes de paquets qu’il résout, et sa couverture runtime. Pour la matrice complète des langages, écosystèmes et détecteurs, voir la page de couverture.

Monorepos

Un dépôt avec plusieurs écosystèmes est découpé par dossier : chaque projet est détecté via son manifeste, audité pour lui-même avec l’analyse adaptée à sa stack, puis agrégé en un rapport unique.

• Sévérité et mapping

  Chaque finding porte une sévérité et est mappé à CWE, OWASP et aux cadres de conformité que vous suivez, pour s’intégrer directement au reporting.

• Provenance

  Chaque finding indique son origine : un analyseur déterministe, une règle déterministe, ou un agent IA adverse. Vous savez toujours si un résultat est mécanique ou raisonné.

• Priorisation par atteignabilité

  Une dépendance vulnérable ne compte que si votre code l’utilise réellement. Stateward rétrograde les problèmes des paquets déclarés mais non utilisés, pour que la liste reflète l’exposition réelle, pas la présence dans le lockfile.

• Corrélation et regroupement

  Les résultats liés (le même paquet sur plusieurs fichiers, ou une même chaîne d’exploitation) sont regroupés en un seul élément, pour trier la cause racine une fois plutôt que d’écluser un mur de doublons.

• Convergence et confiance

  Un même problème trouvé par plusieurs analyseurs indépendants est dédupliqué en un seul résultat et gagne en confiance. Les findings sont validés avant d’arriver chez vous, pas après.

• Correctif vérifié en un clic

  Quand un correctif est mécanique, Stateward propose le changement et peut ouvrir une pull request en brouillon sur une branche dédiée. Avant cette ouverture, Stateward relance l’analyse sur le fichier corrigé et refuse de l’ouvrir si le problème persiste ou si un nouveau high ou critical apparaît. Il ne pousse jamais ni ne merge vos branches.

• Triage et suppression

  Rejetez un finding ou acceptez un motif, et Stateward le respecte lors des revues suivantes. Les findings suivent un état : un problème corrigé reste clos et ne se rouvre qu’en cas de régression.

IDE agentiques (Cursor, Claude Code)

Ajoutez l’intégration éditeur et votre agent peut analyser le code à mesure qu’il l’écrit. Elle expose :

• scan_file Analyser un fichier que vous venez d’écrire, rapide et gratuit
• scan_diff Analyser un ensemble de fichiers modifiés comme une pull request
• audit Lancer l’audit profond de tout le code (utilise des crédits)

{
  "mcpServers": {
    "stateward": {
      "command": "npx",
      "args": ["-y", "@stateward/mcp"],
      "env": { "STATEWARD_API_KEY": "swu_your_key" }
    }
  }
}

Ligne de commande et CI

Analysez un chemin, écrivez du SARIF, et faites échouer le build au-dessus d’une sévérité de votre choix. La sévérité de blocage peut aussi se régler par dépôt pour garder des pipelines simples.

# scan a path, fail the build above "high", write SARIF
npx @stateward/cli scan . --min high --sarif stateward.sarif

• Clés fines et expirables

  Les clés API sont limitées au moindre privilège, peuvent expirer, et affichent leur dernière utilisation. Une clé d’intégration continue limitée à l’analyse ne peut pas toucher la facturation ni l’administration.

• Clés personnelles et de service

  Les clés personnelles appartiennent à un utilisateur ; les clés de service appartiennent à l’organisation et continuent de fonctionner après le départ d’un membre, ce qui convient aux pipelines partagés.

• Rôles

  Les membres peuvent lancer des audits et voir les findings. Les admins voient en plus les analyses de l’organisation et gèrent membres, projets et politique. Les propriétaires contrôlent la facturation et l’organisation. Une capacité de facturation peut être accordée à un admin précis.

• Authentification unique par domaine

  Définissez un domaine d’email pour votre organisation et les inscriptions correspondantes la rejoignent automatiquement comme membres. SAML et SCIM sont disponibles sur demande.

Réglez Stateward par dépôt, depuis la console ou un fichier de politique versionné.

• SARIF

  Exportez les findings en SARIF pour les charger dans l’onglet sécurité de votre hébergeur de code ou tout outil compatible SARIF.

• Nomenclature logicielle (SBOM)

  Téléchargez un SBOM CycloneDX des dépendances d’un dépôt, incluant la licence de chaque composant.

• Échange d’exploitabilité (VEX)

  Un document VEX indique quelles vulnérabilités connues sont réellement exploitables dans votre code, à partir du verdict d’atteignabilité, pour que les consommateurs en aval sachent quelles CVE comptent vraiment.

• Rapport de conformité

  Exportez un rapport prêt pour l’audit des findings mappés aux contrôles, prêt à imprimer en PDF.

• Lien de posture partageable

  Créez une page de posture publique en lecture seule qu’un acheteur peut remettre à son auditeur. Elle montre la posture, le temps moyen de remédiation et la couverture des cadres, sans exposer ni code source ni identifiants. Révocable à tout moment.

Envoyez un nouveau finding critique vers Slack, ou ouvrez un ticket dans Jira ou Linear, depuis les réglages de l’organisation. Les secrets restent côté serveur et ne sont jamais réaffichés au navigateur.

• Lecture seule et éphémère. Stateward lit le code pour l’analyser et commente en retour. Il ne pousse jamais, ne merge jamais, et stocke des métadonnées, pas votre source.
• Hébergement souverain dans l’UE. Le code et les données de sécurité sont hébergés dans l’UE avec résidence des données dans l’UE sur l’infrastructure Citadea.
• Prêt pour l’audit et traçable. Les findings se mappent à OWASP, CWE, SOC 2, ISO 27001, NIS2, DORA et au Cyber Resilience Act de l’UE. Un journal d’accès enregistre qui a consulté les analyses, et vous pouvez effacer toutes les données de l’organisation sur demande.

Plus sur les cadres et les preuves sur la page conformité.

C’est la section la plus profonde. Elle décrit comment Stateward raisonne, par capacité et résultat. Nous gardons les mécanismes exacts privés, comme un motoriste ne livre pas ses plans.

• Classer, puis appliquer la bonne analyse

  Stateward détecte les langages et domaines d’un changement (par exemple backend web, frontend web, infrastructure cloud, smart contract, intégration IA, chaîne d’approvisionnement de dépendances, et code système critique pour la sûreté mémoire) et applique l’analyse adaptée à chacun, enrichie de vérifications conscientes du framework et propres au langage. Dans un monorepo, il détecte chaque projet via son manifeste et audite chacun pour lui-même. Vous ne configurez pas d’analyseurs par langage ; les bonnes vérifications s’exécutent parce que le code a d’abord été compris.

• Couche déterministe plus agents adverses

  Une couche d’analyseurs déterministes rapides s’exécute sur chaque changement et chaque plan, et des agents IA adverses raisonnent sur les risques nouveaux et transverses que la couche déterministe ne peut pas traiter. Les deux passent par un même pipeline de validation, donc un résultat est confirmé avant que vous le voyiez.

• Une base de connaissances vivante

  Stateward entretient sa propre connaissance : un historique de vulnérabilités, des cas réels curatés, et une connaissance des paquets, versions et licences continuellement mise à jour. Nous l’utilisons à la fois pour trouver les problèmes plus vite et pour supprimer les faux positifs qui poussent les équipes à couper un outil.

• Contexte de tout le code

  Stateward construit un modèle de votre dépôt : comment les modules se connectent, quelles entrées sont contrôlées par un attaquant, et si une fonction risquée est réellement atteignable. C’est ce qui lui permet de voir les défauts qui vivent entre fichiers, pas sur une seule ligne.

• Raisonnement induit par merge et inter-branches

  Les défauts les plus difficiles n’apparaissent que lorsque deux changements se rencontrent. La branche A et la branche B peuvent être sûres séparément, et pourtant fusionner les deux dans une branche partagée crée une nouvelle vulnérabilité. Stateward raisonne sur cette image combinée. Cette analyse inter-contexte et consciente des branches est ce que personne d’autre ne fait bien.

• Mémoire de projet durable et évolutive

  Ce modèle est mémorisé entre les exécutions et tenu à jour à mesure que le code change, par projet, par dossier dans un monorepo, et par branche. Stateward enregistre ce qu’il apprend : la forme du projet, ses flux de données, ses dépendances et l’intention derrière elles. Ainsi une nouvelle pull request est revue à la lumière de ce que nous savons déjà, sans relire tout le dépôt, et quand une branche est fusionnée sa connaissance est intégrée à la cible. La mémoire ne retient que la structure et des observations, jamais votre code source, et tout projet peut s’y soustraire.

• Dépendances suivies dans le temps

  Parce que le modèle sait quel paquet chaque partie de votre code utilise et ce que ceux-ci entraînent de façon transitive, une dépendance devenue vulnérable après sa mise en production est rattachée au composant exact et aux fichiers qui l’utilisent, et signalée à temps, via les canaux que vous choisissez. Une vulnérabilité au fond de l’arbre de dépendances est nommée avec la dépendance directe qui l’a introduite.