ci: add KYA security scan for MCP dependencies

[Thezenmonster]

Automated MCP dependency security scanning on every push and PR via KYA Scan.

What it checks per dependency:

• Abuse database: has this package been reported for malicious behaviour?
• Install scripts: does the package run code on npm install?
• Suspicious URLs: hardcoded IPs or exfiltration domains?
• Prompt injection: manipulation patterns in package metadata?
• Metadata quality: missing repo, licence, or description?

919 MCP packages scanned. 98.5% clean. This catches the rest before they reach your project.

Free, no API key, no configuration. One YAML file, zero code changes.

KYA Scan Action | Scanner

---

Note

Low Risk
Adds a new GitHub Actions workflow that runs a third-party security scanning action on every push and pull request; risk is mainly around CI reliability and trusting the external action.

Overview
Introduces a new GitHub Actions workflow, kya-scan.yml, that runs on every push and pull_request and executes Thezenmonster/kya-scan-action@v1 after checkout to scan dependencies for security issues.

^{Written by Cursor Bugbot for commit c0120e6. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Untrusted action pinned to mutable tag enables supply chain attacks

High Severity

Thezenmonster/kya-scan-action@v1 references a mutable tag from an unverified publisher. The action owner can silently replace the code behind v1 at any time — exactly the pattern exploited in the recent Trivy and Xygeni supply chain attacks (March 2026) where mutable tags were force-pushed to inject credential-stealing malware into CI pipelines. This action runs on every push and PR, giving it access to the runner environment and any configured secrets. The action cannot be found in GitHub Marketplace searches, further suggesting it is unvetted.

 

[cursor]

Workflow lacks permissions block granting excessive default access

Medium Severity

The workflow has no permissions: block, so it inherits the repository's default token permissions — which can include write access to contents, packages, and other sensitive scopes. A scanning workflow only needs read access at most. Applying least-privilege permissions (e.g., permissions: contents: read) limits the blast radius if the third-party action is compromised.

 

[cursor]

You have used all of your free Bugbot PR reviews.

To receive reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[Thezenmonster]

Hi team - I've addressed the bot review comments (pinned to commit SHA, added explicit permissions block). This is a single YAML file that scans your npm deps against a community abuse database on each push/PR. No code changes, no new dependencies added to your project. Happy to answer any questions.

[Thezenmonster]

Relevant context for this PR: on March 31, the axios npm package was compromised via a hijacked maintainer account (Snyk write-up). Malicious versions 1.14.1 and 0.30.4 contained a hidden dependency that deployed a cross-platform RAT via a postinstall script.

tavily-mcp pins axios: ^1.6.7, which resolves to the latest 1.x. During the 3-hour compromise window, that would have been 1.14.1. Any fresh npm install without a committed lockfile during that window would have pulled the compromised version.

This is exactly the class of supply chain attack that dependency scanning catches. Whether through this GitHub Action or through our out-of-band scanning service, regular dependency chain screening would flag malicious postinstall hooks like the one in plain-crypto-js@4.2.1.

Separately from this PR, we also offer out-of-band dependency chain reviews and daily monitoring with no CI integration needed. Happy to discuss if that would be a better fit for your workflow.