Vulnerability
A weak spot in code or configuration that an attacker can use to read, change, or disrupt something they should not reach.
See it
What it is
A vulnerability is a weakness that lets someone cross a boundary the system was meant to hold. It might expose data, let records be changed, or knock a service offline. Some are code bugs, like a missing ownership check; others are dangerous configuration, like a public storage bucket or a default password that survived deployment.
Reach for the word when you can name the weakness independently of the attack that uses it. A CVE gives a publicly disclosed vulnerability a shared identifier, and CVSS describes technical severity, but neither tells you whether your exact deployment is reachable or whether the vulnerable feature is even enabled.
Treating every scanner finding as equally urgent is the classic mistake. A critical library flaw in code that never ships may matter less than a medium authorization bug on a public endpoint. Prioritize with evidence: exposure, exploitability, privileges required, data at risk, and whether a working exploit exists. Then patch, mitigate, or explicitly accept it.
Ask AI for it
Audit this application for vulnerabilities and produce fixes, not just a scanner dump. Run Semgrep against the source and OSV-Scanner against the resolved dependency lockfile, then inspect every public route, trust boundary, authorization check, upload, webhook, and secret by hand. For each finding, show the vulnerable file and call path, the attacker prerequisites, the affected confidentiality, integrity, or availability, and a safe local reproduction. Rank findings by reachability and blast radius rather than scanner severity alone. Implement the smallest durable fix, add a regression test that fails before the fix and passes after it, and list any finding you could not verify with the missing evidence.