버그 보너스 프로그램
Capgo는 보안과 투명성을 위해 최선을 다하고 있습니다. 모든 code는 오픈 소스이며, 우리는 보안 연구원들을 통해 코드베이스의 취약점을 식별하는 것을 환영합니다.
오픈 소스 Code
Capgo의 모든 저장소는 오픈 소스입니다. code를 검토, 감사, 기여할 수 있습니다.
GitHub 조직: github.com/Cap-go
유효한 보고서의 요구 사항
버그 보너스 프로그램에 참가하기 위해서는 다음의 모든 요구 사항을 충족해야 합니다.
- 파일 및 라인 번호를 정확하게 식별해야 합니다. (해당하는 GitHub 저장소)
- 보고서는 GitHub 보안 고지서를 통해 해당 저장소에 제출해야 합니다.
- 보안 취약점의 설명 및 잠재적 영향에 대한 명확한 설명이 포함되어야 합니다.
- 재현 가능한 단계를 제공해야 합니다.
Important: 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_2__
우리는 친절하고 유효한 보고서에 대해 지불하지만, 우리의 시간을 존중하지 않는 사람들과 협력할 수 없습니다. 통신을 조용히 유지하고 이 프로그램을 따르세요.
- 보안 보고서 및 침해에 대한 응답은 24-72 시간 이내에 이루어집니다.
- 우리에 대한 스팸을 피하세요. 하루에 세 이메일 이상을 보내면 스팸으로 간주되어 차단됩니다.
- 이 규칙을 무시하거나 스팸인 보고서에 대해 지불하지 않습니다.
- 이 버그 보너스 프로그램을 따르는 범위 내의 보고서만 수락합니다. 다른 보고서는 차단될 수 있습니다.
- 상태 업데이트에 대한 질문을 하지 마세요. 예를 들어 "확인했어?"와 같은 질문을 하지 마세요. 우리가 보고서를 받았다는 것을 확인하면 충분합니다. 그 후에는 여전히 많은 작업이 필요하고, pull request를 준비하는 데 수일이 걸릴 수 있습니다.
Important: Capgo는 작은 회사이기 때문에 보너스 금액이 큰 회사 프로그램보다 낮습니다. Capgo에 대한 명확한 취약점 경로가 없는 보고서는 최대 $30까지 지불됩니다. Capgo 플러그인에 대한 실제, 재현 가능한 영향을 가지는 취약점은 최대 $300까지 지불됩니다. Capgo에서 Capgo 플러그인에 대한 보안 보고서를 수락하고 검토합니다. 그러나 code 플러그인에 대한 지불 보너리는 @capgo/capacitor-업데이터에 한정됩니다. 다른 Capgo 플러그인은 우리의 지불 제품 제공과 관련이 없으므로 그에 대한 보고서는 검토되지만 지불되지 않습니다.
보안 보고하기
- GitHub에서 해당 레포지토리로 이동하세요
- 보안 탭을 클릭하세요
- 보안 고지서를 생성하기 위해 "보안 취약점 보고"를 클릭하세요
- 취약점이 존재하는 파일 경로와 줄 번호를 정확하게 포함하세요
- 취약점을 재현하는 상세한 단계와 보안 영향에 대해 설명하세요
__CAPGO_KEEP_7__
- Reports without exact code line references in GitHub
- Reports not submitted through GitHub Security Advisory
- __CAPGO_KEEP_10__
- Bugs in third-party platforms, dependencies, or services that Capgo cannot fix directly (report those upstream, for example to Supabase).
- 사회공학 또는 피싱 공격 시도
- 서비스 거부 공격 공격
- 웹훅 또는 웹사이트 미리보기 기능에 대한 SSRF 또는 DNS 위조 보고. 이 기능은 서버리스 인프라에서 작동하여 Capgo의 개인 인프라에 접근할 수 없으므로 우리 환경에서 공격할 수 없습니다.
- Capgo이 소유하지 않거나 배포하지 않는 사용자 소유의 애플리케이션 code 또는 프로젝트 구성, capacitor.config.ts, config.capacitor.ts, 애플리케이션 소스 code, 및 환경에 따라 설정된 설정.
- Capgo 번들 파일에 대한 접근 또는 번들 파일이 다운로드 될 수 있는 증거. 번들 파일은 공개 웹 자산이며 사용자는 이러한 사실을 알고 있으며 이러한 접근은 데이터 유출로 간주되지 않습니다.
Supabase 및 제 3 자 서비스
Capgo에 대한 보고가 아니라 Supabase 플랫폼 또는 서비스 버그인 경우 Supabase에 보고하십시오. 만약 Capgo이 만든 또는 선택한 취약한 논리, SQL, RPC, RLS 정책, Edge 함수 또는 구성이 프로젝트에서 수정할 수 있다면, Supabase가 엔드포인트를 제공하더라도 해당 취약점은 범위 내입니다. Supabase 동작에 대한 정보는 Supabase 설정 또는 구성 변경을 포함하여 재현 가능한 케이스를 포함하여 Supabase에 제출하십시오.
예시
이곳에서 유효하지 않습니다
- 만약 Supabase 플랫폼 버그, 장애 또는 Supabase만이 수정할 수 있는 동작이 있다면
- 재현할 수 없는 발견
- 만약 Capgo이 Supabase 동작을 비난한다면 Capgo가 제어하는 수정 또는 정확한 Supabase 설정/구성 변경을 보여주지 않는다면
유효합니다.
- 우리의 프로젝트 설정(단계)에 따라 Capgo가 제어하는 Supabase 미사용 오류를 수정할 수 있습니다.
- 우리의 프로젝트 설정(단계)에 따라 Capgo가 소유한 SQL, RPC, RLS, 함수 또는 통합 문제로 인해 안전하지 않은 Supabase 사용을 수정할 수 있습니다.
- Capgo의 Supabase 프로젝트, 스키마 또는 정책에서 발생하는 재현 가능한 문제, 심지어 그것이 Supabase 엔드포인트를 통해 노출되는 경우에도.
알려진 Supabase 인증 제한 사항(이미 보고됨).
일부 발견물은 반복적으로 보고되고 Supabase 인증 기본값 또는 플랫폼 동작으로 인해 Capgo code에 의해 발생하지 않습니다. 우리는 이러한 문제를만들 때 Supabase demo 프로젝트를 공유하고 ours와 같은 구성으로 구성할 수 있고, Supabase 측에서 구성 변경이 Capgo 보안 규칙 변경이 필요하지 않으면만 검토합니다. Supabase 측에서 구성 변경이 Capgo 소유 SQL, RPC, RLS 정책, 함수 또는 앱 로직 변경이 필요하면, 그것은 우리에게 보고하세요. 왜냐하면 그것이 범위 내에 있기 때문입니다.
- 재현 가능한 사례를 제공하고 정확한 수정을 식별하세요: Supabase 설정/구성 변경이 Supabase 동작 문제를 해결하거나 Capgo가 소유한 code/구성 항목이 변경되어야 하는 경우.
- 이메일 확인 동작은 Supabase 인증 프로젝트 설정(예를 들어 이메일 확인이 비활성화되고 캡처 기반 인증이 사용되는 경우)에 따라 예상됩니다.
- 패스워드 업데이트 및 계정 복구 흐름은 항상 이전 패스워드 재입력 또는 재인증이 필요하지 않을 수 있습니다. 왜냐하면 Supabase 인증이 그러한 방식으로 구성된 경우에요.
- 이 문제가 이 목록에 있지만 제공된 프로젝트 또는 Capgo 소유의 보안 결함에 대한 구체적인 Supabase 측의 수정을 보여줄 수 있다면, 우리는 범위 내로 고려할 수 있습니다.
Capgo Bug Bounty 프로그램에 대한 질문에 대해, GitHub 보안 고지서를 통해 연락해 주세요.