C — risks. This is the distinction most engineers miss, and it's exactly where Lens 1 starts. The project was originally about vulnerabilities, then threats, and today it's organized around risks — meaning impact × likelihood. The shift matters because it changes what you count and how you prioritize. A single vulnerability might be critical or irrelevant depending on context. A risk forces you to consider both.

B — a vulnerability. The system permits user enumeration. An attacker can script requests and build a list of valid usernames, then use that list for credential stuffing or phishing. The fix — returning the same generic message for both cases — is annoying for legitimate users. That's the trade-off, and it's a real one. Some teams accept the risk; some don't. The point is knowing it's there.

C — both are partially right. The form does permit email enumeration — that's a weakness. But the alternative (a generic "something went wrong with registration") makes for a terrible user experience. This is exactly the kind of trade-off a Security Champion navigates: a banking app should probably accept the UX hit, a gaming platform might not. The point isn't that there's one correct answer — it's that you know the trade-off exists.

B — the risk is different. The vulnerability is identical. But the payment API has massively higher impact (financial data, regulatory exposure, millions of users) and higher likelihood (internet-facing, publicly discoverable). The internal tool still needs fixing — SQL injection is never acceptable — but when you're deciding which one to fix this sprint, the formula gives you a clear answer. That's what risk-based thinking buys you: a way to prioritize when you can't fix everything at once.