cloud-exposure-triage

Classifies exposed cloud services and credentials into a capability map with manual validation plans.

7|4|Updated Jun 22, 2026
One-click install
npx skills add https://github.com/dbx0/skills --skill cloud-exposure-triage-dbx0
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: cloud-exposure-triage
Source: https://github.com/dbx0/skills/tree/main/skills/methodology/triage/cloud-exposure-triage
Command: npx skills add https://github.com/dbx0/skills --skill cloud-exposure-triage-dbx0

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Recon often uncovers scattered cloud clues—storage buckets, identity configs, tokens, backend endpoints—without a clear way to judge what they actually mean. This Skill turns those fragments into a structured capability assessment so testers know what access is implied and what to validate manually next. ## Core Features & Use Cases - Capability Bucketing: Normalizes discoveries into identity, data, storage, control plane, and messaging/automation categories. - Credential Classification: Distinguishes public client config from user-context, server-to-server, and admin artifacts to avoid over-claiming risk. - Service-to-Workflow Mapping: Ties each exposed service back to product behaviors like uploads, exports, sync jobs, and admin tooling. - Use Case: During an assessment, recon reveals a storage bucket name, a Cognito-style client ID, and a webhook endpoint. Use this Skill to map each clue to its trust boundary, score confidence, and produce a prioritized list of manual follow-up tests. ## Quick Start Triage these recon findings of exposed cloud services and credentials into a capability map with prioritized manual validation steps.

Frequently Asked Questions about cloud-exposure-triage

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I triage exposed cloud services found during recon?

Normalize each discovery into capability buckets: identity, data, storage, control plane, and messaging. For each one, determine whether it proves a data plane or control plane, what actor classes it reveals, and which workflows deserve manual follow-up testing.

How to assess the risk of leaked cloud credentials and tokens?

Classify each token or config fragment by what it represents: public client configuration, user-context artifact, server-to-server credential, or admin artifact. Then reason about the trust assumptions the application makes for that class before claiming any impact.

What should I test after finding exposed storage buckets or API endpoints?

Map the service to product workflows such as uploads, previews, exports, imports, and sync jobs. Compare read paths to write paths, public client behavior to backend helpers, and user paths to admin-adjacent paths leaked in configuration.

Does this methodology require specific cloud provider tools?

No. It is a provider-agnostic reasoning methodology that works from any recon output mentioning hosted services, identity platforms, or storage endpoints. It produces a manual validation plan rather than running automated exploitation.

When is cloud exposure triage not the right approach?

It is not suited for targets with no leaked backend-service metadata, or when you already have authenticated access and need deep configuration auditing. In those cases, direct cloud configuration review or authenticated testing is more appropriate.