메인 콘텐츠로 건너뛰기

버그 보너스 프로그램

Capgo는 보안과 투명성을 위해 최선을 다하고 있습니다. 모든 code는 오픈 소스이며, 우리는 보안 연구원들을 통해 코드베이스의 취약점을 식별하는 것을 환영합니다.

오픈 소스 Code

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

GitHub 조직: github.com/Cap-go

Capgo 백엔드 & 랜딩

Capgo의 주요 저장소, 백엔드 서비스 및 랜딩 웹사이트를 포함합니다.

Capacitor 업데이터 플러그인

Capacitor 플러그인이 모바일 장치에서 오버 더 에어 업데이트를 처리합니다.

유효한 신고의 요구 사항

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

  • 당신은 GitHub 저장소에서 취약성의 위치를 정확하게 식별해야 합니다.
  • 당신의 신고는 GitHub의 __CAPGO_KEEP_1__에서 취약성이 존재하는 정확한 라인 번호를 포함해야 합니다.
  • 당신의 신고는 관련 저장소의 __CAPGO_KEEP_0__ 보안 고지서에 제출해야 합니다.
  • 당신은 취약성의 설명과 그 잠재적 영향에 대한 명확한 설명을 포함해야 합니다.

당신은 문제를 재현할 수 있는 단계를 제공해야 합니다. If you cannot provide the exact line of code in GitHub where the problem exists, your report will not be eligible for the Bug Bounty program. Reports must be submitted through GitHub Security Advisory only. Payments are handled via Algora.io; please create an account there so we can pay you directly on the platform.

당신이 __CAPGO_KEEP_1__의 __CAPGO_KEEP_0__에서 취약성의 위치를 정확하게 식별하지 못한다면, 버그 보너스 프로그램에 참가할 수 없습니다. 신고는 __CAPGO_KEEP_2__ 보안 고지서에만 제출해야 합니다. Algora.io에서 계정을 생성하여 직접 지불을 받을 수 있도록 해 주세요.

응답 시간과 존중

  • We respond to security reports and breaches within 24-72 hours.
  • 이메일 스팸을 보내지 마세요. 하루에 세 개 이상의 이메일을 보낼 경우 스팸으로 간주되어 차단될 것입니다.
  • 이 규칙을 무시하거나 스팸인 보고서에 대한 보상을 제공하지 않습니다.
  • 이 버그 보너스 프로그램의 규칙을 따르는 범위 내의 보고서만 인정합니다. 다른 경우 차단될 수 있습니다.
  • 보고서 상태 업데이트를 요청하지 마세요. 예를 들어 "확인했어?"와 같은 질문을 하지 마세요. 우리가 보고서를 받았다는 것을 확인하면 충분합니다. 그 후에는 여전히 많은 작업이 필요하며, pull request를 준비하는 데 수일이 걸릴 수 있습니다.

중요: Capgo은 작은 회사이기 때문에 보너스 금액이 큰 회사 프로그램보다 낮습니다. 공격 경로가 명확하지 않은 보고서에 대해 최대 $30까지 지불합니다. Capgo에 실제로 영향을 미치는 reproducible 공격에 대해 최대 $300까지 지불합니다. 문제를 식별하고 수정한 후 pull request를 열었으며, 릴리스가 완료된 후에만 지불이 이루어집니다. 일반적으로 20-30일 정도 걸립니다. "지불을 위해"라는 메시지를 보내지 마세요. 지불은 릴리스가 완료되고, 수정이 작동하는지 테스트하고 검증한 후에만 이루어집니다.

보고 방법

  1. GitHub의 관련 저장소로 이동하세요.
  2. 보안 탭을 클릭하세요.
  3. 보안 취약점을 보고하기 위해 "보안 취약점 보고"를 클릭하세요.
  4. 취약점이 있는 파일 경로와 줄 번호를 정확하게 포함하세요.
  5. __CAPGO_KEEP_0__ 문제를 재현하는 상세한 단계를 제공하고 보안 영향에 대해 설명하십시오.

__CAPGO_KEEP_0__ 범위 밖

  • code 라인 참조가 정확하지 않은 GitHub에 대한 보고서
  • GitHub 보안 고지를 통해 제출되지 않은 보고서
  • __CAPGO_KEEP_0__에 대한 증명이 없는 이론적 취약점
  • Capgo가 직접 수정할 수 없는 외부 플랫폼, 의존성, 또는 서비스의 버그 (예를 들어 Supabase에 보고하십시오).
  • 사회 공학 또는 피싱 시도
  • 서비스 거부 공격
  • 웹훅 또는 웹사이트 미리보기에 대한 SSRF 또는 DNS 위조 보고. 이 기능은 서버리스 인프라에서 실행되므로 Capgo의 사설 인프라에 접근할 수 없으므로 우리 환경에서 공격할 수 없습니다.

Supabase 및 Third-Party Services

Capgo가 만든 또는 선택한 Capgo의 취약한 논리, SQL, RPC, RLS 정책, Edge Function, 또는 구성이 프로젝트에서 수정할 수 있다면, Supabase가 엔드포인트를 제공하더라도 범위 내입니다. Supabase의 동작에 대한 발견에 대해서는 reproducible한 케이스와 Supabase 설정 또는 config 변경을 프로젝트에 적용한 ours와 같은 프로젝트에 적용한 것을 포함하십시오.

예시

Not valid here

  • Supabase 플랫폼의 버그, 장애, 또는 __CAPGO_KEEP_0__만이 수정할 수 있는 동작
  • 재현할 수 없는 발견
  • Capgo가 Supabase 동작을 비난하는 주장이나 Capgo가 제어하는 수정 또는 정확한 Supabase 설정/구성 변경을 보여주지 않는 발견

유효합니다

  • Capgo가 제어하는 Supabase 미구성화가 프로젝트 설정(단계)에 의해 수정될 수 있습니다
  • Capgo가 소유한 SQL, RPC, RLS, 함수 또는 통합 문제로 인해 불안전한 Supabase 사용
  • Capgo의 Supabase 프로젝트, 스키마 또는 정책 내에서 재현 가능한 문제

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

일부 발견은 Capgo code에 의해 Capgo 보안 규칙 변경이 필요하지 않아 Supabase 측에서 구성 변경이 필요한 경우에만 Capgo 소유 SQL, RPC, RLS 정책, 함수 또는 앱 로직 변경이 필요합니다. 이러한 발견은 Supabase 데모 프로젝트와 같은 구성으로 재현할 수 있는 경우에만 검토합니다. Supabase 기본값 또는 플랫폼 동작으로 인해 발생하는 발견입니다.

  • 재현 가능한 사례를 제공하고 정확한 수정을 식별하십시오: Supabase 동작 문제를 해결하는 Supabase 설정/구성 변경 또는 Capgo가 소유한 code/구성 항목이 변경되어야 하는 경우
  • 이메일 확인 동작은 Supabase 인증 프로젝트 설정(예: 이메일 확인이 비활성화되어 캡처 기반 인증이 사용되는 경우)에 따라 예상됩니다.
  • 비밀번호 업데이트 및 계정 복구 흐름은 항상 이전 비밀번호 재입력 또는 재인증이 필요하지 않을 수 있습니다. Supabase Auth가 그렇게 구성되어 있으면.
  • 이 문제가 이 목록에 있지만 제공된 프로젝트 또는 Capgo 소유의 보안 결함에 대한 구체적인 Supabase 측 해결책을 제공할 수 있다면, 우리는 범위 내로 고려할 수 있습니다.

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