T08 · Insecure Dependencies
- Location
package.json:9- Finding
Mutable Third-Party Package Execution Through npx
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This QA skill appears purpose-aligned, but it should be reviewed because it runs an unpinned external npm tool and has under-scoped network and reporting behavior for a financial app.
Review before installing or using in CI. Prefer pinning web-qa-bot to an exact reviewed version, committing a lockfile, and running a local locked binary instead of floating npx commands. Use test accounts, avoid production sessions or secrets, restrict network access to intended Strykr hosts, and treat screenshots, console logs, and reports as potentially sensitive.
package.json:9Mutable Third-Party Package Execution Through npx
src/assertions.ts:200Unrestricted Network Requests Through Configurable Health Checks
src/strykr-bot.ts:69Placeholder QA Assertions Can Produce False Successful Results
The README promotes screenshot capture and report generation for a live trading platform but does not warn that artifacts may contain sensitive information such as account data, portfolio details, prompts, API error payloads, or session-linked content. In QA and CI contexts, these artifacts are commonly stored, shared, or uploaded, which can lead to inadvertent data exposure even without a software exploit. The skill context makes this more dangerous because the target is a financial application and the reports explicitly include screenshots and console errors.
The README instructs users to execute npx web-qa-bot without pinning an exact package version. npx can fetch the latest published package at runtime, so a compromised upstream release or typosquatted replacement could lead to arbitrary code execution on the tester's machine or CI runner. In a QA/CI skill, this is more dangerous because users are explicitly encouraged to run it in automation environments that often have network access, source code, and secrets.
This command again relies on unpinned npx web-qa-bot, which permits execution of whatever version is current in the registry when the command is run. That creates a supply-chain risk where malicious or unexpected package changes could execute code during local testing or CI/CD workflows. Because the skill markets itself as CI/CD-ready, the operational context increases the likelihood and impact of abuse.
The report-generation example also uses unpinned npx web-qa-bot, exposing users to the same runtime package-fetch and supply-chain execution risk. Even though this command appears lower risk than running tests, it still executes package code that may access local files, results, tokens, or CI workspace contents. The README context makes this a true issue because it is a direct operational instruction to execute external code.
The skill describes network-capable behavior against external endpoints like https://app.strykr.ai and PRISM APIs, but it does not declare any explicit tool scope such as permissions or allowed-tools. That creates an authorization and review gap: an agent may infer it should use unrestricted network access, making the skill harder to sandbox and increasing the chance of unintended requests, data exposure, or misuse in broader environments.
The npm scripts invoke npx web-qa-bot without an exact version, so execution may fetch whatever version is current or otherwise resolvable in the environment. In a CI/CD-oriented QA skill, that creates a supply-chain risk where tests run arbitrary updated code, potentially leading to code execution or unexpected behavior during automated workflows.
This script uses npx web-qa-bot without version pinning, which allows the resolved package version to drift over time or be fetched dynamically. Because the package is used to drive browser-based QA automation, any compromised or breaking upstream release could execute in developer or CI environments.
Invoking npx web-qa-bot without a fixed version means this test command may execute unreviewed upstream code when run. In a package marketed as CI/CD-ready, that increases exposure because automated systems may repeatedly execute the command with elevated repository or environment access.
The unpinned npx web-qa-bot invocation introduces supply-chain uncertainty because npx can resolve a newer package version than the one originally tested. That is risky for automation tooling, where compromise or malicious takeover of the package could lead to arbitrary command execution on developer workstations or CI runners.
This script depends on npx web-qa-bot without locking the package version, creating a path for accidental or malicious upstream changes to affect execution. Since the skill targets trading-platform QA, the context raises concern because automated tests may have access to authenticated sessions, test credentials, or internal environments.
Calling npx web-qa-bot here without version pinning allows the actual code run by the script to change independently of this repository. That weakens reproducibility and opens a supply-chain execution risk, particularly in environments that automatically run package scripts.
The npx web-qa-bot usage is unpinned, so the script may execute a different package version over time or across environments. For a prebuilt AI-powered QA package, that means an upstream package compromise could directly impact systems running these tests.
The smoke test uses npx web-qa-bot without an explicit version, introducing the same supply-chain and reproducibility risk as the other scripts. Because smoke tests are likely to be run frequently against live endpoints, a malicious upstream package could abuse that trusted execution path.
expectPageNotBlank is documented as validating that a page loaded correctly, but it always returns true and performs no real checks. In a QA/testing skill for a trading platform, this can silently mask blank-page, render-failure, or app-crash conditions, causing automated tests to pass when the UI is actually unusable.
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
"author": "Next Frontier",
"license": "MIT",
"peerDependencies": {
"web-qa-bot": "^0.1.0"
},
"devDependencies": {
"typescript": "^5.3.0"
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
"web-qa-bot": "^0.1.0"
},
"devDependencies": {
"typescript": "^5.3.0"
},
"repository": {
"type": "git",
No suspicious patterns detected.