Security Scan

Core Principles

1. Defense in depth — Scan multiple layers: packages, source code, configuration, and infrastructure. A project with zero CVEs can still have hardcoded secrets, SQL injection, and missing auth. Each layer catches different vulnerability classes.

2. Prioritize by exploitability — A Critical SQL injection in a public endpoint is more urgent than a Low-severity info disclosure in an admin-only page. Prioritize findings by: exploitability (how easy to exploit), impact (what an attacker gains), and exposure (public vs internal endpoint).

3. No false sense of security — This is static analysis, not a penetration test. It catches known patterns but misses business logic flaws, authorization bypass through complex flows, and runtime-only vulnerabilities. State this clearly in every report.

4. Actionable findings — Every issue includes severity, file and line, description of the vulnerability, impact if exploited, and specific remediation code. "Fix the security issue" is not a finding. "OrderController.cs:23 — Missing [Authorize] on DELETE /orders/{id}. Impact: unauthenticated users can delete orders. Fix: Add [Authorize(Policy = \"OrderAdmin\")]" is.

5. Follow OWASP Top 10 — Structure the scan around known vulnerability categories. The OWASP Top 10 is the industry baseline for web application security. Every finding should map to an OWASP category.

Patterns

6-Layer Security Scan Pipeline

Execute all 6 layers. Each produces findings rated Critical, High, Medium, or Low.