목적
CaseBender는 보안 팀이 사용하는 제품이므로, 제품 보안을 일회성 체크리스트가 아닌 릴리스 요구 사항으로 취급합니다. 보안 보증 프로그램은 보호된 개발 워크플로, 자동화된 보안 테스트, 컨테이너 및 종속성 통제, 릴리스 출처 증명, 문서화된 예외, 독립 평가 계획을 결합합니다. 이 섹션에서는 다음 내용을 설명합니다.- 자동으로 실행되는 통제
- 변경 또는 릴리스를 차단하는 발견 사항
- 각 통제가 생성하는 증거
- 예외 관리 방식
- 고객이 독립적으로 검증할 수 있는 항목
- 자동화된 보증의 한계
보증 개요
보호된 변경 사항 (영문)
보호된 브랜치에 대한 풀 리퀘스트는 병합 전에 통합 Security Gate를 통과해야 합니다.
다계층 테스트
독립된 도구를 사용하여 시크릿, 소스 코드, 종속성, 라이선스, 인프라 및 모든 서비스 이미지를 검사합니다.
릴리스 무결성 (영문)
릴리스 워크플로는 SBOM, 출처 증명, 불변 다이제스트 및 암호화 서명을 생성합니다.
고객용 증거
고객은 커밋, 이미지 다이제스트 또는 릴리스와 연결된 증거를 식별할 수 있습니다.
안전한 변경 수명 주기
제안된 모든 변경 사항은 다음과 같은 상위 수준의 수명 주기를 따릅니다.통제 실행 시점
정확한 트리거와 도구 구성의 최종 기술 기준은 이 페이지가 아니라 워크플로 정의입니다. 저장소 접근 권한이 있는 승인된 검토자는 Security Scan workflow를 확인할 수 있습니다. 접근 권한이 없는 고객은 보안 증거 가이드에 설명된 릴리스별 증거를 이용해야 합니다.
병합을 차단하는 Security Gate
통합 Security Gate는 풀 리퀘스트와 푸시에서 다음 작업이 성공하도록 요구합니다.
GitHub Code Security 라이선스가 없는 경우 스캐너 결과 업로드는 최선 노력 방식으로 처리될 수 있지만, 기반이 되는 로컬 스캔은 계속 차단 통제로 작동합니다. 게이트가 SARIF 수집에 의존하지 않도록 보고서도 워크플로 아티팩트로 보존됩니다.
동적 보안 테스트
주간 DAST 작업은 전용 스테이징 배포를 대상으로 OWASP ZAP을 사용합니다. 능동 테스트를 시작하기 전에 CI는 다음 사항을 검증합니다.- 대상이 자리표시자, localhost 또는 루프백 주소가 아닌지
- 응답이 CaseBender 웹 배포임을 식별하는지
- 구성된 테스트 ID가 인증된 세션을 생성하는지
- 인증 헤더가 마스킹된 저장소 시크릿을 통해 제공되는지
컨테이너 보증
CaseBender는 현재 7개의 서비스 이미지를 생성합니다. 각 프로덕션 Dockerfile은 다단계 빌드와 비루트 런타임 사용자를 사용합니다. 컨테이너 보증 절차에는 다음이 포함됩니다.- Dockerfile 린팅
- 프로덕션 종속성 가지치기
- 게시 전 취약점 스캔
- 이미지 스캔을 통한 내장 시크릿 감지
- 게시 후 불변 다이제스트 선택
- GitHub OIDC ID를 통한 키리스 Cosign 서명
- 게시된 정확한 다이제스트에 대한 서명 검증
latest와 같은 변경 가능한 태그에만 의존하지 않고, 고객이 가져오는 다이제스트에 서명합니다.
소프트웨어 공급망 증거
릴리스 워크플로는 상호 보완적인 여러 기록을 생성합니다.- CycloneDX SBOM — 종속성 분석을 위한 패키지 및 구성 요소 인벤토리
- BuildKit SBOM and provenance — 컨테이너 빌드와 함께 생성되는 빌드 메타데이터
- Cosign signature — 불변 이미지 다이제스트에 결합된 암호화 ID
- SBOM attestation — 이미지와 구성 요소 인벤토리 간의 서명된 연결
- SLSA-format provenance document — 소스 리비전, 워크플로 ID 및 호출 메타데이터
- Scanner reports — 해당 워크플로가 보존하는 SARIF 또는 JSON 출력
subject가 비어 있으므로 7개 이미지 다이제스트에 암호화 방식으로 결합되지 않으며, 아티팩트 수준 출처 증명 또는 독립적인 SLSA 인증으로 표현해서는 안 됩니다.
취약점 처리
발견 사항은 심각도, 악용 가능성, 영향을 받는 배포 모드, 노출 정도 및 패치 가용성에 따라 분류됩니다. 프로젝트에 문서화된 기본 해결 목표는 다음과 같습니다.
고객 계약에 포함되지 않는 한 이는 내부 해결 목표이며 계약상 서비스 수준이 아닙니다.
즉시 해결할 수 없는 경우 예외는 범위가 좁고 검토 가능해야 합니다. 현재 Trivy IaC 예외는
.trivyignore.yaml에 저장되며 발견 사항, 영향을 받는 경로, 근거 및 만료일을 포함합니다. 라이선스 예외는 패키지별로 적용되며, 정책은 라이선스 식별자를 전역적으로 제외하지 않습니다. 이 저장소 파일을 수용된 모든 제품 위험 범주를 포괄하는 완전한 등록부로 해석해서는 안 됩니다.
도구 및 워크플로 무결성
통제 자체도 다음과 같이 보호됩니다.- 타사 GitHub Actions는 불변 커밋 SHA에 고정
- 중요 스캐너 바이너리와 컨테이너 이미지는 버전 또는 다이제스트에 고정
- 잠금 파일 기반 설치에
--frozen-lockfile사용 - 보안 네거티브 통제를 통해 스캐너가 알려진 불량 입력을 예기치 않게 더 이상 거부하지 않는 상황 감지
- 현재 GitHub 브랜치 보호 설정은 필수 상태 검사를 생성하지 않은 직접 업데이트를 거부하며, 이 정책은 소스 저장소 외부에서 관리
- 필수 보안 작업이 실패하거나 취소되거나 예기치 않게 건너뛰어진 경우 통합 작업 실패
보조 악성 코드 휴리스틱
별도의 병합 후 워크플로가main에서 Next.js 및 PostCSS 구성 파일의 변경 사항을 모니터링하여 알려진 악성 npm 공급망 패턴을 탐지하고 자동 되돌리기를 생성할 수 있습니다. 이는 범위가 제한된 패턴 기반 복구 통제입니다. 풀 리퀘스트 게이트, 안티바이러스 엔진, EDR 통제 또는 종합적인 악성 코드 스캔이 아닙니다.
고객 책임
CaseBender는 고객 관리형 인프라에 배포할 수 있습니다. 제품 보증은 해당 환경의 안전한 운영을 대체하지 않습니다. 고객은 다음 사항에 대한 책임을 계속 부담합니다.- TLS 인증서, ingress, 방화벽 및 네트워크 세분화
- ID 공급자, MFA 및 역할 구성
- 데이터베이스, Redis, 객체 스토리지 및 검색 서비스 강화
- 시크릿 순환 및 배포 자격 증명에 대한 접근
- 백업, 모니터링, 보존 및 인시던트 대응
- 지원되는 업데이트 적용 및 릴리스 노트 검토
- 고객의 규제 및 위협 환경에 대한 통제 검증
현재 보증 범위와 한계
2026년 7월 기준:- 자동화된 SAST, SCA, 시크릿, 라이선스, IaC, 컨테이너, SBOM, 서명 및 출처 증명 워크플로가 구현되어 있습니다.
- 인증된 스테이징 DAST가 CI에 구성되어 있지만 유지 관리되는 스테이징 대상과 테스트 ID에 의존합니다.
- GitHub 호스팅 SARIF 및 Dependency Review 기능은 저장소 라이선스에 따라 달라지지만, 로컬 Trivy 및 패키지 감사 게이트는 계속 사용할 수 있습니다.
- 완료된 타사 침투 테스트 보고서나 해결 후 재테스트 확인서를 보유하고 있다고 주장하지 않습니다.
- 규정 준수 매핑은 통제 부합성을 설명할 뿐 독립 인증을 의미하지 않습니다.
관련 문서
- 코드 보안(영문) — 스캐너 구성, DAST, 라이선스 및 취약점 관리
- 공급망 보안(영문) — 종속성, 이미지, SBOM, 서명 및 출처 증명
- 보안 증거 가이드 — 증거 유형 및 해석 방법
- 보안 아키텍처(영문) — 애플리케이션 및 배포 보안 설계
- 독립 침투 테스트 범위(영문) — 예정된 수동 평가 적용 범위