Reporting Security Test Results deals with what you do once you have found something. It covers the criticality of security test results and how that criticality changes the way they are handled and communicated, the evaluation of results to identify vulnerabilities, and the techniques for closing a vulnerability — with an explicit split between hiding a vulnerability and avoiding or removing it. The keywords ethical hacker and risk mitigation belong here.
The mistake that costs marks is applying ordinary defect-reporting habits. A security test report is not distributed to whoever is interested: a described weakness often exists in production too, so the report itself becomes an attack asset, and access to it — including the defect tracking entries — has to be controlled. Equally, candidates pick answers where the vulnerability is made harder to notice and call that closed. Obscuring a weakness leaves it exploitable; removing it or designing around it does not.
Revise by asking two questions of every finding: who is entitled to see this, and does the proposed action actually eliminate the weakness or only conceal it.
Hiding vs avoiding or removing — concealment leaves the weakness exploitable by anyone who looks harder; only elimination or a design change closes it.
Risk mitigation vs closing a vulnerability — reducing exposure is a legitimate answer, but it is not the same as the weakness ceasing to exist.
Restricted vs open distribution — security findings go to a controlled audience, and the defect tracking record needs the same protection as the report.
Impact first, detail later — a summary carries the risk consequence for decision-makers; exploitation detail is not summary material.
Test result vs vulnerability — a failed check is an observation; declaring a vulnerability is an evaluation step you have to justify.
Criticality drives handling — severity here governs who is told and how fast, not merely a priority field.
Ethical hacker vs attacker — identical techniques, but authorization and disclosure obligations are what define the role.
A finding in test usually means a finding in production — assume the same weakness is live, and report accordingly.
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)