T09 · Insecure Skill Coding Practices
- Location
scripts/jira_cli.py:18- Finding
Jira credentials can be transmitted to an attacker-controlled host
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This Jira skill mostly matches its stated purpose, but it needs review because it can change live Jira data and sends the Jira API token to the configured domain without validating it.
Install only if you trust the publisher and can tightly control the runtime environment. Set JIRA_DOMAIN only to the intended Atlassian tenant, use a least-privileged Jira API token, rotate any token that may have run with an untrusted domain, and require explicit user approval before create, transition, or comment commands.
scripts/jira_cli.py:18Jira credentials can be transmitted to an attacker-controlled host
SKILL.md:33Unpinned third-party dependency installation creates supply-chain exposure
The skill requires access to environment variables and the network, but it does not declare any explicit tool scope or allowed-tools boundary. In a credentialed Jira integration, this weakens least-privilege controls and can allow broader-than-expected execution or secret access if the runtime grants defaults.
The trigger text says to activate on any request that mentions Jira operations, which is overly broad for a skill that can both read and modify issue data. Over-triggering can cause the assistant to invoke this skill in ambiguous contexts and perform unintended actions against a live Jira tenant using stored credentials.
The skill description emphasizes operational capabilities but does not clearly warn that it can modify Jira data. In practice, this can lead users or orchestrators to treat the skill as informational when it is capable of creating issues, transitioning workflow state, and adding comments or attachments.
The code implements a comment operation that is not disclosed in the skill metadata, creating a capability mismatch between what reviewers/users expect and what the tool can actually do. Hidden write capabilities are dangerous in agentic settings because they expand the action surface beyond the declared scope and could be invoked without appropriate policy, review, or user awareness.
The create, transition, and comment commands directly perform state-changing requests against a live Jira instance with no built-in confirmation, dry-run mode, or user-approval checkpoint. In an agent context, this raises the risk of accidental or prompt-induced remote modifications, especially since the skill is designed to trigger broadly on Jira-related requests.
The manifest description limits the skill to listing, creating, and transitioning Jira issues, but the SKILL.md overview and usage also describe adding comments and attachments. That expands the described behavior beyond the manifest’s stated scope, even though it remains within Jira.
The documentation states 'Ensure Python 3.9+ is installed on Windows' and labels PowerShell as recommended, which imposes a specific platform context without indicating whether alternatives are supported. This is a mild natural-language policy concern because it constrains usage without explicit opt-in or justification.
The parser exposes a comment subcommand while the surrounding skill description says to use the skill for Jira operations but does not mention commenting. This inconsistency can cause downstream tooling or reviewers to under-classify the skill's write capabilities, making unauthorized or unexpected comments more likely in practice.