정책 설계
정책은 "스캐너가 찾은 것"과 "빌드를 차단하는 것" 사이의 계약입니다. 한쪽으로 어긋나면 첫날부터 모든 빌드가 빨갛게 변해 팀이 게이트를 우회하고, 반대로 어긋나면 게이트가 아무것도 막지 못합니다. 이 페이지는 처음부터 집행 가능하고 시간이 지나며 조여지는 라이선스·취약점 정책을 설계하도록 돕습니다.
팀 정책을 설계하는 team_admin과 조직 전반 기본 정책을 정하는 super_admin. 라이선스 분류 티어와 빌드 차단 게이트에 익숙하다고 가정합니다. SCA(소프트웨어 구성 분석)는 오픈소스 의존성을 목록화하고 리스크를 산정하는 작업으로, 이 정책이 규율하는 대상입니다.
게이트가 실제로 평가하는 것
두 가지 독립 조건이 기본값으로 빌드를 차단하며, 선택적 차원이 하나 더 있습니다.
| 조건 | 기본 차단 | 조정 |
|---|---|---|
| 금지 티어 라이선스를 가진 컴포넌트 | 예 | 팀별 라이선스 정책 |
| Critical 심각도의 열린 발견 항목 | 예 | 고정 — 환경변수로 조정 불가 |
| EPSS 악용 확률이 높은 열린 발견 항목 | 아니요 | GATE_EPSS_THRESHOLD(선택) |
라이선스 쪽과 취약점 쪽은 다른 레버를 쓰므로 따로 설계하십시오.
라이선스 티어: 세 갈래
모든 라이선스는 세 티어 중 하나로 귀결됩니다. 이것이 라이선스 정책의 중심축입니다.
| 티어 | 의미 | 게이트 동작 | 예시 |
|---|---|---|---|
| 금지 | 빌드 차단 | 차단 | AGPL, GPL, SSPL, BUSL |
| 조건부 | 법무 검토 + 승인 필요 | 통과하되 승인 요청 발생 | LGPL, MPL, EPL, CDDL |
| 허용 | 자유롭게 사용 | 통과 | MIT, Apache-2.0, BSD, ISC |
정책이 없으면 포털은 고정된 내장 카탈로그로 분류합니다. 라이선스 정책은 그 분류를 편집 가능한 데이터로 만듭니다 — 보통 허용인 라이선스를 금지하거나, 보통 금지인 라이선스를 특정 컴포넌트에 한해 예외 처리하거나, 미분류 라이선스의 태도를 정할 수 있으며 모두 런타임에, 재배포 없이 이뤄집니다. 범위 우선순위(팀 정책, 없으면 조직 기본, 없으면 내장 카탈로그)는 유효 정책 결정 설명을 따르십시오.
super_admin으로 하우스 규칙을 담은 조직 기본 정책 하나를 작성한 뒤, 팀이 실제로 다른 지점만 각 team_admin이 재정의하게 하십시오(예: 폐쇄형 SaaS를 배포하는 팀은 재배포 바이너리를 내보내는 팀보다 카피레프트를 더 느슨히 다룰 수 있습니다). 모든 팀에 빈 정책을 넘기지 마십시오 — 조직 기본이 정책을 전혀 작성하지 않는 팀의 안전망입니다.
미분류 라이선스 태도는 실제 결정입니다
unknown_license_category는 카탈로그에도 재정의에도 없는 라이선스를 어떻게 다룰지 정합니다. 기본값은 conditional이며, 미상 라이선스가 조용히 통과하거나 강하게 차단되는 대신 승인으로 라우팅됩니다. 특별한 이유가 없으면 그대로 두십시오. allowed는 진짜로 미상인 조건을 검토 없이 내보내고, forbidden은 잘못 파싱되거나 새로운 라이선 스마다 빌드를 실패시킵니다.
승인 워크플로우를 언제 쓰는가
조건부 라이선스는 빌드를 차단하지 않고 승인 큐에 요청을 올리며, 리뷰어가 상태 기계(대기 → 검토 중 → 승인 / 반려)로 처리합니다. "항상 예"나 "항상 아니오"가 아니라 "쓰는 방식에 따라 다르다"가 답일 때 쓰십시오.
- 우리에겐 항상 예 → 정책에서 라이선스를
allowed로 재정의하거나license_exception을 추가하십시오. 컴포넌트별 검토가 없습니다. - 링킹·배포 모델에 따라 다르다 →
conditional로 두고 법무가 컴포넌트별로 결정하게 하십시오. 이 워크플로우의 목적입니다. - 절대 안 됨 → 라이선스를
forbidden으로 재정의하십시오. 빌드가 차단되고 검토가 필요 없습니다.
빌드 차단 게이트는 forbidden 티어만 평가합니다. 승인을 반려로 표시하면 판정이 감사용으로 기록되지만 컴포넌트를 자동으로 금지로 승격하지 않으므로, 이후 스캔은 여전히 그 컴포넌트를 통과시킵니다. 어떤 컴포넌트가 반드시 CI를 차단해야 한다면 정책에서 라이선스를 forbidden으로 재정의하십시오 — 반려 판정에 의존하지 마십시오. 반려 판정 주의를 참고하십시오.
두 프로젝트의 같은 컴포넌트가 독립된 두 요청을 올리므로, 판정이 프로젝트별인지 하우스 전체인지 먼저 정하십시오 — 교차 프로젝트 승인 참고. 조건부 라이선스가 지우는 의무사항(저작자 표시, 소스 공개, 카피레프트)은 의무 카탈로그에 정리돼 있으며, 리뷰어는 승인 드로어에서 곧바로 읽습니다.
취약점 게이트 임계값
심각도 모델은 고정입니다. Critical 열린 발견 항목이 차단하고 그 아래는 게이트 시점에 정보성입니다. 심각도 모델을 참고하십시오. "열린" 의 의미와 추가 차단 조건을 두 레버가 형성합니다.
- 분류 규율(핵심 레버). 열린 발견 항목만 셉니다. VEX 상태 기계로 처리한 항목 —
해당 없음,오탐,수정됨— 은 게이트에서 제외됩니다. 건강한 게이트는 기준을 낮추는 것이 아니라 팀이 실제로 분류하는가에 달려 있습니다. VEX는 그 분류를 기록하는 취약점 악용 가능성 교환 모델입니다. - EPSS 게이트(선택).
GATE_EPSS_THRESHOLD(0–1)를 설정하면 Critical이 아니어도 열린 발견 항목의 악용 확률이 선을 넘을 때 빌드를 실패시킵니다. 팀이 분류에 익숙해질 때까지는 설정하지 마십시오 —GATE_EPSS_THRESHOLD참고.
처음엔 느슨하게, 뒤에 조입니다
출시하자마자 모든 빌드를 차단하는 정책은 일주일 안에 꺼지거나 우회됩니다. 대신 단계적으로 조이십시오.
- 관찰. 사실상 보고 전용으로 게이트를 내보내십시오 — 기본 임계값을 유지하고 재정의를 추가하지 말며, 빨간 벽 없이 팀이 PR에서 판정을 보게 하십시오. 대시보드에서 라이선스와 심각도의 실제 분포를 관찰하십시오.
- 하우스 규칙 성문화. 관찰한 내용에서 조직 기본 정책을 작성하십시오 — 법무가 이미 금지한 것을 금지하고, 미분류 태도를 정하고, 실제 배포 중인 소수의 예외 의존성을 추가하십시오.
- 팀별로 조이기. 팀의 리스크 프로파일이 타당하면
forbidden쪽으로 재정의하고, 분류가 습관이 된 뒤 EPSS 게이트를 켜십시오. 각 조이기 단계는 정책 편집이라 재배포가 없으므로 한 팀씩 옮길 수 있습니다.
더 엄격한 정책을 켜면 다음 스캔에서 모든 컴포넌트의 라이선스 표현을 다시 평가합니다. 어제 통과한 의존성이 오늘 차단될 수 있습니다. 변경을 알리고, 조직 기본을 한 번에 모두에게 뒤집기보다 팀별로 단계화하십시오.
검증
설계한 정책을 점검하십시오.
- 조직 기본 정책이 존재하고, 자체 정책이 없는 팀이 이를 상속합니다(팀의 유효 정책 읽기가 정적 카탈로그로 떨어지는
404가 아니라 조직 기본을 반환합니다).
forbidden으로 재정의한 컴포넌트는 다음 스캔의 빌드 차단 게이트에서 실패하고,license_exception으로 추가한 컴포넌트는 통과합니다.
- 조건부 라이선스 컴포넌트가 차단이 아니라 승인 요청을 올립니다 — 티어 분리가 연결됐음을 확인합니다.
unknown_license_category태도가 방치된 값이 아니라 의도적 선택입니다(기본conditional).
- EPSS 게이트를 켰다면,
GATE_EPSS_THRESHOLD를 넘는 발견 항목은 빌드를 실패시키고 같은 심각도의 낮은 확률 항목은 그렇지 않습니다.
함께 보기
- 라이선스 정책 — 티어·범위·재정의·예외와 편집기
- 의무 카탈로그 — 라이선스 분류별 의무
- 승인 — 조건부 라이선스 워크플로우
- 취약점 — 게이트를 형성하는 VEX 분류
- 환경변수 — 빌드 게이트 —
GATE_EPSS_THRESHOLD