A transit tester treats a successful Metasploit check as enough proof of business impact. What should they do instead?
Select an answer to reveal the explanation.
Short Explanation
A green light on a tool is like a smoke alarm chirp—it says look here, not the building is already gone. Clients need evidence and what it means for their business, not just a happy module status. Prove the story; don’t stop at the beep.
Full Explanation
A transit tester who treats a successful Metasploit check as enough proof of business impact should instead gather evidence and map the finding to real risk and context. Green tool output is a signal to investigate, not an executive impact statement. Pasting the module success banner into the executive summary substitutes vendor wording for municipal risk language leaders need. Automatically raising severity on any positive check ignores exploitability constraints, compensating controls, and asset criticality across transit systems. Omitting the finding unless a public exploit PoC is attached invents an arbitrary evidence bar and can hide real misconfigurations the city must fix. Exam caveat: check modules and exploit modules are not interchangeable proof of compromise; distinguish detection signals from demonstrated impact. Operational check: attach reproducible evidence (request/response, config excerpt, controlled session artifact), state affected transit function, and justify severity against the engagement’s rating rubric before the finding ships. In municipal operations, record the rationale in the engagement notes so future testers and city defenders understand which approach was chosen and which failure modes the rejected options would create for civic services.