🧪 SAST/DAST & PenTesting

1START WITH VULNERABILITY ASSESSMENTS — automated, low cost, continuous. Deploy Qualys/Tenable to scan all assets monthly. This is your baseline.

2COMPLIANCE & GAP ASSESSMENT — if regulated (finance, healthcare), this is non-negotiable. Map controls to NIST CSF or ISO 27001. Identify gaps before auditors do.

3PENETRATION TESTING — quarterly or after major releases. Start with external network + web app pentests. Validates that vulns found by scanners are actually exploitable.

4APPLICATION SECURITY REVIEW — integrate SAST/DAST into CI/CD. Every code change gets scanned.

5PHISHING SIMULATION — monthly campaigns targeting all employees. Measure click rate, report rate.

6RED TEAM — annually for mature orgs. Tests detection and response, not just prevention.

7THIRD-PARTY RISK — assess all critical vendors. SolarWinds taught us supply chain is a top attack vector.

8CLOUD SECURITY — if cloud-first, quarterly CSPM reviews. Misconfigurations cause 80% of cloud breaches.

9IR READINESS — annual tabletop exercises. Test playbooks before you need them. Prioritize by: regulatory requirements → attack surface exposure → organizational maturity → budget.

2Reconnaissance: OSINT, DNS enumeration, technology fingerprinting, social media research.

3Scanning: Port scanning (Nmap), vulnerability scanning (Nessus), web crawling (Burp Suite).

4Exploitation: Attempt to exploit discovered vulnerabilities — injection, auth bypass, privilege escalation. Use frameworks like Metasploit, manual testing.

5Post-Exploitation: Assess impact — lateral movement, data access, persistence mechanisms.

6Reporting: Document findings with severity (CVSS), evidence (screenshots, PoC), and remediation recommendations.

7Remediation Verification: Re-test after fixes to confirm issues are resolved.

2Set rules of engagement: no DoS, no data destruction, no social engineering unless approved.

3Choose a platform: HackerOne, Bugcrowd, or self-hosted.

4Create a vulnerability disclosure policy (VDP).

5Define reward tiers: Critical ($2K-$10K+), High ($500-$2K), Medium ($100-$500), Low ($50-$100).

6Assign a triage team to validate, deduplicate, and prioritize reports.

7Establish SLAs for response and remediation.

8Start with a private program, then expand to public.

• Compile the app — Veracode needs compiled artifacts (.war, .jar, .dll)
• For interpreted languages (Python, JS, PHP), package source into a ZIP
• Exclude test files and third-party libs (those go through SCA)

• Upload via Veracode UI, CLI, or API
• In CI/CD, use Pipeline Scan (~90 seconds for PR checks) or Policy Scan (full depth for release gates)

• Veracode performs data flow analysis and taint tracking — traces untrusted input to dangerous operations
• Maps findings to CWE IDs

• Review findings with CWE ID, file/line number, data flow trace, and fix guidance
• Triage: confirm, mitigate, or mark false positive
• Track Veracode Level (VL1-VL

5for compliance.

Pipeline Scan in PRs, Policy Scan on main, break build on Critical/High findings.

Analyzes manifest files (package.json, pom.xml, requirements.txt, go.sum), builds full dependency tree including transitive dependencies, cross-references against NVD and Veracode's proprietary DB.

Agent-Based Scan in CI/CD, Upload Scan alongside SAST, IDE Plugin for real-time alerts, SCM Integration for auto-scanning PRs.

Known CVEs (e.g., Log4Shell), license risks (GPL vs MIT), outdated libraries, and vulnerable methods your code actually calls.

• Auto-suggests safe version upgrades, generates SBOM in CycloneDX/SPDX format
• KEY DISTINCTION: SAST finds bugs in YOUR code; SCA finds vulnerabilities in LIBRARIES you use
• Both are essential

• Configure browser proxy to Burp (127.0.0.1:8080), install CA cert for HTTPS interception, set target scope
• For authenticated scanning: record login sequence in session handling rules or use cookie/token injection

• Proxy Intercept to modify requests in real-time
• Repeater to replay/modify requests for SQLi, XSS, SSRF, IDOR
• Intruder for automated fuzzing with wordlists
• Comparer to diff responses

• Automated scanners miss business logic flaws — Burp's manual tools catch these
• Authenticated scans reach deeper functionality
• Secondary scans with different user roles test horizontal/vertical privilege escalation
• Burp Collaborator for out-of-band testing (blind SSRF, blind XSS)
• Key extensions: ActiveScan++, Autorize, Logger++
• Automated DAST catches ~60-70%; manual Burp testing catches the remaining business logic flaws that scanners fundamentally cannot detect

• Filter false positives by tracing data flow
• Prioritize by CVSS + EPSS + business context (internet-facing? handles PII?)
• Group findings by root cause — 50 XSS findings might stem from 1 missing output encoding library

Trace back to WHY the vulnerability exists — missing input validation framework? No parameterized query pattern? Insecure defaults? Often 1 root cause produces dozens of findings.

• Present in developer-friendly terms — show the vulnerable code, attack scenario, and fix (not just 'CWE-89')
• Use IDE integrations (Veracode Greenlight, SonarLint)
• Conduct pair-programming 'fix-it' sessions
• Create reusable secure coding patterns
• Never throw findings over the wall

• WAF virtual patches for immediate protection
• Code-level — parameterized queries, output encoding, CSP headers
• Architectural — centralized validation middleware

• Track MTTR by severity
• SLAs — Critical: 24-48 hrs, High: 7 days, Medium: 30 days
• Measure recurring vulnerability reduction over time

• False Positive — the scanner flagged something that is genuinely not a vulnerability
• Example — SAST flags SQL injection but the code uses a parameterized query through an ORM, so injection is impossible
• Mitigated by Design — the vulnerability technically exists in the code path but architectural controls make exploitation impossible
• Example — SAST flags hardcoded credentials in a test file that is excluded from production builds, or DAST finds a reflected XSS but a strict Content Security Policy blocks script execution

• Examine the data flow the tool traced — follow the source (user input) to the sink (dangerous function)
• Verify if input validation, encoding, or parameterization exists along the path that the scanner missed
• Common SAST false positives — ORM-generated queries flagged as SQL injection, encoded output flagged as XSS, dead code paths, test files

• Reproduce the finding manually — send the same payload the scanner used and verify if the vulnerability actually triggers
• Check if a WAF, CSP, or application-level control blocks the attack in practice

• Check if the vulnerable function in the library is actually called by the application (reachability analysis)
• Verify if the vulnerability applies to the deployment context

• Developer submits a mitigation request with evidence — code snippets showing the control, architecture diagrams, or test results proving non-exploitability
• Security engineer reviews the evidence independently — never approve based on developer assertion alone
• Document the decision with rationale, CWE ID, reviewer name, and expiration date
• Set mitigations to expire and require re-review (e.g., every 12 months)

• Track false positive rates per scanner and per application
• Periodically audit approved mitigations — sample 10% quarterly
• Never approve mitigated-by-design for Critical severity findings without a second reviewer

• MME (Mitigate by Mitigation, Mitigate by Environment) — these are Veracode mitigation categories where a finding is accepted because either a code-level mitigation exists that the scanner cannot detect (Mitigate by Mitigation) or network/infrastructure controls prevent exploitation (Mitigate by Environment — e.g., WAF rules, network segmentation, IP whitelisting)
• SbD (Secure by Design) — a formal process where the application architecture is reviewed upfront to confirm security controls are baked into the design rather than bolted on after scanning

• At each SDLC phase, specific security tasks must be completed and approved
• Design Phase — threat model review, security requirements sign-off, data classification
• Development Phase — SAST scan completion, SCA scan with no unapproved Critical/High findings, secure code review
• Testing Phase — DAST scan against staging, penetration testing for high-risk applications
• Pre-Production — all findings remediated or formally mitigated with approved MME requests, policy scan passing at required Veracode Level

• Verify the mitigation type is appropriate — Mitigate by Mitigation requires code evidence (show the sanitization, encoding, or parameterization the scanner missed)
• Mitigate by Environment requires infrastructure evidence (WAF rule screenshots, network diagram showing segmentation)
• Reject if evidence is insufficient
• Critical findings require a second AppSec reviewer plus manager approval

• Validate that the threat model covers all relevant attack vectors
• Confirm security controls are mapped to specific threats
• Review architecture diagrams for secure patterns — defense in depth, least privilege, secure defaults

• Financial regulators (OCC, FFIEC, MAS) require evidence of SDLC security controls
• Maintain separation of duties — the developer cannot approve their own MME request
• Track aging mitigations with expiration dates

MME submitted without evidence, Mitigate by Environment claimed without infrastructure controls, SCA finding mitigated when a patch is available — reject and require the upgrade.