PROJECT / SAMPLE
Finding the bug was the first 20%.
An application-security review continued through patches, regression coverage, and verification instead of ending at a findings report.
- Date
- 2026-05
- Type
- security / software
- Status
- fictional fixture
- Published
- prototype only
Problem
A product approaching launch needed a security review, but the delivery team also needed practical help changing risky authentication, authorization, and internal-service assumptions.
Constraints
- Launch-critical functionality could not be broadly redesigned.
- Fixes had to fit the team's existing stack and release process.
- Verification needed to remain useful after the engagement.
Observed
- Authorization checks were inconsistent across adjacent endpoints.
- An internal fetch path admitted server-side request forgery.
- Secrets and service trust boundaries reflected obsolete deployment assumptions.
Work
- Reviewed authentication and authorization boundaries.
- Traced secret handling and internal service assumptions.
- Tested SSRF and dependency attack surface.
- Implemented remediation patches with the delivery team.
- Added security regression cases to CI.
Decisions
- Rank findings by exploitable system impact, not scanner severity alone.
- Turn every critical repair into an executable regression.
- Keep remediation close to the engineers who understand the application.
Result / SAMPLE
Critical launch risk was removed, and the resulting tests kept the repaired boundaries visible to future changes.
- 3 critical / 7 high findings identified
- all critical findings remediated before launch
- security regression suite added to CI
What we did not do
We did not deliver a severity spreadsheet and disappear. A finding was not considered resolved until the repair was verified.
Technical index
application security / threat modeling / CI / security testing