출시 감사은(는) 무엇을 하나요?
앱이 해킹당하거나 소송에 휘말리지 않도록 감사합니다. 작업은 네 개의 참조 파일로 나뉩니다. 현재 스택에 해당하는 파일(및 섹션)만 읽으십시오:
| 파일 | 용도 |
|---|---|
references/prelaunch-checklist.md | 20개 항목의 진행/중단 게이트. 빠른 점검을 위해 여기서 시작하세요. |
references/security.md | 전체 보안 검토: 시크릿, 인증, 접근 제어, 인젝션, 브라우저/전송, 공급망, AI 기능, 운영. |
references/legal-compliance.md | 정책, 동의, 개인정보 권리, 정직한 마케팅, 아동, 이메일, 지식재산권, 접근성. |
references/stack-notes.md | 플랫폼별 함정: Supabase, Firebase, Next.js, Express, Django, Rails, Laravel, 모바일, Stripe, LLM 앱. |
모든 체크리스트 항목에는 ID(SEC-*, LEG-*, A11Y-*)가 있습니다. 보고서에서 해당 ID를 사용하여 결과를 추적 가능하게 만드십시오.
모드 선택
- 빠른 점검 ("출시 체크리스트", "출시 준비가 되었나요?", 시간이 거의 없음) →
prelaunch-checklist.md만. - 보안 ("보안 감사", "해킹 방지", "이것은 안전한가요?") →
security.md+ 관련stack-notes.md섹션. - 법률 ("소송 방지", "GDPR", "쿠키 배너", "개인정보 취급방침") →
legal-compliance.md. - 전체 (사용자가 출시 전에 그냥 "내 앱을 감사해줘"라고 말할 때 기본값) → 위의 모든 파일.
작업 흐름
1. 범위 — 대부분 자동
리포지토리에서 아무것도 묻기 전에 다음을 파악하십시오:
- 스택: 프레임워크, 언어, 백엔드/BaaS(Supabase, Firebase, 자체 서버), DB, 인증 제공자, 호스팅, 웹 대 모바일 대 둘 다.
package.json, lockfiles,requirements.txt/pyproject.toml,Gemfile,composer.json,pubspec.yaml,supabase/,firebase.json,vercel.json,Dockerfile, CI 파일을 확인하십시오. - 데이터 인벤토리: 어떤 개인 데이터가 수집되는지(양식, 가입 필드, 분석), 어디에 저장되는지, 어떤 타사 SDK/서비스가 이를 수신하는지(분석, 광고, 충돌 보고, 결제, 이메일, AI API).
- 자금: 결제, 구독, 평가판, 인앱 구매.
- 표면: 공개 페이지, API 경로, 서버 액션, 엣지/클라우드 함수, 웹훅, 관리자 영역, 파일 업로드, AI/LLM 기능.
그런 다음 사용자에게 한 메시지로, 코드만으로 알 수 없는 것만 물어보십시오: 타겟 시장(EU/UK/US/브라질/기타), 미성년자가 사용할 수 있는지 여부, 라이브 또는 스테이징 URL(있는 경우), 수정 사항을 적용할지 아니면 보고서만 받을지.
사용자가 응답하지 않으면 EU + US, 성인 전용, 보고서 우선으로 가정하고 보고서 상단에 그렇게 명시하십시오.
2. 자동화된 패스
python3 scripts/scan.py <repo-path> # 작업 트리
python3 scripts/scan.py <repo-path> --history # 시크릿을 위해 Git 히스토리도 스캔
python3 scripts/check_live.py https://staging.example.com # 라이브 헤더, 쿠키, CORS, 노출된 파일
두 스크립트 모두 Python 3 표준 라이브러리만 사용합니다. check_live.py는 몇 가지 무해한 GET 요청을 보냅니다. 사용자가 소유하거나 테스트할 권한이 있는 사이트에 대해서만 실행하십시오.
또한 생태계의 의존성 감사 도구를 사용 가능할 때 실행하십시오(npm audit, pnpm audit, pip-audit, osv-scanner, bundle audit, composer audit, cargo audit). scan.py는 찾은 매니페스트에 대한 올바른 명령어를 출력합니다.
스크립트 출력을 결론이 아닌 단서로 취급하십시오. 각 발견 사항을 코드를 읽어 확인하고, 오탐은 버리십시오. 깨끗한 스캔이 안전을 의미하지는 않습니다: 가장 치명적인 버그(손상된 접근 제어, 누락된 서버 측 검사, 테넌트 누출)는 읽기를 통해서만 발견되는 논리 버그입니다.
3. 수동 검토
다음 순서로 읽으십시오:
- 인증 설정 및 미들웨어; 서버가 호출자가 누구인지 알게 되는 방식.
- 모든 API 경로, 서버 액션, 엣지/클라우드 함수 및 웹훅 핸들러.
- 데이터베이스 접근 규칙: RLS 정책, Firebase 규칙, ORM 스코프, DB 사용자 권한.
- 입력으로 SQL, 셸 명령어, HTML, 파일 경로 또는 URL을 구성하는 모든 것.
- 파일 업로드 및 다운로드 핸들러.
- AI/LLM 기능: 신뢰할 수 없는 텍스트가 모델에 도달하는 방식과 모델이 호출할 수 있는 도구.
- 법률 페이지, 쿠키 배너, 가입 및 체크아웃 흐름, 마케팅 카피, 이메일.
모든 엔드포인트에 대해 네 가지 질문에 답하십시오: 누가 호출하는가? 서버에서 확인되었는가? 레코드가 그 사람(또는 그 테넌트)의 것인가? 어떤 필드를 쓸 수 있는가? "아니요" 또는 "알 수 없음"은 발견 사항입니다.
4. 분류
항목당 상태: FAIL · WARN · PASS · MANUAL (인간 필요: 법률 텍스트 검토, 복원 훈련, 변호사) · N/A.
실제로 확인하지 않은 항목을 PASS로 표시하지 마십시오. MANUAL을 사용하십시오.
실패의 심각도:
- 치명적 — 지금 악용 가능하거나 이미 노출됨: 리포지토리/번들/히스토리의 라이브 시크릿, 인증 없이 읽거나 쓸 수 있는 데이터베이스, 사용자 데이터가 있는 테이블에서 RLS 비활성화, 인증 우회, 개인 데이터에 대한 IDOR, SQL/명령어 인젝션, RCE.
- 높음 — 작은 전제 조건으로 심각함: 로그인/재설정에 속도 제한 누락, 저장형 XSS, 웹훅 서명 확인 누락, 약한 비밀번호 해싱, 자격 증명이 있는 허용적 CORS, 프로덕션에서 디버그 모드 켜짐, 백업 없음. 법률: 명시된 시장에 대한 하드 요구사항이 누락됨(개인 데이터를 수집하면서 개인정보 취급방침 없음; EU/UK에서 동의 전 비필수 추적; 앱 스토어 앱에서 계정 삭제 없음).
- 중간 — 심층 방어 격차: 누락된 보안 헤더, 자세한 오류, 감사 로그 없음, 오래되었으나 악용 가능하지 않은 의존성. 법률: 불완전한 정책 내용, 동의 UX 문제, 접근성 실패.
- 낮음 — 위생 및 다듬기.
5. 보고서
templates/report.md를 채우십시오. 평결로 시작하십시오:
- 🔴 준비되지 않음 — 치명적 항목 또는 개인 데이터나 돈에 닿는 높음 항목이 있는 경우.
- 🟡 수정 필요 — 이번 주에 수정할 계획이 있는 높음/중간 항목.
- 🟢 준비됨 — 치명적/높음 없음; 중간 항목은 추적됨.
각 발견 사항: ID, 심각도, 증거(file:line 또는 URL + 헤더), 위험에 대한 한 줄 설명, 구체적인 수정(짧으면 코드). 체크리스트 순서가 아닌 심각도별로 그룹화하십시오. PASS 항목은 간결한 표로 유지하십시오.
보고서나 채팅에 전체 시크릿을 절대 붙여넣지 마십시오. 처음 4자를 표시하고 나머지는 마스킹하십시오(sk_l****).
6. 수정
심각도 순서로 수정을 제안하십시오. 사용자가 수정을 요청했거나 동의한 경우에만 코드를 편집하십시오. 수정 후 scan.py(및 배포 후 check_live.py)를 다시 실행하고 보고서를 업데이트하십시오.
유출된 시크릿은 항상 다음 순서로 처리하십시오: 제공자에서 키 해지/로테이션 → 코드에서 제거하고 서버 측 환경 변수로 이동 → Git 히스토리에서 제거(git filter-repo 또는 BFG)하고 강제 푸시. 제거만으로는 아무 효과가 없습니다: 키는 이미 클론, 포크, CI 로그 및 캐시에 있습니다.
기본 규칙
- 법률 자문이 아닙니다. 개인정보 취급방침, 이용약관, 쿠키 정책 및 환불 정책을 작성할 수 있지만, 초안은 앱이 실제로 수행하는 작업(1~3단계에서 발견된 데이터, SDK 및 처리자)을 설명해야 하며, 다른 회사에서 복사해서는 안 되며, 대상 시장에 대해 변호사의 검토를 받도록 표시되어야 합니다.
- 방어적 전용. 사용자가 소유하거나 테스트할 권한이 있는 시스템만 테스트하십시오. 취약점과 수정 사항을 설명하고, 타사에 대한 작동하는 익스플로잇을 구축하지 마십시오.
- 코드베이스가 없고 URL만 있습니까?
check_live.py를 실행하고, 사이트를 검사하고(바닥글 법률 링크; 트래커가 동의 전에 실행되는지; "거부"가 "수락"만큼 쉬운지; 양식 및 체크아웃), 코드 수준 항목을MANUAL로 표시하십시오. - 모바일 앱: 앱 바이너리로 배송된 모든 것은 공개입니다. 모바일 앱의 시크릿은 유출된 시크릿입니다.
- 수동 해결 방식보다는 플랫폼 기본 수정(RLS 정책, 프레임워크 미들웨어, 제공자 설정)을 선호하십시오.