SECURITY.md

보안 정책

언어: English | 한국어 | Español | Français | हिन्दी | 简体中文

이 문서는 0disoft가 소유한 저장소에 기본으로 적용되는 보안 정책입니다. 각 저장소에 별도의 SECURITY.md가 있다면, 해당 저장소의 보안 정책이 우선 적용됩니다.

지원 대상 저장소

보안 제보는 현재 유지보수 중인 저장소를 대상으로 검토합니다.

보관 처리된 저장소, 실험용 저장소, 더 이상 권장되지 않는 저장소, 유지보수되지 않는 저장소에는 보안 수정이 제공되지 않을 수 있습니다.

저장소에 별도 안내가 없는 한, 보안 대응은 기본 브랜치와 최신 공개 릴리스를 기준으로 가능한 범위 안에서 처리합니다. 릴리스를 사용하지 않는 저장소라면 기본 브랜치를 기준으로 합니다.

기여 변경의 보안 검토 기준

인증, 권한 부여, 암호화, 비밀값 처리, 결제 처리, 개인정보 처리, 네트워크에 노출되는 동작을 새로 추가하거나 변경하는 작업은 메인테이너의 추가 검토가 필요합니다.

암호화 정책

암호화 동작을 새로 추가하거나, 변경하거나, 암호화 동작에 의존하는 변경을 할 때는 다음 기준을 따릅니다.

• 메인테이너의 명시적인 승인과 적절한 보안 검토 없이 직접 암호화 방식을 구현하거나 암호화 구성 요소를 직접 조합하지 마세요.
• 검증된 프로토콜, 활발히 유지보수되는 라이브러리, 표준화 절차를 거친 구현을 우선 사용합니다.
• 대칭키 암호와 해시 함수는 계속 사용할 수 있습니다. 현대적인 인증 암호화, 메시지 인증, 해시 구성 요소를 유지보수되는 라이브러리를 통해 사용해 주세요.
• 암호화 선택지는 가능한 한 설정 가능하고 교체 가능하게 설계해야 합니다. 프로토콜 협상이나 라이브러리 설정을 사용할 수 있다면 알고리즘을 코드에 고정하지 마세요.

공개키 암호와 양자내성암호

• 새로운 공개키 암호화, 키 설정, 전자서명 기능을 추가할 때는 운영 환경에서 사용할 수 있는 지원이 존재하는 경우 미국 국립표준기술연구소(NIST)가 표준화한 양자내성암호(PQC, Post-Quantum Cryptography)를 우선 검토합니다.
• 새로운 키 설정에는 ML-KEM을, 새로운 전자서명에는 프로토콜과 실행 환경에 맞는 경우 ML-DSA 또는 SLH-DSA를 우선 검토합니다.
• FN-DSA와 HQC를 포함해 NIST 표준 또는 표준화 절차에 있는 추가 알고리즘은 성숙도를 계속 확인합니다.
• 상호운용성을 위해 필요한 경우 기존 암호 방식과 양자내성암호를 함께 사용하는 하이브리드 구성을 허용합니다. 다만 인정된 프로토콜, 프로파일, 또는 공급자가 지원하는 표준을 따라야 합니다.
• 호환성을 위해 필요한 경우 기존 RSA, Diffie-Hellman, ECDH, ECDSA, EdDSA 사용은 유지할 수 있습니다. 다만 새로 추가하는 장기 보관 비밀값, 장기 신뢰 루트, 새로운 암호 프로토콜 설계는 가능한 한 양자내성 전환을 염두에 두어야 합니다.
• 표준이 아니거나, 실험적이거나, 연구용에 가까운 양자내성암호 방식은 메인테이너의 명시적인 승인과 보안 검토 없이 운영 코드에 사용하지 마세요.

목표는 기존 암호 방식을 즉시 모두 금지하는 것이 아닙니다. 불필요하게 양자컴퓨터에 취약한 공개키 의존성을 새로 늘리지 않고, 암호화 구성 요소를 나중에 교체할 수 있게 유지하는 것이 목표입니다.

비밀번호 저장 정책

프로젝트가 사용자 비밀번호를 저장한다면 다음 기준을 따릅니다.

• 비밀번호를 평문으로 저장하거나 복호화 가능한 방식으로 저장하지 않습니다.
• MD5, SHA-1, SHA-256, SHA-512 같은 빠른 일반 해시 함수를 비밀번호에 직접 사용하지 않습니다.
• 새 비밀번호 해싱에는 Argon2id를 우선 사용합니다.
• 비밀번호마다 고유하고 무작위로 생성된 솔트 값(salt)을 사용합니다. Argon2id 비밀번호 해싱에는 16바이트 솔트 값이 권장됩니다.
• 유지보수되는 라이브러리와 표준 비밀번호 해시 형식을 우선 사용합니다.
• Argon2id 설정값은 하드웨어 성능과 배포 환경에 맞게 조정할 수 있어야 하며, 시간이 지나면서 재검토해야 합니다.
• 저장소별 정책에서 더 엄격한 기준을 정하지 않는 한, 최소한 OWASP가 권장하는 Argon2id 최소 설정인 메모리 19 MiB, 반복 2회, 병렬도 1을 사용합니다.
• Argon2id를 사용할 수 없는 경우에는 가능한 한 scrypt를 사용합니다. 기존 시스템에서는 적절한 작업 계수와 이전 계획이 있을 때 bcrypt를 임시로 유지할 수 있습니다. FIPS-140 준수가 필요하다면 승인된 작업 계수로 PBKDF2-HMAC-SHA-256을 사용합니다.
• 빠른 해시, 솔트 값 없는 해시, 직접 만든 비밀번호 해싱 방식은 사용하지 않습니다.
• 나중에 해시를 업그레이드할 수 있도록 알고리즘, 설정값, 솔트 값, 해시 버전을 각 비밀번호 해시와 함께 저장합니다.

토큰, API 키, 비밀값 저장 정책

서버가 생성하는 토큰, API 키, 복구 코드와 같은 비밀값은 다음 기준을 따릅니다.

• 비밀값은 암호학적으로 안전한 난수 생성기로 생성합니다.
• 명확한 운영상 필요가 없다면 API 키, 접근 토큰, 갱신 토큰, 세션 토큰, 복구 코드를 원문으로 저장하지 않습니다.
• 원문 복구가 필요하지 않다면 비밀 키를 사용하는 해시(HMAC 등), 일반 해시, 또는 되돌릴 수 없는 검증자를 저장하는 방식을 우선 사용합니다.
• 비밀값은 저장소에 커밋하거나, 로그에 남기거나, 오류 메시지에 노출하거나, 테스트 데이터에 포함하지 않습니다.
• 운영 비밀값은 비밀값 관리자, 환경별 비밀값 저장소, 또는 플랫폼의 암호화된 비밀값 기능을 사용합니다.

의존성 및 공급망 보안

• 의존성은 합리적인 범위 안에서 최신 상태로 유지합니다.
• 보안에 영향을 줄 수 있는 의존성 변경은 릴리스 전에 검토해야 합니다.
• 암호화, 인증, 권한 부여, 직렬화, 템플릿 렌더링, 네트워크 데이터 파싱과 관련된 의존성은 메인테이너 검토 없이 추가하지 않습니다.

취약점 신고

보안 취약점은 공개 이슈, 풀 리퀘스트, 토론으로 신고하지 마세요.

저장소에서 GitHub 비공개 취약점 신고 기능을 제공한다면 해당 기능을 사용해 주세요.

비공개 취약점 신고 기능이 없다면, 악용 방법이나 세부 내용을 공개하지 마세요. 저장소 또는 메인테이너의 GitHub 프로필에 적힌 비공개 연락 수단을 사용해 주세요.

취약점을 신고할 때는 다음 내용을 포함해 주세요.

• 영향을 받는 저장소
• 영향을 받는 버전, 브랜치, 커밋이 알려져 있다면 해당 정보
• 문제에 대한 명확한 설명
• 문제를 재현하는 절차
• 예상되는 영향
• 가능한 완화 방법이 있다면 해당 내용

처리 방식

제보는 선의에 따라 검토합니다.

메인테이너는 추가 정보를 요청하거나, 수정 사항을 준비하거나, 공개 시점을 조율하거나, 제보된 문제가 보안 취약점에 해당하지 않는다고 판단할 수 있습니다.

수정 또는 완화 방법이 준비되기 전까지는 문제를 공개하지 말아 주세요. 다만 메인테이너가 합리적인 기간 동안 응답하지 않는 경우는 예외로 볼 수 있습니다.