Sample questions
As Secure Sdlc Sast DastDifficulty 1
What does a SAST (Static Application Security Testing) tool analyze to find vulnerabilities?
- aNetwork traffic captured while the application is running in production
- bLog files generated after a deployed application has been running for several days
- cUser-reported bug tickets filed after a security incident occurred
- dThe application's source code, bytecode, or binaries without executing the program✓
Explanation:SAST tools parse source code, bytecode, or binaries directly and reason about control flow and data flow without ever running the application, which is why they can be applied as soon as code exists, even before it compiles into a deployable artifact.
As Secure Sdlc Sast DastDifficulty 1
What does a DAST (Dynamic Application Security Testing) tool require in order to test an application?
- aFull read access to the application's source code repository, since DAST is assumed to statically analyze source files for the same patterns SAST would look for
- bA running instance of the application that it can send requests to and observe responses from✓
- cA copy of the compiled binary with debug symbols stripped out
- dThe list of every developer who has committed code to the project
Explanation:DAST works like a black-box attacker: it needs a deployed, running application (often in a staging environment) so it can send crafted HTTP requests and inspect the actual responses, headers, and behavior. It never reads source code.
As Secure Sdlc Sast DastDifficulty 2
A team wants to catch an unsanitized SQL query concatenation bug as early as possible, ideally while a developer is still writing the code before it is even committed. Which testing approach fits this goal best?
- aDAST run nightly against the staging environment, which still requires the feature to already be deployed and running before any feedback is produced
- bSAST integrated into the IDE or run on every pull request✓
- cLoad testing executed right before a production release
- dManual penetration testing performed once per quarter
Explanation:SAST reads the source directly, so it can run inside an IDE plugin or as a pre-commit/PR check, giving feedback before the code is even merged. DAST, penetration testing, and load testing all require a running, often later-stage, deployment.
As Secure Sdlc Sast DastDifficulty 2
Which limitation is most commonly associated with SAST tools?
- aThey cannot be run until the application is deployed to production, since the tool is assumed to need a live HTTP endpoint to inspect, the same way a DAST scanner does
- bThey can only detect vulnerabilities in compiled languages, never in interpreted ones
- cThey tend to produce a meaningful number of false positives because they lack full runtime context✓
- dThey require the application to be under active attack to generate any findings
Explanation:Because SAST reasons about code paths statically, without knowing exact runtime values, configuration, or how components are actually wired together, it often flags patterns that look risky but are not exploitable in practice, producing false positives that need triage.
As Secure Sdlc Sast DastDifficulty 2
Which limitation is most commonly associated with DAST tools?
- aThey can only find issues in code paths that are actually exercised by the requests they send during the scan✓
- bThey cannot be automated and must always be operated manually by a human tester, because interpreting an HTTP response for a real vulnerability is assumed to require human judgment that no scripted crawler can replicate
- cThey require the full source code of every dependency to be provided in advance
- dThey can only run against applications written in memory-unsafe languages such as C
Explanation:DAST behaves like an outside attacker sending requests, so any code path, endpoint, or feature it never reaches (e.g. behind an unusual auth flow, a rarely used admin form) stays untested. Coverage depends entirely on what the scan crawls or is configured to hit.
As Secure Sdlc Sast DastDifficulty 3
IAST (Interactive Application Security Testing) tools are typically described as combining aspects of SAST and DAST. What is the core idea behind this hybrid approach?
- aIAST replaces automated scanning entirely with a checklist filled out manually by developers
- bIAST only scans the network perimeter and never looks inside the running application process
- cIAST is simply DAST renamed, with no actual technical difference between the two
- dIAST instruments the running application with an agent, so it observes real code execution while functional or DAST-style tests exercise it✓
Explanation:IAST places an instrumentation agent inside the running application (similar to how SAST understands code) and then observes what actually executes as the app is driven by functional tests or DAST traffic, combining code-level visibility with real runtime behavior.