Step 319. 첫 제보 제출과 트리아지 대응 — 버튼을 누른 뒤가 진짜 시작

Level 4 — 제보·CVE 분석·오픈소스 기여 | 난이도 ★★★☆☆ | 예상 소요 시간 2시간

전제: Step 318에서 인정받는 제보서를 작성했다. 제보 대상 프로그램의 scope와 규칙을 이해한다.

준비물: 완성된 제보서(Step 318의 산출물), 제보 대상 프로그램 계정, 그리고 판정 결과를 기록할 노트. 명령 실습이 없는 읽기·역할극 중심 챕터입니다.
주의: ⚠️ 이 챕터의 실습은 내 랩·합법 플랫폼 전용입니다. 허가 없는 시스템에 적용하면 범죄입니다. 이 환경은 외부 네트워크가 차단되어 있어 플랫폼 화면과 트리아저와의 메시지는 전부 "화면 예시"로 표기합니다.

Step 318에서 제보서를 완성했습니다. 그런데 제출 버튼을 누르는 순간, 일은 끝나는 것이 아니라 시작됩니다. 제보서는 트리아저(triageer)라는 사람의 책상에 도착하고, 그 사람의 판정에 따라 유효가 되기도, 중복이 되기도, 거절되기도 합니다. 오늘은 "제출 → 트리아지 → 판정 → 후속 대응"이라는 흐름 전체를 배우고, 트리아저와 주고받는 영어 커뮤니케이션의 기본 표현과, 불인정 판정에 대응하는 정중한 재검토 요청법을 익힙니다. 첫 제보가 거절돼도 좌절하지 않는 것 — 그것이 이 챕터의 진짜 목표입니다.

1. 학습 목표

이 챕터를 끝내면 다음을 할 수 있습니다:

제보가 접수된 뒤 거치는 트리아지 흐름(접수 → 검토 → 판정)을 설명한다
네 가지 판정(유효/중복/정보성/해당 없음)의 의미와 각각의 후속 행동을 말한다
트리아저의 추가 질문에 24시간 안에 답하는 영어 기본 표현을 쓴다
흔한 불인정 사유 다섯 가지를 들고, 이견이 있을 때 재검토를 요청하는 정중한 문장을 쓴다
판정 결과를 "무료 코칭"으로 해석해 다음 탐색 계획에 반영한다

2. 배경 지식 — 오늘의 도구와 개념

오늘의 도구 한눈에 보기

구분	내용
언어·환경	제보 플랫폼 웹사이트(화면 예시) + 기록용 노트
오늘의 도구	제출 양식, 트리아지 메시지 스레드, 판정 상태 표시
필요한 개념	트리아지, 판정 4종, 영어 제보서 기본 표현, 평판(reputation)
오늘의 산출물	"제보 진행 기록표" — 접수 일시부터 최종 판정과 사유까지의 타임라인

2-1. 트리아지 — 응급실의 우선순위 분류에서 온 단어

트리아지(triage)는 원래 응급실에서 환자를 중증도 순으로 분류하는 일입니다. 버그바운티에서도 같습니다. 하루에 수십 건씩 들어오는 제보를 트리아저가 읽고 분류합니다 — "진짜 취약점인가", "scope 안인가", "이미 보고됐나".

트리아저는 여러분의 적이 아닙니다. 수백 건의 제보를 처리하는 동료 보안 전문가이고, 여러분의 제보서가 명확할수록 그 사람의 일이 쉬워지고, 판정도 빨라집니다. Step 318에서 재현 단계와 증거를 정성껏 쓴 이유가 여기서 드러납니다.

2-2. 판정의 네 가지 상태

플랫폼마다 명칭은 조금씩 다르지만, 판정의 골격은 네 가지입니다.

판정	의미	여러분의 후속 행동
유효(valid / triaged)	취약점 인정. 수정 대기 또는 보상 진행	기록하고, 필요하면 retest에 협조
중복(duplicate)	누군가 먼저 같은 취약점을 제보함	아깝지만 정상. 사유를 보고 탐색 방향 조정
정보성(informative)	취약점은 맞으나 보상 기준 미달(영향이 작거나 베스트 프랙티스 수준)	같은 종류를 더 깊게 파볼지 판단
해당 없음(N/A)	취약점으로 인정 불가(scope 밖, 규칙 위반, 오해 등)	사유를 정확히 이해하고 재제출 여부 결정

중복 판정은 헌터라면 누구나 겪는 통과 의례입니다. 프로 헌터들의 유효율도 생각보다 높지 않습니다. 첫 제보가 중복이면 아쉽지만, "내가 찾은 것이 실제 취약점이었다"는 검증이기도 합니다.

2-3. 커뮤니케이션이 곧 평판이다

트리아지 과정은 대부분 플랫폼 안의 메시지 스레드로 진행됩니다. 여기서의 태도가 헌터의 평판(reputation)을 만듭니다. 빠르고 정확하고 정중한 헌터는 트리아저의 기억에 남고, 다음 제보에서 유리한 출발점을 얻습니다. 반대로 감정적으로 항의하거나 답변이 늦는 헌터는 좋은 판정을 받을 제보도 흐릅니다.

영어가 부담스럽더라도 괜찮습니다. 트리아지 메시지는 문학이 아니라 정보 전달입니다. 짧고 정확한 문장이 유려한 문장보다 낫습니다. 3-4에서 바로 베껴 쓸 수 있는 표현을 정리합니다.

2-4. 기다림도 프로세스다

판정까지는 수일에서 수 주가 걸립니다. 이 대기 시간에 아무것도 안 하고 결과만 새로고침하는 것은 초보의 단골 패턴입니다. 대기 중에는 ① 같은 타깃의 다른 지점을 계속 탐색하거나, ② 다른 타깃의 정찰을 시작하거나, ③ 제보 기록을 정리합니다. 헌터의 시간은 판정을 기다리는 시간이 아니라, 다음 제보를 준비하는 시간입니다.

3. 따라 하기

오늘은 명령어가 아니라 절차와 문장을 따라 합니다. 외부 네트워크가 차단된 이 환경에서는 플랫폼 화면과 메시지를 예시로 재구성해 보여 주고, 여러분의 실제 제보 때 그대로 쓸 수 있는 형식을 만듭니다.

3-1. 제출 직전 — 마지막 3분 점검

제출 버튼을 누르기 전에 세 가지를 다시 확인합니다.

[ ] scope 재확인 — 내가 테스트한 도메인/기능이 프로그램 규칙 안인가?
[ ] 재현 단계 단독 실행 가능 — 트리아저가 내 증거만으로 따라 할 수 있는가?
[ ] 증거 첨부 — 스크린샷/영상/요청 로그가 빠짐없이 들어갔는가?

읽는 법: 이 점검을 건너뛰고 날린 제보가 N/A로 돌아오는 경우가 가장 많습니다. 특히 scope 밖 제보는 보상만 없는 게 아니라 프로그램 규칙 위반으로 계정에 불이익이 될 수도 있습니다. 3분의 점검이 수 주의 재심을 막습니다.

3-2. 제출과 기록 — 제보 진행 기록표 만들기

양식에 맞춰 제출한 뒤, 노트에 기록표를 만듭니다. 플랫폼이 상태를 보여 주더라도, 내 노트에 내 언어로 기록하는 습관이 나중에 포트폴리오가 됩니다.

기록표 예시:

제보 번호:    #2026-0412
프로그램:     example-corp 버그바운티
제출 일시:    2026-09-09 14:20
제목:         Stored XSS in profile bio field
상태:         New (접수됨)
판정 일시:    (대기)
판정:         (대기)
사유/메모:    (대기)
다음 행동:    답변 대기 중 — 동일 타깃의 다른 입력 필드 탐색 계속

왜 하는가: 제보가 여러 건으로 늘면 어느 것이 어떤 상태인지 머릿속으로 관리할 수 없습니다. 이 표가 있으면 Step 320~322의 CVE 분석 기록과 함께 "연구 활동 로그"가 됩니다.

3-3. 트리아저의 질문이 왔을 때 — 24시간 규칙

트리아저가 재현에 필요한 것을 물어보는 메시지가 옵니다. 화면 예시:

Triager: Thanks for the report. I followed your steps but the payload
did not execute on my end. Could you share:
1. The exact browser and version you used
2. A short screen recording of the reproduction
3. The full request/response (with session cookies removed)

읽는 법: 세 가지를 물었습니다 — 환경 정보, 영상 증거, 통신 로그. 여기에 대한 답변은 24시간 안에 보냅니다. 늦어지는 제보는 스레드 아래로 밀리고, 트리아저의 기억에서도 밀립니다. 답변할 때는 요청한 것을 정확히, 요청하지 않은 것은 덧붙이지 않는 것이 원칙입니다.

답변 예시 (바로 베껴 쓸 수 있는 형식):

Hi, thanks for checking.

1. Browser: Chrome 128.0.6613.120 (Windows 11)
2. Recording attached (repro.mp4, 45 seconds).
3. Full request/response attached (request.txt). Session cookies removed.

The payload only fires after the profile page is reloaded — step 4 in
my original report. Please let me know if you need anything else.

왜 하는가: 질문에 대한 답변 품질이 곧 두 번째 제보서입니다. "재로드해야 발동한다"처럼 제보서에 빠진 조건이 발견되면, 정직하게 인정하고 정보를 추가합니다. 감추면 신뢰를 잃고, 인정하면 신뢰를 얻습니다.

3-4. 영어 기본 표현 치트시트

트리아지 스레드에서 자주 쓰는 문장들을 모았습니다. 그대로 베껴 쓰세요.

상황	표현
추가 정보 제공	`Here is the additional information you requested.`
재현 확인 부탁	`Could you try again after a hard refresh (Ctrl+F5)?`
조건 설명	`The issue only occurs when the user has already logged in.`
시간이 필요할 때	`I need a day to prepare a clearer PoC. I will update you by tomorrow.`
감사	`Thanks for the quick triage.`
재검토 요청	`I respectfully disagree with the severity assessment. May I explain why?`

읽는 법: 전부 짧습니다. 트리아저는 문법 점수를 매기지 않습니다. "무엇을 / 언제 / 어떻게"가 들어간 문장이면 충분합니다. 모르는 것을 모른다고 말하는 것(I'm not sure, but let me test that and get back to you.)도 완벽한 답변입니다.

3-5. 판정이 왔다 — 네 경우의 후속 행동

유효(triaged) 판정 예시 (화면 예시):

Status changed: New → Triaged
"We have validated the issue and forwarded it to the engineering team."

축하합니다. 기록표에 판정과 일시를 적고, 나중에 수정 확인(retest) 요청이 오면 협조합니다. 그리고 "내 첫 유효 제보"로 포트폴리오에 한 줄을 남깁니다.

중복 판정 예시 (화면 예시):

Status changed: New → Duplicate
"This issue was already reported by another researcher."

아쉽지만 실패가 아닙니다. 누군가 먼저 찾을 만큼 실제로 존재하는 취약점을 내 힘으로 찾았다는 뜻입니다. 사유를 읽고 — 먼저 제보된 시점이 언제였는지 등 — 다음에는 더 깊은 지점이나 덜 경쟁적인 타깃을 노리는 식으로 전략을 조정합니다.

N/A 판정 예시 (화면 예시):

Status changed: New → Not Applicable
"The reflected value is properly encoded in the response body.
Self-XSS in the admin panel is out of scope per program policy."

여기서 두 갈래가 있습니다. 사유가 맞으면 배움으로 삼고 넘어갑니다. 사유가 틀렸다고 확신하면 — 재현이 되는데 "인코딩됐다"고 하면 — 3-6의 재검토 요청으로 갑니다.

3-6. 재검토 요청 — 정중하지만 근거 있게

판정에 이견이 있을 때의 문장은 감정이 아니라 증거로 씁니다.

재검토 요청 예시:

Thank you for the review. I respectfully believe the issue is valid,
and I would like to ask for a second look.

The triage note says the value is encoded in the response body. That is
true for the profile page. However, the same value is rendered WITHOUT
encoding on the public share page (/share/{id}) — please see the
attached screenshot and the new request log.

Reproduction on /share/{id}:
1. (단계 재기술)

If this endpoint is also considered safe, I will accept the decision.
Thank you for your time.

읽는 법: 구조가 보이시나요? ① 감사와 존중 표명 → ② 상대 주장의 인정할 부분은 인정 → ③ 그러나 새로운 증거(상대가 못 본 지점) 제시 → ④ 그래도 안 되면 수용하겠다는 문구. 이 구조는 버그바운티를 넘어 모든 기술 논쟁에서 통하는 형식입니다.

왜 하는가: 재검토가 받아들여지지 않아도, 이 메시지 자체가 여러분의 평판을 올립니다. 반대로 "Why was this rejected?? I spent hours!!" 같은 감정적 메시지는 다음 제보의 판정에까지 그림자를 드리웁니다.

4. 미션과 연습문제

미션 — 제보 진행 기록표와 트리아지 역할극

Step 318의 제보서(또는 연습용 가상 제보서)를 실제 프로그램에 제출하거나, 제출할 수 없다면 "제출 시뮬레이션"으로 기록표의 제출 일시까지 채웁니다
3-2의 기록표 형식으로 제보 진행 기록표를 만들고, 상태가 바뀔 때마다 갱신합니다
3-3의 트리아저 질문(화면 예시)에 대한 답변을, 자신의 제보 내용에 맞춰 영어로 작성해 봅니다
"N/A — self-XSS는 scope 밖"이라는 가상 판정을 받았다고 가정하고, 3-6 구조로 재검토 요청 메시지를 영어로 작성해 봅니다

연습문제

문제 1. 판정 네 가지(유효/중복/정보성/N/A)를 각각 한 문장으로 설명하고, 중복 판정이 "실패가 아닌 이유"를 말해 보세요.

문제 2. 트리아저가 "제보서 3단계에서 멈춘다"는 질문을 보냈습니다. 어떤 정보들을 답변에 포함해야 하고, 어느 시간 안에 답하는 것이 좋은가요?

문제 3. 다음 재검토 요청의 문제점을 두 가지 이상 지적해 보세요: This is ridiculous. Your triager clearly did not even try my steps. Reopen this NOW.

문제 4. 판정 대기 기간(수일~수 주)에 해야 할 일과 하지 말아야 할 일을 각각 하나씩 들어 보세요.

5. 모범 답안과 완료 기준

미션 모범 답안

기록표는 3-2의 예시 형식에 실제 값이 채워져 있으면 됩니다. 핵심은 "판정 일시와 사유가 결과와 무관하게 기록됐는가"입니다 — 거절된 제보일수록 사유를 자세히 적으세요. 그것이 다음 탐색의 나침반입니다.

트리아저 답변의 모범 예 (가상의 Stored XSS 제보 기준):

Hi, thanks for checking.

1. Browser: Firefox 130.0 (Windows 11)
2. Recording attached — note the payload fires only after the bio is
   saved AND the page is reloaded (step 4 in my report).
3. Request/response attached with cookies removed.

Happy to provide anything else.

재검토 요청의 모범 예는 3-6의 구조를 따릅니다: ① 존중 표명 ② 상대 주장 중 맞는 부분 인정 ③ 새 증거 ④ 수용 문구. 네 요소가 모두 있으면 합격입니다.

검증하는 법: ① 기록표에 최소 "제출 일시/상태/다음 행동"이 있는가. ② 영어 답변이 24시간 규칙과 "요청한 것만 정확히" 원칙을 지키는가. ③ 재검토 요청에 감정 표현이 없고 증거가 있는가.

연습문제 해답

문제 1 해답. 유효는 취약점이 인정돼 수정·보상 절차로 넘어간 상태, 중복은 다른 연구자가 먼저 같은 취약점을 제보한 상태, 정보성은 취약점은 맞지만 영향이 작아 보상 기준에 못 미치는 상태, N/A는 scope 밖·규칙 위반·오해 등으로 취약점 자체가 인정되지 않은 상태입니다. 중복이 실패가 아닌 이유는, 실제로 존재하는 취약점을 남보다 늦었을 뿐 스스로 찾아냈다는 검증이기 때문입니다.

문제 2 해답. 실행 환경(브라우저/OS 버전), 재현 영상이나 더 상세한 단계, 쿠키 등 비밀을 지운 요청/응답 로그를 포함합니다. 답변은 24시간 안이 좋습니다. 재현에 필요한 조건이 제보서에 빠져 있었다면(예: 재로드 필요) 그 사실도 정직하게 밝힙니다.

문제 3 해답. ① 감정적이고 비난조입니다(ridiculous, NOW). ② 근거가 없습니다 — 왜 재현돼야 하는지, 상대가 놓친 조건이 무엇인지를 말하지 않습니다. ③ 상대 주장에 대한 인정이 없어 대화가 아니라 항의가 됩니다. 이런 메시지는 재검토 확률을 낮추고 평판을 깎습니다.

문제 4 해답. 해야 할 일: 같은 타깃의 다른 지점 탐색을 계속하거나 새 타깃의 정찰을 시작하는 것(제보 기록 정리도 포함). 하지 말아야 할 일: 판정 상태를 하루에도 여러 번 새로고침하며 기다리는 것, 그리고 답변 전에 같은 취약점을 다른 채널(벤더 이메일, SNS)에 중복 제출하는 것 — 이중 제출은 프로그램 규칙 위반이 될 수 있습니다.

완료 기준 체크리스트

[ ] 접수 → 트리아지 → 판정의 흐름을 설명할 수 있다
[ ] 판정 4종(유효/중복/정보성/N/A)의 의미와 후속 행동을 말할 수 있다
[ ] 트리아저 질문에 대한 영어 답변을 3-4 치트시트로 작성할 수 있다
[ ] 흔한 불인정 사유(scope 밖, 재현 불가, 영향 미달, 오해)를 열거할 수 있다
[ ] 재검토 요청의 4단 구조(존중→인정→증거→수용)를 쓸 수 있다
[ ] 미션: 제보 진행 기록표와 트리아지 역할극 문장을 완성했다

6. 흔한 실수와 해결

벽 1. 제출하고 나니 scope 밖이었다

증상 (화면 예시):

Status changed: New → Not Applicable
"This asset is out of scope per program policy."

원인: 제출 전 scope 재확인을 건너뛴 경우입니다. 프로그램 페이지의 scope 목록은 수시로 바뀝니다.
해결: 제출 직전에 scope 페이지를 다시 여는 것을 체크리스트에 고정하세요. 이미 벌어진 일이라면 사유를 기록하고 다음 제보 때 재발 방지에 활용합니다.

벽 2. 트리아저가 "재현이 안 된다"고 한다

증상 (화면 예시): I could not reproduce the issue following your steps.

원인: 제보서에 숨은 전제가 있는 경우가 대부분입니다 — 로그인 상태, 특정 브라우저, 재로드, 특정 계정 권한 같은 것들입니다.
해결: 당황하지 말고 3-3처럼 환경 정보·영상·로그를 24시간 안에 내면서, "발동 조건"을 문장으로 명시하세요. 영상이 최강의 증거입니다.

벽 3. 판정이 수 주째 안 온다

증상: 상태가 New나 Triaged에서 멈춰 있습니다.
원인: 트리아지 큐가 밀려 있거나, 벤더의 확인이 늦는 것입니다. 여러분이 풀 수 있는 문제가 아닙니다.
해결: 플랫폼 규정상 리마인더가 허용되면 1~2주 간격으로 정중히 한 번씩(Hi, just checking if there is any update. Thanks!). 그 사이에는 다음 탐색으로 시간을 씁니다.

벽 4. 재검토 요청을 보냈는데 오히려 사이가 나빠졌다

증상: 재검토 요청 후 트리아저의 답변이 차가워졌습니다.
원인: 요청 문장에 감정이나 단정이 섞인 경우입니다("분명히 취약점입니다"는 단정, "제가 재현했습니다"는 근거).
해결: 3-6의 구조를 다시 보세요. 상대 주장 중 맞는 부분을 먼저 인정하는 문장이 빠지면 요청이 논쟁으로 바뀝니다. 다음 메시지에서라도 "제가 놓친 조건이 있었는지 다시 확인하겠습니다"로 톤을 되돌릴 수 있습니다.

벽 5. 첫 제보가 중복이라 손이 안 움직인다

증상: Duplicate 판정 후 며칠째 아무것도 못 하고 있습니다.
원인: 정상적인 감정입니다. 다만 사실관계는 다릅니다 — 중복은 "틀린 제보"가 아니라 "늦은 정답"입니다.
해결: 기록표의 사유 칸에 "무엇을 배웠는가"를 한 줄 적으세요. "이 입력 필드는 경쟁이 치열하다", "이 타깃은 이미 많이 파였다" 같은 정보는 다음 탐색의 전략 자산입니다. 프로 헌터들도 유효율은 낮습니다 — 거절 사유는 무료 코칭입니다.

7. 정리

오늘의 개념

개념	한 줄 설명
트리아지(triage)	들어온 제보를 검토·분류하는 절차 — 응급실 분류에서 온 단어
트리아저	제보를 처음 읽고 판정하는 보안 전문가 — 적이 아니라 동료
유효(valid/triaged)	취약점 인정 판정
중복(duplicate)	먼저 제보된 취약점 — 늦은 정답이지 오답이 아니다
정보성(informative)	취약점은 맞으나 보상 기준 미달
N/A	취약점 불인정 — 사유를 읽고 배움 또는 재검토로
평판(reputation)	커뮤니케이션 태도가 쌓이는 헌터의 무형 자산

오늘의 문장과 형식

도구	하는 일
제보 진행 기록표	제출 일시~판정 사유까지의 타임라인 관리
24시간 규칙	트리아저 질문에 대한 답변 기한
`Could you share...` 계열	트리아저의 대표적 추가 요청 문형
재검토 요청 4단 구조	존중 → 인정 → 새 증거 → 수용

명령어보다 중요한 감각

제출 버튼은 끝이 아니라 대화의 시작입니다. 그리고 그 대화의 품질 — 빠르고, 정확하고, 정중한가 — 가 기술 실력만큼 오래 남습니다. 판정 결과보다 중요한 것은 기록입니다. 유효든 중복이든 N/A든, 사유를 적은 기록표 한 줄이 다음 제보의 방향을 바꿉니다.

마지막으로, 첫 제보가 거절되면 크게 실망하는 것이 정상입니다. 그럴 때는 이 한 문장을 기억하세요 — "거절 사유는 무료 코칭이다." 왜 안 됐는지 이해하고 다음 후보에 반영하면, 그것이 곧 실력입니다.

전부 체크되면 Step 319 완료입니다. 사이드바의 체크박스를 눌러 진도를 저장하세요.