TL;DR: SAST reads code without running it, SCA reads your dependency tree, DAST attacks the running application, and IAST instruments a running app to combine the first and the third. They cannot reliably establish the full business authorization policy, which is why a pipeline full of green scanners is not a secure application.
How to approach it
Define each in one line, then place it on a pipeline in order, then say what the set as a whole cannot detect. The last part is what separates a security-aware engineer from someone reciting a vendor diagram.
A strong answer
SAST analyses source or bytecode without executing it. It runs early, on commit or in the pull request, because it needs only the code. It is good at injection patterns, unsafe deserialisation and hardcoded secrets, and it is famously noisy: high false positive rates are the main reason teams stop looking at it.
SCA inspects your dependencies and matches them against vulnerability databases. It is the highest value per unit of effort in the whole list, because most of the exploitable code in a modern service is code you did not write. It runs at the same stage as SAST and additionally on a schedule, because a dependency that was clean on Tuesday is not clean on Friday when a CVE lands.
Container image scanning is SCA applied to the image layers, catching the base image packages that the application manifest never mentions. It belongs after build and before push.
DAST attacks the running application from the outside with no knowledge of the source. It needs a deployed environment, so it sits after the staging deploy. It finds what actually happens rather than what the code appears to do, including misconfiguration, missing headers and authentication gaps. It is slow, so it typically runs nightly rather than per commit.
IAST instruments the running application with an agent and observes execution during functional or DAST tests. Because it sees both the request and the code path it triggers, it has far lower false positives than SAST and finds things DAST alone would miss. The cost is an agent in your runtime.
Now the honest part. These tools can detect some broken access-control patterns, but do not establish complete authorization correctness, which is consistently the top category in the OWASP Top Ten. A scanner cannot know that user A should not be able to read order 1234, because that is a statement about your domain, not about your syntax. The same applies to business logic abuse, pricing manipulation and workflow bypass. Those need threat modelling and authorisation tests written by people who understand the domain.
On gate policy, the pragmatic position: block unacceptable exploitable risk, including a pre-existing critical flaw on a reachable path. New findings can use stricter default gates while existing lower-risk debt follows an owned remediation schedule. A gate that fails on a pre-existing CVE with no available fix trains developers to add exceptions, and once exceptions are routine the gate is decorative.
What interviewers probe next
"Trivy flags a critical CVE in your base image at deploy time. What is your policy?" Check exploitability first: is the vulnerable path reachable and is a fixed base image available. If a fix exists, rebuild and redeploy. If not, document the compensating control and set an expiry on the exception. If no acceptable compensating control exists, delay exposure or disable the affected feature. OWASP authorization testing requires tests grounded in the application’s access rules.
"Where does secret scanning sit?" Pre-commit and in CI, and once a secret has been committed the only correct response is rotation. Removing it from history is cleanup, not remediation.
"What is SBOM for?" Knowing within minutes rather than days which of your images contain a newly disclosed component. It is an inventory question, and the value only shows up during an incident.
Common mistakes
Presenting the four as interchangeable. They see different things at different stages, and a pipeline with only SAST is common and weak.
Claiming shift-left replaces runtime security. Runtime detection with Falco or an equivalent catches what static analysis structurally cannot.
Recommending that every scanner blocks the build. That is the fastest route to a team that turns them all off.