Skip to main content

버그 보너스 프로그램

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

오픈 소스 Code

Every repository in the Capgo organization is open source. You can review, audit, and contribute to our code.

GitHub Organization: github.com/Cap-go

Capgo 백엔드 & 랜딩

Main Capgo repository including backend services and landing website

Capacitor Updater Plugin

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

BUG Bounty 프로그램에 대한 요구 사항

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

  • 해당 취약성의 위치를 정확하게 식별한 GitHub 저장소의 특정 파일과 라인 번호를 지정해야 합니다.
  • BUG Bounty 프로그램에 참가하기 위해서는 GitHub 보안 고지서를 통해 해당 저장소에 제출해야 합니다.
  • 취약성의 설명과 그 잠재적 영향에 대한 명확한 설명을 포함해야 합니다.
  • 취약성을 재현할 수 있는 단계를 제공해야 합니다.

중요: 해당 취약성의 위치를 정확하게 식별하지 못하거나 GitHub에서 code의 특정 라인을 지정하지 못하는 경우 BUG Bounty 프로그램에 참가할 수 없습니다. BUG Bounty 프로그램에 참가하기 위해서는 GitHub 보안 고지서를 통해만 제출해야 합니다. Algora.io를 통해 지불이 처리되며, 해당 플랫폼에서 직접 지불을 받으려면 계정을 생성해야 합니다.

응답 시간과 존중

우리는 친절하고 BUG Bounty 프로그램에 참가한 경우에만 지불을 합니다. 그러나 우리의 시간을 존중하지 않는 사람들과 협력할 수 없습니다. 통신을 차분하게 유지하고 이 프로그램을 따르십시오.

  • 24-72시간 이내에 보안 보고서 및 침해에 대한 응답을 드립니다.
  • 우리에 대한 스팸을 보내지 마십시오. 단일 일 내에 3개 이상의 이메일이 스팸으로 간주되어 차단될 것입니다.
  • 이 규칙을 무시하거나 스팸인 보고서에 대한 보상을 제공하지 않습니다.
  • 이 버그 보너스 프로그램을 따르는 인 스코프 보고서만 수락합니다. 다른 보고서는 차단될 수 있습니다.
  • 보고서 상태 업데이트에 대한 질문을 하지 마십시오. 우리가 보고서를 받은 것을 확인하면 충분합니다. 그 후에는 여전히 많은 작업이 남아 있으며 pull request를 준비하는 데 수일이 걸릴 수 있습니다.

중요: Capgo은 작은 부트스트랩 회사이기 때문에 우리의 보너스 금액은 대기업 프로그램보다 낮습니다. 명확한 공격 경로가 없는 보고서에 대한 보상은 최대 $30까지 제공됩니다. 실제로 재현 가능한 영향을 가지는 공격은 Capgo에 대해 최대 $300까지 제공됩니다. 우리는 Capgo 플러그인에 대한 보안 보고서를 수락하고 검토합니다. 그러나 @capgo/capacitor-업데이터에 대한 플러그인 code에 대한 보너스 보상은 제한됩니다. 다른 Capgo 플러그인은 우리의 유료 제품 제공과 관련이 없으므로 보고서를 검토하지만 보상을 제공하지 않습니다. 지불은 문제를 식별하고 수정한 후 pull request를 열었으며 그 후에 릴리스가 활성화되었을 때 보고서 작성자가 테스트하고 유효성을 검사한 후에만 이루어집니다. 일반적으로 20-30일이 걸립니다. 릴리스가 활성화되고 테스트 및 유효성을 검사한 후에만 지불이 이루어지므로 '지불을 위해'라는 메시지를 보내지 마십시오.

보고 방법

  1. GitHub의 관련 저장소로 이동하십시오.
  2. 보안 탭을 클릭하세요.
  3. 취약점을 보고하려면 "취약점 보고"를 클릭하세요.
  4. __CAPGO_KEEP_0__에서 취약성이 존재하는 정확한 파일 경로와 줄 번호를 포함하세요.
  5. __CAPGO_KEEP_1__에서 __CAPGO_KEEP_0__의 정확한 줄 번호가 없는 보고서

__CAPGO_KEEP_0__ 보안 고지서를 통해 제출되지 않은 보고서

  • Reports without exact code line references in GitHub
  • GitHub가 직접 수정할 수 없는 외부 플랫폼, 의존성 또는 서비스의 버그 (예를 들어 Supabase로 보고)
  • 사회 공학 또는 피싱 시도
  • Bugs in third-party platforms, dependencies, or services that Capgo cannot fix directly (report those upstream, for example to Supabase).
  • __CAPGO_KEEP_0__의 사설 인프라에 접근할 수 없는 웹후크 또는 사이트 미리보기에 대한 SSRF 또는 DNS 위조 보고
  • 이러한 기능은 서버리스 인프라에서 실행되므로 __CAPGO_KEEP_0__의 사설 인프라에 접근할 수 없습니다. 따라서 우리 환경에서 공격할 수 없습니다.
  • Capgo의 사설 인프라에 접근할 수 없는 웹후크 또는 사이트 미리보기에 대한 SSRF 또는 DNS 위조 보고
  • 사용자가 소유한 애플리케이션 code 또는 프로젝트 구성이 Capgo이 소유하지 않거나 배포하지 않거나 제어하지 않는 파일, capacitor.config.ts, config.capacitor.ts, 앱 소스 code, 환경에 따라 설정된 설정을 포함합니다.
  • Capgo 배포 파일에 대한 접근 또는 배포 파일이 다운로드 될 수 있는 증거

Supabase 및 제 3 자 서비스

Supabase 플랫폼 또는 서비스 버그의 원인이면 Supabase에 보고하고 Capgo에 보고하지 마십시오. Capgo이 만든 또는 선택한 취약한 논리, SQL, RPC, RLS 정책, Edge Function 또는 구성이 프로젝트에서 수정할 수 있다면 Supabase가 제공하는 엔드포인트와 관계없이 범위에 포함됩니다. Supabase 동작에 대한 발견은 프로젝트와 같이 구성된 경우 Supabase 설정 또는 구성 변경이 예방하는 정확한 경우를 포함하여 reproducible한 경우를 포함하여 Supabase에 포함되어야 합니다.

예시

유효하지 않습니다

  • Supabase 플랫폼 버그, 중단 또는 Supabase만이 수정할 수 있는 동작
  • 재현할 수 없는 발견
  • Supabase 동작을 Capgo에 비난하는 주장입니다. Capgo가 제어하는 수정 또는 정확한 Supabase 설정/구성 변경을 제공하지 않습니다.

유효합니다

  • Capgo가 제어하는 Supabase 미구성화가 프로젝트 설정에서 수정할 수 있는 단계를 포함하여 프로젝트 설정에서 수정할 수 있습니다.
  • Capgo가 소유한 SQL, RPC, RLS, 함수 또는 통합 문제가 불안전한 Supabase 사용을 유발합니다.
  • Capgo의 Supabase 프로젝트, 스키마 또는 정책에서 재현할 수 있는 문제, 심지어 그것이 Supabase 엔드포인트를 통해 노출되는 경우에도

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

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

  • 재현할 수 있는 사례를 제공하고 정확한 수정을 식별하세요: Supabase 설정/구성 변경이 Supabase 동작 문제를 해결하거나 Capgo 소유 code/구성 항목이 변경되어야 하는 경우
  • 이메일 확인 동작은 Supabase 인증 프로젝트 설정에 따라 예상됩니다 (예를 들어, 이메일 확인이 비활성화되어 있고 캡처 기반 인증이 사용되는 경우)
  • 패스워드 업데이트 및 계정 복구 흐름은 항상 이전 패스워드 재입력 또는 재인증이 필요하지 않습니다. 왜냐하면 Supabase 인증이 그렇게 구성되어 있기 때문입니다.
  • If the issue is in this list but you can show a concrete Supabase-side fix in the provided project or a concrete Capgo-owned security defect, we can consider it in scope.

이 문제가 이 목록에 있지만, 제공된 프로젝트에서 Supabase 측에서 구체적인 수정을 보여줄 수 있고 GitHub 소유 보안 결함을 구체적으로 보여줄 수 있다면, 우리는 그것을 고려할 수 있습니다.