> ## Documentation Index
> Fetch the complete documentation index at: https://docs.casebender.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 보안 증거 가이드

> CaseBender의 스캐너 보고서, SBOM, 서명, 출처 증명, 예외 및 평가 상태를 검토하는 고객을 위한 가이드입니다.

## 개요

보안 증거는 고객이 평가 중인 정확한 소프트웨어로 추적할 수 있을 때 가장 유용합니다. CaseBender는 Git 커밋으로 빌드를 식별하고 불변 다이제스트로 컨테이너 아티팩트를 식별합니다.

보증 검토를 시작할 때 다음 중 하나를 기준으로 삼으십시오.

* CaseBender 릴리스 버전
* 릴리스에 표시된 Git 커밋 SHA
* 배포된 각 컨테이너 이미지의 다이제스트
* 아티팩트를 생성한 워크플로 실행

`latest`와 같은 태그는 편리한 참조이지만 안정적인 증거 식별자는 아닙니다.

## 증거 카탈로그

| 증거                 | 입증하는 내용                            | 중요 제한 사항                                                |
| ------------------ | ---------------------------------- | ------------------------------------------------------- |
| Security Gate 결과   | 특정 리비전에 필요한 CI 보안 작업이 성공적으로 완료됨    | 구성된 자동화 통제만 포함                                          |
| Gitleaks 보고서/로그    | 스캔된 소스와 기록에 일치하는 시크릿 패턴이 남아 있지 않음  | 가능한 모든 자격 증명 형식을 식별할 수는 없음                              |
| Trivy 파일 시스템 SARIF | 스캔된 저장소 상태의 종속성 발견 사항              | 권고 데이터베이스와 패키지 탐지는 시간에 따라 변경됨                           |
| Trivy 컨테이너 SARIF   | 빌드된 서비스 이미지의 OS 및 애플리케이션 발견 사항     | 스캔된 다이제스트에만 적용                                          |
| Trivy IaC SARIF    | Docker 및 Kubernetes 구성의 발견 사항      | 모든 런타임 플랫폼 설정을 검증하지는 않음                                 |
| Semgrep SARIF      | 구성된 소스 및 오염 분석 규칙의 발견 사항           | 규칙 적용 범위는 수동 코드 검토와 동일하지 않음                             |
| 종속성 감사 JSON        | 패키지 레지스트리에 알려진 프로덕션 종속성 권고         | 운영 체제 패키지는 포함하지 않음                                      |
| 라이선스 JSON 및 정책 결과  | 탐지된 라이선스와 패키지별 정책 결정               | 법적 해석은 고객별로 달라짐                                         |
| CycloneDX SBOM     | 저장소 또는 이미지에서 탐지된 구성 요소             | SBOM은 인벤토리이며 취약점이 없다는 진술이 아님                            |
| Cosign 서명          | 워크플로 ID가 특정 이미지 다이제스트에 서명함         | 서명 검증은 애플리케이션 동작을 평가하지 않음                               |
| SBOM 증명            | 서명된 SBOM이 특정 이미지와 연결됨              | 증명의 정확성은 SBOM 생성의 정확성에 좌우됨                              |
| SLSA 형식 출처 증명 문서   | 소스 리비전 및 빌드 호출 메타데이터               | 현재 `subject`가 비어 있어 이미지 다이제스트에 결합되지 않으며 독립 인증을 받은 것이 아님 |
| OWASP ZAP 보고서      | ZAP이 접근한 인증된 스테이징 경로의 결과           | API 또는 비즈니스 로직 전체가 포함되었음을 입증하지 않음                       |
| 예외 기록              | 발견 사항의 범위를 의도적으로 한정하고 근거와 만료일을 지정함 | 근본적인 위험을 제거하지 않음                                        |

## 추적성 절차

### 1. 배포된 다이제스트 기록

레지스트리 또는 컨테이너 런타임을 사용하여 불변 다이제스트를 캡처합니다.

```bash theme={null}
docker image inspect IMAGE:TAG \
  --format='{{index .RepoDigests 0}}'
```

예상 출력은 다음과 유사합니다.

```text theme={null}
registry.example.com/casebender/web@sha256:...
```

### 2. 서명 검증

CaseBender 릴리스 워크플로는 GitHub Actions OIDC가 지원하는 키리스 Cosign 서명을 사용합니다.

```bash theme={null}
cosign verify \
  --certificate-identity-regexp='https://github.com/casebender/webapp/' \
  --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \
  IMAGE@sha256:DIGEST
```

검증은 태그만을 대상으로 하지 말고 다이제스트를 대상으로 수행해야 합니다. 레지스트리 채널과 인증서 ID는 아티팩트와 함께 제공된 릴리스 문서와 일치해야 합니다.

### 3. 출처 증명 메타데이터 검증

출처 증명 문서에서 다음을 검토하십시오.

* 저장소 및 소스 리비전
* 워크플로 ID 및 트리거
* 빌드 타임스탬프 및 실행 주체
* `subject` 필드 및 검토 중인 아티팩트를 식별하는지 여부
* 첨부된 서명 및 서명 인증서

<Warning>
  현재 독립형 CaseBender 출처 증명 문서의 `subject`는 비어 있습니다. 서명된 워크플로 메타데이터임은 검증할 수 있지만, 현재로서는 특정 컨테이너 다이제스트가 해당 호출을 통해 생성되었음을 입증할 수 없습니다. 아티팩트 수준 추적성에는 레지스트리 다이제스트, 이미지 서명 및 이미지 SBOM 증명을 사용하십시오.
</Warning>

내용을 신뢰하기 전에 서명된 blob을 검증하십시오.

```bash theme={null}
cosign verify-blob \
  --signature provenance.json.sig \
  --certificate provenance.json.cert \
  --certificate-identity-regexp='https://github.com/casebender/webapp/' \
  --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \
  provenance.json
```

### 4. SBOM 검토

SBOM을 사용하여 배포와 관련된 직접 및 전이 구성 요소를 식별하십시오. 고객은 CycloneDX JSON을 자체 취약점 관리 또는 소프트웨어 자산 도구로 가져올 수 있습니다.

SBOM은 검토 중인 동일한 커밋 또는 이미지 다이제스트와 일치해야 합니다. 저장소 수준 SBOM과 이미지 수준 SBOM은 서로 다른 질문에 답하므로 상호 교환 가능한 것으로 취급해서는 안 됩니다.

### 5. 보안 발견 사항 및 예외 검토

다음 사항을 확인하십시오.

* 스캔을 건너뛰지 않고 완료했는지
* 보고서가 대상 리비전 또는 다이제스트에 해당하는지
* 워크플로가 사용한 심각도 정책
* 수정되지 않은 발견 사항이 스캐너 구성에 의해 제외되었는지
* 예외가 정확한 발견 사항과 경로에 적용되는지
* 예외가 아직 검토 기간 내에 있는지

## 아티팩트 보존

현재 워크플로 보존 설정은 다음과 같습니다.

* 스캐너 및 감사 아티팩트: 일반적으로 30일
* 저장소 CycloneDX SBOM 아티팩트 및 서명 자료: 1,095일
* 레지스트리 서명 및 증명: 레지스트리 수명 주기 정책에 따라 해당 레지스트리 아티팩트와 함께 보존

고객 자체 환경의 보존은 해당 고객이 통제합니다. 더 긴 감사 보존 기간이 필요한 고객은 배포된 각 릴리스에 대해 받은 증거 패키지를 보관해야 합니다.

## 권장 고객 증거 패키지

릴리스 보증 검토를 위한 관련 패키지에는 다음이 포함될 수 있습니다.

1. 릴리스 식별자 및 커밋 SHA
2. 배포된 서비스 이미지의 불변 다이제스트
3. Security Gate 워크플로 결과
4. 해당 다이제스트의 컨테이너 스캔 결과
5. CycloneDX SBOM
6. 서명 검증 출력
7. 서명된 출처 증명 및 검증 출력
8. 적용 가능한 유효 예외 기록
9. 취약점 해결 요약
10. 현재 침투 테스트 상태 설명

가용성은 저장소 권한, 레지스트리 채널, 아티팩트 보존 기간 및 계약상 공개 조건에 따라 달라질 수 있습니다. 원시 보고서에는 저장소 경로, 종속성 세부 정보 또는 인프라 정보가 포함될 수 있으므로 안전한 전송이나 민감 정보 삭제가 필요할 수 있습니다.

## 성공 결과 해석

녹색 워크플로는 구성된 작업이 해당 리비전에 인코딩된 정책에 따라 완료되었음을 의미합니다. 다음을 의미하지는 않습니다.

* 취약점이 존재하지 않음
* 모든 애플리케이션 경로를 테스트함
* 배포된 모든 인프라가 스캔된 템플릿과 일치함
* 모든 종속성에 향후 권고가 발생하지 않음
* 제3자가 결과를 독립적으로 검증함
* 릴리스가 규정 준수 프레임워크에 따른 인증을 받음

더 높은 수준의 보증이 필요한 배포에서는 자동화된 증거를 아키텍처 검토, 고객 환경 강화, 위협 모델링 및 독립적인 수동 테스트와 결합하십시오.

## 침투 테스트 증거

CaseBender는 현재 완료된 타사 침투 테스트 보고서나 해결 후 재테스트 확인서를 보유하고 있다고 주장하지 않습니다. 자동화된 ZAP 테스트와 제품 내 침투 테스트 관리 기능은 이러한 증거를 대체하지 않습니다.

예정된 평가 수행, 필요한 테스터 자격, 수행 규칙 및 예상 결과물은 [독립 침투 테스트 범위(영문)](/en/security/penetration-test-scope)에 문서화되어 있습니다.

## 보안 문제 신고

의심되는 CaseBender 취약점은 [security@casebender.com](mailto:security@casebender.com)으로 신고하십시오. 다음 정보를 포함해 주십시오.

* 영향을 받는 버전 또는 이미지 다이제스트
* 배포 모드
* 재현 가능한 단계
* 예상 동작 및 관찰된 동작
* 잠재적 영향
* 안전하게 취급할 수 있는 개념 증명 자료

암호화되지 않은 최초 메시지에는 유효한 자격 증명, 고객 데이터 또는 파괴적인 익스플로잇 자료를 포함하지 마십시오.

## 관련 문서

* [보안 보증 프로그램](/ko/security/security-assurance)
* [코드 보안(영문)](/en/security/code-security)
* [공급망 보안(영문)](/en/security/supply-chain)
* [배포 강화 가이드(영문)](/en/security/hardening-guide)