CCSP Practice Question: Is implementing a DevSecOps pipeline for…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Runtime Application Self-Protection (RASP)

  Why it's wrong here

  RASP instruments a running application and inspects calls at execution time, so it cannot analyse source code before the build runs. It is tempting because RASP catches runtime exploits, but static analysis of source without execution is SAST, which integrates at the commit stage.

• ✗

  Dynamic Application Security Testing (DAST)

  Why it's wrong here

  DAST probes a deployed, running application from outside, so it requires execution and cannot inspect source code. It is tempting because DAST finds exploitable flaws, but the stem demands pre-execution source review, which is SAST's static parsing of code.

• ✗

  Interactive Application Security Testing (IAST)

  Why it's wrong here

  IAST combines instrumentation with runtime execution, requiring the application to run under test, so it cannot analyse source statically. It is tempting because IAST reports code-level detail, but the stem's no-execution requirement is met by SAST, which parses source directly.

• ✓

  Static Application Security Testing (SAST)

  Why this is correct

  SAST analyses source code, bytecode or binaries without executing the application, so it runs on every commit inside the CI/CD pipeline and flags injection, insecure deserialisation and similar flaws before build or deployment. This satisfies the constraint of early analysis without executing the application.

Go deeper

Related to this question