What are SAST and DAST?
SAST stands for static application security testing. It scans source code for vulnerabilities without running it. DAST stands for dynamic application security testing, which attacks a running application from the outside to find flaws the way an attacker would.
What the buyer is really asking
Which kinds of testing do you actually run: static analysis, dynamic scanning, dependency scanning, third-party penetration tests? Name the tools and how often each runs. Be plain about anything you do not do yet.
Other ways buyers ask it
Every one of these wants the same answer:
- “What application security testing do you perform?”
- “Do you perform SAST and DAST?”
- “Do you conduct penetration tests?”
- “Can you share your latest pen test report?”
Evidence to have ready
- Scanner configuration in CI
- The most recent penetration test summary, if one exists
- Remediation records for findings
Sample answers by company stage
The right answer depends on what you actually run today. Each sample below is honest only if its condition is true for you. Swap the bracketed details for your own.
Early startup
Use this if: You run free or built-in scanners and have not yet paid for a penetration test.
We run static analysis with [CodeQL] on every pull request and dependency scanning with [Dependabot]. Secret scanning is enabled on all repositories. We do not yet run a dedicated dynamic scanner, and we have not commissioned a third-party penetration test. Engineering triages scanner findings [weekly] and fixes critical and high issues first. Before our first independent test, we review our own authentication, authorization, and input handling against the OWASP Top 10 checklist. We are glad to walk a reviewer through our CI configuration and recent scan results.
Scaling
Use this if: Static, dependency, and dynamic scanning run on a schedule, and you have at least one completed penetration test.
Our application security testing has four layers. Static analysis with [Semgrep] runs on every pull request and blocks merges on high-severity findings. Dependency scanning with [Snyk] monitors our libraries continuously. Dynamic scanning with [OWASP ZAP] runs [weekly] against staging using authenticated sessions. An independent firm performs a penetration test [annually]. Our most recent test finished in [month and year], and all critical and high findings were fixed and retested. We can share an executive summary under NDA.
Enterprise-ready
Use this if: Testing is continuous, penetration tests cover your full application and API, and the results are inside an audited scope.
Static analysis, dependency scanning, secret scanning, container scanning, and infrastructure-as-code scanning run in CI as required checks. Authenticated dynamic scanning runs against staging before every release and against production [monthly]. Independent penetration tests run [twice a year] and cover the web application, the public API, and our cloud configuration. Each test ends with a retest letter confirming fixes. We also run a bug bounty program through [platform]. Findings from every source are tracked to closure under severity-based deadlines, and our SOC 2 Type II auditor tests that process.
How the major questionnaires word it
Each standard questionnaire asks this in its own structure. These are paraphrased summaries, not the licensed question text.
- CAIQ v4 (Cloud Security Alliance)
- Automated application security testing is a row in the Application and Interface Security domain. Independent penetration testing is a separate row in Threat and Vulnerability Management. Answer both, and say which one covers your API.
- SIG (Shared Assessments)
- SIG asks separately about static code analysis, dynamic testing, and penetration testing, usually with how often each runs and whether a third party performs it. Expect a request for the latest report.
- VSA (Vendor Security Alliance)
- VSA-style questionnaires ask whether you had a penetration test in the last 12 months and whether critical findings were fixed. Yes to the first without the second is a weak answer.
- HECVAT (higher education)
- HECVAT asks how often you scan and test the application and whether you will share results with the institution. Offering a summary under NDA is the usual answer.
More evidence reviewers accept
- A penetration test executive summary or attestation letter with test dates and scope
- A retest letter confirming critical and high findings were closed
- A dated scan export showing no open critical findings
- A scope statement listing which applications, APIs, and environments were tested
- Your vulnerability disclosure or bug bounty page
Red flags reviewers look for
- An old or narrow penetration test. A test older than 12 months, or one scoped only to the marketing site, does not answer the question. Reviewers check the dates and scope on the letter.
- Scanners nobody triages. Saying you run static analysis while thousands of alerts sit open is worse than a smaller honest setup. Reviewers may ask for open counts.
- Calling a vulnerability scan a pen test. An automated external scan is not a penetration test. Security reviewers know the difference, and mislabeling one costs credibility on everything else.
- Unauthenticated dynamic scans only. A scanner that never logs in sees your login page and little else. Say whether your dynamic scans cover authenticated areas.
- Refusing to share anything. A flat no stalls the review. An executive summary or attestation letter under NDA is the normal middle ground.
- Testing only your own code. Container base images, runtimes, and cloud configuration carry vulnerabilities too. If your testing stops at the code you wrote, say what covers the rest.
Follow-up questions to expect
Which tools do you use?
Name them. Reviewers recognize common tools and treat a named tool as more credible than a category. If a tool is free or built into your code host, that is fine to say.
Who performed your last penetration test?
Give the firm name, the test dates, and the scope. If the test was done in-house, say so plainly. Internal testing still counts, but it is not an independent test.
Did the test cover our use case?
If the buyer will rely on your API or a specific integration, check that the test scope included it. A scope gap is a reasonable finding, and saying so first builds trust.
What happens when a scan finds something?
Connect testing to your remediation process: who triages, how severity is set, and the deadline for each severity. This is where testing answers meet the vulnerability management question.
How do you handle false positives?
Every scanner produces them, and buyers know it. Say who can mark a finding as a false positive, whether a second person confirms it, and whether the reason is recorded. Suppressions with no review trail look like findings being hidden. A short documented rule, such as security lead approval with a written reason, answers this cleanly and shows the scanner output is trusted.
How Tyrvar answers this
Tyrvar treats every wording above as one question. You write the answer once, attach the evidence, and revisit it when your setup changes. Each buyer gets that approved answer no matter how their questionnaire words it. If you have not answered it yet, Tyrvar flags the question for you and does not make something up. Try it on your own questionnaire.