DETECTIONcis-aws-2.1.5 · block-public-access
Premiers design partners · AWS · Azure · GCP

Les outils d'audit signalent le problème.
NIMBUS envoie le correctif.

Chaque audit vous laisse une liste de dizaines de lignes. Personne n'a le temps de les traiter. NIMBUS écrit le correctif et vous l'envoie en pull request Terraform, avec son plan et son retour arrière. Vous relisez. Vous mergez. Ou pas.

Devenir design partnerCréer un compteComment ça marche
  • Il ne peut rien casser
    Rôle en lecture seule. Il regarde, il n'écrit pas.
  • Vous gardez la main
    Chaque correctif est une pull request. Rien ne part sans votre merge.
  • Tout s'annule
    Un revert, comme n'importe quel commit. Si ça régresse, il ouvre la PR lui-même.
Open#142fix(s3): enable block-public-access on prod buckets (CIS 2.1.5)
nimbus-bot a ouvert cette PR — fix/cis-2-1-5-s3-public-access→main
propose-only · généré par IA (NIMBUS) — revue humaine requise
modules/s3/main.tf
+2-2
resource "aws_s3_bucket_public_access_block" "prod" {
block_public_acls = false
block_public_acls = true
restrict_public_buckets = false
restrict_public_buckets = true
}
Tous les checks sont passés
terraform plan3 to change, 0 to destroy
sandbox applyapply réussi
steady-state checkspassés
blast radius3 buckets · sans downtime
Revert par PR
block-public-access · ledger par fix-typerung: auto-pr
6 / 6 merges propres · 0 rollback · encore 4 → éligible auto-merge (opt-in)
COVERAGE247 aws / 203 azure / 162 gcp

Des contrôles réellement exécutés, pas des cases à cocher. Plus les dépenses inutiles. Sur un compte réel, un seul passage remonte des dizaines de problèmes.

0
Répartition des contrôles
  • AWS247
  • AZURE203
  • GCP162
Ce qu'on a mesuré, et sur quoi
  • 89 %
    8 correctifs sur 9
    banc public : le correctif fait-il ce qu'il annonce
  • −49 %
    un rejeu sur facture réelle
    économie recalculée sur une vraie facture
  • 1
    boucle complète en production
    détection → pull request → merge → nouvelle vérification
THE LOOPsrc/automation/orchestrator.ts
La boucle

Détecter. Corriger. Gagner en autonomie.

Trois étapes. Aucun outil d'audit ne fait la deuxième.

  1. 01

    Vous le branchez

    Un rôle en lecture seule, et c'est parti. Il passe vos comptes AWS, Azure et GCP au crible : 612 contrôles de sécurité, plus les dépenses qui ne servent à rien. À ce stade, il ne peut rien modifier — même s'il le voulait.

    LECTURE SEULE
  2. 02

    Il écrit le correctif

    Chaque problème devient une pull request Terraform sur votre dépôt. Le plan, ce qui change, le retour arrière : tout est joint. Vous la relisez comme celle d'un collègue. Après le merge, il revérifie et vous montre que le problème a disparu.

    PREUVE JOINTE
  3. 03

    Il en fait plus quand il l'a mérité

    Chaque type de correctif a son propre historique. Sans faute, il monte d'un cran. Un échec, il redescend. La confiance gagnée sur un correctif ne s'étend jamais aux autres, et le dernier cran ne s'ouvre que si vous le demandez.

    CONFIANCE ACQUISE
ANATOMY OF A FIX PRsrc/automation/pr-body.ts
Ce qui est joint à la pull request

Vous ne croyez pas un modèle sur parole.

Chaque pull request arrive avec ses preuves. Et quand une vérification n'a pas tourné, c'est écrit noir sur blanc — pas caché sous une coche verte.

  • plan Terraform3 ressources modifiées, 0 détruite
  • essai en bac à sablenon installé sur ce dépôt
  • contrôles de stabilitédépend de l'essai en bac à sable
  • périmètre d'impact3 buckets · aucune interruption
  • retour arrièreune PR de revert, comme n'importe quel commit
  • mention IArédigée par une IA — revue humaine requise
Trois états, jamais deux
  • a tourné · concluant
  • n'a pas tourné · non configuré
  • a tourné · échoué — ne pas merger

Deux lignes n'ont pas tourné ici, et le disent. Ailleurs, elles seraient vertes. C'est ce qui vous dit où regarder avant de merger.

THE LEDGERsrc/trust/routes.ts
Une autonomie qui se gagne, correctif par correctif

Il n'a pas les clés. Il les gagne.

La vraie question devant un agent : jusqu'où va-t-il seul ? Aussi loin que son historique le mérite, sur ce correctif précis. Pas un cran de plus. Et tout se reprend.

Les quatre crans
  1. observe — n'écrit rien, apprend
  2. propose — vous rédigez la suite
  3. ouvre la pull request — vous mergezPLAFOND ACTUEL
  4. merge de lui-même (sur demande explicite)DÉFINI · PAS ACTIVÉ
SURFACESsrc/mcp · src/cli · frontend
Là où vos équipes travaillent déjà

Rien de nouveau à ouvrir le matin.

Vos ingénieurs gardent leurs outils. Vous gardez la vue d'ensemble. Le code source est ouvert aux design partners.

  • MCPdepuis Claude Desktop, Cursor ou Windsurf
  • CLIdans votre terminal et votre CI
  • INTERFACEl'état des lieux et l'historique de confiance
DESIGN PARTNERSpremiers accès · lecture seule
Où nous en sommes

Nous ouvrons les premiers accès design partners.

NIMBUS tourne sur des comptes réels et la boucle complète a été vérifiée en production. Il nous manque ce qu'aucun développement ne remplace : quelques entreprises qui le branchent et nous disent où il pèche. Il arrive en lecture seule. Il repart en supprimant une ligne.

Ce que vous y gagnez
  • L'état complet de votre cloud : 612 contrôles de sécurité (247 AWS · 203 Azure · 162 GCP) et les dépenses inutiles
  • Vos premiers correctifs écrits et prêts à relire, sur votre dépôt
  • Un vrai poids sur la suite : ce que vous demandez, c'est ce qu'on construit
  • Le fondateur au bout du fil, pas un formulaire de support
Ce que nous demandons
  • Un cloud réel à inspecter (AWS, Azure ou GCP)
  • Une trentaine de minutes pour brancher un rôle en lecture seule
  • Votre Terraform sur GitHub : c'est là que les correctifs arrivent. Pas de Terraform ? L'audit marche quand même.
  • Votre avis sans filtre, y compris quand il fait mal. C'est tout ce que nous demandons en échange.
Comment ça se déroule
  1. Jour 1Une trentaine de minutes pour brancher le rôle. Premier état des lieux le jour même.
  2. Semaine 1Nous passons les problèmes en revue ensemble. Les premiers correctifs arrivent sur votre dépôt, plan à l'appui.
  3. Semaine 2Vous mergez, ou non. NIMBUS revérifie après coup. Vous décidez de la suite.

Vous voulez arrêter ? Supprimez le rôle IAM : une ligne, et il ne voit plus rien.

Ce que ça implique côté sécurité
Accès
AWS : un rôle inter-comptes en lecture seule (AssumeRole avec ExternalId), aucune clé conservée. Azure et GCP : identifiants en lecture seule, chiffrés au repos (AES-256-GCM).
Écriture
Jamais directe. Chaque changement est une pull request sur votre dépôt et Terraform s'exécute dans votre CI. NIMBUS ne détient aucune clé d'écriture sur votre cloud.
Révocation
Vous supprimez le rôle ou l'identifiant : l'accès disparaît sur-le-champ.
IA
L'analyse passe par l'API Claude et ne transmet que les problèmes détectés et des métadonnées de configuration. Vos identifiants ne sont jamais envoyés au modèle.
Devenir design partner
ou écrivez-moi directement
CLOSEnimbus-agentic.com
Une trentaine de minutes, en lecture seule

Voyez ce qu'il trouve chez vous.
Décidez ensuite.

Devenir design partnerCréer un compte

Lecture seule par défaut. Chaque modification passe par une pull request que vous approuvez, et s'annule comme n'importe quel commit.