Automated Scanning with VulnHawk and Other Tools
Automated scanners test many inputs quickly and catch common issues before attackers do. VulnHawk is one such tool from the PandaDev ecosystem; open-source options include OWASP ZAP and Nuclei. Use them on applications you own or are authorised to test.
Types of automated security testing
| Type | Looks at | Examples |
|---|---|---|
| SAST (static) | source code | Bandit, Semgrep, CodeQL |
| SCA (dependencies) | libraries and versions | pip-audit, npm audit, Dependabot |
| DAST (dynamic) | the running app over HTTP | VulnHawk, OWASP ZAP |
| Secret scanning | code and history | GitHub secret scanning, gitleaks |
| Configuration | headers, TLS, DNS | header checkers, SSL Labs |
Each sees different problems; use several.
Running a dynamic scan safely
- Scan staging, not production, unless agreed: scanners submit forms and can create junk data or trigger emails.
- Use dedicated test accounts for authenticated scanning, one per role.
- Exclude destructive endpoints (delete account, send payment, logout) from active testing.
- Coordinate timing with whoever runs the infrastructure; scans can trigger rate limits and alerts.
What scanners find well
Missing security headers, outdated TLS configuration, reflected XSS, some injection, exposed files (.git, backups), known vulnerable versions, open redirects, cookie flags.
What they usually miss
Business-logic flaws: IDOR, privilege escalation, payment manipulation, race conditions, multi-step workflow abuse. These need human testing and the access-control test matrix from the earlier module.
Triage
For each finding:
- Reproduce it manually. Scanners produce false positives.
- Rate severity by real impact and exploitability.
- Fix the root cause, not just the reported URL; search for the same pattern elsewhere.
- Add a test that would catch a regression.
- Rescan to confirm.
Scanning in CI
Run SAST, dependency audits and secret scanning on every pull request; run a baseline dynamic scan against a preview or staging deployment before releases, failing the build on high-severity findings.
Exercise
Run a SAST tool, a dependency audit and a dynamic scanner against a local practice app or your own staging site. Triage every finding into true/false positive with severity, fix the true positives and document what the tools missed that manual testing found.
Check yourself
- Why scan staging rather than production?
- Which vulnerability classes do scanners usually miss?
- What are the five triage steps?
Tu progreso se guarda solo en este navegador.
Enviar para revisión (10 puntos)