메인 콘텐츠로 건너뛰기

버그 보너스 프로그램

Capgo는 보안과 투명성을 위해 최선을 다하고 있습니다. 모든 code는 오픈 소스이며, 우리는 코드베이스에서 취약점을 식별하는 데 도움을 주기 위해 보안 연구자들을 환영합니다.

오픈 소스 Code

Capgo 조직의 모든 저장소는 오픈 소스입니다. code을 검토, 감사, 기여할 수 있습니다.

GitHub 조직: github.com/Cap-go

Capgo 백엔드 & 랜딩

모바일 장치에서 오버 더 에어 업데이트를 처리하는 핵심 Capgo 플러그인

Capacitor Updater Plugin

The core Capacitor plugin that handles over-the-air updates on mobile devices

__CAPGO_KEEP_0__의 유효한 보고서에 대한 요구 사항

Bug Bounty 프로그램에 참가하기 위해, 다음의 모든 요구 사항을 충족해야 합니다.

  • GitHub의 GitHub 저장소에서 취약성의 정확한 파일 및 라인 번호를 식별해야 합니다.
  • GitHub 보안 고지서를 관련 저장소에서 GitHub로 제출해야 합니다.
  • 취약성 및 그 잠재적 영향에 대한 명확한 설명을 포함해야 합니다.
  • 취약성의 증명 가능한 단계를 제공해야 합니다.

중요한 점: GitHub의 code 라인에 문제가 있는 경우 정확한 라인을 제공할 수 없다면 Bug Bounty 프로그램에 참가할 수 없습니다. GitHub 보안 고지서만 제출해야 하며, Algora.io에서 계정을 생성하여 직접 지불할 수 있도록 해 주세요.

응답 시간 및 존중

우리는 친절하고 유효한 보고서에 대한 보상을 지불하지만, 우리의 시간을 존중하지 않는 사람들과 협력할 수 없습니다. 보고서와 침해에 대한 보안 보고서에 대한 응답은 24-72시간 이내에 이루어집니다.

  • 우리는 스팸을 받지 않습니다. 하루에 세 개 이상의 이메일을 보내면 스팸으로 간주되어 차단됩니다.
  • __CAPGO_KEEP_1__은 __CAPGO_KEEP_0__입니다.
  • 이러한 규칙을 무시하거나 스팸인 경우 보상금을 지불하지 않습니다.
  • 이 버그 보너스 프로그램을 따르는 내부 범위의 보고서만 인정합니다. 다른 경우 차단될 수 있습니다.
  • 상태 업데이트를 요청하지 마십시오. 예를 들어 "확인했나요?"와 같은 질문. 우리가 보고서를 받은 것을 확인하면 그만입니다. 그 후에도 여전히 많은 작업이 남아 있으며 pull request를 준비하는 데 수일이 걸릴 수 있습니다.

중요: Capgo은 작은 회사이기 때문에 보너스 금액이 큰 회사 프로그램보다 낮습니다. exploit 경로가 명확하지 않은 보고서는 최대 $30까지 지불됩니다. Capgo에 실제로 reproducible한 영향을 미치는 exploit은 최대 $300까지 지불됩니다. Capgo 플러그인에 대한 보안 보고서를 받고 검토합니다. 그러나 code 플러그인에 대한 지불은 @capgo/capacitor-업데이터에 한정됩니다. 다른 Capgo 플러그인은 우리의 지불 제품 제공과 관련이 없으므로 지불되지 않습니다.

보고하기

  1. GitHub의 관련 저장소로 이동하세요.
  2. 보안 탭을 클릭하세요.
  3. 보안 고지서를 생성하기 위해 "보안 취약점 보고"를 클릭하세요.
  4. 파일 경로와 줄 번호를 포함하여 취약성의 정확한 위치를 포함하십시오.
  5. 취약성의 reproduce 방법과 보안 영향에 대한 자세한 설명을 제공하십시오.

범위 밖

  • code 라인 참조가 포함되지 않은 GitHub에 제출되지 않은 보고서
  • GitHub 보안 고지서를 통해 제출되지 않은 보고서
  • 증명된 proof of concept가 없는 이론적 취약성
  • Capgo이 직접 수정할 수 없는 third-party 플랫폼, 의존성, 또는 서비스의 버그 (예를 들어 Supabase에 보고하십시오).
  • 사회 공학 또는 피싱 시도
  • 서비스 거부 공격
  • SSRF 또는 DNS 위조 보고서 (웹후크 또는 웹사이트 미리보기에 대한 것). 이 기능은 서버리스 인프라에서 실행되므로 Capgo의 사설 인프라에 접근할 수 없으므로 우리 환경에서 공격할 수 없습니다.
  • 사용자 소유의 code 애플리케이션 또는 프로젝트 설정 ( Capgo이 소유, 배포, 또는 제어하지 않는 파일, 예를 들어 capacitor.config.ts, config.capacitor.ts, 앱 소스 code, 환경에 따라 설정).
  • Capgo 번들 파일에 대한 접근 또는 번들 파일이 다운로드 될 수 있다는 증거. 번들 파일은 공개 웹 자산이며 사용자는 이를 알리고 번들 파일에 대한 접근은 데이터 침해로 간주되지 않습니다.

Supabase 및 제 3 자 서비스

If the root cause is a Supabase platform or service bug, report it to Supabase, not Capgo. If the vulnerable logic, SQL, RPC, RLS policy, Edge Function, or configuration was created or chosen by Capgo and we can fix it in our project, it is in scope even when Supabase serves the endpoint. For findings about Supabase behavior itself, include a reproducible case and the exact Supabase setting or config change that prevents it in a project configured like ours.

예시

유효하지 않음

  • Supabase 플랫폼 버그, 중단 또는 Supabase만 수정할 수 있는 동작
  • 재현할 수 없는 발견
  • A claim that blames Capgo for Supabase behavior without showing a Capgo-controlled fix or the exact Supabase setting/config change

유효함

  • Capgo가 제어하는 Supabase 미사용 설정 (단계 포함)
  • Capgo가 소유한 SQL, RPC, RLS, 함수 또는 통합 문제로 인한 불안정한 Supabase 사용
  • Capgo의 Supabase 프로젝트, 스키마 또는 정책에서 재현할 수 있는 문제, 심지어 엔드포인트를 통해 노출된 경우

알려진 Supabase 인증 제한 (이미 보고됨)

일부 발견은 Supabase Auth 기본 설정 또는 플랫폼 동작으로 인해 Capgo code로 인해 반복적으로 보고되는 경우입니다. 우리는 이러한 발견을 공유된 Supabase 데모 프로젝트에서 재현할 수 있고, 우리와 같은 설정으로 구성된 경우에만 검토합니다. 또한, 고치는 것이 Supabase 측의 설정 변경으로 인한 것이고, Capgo 보안 규칙 변경이 필요하지 않다면만 검토합니다. 고치는 것이 Capgo 소유 SQL, RPC, RLS 정책, 함수, 또는 앱 로직 변경이 필요한 경우에는 우리에게 보고해 주세요. 왜냐하면 그게 범위에 포함된 것입니다.

  • 문제를 재현할 수 있는 경우를 제공하고, 정확한 고치는 것을 식별하세요. 고치는 것이 Supabase 설정/구성 변경으로 인한 Supabase 동작 문제를 해결하거나, Capgo 소유 code/구성 항목이 변경되어야 하는 경우입니다.
  • 이메일 인증 동작은 Supabase Auth 프로젝트 설정에 따라 예상됩니다. (예를 들어, 이메일 확인이 비활성화되어 있고 캡처 기반 인증이 사용되는 경우).
  • 패스워드 업데이트 및 계정 복구 흐름은 항상 이전 패스워드 재입력 또는 재인증이 필요하지 않을 수 있습니다. 왜냐하면 Supabase Auth가 그럴 수 있기 때문입니다.
  • 이 목록에 있는 문제가 있지만, 제공된 프로젝트 또는 Capgo 소유 보안 결함에 대한 구체적인 Supabase 측 고치가 제공되는 경우, 우리는 그 범위에 포함할 수 있습니다.

Capgo Bug Bounty 프로그램에 대한 질문은 GitHub 보안 고지서를 통해 연락해 주세요.