---
title: CIS Benchmarks + SLSA Build Levels — 점수 체계 비교
source_type: official-doc
url: https://www.cisecurity.org/cis-benchmarks
archive_url:
status: raw
confidence: high
tags: [scorecard, readiness, cis, slsa, supply-chain, ca-skeleton, official-doc]
related_projects: [ca-skeleton]
related_branches: [feature-implementation-readiness-scorecard, feature-build-release-supply-chain-contract]
created: 2026-05-25
last_reviewed: 2026-05-27
---

# CIS Benchmarks + SLSA Build Levels — 점수 체계 비교

> Layer: `raw/official-docs/` — CIS Benchmarks 및 SLSA spec 발췌. ca-tmpl 대안 후보 두 개("CIS Benchmark scoring", "SLSA build level scoring") 의 1차 자료.
> 주: 한 파일에 두 출처를 묶어 두는 이유는 두 모델이 모두 **외부 점수 체계의 representative** 이고 본 scorecard 와 비교 목적이 동일하기 때문.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-implementation-readiness-scorecard]] | Group G-G 대안 3 — CIS scored/not-scored 와 SLSA Build L0~L3 이라는 외부 점수 체계와 ca-tmpl 의 binary pass/fail 차이를 명문화 |
| [[raw/branch-notes/feature-build-release-supply-chain-contract]] | SLSA Build L1+ provenance 요건이 area 14 (build/CI/runtime) evidence cell 에 매핑되는 근거 |

추가 foundational 인용:

- [[raw/project-notes/ca-skeleton-operational-contract]] — §27 "100점 Readiness Scorecard" 에서 area 14 의 evidence 형태로 SLSA provenance 인용 가능성 검토

## 컨텍스트

`feature-implementation-readiness-scorecard` 의 ca-tmpl 대안 후보 중 **CIS Benchmark scoring** 과 **SLSA build level scoring** 두 개가 있었다. 둘 다 "외부 표준 점수" 의 대표. 본 skeleton 의 binary pass/fail 이 그 둘과 어떻게 다른지 명문화 필요.

## 출처 / Source

### CIS Benchmarks

- 원본 URL: https://www.cisecurity.org/cis-benchmarks
- 아카이브 URL: (미수집)
- 저자 / 조직: Center for Internet Security (CIS)
- 발행일: 지속적으로 갱신
- 마지막 확인일: 2026-05-27

### SLSA Build Levels

- 원본 URL: https://slsa.dev/spec/v1.0/levels
- 아카이브 URL: (미수집)
- 저자 / 조직: SLSA / OpenSSF (Linux Foundation)
- 발행일: v1.0
- 마지막 확인일: 2026-05-27

## 핵심 인용 / Key quotes (verbatim)

### CIS

> [§CIS Benchmarks List] "The CIS Benchmarks® are prescriptive configuration recommendations for more than 25+ vendor product families."

> [§CIS Benchmarks List] "They represent the consensus-based effort of cybersecurity experts globally to help you protect your systems against threats more confidently."

### SLSA

> [§Build L0: No guarantees] "No requirements—L0 represents the lack of SLSA."

> [§Build L1: Provenance exists] "Package has provenance showing how it was built. Can be used to prevent mistakes but is trivial to bypass or forge."

> [§Build L1: Provenance exists] "Provenance exists describing how the artifact was built, including the build platform, build process, and top-level inputs."

> [§Build L2: Hosted build platform] "Forging the provenance or evading verification requires an explicit 'attack', though this may be easy to perform."

> [§Build L2: Hosted build platform] "Build platform runs on dedicated infrastructure, not an individual's workstation, and the provenance is tied to that infrastructure through a digital signature."

> [§Build L2 - Benefits] "Prevents tampering after the build through digital signatures."

> [§Build L3: Hardened builds] "Forging the provenance or evading verification requires exploiting a vulnerability that is beyond the capabilities of most adversaries."

> [§Build L3: Hardened builds] "All of Build L2, plus: Build platform implements strong controls to prevent runs from influencing one another."

> [§Build L3: Hardened builds - Benefits] "Prevents tampering during the build—by insider threats, compromised credentials, or other tenants."

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| SC-CIS-C1 | CIS Benchmarks 는 25+ vendor 제품군 (vendor product families) 을 대상으로 한 prescriptive configuration recommendations | [§CIS Benchmarks List] "The CIS Benchmarks® are prescriptive configuration recommendations for more than 25+ vendor product families." | `official-standard` | CIS 가 cover 하는 25+ vendor 제품 환경 | CIS 가 모든 cloud/on-prem 환경의 universal scoring 표준이라는 뜻 아님 — vendor-specific |
| SC-CIS-C2 | CIS Benchmarks 는 글로벌 cybersecurity 전문가들의 consensus 기반으로 개발됨 | [§CIS Benchmarks List] "They represent the consensus-based effort of cybersecurity experts globally to help you protect your systems against threats more confidently." | `official-standard` | CIS 개발 process 일반 | consensus 가 single-vendor 표준보다 더 정확하다는 뜻 아님 — 개발 method 의 사실만 |
| SC-CIS-C3 | (Level 1/2 profile 및 Scored/Not Scored 구분은 본 landing page 의 fetched 콘텐츠에 없음 — 개별 Benchmark PDF 또는 별도 페이지에서 정의됨) | (해당 인용 없음 — 본 landing page fetch 에서 누락) | `needs-confirmation` | (별도 페이지 확인 필요) | 본 page 만으로는 Level 1/2 / Scored 의 정확한 정의 인용 불가 |
| SC-SLSA-C1 | SLSA Build L0 는 "no requirements" — SLSA 부재 상태를 나타냄 | [§Build L0] "No requirements—L0 represents the lack of SLSA." | `official-standard` | SLSA Build Track baseline | L0 환경이 어떤 위협에 노출되는지의 위협 모델은 본 인용 범위 밖 |
| SC-SLSA-C2 | SLSA Build L1 은 "package has provenance showing how it was built" 를 요구하며, build platform / build process / top-level inputs 를 기술한 provenance 가 존재해야 함. 단 trivial 하게 우회/위조 가능 | [§Build L1] "Package has provenance showing how it was built. Can be used to prevent mistakes but is trivial to bypass or forge." + "Provenance exists describing how the artifact was built, including the build platform, build process, and top-level inputs." | `official-standard` | SLSA Build L1 준수 빌드 | L1 provenance 가 실제 보안 공격을 방어한다는 뜻 아님 — "prevent mistakes" 만 보장 |
| SC-SLSA-C3 | SLSA Build L2 는 "build platform runs on dedicated infrastructure" + provenance 가 digital signature 로 infrastructure 에 묶임. tampering after the build 를 방지 | [§Build L2] "Build platform runs on dedicated infrastructure, not an individual's workstation, and the provenance is tied to that infrastructure through a digital signature." + [Benefits] "Prevents tampering after the build through digital signatures." | `official-standard` | hosted CI/CD (e.g., GitHub Actions hosted runners) | L2 가 빌드 중 tampering 도 방지한다는 뜻 아님 — "after the build" 만 |
| SC-SLSA-C4 | SLSA Build L3 는 L2 + "build platform implements strong controls to prevent runs from influencing one another". 빌드 중 tampering (insider threats, compromised credentials, other tenants) 을 방지 | [§Build L3] "All of Build L2, plus: Build platform implements strong controls to prevent runs from influencing one another." + [Benefits] "Prevents tampering during the build—by insider threats, compromised credentials, or other tenants." | `official-standard` | L3 인증 hardened build platform (e.g., 격리 강화 hosted runners) | L3 가 supply chain 전체 위험 (dependency confusion, package compromise) 을 cover 한다는 뜻 아님 — Build Track 범위만 |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - `SC-CIS-C1` ~ `C2`: CIS 가 vendor product family 대상 prescriptive recommendation 이며 consensus 기반이라는 사실
  - `SC-SLSA-C1` ~ `C4`: SLSA Build L0~L3 의 정확한 요건과 각 level 이 방지하는 위협 범위
- **이 자료가 증명하지 않는 것**:
  - CIS Level 1 / Level 2 profile 의 정확한 정의 (본 landing page fetch 에 누락 — `SC-CIS-C3` 는 `needs-confirmation`)
  - CIS Scored vs Not Scored 의 정의 (동일)
  - SLSA Build Track 외의 Source Track / Provenance Track 의 요건 (별도 문서)
  - SLSA L1~L3 가 ca-tmpl 의 area 14 와 1:1 매핑되는 정합성 (수작업 매핑 필요)
  - CIS 와 SLSA 가 ca-tmpl 의 binary pass/fail 보다 우월/열등하다는 비교 판단
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - CIS Benchmarks 개별 PDF 에서 Level 1/2 + Scored/Not Scored 정의 1차 인용 확보 (현재 `SC-CIS-C3` 는 `needs-confirmation`)
  - SLSA Build L1+ provenance 가 area 14 의 "Required evidence" cell 에 들어갈 정확한 형태 (signed artifact verify 명령 + 출력 sample 필요)
  - ca-tmpl 의 area 단위 binary 와 SLSA L1/L2/L3 단계적 maturity 의 호환성 (L1 통과 ≠ area 14 pass 일 수 있음)

## 메모 / Notes (내 프로젝트 해석)

> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

- CIS = **항목 단위 scored/not-scored + Level 1/2 profile** (단 본 landing page 직접 인용 없음 — `SC-CIS-C3`). 본 skeleton 과 가까운 구조이지만, profile 은 **strictness level** (L1=일반, L2=강화) 이고 본 skeleton 은 **area completeness**.
- SLSA = **build supply chain 단계적 maturity (L0→L3)**. 본 skeleton 의 area 14 ("config/secret/build/CI/runtime") owner branch 들과 **직접 매핑 가능 (SC-SLSA-C2~C4 의 provenance 요건 → evidence cell)**.
- 본 skeleton 에 도입 가능 부분:
  - SLSA Build L1+ 요건 (provenance 존재, `SC-SLSA-C2`) 을 area 14 의 "Required evidence" cell 에 명시 가능 (예: signed artifact verify).
  - CIS 의 scored/not-scored 개념 (인용 미확보) 을 area 별 evidence 에서 "automation possible / manual only" 구분으로 재사용 가능 (이미 ca-tmpl 이 "automation missing is allowed only if manual evidence table is complete" 로 흡수).
- 도입 비용: 두 표준 모두 별도 ecosystem 이 있고 audit 자체가 무겁다. skeleton 단계에서 **준수 선언이 아니라 evidence 형태로 참조** 하는 정도가 합리적.

## Related / 관련

- 같은 주제 다른 official-doc:
  - [[raw/official-docs/scorecard-aws-well-architected]] — Group G-G 대안 1 (질문 기반 HRI flag)
  - [[raw/official-docs/scorecard-opentelemetry-maturity]] — Group G-G 대안 2 (signal lifecycle 모델)
- 인용하는 branch:
  - [[raw/branch-notes/feature-implementation-readiness-scorecard]] — Group G-G 대안 3
  - [[raw/branch-notes/feature-build-release-supply-chain-contract]] — area 14 evidence
- canonical contract 섹션:
  - [[raw/project-notes/ca-skeleton-operational-contract]] §27 "100점 Readiness Scorecard"
- 인용하는 wiki: (미작성)