Security Testing Tools closes the syllabus and is the shortest chapter by official study time. It does two things: it categorizes security testing tools along the same axes you met earlier — white-box, black-box, grey-box, static, dynamic — and it covers the considerations for selecting and applying them. The named families are SAST (static application security testing), DAST (dynamic application security testing), IAST (interactive application security testing), SCA (software composition analysis), vulnerability scanning, fuzz testing and penetration testing tools.
The classic error is preparing with a product in mind. Nothing here asks about a particular scanner, its licence model or its command-line flags; the questions are about categories and about matching a use case to the right category. If you know one commercial tool intimately and cannot say which family it belongs to, you will read a scenario and pick by brand instinct instead of by what the tool can observe. Being short does not make this chapter free — the selection objective is at application level.
Learn it by writing, for each family, what artifact it inspects, when in the lifecycle it can run, and what it structurally cannot find.
SAST vs DAST — code and configuration examined without execution, versus a running system probed from outside.
IAST vs the other two — it observes the application from inside while it runs, so it is neither purely static nor purely external.
SCA vs SAST — composition analysis looks at the third-party and open-source software (OSS) components you assembled, not at the code your team wrote.
Vulnerability scanning vs penetration testing — automated detection of known weaknesses is not the same as a human attempting exploitation.
Category, not product — the answers describe what a class of tool can see; brand knowledge is not the discriminator.
Fuzzing tools vs scanners — generating malformed input to provoke unexpected behaviour differs from comparing a system against a signature list.
Security-specific static analysis — a general-purpose code analyser is not a security tool just because it reports defects.
Selection is context-driven — the use case, the artifact available and the lifecycle stage decide the category, not tool popularity.
This chapter is covered most heavily (3 questions) in CT-STE — Mock Exam 1 (Zero Trust, Access Control & Threat Modelling), CT-STE — Mock Exam 2 (Attacker Profiling, DevOps Pipelines & Standards as Oracles), CT-STE — Mock Exam 3 (Reconnaissance Analysis, Standards & Regression)