버그 보너스 프로그램
Capgo는 보안과 투명성을 위해 최선을 다하고 있습니다. 모든 code는 오픈 소스이며, 우리는 보안 연구원들을 Capgo의 취약점을 식별하는 데 도움을 주기 위해 환영합니다.
오픈 소스 Code
Capgo 조직 내의 모든 저장소는 오픈 소스입니다. code을 검토, 감사, 기여할 수 있습니다.
GitHub 조직: github.com/Cap-go
Capacitor 업데이터 플러그인
Capacitor 플러그인이 모바일 장치에서 오버 더 에어 업데이트를 처리하는 핵심 플러그인입니다.
유효한 보고서의 요구 사항
버그 보너스 프로그램에 참가하기 위해서는 다음의 모든 요구 사항을 충족해야 합니다.
- GitHub 저장소의 정확한 파일 및 라인 번호를 식별해야 합니다.
- GitHub 보안 고지서를 관련 저장소에서 제출해야 합니다.
- __CAPGO_KEEP_0__의 취약점에 대한 명확한 설명과 잠재적 영향
- __CAPGO_KEEP_0__에서 문제를 재현할 수 있는 단계를 제공해야 합니다.
중요한 점: GitHub의 code 라인 번호를 정확하게 제공할 수 없다면 버그 보너스 프로그램에 참가할 수 없습니다. GitHub 보안 고지서만 제출해야 하며, Algora.io에서 계정을 생성하여 직접 지불할 수 있도록 해주세요.
응답 시간 및 존중
우리는 친절하고 유효한 보고서에 대한 보상을 제공하지만, 우리의 시간을 존중하지 않는 사람들과 협력할 수 없습니다. 통신을 조용히 유지하고 이 프로그램을 따르세요.
- 보안 보고 및 침해에 대한 응답은 24-72 시간 내에 이루어집니다.
- 우리에 대한 스팸을 피하세요. 단일 일 내에 3 개 이상의 이메일이 스팸으로 간주되어 차단됩니다.
- 이 규칙을 무시하거나 스팸인 보고서에 대한 보상을 제공하지 않습니다.
- 이 버그 보너스 프로그램을 따르는 범위 내의 보고서만 수락합니다. 다른 경우 차단될 수 있습니다.
- 상태 업데이트에 대한 질문을 하지 마십시오. 예를 들어 "체크했나요?"와 같은 질문을 하지 마십시오. 우리가 보고서를 받은 것을 확인하면 충분합니다. 그 후에는 여전히 많은 작업이 남아 있으며 pull request를 준비하는 데 수일이 걸릴 수 있습니다.
중요: Capgo은 작은 부트스트랩 회사이기 때문에 보너스 금액은 대기업 프로그램보다 낮습니다. 명확한 공격 경로가 없는 보고서는 최대 $30까지 지불됩니다. 실제로 reproducible 영향을 가지는 Capgo의 취약점은 최대 $300까지 지불됩니다. 지불은 문제를 식별하고 수정한 후 pull request를 열었으며, 릴리스가 완료된 후 취약점이 수정되었는지 확인한 후에만 이루어집니다. 이 과정이 일반적으로 20-30 일 정도 걸립니다. 릴리스가 완료된 후에만 지불이 이루어지므로 "지불을 위해"라는 메시지를 보내지 마십시오.
보고하기
- GitHub의 관련 저장소로 이동하세요.
- 보안 탭을 클릭하세요.
- 취약점을 보고하기 위해 새로운 보안 고지를 생성하세요.
- 취약점이 존재하는 정확한 파일 경로 및 라인 번호를 포함하세요.
- 해당 문제를 재현하는 상세한 단계를 제공하고 보안 영향에 대해 설명하십시오.
범위 밖
- code 라인 참조의 정확한 GitHub 에서 제출되지 않은 보고서
- GitHub 보안 고지서를 통해 제출되지 않은 보고서
- 증명된 개념 증명이 없는 이론적 취약성
- 직접 수정할 수 없는 Capgo 플랫폼, 의존성, 또는 서비스의 버그 (예를 들어 Supabase로 보고하십시오).
- 사회 공학 또는 피싱 시도
- 서비스 거부 공격
- 웹 훅 또는 웹사이트 미리보기에 대한 SSRF 또는 DNS 위조 보고. 이 기능은 서버리스 인프라에서 실행되므로 Capgo 사설 인프라에 접근할 수 없으므로 우리 환경에서 공격할 수 없습니다.
Supabase 및 Third-Party Services
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.
예시
Not valid here
- A Supabase platform bug, outage, or behavior that only Supabase can fix
- A finding that cannot be reproduced
- A claim that blames Capgo for Supabase behavior without showing a Capgo-controlled fix or the exact Supabase setting/config change
Valid here
- A Capgo-controlled Supabase misconfiguration that can be fixed in our project settings (with steps)
- A Capgo-owned SQL, RPC, RLS, function, or integration issue that causes insecure Supabase usage
- A reproducible issue in Capgo's Supabase project, schema, or policies, even if it is exposed through a Supabase endpoint
Already reported Supabase Auth Limitations
Some findings are repeatedly reported and are caused by Supabase Auth defaults or platform behavior rather than Capgo code. We review these only when they can be reproduced in a shared Supabase demo project configured like ours and when the fix is a Supabase-side configuration change that does not require changing Capgo security rules. If the fix requires changing Capgo-owned SQL, RPCs, RLS policies, functions, or app logic, report it to us because that is in scope.
- Provide a reproducible case and identify the exact fix: either the Supabase setting/config change that resolves a Supabase behavior issue, or the Capgo-owned code/config object that must change.
- Email verification behavior is expected to follow your Supabase Auth project settings (for example, whether email confirmation is disabled and capture-based auth is used).
- 비밀번호 업데이트 및 계정 복구 흐름은 항상 이전 비밀번호 재입력 또는 재인증이 필요하지 않을 수 있습니다. Supabase Auth가 그렇게 구성되어 있으면.
- 이 문제가 이 목록에 있지만 제공된 프로젝트 또는 Capgo 소유의 보안 결함에 대한 구체적인 Supabase 측 해결책을 제공할 수 있다면, 우리는 고려할 수 있습니다.
우리 Bug Bounty 프로그램에 대한 질문에 대해, GitHub 보안 고지서를 통해 연락해 주세요.