Vulnerability Assessment — DevSecOps Scanning Protocol

Vulnerabilities exist in code, dependencies, configuration, and infrastructure. Your job is to FIND them, CLASSIFY them, and REPORT them — not fix them. Fixes are separate tasks.

Two Scanning Modes

Mode 1: Dependency Audit (sec_dependency_audit)

Scan project dependency files for known CVEs:

What to scan:

• Python: requirements.txt, pyproject.toml, setup.py
• Node: package.json, package-lock.json
• Docker: Dockerfile (base image versions)

Tools available:

• semgrep MCP server (if installed) — pattern-based scanning
• pip audit via Bash — Python CVE database
• npm audit via Bash — Node CVE database
• dependency-scanner sub-agent — isolated scanning without context bloat

Classification:

Severity	Criteria	Action
CRITICAL	Remote code execution, auth bypass, data exposure in production deps	fleet_alert(severity="critical", category="security") + security_hold + ntfy PO
HIGH	Privilege escalation, significant data leak, in production deps	fleet_alert(severity="high") + create fix task
MEDIUM	DoS potential, info disclosure, in non-production deps	Board memory [security, audit] + create task
LOW	Theoretical risk, dev-only deps, mitigated by other controls	Board memory only

Mode 2: Code Scan (sec_code_scan)

Scan source code for security anti-patterns:

Categories to check (per OWASP Top 10):

1. Injection — SQL, command, LDAP, XPath
2. Broken auth — hardcoded creds, weak session management
3. Sensitive data exposure — logging secrets, unencrypted storage
4. XML external entities — unsafe XML parsing
5. Broken access control — missing authorization checks
6. Security misconfiguration — debug mode, default credentials
7. Cross-site scripting — unescaped output
8. Insecure deserialization — untrusted data parsing
9. Known vulnerabilities — outdated libraries (overlaps with dep audit)
10. Insufficient logging — missing audit trail for security events

Tools:

• semgrep MCP — structured rule-based scanning
• secret-detector sub-agent — credential pattern matching
• security-auditor sub-agent — comprehensive OWASP audit

The Vulnerability Report

Structure your findings as a vulnerability_report artifact:

## Vulnerability Assessment: {project}
Date: {date}
Scope: {what was scanned}

### Critical Findings (0)
(none found)

### High Findings (2)
- [H-001] Dependency: requests 2.28.0 has CVE-2023-XXXXX (SSRF)
  Location: requirements.txt:5
  Recommendation: Pin to >= 2.31.0
  
- [H-002] Code: SQL interpolation in query builder
  Location: fleet/infra/db.py:142
  Pattern: f"SELECT * FROM {table}" — allows table name injection
  Recommendation: Use parameterized queries

### Medium Findings (1)
- [M-001] Configuration: DEBUG=True in production config template
  Location: config/app.yaml.template:3
  Recommendation: Set DEBUG=False, use environment variable

### Summary
Total: 3 findings (0 critical, 2 high, 1 medium)
Recommendation: Create fix tasks for H-001 and H-002 before next release.

When to Set security_hold

security_hold is a task custom field that prevents the task from being approved. Set it when:

• Critical vulnerability found in code the task touches
• Security requirement from your contribution was NOT followed
• Credentials or secrets detected in committed code

The hold is cleared when: the finding is resolved AND you verify the fix.

CRON Integration

Your nightly dependency scan CRON (nightly-dependency-scan in agent-crons.yaml) runs this skill automatically:

1. Scan all projects in config/projects.yaml
2. Classify findings
3. For critical: alert + security_hold + ntfy
4. For non-critical: board memory summary
5. Record trail

The CRON runs in an isolated session with proper model/effort. You don't need to remember to scan — the fleet's nervous system handles scheduling. Your job during heartbeat is to ACT on findings the CRON surfaced.