OWASP security testing means checking your web application, API or mobile app against the guidance of the Open Worldwide Application Security Project: the Top 10 as a risk list, the Web Security Testing Guide (WSTG) as the test method, and the Application Security Verification Standard (ASVS) as the yardstick for “secure enough”. The three work together, and a good test uses all of them. This guide explains what each contributes, how SAST, DAST and penetration tests fit around them, and how to scope, buy and verify a test without paying for a scanner printout.

It is written for CEOs, VPs and directors of engineering. That includes teams in Poland, where customers, regulators and public tenders increasingly ask for a security test “according to OWASP” and rarely say what that means.

TL;DR

• The OWASP Top 10 is an awareness list of risks, not a test plan. The WSTG describes how to test, and the ASVS defines what to verify and at which level.
• SAST reads code and runs in the build. DAST attacks a running application in staging. A penetration test adds a human who chains weaknesses and proves business impact.
• Scope decides the value of a test: assets, knowledge model, attack vector, exclusions and rules of engagement must be written down before work starts.
• A report is only useful if it carries severity, affected items and developer-level remediation, and if fixes are retested.
• Treat security testing as a continuous practice in the delivery pipeline, with a manual test at major releases.

What OWASP actually gives you

OWASP is a nonprofit community, and most people meet it through one document. In practice you will use three.

OWASP Top 10. The Top 10 is a global reference standard for the most critical web application security risks, and OWASP recommends it as a first step toward a secure coding culture. The 2025 edition covers 248 CWEs across 10 categories. It introduced Software Supply Chain Failures as A03, widening the old “vulnerable components” category to dependencies, build systems and distribution infrastructure, and Injection moved down to fifth place.

Web Security Testing Guide (WSTG). The WSTG is described by OWASP as a premier testing resource for developers and security professionals. Its framework is a flexible set of testing activities that organizations adopt and adapt, rather than a checklist to be ticked off.

ASVS. The Application Security Verification Standard lists verifiable requirements at three levels. It is the document to cite in a contract, because it answers the question “tested against what?”. Always confirm the current version on OWASP’s site before you write it into a statement of work. A Polish public procurement specification, for example, required testing against ASVS 4.0.3 or equivalent, considering Levels 1 and 2. Newer versions have since appeared, so a pinned version number matters.

For mobile, OWASP’s Mobile Application Security project provides the standard, and the Developer Guide lists the MASTG among its verification guides.

A common mistake is to commission “a Top 10 test”. The Top 10 groups hundreds of weakness types into ten headings, so a report that merely says “no injection found” tells you little. A test mapped to WSTG test cases and an ASVS level tells you what was examined and what was not.

SAST, DAST and penetration tests: how they differ

The query that brings most engineers to this topic is “DAST vs SAST”. They are not rivals. They look at different things at different moments.

SAST: reading the code

Static application security testing scans source code for known vulnerability patterns. OWASP’s guidance is that these tools work best integrated into the development environment and build pipeline, so developers see findings while the change is still fresh. SAST is strong on injection patterns, hard-coded secrets and unsafe API use. It cannot see how the deployed system behaves, and it produces false positives that need triage.

DAST: attacking the running application

DAST is black-box testing against a running target, typically after the code is built and deployed to a test, staging or integration environment. Because it exercises the real system, it can find runtime and environment issues such as misconfiguration. It does not point to a line of code, and it only covers the paths the scanner manages to reach, which is a real limit for authenticated flows and complex business logic.

Penetration tests: a human who chains findings

A penetration test applies manual analysis of attack scenarios and controlled exploitation. The point is to show what an attacker could actually do with your data, not to list every theoretical weakness. A scanner will report a low-severity information leak and a medium-severity access check separately. A tester may combine them into account takeover. Authorization flaws and business-logic errors, which sit at the top of the OWASP list as Broken Access Control, are where manual work earns its cost.

This is also the answer to “application penetration tests” versus a vulnerability scan: a scan is an automated inventory of known issues, while a pentest is an adversarial exercise with judgment and proof of impact.

OWASP itself warns that security testing alone is not a good standalone measure and should be combined with code review, development guidance and other activities. That framing should shape your budget: the test is one control among several.

Where each test belongs in your delivery pipeline

OWASP’s guidance for teams is to use SAST and software composition analysis at build time, DAST in staging, and continuous monitoring after release, tailoring everything to project needs. It also stresses that developers should own security testing in their daily workflow rather than receive a report once a year.

A workable pattern for a product team looks like this:

1. Every commit: secret scanning, SAST and dependency checks, with failing builds only for high-severity, high-confidence findings so the pipeline does not become a bottleneck.
2. Every deploy to staging: an authenticated DAST scan against the new build, plus automated regression tests for authorization rules (can user A read user B’s record?).
3. Every quarter or major release: a manual review of high-risk features, such as new payment flows, file upload, SSO or a public API.
4. Every year or before a significant launch: a full penetration test scoped to ASVS Level 2 for typical business applications, Level 3 where a failure would be severe.
5. Always: monitoring and alerting. Logs nobody watches do not stop an incident.

The automated layers depend on solid delivery foundations. If your pipeline is still fragile, start with a scalable CI/CD framework for enterprise delivery and a sound test automation approach, since security gates are only as dependable as the pipeline that runs them. Functional tests also miss most security defects, because they check that the feature works for the intended user, not that it fails safely for a hostile one. Our overview of functional and non-functional testing for enterprises covers where security sits in that picture.

Testing APIs and mobile apps

Most modern products expose more through their APIs than through their web pages. Two habits matter.

First, test object-level and function-level authorization explicitly. Write regression tests that log in as two ordinary users and a administrator and assert which resources each can reach. These tests are cheap, run in CI, and catch the access-control regressions that cause most serious data exposure.

Second, include the API in the scope document with its schema. Testers working from an OpenAPI specification and test accounts for each role cover more ground than testers who have to discover endpoints.

For mobile apps, scope the app binary, its backend and the local data storage together, and use the OWASP mobile standard and MASTG as the reference rather than the web guide alone.

How to scope an application security test

Scope is where most tests succeed or fail. A useful scope document specifies assets, the knowledge model, the attack vector, exclusions and rules of engagement. In plain terms:

• Assets: which domains, applications, API versions, mobile builds and environments are in scope. Staging with production-like data is usually preferable to production.
• Knowledge model: black box (no information), gray box (test accounts and documentation) or white box (code access). Gray box typically gives the best findings per day of effort.
• Attack vector: external internet attacker, authenticated user, malicious insider, compromised partner.
• Exclusions: third-party services you have no right to test, denial-of-service, social engineering.
• Rules of engagement: testing windows, contact persons, emergency stop procedure, how found credentials and data are handled and stored, and how encrypted data is protected in transit and at rest. Reviewing how a vendor documents encryption and data protection is a good template for the questions to ask your tester.
• Standard and level: for instance, WSTG methodology and ASVS Level 2, with the version number written out.

A proportionate scope also decides depth. A marketing site needs a lighter touch than a platform processing health or legal data. The cost of a breach, including customer trust, belongs in the decision. Good background on that link is why website security protects brands and customer trust.

For teams selling into regulated Polish and EU sectors, customers may also expect testing evidence tied to frameworks like NIS2. Ask your legal and compliance leads which obligations apply to you, and write the resulting requirements into the scope.

What a good report contains, and why retest matters

The WSTG recommends that reports cover objectives, scope, findings and remediation summaries, technical descriptions, affected items and severity ratings. In practice, check for these before you accept a deliverable:

• An executive summary a board member can read in five minutes.
• Each finding with severity, reproduction steps, evidence and the affected endpoint or function.
• A statement of what was tested and what was not, against the agreed standard and level.
• Remediation advice that follows a prioritized approach based on real business risk, with technical recommendations that pinpoint affected functions and offer clear solutions for developers.
• A retest of fixed issues, with the result documented.

The last point is easy to skip and expensive to miss. A finding marked “fixed” by a developer is not the same as a finding verified as fixed. If you buy security testing through procurement, put the retest into the contract; we explain why in our piece on requiring retests in application security audits.

Our perspective

We see the same pattern in engineering organizations of every size: security testing is bought as an event and treated as a certificate. A test passes, the PDF goes to the customer, and the next release changes the attack surface the same week.

Our view is that OWASP works best when it is embedded in how software is built. Use the Top 10 to align the team on risks. Choose an ASVS level that matches the real consequences of failure. Let SAST, dependency checks and DAST run on every change, and keep manual testing for what automation cannot judge: authorization logic, multi-step abuse and new features. Insist on reports that a developer can act on within the sprint, and on retests that close the loop.

We also think the best security investment is rarely the most exotic one. Teams with reliable pipelines, clear environments and good test discipline find and fix problems faster than teams that rely on an annual audit. Security is an engineering quality, and it improves with the same habits that improve everything else: small changes, fast feedback, clear ownership.

— Vlad

How DevPulse can help

If you want an independent view of where your application stands before you commission a formal test, our technical audit and technology consulting team reviews architecture, code and delivery practices and helps you define a proportionate scope. Our quality engineering and DevOps engineering teams build the automated layers described above into your pipeline, so security checks run on every change instead of once a year. If your risk sits in an aging platform, legacy system modernization removes the components that are hardest to secure. To discuss your situation, request a consultation.

How to choose a testing partner

Whether you work with an internal team or an outside provider, ask these questions before signing:

• Which standard and which version will the test follow, and at which ASVS level?
• Who performs the manual work, and how much of the effort is manual versus automated?
• Will the report include proof of exploitation, severity rationale and developer-level remediation?
• Is a retest included, and within what period?
• How will test data, credentials and findings be stored, and who can access them?
• Can findings be exported into your issue tracker so they enter the normal sprint flow?

Be cautious of any offer that cannot answer the first and third questions. A provider that sells a scanner export as a penetration test leaves you with the findings an attacker would find first, and none of the ones they would find second.

Third-party risk applies as well. If development is outsourced, the supplier’s practices become part of your attack surface. Our guides on cybersecurity in IT outsourcing and common outsourcing risks list the controls worth requiring.

FAQ

What is the difference between DAST and SAST?

SAST analyzes source code without running it, so it fits in the IDE and the build and points developers to the exact line. DAST attacks a running application, usually in staging, and finds runtime and configuration problems. Most teams need both, plus manual testing for logic and authorization flaws.

Is a penetration test the same as an OWASP test?

Not exactly. OWASP supplies the methodology (WSTG), the risk list (Top 10) and the verification standard (ASVS). A penetration test is the activity, and a good one is performed against those references. Ask the provider which standard and level the report will map to.

How often should we test against the OWASP Top 10?

Run automated checks on every change and every staging deployment. Schedule a manual penetration test at least before major releases or significant architecture changes, and retest after fixes. The right rhythm also depends on your regulatory obligations and the sensitivity of the data you handle.

Which ASVS level do we need?

Level 1 is a baseline for lower-risk applications, Level 2 is the common choice for business applications handling sensitive data, and Level 3 is for the most critical systems. A Polish public tender specification, for instance, asked for ASVS 4.0.3 or equivalent at Levels 1 and 2. Confirm the current version and check what your customers or contracts require.

Sources

• OWASP Top 10 project
• OWASP Top 10:2025 Introduction
• OWASP Web Security Testing Guide project
• WSTG: The Web Security Testing Framework
• WSTG v4.1: Reporting
• OWASP Testing Guide v4
• OWASP Developer Guide
• Automated dynamic application security testing
• Polish procurement specification requiring OWASP ASVS 4.0.3
• Test scope guidance for IT security testing

Recommended

• Test Automation Quality Assurance: A 2026 Guide
• Quality Assurance Checklist: A Practical 2026 Guide
• Incident Management Process: A 2026 Implementation Guide
• Functional and Non-Functional Testing Guide for Enterprises