본문 바로가기

버그 바운티 프로그램

Capgo는 보안과 투명성에 전념하고 있습니다. 모든 code는 오픈 소스이며, 보안 연구자분들이 저희 codebase의 취약점을 찾는 데 도움을 주시기를 환영합니다.

오픈 소스 Code

Capgo 조직의 모든 repository는 오픈 소스입니다. 저희 code를 직접 검토하고 감사하며 기여하실 수 있습니다.

GitHub 조직: github.com/Cap-go

Capgo 백엔드 및 랜딩 페이지

Capgo backend 및 제품 리포지토리 (capgo.app API, dashboard 및 관련 서비스)

리포지토리 보기 보안 이슈 제보하기

Capacitor Updater 플러그인

모바일 기기의 over-the-air 업데이트를 처리하는 핵심 Capacitor plugin

리포지토리 보기 보안 이슈 제보하기

유효한 제보 요건

Bug Bounty 프로그램 대상이 되려면, 제보 내용이 다음 요건을 모두 충족해야 합니다:

  • GitHub repository 내에서 취약점이 존재하는 정확한 파일과 라인 번호를 식별해야 합니다.
  • 해당 repository의 GitHub Security Advisory를 통해 리포트를 제출해야 합니다.
  • 취약점에 대한 명확한 설명과 잠재적 영향을 반드시 포함해야 합니다.
  • 문제를 재현할 수 있는 단계를 제공해야 합니다.

중요: GitHub 내 code의 정확한 라인을 특정할 수 없는 경우, Bug Bounty 프로그램 대상에서 제외됩니다. 리포트는 반드시 GitHub Security Advisory를 통해서만 제출해야 합니다. 보상은 Algora.io를 통해 지급되므로, 플랫폼에서 직접 보상을 받으실 수 있도록 계정을 생성해 주세요.

응답 시간과 존중

저희는 친절하며 유효한 리포트에 대해서는 보상을 지급하지만, 저희의 시간을 존중하지 않는 분들과는 협업할 수 없습니다. 차분하게 소통해 주시고 본 프로그램의 규정을 따라 주세요.

  • 보안 리포트 및 침해 사고에 대해서는 24~72시간 이내에 응답합니다.
  • 스팸을 보내지 마세요. 하루에 이메일을 3회 이상 보내는 경우 스팸으로 간주되어 차단됩니다.
  • 규정을 준수하지 않거나 스팸성인 리포트에는 보상을 지급하지 않습니다.
  • 본 Bug Bounty 프로그램을 따르는 범위 내 리포트만 접수되며, 그 외의 사항은 차단될 수 있습니다.
  • "확인해 보셨나요?"와 같이 진행 상황을 묻는 질문은 삼가 주세요. 제보 접수가 확인되면 충분합니다. 이후에도 많은 작업이 필요하며, pull request를 준비하는 데 며칠이 소요될 수 있습니다.

중요: Capgo는 규모가 작은 스타트업이므로, 대기업의 버그 바운티 프로그램보다 보상 금액이 적습니다. 명확한 exploit path가 없는 제보는 최대 $30까지 지급됩니다. Capgo에 실질적이고 재현 가능한 영향을 미치는 exploit의 경우 최대 $300까지 지급됩니다. Capgo 플러그인에 대한 보안 제보도 검토하지만, 플러그인 code에 대한 유료 보상은 @capgo/capacitor-updater.로 제한됩니다. 기타 Capgo 플러그인은 무료로 제공되는 제품으로, 제보 내용은 검토하지만 별도의 보상은 지급되지 않습니다. 보상은 이슈 확인, 수정 버전 출시, 그리고 출시 후 해당 수정 사항이 정상 작동함을 사용자가 직접 확인한 후에만 지급됩니다. 단순히 pull request를 생성하거나 링크를 공유하는 것만으로는 지급 대상이 되지 않습니다. 이 과정은 심각도와 릴리스 주기에 따라 며칠에서 몇 주가 소요될 수 있습니다. "보상금을 받으려면"과 같은 메시지는 보내지 말아 주세요. 보상은 릴리스가 배포되고 사용자가 수정 사항을 테스트 및 검증한 후에만 이루어집니다.

제보 방법

  1. GitHub의 관련 repository로 이동하세요
  2. "Security" 탭을 클릭하세요
  3. "Report a vulnerability"를 클릭하여 새로운 security advisory를 생성하세요
  4. 취약점이 존재하는 정확한 파일 경로와 라인 번호를 포함해 주세요
  5. 문제를 재현할 수 있는 상세한 단계와 보안 영향에 대해 설명해 주세요.

제외 대상

  • GitHub 내 code 코드 라인 참조가 없는 보고서
  • GitHub Security Advisory를 통해 제출되지 않은 보고서
  • PoC(Proof of Concept)가 없는 이론적인 취약점
  • Capgo이 직접 수정할 수 없는 타사 플랫폼, 의존성 또는 서비스의 버그 (예: Supabase와 같은 업스트림에 보고)
  • 사회 공학적 공격 또는 피싱 시도
  • DoS(Denial of Service) 공격
  • webhook 또는 웹사이트 프리뷰에 대한 SSRF 또는 DNS spoofing 보고. 해당 기능은 serverless 인프라에서 실행되며 Capgo의 프라이빗 인프라에 접근하는 데 사용할 수 없으므로, 당사 환경에서는 익스플로잇이 불가능합니다.
  • capacitor.config.ts, config.capacitor.ts, code 앱 소스 및 환경별 설정을 포함하여, Capgo이 소유, 배포 또는 제어하지 않는 사용자 소유의 애플리케이션 code 또는 프로젝트 구성.
  • Capgo bundle 파일에 대한 접근 또는 bundle 파일을 다운로드할 수 있다는 증거. Bundle 파일은 공개된 웹 에셋이며 사용자는 이에 대해 안내받으므로, 해당 파일에 대한 접근은 데이터 유출로 간주되지 않습니다.
  • 설계상 의도적으로 공개된 인증되지 않은 Capgo plugin/API 엔드포인트 — API 키가 필요 없는 channel_self 설정 및 update/stats 엔드포인트 포함 — 는 취약점이 아닙니다. 이를 취약점으로 보고하지 마세요.
  • external_url을 통해 제공되는 bundle의 암호화가 Uploader 또는 UI에서 잘못 표시되는 것은 Capgo 취약점이 아닙니다 (외부 호스팅 bundle의 암호화는 Capgo의 제어 범위를 벗어납니다).

Supabase 및 제3자 서비스

근본 원인이 Supabase 플랫폼이나 서비스의 버그인 경우, Capgo이 아닌 Supabase에 보고해야 합니다. 만약 취약한 로직, SQL, RPC, RLS 정책, Edge Function 또는 설정이 Capgo에 의해 생성되었거나 선택되었고 저희 프로젝트 내에서 수정이 가능하다면, Supabase가 엔드포인트를 제공하더라도 조사 범위에 포함됩니다. Supabase 자체의 동작에 관한 발견 사항은 재현 가능한 사례와 함께, 저희와 유사하게 구성된 프로젝트에서 해당 동작을 방지할 수 있는 정확한 Supabase 설정 또는 구성 변경 사항을 포함해 주세요.

예시

해당 사항 없음

  • Supabase 플랫폼 버그, 장애 또는 Supabase만 해결할 수 있는 동작
  • 재현할 수 없는 발견 사항
  • Capgo이 제어하는 수정 방법이나 정확한 Supabase 설정/구성 변경 사항을 제시하지 않은 채, Supabase의 동작을 Capgo의 책임으로 돌리는 주장

해당 사항 있음

  • 저희 프로젝트 설정에서 (단계별 가이드와 함께) 수정 가능한 Capgo 제어 하의 Supabase 설정 오류
  • 보안에 취약한 Supabase 사용을 유발하는 Capgo 소유의 SQL, RPC, RLS, function 또는 통합 이슈
  • Supabase 엔드포인트를 통해 노출되더라도, Capgo의 Supabase 프로젝트, 스키마 또는 정책에서 발생하는 재현 가능한 이슈

알려진 Supabase Auth 제한 사항 (이미 보고됨)

일부 발견 사항은 Capgo code의 문제가 아니라 Supabase Auth 기본 설정이나 플랫폼 동작 때문에 반복적으로 보고됩니다. 이런 사항은 당사와 동일하게 구성된 Supabase 데모 프로젝트에서 재현 가능하고, Capgo 보안 규칙을 변경할 필요 없이 Supabase 측 설정 변경만으로 해결되는 경우에만 검토합니다. 해결을 위해 Capgo 소유의 SQL, RPC, RLS 정책, 함수 또는 앱 로직을 변경해야 한다면 이는 보상 범위에 해당하므로 저희에게 보고해 주세요.

  • 재현 가능한 사례를 제공하고 정확한 해결 방법을 명시해 주세요. 즉, Supabase 동작 문제를 해결하는 Supabase 설정/구성 변경인지, 아니면 Capgo 소유의 code/config 객체를 변경해야 하는지입니다.
  • 이메일 인증 동작은 Supabase Auth 프로젝트 설정(예: 이메일 확인 비활성화 여부, 캡처 기반 인증 사용 여부)을 따르는 것이 정상입니다.
  • Supabase Auth가 그렇게 설정되어 있다면, 비밀번호 변경 및 계정 복구 흐름에서 기존 비밀번호 재입력이나 재인증이 항상 필요하지 않을 수 있습니다.
  • 해당 이슈가 이 목록에 있더라도, 제공된 프로젝트에서 구체적인 Supabase 측 해결 방법을 보여주거나 Capgo 소유의 구체적인 보안 결함을 입증할 수 있다면 보상 범위로 검토할 수 있습니다.

Bug Bounty 프로그램 관련 문의는 GitHub Security Advisories를 통해 연락해 주세요.