버그 보너스 프로그램
Capgo은 보안과 투명성을 위해 최선을 다하고 있습니다. 모든 code은 오픈 소스이며, 우리는 보안 연구원들을 통해 코드베이스의 취약점을 식별하는 것을 환영합니다.
오픈 소스 Code
Capgo의 모든 저장소는 오픈 소스입니다. code을 검토, 감사, 기여할 수 있습니다.
GitHub 조직: github.com/Cap-go
유효한 신고의 요구 사항
버그 보너스 프로그램에 참가하기 위해서는 다음의 모든 요구 사항을 충족해야 합니다.
- GitHub 레포지토리에서 취약성의 정확한 파일과 라인 번호를 식별해야 합니다.
- 신고는 GitHub 보안 고지서를 통해 해당 레포지토리에 제출해야 합니다.
- 취약성의 명확한 설명과 잠재적 영향에 대한 설명을 포함해야 합니다.
- 문제를 재현할 수 있는 단계를 제공해야 합니다.
중요: 문제의 정확한 라인을 GitHub에서 code에서 찾을 수 없다면 버그 보너스 프로그램에 참가할 수 없습니다. 신고는 GitHub 보안 고지서를 통해만 제출해야 하며, 알고라.이오를 통해 지불이 처리됩니다. 따라서 플랫폼에서 직접 지불할 수 있도록 계정을 생성해 주세요.
응답 시간과 존중
우리는 친절하고 유효한 보고서에 대해 보상을 하지만, 우리의 시간을 존중하지 않는 사람들과 협력할 수 없습니다. 통신을 조용히 유지하고 이 프로그램을 따르세요.
- 우리는 보안 보고서와 침해에 대해 24-72 시간 내에 응답합니다.
- 우리에 대한 스팸을 하지 마세요. 하루에 세 이메일 이상 보낼 경우 스팸으로 간주되어 차단됩니다.
- 이 규칙을 무시하거나 스팸인 보고서에 대한 보상을 하지 않습니다.
- 이 버그 보너스 프로그램의 범위 내에 있는 보고서만 받아들입니다. 다른 보고서는 차단될 수 있습니다.
- 상태 업데이트를 요청하는 것과 같은 질문을 하지 마세요. 우리가 보고서를 받았다는 것을 확인하면 충분합니다. 그 후에는 여전히 많은 작업이 남아 있으며 pull request를 준비하는 데 수일이 걸릴 수 있습니다.
중요: Capgo는 작은 부트스트랩 회사이기 때문에 우리의 보너스 금액은 대기업 프로그램보다 낮습니다. Capgo의 보너스 금액은 $30까지 지급됩니다. Capgo의 실제, 재현 가능한 영향을 가진 취약점은 $300까지 지급됩니다. 우리는 Capgo 플러그인에 대한 보안 보고서를 수용하고 검토합니다. 그러나 code 플러그인의 보너스 지급은 @capgo/capacitor-업데이터에 제한됩니다. 다른 Capgo 플러그인은 우리의 지불 제품 제공과 관련이 없으므로 보고서를 검토하지만 지불되지 않습니다. 지불은 문제를 식별하고 수정을 릴리스한 후, 수정이 작동하는지 확인한 후에만 지불됩니다. pull request를 열거나 링크하는 것만으로는 지불이 승인되지 않습니다. 이 프로세스는 중증도와 릴리스 주기에 따라 몇 일에서 몇 주까지 걸릴 수 있습니다. 지불을 위해 메시지를 보내지 마십시오. 지불은 릴리스가 활성화되고 수정이 테스트되고 유효화된 후에만 발생합니다.
How to Report
- GitHub의 관련 저장소로 이동하세요.
- 보안 탭을 클릭하세요.
- 취약성 보고를 클릭하여 새로운 보안 고지를 생성하세요.
- 취약성이 있는 파일 경로와 라인 번호를 정확하게 포함하세요.
- 취약성의 상세한 복제 단계와 보안 영향에 대해 설명하세요.
범위 밖
- code의 정확한 라인 참조가 GitHub에 없는 보고서
- GitHub 보안 고지를 통해 제출되지 않은 보고서
- 이론적인 취약성에 대한 증명이 없는 보고서
- Capgo의 외부 플랫폼, 의존성 또는 서비스에서 직접 수정할 수 없는 버그 (예를 들어 Supabase로 보고).
- 사회 공학 또는 피싱 시도
- 서비스 거부 공격
- 웹 훅 또는 웹사이트 미리보기에 대한 SSRF 또는 DNS 위조 보고는 서버리스 인프라에서 실행되기 때문에 Capgo의 개인 인프라에 접근할 수 없으므로 Capgo 환경에서 공격할 수 없습니다.
- 사용자 소유의 code 또는 프로젝트 구성이 Capgo이 소유, 배포 또는 제어하지 않는 파일, 예를 들어 capacitor.config.ts, config.capacitor.ts, 앱 소스 code, 환경별 설정.
- Capgo 번들 파일에 대한 접근 또는 번들 파일이 다운로드 될 수 있는 증거. 번들 파일은 공개 웹 자산이므로 사용자는 이를 알리고 번들 파일에 대한 접근이 데이터 유출로 간주되지 않습니다.
- 인증되지 않은 Capgo 플러그인/ API 엔드포인트는 의도적으로 공개된 디자인으로, 채널_self set 및 update/stats 엔드포인트를 제외한 API 키가 필요하지 않은 엔드포인트는 취약점이 아닙니다. 이를 취약점으로 보고하지 마십시오.
- 외부 URL을 통해 제공되는 번들의 암호화에 대한 업로더 또는 UI의 잘못된 레이블은 Capgo 취약점이 아닙니다 (외부 호스트된 번들의 암호화는 Capgo의 제어 범위 밖입니다).
Supabase 및 제 3자 서비스
Supabase 플랫폼 또는 서비스 버그의 원인이면 Supabase에 보고하고 Capgo에 하지 마세요. Capgo가 만든 또는 선택한 취약한 논리, SQL, RPC, RLS 정책, Edge 함수 또는 구성이 프로젝트에서 수정할 수 있다면, Supabase가 엔드포인트를 제공하더라도 범위에 포함됩니다. Supabase의 동작에 대한 발견에 대해서는 reproducible한 경우와 Supabase 설정 또는 구성 변경을 프로젝트에 적용하여 방지할 수 있는 정확한 Supabase 설정 또는 구성 변경을 포함하세요.
예시
유효하지 않음
- Supabase 플랫폼 버그, 장애 또는 Supabase만이 수정할 수 있는 동작
- 재현할 수 없는 발견
- Supabase 동작을 Capgo에 책임지우며 Capgo가 통제하는 수정 또는 정확한 Supabase 설정/구성 변경을 제공하지 않는 주장
유효함
- Capgo가 통제하는 Supabase 미구성화가 프로젝트 설정에서 수정할 수 있는 단계를 포함하여 프로젝트 설정에서 수정할 수 있습니다.
- Capgo가 소유한 SQL, RPC, RLS, 함수 또는 통합 문제가 불안전한 Supabase 사용을 유발하는 경우
- Capgo의 Supabase 프로젝트, 스키마 또는 정책에 reproducible한 문제가 발생하는 경우, 심지어 Supabase 엔드포인트를 통해 노출되는 경우
알려진 Supabase 인증 제한 (이미 보고됨)
일부 발견은 반복적으로 보고되고 Supabase Auth 기본값 또는 플랫폼 동작으로 인해 Capgo code 보다는 Capgo가 아닌 경우에만 검토됩니다. 이러한 발견을 검토하기 위해서는 공유 Supabase 데모 프로젝트에서 Capgo 보안 규칙 변경이 필요하지 않는 Supabase 측 구성 변경이 필요합니다. Capgo 소유 SQL, RPC, RLS 정책, 함수 또는 앱 로직 변경이 필요한 경우에는 이를 우리에게 보고하세요.
- 재현 가능한 사례를 제공하고 정확한 수정을 식별하세요: Supabase 설정/구성 변경이 Supabase 동작 문제를 해결하거나 Capgo-소유 code/구성 항목이 변경되어야 하는 경우입니다.
- 이메일 확인 동작은 Supabase Auth 프로젝트 설정 (예: 이메일 확인이 비활성화되어 있고 캡처 기반 인증이 사용되는 경우) 에 따라 예상됩니다.
- 패스워드 업데이트 및 계정 복구 흐름은 Supabase Auth가 구성된 대로 항상 이전 패스워드 재입력 또는 재인증이 필요하지 않을 수 있습니다.
- 만약 이 문제가 목록에 있지만 제공된 프로젝트 또는 구체적인 Capgo 소유 보안 결함에 대한 구체적인 Supabase 측 수정을 보여줄 수 있다면, 우리는 이를 범위 내로 고려할 수 있습니다.
우리 Bug Bounty 프로그램에 대한 질문은 GitHub 보안 고지서를 통해 연락해 주세요.