feat: Add Dependency Risk Analyzer template

[AnsariUsaid]

🔒 Dependency Risk Analyzer

Automated security analysis for npm and Python dependencies.

Problem Statement

Developers waste hours manually auditing dependencies for security risks. Existing tools are either:

• Paid (Snyk)
• Limited (Dependabot only checks versions)
• Complex to set up

Solution

A free, comprehensive dependency risk analyzer that provides instant security reports.

Features

• ✅ Multi-ecosystem support (npm + Python)
• ✅ CVE detection via OSV.dev database
• ✅ Abandoned package detection (365+ days)
• ✅ Bus factor analysis (single-maintainer risk)
• ✅ License risk detection (GPL, AGPL)
• ✅ AI-generated markdown reports
• ✅ Risk scoring (0-100 scale)

Architecture

11-node flow with classifier logic, parallel ecosystem branches, loop-based package analysis, and LLM report generation.

Testing

Flow deployed and tested in Lamatic Studio with real package.json and requirements.txt files.

---

Submission for: Lamatic AgentKit Challenge

---

PR Checklist

1. Select Contribution Type

• Kit (kits/<category>/<kit-name>/)
• Bundle (bundles/<bundle-name>/)
• Template (templates/<template-name>/)

---

2. General Requirements

• PR is for one project only (no unrelated changes)
• No secrets, API keys, or real credentials are committed
• Folder name uses kebab-case and matches the flow ID
• All changes are documented in README.md (purpose, setup, usage)

---

3. File Structure (Check what applies)

• config.json present with valid metadata (name, description, tags, steps, author, env keys)
• All flows in flows/<flow-name>/ (where applicable) include:
  • config.json (Lamatic flow export)
  • inputs.json
  • meta.json
  • README.md
• .env.example with placeholder values only (kits only)
• No hand‑edited flow config.json node graphs (changes via Lamatic Studio export)

---

4. Validation

• npm install && npm run dev works locally (kits: UI runs; bundles/templates: flows are valid)
• PR title is clear
• GitHub Actions workflows pass (all checks are green) ← Will be checked by CI
• All CodeRabbit or other PR review comments are addressed and resolved ← Will address if raised
• No unrelated files or projects are modified

[coderabbitai]

Important

Review skipped

Auto reviews are limited based on label configuration.

🏷️ Required labels (at least one) (1)

• agentkit-challenge

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI (base), Organization UI (inherited)

Review profile: ASSERTIVE

Plan: Pro

Run ID: de713485-9d77-48e8-924e-421d6cbade7d

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

PR Validation Results

New Contributions Detected

• Template: templates/dependency-risk-analyzer

Check Results

Check	Status
No edits to existing projects	✅ Pass
Required root files present	✅ Pass
Flow folder structure valid	✅ Pass
No changes outside contribution dirs	✅ Pass

---

🎉 All checks passed! This contribution follows the AgentKit structure.

[d-pamneja]

Could you improve the schema for the input of the trigger node, so that the flow can run smoothly, else LGTM.

[d-pamneja]

Hi @AnsariUsaid
I noticed that all the Node.js cases are effectively being skipped because the flow treats triggerNode_1.output.file_content as a plain string but the Node path assumes it is already a parsed JSON object.
In codeNode_637 we currently do:

const pkg = {{triggerNode_1.output.file_content}};

const deps = {
  ...(pkg.dependencies || {}),
  ...(pkg.devDependencies || {})
};

However, file_content is defined in the trigger schema as a "string", so for Node inputs we’re passing raw JSON text (e.g. "{"dependencies":{...}}") rather than an object. That means pkg.dependencies and pkg.devDependencies are undefined, packages becomes an empty array, and the npm branch never actually iterates over any dependencies. The Python branch doesn’t hit this problem because it explicitly treats the input as text and splits it line by line.
To fix this, we should explicitly parse the Node input before reading dependencies:

const raw = {{triggerNode_1.output.file_content}};
const pkg = typeof raw === "string" ? JSON.parse(raw) : raw;

const deps = {
  ...(pkg.dependencies || {}),
  ...(pkg.devDependencies || {})
};

const packages = Object.entries(deps).map(([name, version]) => ({
  name: String(name),
  version: String(version).replace(/[\^~]/g, "")
}));

return { packages };

I’d also align codeNode_170 with this approach so both code paths treat file_content consistently: parse JSON for npm-style inputs and treat plain text as requirements.txt for Python. This should stop the NodeJS flow from “skipping” and actually produce risk reports for Node dependencies.