T08 · Insecure Dependencies
- Location
SKILL.md:14- Finding
Unpinned Third-Party Dependencies Create a Supply-Chain Risk
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is local and not destructive, but it substantially overstates engineering parsing and verification capabilities that the code does not actually implement.
Install only if you treat this as a local heuristic extraction/reporting helper, not an authoritative electrical-topology, model, quantity, title-block, terminal-table, or UL compliance verifier. Pin and review dependencies before installation, run it with access limited to the intended drawing and BOM files, and manually validate outputs before using them for engineering, procurement, or compliance decisions.
SKILL.md:14Unpinned Third-Party Dependencies Create a Supply-Chain Risk
The skill claims extraction of model, quantity, topology, terminal tables, title-block metadata, series/parallel analysis, and power-flow direction, but the implementation reportedly lacks these capabilities and may emit undeclared preview outputs. In an electrical-document context, this can cause silent data-quality failures and unexpected file generation, both of which are risky in controlled engineering workflows.
The skill claims extraction of model, quantity, topology, terminal tables, title-block metadata, series/parallel analysis, and power-flow direction, but the implementation reportedly lacks these capabilities and may emit undeclared preview outputs. In an electrical-document context, this can cause silent data-quality failures and unexpected file generation, both of which are risky in controlled engineering workflows.
The skill claims extraction of model, quantity, topology, terminal tables, title-block metadata, series/parallel analysis, and power-flow direction, but the implementation reportedly lacks these capabilities and may emit undeclared preview outputs. In an electrical-document context, this can cause silent data-quality failures and unexpected file generation, both of which are risky in controlled engineering workflows.
The skill advertises commands that read local files and write outputs, but it does not declare an explicit tool scope such as permissions or allowed-tools. That creates an authorization ambiguity where an agent may grant broader filesystem write capability than users expect, increasing the chance of unintended file creation or overwrite during routine use.
The description begins with an explicit "EN:" branch and mixes bilingual content, but it does not state that language should follow the user's preference or provide a language-choice policy. This can violate a language/locale policy if the skill defaults to a specific language without opt-in.
The trigger phrases are broad and overlap with common electrical-document tasks, which increases the chance of accidental invocation on unrelated user requests. Unintended activation can expose local files to parsing routines or cause unnecessary output generation when the user did not intend to use this skill.
The file is written entirely in Chinese and does not indicate that users may choose another language or that the skill is intentionally restricted to a Chinese-speaking or region-specific audience. Under the policy rule, forcing a specific language without opt-in is a natural-language policy violation.
The manifest describes a skill for extracting structured data from EPLAN/vector PDF drawings: components, wire topology, terminals, and title-block metadata. This script instead cross-checks a PDF against an external Excel BOM, evaluates UL-related BOM fields, and exports a synthesized workbook, which is broader than pure drawing-data extraction.
The docstring claims four checks including matching nearby model text to BOM model and verifying BOM quantity against drawing occurrence frequency. In code, the result only records whether a designator was found and on which pages; there is no proximity-based model comparison and no quantity-vs-occurrence validation logic.
The comments/docstring explicitly state that the script checks model consistency near the designator and quantity consistency between BOM and drawing frequency. The actual logic only builds presence/page listings for designators and never compares normalized models or counts occurrences against BOM quantities, so the documentation is actively misleading about implemented intent.
This Python file contains user-facing natural-language text such as the module description and argument help strings entirely in Chinese. Under the policy rule for language/locale, forcing a specific language without user opt-in is a natural-language policy violation when no alternative or justification is provided.
The module-level and CLI documentation describe topology parsing, but the code does not compute connectivity graphs, pin relationships, series/parallel structure, or power-flow direction; it only counts wire endpoints near text labels. This is dangerous because the skill is positioned for parsing electrical schematics, where overstated capability can mislead users into making safety-relevant conclusions from non-topological data.
The skill metadata promises extraction of wire/pin topology, terminal tables, title-block metadata, and component model/quantity, but the implementation only identifies likely component designators and counts nearby line endpoints. In an engineering workflow, this mismatch can cause users or downstream agents to trust incomplete or fabricated structured output for electrical review, procurement, or maintenance decisions.
The document presents bilingual content, but the explicit language split may imply a fixed locale presentation pattern rather than user-selected language behavior. Under the policy rule, locale handling should be clearly optional or justified; this README does not state any language selection behavior or rationale.
No suspicious patterns detected.