1 min lesson
Quantify the impact like Cursor does
Rebuild the parts of "Quantify the impact like Cursor does", then say why each one matters.
Step 1 of 2
Quantify the impact like Cursor does
Cursor frames its own security work concretely, so meet that bar. Their AI-augmented review runs across effectively every internal PR and catches vulnerabilities, blocking issues at CI before production. Anchor your story in the same kind of concrete outcome.
- Coverage
- PRs, repos or services your control now guards automatically
- Vulns prevented
- Instances of the class caught at CI or pre-commit since you shipped it
- Blast radius reduced
- Standing permissions removed, data reachable before vs after, accounts no longer impersonable
- Friction removed
- Manual review steps eliminated, time-to-secure-default measured in a codemod not a quarter
A number isolates your contribution from the team's.
“I noticed our internal services trusted any caller inside the VPC, so I built a request that read another tenant's data through a service that never checked the caller's identity - classic confused-deputy. Patching that one path would've left a dozen like it. Instead I shipped an mTLS-backed auth library where the default client carries identity and the server rejects unauthenticated calls, then codemodded the existing call sites. After rollout, an unauthenticated internal call fails at CI, not in production. We went from ‘trust the network' to ‘trust the caller' across about forty services and that whole class of cross-tenant read closed.”
Learn more
Advanced table
Stay on the builder side of the line
Stay on the builder side of the line
- Reads as gatekeeper
- “I found the bug and filed a P1 for the owning team.”
- Reads as builder-attacker
- “I found the bug and shipped the library that makes it unrepresentable.”
- Reads as gatekeeper
- “I added a required review step for anything touching auth.”
- Reads as builder-attacker
- “I made the auth check a default so the unsafe path needs an explicit override.”
- Reads as gatekeeper
- “I documented the risk in our threat-model wiki.”
- Reads as builder-attacker
- “I encoded the mitigation as a CI check that fails with a fix-it link.”
- Reads as gatekeeper
- “I blocked the launch until it was secure.”
- Reads as builder-attacker
- “I gave the team a paved road so the launch was secure by default.”
| Reads as gatekeeper | Reads as builder-attacker |
|---|---|
| “I found the bug and filed a P1 for the owning team.” | “I found the bug and shipped the library that makes it unrepresentable.” |
| “I added a required review step for anything touching auth.” | “I made the auth check a default so the unsafe path needs an explicit override.” |
| “I documented the risk in our threat-model wiki.” | “I encoded the mitigation as a CI check that fails with a fix-it link.” |
| “I blocked the launch until it was secure.” | “I gave the team a paved road so the launch was secure by default.” |
Same risk, opposite signal. The right column is the role.
Don't let the attacker half become the whole story. A vivid exploit with no defense reads as a pentester and Cursor is hiring a builder. Spend roughly a third of your airtime on the find and two-thirds on what you built so the class can't come back.