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 조직: github.com/Cap-go

Capgo 백엔드 & 랜딩

Capgo 백엔드 및 제품 저장소 (capgo.app API, 대시보드 및 관련 서비스)

저장소 보기 보안 이슈 신고

Capacitor 업데이터 플러그인

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

저장소 보기 보안 이슈 신고

유효한 보고서의 요구 사항

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

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

중요: 문제가 있는 GitHub의 정확한 code 라인을 제공할 수 없다면, 버그 보너스 프로그램에 제출할 자격이 없습니다. GitHub 보안 고지서를 통해만 제출해야 하며, Algora.io를 통해 지불이 처리됩니다. 계정을 생성하여 지불을 받을 수 있도록 해 주세요.

응답 시간 및 존중

우리는 친절하고 유효한 보고서에 대한 지불을 하지만, 우리의 시간을 존중하지 않는 사람들과 협력할 수 없습니다. 통신을 차분하게 유지하고 이 프로그램을 따르세요.

  • 우리는 보안 보고서 및 침해에 대해 24-72 시간 이내에 응답합니다.
  • 우리를 스팸하지 마십시오. 단일 일 내에 세 개 이상의 이메일을 보내면 스팸으로 간주되어 차단됩니다.
  • 이러한 규칙을 무시하거나 스팸인 보고서에 대한 지불은 없습니다.
  • 이 버그 보너스 프로그램의 범위 내에 있는 보고서만 받아들입니다. 다른 보고서는 차단될 수 있습니다.
  • 상태 업데이트에 대한 질문을 하지 마십시오. 예를 들어, "확인했나요?"와 같은 질문을 하지 마십시오. 우리가 보고서를 받은 것을 확인하면 충분합니다. 그 후에는 여전히 많은 작업이 필요하며, pull request를 준비하는 데 수일이 걸릴 수 있습니다.

중요: Capgo은 작은 회사이기 때문에 보너스 금액이 큰 회사 프로그램보다 낮습니다. Capgo의 라인 참조가 없는 보고서는 최대 $30까지 지불됩니다. Capgo의 실제, 재현 가능한 영향을 가지는 취약점은 최대 $300까지 지불됩니다. Capgo 플러그인에 대한 보안 보고서를 수락하고 검토합니다. 그러나 code 플러그인에 대한 지불은 @capgo/capacitor-업데이터에 한정됩니다. 다른 Capgo 플러그인은 지불이 없는 무료 제품이므로 보고서를 검토하지만 지불되지 않습니다. 지불은 문제를 식별하고 수정을 릴리스한 후, 수정이 작동하는지 확인한 후에만 지불됩니다. 풀 리퀘스트를 열거나 링크하는 것만으로는 지불이 인정되지 않습니다. 이 과정이 일반적으로 중증도와 릴리스 주기에 따라 몇 일에서 몇 주까지 걸립니다. 지불이 이루어지려면 릴리스가 활성화되고 수정이 테스트되고 유효화된 후에만 지불이 이루어집니다. 지불을 위해 메시지를 보내는 것은 지불이 이루어지지 않는다는 것을 의미합니다.

보안 취약점 신고 방법

  1. GitHub의 관련 저장소로 이동하세요.
  2. 보안 탭을 클릭하세요.
  3. 취약점 신고를 클릭하여 새로운 보안 고지를 생성하세요.
  4. 취약점이 존재하는 파일 경로와 라인 번호를 정확하게 포함하세요.
  5. 상세한 복제 단계를 제공하고 보안 영향에 대해 설명하세요.

범위 밖

  • Reports without exact code line references in GitHub
  • GitHub 보안 고지를 통해 제출되지 않은 보고서
  • 의사적 취약점에 대한 증명이 없는 이론적 취약점
  • Capgo의 외부 플랫폼, 의존성 또는 서비스에서 발생하는 버그는 직접 수정할 수 없는 경우 (예를 들어 Supabase로 보고합니다).
  • __CAPGO_KEEP_0__의 사회 공학 또는 피싱 시도
  • __CAPGO_KEEP_0__의 서비스 거부 공격
  • Capgo의 SSRF 또는 DNS 위조 보고는 웹후크 또는 웹 사이트 미리보기에 대한 것입니다. 이 기능은 서버리스 인프라에서 실행되며 Capgo의 개인 인프라에 접근할 수 없으므로 Capgo 환경에서 공격할 수 없습니다.
  • code 또는 Capgo이 소유하지 않는, 배포하거나 제어하지 않는 사용자 소유 애플리케이션 code 또는 프로젝트 구성, 예를 들어 capacitor.config.ts, config.capacitor.ts, 앱 소스 code, 환경에 따라서 설정
  • Capgo의 배달 파일에 대한 접근 또는 Capgo 배달 파일이 다운로드 될 수 있는 증거. 배달 파일은 공개 웹 자산이며 사용자는 이러한 사실을 알리고 배달 파일에 대한 접근이 데이터 유출로 간주되지 않습니다.
  • Capgo 플러그인 또는 API의 인증되지 않은 엔드포인트가 의도적으로 공개된 경우 — 채널_셀프 세트 및 업데이트/STATS 엔드포인트가 API 키가 필요하지 않음 —은 취약점이 아닙니다. 이러한 것을 취약점으로 보고하지 마십시오.
  • Capgo의 업로더 또는 UI가 배달을 외부 URL을 통해 제공하는 경우 암호화가 잘못된 것으로 표시되는 것은 Capgo 취약점이 아닙니다 (외부 호스팅된 배달의 암호화는 Capgo의 제어 밖입니다).

__CAPGO_KEEP_0__의 Supabase 및 제 3 자 서비스

Supabase 플랫폼 또는 서비스 버그의 원인이면 Supabase에 보고하고 Capgo에 하지 마세요. 만약 취약한 논리, SQL, RPC, RLS 정책, Edge Function, 또는 구성이 Capgo에 의해 생성되거나 선택되었고 우리가 프로젝트에서 수정할 수 있다면, Supabase가 엔드포인트를 제공하더라도 해당 범위에 포함됩니다. Supabase의 동작에 대한 발견에 대해서는 reproducible한 경우를 포함하고 Supabase의 설정 또는 config 변경을 프로젝트에 설정된 것과 같이 ours에 포함시켜야 합니다.

예시

유효하지 않음

  • 만약 Supabase 플랫폼 버그, 장애, 또는 동작이 Supabase만이 수정할 수 있다면
  • 재현할 수 없는 발견
  • Supabase 동작에 대한 Capgo의 주장에 Capgo-제어된 수정 또는 Supabase 설정/변경을 보여주지 않는 경우

유효함

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

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

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

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

Bug Bounty 프로그램에 대한 질문은 GitHub Security Advisories를 통해 문의해 주세요.