Security Testing Guide: OWASP, SAST, DAST & Pen Testing
Security testing identifies vulnerabilities in software before attackers can exploit them. It spans automated scanning — static analysis, dynamic analysis, and software composition analysis — through manual penetration testing by skilled security engineers. As software breaches cost organisations an average of $4.45 million per incident according to IBM’s Cost of a Data Breach 2023 report, security testing is not optional for any application handling user data.
The OWASP Foundation publishes and maintains the OWASP Top 10, the most widely adopted awareness document for web application security. The Google Testing Blog’s security series emphasises that security testing must shift left — integrated into development rather than performed as a separate phase. Teams that adopt continuous security testing detect and fix vulnerabilities at a fraction of the cost of post-release remediation.
The OWASP Top 10
The OWASP Top 10 represents the most critical security risks to web applications, updated approximately every three years based on data from hundreds of organisations and millions of applications. OWASP is not a standard but an industry consensus document that guides security testing priorities. Every security tester should be familiar with the Top 10 and know how to test for each category.
Broken Access Control — users accessing resources they should not — is the most prevalent risk, appearing in over 34 percent of tested applications. It includes privilege escalation, missing access controls on API endpoints, and path traversal vulnerabilities. Testing for broken access control involves attempting to access resources without proper authorisation — deleting another user’s data, viewing admin panels as a regular user, or modifying HTTP headers to bypass checks.
Cryptographic Failures encompass weak encryption algorithms, hardcoded cryptographic keys, exposed sensitive data in transit or at rest, and improper certificate validation. This category was formerly called “Sensitive Data Exposure.” Testing focuses on data classification — identifying which data is sensitive and verifying it is encrypted using modern algorithms with proper key management.
Injection — SQL, NoSQL, OS command, and LDAP injection — remains the most well-known vulnerability class. Parameterised queries and prepared statements prevent the vast majority of injection attacks. Testing injection requires systematically inserting special characters and payloads into input fields and observing the application’s response for signs of successful injection.
Types of Security Testing
SAST (Static Application Security Testing)
SAST analyses source code, bytecode, or binary code without executing it. It finds vulnerabilities early in the development lifecycle, often during coding or code review. SAST tools detect issues like SQL injection sinks, cross-site scripting reflections, hardcoded credentials, and insecure cryptographic usage. SAST tools vary in their false positive rates — CodeQL and Semgrep tend to produce fewer false positives than older tools — so teams should tune their SAST configuration over several months to suppress known false positives while maintaining detection coverage for genuine vulnerabilities.
# Semgrep for targeted SAST scanning
semgrep --config=p/python --config=p/owasp-top-ten \
--error --jobs=4 src/
# SonarQube analysis
sonar-scanner \
-Dsonar.projectKey=myapp \
-Dsonar.sources=src \
-Dsonar.host.url=https://sonarcloud.ioPopular SAST tools include Semgrep, SonarQube, Checkmarx, Fortify, and CodeQL.
DAST (Dynamic Application Security Testing)
DAST tests running applications by sending malicious payloads and observing responses. It does not require access to source code and detects vulnerabilities that only manifest at runtime — authentication flaws, session management issues, and configuration weaknesses. DAST is typically slower than SAST but produces fewer false positives because it tests against a running application. The OWASP ZAP project provides both automated scanning for CI/CD integration and an intercepting proxy for manual penetration testing.
# OWASP ZAP automated scan
zap-cli quick-scan \
--spider \
--scanners all \
--format json \
--output scan-report.json \
https://staging.example.comPopular DAST tools include OWASP ZAP, Burp Suite Professional, Acunetix, and HCL AppScan.
IAST and RASP
Interactive Application Security Testing (IAST) instruments the application to analyse interactions during testing, combining SAST and DAST advantages. Runtime Application Self-Protection (RASP) monitors application behaviour at runtime and blocks attacks. Both approaches provide real-time protection but require agent installation in the application runtime.
Penetration Testing
Penetration testing simulates real-world attacks to find exploitable vulnerabilities. Unlike automated scanning, penetration testing involves creative, manual exploration that follows the same thought processes as real attackers. The ISTQB Advanced Security Tester syllabus distinguishes between penetration testing and vulnerability scanning: scanning identifies known vulnerabilities, while penetration testing validates whether those vulnerabilities are actually exploitable in the specific context of your application and infrastructure. The standard methodology includes five phases: reconnaissance, scanning, exploitation, post-exploitation, and reporting.
Reconnaissance gathers information about the target through passive techniques — DNS enumeration, certificate transparency logs, search engine dorking, and social media mining. Scanning identifies open ports, running services, and potential vulnerabilities using tools like Nmap and masscan. Exploitation attempts to compromise the target through identified vulnerabilities using frameworks like Metasploit or custom exploits. Post-exploitation assesses the blast radius — what data can be accessed, what systems are reachable from the compromised host. Reporting documents findings with severity ratings, proof-of-concept exploit steps, and remediation recommendations.
Vulnerability Scanning
Automated vulnerability scanners check for known CVEs and common misconfigurations. These tools complement SAST and DAST by scanning the infrastructure and dependency layers. Container scanning tools like Trivy and Grype analyse Docker images for known vulnerabilities in base images and installed packages. Infrastructure scanning tools like Checkov and Terrascan validate Terraform and CloudFormation templates against security best practices.
Software Composition Analysis
SCA scans application dependencies for known vulnerabilities. Modern applications use hundreds of open-source libraries, each a potential attack vector. Tools like Snyk, Dependabot, Trivy, and Grype maintain databases of known Common Vulnerabilities and Exposures (CVEs) and alert when dependencies contain vulnerable versions.
Security Testing in CI/CD
Integrate SAST on every pull request to catch vulnerabilities before code enters the main branch. Run SCA on every commit to alert on newly disclosed CVEs in existing dependencies. Execute DAST on staging environments before releases to identify runtime vulnerabilities. Scan Docker images and infrastructure-as-code templates for misconfigurations and insecure defaults. The “shift left” movement in security — championed by the Google Testing Blog and OWASP — argues that finding vulnerabilities during development is an order of magnitude cheaper than finding them during security testing phases or after release. A vulnerability found in production costs on average $80,000 according to the IBM Cost of a Data Breach report; the same vulnerability caught during development costs approximately $800 to fix.
Best Practices
Shift security left — find vulnerabilities as early as possible. Use multiple testing approaches since no single technique catches everything. Keep dependencies updated since most breaches exploit known vulnerabilities with available patches. Follow the principle of least privilege for all service accounts and database users. Implement proper logging and monitoring to detect exploitation attempts. Conduct regular penetration tests, ideally quarterly or after major architectural changes.
Dynamic Analysis Tools
DAST (Dynamic Application Security Testing) tools scan running applications for vulnerabilities. OWASP ZAP and Burp Suite intercept HTTP traffic, test for injection attacks, and report vulnerabilities. Integrate DAST into CI/CD pipelines to catch security issues before deployment. Automated scanning complements manual penetration testing and covers common vulnerability classes systematically.
Fuzz Testing
Fuzz testing feeds invalid, unexpected, or random data to application inputs. Tools like AFL, libFuzzer, and OSS-Fuzz automate this process. Integrate fuzzing into CI for security-critical code paths — parsers, network protocols, and input handlers. Fuzz testing has found thousands of critical vulnerabilities in major software projects including the Linux kernel, OpenSSL, and systemd.
Test Environment Management
Test environments are a common bottleneck in quality assurance. Challenges: environment availability conflicts, configuration drift between environments, data inconsistency, and recreation time. Solutions: use infrastructure-as-code (Terraform, Pulumi, CloudFormation) to provision environments consistently. Containerize test environments with Docker Compose for reproducibility. Use ephemeral environments — spin up for each test run and destroy afterward. Production-like test data is essential: anonymized production data copies, synthetic data generation tools, and data masking for sensitive information. Database migration testing is often overlooked — test that migrations work both forward and backward. Environment monitoring tracks availability and alerts when issues arise.
Exploratory Testing Techniques
Exploratory testing complements automated testing by finding unexpected issues. Session-based test management structures exploratory testing into timed sessions with a charter (mission), notes, and bug reports. Heuristic testing uses rules of thumb to guide exploration: FEW HICCUPS (Functionality, Errors, Workflow, High-volume, Interrupts, Compatibility, Configuration, Usability, Performance, Security). Pair testing — two testers working together — combines different perspectives and catches more issues than solo testing. Charter-based testing defines a mission without detailed test cases, allowing testers to follow their curiosity within bounds.
FAQ
Q: What is the difference between SAST and DAST?
A: SAST analyses source code without execution, finding vulnerabilities during development. DAST tests running applications, finding runtime vulnerabilities. They complement each other.
Q: How often should I run penetration tests?
A: At minimum annually and after every major architectural change. Quarterly is recommended for applications handling sensitive data.
Q: Is OWASP ZAP sufficient for security testing?
A: ZAP is excellent for automated scanning and CI/CD integration but should be supplemented with manual penetration testing for thorough coverage.
Q: What is the most common security vulnerability?
A: Broken access control, which appears in over 34 percent of tested applications according to OWASP data.
Internal Links
- Read about Testing Fundamentals for the role of non-functional testing.
- Explore CI/CD Testing for integrating security scans into deployment pipelines.
- Learn about Performance Testing for understanding how security controls affect application performance.