버그 보너스 프로그램

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

오픈 소스 Code

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

GitHub 조직 github.com/Cap-go

유효한 보고서의 요구 사항

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

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

처리 시간 및 존중

우리는 친절하고 유효한 보고서에 대한 보상을 제공하지만, 우리의 시간을 존중하지 않는 사람들과 협력할 수 없습니다. 따라서 이 프로그램을 따라서 조용히 의사소통을 하시길 바랍니다.

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

__CAPGO_KEEP_0__에 대한 보안 보고서 제출 방법

1. GitHub의 관련 저장소로 이동하세요
2. Click on the "Security" tab
3. 보안 탭을 클릭하세요
4. Click "Report a vulnerability" to create a new security advisory
5. 보안 취약점을 신고하여 새로운 보안 고지를 생성하세요

Include the exact file path and line number(s) where the vulnerability exists

• Reports without exact code line references in GitHub
• Reports not submitted through GitHub Security Advisory
• 이ssue를 재현하는 자세한 단계와 보안 영향에 대해 설명하세요
• Bugs in third-party platforms, dependencies, or services that Capgo cannot fix directly (report those upstream, for example to Supabase).
• 범위 밖
• Reports without exact __CAPGO_KEEP_0__ line references in __CAPGO_KEEP_1__
• __CAPGO_KEEP_1__에 있는 정확한 Capgo 라인 참조가 없는 보고서입니다. ','Reports not submitted through Capgo Security Advisory (보안 고지)','Theoretical vulnerabilities without proof of concept (이론적 취약점은 증명이 없는 경우) ','Bugs in third-party platforms, dependencies, or services that Capgo cannot fix directly (report those upstream, for example to Supabase). (Capgo가 직접 수정할 수 없는 외부 플랫폼, 의존성, 또는 서비스의 버그는 업스트림으로 보고하세요, 예를 들어 Supabase로) ','Social engineering or phishing attempts (사회 공학 또는 피싱 시도)','Denial of service attacks (서비스 거부 공격)','SSRF or DNS spoofing reports against webhooks or website preview. These features run on serverless infrastructure and cannot be used to reach private Capgo infrastructure, so they are not exploitable in our environment. (SSRF 또는 DNS 스푸핑 보고는 웹후크 또는 웹사이트 미리보기에 대한 것입니다. 이 기능은 서버리스 인프라에서 실행되며 Capgo의 개인 인프라에 접근할 수 없으므로 우리 환경에서 취약점이 없습니다.)
• 사용자 소유의 애플리케이션 code 또는 프로젝트 구성이 Capgo이 소유하지 않거나 배포하지 않거나 제어하지 않는 파일, 예를 들어 capacitor.config.ts, config.capacitor.ts, 앱 소스 code, 환경에 따라 달라지는 설정
• Capgo 번들 파일에 대한 접근 또는 번들 파일이 다운로드 될 수 있는 증거. 번들 파일은 공개 웹 자산으로, 사용자는 이를 알리고, 이를 접근하는 것은 데이터 유출로 간주되지 않습니다.

Supabase 및 제 3 자 서비스

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

예시

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

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

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

우리 Bug Bounty 프로그램에 대한 질문에 대해, GitHub 보안 고지서를 통해 연락해 주십시오.