AI 버그바운티로 포트폴리오 만들기

LLM·에이전트 레드티밍을 통해 자체 환경에서 충분히 연습했다면, 다음 단계는 실제 운영 중인 AI 제품을 대상으로 합법적으로 실력을 검증하는 것입니다. 버그바운티(Bug Bounty) 프로그램은 “허가받은 해킹"의 가장 대표적인 형태이며, AI 보안 분야에서는 특히 빠르게 성장하고 있는 영역입니다.

    flowchart LR
    subgraph SCOPE["프로그램 범위 확인"]
        S1["정책 문서 검토\n범위/금지행위/제출방식"]
    end

    subgraph FIND["취약점 유형"]
        V1["프롬프트 인젝션"]
        V2["탈옥(Jailbreak)"]
        V3["데이터 유출\n(시스템 프롬프트/RAG)"]
        V4["에이전트 도구\n권한 상승"]
        V5["모델 추출 /\nRate limit 우회"]
    end

    subgraph REPORT["리포트 작성"]
        R1["재현 단계 + 재현율\n(N회 중 성공 횟수)"]
        R2["영향(Impact)\n비즈니스 관점 설명"]
        R3["완화 제안\n+ 책임 있는 공개"]
    end

    S1 --> V1 & V2 & V3 & V4 & V5
    V1 --> R1
    V2 --> R1
    V3 --> R1
    V4 --> R1
    V5 --> R1
    R1 --> R2 --> R3
    R3 -.연습.- LRT["자체 실습\n(LLM·에이전트 레드티밍)"]

    classDef scope fill:#e7f1ff,stroke:#3b82f6,color:#1e3a8a;
    classDef threat fill:#fff3cd,stroke:#d39e00,color:#664d03;
    class S1,R1,R2,R3,LRT scope;
    class V1,V2,V3,V4,V5 threat;
  

1. AI 제품 버그바운티의 특징

전통적인 웹 버그바운티와의 차이

이런 차이 때문에, AI 버그바운티는 전통적인 침투테스트 스킬만으로는 부족하고, LLM·에이전트 레드티밍에서 다룬 harm list 기반 사고와 재현성 있는 기록 습관이 훨씬 중요해집니다.

AI 버그바운티가 주목받는 이유

• 생성형 AI 제품이 빠르게 출시되면서, 출시 전에 모든 실패 모드를 내부적으로 발견하기 어렵습니다.
• 모델 제공자와 애플리케이션 개발사가 분리되어 있는 경우가 많아, “모델은 안전하지만 애플리케이션이 취약한” 사례를 외부 연구자가 발견하는 것이 가치 있습니다.
• 많은 기업이 AI 관련 취약점을 별도 카테고리로 분류하고, 보상 정책을 운영하기 시작했습니다.

2. 어떤 종류의 취약점이 주로 리포트되는가

(1) 프롬프트 인젝션 (Prompt Injection)

• 시스템 프롬프트를 무시하게 만들거나, 외부 데이터(웹페이지, 문서, 이메일)에 삽입된 지시를 모델이 따르게 하는 사례
• 특히 에이전트형 제품에서, 인젝션된 지시가 실제 도구 호출(파일 삭제, 이메일 전송, 결제 등)로 이어지는 경우는 매우 높은 심각도로 평가됩니다
• 관련 개념: 프롬프트 인젝션

(2) 탈옥 (Jailbreak)

• 콘텐츠 정책을 우회해 금지된 콘텐츠(무기 제작, 악성코드, 차별적 콘텐츠 등)를 생성하게 만드는 사례
• 단발성 우회보다는, 일관되게 재현 가능한 우회 패턴을 보여줄 때 더 가치 있게 평가됩니다
• 관련 개념: 탈옥(Jailbreak)

(3) 데이터 유출 (Data Leakage)

• 시스템 프롬프트, 다른 사용자의 대화 내용, RAG에 포함된 비공개 문서, 학습 데이터의 일부를 노출하는 사례
• 멀티 테넌트(multi-tenant) 환경에서 “사용자 간 격리"가 깨지는 경우는 특히 심각하게 다뤄집니다

(4) 에이전트 도구의 권한 상승 (Privilege Escalation in Agent Tools)

• 에이전트가 호출할 수 있는 도구(파일 시스템 접근, 코드 실행, API 호출 등)의 권한 경계를 벗어나는 사례
• 예: “읽기 전용으로 설계된 도구를 통해 쓰기 작업을 유도”, “사용자 A의 권한으로 사용자 B의 데이터에 접근”
• 이 영역은 전통적인 IDOR(Insecure Direct Object Reference), SSRF 같은 취약점과 AI 특화 취약점이 결합되는 경우가 많습니다

(5) 기타

• 모델 추출, 멤버십 추론 등 모델 탈취 및 추출 섹션에서 다룬 공격의 실제 사례
• Rate limiting 우회를 통한 자원 남용(예: 무제한 API 호출로 비용 유발)

3. 좋은 리포트 작성법

AI 버그바운티에서는 “취약점이 존재한다"는 주장만으로는 충분하지 않습니다. 재현 가능하고, 영향이 명확하며, 완화 방안까지 제시하는 리포트가 높은 평가를 받습니다.

리포트 구조 템플릿

## 제목
[간결하고 구체적인 제목 — 예: "RAG 문서를 통한 시스템 프롬프트 유출"]

## 요약 (Summary)
한 문단으로 핵심 내용을 설명. 어떤 취약점인지, 무엇을 할 수 있는지.

## 재현 단계 (Steps to Reproduce)
1. ...
2. ...
3. ...
(스크린샷, 전체 프롬프트/응답 텍스트, 가능하면 스크립트 첨부)

## 재현율 (Reproducibility)
- 10회 시도 중 N회 성공
- 어떤 조건에서 더 잘 재현되는지 (특정 언어, 특정 길이의 입력 등)

## 영향 (Impact)
- 이 취약점이 악용될 경우 어떤 피해가 발생하는가
- 실제 공격자가 이를 어떻게 활용할 수 있는가 (구체적인 시나리오)

## 완화 제안 (Suggested Mitigation)
- 시스템 프롬프트 수정, 입력/출력 필터링, 권한 분리 등 구체적인 제안
- 가능하다면 [방어 기법](/docs/defenses) 섹션에서 다룬 기법과 연결

## 참고 자료
- 관련 CWE, MITRE ATLAS 전술 등

리포트 품질을 높이는 팁

• 재현 영상/스크립트 첨부: 비결정적인 모델 응답의 특성상, 텍스트 설명만으로는 신뢰도가 떨어질 수 있습니다.
• “왜 이게 문제인가"를 비즈니스 관점에서 설명: 단순히 “모델이 이상한 말을 했다"가 아니라, “이로 인해 회사가 법적/재정적/평판 리스크에 노출된다"는 식으로 영향(impact)을 구체화합니다.
• 과장하지 않기: 심각도를 과도하게 부풀리면 신뢰를 잃습니다. 영향 범위를 정직하게 기술하는 것이 장기적으로 더 좋은 평판을 만듭니다.
• 중복 제출 피하기: 제출 전 기존 공개된 리포트나 알려진 이슈를 검색해 중복을 피합니다.

4. 입문자가 시작하는 방법

(1) 공개 프로그램 탐색

• 주요 AI 기업들은 자체 버그바운티 프로그램을 운영하거나, HackerOne/Bugcrowd 같은 플랫폼을 통해 AI 관련 범위를 공개합니다.
• 처음에는 보상 규모보다, “AI/LLM” 카테고리가 명시되어 있고 범위(scope)가 명확한 프로그램을 선택하는 것이 좋습니다.
• 프로그램의 정책 문서에서 다음을 반드시 확인하세요: 테스트 가능한 범위, 금지된 행위, 리포트 제출 방식, 응답 기간.

(2) 책임 있는 공개 (Responsible Disclosure)

• 프로그램이 없는 시스템에서 우연히 취약점을 발견했다면, 공개 전에 먼저 해당 조직에 비공개로 연락하는 것이 표준 관례입니다.
• 합리적인 시간(통상 30~90일) 동안 수정할 기회를 주고, 그 이후에야 공개 여부를 논의합니다.
• 이 절차를 지키는 것 자체가 “신뢰할 수 있는 보안 연구자"로서의 평판을 쌓는 핵심 요소입니다.

(3) 자체 실습으로 시작하기

• 아직 외부 프로그램에 제출할 준비가 안 되었다면, LLM·에이전트 레드티밍에서 다룬 작은 RAG 챗봇 실습으로 먼저 “리포트 작성 연습"을 해보세요.
• 자체 환경에서 작성한 리포트는 그대로 포트폴리오 프로젝트의 산출물이 됩니다.

5. 정리

AI 버그바운티는 단순히 “취약점을 찾아 돈을 받는 활동"이 아니라, 실제 운영 환경에서 통하는 위협모델을 검증하고, 업계 표준에 맞는 리포트를 작성하는 훈련 과정입니다. 이 경험은 이력서나 면접에서 “AI 보안 실무 경험이 있다"는 가장 강력한 증거가 되며, 다음 페이지의 포트폴리오 프로젝트와 직접 연결됩니다.