What application security testing covers
Application security testing is the set of checks a software company runs on its own product to find vulnerabilities before an attacker does. It covers four different things: the code the company's developers write, the open source libraries they bring in, the application as it is actually deployed, and the design decisions people make when they build a feature. Each of these fails in a different way, so no single technique covers all four.
Static testing reads code without running it, dependency scanning checks third party components against known vulnerabilities, dynamic testing probes the running system from outside, and human review judges logic and design. The blind spots of each method are covered by another, which is why the useful question is never which tool a company bought. It is how the methods fit together, how often they run and what happens to their findings.
For a company that already holds a certification, the question usually arrives in one of two ways. An auditor asks for evidence that security testing happens during development and before release, or an enterprise customer's security questionnaire asks whether the company runs SAST and DAST, how often, and what it does with the results. Both are asking for the same thing: proof of a process that finds problems and fixes them, applied to every release rather than to a demonstration.
- SAST. What it examines: source code, without running it. Finds well: injection flaws, unsafe functions, hardcoded secrets. Misses: runtime configuration, business logic.
- SCA. What it examines: third party libraries and their versions. Finds well: known vulnerabilities in dependencies. Misses: flaws in the company's own code.
- DAST. What it examines: the running application, from outside. Finds well: misconfiguration, missing headers, exposed endpoints. Misses: paths it cannot reach.
- Code review. What it examines: changes, read by a person. Finds well: authorisation logic, design flaws. Misses: volume, since nobody can read everything.
SAST: reading the code before it runs
Static application security testing analyses source code, or compiled code, for patterns that indicate a vulnerability. Because it needs no running environment, it can run on every commit or pull request, which makes it the earliest automated check in the development cycle. It is particularly good at flaws with a recognisable shape: user input reaching a database query without parameterisation, unsafe deserialisation, weak hashing functions, or credentials written directly into source files. Its findings point to the exact file and line, often with the affected code, so a developer can act on them without a security specialist translating the result.
Its limits are well documented, and OWASP's own guidance on these tools is candid about them. Static analysis can automatically identify only a relatively small share of application security flaws, it produces a high number of false positives, and some categories are very hard to automate at all, notably authentication and access control problems. A SAST tool cannot know that a user from customer A must never see customer B's invoices. That rule lives in the business, not in the syntax, and no amount of pattern matching will find its absence.
False positives are the practical problem, and they decide whether SAST is useful or ignored. A first scan of a codebase with a few years of history can return hundreds of findings, and a team that has to sort them all by hand quickly stops reading the reports. The value of SAST depends almost entirely on tuning: disabling rules that do not apply to the company's stack, marking accepted findings so they stop reappearing, and agreeing which severities block a release. A tool that cries wolf on every pull request is worse than no tool, because it teaches developers to click past warnings.
The pattern that works in most teams is to scan every pull request but report only the findings that change introduces, and to block the merge only on critical or high severity issues. The backlog of older findings is handled separately, as a prioritised list with owners and dates, worked through alongside normal development. This keeps new code clean from the first day without asking developers to fix years of history before they can ship anything, and it gives an auditor a clear story: new risk is stopped at the door, old risk is being reduced on a plan.
Dependencies and secrets: the code nobody on the team wrote
Most of the code running in a modern web application comes from open source libraries rather than from the company's own developers, and each of those libraries brings its own dependencies. Software composition analysis (SCA) inventories all of them, down to the exact versions, and checks them against databases of published vulnerabilities. It answers a question SAST cannot: is any component the company ships affected by a flaw that is already public?
That question becomes urgent every time a critical vulnerability is disclosed in a widely used library. The first thing customers and auditors ask is whether the company is affected and how quickly it knew. A team with SCA in its pipeline can answer in minutes and show the upgrade it made. A team without it starts searching repositories by hand, often across services nobody has touched in a year, while customers wait for an answer. Most dependency findings are also cheap to fix, since the remedy is usually an upgrade, which is why SCA tends to deliver the fastest reduction in risk of any testing method.
The same inventory produces a software bill of materials (SBOM), a machine readable list of every component and version in a release. The SBOM is moving from good practice to requirement. The Cyber Resilience Act requires manufacturers of products with digital elements to identify and document the components in their products, and enterprise customers increasingly ask for an SBOM during procurement so they can run their own checks when the next library vulnerability is announced.
Secrets scanning covers a related and very common failure: API keys, passwords, tokens and private keys committed to source control. A credential in a repository stays in the history even after the line is deleted, so the only real fix is to rotate the secret, not just remove it from the code. Scanning before each commit stops new secrets from entering the repository, and scanning the full history once finds the ones already there. Leaked credentials in code are one of the most frequent ways into cloud environments, and closing this route is quick compared with almost any other control.
DAST: testing what is actually deployed
Dynamic application security testing sends requests to a running application and analyses the responses, much as an automated attacker would. It needs no access to source code and sees the application exactly as it is deployed, including the web server, the framework configuration and the infrastructure in front of it. That makes it the natural complement to SAST: one reads what the developers intended, the other tests what is actually running.
DAST catches problems that only exist at runtime. Typical findings include missing security headers, error pages that reveal stack traces and internal paths, cookies without the right security flags, outdated TLS configuration and administration interfaces that should never have been reachable. It also finds injection flaws that static analysis missed because the vulnerable behaviour came from configuration rather than code. And it confirms that a fix actually works once deployed, which no code scan can do.
Its main limitation is reach: DAST can only test what it can get to. Areas behind a login, multistep workflows and APIs without documentation have to be configured explicitly, with test accounts and API definitions, otherwise the scan covers little more than the login page and the marketing site. This is the most common reason a DAST report looks clean while the application is not. When a customer or auditor reviews DAST evidence, the first question worth answering in advance is which parts of the application the scan actually authenticated into.
DAST is also slower than static analysis and more intrusive, so it should run against a staging environment that mirrors production rather than against live customer data. A weekly scheduled scan of staging, plus a scan before each major release, is a common rhythm that is easy to justify to an auditor. Findings go into the same triage process as everything else, with the same severity rules and fix timeframes.
Code review and the flaws tools cannot see
Every change merged into a production branch should be read by someone other than the person who wrote it. Peer review is primarily a quality practice, but it is also the only control that reliably catches the vulnerabilities automated tools miss, because the most damaging flaws in business software are usually logic errors rather than coding mistakes.
Consider the kind of issue that ends up in an incident report: an endpoint that checks the user is logged in but not that the record they request belongs to their organisation, a discount that can be applied twice, a role that can approve its own request, an export function that ignores the permissions applied on screen. These appear in the OWASP Top 10 under broken access control, and they are invisible to pattern matching. A reviewer who understands the product can spot them quickly, provided they are looking. A short security checklist on every pull request (authorisation checked, input validated, no secrets, sensitive actions logged) makes review more consistent without making it slower.
Some changes deserve more than peer review. New authentication flows, changes to payment or permission logic, new integrations that handle customer data and new public APIs carry enough risk to justify a review by someone with security expertise before they ship. Defining that list in advance, and recording that the review happened, gives an auditor a clear and proportionate answer to how risky changes are controlled. It also stops the security review from becoming a bottleneck for every small change.
For auditors, the record matters as much as the review. Branch protection rules that require an approval before merging, together with the approval history in the repository, are usually enough evidence for routine changes. For high risk changes, a short note of who reviewed them and what was checked completes the picture.
Where penetration testing fits
A penetration test is a time limited exercise in which skilled testers try to break the application, combining tools with manual exploration of business logic and weaknesses that only become dangerous when chained together. It is the best check of the overall result, and many enterprise customers ask for a recent report as part of their security review.
It is not a substitute for testing during development. A penetration test is a snapshot taken once or twice a year, while the code changes every week, so most of what is shipped between tests has never been examined. A test run without prior automated testing also tends to spend expert time on issues that SAST, SCA or DAST would have found earlier and more cheaply, such as outdated libraries and missing headers, leaving less time for the logic flaws only people can find.
The strongest programmes therefore use the two together. Automated testing runs continuously and keeps the common issues out, and the penetration test is scoped to the areas where human judgement adds most: authorisation across tenants, payment flows, new features and anything the automated tools cannot reach. The findings from each penetration test also feed back into the pipeline, as new SAST rules, new DAST configuration or new review checklist items, so the same class of flaw is caught automatically next time. Our article on penetration testing versus vulnerability scanning explains the difference in more depth.
What auditors and customers expect as evidence
None of the main frameworks names a specific tool. They ask for a defined process, applied consistently, with evidence that it runs and that its findings are dealt with.
In ISO 27001:2022, the relevant Annex A controls sit together: 8.25 secure development life cycle, 8.26 application security requirements, 8.27 secure system architecture and engineering principles, 8.28 secure coding and 8.29 security testing in development and acceptance. An auditor will look for a secure development policy that describes the testing methods, evidence that they run, such as pipeline logs, scan reports and review records, and evidence that findings were fixed within the agreed timeframes or formally accepted. Excluding these controls in the Statement of Applicability needs a convincing justification, and for a company that builds software it rarely has one. Our guide to ISO 27001 for SaaS companies covers the other controls that change for software businesses.
SOC 2 does not mention SAST either, but its change management criterion (CC8.1) and system operations criterion (CC7.1) expect changes to be tested and approved before deployment and vulnerabilities to be identified and addressed. In a Type II report the auditor samples changes from across the whole period, so the evidence has to exist for every sampled pull request: the review approval, the test results and the deployment record. A process that only works when someone remembers to run it will show gaps in the sample. Our overview of the SOC 2 Trust Services Criteria explains how the criteria are structured.
Under NIS2, Article 21(2)(e) requires security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure, which our article on NIS2 Article 21 covers in full. For companies that sell software products in the EU, the Cyber Resilience Act adds product level obligations on vulnerability handling and component documentation. Enterprise customers translate all of this into the same handful of questionnaire questions: which testing methods run, how often, who triages findings and how quickly critical issues are fixed.
Making the programme last
The most common failure in application security is not a missing tool but a tool nobody looks at. A few decisions made at the start determine whether testing becomes part of how the team works or turns into noise that everyone learns to ignore.
The order of introduction matters. For most teams it makes sense to start with secrets scanning, because it is quick to set up and its findings are unambiguous, and then add SCA, because dependency vulnerabilities are numerous and usually fixed by upgrading. SAST on new code comes next, tuned before it is allowed to block anything, and DAST against staging follows once test accounts and API definitions are in place. Peer review usually exists already and only needs a security checklist and a record. Introducing everything at once tends to bury the team in findings and discredit the programme before it has delivered anything.
The rules for handling findings matter as much as the tools. Write down who reviews new findings, how severity is set and how quickly each severity must be fixed, for example critical issues within days, high within a few weeks and medium within the quarter, with exceptions approved and recorded rather than left open. Those timeframes are exactly what an auditor tests against and what a customer questionnaire asks about, so they should be realistic for the team rather than copied from a template.
Finally, measure what changes. Track open findings by severity, the age of the oldest critical finding and the share of findings fixed within the agreed timeframe. A falling trend over several quarters is stronger evidence than any single scan report, and it is the figure the management team should see, alongside the other indicators of the security programme.
Where Qalea fits
Qalea runs application security testing on a client's own code, dependencies and containers, covering SAST, DAST, SCA, secrets detection and SBOM generation from the first commit to the running application, and manual penetration testing covers what automated tools cannot reach. The Qalea team helps prioritise findings by real risk and agree remediation plans the development team can actually follow.
The results sit alongside the rest of the security programme on the Qalea platform, where the secure development evidence for ISO 27001, SOC 2 and NIS2 is kept with every other control. Exposure from outside is covered by attack surface management, described in our article on the external attack surface. Our attack surface and pentesting topic page has more on testing and exposure.
