T09 · Insecure Skill Coding Practices
- Location
SKILL.md:29- Finding
Transmission of Reusable Cloud Credentials to an External Scanning Service
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:29-37,SKILL.md:80-81,SKILL.md:149-152, andopenapi.json:48-66
Vulnerability Type: External disclosure and unsafe handling of cloud credentials
Risk Level: High
Classification: T09: Insecure Skill Coding PracticesThe Skill directs users or agents to provide cloud access keys, secret keys, tokens, or service-account data to a third-party API. The project contains only documentation and an OpenAPI contract; it does not include a local scanner implementation or controls governing how the remote service stores, logs, uses, or deletes submitted credentials.
Vulnerable Code Snippets
SKILL.md:29-37:json { "provider": "aws", "credentials": { "access_key_id": "AKIAIOSFODNN7EXAMPLE", "secret_access_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY", "region": "us-east-1" } }SKILL.md:80-81:markdown | `provider` | string | Yes | Cloud provider identifier (e.g., `aws`, `azure`, `gcp`, `alibaba`) | | `credentials` | object | Yes | Provider-specific authentication credentials including access keys, secret keys, tokens, or service account data required to authenticate and access cloud resources |SKILL.md:149-152:markdown - **Kong Route:** https://api.mkkpro.com/security/cloud-misconfig-scanner - **API Docs:** https://api.mkkpro.com:8018/docsopenapi.json:48-66:json "CloudScanRequest": { "properties": { "provider": { "type": "string", "title": "Provider" }, "credentials": { "type": "object", "title": "Credentials" } }, "type": "object", "required": [ "provider", "credentials" ], "title": "CloudScanRequest" }Technical Analysis
The API contract requires a generic
credentialsobject and allows it to contain reusable cloud authentication material. The documentation expl ...[truncated 3312 chars]- Remediation
View remediation
Remediation Suggestions
-
Replace long-lived credentials with federation
- Use provider-native short-lived role assumption, workload identity federation, managed identities, or OAuth device and authorization flows.
- Do not request secret access keys, private service-account keys, or reusable bearer tokens.
-
Enforce least privilege
- Publish provider-specific read-only policies containing only the APIs required for scanning.
- Require dedicated scanner identities with account, project, subscription, region, and resource boundaries.
- Reject administrative, root, owner, or organization-management credentials where technically possible.
-
Prefer local collection
- Run cloud API discovery locally and send only normalized configuration findings to the external service.
- Alternatively, deploy the scanner within the customer's controlled cloud account so credentials do not cross the trust boundary.
-
Add provider-specific schemas
- Replace the unrestricted
credentialsobject with explicit schemas for each supported provider. - Disallow unknown properties and unnecessary secret types.
- Validate that temporary credentials include expiration and session-token information.
- Replace the unrestricted
-
Protect secrets operationally
- Disable request-body logging at the application, reverse proxy, API gateway, tracing, analytics, and error-reporting layers.
- Apply structured redaction to all authentication fields.
- Keep credentials only in memory for the duration of a scan and securely delete any transient copies.
- Document encryption, retention, access-control, incident-response, and deletion practices.
-
Introduce informed authorization
- Clearly identify the external recipient and exact credential fields before transmission.
- Require explicit user confirmation before an agent sends cloud secrets outside the local environment.
- Warn users never to provide roo ...[truncated 374 chars]
-
