T09 · Insecure Skill Coding Practices
- Location
build-failures.md:12- Finding
Gradle build scans may disclose sensitive build and environment metadata
- Content
View full analysis
Vulnerability Details
File Location:
build-failures.md:12; related recommendations atgradle.md:23andci.md:80, with the risk acknowledged atci.md:44
Vulnerability Type: External disclosure of build and environment metadata
Risk Level: MediumVulnerable guidance:
markdown - `--stacktrace` shows where Gradle failed; `--info` shows what it was doing; `--scan` shows which task, how long and with what inputs. Reach for `--info` before `--stacktrace`: the cause is usually a missing input, not a Gradle bug.Related guidance:
markdown Measure with `./gradlew --profile` or a build scan, and take the median of three runs.markdown - Guard against leakage: never echo the decoded values, never run the build with a flag that dumps all properties, and remember that a build scan can publish environment details. Rotate anything that appears in a log, immediately.markdown - A build scan on a slow build names the task that cost the time in one look — far faster than reading a log.Technical Analysis
The Skill recommends Gradle build scans for build-failure diagnosis and performance measurement. A build scan can transmit build telemetry to an external scan service, including task names, project structure, dependency information, repository metadata, file paths, system properties, and environment-derived details.
The Skill acknowledges that a build scan may publish environment information, but its scan recommendations do not impose a mandatory user-consent step, destination verification, access-control review, or pre-upload redaction check. This creates an unsafe default: an Agent following the diagnostic guidance could recommend or initiate an externally published scan without ensuring that the user understands what data leaves the machine.
This is not evidence of deliberate credential exfiltration. Elsewhere, the Skill expressly prohibits storing, logging, or trans ...[truncated 1546 chars]
- Remediation
View remediation
Remediation Suggestions
-
Make local profiling the default:
- Prefer
./gradlew --profile,--info, or locally retained reports. - Present build scans only when local diagnostics are insufficient.
- Prefer
-
Require explicit informed consent before generating or publishing a scan:
- State that build metadata will leave the machine.
- Identify the receiving service.
- Explain expected retention and access controls.
- Do not treat prior consent to ordinary network operations as consent to upload diagnostic metadata.
-
Add a mandatory pre-upload review:
- Inspect Gradle properties, system properties, repository URLs, custom tags, and captured environment values.
- Remove credentials, tokens, internal hostnames, usernames, and sensitive paths.
- Abort the upload if the captured data cannot be adequately reviewed.
-
Use restrictive publication settings:
- Require authenticated or private access where supported.
- Avoid publicly accessible scan links.
- Set the shortest practical retention period.
-
Add a post-upload handling rule:
- Do not place scan URLs in public issues, logs, or persistent Skill memory.
- Revoke or delete scans accidentally published with sensitive information.
- Rotate any credential appearing in a scan immediately.
-
Rewrite the affected guidance, for example:
markdown Prefer `--info` or `./gradlew --profile`, which retain diagnostics locally. A build scan uploads build and environment metadata to an external service. Generate one only after explicit user confirmation, destination and access-control verification, and review for secrets or proprietary metadata.-