T09 · Insecure Skill Coding Practices
- Location
modules/issue-templates.md:18- Finding
Unredacted Workflow Evidence May Be Published to External Issue Trackers
- Content
View full analysis
Vulnerability Details
File Location:
modules/issue-templates.md:18-46
Additional Locations:SKILL.md:71-73,SKILL.md:86-89,SKILL.md:133-135;modules/detection-patterns.md:118-140;modules/issue-templates.md:171-185
Vulnerability Type: Sensitive information exposure through unredacted evidence collection and publication
Risk Level: MediumVulnerable Code
markdown ## Error Report Template ```markdown ## Background Detected during workflow execution on {{DATE}}. **Source:** {{WORKFLOW_NAME}} session {{SESSION_ID}} **Severity:** {{SEVERITY}} ## Problem {{ERROR_DESCRIPTION}} **Command:**{{COMMAND}}
text **Output:**{{OUTPUT_EXCERPT}}
text **Exit code:** {{EXIT_CODE}} ## Context - Previous operation: {{PREVIOUS_OP}} - Working directory: {{WORKING_DIR}} - Environment factors: {{ENV_NOTES}}The skill also directs the agent to collect and link potentially sensitive evidence:
text 1. Log execution events - Commands, outputs, timing 2. Tag anomalies - Failures, timeouts, inefficiencies 3. Store evidence - For reproducibilityIssue publication can be configured to occur without case-by-case approval:
yaml auto_create_issues: false # Require approval before creatingTechnical Analysis
The skill collects raw command lines, command output, working directories, environment notes, session identifiers, and surrounding execution context. These values are inserted directly into issue templates without a required sanitization or secret-redaction stage.
Workflow commands and their output commonly contain sensitive values, including:
- Access tokens passed through command-line arguments
- Authentication headers or signed URLs
- Credentials printed by failing tools
- Private repository names and source fragments
- Internal hostnames, user names, and filesystem paths
- Environment configuration or deploym ...[truncated 2441 chars]
- Remediation
View remediation
Remediation Suggestions
-
Add mandatory redaction before evidence storage and rendering
- Detect common token, password, private-key, authorization-header, signed-URL, and connection-string formats.
- Replace detected values with stable placeholders such as
[REDACTED_TOKEN]. - Redact secrets from both command arguments and output excerpts.
-
Use an allowlist-based evidence model
- Publish only explicitly approved fields.
- Exclude raw environment data by default.
- Normalize working directories so user names and sensitive path components are removed.
- Avoid including complete commands when a sanitized command name and non-sensitive arguments are sufficient.
-
Limit evidence volume
- Truncate output excerpts to a conservative size.
- Select only lines directly relevant to the failure.
- Store detailed evidence locally in a protected location rather than embedding it in remote issues.
-
Require explicit approval for external publication
- Do not allow
auto_create_issuesto bypass review when evidence fields are present. - Present the exact sanitized issue body to the user before submission.
- Require separate confirmation when the destination repository is public.
- Do not allow
-
Validate the publication destination
- Determine repository visibility before creating an issue.
- Block automatic publication to public repositories.
- Apply the principle of least privilege to GitHub or GitLab credentials.
-
Add automated security tests
- Test redaction of GitHub tokens, cloud credentials, bearer tokens, private keys, passwords, signed URLs, and connection strings.
- Verify that secrets cannot survive template rendering.
- Add regression tests for multiline and encoded secret formats.
-
