An application security assessment is a scoped review of one application against a defined standard. You decide what is in scope, model the threats, test using several methods, rate and report the findings, and retest the fixes. A good one ends with changes made, not a PDF filed away.
What should you assess against?
Pick a standard so the result means something. OWASP's Application Security Verification Standard provides a basis for testing web application technical security controls and a list of requirements for secure development. The OWASP Web Security Testing Guide describes how to test, and its project page describes it as a testing resource for developers and security professionals. For the organization around the application, OWASP SAMM offers a measurable way to analyze and improve your software security posture.
What goes in the scope?
Write down the application, its environments, its APIs, the third-party services it depends on, and what is off limits. Include the data classes it handles and the users it has. If a production test could disrupt customers, agree on windows and a contact. Get written approval before testing anyone's systems.
Which methods find what?
No single method sees everything.
- Threat modeling finds design flaws before code exists, such as a missing authorization step.
- Static analysis of code finds injection paths, secrets and unsafe functions.
- Dependency analysis finds known-vulnerable libraries, and reachability helps decide which ones matter.
- Dynamic testing probes the running application for issues such as broken access control and misconfiguration.
- Manual testing finds business logic flaws, which scanners rarely catch, such as buying an item at a negative price.
- Configuration review covers headers, TLS settings, cloud permissions and secrets handling.
How should you rate and report findings?
For each finding, record where it is, how to reproduce it, what an attacker gains, and a suggested fix. Rate by impact and likelihood in your context, not by a score alone. Exposure matters: a flaw on a login page open to the internet outranks the same flaw on an internal admin tool. Check whether the vulnerable component appears in CISA's Known Exploited Vulnerabilities catalog, and add that to your rating.
Report in two layers: a one-page summary for decision makers and a detailed list for the engineers who fix things.
A constructed example
A company assesses its customer billing portal against ASVS controls on authentication, access control and input handling. Threat modeling shows invoices are fetched by numeric ID. A manual test confirms that changing the ID returns another customer's invoice, a broken access control flaw that no scanner reported. Static analysis finds two hard-coded keys. Dependency analysis lists 11 vulnerable libraries, of which three are reachable. The report ranks the ID flaw first, schedules key rotation the same day, and sets a two-week window for the reachable libraries. A retest a month later confirms all three fixed.
Who should do it?
Internal teams know the system and can assess often. External testers bring fresh eyes and skills your team may lack, and some customers and regulators expect independent testing. A sensible pattern is continuous automated checks run internally, with an independent manual assessment for important applications on a yearly basis or after large changes. Whoever does it, keep the tester separate from the author of the code where you can, and make sure someone owns the follow-up.
How to check or apply this
- Choose the standard and the target level, such as an ASVS level that fits the data's sensitivity.
- Write the scope, rules of engagement and approvals.
- Draw the data flows and list the trust boundaries.
- Run automated checks: code, dependencies, secrets, running app.
- Do manual testing on authentication, authorization and business logic.
- Rate each finding with context, and assign an owner.
- Fix, then retest, and record the retest result.
- Feed lessons into coding standards, templates and CI checks.
- Schedule the next assessment, and run lighter automated checks in between.
Safeguard's scanning, reachability analysis and policies can cover the automated half of this list.
Quick check
Is a penetration test the same as an assessment?
A pen test is one method inside an assessment. An assessment is broader and includes design review, code analysis and standards mapping.
How often should I assess an application?
After major changes and at least yearly for important applications, with automated checks running continuously in between.
Sources
- OWASP Application Security Verification Standard
- OWASP Web Security Testing Guide
- OWASP SAMM
- CISA Known Exploited Vulnerabilities Catalog
Last reviewed: 18 October 2026.
