Un collecteur et moteur de dérivation. Il cartographie votre environnement, évalue les permissions effectives et la confiance, et écrit un graphe d'attaque complet dans un seul fichier .rage.ndjson. L'entrée de tout le reste.
Vous n'avez pas 4 000 constats. Vous avez six chemins vers vos joyaux de la couronne.
Un CSPM vous remet une liste plate, dédupliquée et triée par sévérité de mauvaises configurations, et vous laisse deviner lesquelles comptent. Thunderstorm raisonne en termes d'atteignabilité : il collecte votre cloud en lecture seule, le modélise comme un graphe de capacités de sécurité, et vous dit qu'une relation de confiance OIDC GitHub Actions mène, en quatre sauts, à votre lac de données de production.
Aucun des sauts ci-dessus n'est un constat à lui seul. Un bucket public, une clé dans un fichier d'état, un rôle assumable, une action IAM trop large. Le chemin est le constat, et le chemin est ce que presque rien d'autre ne calcule.
Profond sur la plateforme vers laquelle vous le pointez. Lancez-le contre un compte AWS, un abonnement Azure ou un projet GCP, et il cartographie cet environnement unique dans les termes propres du fournisseur : assume-role STS et élévation de privilèges IAM dans AWS, chaînes RBAC et identité managée dans Azure, emprunt d'identité de compte de service dans GCP. Un environnement, un graphe, modélisé comme ce cloud fonctionne réellement.
Beaucoup d'outils énumèrent davantage. L'affirmation ici est que Thunderstorm raisonne sur ce qu'il énumère avec une réelle profondeur : 219 types de ressources, 80 types d'arêtes, plus de 2 400 règles de dérivation et 1 049 sites de fuite d'identifiants cartographiés, tous issus de RAGE.
RAGE est le format, Thunderstorm le produit, Blaze l'explore.
Ils sont ce que Thunderstorm produit à partir d'un seul scan.
Un bucket S3 mal configuré. Thunderstorm le suit sur six sauts jusqu'à la base de données clients de production, et une seconde route directement vers le secret maître de la base de données.
Internet ──public s3:GetObject──▶ acme-terraform-state (public bucket)
──ExposesCredential────▶ AKIA… (access key leaked in tfstate)
──CredentialsFor───────▶ ec2-app-role
──CanAssume────────────▶ terraform-exec (sts:AssumeRole)
──CanEscalateTo────────▶ OrganizationAdmin (iam:AttachRolePolicy)
──CanReadData──────────▶ acme-prod-customers (PII)
Chaque saut porte la permission qui le permet, la preuve qui l'établit et un récit en langage clair. Les valeurs divulguées en ressortent également :
Un blob lisible publiquement divulgue un secret de principal de service. Un Contributor disposant d'une permission supplémentaire se promeut lui-même en Owner de l'abonnement. Aucune exploitation d'application ; juste une mauvaise configuration cloud et de l'IAM.
Internet ──anonymous blob read──▶ acmedeploy (public Storage account)
──ExposesCredential────▶ automation-sp secret (in a deploy config blob)
──CredentialsFor───────▶ automation-sp (Contributor)
──CanEscalateTo────────▶ Owner (Microsoft.Authorization/roleAssignments/write)
──CanReadData──────────▶ acmedatalake
L'emprunt d'identité de compte de service est invisible pour la plupart des outils. Thunderstorm traite iam.serviceAccounts.getAccessToken comme l'arête de mouvement latéral qu'elle est.
Internet ──public allUsers───▶ acme-public-exports (GCS)
──ExposesCredential─▶ sa-deploy-key
──CredentialsFor────▶ sa-deploy
──CanImpersonate────▶ sa-data-pipeline
──CanImpersonate────▶ sa-org-admin
──CanReadData───────▶ acme_customers_pii (BigQuery)
view l'ouvre dans votre navigateur ; rien n'est téléversé.collectors/, engine/).Thunderstorm ne porte aucune taxonomie, correspondance ou règle qui lui soit propre. Il consomme la norme RAGE de bout en bout :
| Préoccupation | Réside dans RAGE |
|---|---|
| Taxonomie des nœuds / arêtes, conditions | vocab/{node-types,edge-types,conditions}.json |
| Correspondances natif→générique + recettes de collecte | providers/{aws,gcp,azure}.json |
| Corpus de règles de dérivation | rules/ |
| Catalogue d'exposition des identifiants | exposure-db/{aws,gcp,azure}.json + vocabulary.json |
Lien de version : le spec_version de RAGE est le nombre unique qui épingle Thunderstorm à une version de RAGE. Le collecteur le lit en direct depuis le RAGE contre lequel il a été compilé (thunderstorm version affiche RAGE <v>) et l'appose dans chaque graphe qu'il émet ; Blaze Lite lit cet apposage et avertit lorsqu'un graphe a été construit contre une version qu'il ne prend pas en charge.
Comment RAGE est résolu (la première correspondance l'emporte) :
$RAGE_ROOT : un checkout RAGE en direct, si vous le définissez (surcharge de développement ; les modifications s'appliquent sans recompilation).collectors/rage/, intégré au binaire.Rafraîchissez l'instantané avec make RAGE_ROOT=/path/to/rage (ou go generate ./... dans collectors/). RAGE se trouve à github.com/trustedsec/rage.