🧪 SAST/DAST & PenTesting
Static and dynamic application security testing, penetration testing methodologies, red teaming, bug bounty programs, and security assessment tools.
Overview
Security testing validates that applications, systems, and networks are resilient against attacks. It combines automated scanning (SAST/DAST/IAST) with manual expertise (penetration testing) to identify vulnerabilities before adversaries do. A mature security testing program integrates into CI/CD pipelines, runs continuously, and includes both internal assessments and external engagements.
Key Concepts
SAST (Static Analysis)
Analyzes source code, bytecode, or binaries without executing the application. Finds vulnerabilities early in the SDLC — SQL injection, XSS, buffer overflows, insecure crypto. Tools: SonarQube, Checkmarx, Semgrep, Fortify.
DAST (Dynamic Analysis)
Tests running applications by sending HTTP requests and analyzing responses. Discovers runtime vulnerabilities — authentication flaws, misconfigurations, injection attacks. Tools: Burp Suite, OWASP ZAP, Acunetix, Nuclei.
IAST (Interactive Analysis)
Combines SAST and DAST by instrumenting the application runtime. Provides real-time analysis with context about code paths and data flows. Tools: Contrast Security, Seeker.
Penetration Testing
Manual ethical hacking to discover complex vulnerabilities that automated tools miss. Follows methodologies: OWASP Testing Guide, PTES, OSSTMM. Includes black-box, gray-box, and white-box approaches.
Red Teaming
Simulates full adversary campaigns against an organization — not just technical exploits but also social engineering, physical access, and supply chain attacks. Tests people, processes, and technology holistically.
Bug Bounty Programs
Crowdsourced security testing where external researchers find and report vulnerabilities for rewards. Platforms: HackerOne, Bugcrowd, Synack. Requires clear scope, rules of engagement, and responsible disclosure policies.
Security Testing Pipeline
Security Testing in CI/CD Pipeline
From code commit through SAST, DAST, pen testing, to production
SAST vs DAST Comparison
| Aspect | SAST | DAST |
|---|---|---|
| When | During development (code review) | After deployment (running app) |
| Access | Source code / bytecode | HTTP interface (black-box) |
| Speed | Fast (minutes) | Slower (hours) |
| False Positives | Higher | Lower |
| Finds | Code-level bugs (injection, XSS) | Runtime issues (auth, config) |
| Languages | Language-specific | Language-agnostic |
| CI/CD Fit | Pre-build gate | Post-deploy gate |
Interview Preparation
What is the difference between SAST and DAST, and when would you use each?
SAST (Static Application Security Testing) analyzes source code without running the app — it finds vulnerabilities like SQL injection, XSS, and hardcoded secrets early in development. DAST (Dynamic Application Security Testing) tests a running application from the outside, discovering runtime issues like authentication bypass, misconfigurations, and session management flaws. Best practice: use SAST as a pre-commit/pre-build gate for fast feedback, and DAST as a post-deploy gate against staging environments. Combine both with IAST for the most comprehensive coverage. Neither replaces manual pen testing for business logic flaws.
Walk me through a penetration testing engagement from start to finish.
1) Scoping & Rules of Engagement: Define targets, exclusions, timeline, and communication protocols. 2) Reconnaissance: OSINT, DNS enumeration, technology fingerprinting, social media research. 3) Scanning: Port scanning (Nmap), vulnerability scanning (Nessus), web crawling (Burp Suite). 4) Exploitation: Attempt to exploit discovered vulnerabilities — injection, auth bypass, privilege escalation. Use frameworks like Metasploit, manual testing. 5) Post-Exploitation: Assess impact — lateral movement, data access, persistence mechanisms. 6) Reporting: Document findings with severity (CVSS), evidence (screenshots, PoC), and remediation recommendations. 7) Remediation Verification: Re-test after fixes to confirm issues are resolved.
How would you set up a bug bounty program?
1) Define scope: which assets are in-scope (web apps, APIs, mobile) and out-of-scope (third-party, production databases). 2) Set rules of engagement: no DoS, no data destruction, no social engineering unless approved. 3) Choose a platform: HackerOne, Bugcrowd, or self-hosted. 4) Create a vulnerability disclosure policy (VDP). 5) Define reward tiers: Critical ($2K-$10K+), High ($500-$2K), Medium ($100-$500), Low ($50-$100). 6) Assign a triage team to validate, deduplicate, and prioritize reports. 7) Establish SLAs for response and remediation. 8) Start with a private program, then expand to public.
Framework Mapping
| Framework | Relevant Controls |
|---|---|
| OWASP | Testing Guide v4, ASVS Verification Levels, Top 10 Testing, SAMM Security Testing |
| NIST | SP 800-53 CA (Assessment), SA (System Acquisition), RA (Risk Assessment) |
| MITRE | ATT&CK Tactics mapping for penetration testing scenarios and red team playbooks |