피드로 돌아가기
Dev.toSecurity
원문 읽기
6건의 제출과 0달러 수익을 통한 Pre-submit Gate 설계 및 Conversion Rate 최적화
Why bug bounty income is harder than it looks: the New Hacker trial cap and six compound mistakes that wasted a full day
AI 요약
Context
신규 리서처가 직면하는 HackerOne의 Account-wide Trial Cap 제약으로 인한 제출 지연과 Duplicate 판정률 증가 문제 분석. 기술적 정답(Bug 존재)과 보상 기준(Threat Model)의 불일치로 인한 리소스 낭비가 핵심 병목 지점으로 작용함.
Technical Solution
- Variant-race Timing Check를 통한 제출 시점 최적화 및 Queueing 전략 폐기로 Duplicate 위험 최소화
- Design-context Filter 적용으로 단순 구현 오류가 아닌 프로그램의 Threat Model에 부합하는 Severity인지 사전 검증
- Payment-likely Trust-model Check를 통해
offers_bounties플래그와 실제eligible_for_bounty범위의 일치 여부 확인 - HackerOne 외부의 Direct 채널(MSRC, Apple, Google VRP 등)로의 경로 다변화를 통한 Trial Cap 제약 우회
- Security-flavored Commit을 실시간 모니터링하는 Cron Job 기반의 Variant-race Feed 구축으로 탐지 윈도우 확보
실천 포인트
- [ ] 제출 전 해당 Scope의 실제 보상 가능 여부(Eligible for bounty)를 API로 재검증했는가? - [ ] 발견한 취약점이 벤더의 Threat Model상 Paid Severity에 해당함을 입증할 논리가 준비되었는가? - [ ] 플랫폼의 Trial Cap에 걸려 대기 중인 리포트가 타 리서처에 의해 Duplicate 될 가능성을 검토했는가? - [ ] 해당 프로그램이 플랫폼 외에 Direct Intake 채널을 운영하고 있는지 확인했는가?