Application Security Testing (AST)
Most services an organization offers today run through applications: internet banking, mobile apps, citizen portals, partner APIs. Application security testing checks those applications for flaws an attacker could use to steal data or misuse the service. Done well, it becomes a routine step before every release instead of an emergency after a breach.
What the service includes
AST is an umbrella term. It brings together several kinds of checks, and each finds different problems.
Static analysis (SAST) reads the source code without running it and looks for insecure patterns. Dynamic testing (DAST) attacks the running application from the outside, as a user or attacker would. Interactive testing (IAST) watches the application from the inside while it is being tested, which helps pinpoint the exact line of code behind a problem. Software composition analysis (SCA) lists the open-source components your application depends on and flags any with known weaknesses.
Tools such as Checkmarx, Semgrep, Burp Suite and OWASP ZAP give breadth. Our specialists then test by hand for the things tools cannot judge, such as a checkout that lets a customer change the price, or a login step that can be skipped.
When it is worth doing
AST suits organizations that release software often and want every release checked, including the small ones. It also makes sense before launching a new app, after a major rewrite, or when a regulator or enterprise customer asks how you test your applications.
If you need one deep, attacker’s-eye look at a single system before go-live, a penetration test may be the better fit. Many clients use both.
How much should the testers be told?
That depends on what you want to learn. In a black box test, testers get no inside information. It shows exactly what an outsider sees, but can miss deeper problems. In a grey box test, they receive user accounts and some documentation, which is the usual balance of cost and depth. In a white box test, they get the source code and architecture documents. It takes more effort and gives the most thorough result, so it suits regulated or high-value releases.
Testing can happen once per release, or be built into your CI/CD pipeline (the automated process that builds and ships your software). In the second case, a serious finding stops the release automatically.
A typical engagement
We start by identifying the user journeys and data that matter most, such as login, payments and personal data, and where trust changes hands between systems. Automated tools are configured for your technology.
Specialists then work through test cases based on OWASP ASVS, the open standard for application security requirements. They cover login, access rights, input handling, encryption and business logic. Each finding is rated using CVSS and the OWASP Risk Rating, adjusted for what it would mean for your business. Developers receive clear fix guidance for each issue.
What you are left with
- A report with an executive summary, evidence for each finding and fix guidance.
- An OWASP ASVS coverage summary showing which security requirements the release meets.
- Mapping of findings to ISO/IEC 27001:2022, SOC 2 and PCI DSS.
- Retest results confirming which issues are closed.
For teams that want the reference points, the work also follows OWASP WSTG and aligns with the NIST Secure Software Development Framework (SSDF). Request an application security testing proposal to talk through your release schedule.