donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
7b5ff2f80b546a453ce17d2ff9a8fb4e58220cc0
llm-wiki/raw/official-docs/scorecard-cis-benchmarks-slsa.md
T

11 KiB
Raw Blame History

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

컨텍스트

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

출처 / Source

CIS Benchmarks

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 / 관련

Reference in New Issue View Git Blame Copy Permalink