A practical approach to application security

Start with a shared scope

An assessment begins with the application and the question you need answered. Agree the assets, environments, roles, integrations, and business journeys in scope. Identify third-party dependencies, exclusions, and any constraints that affect coverage.

Before testing, establish written authorisation, permitted techniques, test windows, emergency contacts, and stop conditions. Agree how evidence will be handled and how urgent findings will be communicated. Retesting, deliverables, and timing belong in the engagement scope.

Select the right checks

Use a versioned test plan to make coverage reviewable. Relevant reference material includes:

OWASP WSTG v4.2: a catalogue of web application testing techniques.
OWASP ASVS 5.0.0: security requirements that can inform an agreed verification scope.
OWASP Top 10:2025: a way to communicate common web application risk categories.
OWASP API Security Top 10:2023: a reference for API-specific risks.

The Top 10 is not a complete penetration testing methodology. Applicability depends on the application. Identify what was tested, what was excluded, and what could not be verified; do not represent a partial assessment as full ASVS verification.

Validate and explain

Automated results are inputs to an investigation. A useful finding establishes the affected component, prerequisites, expected behaviour, observed behaviour, evidence, and impact. Keep test activity inside the authorised boundaries and use the minimum evidence needed to demonstrate the issue.

Distinguish confirmed findings from observations that need more investigation. Include the rationale behind severity and prioritisation, accounting for the application’s business context. If a numerical severity score is used, document its scoring version and assumptions.

Make remediation usable

A technical report should help the developer reproduce the issue and decide what to change. An executive summary should explain the material risks and limitations without requiring the reader to interpret raw tool output.

Useful deliverables include an assessed asset list, coverage summary, prioritised findings, remediation recommendations, and a record of assumptions and exclusions. A finding can be transferred into a work tracker with an owner and acceptance criteria.

Agree how to retest

Retesting checks whether an identified problem remains after a change. Record the tested version and environment, distinguish closed findings from partially resolved or unverified findings, and note any remaining risk. A retest does not automatically extend the original assessment to every new feature or code change.

Reference material

These references inform assessment planning. They do not imply endorsement, accreditation, or a guarantee that all vulnerabilities will be found.