arsenals 1.0.0

package/bin/arsenals.js

@@ -0,0 +1,53 @@
+#!/usr/bin/env node
+const fs = require('fs');
+const path = require('path');
+
+const args = process.argv.slice(2);
+const command = args[0];
+const skillName = args[1];
+
+const skillsRoot = path.join(__dirname, '..');
+const available = fs.readdirSync(skillsRoot, { withFileTypes: true })
+  .filter(e => e.isDirectory() && e.name !== 'bin' && !e.name.startsWith('.'))
+  .map(e => e.name);
+
+if (command === 'list') {
+  console.log('Available skills:');
+  available.forEach(s => console.log(`  - ${s}`));
+  process.exit(0);
+}
+
+if (command !== 'install') {
+  console.error('Usage:\n  arsenals install <skill-name>\n  arsenals list');
+  process.exit(1);
+}
+
+if (!skillName) {
+  console.error('Skill name required.\nAvailable:\n' + available.map(s => `  - ${s}`).join('\n'));
+  process.exit(1);
+}
+
+const sourceDir = path.join(skillsRoot, skillName);
+if (!fs.existsSync(sourceDir)) {
+  console.error(`Skill "${skillName}" not found.\nAvailable:\n` + available.map(s => `  - ${s}`).join('\n'));
+  process.exit(1);
+}
+
+const destDir = path.join(process.env.HOME, '.claude', 'skills', skillName);
+fs.mkdirSync(destDir, { recursive: true });
+
+function copyDir(src, dest) {
+  for (const entry of fs.readdirSync(src, { withFileTypes: true })) {
+    const srcPath = path.join(src, entry.name);
+    const destPath = path.join(dest, entry.name);
+    if (entry.isDirectory()) {
+      fs.mkdirSync(destPath, { recursive: true });
+      copyDir(srcPath, destPath);
+    } else {
+      fs.copyFileSync(srcPath, destPath);
+    }
+  }
+}
+
+copyDir(sourceDir, destDir);
+console.log(`Installed "${skillName}" → ${destDir}`);

package/cybersecurity-agent/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: cybersecurity-agent
+description: >
+  Use for ANY cybersecurity task involving repositories, codebases, or online accounts: scan for email
+  leaks/credential exposures (HaveIBeenPwned), find repo vulnerabilities (CVEs, OWASP Top 10, dependency
+  audits), SAST/DAST analysis, exposed secrets/API keys, dependency CVE audits, vector/AI/LLM security
+  issues, GitHub/GitLab misconfigurations, or a security report. Triggers on "check if my email was leaked",
+  "scan my repo", "find vulnerabilities", "security audit", "CVE check", "exposed secrets", "security review",
+  "pentest prep", or security + repo/email/codebase mentions. Also triggers on explicit "/devsecops" for a
+  PR/diff reviewer mode (Module G): a lighter, preventive checklist (authz, data exposure, injection, secrets,
+  deps, least privilege), never posted to GitHub/GitLab.
+---
+
+# Cybersecurity Agent Skill
+
+A comprehensive security analysis skill covering email leak detection, repository vulnerability scanning,
+dependency CVE auditing, secret/credential exposure, and AI/vector-specific attack surfaces.
+
+---
+
+## Workflow Overview
+
+```
+1. Identify Scope        → What are we scanning? (email, repo URL, codebase, dependency file)
+2. Select Checks         → Which modules apply? (see Module Index below)
+3. Gather Intelligence   → Run web searches, fetch advisories, query public databases
+4. Analyze & Report      → Structure findings by severity (Critical / High / Medium / Low / Info)
+5. Recommend Remediation → Actionable fix for each finding
+```
+
+Always start by asking (or inferring from context):
+- **Target**: email address, repo URL, package name, uploaded file, or codebase path
+- **Scope**: full audit vs. specific concern (leaks only? deps only? secrets only?)
+- **Urgency**: is this incident response or proactive hardening?
+
+---
+
+## Module Index
+
+| Module | When to use | Reference file |
+|--------|-------------|----------------|
+| A – Email Leak Detection | User provides email(s) to check | `references/email-leaks.md` |
+| B – Dependency CVE Audit | package.json / requirements.txt / pom.xml / Cargo.toml present | `references/dependency-cve.md` |
+| C – Secret & Credential Scan | Source code or repo to check for hardcoded secrets | `references/secret-scan.md` |
+| D – SAST / Code Vulnerability | Source code review for logic/security flaws | `references/sast.md` |
+| E – Repository Misconfiguration | GitHub/GitLab repo settings, CI/CD, branch protection | `references/repo-misconfig.md` |
+| F – Vector / AI Attack Surface | ML models, embeddings, vector DBs, LLM integrations | `references/vector-ai-security.md` |
+| G – DevSecOps PR Review | Explicit `/devsecops` invocation on a PR/diff | `references/pr-review.md` |
+
+Read the relevant reference file(s) before proceeding with that module.
+
+**Module G is different from A–F**: it only runs on explicit invocation (`/devsecops`,
+"devsecops review this PR/diff"), produces a shorter reviewer-style note instead of the
+full Security Report, and never posts anywhere — see `references/pr-review.md` for its
+own output format.
+
+---
+
+## Output Format
+
+Always produce a structured **Security Report** using this template:
+
+```
+## 🔐 Security Report — [Target]
+**Date**: [today]   **Scope**: [modules run]   **Risk Level**: [CRITICAL | HIGH | MEDIUM | LOW | CLEAN]
+
+---
+
+### Executive Summary
+[2-3 sentences: what was scanned, headline findings, immediate action needed]
+
+---
+
+### Findings
+
+#### [SEVERITY] — [Finding Title]
+- **Category**: [Email Leak | CVE | Hardcoded Secret | Code Flaw | Misconfiguration | AI/Vector]
+- **Location**: [file:line | endpoint | dependency name@version | breach source]
+- **Description**: [what the issue is and why it matters]
+- **Evidence**: [snippet, CVE ID, breach name, or search result citation]
+- **Remediation**: [exact steps to fix]
+- **References**: [CVE link, advisory, OWASP link, etc.]
+
+[repeat for each finding]
+
+---
+
+### Remediation Priority Queue
+1. [Critical items first]
+2. …
+
+---
+
+### Clean Checks
+[List checks that passed with no issues]
+```
+
+Severity scale:
+- 🔴 **CRITICAL** — Immediate exploitation risk, active breach, or leaked credentials in use
+- 🟠 **HIGH** — Serious vulnerability, easily exploitable
+- 🟡 **MEDIUM** — Requires specific conditions to exploit
+- 🔵 **LOW** — Defense-in-depth, best practice violation
+- ℹ️ **INFO** — Informational, no direct risk
+
+---
+
+## General Investigation Steps
+
+### For any target, always:
+
+1. **Web search** for recent CVEs, breach announcements, or security advisories related to the target
+2. **Cross-reference** findings with public databases (NVD, OSV, Snyk Advisor, HaveIBeenPwned)
+3. **Check GitHub** for known exploits or proof-of-concept code if a CVE is found
+4. **Fetch official advisories** when CVE IDs are identified
+5. **Cite every finding** with a source URL or database reference
+
+### Search query patterns:
+
+```
+Email leaks:      site:haveibeenpwned.com "[email]"
+                  "[email]" leaked OR breached OR exposed
+                  
+Dependency CVEs:  "[package]@[version]" CVE OR vulnerability OR exploit
+                  site:nvd.nist.gov "[package name]"
+                  site:osv.dev "[package ecosystem] [package name]"
+                  "[package]" security advisory [year]
+
+Repo issues:      "[repo name]" exposed secret OR API key OR credentials
+                  "[repo name]" CVE OR vulnerability [current year]
+                  
+Vector/AI:        "[framework]" prompt injection OR embedding attack OR model poisoning
+```
+
+---
+
+## Quick-Start Decision Tree
+
+```
+User says "check email X"          → Run Module A
+User pastes package.json / lockfile → Run Module B
+User pastes source code            → Run Modules C + D
+User gives GitHub URL              → Run Modules B + C + E (+ F if AI project)
+User mentions AI/LLM/vector DB     → Run Module F + relevant others
+User says "full audit"             → Run all applicable modules
+User says "/devsecops" or pastes
+  a PR/diff for security review    → Run Module G ONLY (not the full report format)
+```
+
+---
+
+## Ethics & Legal Reminder
+
+- Only scan targets the user owns or has explicit authorization to test
+- Do not attempt active exploitation — this skill is for **passive reconnaissance and advisory**
+- Do not share or store leaked credentials found in breach databases
+- For active penetration testing, recommend the user engage a licensed professional
+
+---
+
+## After the Report
+
+Always close with:
+1. **Top 3 immediate actions** (numbered, specific)
+2. **Offer to go deeper** on any specific finding
+3. **Suggest ongoing hygiene**: dependency update schedule, secret rotation policy, breach monitoring setup

package/cybersecurity-agent/references/dependency-cve.md

@@ -0,0 +1,130 @@
+# Module B — Dependency CVE Audit
+
+## Goal
+Identify known CVEs and security advisories in a project's dependencies across any ecosystem.
+
+---
+
+## Supported Ecosystems
+
+| File | Ecosystem | Audit Tool |
+|------|-----------|------------|
+| package.json / package-lock.json / yarn.lock | npm (Node.js) | `npm audit` |
+| requirements.txt / Pipfile / pyproject.toml | PyPI (Python) | `pip-audit` / `safety` |
+| pom.xml / build.gradle | Maven / Gradle (Java) | OWASP Dependency-Check |
+| Cargo.toml / Cargo.lock | crates.io (Rust) | `cargo audit` |
+| go.mod / go.sum | Go modules | `govulncheck` |
+| Gemfile / Gemfile.lock | RubyGems | `bundler-audit` |
+| composer.json | Packagist (PHP) | `local-php-security-checker` |
+
+---
+
+## Step-by-Step Process
+
+### 1. Parse the Dependency File
+Extract all direct and (if lockfile present) transitive dependencies with their pinned versions.
+
+### 2. Query Vulnerability Databases
+
+For each dependency, search:
+
+**OSV (Open Source Vulnerabilities — Google):**
+```
+web_fetch: https://api.osv.dev/v1/query  (POST with package name + ecosystem)
+web_search: site:osv.dev "[package name]" "[ecosystem]"
+```
+
+**NVD (National Vulnerability Database — NIST):**
+```
+web_search: site:nvd.nist.gov/vuln/search "[package name]"
+web_fetch: https://nvd.nist.gov/vuln/search/results?query=[package]
+```
+
+**Snyk Vulnerability Database:**
+```
+web_search: site:security.snyk.io "[package name]" "[version range]"
+```
+
+**GitHub Advisory Database:**
+```
+web_search: site:github.com/advisories "[package name]"
+```
+
+**PyPI / npm advisories (ecosystem-specific):**
+```
+web_search: "[package]@[version]" CVE security advisory
+web_search: "[package name]" npm audit vulnerability [year]
+```
+
+### 3. For Each CVE Found, Fetch Details
+```
+web_fetch: https://nvd.nist.gov/vuln/detail/[CVE-ID]
+web_search: [CVE-ID] exploit OR PoC OR patch
+```
+
+### 4. Check for Unpinned / Outdated Packages
+Flag packages using:
+- Wildcard versions (`^`, `~`, `*`, `>=`)
+- Versions more than 2 major releases behind latest
+- Deprecated packages (check npm/PyPI deprecation notices)
+
+---
+
+## CVE Severity Mapping (CVSS v3)
+
+| CVSS Score | Severity | Priority |
+|------------|----------|----------|
+| 9.0 – 10.0 | 🔴 CRITICAL | Fix immediately |
+| 7.0 – 8.9  | 🟠 HIGH | Fix within 7 days |
+| 4.0 – 6.9  | 🟡 MEDIUM | Fix within 30 days |
+| 0.1 – 3.9  | 🔵 LOW | Fix at next release cycle |
+
+---
+
+## Reporting Format for Each Vulnerable Dependency
+
+```
+**[package-name]@[current-version]**
+- CVE: [CVE-ID] (CVSS: [score] / [severity])
+- Affected versions: [range]
+- Fixed in: [version]
+- Attack vector: [Network | Local | Physical] — [description of exploit]
+- Remediation: `npm install [package]@[fixed-version]` (or equivalent)
+- Advisory: [URL]
+```
+
+---
+
+## Remediation Commands by Ecosystem
+
+```bash
+# Node.js
+npm audit fix          # auto-fix where possible
+npm audit fix --force  # force major upgrades (review breaking changes!)
+
+# Python
+pip install --upgrade [package]
+pip-audit --fix
+
+# Rust
+cargo update [crate]
+
+# Go
+go get [module]@[version]
+
+# Ruby
+bundle update [gem]
+```
+
+---
+
+## Supply Chain Attack Indicators
+
+Also flag these red flags (search for them):
+- Package name is very similar to a popular package (typosquatting)
+  ```
+  web_search: "[package-name]" typosquatting OR malicious OR removed
+  ```
+- Package was recently transferred to a new maintainer
+- Package has very few downloads but is pinned by a popular dependency
+- Install scripts (`preinstall`, `postinstall`) in package.json that execute code

package/cybersecurity-agent/references/email-leaks.md

@@ -0,0 +1,75 @@
+# Module A — Email Leak Detection
+
+## Goal
+Determine if one or more email addresses appear in known data breaches, paste sites, or credential dumps.
+
+---
+
+## Step-by-Step Process
+
+### 1. Primary Search — HaveIBeenPwned (HIBP)
+```
+web_search: site:haveibeenpwned.com "[email address]"
+web_fetch:  https://haveibeenpwned.com/account/[email]   (public lookup page)
+```
+Note: HIBP API requires a key; use web search to surface the public breach count and breach names.
+
+### 2. Breach Database Cross-Check
+Search these sources for the email or its domain:
+```
+"[email]" leaked OR breached OR "data breach" OR "credential dump"
+"[email domain]" breach 2023 OR 2024 OR 2025
+"[email]" pastebin OR ghostbin OR rentry
+```
+
+### 3. Domain-Level Breach Check
+If checking a corporate email, also check the domain:
+```
+"@[domain.com]" breach OR leak OR "database dump"
+site:haveibeenpwned.com "[domain.com]"
+```
+
+### 4. Dark Web Mention Check (OSINT)
+```
+"[email]" site:dehashed.com          (search results page, no login needed for metadata)
+"[email]" intext:password site:pastebin.com
+```
+
+### 5. Recent Breach News
+```
+web_search: "[email domain]" data breach [current year]
+web_search: major data breaches [current year] email leak
+```
+
+---
+
+## Interpreting Results
+
+| Signal | Severity | Action |
+|--------|----------|--------|
+| Email in active breach with password hash | 🔴 CRITICAL | Rotate password immediately, enable MFA |
+| Email in breach (no password) | 🟠 HIGH | Monitor, enable breach alerts |
+| Email in old breach (2+ years, password changed) | 🟡 MEDIUM | Confirm password was rotated |
+| Email domain in corporate breach | 🟡 MEDIUM | Check all employees, notify IT |
+| No breach found | ℹ️ INFO | Set up ongoing monitoring |
+
+---
+
+## Reporting Breach Details
+
+For each breach found, document:
+- **Breach name** (e.g., "LinkedIn 2021", "RockYou2024")
+- **Date of breach**
+- **Data exposed** (email, password hash, plaintext password, phone, SSN, etc.)
+- **Source** (HIBP, news article, security researcher report)
+- **Remediation**: which service to update, whether MFA is available
+
+---
+
+## Recommended Monitoring Tools to Mention
+
+- **HaveIBeenPwned.com** — free breach alerts by email
+- **Google One Dark Web Report** — monitors personal info on dark web
+- **Firefox Monitor** — HIBP-powered free alerts
+- **1Password Watchtower** — monitors saved credentials against breaches
+- **Dehashed.com** — deeper search (paid) for credential dumps

package/cybersecurity-agent/references/pr-review.md

@@ -0,0 +1,136 @@
+# Module G — DevSecOps PR Review
+
+## Goal
+Act as a DevSecOps reviewer on a pull request / diff. This is a **preventive, shift-left**
+mode — the point is to catch what a purely functional reviewer would miss, before merge,
+not to produce an incident-style audit. Runs only when explicitly invoked (`/devsecops`,
+"devsecops review this PR", "security review this diff").
+
+**Hard rule, no exceptions**: this module NEVER posts comments to GitHub/GitLab, opens
+review threads, or submits an approval/rejection on the platform. Output goes to the user
+in chat only. This mirrors the standing rule that no agent (including Veronica) auto-posts
+to PR conversations.
+
+---
+
+## Input
+
+Accepts, in order of preference:
+1. A diff / patch pasted or fetched (`git diff`, PR diff URL content, changed files)
+2. A PR URL — fetch the diff, don't infer from title/description alone
+3. Specific changed files if no diff is available
+
+If given a PR URL to a repo tool you have access to (GitHub connector, etc.), fetch the
+actual diff content — don't review based on the PR description alone.
+
+---
+
+## Review Checklist
+
+Work through changed files against this list. Only report what's actually present in the
+diff — don't flag hypothetical issues in unchanged code unless directly relevant to the change.
+
+### 1. Authorization on every new/changed endpoint or action
+- New route/controller/Action — is there a policy check, gate, middleware, or Filament
+  resource authorization guarding it?
+- Changed authorization logic — does the diff *narrow* or *widen* access? Widening access
+  is always worth flagging even if intentional.
+- IDOR: does a new endpoint accept an ID without checking the authenticated user owns/can
+  access that record?
+- New Filament resource/page — confirm `canViewAny`, `canView`, `canCreate`, `canEdit`,
+  `canDelete` are defined and not left at framework defaults if the resource is sensitive.
+
+### 2. Data exposure
+- New API resource / DTO / Filament table column — does it expose fields that shouldn't
+  leave the boundary (password hashes, tokens, internal IDs used for enumeration, other
+  users' PII)?
+- Logging — does the diff log request payloads, user objects, or exception context that
+  could contain PII, tokens, or secrets? (This is the exact failure mode behind the QA
+  email exposure incident — treat any new `Log::` / `logger()` call touching user data as
+  worth a close look.)
+- Error messages returned to the client — do they leak stack traces, internal paths, or
+  query details?
+
+### 3. Injection vectors
+- Raw DB queries (`DB::raw`, `whereRaw`, string-built SQL) with unescaped input
+- Unsafe `unserialize()` / dynamic class instantiation from user input
+- Shell exec (`exec`, `shell_exec`, `Process::run`) with unsanitized input
+- Blade `{!! !!}` unescaped output on user-controllable data
+- Mass assignment: new model fields — check `$fillable`/`$guarded` cover the new fields
+  correctly rather than defaulting to fully open
+
+### 4. Secrets in the diff
+- Hardcoded API keys, tokens, credentials, webhook URLs in code or config
+- New `.env.example` entries — confirm no real value was accidentally left in
+- New third-party integration — is the key going through config/env, not inline?
+
+### 5. Dependency changes
+- New `composer.json` / `package.json` entries — flag anything unfamiliar or with a
+  low download count / recent first-release for a quick CVE check (defer to Module B for
+  the actual audit if the user wants depth)
+- Version *downgrades* on existing dependencies — worth asking why
+
+### 6. Least privilege
+- New queue job, scheduled command, or service — does it request broader DB/API
+  permissions than it needs?
+- New Filament panel/resource — scoped to the right guard/tenant if this is a
+  multi-site admin panel context (relevant given the site-manager architecture)
+
+### 7. DDD/Actions-pattern specific (project convention checks)
+- Validation living in the Action/DTO boundary, not skipped because "the controller
+  already checked" — check the input is actually validated where it enters, not assumed safe
+- Domain logic not accidentally bypassing invariants via direct Eloquent calls where an
+  Action should be used instead
+
+---
+
+## Output Format
+
+This is a **reviewer's note**, not a full Security Report — shorter, PR-shaped, meant to be
+read once before deciding whether to comment/request changes yourself.
+
+```
+## 🔎 DevSecOps Review — [PR title / diff description]
+
+**Files reviewed**: [list or count]
+**Overall read**: [Looks safe to merge / Needs changes before merge / Needs a second look on X]
+
+---
+
+### Flagged
+
+#### [SEVERITY] — [short title]
+- **File**: [path:line]
+- **Issue**: [what's wrong, in reviewer language — the way you'd phrase it as a PR comment]
+- **Suggested fix**: [concrete, ideally a code-level suggestion]
+
+[repeat per finding, ordered by severity]
+
+---
+
+### Looked fine
+[Brief list — auth checks present, no secrets, deps clean, etc. Keeps the note honest
+about what was actually checked vs skipped.]
+
+---
+
+### Not posted anywhere
+These are for you to review and post yourself if you agree — nothing has been sent to
+GitHub/GitLab.
+```
+
+Severity scale matches the main skill: 🔴 CRITICAL / 🟠 HIGH / 🟡 MEDIUM / 🔵 LOW / ℹ️ INFO.
+For PR review, CRITICAL/HIGH should almost always mean "request changes"; MEDIUM/LOW can be
+framed as suggestions rather than blockers.
+
+---
+
+## What NOT to do in this mode
+
+- Don't run a full dependency CVE sweep or SAST pass unless asked — this is a targeted
+  diff review, not Module B/D's full audit. Offer to run those separately if the diff
+  touches a lot of dependencies or looks like it needs deeper analysis.
+- Don't comment on style, formatting, PHPStan/Pint issues, or non-security code quality —
+  that's not this module's job and dilutes the security signal.
+- Don't invent findings to seem thorough. An empty "Flagged" section is a valid, useful
+  result.