Vulnerability Scanning vs. Penetration Testing
| Property | Vulnerability Scanning | Penetration Testing |
|---|---|---|
| Goal | Identify potential weaknesses | Confirm weaknesses are exploitable; measure actual impact |
| Exploitation | None — scanning only; no attacks launched | Active exploitation of confirmed vulnerabilities |
| Invasiveness | Minimally invasive; production-safe in most cases | Intentionally invasive; can crash services, modify data |
| Output | List of potential vulnerabilities by severity | Confirmed vulnerabilities + attacker pathway demonstration |
| Frequency | Continuous or regularly scheduled (weekly, monthly) | Periodic engagements (annual, post-major-change) |
| Analogy | Checking which doors are unlocked | Walking through the unlocked doors and mapping what's inside |
Internal vs. External Scanning — Two Perspectives
| Property | External Scan | Internal Scan |
|---|---|---|
| Scan position | Outside the network perimeter (internet-facing) | Inside the network perimeter |
| Attacker model | External attacker with no prior access | Insider threat, compromised account, or post-breach lateral movement |
| What it finds | Internet-facing services, open ports on public IPs, exposed APIs, public-facing servers | Internal devices (workstations, printers, databases), shadow IT, unauthorized devices, internal-only services |
| Common misconception | — | "We don't need internal scanning because we have a firewall" — false; insiders and post-breach attackers operate inside the perimeter |
| Required together? | Yes — external alone misses internal vulnerabilities; internal alone misses internet-facing exposure. Both are required for complete coverage. | |
SAST — What It Finds vs. What It Misses
| Category | SAST Can Find | SAST Cannot Find |
|---|---|---|
| Memory safety | Buffer overflow patterns, unsafe C functions (strcpy, gets, sprintf) | Heap corruption that only manifests with specific runtime inputs |
| Injection | SQL string concatenation patterns, unescaped output to HTML context | Second-order injection where stored data is used safely in one place but unsafely in another |
| Credentials | Hardcoded passwords, API keys in source code | Credentials passed at runtime via environment variables (not in code) |
| Cryptography | Use of deprecated algorithms (MD5, SHA-1, DES) | Correct algorithm used incorrectly (AES-ECB mode, wrong IV reuse, improper key management) |
| Authentication | Missing authentication checks on individual routes (sometimes) | Authentication design flaws — race conditions, session predictability, token entropy issues |
| Business logic | Nothing — SAST does not understand business intent | All business logic vulnerabilities (price manipulation, workflow bypass, privilege escalation through intended features) |
Fuzzing — Synonyms and Anomalous Response Indicators
| Category | Details |
|---|---|
| Synonyms for fuzzing on the exam | Fault injection, robustness testing, negative testing, syntax testing — all describe submitting unexpected input to observe behavior |
| What a fuzzer submits | Random data, boundary values (0, -1, MAX_INT, empty string, null), oversized input, malformed structure, encoding variants, protocol-invalid sequences |
| Anomalous responses that indicate a vulnerability | Application crash or segfault, unhandled exception with stack trace, HTTP 500 server error where 400 was expected, memory corruption indicators, timeout or freeze, unexpected output (data leak) |
| Why anomalous response = potential vulnerability | Crash or error on malformed input reveals the code path that an attacker would seek to control — buffer overflow, null dereference, logic error. The same crash an attacker would try to trigger and exploit. |
| Fuzzing is dynamic — application must be running | Complements SAST (static, no execution needed). Together they cover different vulnerability classes. |
| Historical origin | 1988, University of Wisconsin, Professor Barton Miller, "OS Utility Program Reliability" course — the Fuzz Generator project demonstrated random input reliably exposed UNIX utility flaws |
| CERT BFF | CERT Basic Fuzzing Framework — Carnegie Mellon University; structured, accessible fuzzing environment for organizational use |
Package Monitoring — Supply Chain Verification Techniques
| Technique | How It Works | What It Detects |
|---|---|---|
| Digital signatures | Package maintainer signs the release with their private key; consumer verifies with maintainer's public key before installation | Packages modified after publication; packages from unexpected sources |
| Hash validation | Compare SHA-256 (or SHA-512) hash of downloaded file against hash published by maintainer on official channel | Any modification to the file — even a single byte changes the hash |
| Repository authentication | Confirm download came from official repository, not a mirror, fork, or third-party host | Typosquatting packages, unofficial forks with injected code, compromised mirrors |
| Lab testing before production | Deploy package in isolated environment; observe behavior before production rollout | Malicious behavior that static checks miss; unexpected network connections, file system changes |
| Continuous CVE monitoring | Tools (OWASP Dependency-Check, Dependabot, Snyk) track all installed dependencies against CVE databases; alert when a CVE is published for an installed version | Known vulnerabilities in currently installed dependency versions; eliminates gap between "CVE disclosed" and "organization aware" |
Vulnerability Severity Triage — The Post-Scan Workflow
| Step | Action | Why It Matters |
|---|---|---|
| 1. Review findings | Examine each scanner finding individually; understand what the scanner detected | Scanners generate hundreds of findings across many systems; raw output is not actionable without review |
| 2. Verify against actual system | Confirm the vulnerability exists as reported; check whether compensating controls apply | Eliminates false positives before remediation is scheduled; prevents wasted patching effort |
| 3. Classify severity | Rate each confirmed finding: Critical, High, Medium, Low, or Informational | Not all vulnerabilities are equal; severity drives remediation timeline |
| 4. Prioritize by exploitability and context | Critical/High findings on internet-facing or data-holding systems get immediate attention; Medium/Low addressed in scheduled maintenance | Attempting to fix everything simultaneously is operationally infeasible; prioritization makes remediation sustainable |
| 5. Remediate and rescan | Apply patches, configuration changes, or workarounds; rescan to confirm resolution | Remediation without verification leaves false confidence; rescan closes the loop |