Vulnerability Scanner
Apply OWASP 2025-oriented threat thinking, checklists, and optional security_scan.py validation before release or during hardening sprints.
Overview
Vulnerability Scanner is an agent skill most often used in Ship (also Operate monitoring, Build backend hardening) that applies OWASP 2025-oriented checklists and optional security_scan.py validation for solo builders pr
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill vulnerability-scannerWhat is this skill?
- Security expert mindset: assume breach, zero trust, defense in depth, least privilege, fail secure
- OWASP Top 10:2025 risk framing plus linked checklists.md for auth, API, and data protection
- Pre-scan threat modeling: assets, actors, vectors, business impact
- Optional automated validation via scripts/security_scan.py against a project path
- Supply chain and attack-surface mapping called out in skill positioning
- OWASP Top 10:2025 risk categories framed in skill body
- Five core security principles table (assume breach through fail secure)
Adoption & trust: 855 installs on skills.sh; 40.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to ship or expose an API but lack a repeatable way to frame threats, map attack surface, and prioritize fixes beyond grep-for-secrets.
Who is it for?
Indie SaaS and API builders doing pre-launch security passes with agent-assisted checklist discipline.
Skip if: Regulated environments needing formal pen-test reports, or teams that only want dependency CVE scanning without access-control review.
When should I use this skill?
User needs advanced vulnerability analysis, OWASP-oriented review, supply chain awareness, or project security validation with security_scan.py.
What do I get? / Deliverables
You leave with threat-model answers, OWASP-aligned review coverage, and optional script-backed validation paths so fixes target highest business risk first.
- Threat-model answers (assets, actors, vectors, impact)
- OWASP-aligned findings and prioritized risk notes
- Optional security_scan.py validation output
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Security review is canonically shelved under Ship because solo builders run it before launch prep and alongside review gates—not only after incidents. The `security` subphase covers vulnerability analysis, access control, and supply-chain risk—not generic unit testing.
Where it fits
Walk OWASP access-control and API checklists before enabling public signup on a solo SaaS.
Pair the skill with a PR review to flag authz gaps and data-protection omissions.
Re-run threat questions after adding a third-party OAuth provider or new admin routes.
How it compares
Use as a structured review playbook with optional local scan—not a hosted DAST appliance or WAF replacement.
Common Questions / FAQ
Who is vulnerability-scanner for?
Solo developers and small teams shipping SaaS, APIs, or CLIs who want OWASP-aligned vulnerability analysis principles embedded in their coding agent workflow.
When should I use vulnerability-scanner?
In Ship security before launch; in Ship review when auditing auth and APIs; in Operate iterate when investigating exposure after architecture changes.
Is vulnerability-scanner safe to install?
It may run local Python scan scripts against your repo—review the Security Audits panel on this page and read scripts/security_scan.py before executing in production machines.
SKILL.md
READMESKILL.md - Vulnerability Scanner
# Vulnerability Scanner > Think like an attacker, defend like an expert. 2025 threat landscape awareness. ## 🔧 Runtime Scripts **Execute for automated validation:** | Script | Purpose | Usage | |--------|---------|-------| | `scripts/security_scan.py` | Validate security principles applied | `python scripts/security_scan.py <project_path>` | ## 📋 Reference Files | File | Purpose | |------|---------| | [checklists.md](checklists.md) | OWASP Top 10, Auth, API, Data protection checklists | --- ## 1. Security Expert Mindset ### Core Principles | Principle | Application | |-----------|-------------| | **Assume Breach** | Design as if attacker already inside | | **Zero Trust** | Never trust, always verify | | **Defense in Depth** | Multiple layers, no single point | | **Least Privilege** | Minimum required access only | | **Fail Secure** | On error, deny access | ### Threat Modeling Questions Before scanning, ask: 1. What are we protecting? (Assets) 2. Who would attack? (Threat actors) 3. How would they attack? (Attack vectors) 4. What's the impact? (Business risk) --- ## 2. OWASP Top 10:2025 ### Risk Categories | Rank | Category | Think About | |------|----------|-------------| | **A01** | Broken Access Control | Who can access what? IDOR, SSRF | | **A02** | Security Misconfiguration | Defaults, headers, exposed services | | **A03** | Software Supply Chain 🆕 | Dependencies, CI/CD, build integrity | | **A04** | Cryptographic Failures | Weak crypto, exposed secrets | | **A05** | Injection | User input → system commands | | **A06** | Insecure Design | Flawed architecture | | **A07** | Authentication Failures | Session, credential management | | **A08** | Integrity Failures | Unsigned updates, tampered data | | **A09** | Logging & Alerting | Blind spots, no monitoring | | **A10** | Exceptional Conditions 🆕 | Error handling, fail-open states | ### 2025 Key Changes ``` 2021 → 2025 Shifts: ├── SSRF merged into A01 (Access Control) ├── A02 elevated (Cloud/Container configs) ├── A03 NEW: Supply Chain (major focus) ├── A10 NEW: Exceptional Conditions └── Focus shift: Root causes > Symptoms ``` --- ## 3. Supply Chain Security (A03) ### Attack Surface | Vector | Risk | Question to Ask | |--------|------|-----------------| | **Dependencies** | Malicious packages | Do we audit new deps? | | **Lock files** | Integrity attacks | Are they committed? | | **Build pipeline** | CI/CD compromise | Who can modify? | | **Registry** | Typosquatting | Verified sources? | ### Defense Principles - Verify package integrity (checksums) - Pin versions, audit updates - Use private registries for critical deps - Sign and verify artifacts --- ## 4. Attack Surface Mapping ### What to Map | Category | Elements | |----------|----------| | **Entry Points** | APIs, forms, file uploads | | **Data Flows** | Input → Process → Output | | **Trust Boundaries** | Where auth/authz checked | | **Assets** | Secrets, PII, business data | ### Prioritization Matrix ``` Risk = Likelihood × Impact High Impact + High Likelihood → CRITICAL High Impact + Low Likelihood → HIGH Low Impact + High Likelihood → MEDIUM Low Impact + Low Likelihood → LOW ``` --- ## 5. Risk Prioritization ### CVSS + Context | Factor | Weight | Question | |--------|--------|----------| | **CVSS Score** | Base severity | How severe is the vuln? | | **EPSS Score** | Exploit likelihood | Is it being exploited? | | **Asset Value** | Business context | What's at risk? | | **Exposure** | Attack surface | Internet-facing? | ### Prioritization Decision Tree ``` Is it actively exploited (EPSS >0.5)? ├── YES → CRITICAL: Immediate action └── NO → Check CVSS ├── CVSS ≥9.0 → HIGH ├── CVSS 7.0-8.9 → Consider asset value └── CVSS