Offensive security research: finding out what an attacker can actually do, and proving it safely enough that engineers trust the fix.
Scanner output dressed up as a finding doesn't count. A result is only done when it's reproducible, scoped, and actionable for the team that has to remediate it.
| Area | In practice |
|---|---|
| Identity & auth | OAuth/OIDC edge cases, missing state/nonce binding, callback trust, session & account fixation |
| Web & local apps | CSRF against local management UIs, IDOR, access-control failures, request smuggling, SSRF |
| Cloud & IAM | Workload identity boundaries, IAM misconfiguration chains, metadata-service pivots, secret exposure |
| Supply chain | CI/CD runner isolation, GitHub Actions hardening, dependency confusion, artifact/build-cache poisoning |
| AI tooling | Connector trust boundaries, agent workflow abuse, review-payload exposure in AI-assisted pipelines |
Languages
Infra & Platforms
Workflow
scope check -> recon -> candidate finding -> reproduce locally
-> validate exploitability -> calibrate impact
-> report for engineers -> retest on fix
Three rules that don't change per engagement:
- Scope is a hard boundary, not a suggestion — testing stays inside explicit authorization.
- Reproduce before reporting — scanner output and exploitable behavior are not the same thing.
- Prove impact without causing it — controlled PoCs, local fake services, non-destructive payloads.
Two engagement types, side by side
External — bug bounty / disclosure
recon → scope check → exploitability validation → impact calibration → report → triage response → retest
Internal — repo / architecture review
threat model → source–sink mapping → auth boundary review → dynamic validation → minimal PoC → report-ready evidence
CVE-2026-28740CVE-2026-54094
m2hczs@proton.me
For security reports: scope, affected asset, reproduction steps, impact, remediation context. No scope, no read.
