버그 보상 프로그램
Capgo는 보안과 투명성을 위해 최선을 다하고 있습니다. 모든 code는 오픈 소스이며, 우리의 코드베이스에서 취약점을 식별하는 데 도움을 주는 보안 연구원들을 환영합니다.
Code는 오픈 소스입니다.
Every repository in the Capgo organization is open source. You can review, audit, and contribute to our code.
GitHub Organization: https://github.com/Cap-go
보안 보너스 프로그램에 참가하기 위한 요구 사항
보안 보너스 프로그램에 참가하기 위해서는 다음의 모든 요구 사항을 충족해야 합니다.
- 보안 취약점이 존재하는 GitHub 저장소의 정확한 파일 및 라인 번호를 식별해야 합니다.
- 보안 취약점이 존재하는 GitHub 저장소의 관련 저장소에서 GitHub 보안 고지서를 통해 보고서를 제출해야 합니다.
- 보안 취약점과 그 잠재적 영향에 대한 명확한 설명을 포함해야 합니다.
- 보안 취약점을 재현할 수 있는 단계를 제공해야 합니다.
중요: 보안 취약점이 존재하는 GitHub의 code 라인 번호를 정확하게 제공하지 못하는 경우 보안 보너스 프로그램에 참가할 수 없습니다. 보안 보너스 프로그램에 참가하기 위해서는 GitHub 보안 고지서만을 통해 보고서를 제출해야 합니다. Algora.io를 통해 지불이 처리되며, 지불을 받으려면 계정을 생성해야 합니다.
응답 시간 및 존중
우리는 친절하고 보안 취약점에 대한 보상을 지불합니다. 그러나 우리의 시간을 존중하지 않는 사람과 협력할 수 없습니다. 프로그램을 따라서 평온한 의사소통을 유지하고 주의하세요.
- 보안 보고 및 침해에 대한 응답 시간은 24-72시간입니다.
- Do not spam us. More than three emails in a single day is considered spam and will be blocked.
- We do not pay for reports that ignore these rules or are spam.
- Only in-scope reports that follow this bug bounty program are accepted; anything else may be blocked.
- Do not ask for status updates such as "have you checked?" or similar questions. Once we confirm we received your report, that is enough. After that, there is still significant work to do, and preparing a pull request can take several days.
Important: Payments are issued only after we have identified the issue, fixed it, opened a pull request, and you have verified after release that the fix works for you. This process usually takes between 20 and 30 days. Please do not send messages like "to get paid"; payment happens only once the release is live and you've tested and validated the fix.
How to Report
- GitHub의 관련 저장소로 이동하세요.
- 보안 탭을 클릭하세요.
- 보안 취약점을 신고하려면 "보안 취약점 신고"를 클릭하세요.
- 취약점이 있는 파일 경로와 라인 번호를 정확하게 포함하세요.
- 취약점을 재현하는 상세한 단계와 보안 영향에 대해 설명하세요.
범위 밖
- code의 정확한 라인 참조가 없는 GitHub의 보고서
- GitHub 보안 고지서를 통해 제출되지 않은 보고서
- 증명된 개념적 취약점
- 제3자 플랫폼, 의존성 또는 서비스의 Capgo가 직접 수정할 수 없는 버그
- 사회 공학 또는 유인물 공격
- 서비스 거부 공격
Supabase 및 제3자 서비스
Root 원인은 Supabase 플랫폼 또는 서비스 버그일 경우 Supabase에 보고하고 Capgo에 보고하지 마십시오. 만약 Capgo가 생성하거나 선택한 취약한 논리, SQL, RPC, RLS 정책, Edge Function 또는 구성이 있고 우리 프로젝트에서 수정할 수 있다면, Supabase가 엔드포인트를 제공하더라도 범위에 포함됩니다. Supabase의 동작에 대한 보고서는 프로젝트가 우리와 같은 설정으로 구성된 경우 재현 가능한 사례와 Supabase 설정 또는 구성 변경을 포함하여 Supabase가 수정할 수 있는 경우를 포함해야 합니다.
예시
유효하지 않음
- Supabase 플랫폼 버그, 중단 또는 동작이 __CAPGO_KEEP_0__가 수정할 수 있는 경우
- 재현할 수 없는 발견
- Capgo가 Supabase 동작을 비난하는 주장이나, Capgo가 제어하는 수정 또는 정확한 Supabase 설정/구성 변경을 보여주지 않는 경우
유효합니다
- Capgo가 제어하는 Supabase 설정 오류를 프로젝트 설정(단계)에 따라 수정할 수 있습니다.
- Capgo가 소유한 SQL, RPC, RLS, 함수 또는 통합 문제로 인해 불안정한 Supabase 사용이 발생하는 경우
- Capgo의 Supabase 프로젝트, 스키마 또는 정책 내에서 재현할 수 있는 문제, 심지어 그것이 Supabase 엔드포인트를 통해 노출되는 경우
알려진 Supabase 인증 제한 사항 (이미 보고됨)
일부 발견은 Supabase 인증 기본값 또는 플랫폼 동작으로 인해 Capgo code에 의한 것이 아니라 반복적으로 보고됩니다. 이러한 발견은 Supabase 데모 프로젝트가 우리와 같은 구성으로 구성되었을 때 재현할 수 있고, Supabase 측에서 설정/구성 변경이 필요하지 않고 Capgo 보안 규칙을 변경하지 않는 경우에만 검토합니다. 설정/구성 변경이 필요할 경우, Capgo 소유 SQL, RPC, RLS 정책, 함수 또는 앱 로직을 변경하는 경우, 그것은 우리에게 보고하십시오.
- 재현할 수 있는 사례를 제공하고, 정확한 수정을 식별하십시오: Supabase 동작 문제를 해결하는 Supabase 설정/구성 변경 또는 Capgo가 제어하는 code/구성 항목
- 이메일 확인 동작은 Supabase 인증 프로젝트 설정에 따라 예상됩니다(예를 들어, 이메일 확인이 비활성화되어 있고 캡처 기반 인증이 사용되는 경우)
- 비밀번호 업데이트 및 계정 복구 흐름은 항상 이전 비밀번호 재입력 또는 재인증이 필요하지 않을 수 있습니다. Supabase Auth가 그렇게 구성되어 있으면.
- 이 문제가 이 목록에 있지만 제공된 프로젝트 또는 Capgo 소유의 보안 결함에 대한 구체적인 Supabase 측 해결책을 제공할 수 있다면, 우리는 그 범위 내에서 고려할 수 있습니다.
우리 Bug Bounty 프로그램에 대한 질문에 대해, GitHub 보안 고지서를 통해 연락해 주세요.