T09 · Insecure Skill Coding Practices
- Location
scripts/pipeline_monitor.py:38- Finding
GitLab API token can be transmitted to an arbitrary or plaintext endpoint
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This CI/CD skill is mostly purpose-aligned, but it needs Review because it can handle deployment automation and CI credentials without enough safeguards.
Review this skill before installing. Use only narrowly scoped, short-lived GitHub or GitLab tokens, avoid passing tokens on the command line, do not use untrusted or plaintext GitLab URLs, and inspect generated CI/CD files before committing them or letting them affect production deployments.
scripts/pipeline_monitor.py:38GitLab API token can be transmitted to an arbitrary or plaintext endpoint
requirements.txt:1Unbounded dependencies and mutable CI component references create supply-chain exposure
The skill exposes a deployment_trigger capability that can target production but does not include any explicit warning, confirmation, or safety guidance for production-affecting actions. In a CI/CD context, triggering deployments is inherently high-trust and can cause service disruption, unintended releases, or operational impact if invoked carelessly or through ambiguous user intent.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
if token:
headers["Authorization"] = f"token {token}"
url = f"https://api.github.com/repos/{repo}/actions/runs"
try:
response = requests.get(url, headers=headers)
This markdown file presents automated deployment and CI/CD configuration generation as core features, and the examples later save workflow files into repository paths. The description does not include any user warning that these actions can alter build/deployment behavior or commit-worthy project files, which is relevant to user data and system integrity.
The examples save workflow and CI configuration files directly to standard repository paths without warning that existing files may be created or overwritten. In practice this can unintentionally replace repository automation, alter build behavior, or introduce deployment changes, especially because CI/CD config files are security- and release-sensitive.
The dependency is specified with a minimum version only, so builds may resolve to different releases over time. That weakens reproducibility and can unintentionally introduce a vulnerable or incompatible PyYAML version into downstream environments.
PyYAML>=6.0
requests>=2.28.0
python-jenkins>=1.8.0
PyYAML has multiple known advisories, and because the manifest does not pin a version, there is no way to verify whether deployments will receive a fixed or vulnerable release. This is more concerning because PyYAML has a history of unsafe parsing/deserialization issues, which can become serious if the application ever processes untrusted YAML.
Using a non-exact version for requests allows future installations to pull in any newer release that satisfies the range. This creates supply-chain and reproducibility risk because a newly introduced vulnerable or behavior-changing version could be installed without code changes.
PyYAML>=6.0
requests>=2.28.0
python-jenkins>=1.8.0
Requests has numerous historical advisories, and the unpinned requirement prevents verification that an installed version is patched. If this skill makes outbound HTTP requests, a vulnerable requests release could expose credentials, mishandle redirects, or weaken transport security depending on the affected version.
An unpinned python-jenkins dependency means the installed package version is not deterministic and may change between builds. Because this library may interact with CI/CD infrastructure, unexpected updates could increase operational and security risk if a bad release or vulnerable version is resolved.
PyYAML>=6.0
requests>=2.28.0
python-jenkins>=1.8.0
The file’s user-facing title and multiple docstrings are written in Chinese alongside English, but there is no indication that language selection is optional or that the skill is intended only for a Chinese-speaking context. This creates a natural-language locale constraint without explicit user opt-in or justification.
The file mixes English and Chinese in docstrings and descriptions, while several user-facing help strings and output messages are fixed rather than selectable by the user. This can violate language/locale policy when a skill imposes a language presentation without explicit opt-in or configuration.
The save method opens the target path in write mode, which will overwrite an existing file, but there is no confirmation prompt or pre-write warning. Although the script prints a success message afterward, it does not disclose this destructive behavior before performing the write.
This code includes user-facing natural-language strings such as docstrings in Chinese (e.g. the function descriptions) while the skill does not provide any explicit user opt-in or language-selection mechanism. That can violate language/locale policy when a skill implicitly forces a language for some users.
No suspicious patterns detected.