T08 · Insecure Dependencies
- Location
references/validate-angular.sh:25- Finding
Unpinned npx Commands Can Retrieve and Execute Untrusted Packages
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill fits a SonarQube fixing workflow, but it has review-worthy risks around credential handling, broad repository changes, and unpinned command execution.
Install only if you are comfortable reviewing its actions. Use a dedicated least-privilege SonarQube token, trusted HTTPS SonarQube URLs, and an approved repository workspace. Do not allow it to remove scanner or CI quality configuration unless you explicitly want that change, and prefer locked local dependencies instead of unpinned npx downloads.
references/validate-angular.sh:25Unpinned npx Commands Can Retrieve and Execute Untrusted Packages
references/download-issues.sh:20SonarQube Bearer Tokens Can Be Sent to Unvalidated or Plaintext Destinations
references/sonar-local-scan.sh:7Incorrect Project Root Derivation Can Scan or Modify an Unintended Directory
references/sonar-local-scan.sh:59Local SonarScanner Uses a Hardcoded Default Administrative Credential over HTTP
The declared description presents a comprehensive SonarQube automation skill that analyzes SonarQube issues and applies fixes with tests and coverage support. The supplied code chunk only performs local stack detection based on repository files such as pom.xml, package.json, and requirements.txt. While stack detection could be a supporting helper within a larger SonarQube remediation skill, this code chunk by itself does not implement the core declared functionality and instead has a materially different primary purpose. There are no undeclared sensitive accesses, but the behavior shown is substantially narrower and different from the declared purpose.
The declared description presents a comprehensive SonarQube remediation skill, but the supplied code is only a standalone JSON formatter shell script. It does not analyze SonarQube issues, connect to SonarQube deployments, generate fixes, create tests, or handle coverage. Its primary purpose is materially different and unrelated to the declared skill purpose, so this is a clear mismatch.
The declared description promises an end-to-end automatic SonarQube remediation skill: issue analysis, fix generation, unit tests, coverage, and support for multiple SonarQube deployment types via environment variables. The supplied code chunk is much narrower. It is a helper script for running a local SonarQube scan, creating minimal configuration if absent, and adding a few coverage path properties based on detected project files. It does not inspect issues, modify source code, generate fixes, run tests, or produce coverage. It also hardcodes the SonarQube host to localhost:9000 and only uses an environment variable for the login token, which falls short of the stated deployment flexibility. This is a material description-behavior mismatch, not just an implementation detail.
The declared description promises a SonarQube automation skill that works across languages/frameworks to analyze SonarQube issues, generate fixes, and manage tests/coverage in the context of SonarQube deployments. The provided code does not interact with SonarQube at all. Instead, it is an Angular-specific validation script that detects Angular projects and runs ng lint/eslint, Prettier, tests with coverage, and a production build. Its primary purpose is local Angular validation and formatting, which is materially different from SonarQube-driven issue fixing. This is a clear description-behavior mismatch.
The declared description centers on automatic remediation of SonarQube issues, including SonarQube-specific analysis and support for different SonarQube deployments. The supplied code does not interact with SonarQube at all, does not analyze SonarQube issues, and does not generate or apply fixes. Instead, it is a straightforward C#/.NET validation script that runs build analyzers, formatting checks, and tests with coverage using standard dotnet tooling. While tests and coverage are loosely related to quality workflows, the primary purpose and capabilities are materially different from the declared SonarQube-focused automation.
The declared description centers on automatically fixing SonarQube-reported quality issues across languages and environments. The supplied code instead is a simple Go validation helper that runs linting, formatting inspection, and tests with coverage. While testing and coverage are loosely related to code quality, the primary purpose is materially different: local Go validation rather than SonarQube issue remediation. The absence of any SonarQube API usage, environment-variable-based deployment support, issue parsing, or fix generation makes this a clear description-behavior mismatch.
The declared description centers on automated remediation of SonarQube issues across arbitrary languages and deployments. The supplied code does something materially different: it validates Java/Kotlin projects by invoking Maven/Gradle checks for Checkstyle, PMD, Spotless, and JaCoCo. There is no evidence of SonarQube connectivity, environment-variable-based deployment support, issue analysis from SonarQube, fix generation, or broad cross-language behavior. This is not just an incomplete excerpt of a larger SonarQube fixer; the code’s primary purpose is local static-analysis/formatting/coverage validation for Java/Kotlin, which is outside the declared purpose.
The declared description centers on automatically fixing SonarQube code quality issues across any language/framework, including SonarQube issue analysis and support for different SonarQube deployments. The supplied code does not interact with SonarQube at all: it simply validates a JS/TS project by running ESLint, Prettier, and tests with coverage. While testing and coverage are mentioned in the description, here they are part of a local validation workflow and not tied to SonarQube issue remediation. This is a materially different primary purpose, so it should be flagged as a mismatch.
The declared description centers on automatic remediation of SonarQube issues across any language/framework and support for various SonarQube deployments. The supplied code instead performs local PHP validation using PHPStan, PHP CS Fixer in dry-run mode, and PHPUnit coverage generation. While tests and coverage loosely align with quality workflows, the primary purpose is materially different: it neither connects to SonarQube nor consumes SonarQube issues, and it does not automatically fix issues. It is also restricted to PHP and relies on non-SonarQube tooling. Therefore the description does not accurately represent this code chunk.
The declared description centers on SonarQube-driven automated remediation across arbitrary languages and frameworks. The supplied code does not interact with SonarQube, environment variables, or any remote/custom deployment. Instead, it is a local Python validation script that runs standard linting, formatting checks, and tests with coverage. That is a materially different primary purpose and capability set from the declared SonarQube auto-fix skill.
The description promises a SonarQube-focused automation skill that analyzes SonarQube issues, generates fixes, and supports multiple SonarQube deployment modes across languages and frameworks. The actual code chunk is a simple Ruby validation script that invokes RuboCop, Rufo, and rspec with coverage. Its primary purpose is generic Ruby lint/format/test validation, not SonarQube issue remediation. This is a material mismatch in scope, integration target, and capabilities.
The declared description centers on automatic remediation of SonarQube issues across environments, but the code shown only performs Scala project validation via sbt and Scala-specific linters/test coverage tools. It does not connect to SonarQube, consume SonarQube findings, generate fixes, or implement multi-language/framework support. This is a materially different primary purpose, so it is a mismatch.
The skill extensively instructs the agent to execute shell commands, invoke scripts, run package managers, and interact with external services, but it declares no explicit tool scope such as allowed-tools or permissions. That mismatch weakens policy enforcement and can cause an agent runtime to permit broader command execution than a reviewer expects, increasing the chance of unsafe or unintended actions.
npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.
npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.
npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.
npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.
npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.
npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.
npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.
The skill instructs the agent to remove SonarQube scanner and related configuration files from the repository, even though those files may be required for existing CI/CD, compliance, auditability, or project-specific quality controls. Automatic deletion of security- and quality-related configuration is dangerous because it can silently weaken scanning coverage, break pipeline enforcement, or remove organization-mandated controls unrelated to the immediate issue being fixed.
The skill says to change only items directly related to listed SonarQube issues, but elsewhere orders deletion of scanner files and configuration that may be unrelated to those issues. This inconsistency increases the risk of scope creep and destructive modifications outside user intent, which can undermine trust boundaries and cause harmful repository-wide side effects.
The instruction to automatically delete SonarQube-related scanner files is a destructive repository change with no mandatory warning, review gate, or confirmation step. In an autonomous agent context, this can remove important build and security controls silently, causing loss of protections and breaking downstream workflows before a human notices.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
If the user asks to remove isolated environments after completion, list the paths first and ask for explicit confirmation before deleting anything. Do not run rm -rf or find -exec rm -rf without consent.
# List what would be removed (do not delete automatically)
The script invokes sonar-scanner against a SonarQube server and passes SONAR_TOKEN, which causes project source and analysis metadata to be transmitted over HTTP to a service. Although the script logs that a scan is running, it does not explicitly warn the user that code and authentication material may be sent to a server.