컴플라이언스 프레임워크

요약

프로젝트에 특정 컴플라이언스 요구 사항이 있거나 추가 감독이 필요하다는 것을 식별하는 레이블인 컴플라이언스 프레임워크를 생성할 수 있습니다. Ultimate 티어에서는 컴플라이언스 프레임워크가 적용된 프로젝트에 선택적으로 컴플라이언스 파이프라인 구성과 보안 정책을 적용할 수 있습니다.

프로젝트에 특정 컴플라이언스 요구 사항이 있거나 추가 감독이 필요하다는 것을 식별하는 레이블인 컴플라이언스 프레임워크를 생성할 수 있습니다.

Ultimate 티어에서는 컴플라이언스 프레임워크가 적용된 프로젝트에 선택적으로 컴플라이언스 파이프라인 구성과 보안 정책을 적용할 수 있습니다.

컴플라이언스 프레임워크는 최상위 그룹에 생성됩니다. 프로젝트가 기존 최상위 그룹 외부로 이동되면 해당 프로젝트의 프레임워크가 제거됩니다.

각 프로젝트에 최대 20개의 컴플라이언스 프레임워크를 적용할 수 있습니다.

클릭스루 데모는 커스텀 컴플라이언스 프레임워크를 참고합니다.

사전 요구 사항#

컴플라이언스 프레임워크를 생성, 편집, 삭제하려면 사용자는 다음 중 하나를 충족해야 합니다.
- 최상위 그룹에 대한 Owner 또는 Security Manager 권한이 있습니다.
- 커스텀 역할을 할당받고, 그 역할에 admin_compliance_framework 커스텀 권한이 있습니다.
프로젝트에 컴플라이언스 프레임워크를 추가하거나 제거하려면 프로젝트가 속한 그룹에 컴플라이언스 프레임워크가 있어야 합니다.

템플릿으로 컴플라이언스 프레임워크 생성#

히스토리

GitLab 19.0에서 compliance_framework_templates라는 이름의 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
GitLab 19.1에서 일반 공개되었습니다. 기능 플래그 compliance_framework_templates가 제거되었습니다.

컴플라이언스 프레임워크를 처음부터 구축하지 않고, 미리 정의된 즉시 사용 가능한(OOTB) 템플릿으로 생성할 수 있습니다. 템플릿에는 일반적인 컴플라이언스 표준에 맞춘 요구 사항과 컨트롤이 미리 구성되어 있어, 수동 설정 없이 빠르게 시작할 수 있습니다.

다음 템플릿을 사용할 수 있습니다.

템플릿	설명
CIS CSC v8.1	기초 보안 컨트롤, 기초 보안 컨트롤, 조직 보안 컨트롤을 포괄하는 Center for Internet Security Controls v8.1 프레임워크입니다.
CSA CCM v4	클라우드 보안 보증을 위한 Cloud Security Alliance Cloud Controls Matrix v4 프레임워크입니다.
Cyber Essentials	다섯 가지 핵심 기술 컨트롤을 포괄하는 영국 정부 지원 Cyber Essentials 체계입니다.
DORA	금융 부문 ICT 리스크 관리를 위한 Digital Operational Resilience Act 프레임워크입니다.
FedRAMP High	미국 연방 클라우드 서비스를 위한 Federal Risk and Authorization Management Program High 기준선입니다.
FedRAMP Low	미국 연방 클라우드 서비스를 위한 Federal Risk and Authorization Management Program Low 기준선입니다.
FedRAMP Moderate	미국 연방 클라우드 서비스를 위한 Federal Risk and Authorization Management Program Moderate 기준선입니다.
IRAP Official	호주 Information Security Registered Assessors Program Official 분류 프레임워크입니다.
IRAP Protected	호주 Information Security Registered Assessors Program Protected 분류 프레임워크입니다.
IRAP Secret	호주 Information Security Registered Assessors Program Secret 분류 프레임워크입니다.
IRAP Top Secret	호주 Information Security Registered Assessors Program Top Secret 분류 프레임워크입니다.
ISMAP	일본 Information System Security Management and Assessment Program 프레임워크입니다.
ISO 27001:2022	정보 보안 관리 시스템에 관한 국제 표준입니다.
NIS 2	핵심 기반 시설을 위한 EU Network and Information Security Directive 2 프레임워크입니다.
NIST 800-171 Rev. 3 CMMC	NIST SP 800-171 Revision 3 Cybersecurity Maturity Model Certification 프레임워크입니다.
NIST SP 800-218	NIST Secure Software Development Framework(SSDF) v1.1입니다.
NIST 800-53 Revision 5	정보 시스템을 위한 NIST SP 800-53 Rev. 5 보안 및 프라이버시 컨트롤입니다.
SOC 2	COSO 원칙에 매핑된 요구 사항을 갖추고 취약점 스캐닝, 액세스 컨트롤, 변경 관리를 포괄하는 System and Organization Controls 2 프레임워크입니다.
TISAX	자동차 산업의 정보 보안 요구 사항을 위한 Trusted Information Security Assessment Exchange 프레임워크입니다.

UI로 템플릿에서 프레임워크 생성#

템플릿으로 컴플라이언스 프레임워크를 생성하려면:

상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Frameworks 탭을 선택합니다.
New framework를 선택합니다.
Create from template를 선택합니다.
사용 가능한 템플릿을 살펴보고 하나를 선택하여 그 요구 사항과 컨트롤을 미리 봅니다.
선택 사항. 프레임워크를 사용자화하려면 Name, Description, Color를 재정의합니다.
선택 사항. 이 프레임워크를 그룹의 기본 프레임워크로 지정하려면 Set as default를 선택합니다.
Create framework를 선택합니다.

템플릿의 모든 요구 사항과 컨트롤이 미리 채워진 상태로 프레임워크가 생성됩니다. 이후 프레임워크를 편집하여 필요에 따라 요구 사항을 추가, 제거, 수정할 수 있습니다.

API 기반 생성은 템플릿으로 컴플라이언스 프레임워크 생성을 참고합니다.

컴플라이언스 프레임워크 가져오기#

히스토리

GitLab 17.11에서 도입되었습니다.

이 기능으로 공유되거나 백업된 컴플라이언스 프레임워크를 사용할 수 있습니다. JSON 파일은 기존 컴플라이언스 프레임워크와 같은 이름을 사용할 수 없습니다.

JSON 템플릿 라이브러리는 Compliance Adherence Templates 프로젝트에서 제공됩니다. 이 사전 정의된 템플릿은 완성된 프레임워크를 제공합니다. 수동 설정이 필요하지 않으므로 빠르게 시작하는 데 도움이 됩니다.

사전 정의된 컴플라이언스 프레임워크 가져오기#

미리 만들어진 컴플라이언스 프레임워크를 가져오려면:

Compliance Adherence Templates 프로젝트로 이동합니다.
사용 가능한 프레임워크 템플릿을 살펴보고 원하는 프레임워크의 JSON 파일을 다운로드합니다.
상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Frameworks 탭을 선택합니다.
New framework를 선택합니다.
Import framework를 선택합니다.
표시되는 대화 상자에서 로컬 시스템의 JSON 파일을 선택합니다.
가져오기가 성공하면 새 컴플라이언스 프레임워크가 목록에 나타납니다.

이제 프레임워크를 프로젝트에 적용할 수 있습니다. 프로젝트에 컴플라이언스 프레임워크 적용을 참고합니다.

JSON 파일에서 컴플라이언스 프레임워크 가져오기#

JSON 템플릿을 사용하여 컴플라이언스 프레임워크를 가져오려면:

상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Frameworks 탭을 선택합니다.
New framework를 선택합니다.
Import framework를 선택합니다.
표시되는 대화 상자에서 로컬 시스템의 JSON 파일을 선택합니다.

가져오기가 성공하면 새 컴플라이언스 프레임워크가 목록에 나타납니다. 오류가 있으면 수정할 수 있도록 표시됩니다.

컴플라이언스 프레임워크 생성, 편집 또는 삭제#

컴플라이언스 프레임워크 리포트 또는 컴플라이언스 프로젝트 리포트를 사용하여 컴플라이언스 프레임워크를 생성, 편집, 삭제할 수 있습니다.

컴플라이언스 프레임워크 리포트 사용에 관한 자세한 내용은 다음을 참고합니다.

컴플라이언스 프로젝트 리포트 사용에 관한 자세한 내용은 다음을 참고합니다.

새 컴플라이언스 프레임워크 생성.
컴플라이언스 프레임워크 편집.
컴플라이언스 프레임워크 삭제. 하위 그룹과 프로젝트는 최상위 그룹에 생성된 모든 컴플라이언스 프레임워크에 접근할 수 있습니다. 그러나 하위 그룹이나 프로젝트를 사용해서는 컴플라이언스 프레임워크를 생성, 편집, 삭제할 수 없습니다. 프로젝트 Owner는 자신의 프로젝트에 적용할 프레임워크를 선택할 수 있습니다.

프로젝트에 컴플라이언스 프레임워크 적용#

히스토리

GitLab 17.3에서 여러 컴플라이언스 프레임워크 적용이 도입되었습니다.
GitLab 17.11에서 컴플라이언스 프레임워크를 통해 프로젝트에 컴플라이언스 프레임워크를 적용하는 기능이 도입되었습니다.

프로젝트에 여러 컴플라이언스 프레임워크를 적용할 수 있지만, 개인 네임스페이스의 프로젝트에는 컴플라이언스 프레임워크를 적용할 수 없습니다.

프로젝트에 컴플라이언스 프레임워크를 적용하려면 컴플라이언스 프로젝트 리포트를 통해 컴플라이언스 프레임워크를 적용합니다.

GraphQL API를 사용하여 프로젝트에 하나 또는 여러 개의 컴플라이언스 프레임워크를 적용할 수 있습니다.

GraphQL로 하위 그룹에 컴플라이언스 프레임워크를 생성하면, 사용자에게 올바른 권한이 있는 경우 프레임워크가 루트 상위 그룹에 생성됩니다. GitLab UI는 이 동작을 권장하지 않기 위해 읽기 전용 보기를 제공합니다.

컴플라이언스 프레임워크를 통해 프로젝트에 컴플라이언스 프레임워크를 적용하려면:

상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Projects 탭을 선택합니다.
컴플라이언스 프레임워크에 마우스를 올리고 Edit Framework 탭을 선택합니다.
Projects 섹션을 선택합니다.
목록에서 프로젝트를 선택합니다.
Update Framework를 선택합니다.

기본 컴플라이언스 프레임워크#

그룹 Owner는 기본 컴플라이언스 프레임워크를 설정할 수 있습니다. 기본 프레임워크는 해당 그룹에 생성되는 모든 새 프로젝트와 가져온 프로젝트에 적용됩니다. 기존 프로젝트에 적용된 프레임워크에는 영향을 주지 않습니다. 기본 프레임워크는 삭제할 수 없습니다.

기본값으로 설정된 컴플라이언스 프레임워크에는 default 레이블이 붙습니다.

컴플라이언스 센터를 사용하여 기본값 설정 및 제거#

컴플라이언스 프로젝트 리포트에서 기본값으로 설정하거나 기본값을 제거하려면:

상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Projects 탭을 선택합니다.
컴플라이언스 프레임워크에 마우스를 올리고 Edit Framework 탭을 선택합니다.
Set as default를 선택합니다.
Save changes를 선택합니다.

컴플라이언스 프레임워크 리포트에서 기본값으로 설정하거나 기본값을 제거하려면:

상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Frameworks 탭을 선택합니다.
컴플라이언스 프레임워크에 마우스를 올리고 Edit Framework 탭을 선택합니다.
Set as default를 선택합니다.
Save changes를 선택합니다.

프로젝트에서 컴플라이언스 프레임워크 제거#

그룹의 한 개 또는 여러 프로젝트에서 컴플라이언스 프레임워크를 제거하려면 컴플라이언스 프로젝트 리포트를 통해 컴플라이언스 프레임워크를 제거합니다.

컴플라이언스 프레임워크를 JSON 파일로 내보내기#

히스토리

GitLab 17.11에서 도입되었습니다.

이 기능으로 컴플라이언스 프레임워크를 공유하고 백업할 수 있습니다.

컴플라이언스 센터에서 컴플라이언스 프레임워크를 내보내려면:

상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Frameworks 탭을 선택합니다.
내보내려는 컴플라이언스 프레임워크를 찾습니다.
세로 줄임표(⋮)를 선택합니다.
Export as JSON file을 선택합니다.

JSON 파일이 로컬 시스템에 다운로드됩니다.

JSON 템플릿 구조 및 스키마#

컴플라이언스 프레임워크 JSON 템플릿은 프레임워크 메타데이터, 요구 사항, 연결된 컨트롤을 정의하는 특정 스키마 구조를 따릅니다. 이 구조를 이해하면 조직의 특정 컴플라이언스 요구에 맞게 커스텀 템플릿을 만들거나 기존 템플릿을 수정할 수 있습니다.

프레임워크 속성#

각 JSON 템플릿에는 다음 최상위 속성이 포함됩니다.

속성	유형	필수	설명
`name`	String	Yes	컴플라이언스 프레임워크의 표시 이름입니다.
`description`	String	Yes	프레임워크 목적에 관한 자세한 설명입니다.
`color`	String	Yes	프레임워크의 16진수 색상 코드입니다(예: `#1f75cb`).
`requirements`	Array	No	컴플라이언스 컨트롤을 정의하는 요구 사항 객체 배열입니다.

요구 사항 구조#

requirements 배열의 각 요구 사항에는 다음이 포함됩니다.

속성	유형	필수	설명
`name`	String	Yes	컴플라이언스 요구 사항의 이름입니다.
`description`	String	Yes	요구 사항이 적용하는 내용에 관한 자세한 설명입니다.
`controls`	Array	Yes	요구 사항을 구현하는 컨트롤 객체 배열입니다.

컨트롤 구조#

controls 배열의 각 컨트롤은 특정 검사를 정의합니다.

속성	유형	필수	설명
`name`	String	Yes	GitLab 컨트롤 ID입니다(예: `scanner_sast_running`).
`control_type`	String	Yes	GitLab 컨트롤에서는 항상 `"internal"`입니다.
`expression`	Object	Yes	컨트롤의 평가 로직을 정의합니다.

표현식 객체#

expression 객체는 컨트롤이 평가되는 방식을 정의합니다.

속성	유형	필수	설명
`field`	String	Yes	평가할 필드 이름입니다(컨트롤 이름과 일치).
`operator`	String	Yes	비교 연산자입니다(`=`, `>=`, `<=`, `>`, `<`).
`value`	Mixed	Yes	예상 값입니다(불리언, 숫자 또는 문자열).

JSON 템플릿 구조 예시#

전체 구조를 보여주는 간단한 예시입니다.

{
  "name": "Example Compliance Framework",
  "description": "Example framework demonstrating JSON structure",
  "color": "#1f75cb",
  "requirements": [
    {
      "name": "Security Scanning Requirement",
      "description": "Ensure security scanning is enabled for all projects",
      "controls": [
        {
          "name": "scanner_sast_running",
          "control_type": "internal",
          "expression": {
            "field": "scanner_sast_running",
            "operator": "=",
            "value": true
          }
        },
        {
          "name": "minimum_approvals_required_2",
          "control_type": "internal",
          "expression": {
            "field": "minimum_approvals_required",
            "operator": ">=",
            "value": 2
          }
        }
      ]
    }
  ]
}

요구 사항#

히스토리

GitLab 17.11에서 enable_standards_adherence_dashboard_v2라는 이름의 기능 플래그와 함께 도입되었습니다. 기본적으로 활성화되어 있습니다.
GitLab 18.3에서 일반 공개되었습니다. 기능 플래그 enable_standards_adherence_dashboard_v2가 제거되었습니다.

GitLab Ultimate에서는 컴플라이언스 프레임워크에 대한 특정 요구 사항을 정의할 수 있습니다. 요구 사항은 하나 또는 여러 개의 컨트롤로 구성되며, 컨트롤은 해당 프레임워크가 할당된 프로젝트의 구성이나 동작을 검사합니다. 각 요구 사항은 컨트롤을 최대 5개까지 가집니다.

각 컨트롤에는 GitLab이 예약된 스캔이나 트리거된 스캔 중에 프로젝트의 준수 여부를 평가할 때 사용하는 로직이 포함됩니다. 준수 여부를 추적하는 방식에 관한 자세한 내용은 컴플라이언스 상태 리포트를 참고합니다.

프레임워크 요구 사항에는 GitLab 컴플라이언스 컨트롤 또는 외부 컨트롤을 사용할 수 있습니다.

GitLab 컴플라이언스 컨트롤#

히스토리

GitLab 18.7 이상에서 보안 스캐너 컨트롤에 더 이상 성공한 파이프라인이 필요하지 않습니다.

GitLab 컴플라이언스 컨트롤은 GitLab 컴플라이언스 프레임워크에서 사용할 수 있습니다. 컨트롤은 컴플라이언스 프레임워크에 할당된 프로젝트의 구성이나 동작을 검사합니다.

GitLab 컴플라이언스 컨트롤을 조합하여 컴플라이언스 표준을 충족하는 데 활용합니다.

Note

실행 중인 스캐너를 확인하는 보안 스캐너 컨트롤은 하위 파이프라인에 구성된 스캐너를 탐지하지 못합니다. 이러한 컨트롤이 통과하려면 상위 파이프라인에 보안 스캐너를 구성해야 합니다. 자세한 내용은 이슈 595632를 참고합니다.

컨트롤 이름	컨트롤 ID	설명
API security running	`scanner_api_security_running`	프로젝트의 기본 브랜치 파이프라인에서 API 보안 스캐닝이 구성되고 실행되고 있음을 보장합니다.
At least one approval	`minimum_approvals_required_1`	머지 전에 머지 리퀘스트가 최소 하나의 승인을 요구함을 보장합니다.
At least two approvals	`minimum_approvals_required_2`	머지 전에 머지 리퀘스트가 최소 두 개의 승인을 요구함을 보장합니다.
Auth SSO enabled	`auth_sso_enabled`	프로젝트에 SSO(Single Sign-On) 인증이 활성화되어 있음을 보장합니다.
Author approved merge request is forbidden	`merge_request_prevent_author_approval`	머지 리퀘스트 작성자가 자신의 변경 사항을 승인할 수 없음을 보장합니다.
Branch deletion disabled	`branch_deletion_disabled`	브랜치를 삭제할 수 없음을 보장합니다.
CI/CD job token scope enabled	`cicd_job_token_scope_enabled`	CI/CD job 토큰 범위 제한이 활성화되어 있음을 보장합니다.
Code changes require code owners	`code_changes_requires_code_owners`	코드 변경 사항이 코드 소유자의 승인을 요구함을 보장합니다.
Code owner approval required	`code_owner_approval_required`	코드 소유자 파일이 구성되어 있음을 보장합니다.
Code quality running	`scanner_code_quality_running`	프로젝트의 기본 브랜치 파이프라인에서 코드 품질 스캐닝이 구성되고 실행되고 있음을 보장합니다.
Committers approved merge request is forbidden	`merge_request_prevent_committers_approval`	머지 리퀘스트에 커밋한 사용자가 이를 승인할 수 없음을 보장합니다.
Container scanning running	`scanner_container_scanning_running`	프로젝트의 기본 브랜치 파이프라인에서 컨테이너 스캐닝이 구성되고 실행되고 있음을 보장합니다.
DAST running	`scanner_dast_running`	프로젝트의 기본 브랜치 파이프라인에서 동적 애플리케이션 보안 테스팅(DAST)이 구성되고 실행되고 있음을 보장합니다.
Default branch protected	`default_branch_protected`	기본 브랜치에 보호 규칙이 활성화되어 있음을 보장합니다.
Default branch protected from direct push	`default_branch_protected_from_direct_push`	기본 브랜치에 직접 푸시하는 것을 방지합니다.
Default branch users can merge	`default_branch_users_can_merge`	사용자가 기본 브랜치에 변경 사항을 머지할 수 있는지를 제어합니다.
Default branch users can push	`default_branch_users_can_push`	사용자가 기본 브랜치에 직접 푸시할 수 있는지를 제어합니다.
Duo Agentic Flow audit events streaming	`duo_agentic_flow_audit_events_streaming`	그룹 수준의 활성 감사 이벤트 스트리밍 대상이 GitLab Duo Agent Platform 이벤트를 수집함을 보장합니다. 그룹에서 Agent Platform이 비활성화되어 있으면 통과합니다.
Dependency scanning running	`scanner_dep_scanning_running`	프로젝트의 기본 브랜치 파이프라인에서 의존성 스캐닝이 구성되고 실행되고 있음을 보장합니다. 참고: GitLab Self-Managed 인스턴스(18.4 이상)에서는 SBOM 기반 의존성 스캐닝을 사용할 때 아티팩트 차이로 인해 이 컨트롤이 실패할 수 있습니다. 호환성 고려 사항을 참고합니다.
Ensure two administrators per repository	`ensure_2_admins_per_repo`	각 프로젝트에 최소 두 명의 Owner가 할당되어 있음을 보장합니다.
Error tracking enabled	`error_tracking_enabled`	프로젝트에 오류 추적이 활성화되어 있음을 보장합니다.
Force push disabled	`force_push_disabled`	리포지터리에 강제 푸시하는 것을 방지합니다.
Forks exist for the project	`has_forks`	프로젝트가 포크되었음을 보장합니다
GitLab license level Ultimate	`gitlab_license_level_ultimate`	GitLab 인스턴스가 Ultimate 라이선스를 사용하고 있음을 보장합니다.
Has valid CI/CD configuration	`has_valid_ci_config`	프로젝트에 유효한 CI/CD 구성이 있음을 보장합니다.
IaC scanning running	`scanner_iac_running`	프로젝트의 기본 브랜치 파이프라인에서 IaC(Infrastructure as Code) 스캐닝이 구성되고 실행되고 있음을 보장합니다.
Internal visibility is forbidden	`project_visibility_not_internal`	프로젝트가 내부 가시성으로 설정되지 않았음을 보장합니다.
Issue tracking enabled	`issue_tracking_enabled`	프로젝트에 이슈 추적이 활성화되어 있음을 보장합니다.
License compliance running	`scanner_license_compliance_running`	프로젝트의 기본 브랜치 파이프라인에서 라이선스 컴플라이언스 스캐닝이 구성되고 실행되고 있음을 보장합니다.
Merge request commit resets approvals	`merge_request_commit_reset_approvals`	머지 리퀘스트에 새 커밋이 추가되면 승인이 재설정됨을 보장합니다.
Merge requests approval rules prevent editing	`merge_requests_approval_rules_prevent_editing`	머지 리퀘스트 승인 규칙을 편집할 수 없음을 보장합니다.
Merge requests require code owner approval	`merge_requests_require_code_owner_approval`	머지 리퀘스트가 코드 소유자의 승인을 요구함을 보장합니다.
Model experiments access level configured	`model_experiments_access_level_configured`	ML 모델 실험이 프로젝트 멤버에게만 제한되어 있음을 보장합니다.
Model registry access level configured	`model_registry_access_level_configured`	ML 모델 레지스트리가 프로젝트 멤버에게만 제한되어 있음을 보장합니다.
More members than admins	`more_members_than_admins`	프로젝트에 할당된 관리자(Owner 또는 Maintainer)가 전체 멤버보다 적음을 보장합니다.
Package Hunter no findings untriaged	`package_hunter_no_findings_untriaged`	모든 Package Hunter 발견 사항이 심사되었음을 보장합니다.
Project not archived	`project_archived`	프로젝트가 아카이브되었는지를 확인합니다. 일반적으로 `false`가 준수입니다.
Project not marked for deletion	`project_marked_for_deletion`	프로젝트가 삭제 표시되었는지를 확인합니다. `false`가 준수입니다.
Project pipelines not public	`project_pipelines_not_public`	프로젝트 파이프라인이 공개적으로 표시되지 않음을 보장합니다. 프로젝트 가시성은 고려하지 않습니다.
Project repository exists	`project_repo_exists`	프로젝트에 Git 리포지터리가 있음을 보장합니다.
Project visibility not public	`project_visibility_not_public`	프로젝트가 공개 가시성으로 설정되지 않았음을 보장합니다.
Protected branches exist	`protected_branches_set`	프로젝트에 보호된 브랜치가 있음을 보장합니다.
Push protection enabled	`push_protection_enabled`	프로젝트에 시크릿 푸시 보호가 활성화되어 있음을 보장합니다.
Require branch up to date	`require_branch_up_to_date`	머지 전에 소스 브랜치가 대상 브랜치와 최신 상태로 유지됨을 보장합니다.
Require linear history	`require_linear_history`	머지 커밋을 금지하여 선형 커밋 히스토리를 보장합니다.
Require MFA at organization level	`require_mfa_at_org_level`	조직 수준에서 다중 인증이 요구됨을 보장합니다.
Require MFA for contributors	`require_mfa_for_contributors`	기여자가 다중 인증을 활성화했음을 보장합니다.
Requires signed commits	`require_signed_commits`	서명된 커밋이 요구됨을 보장합니다.
Reset approvals on push	`reset_approvals_on_push`	머지 리퀘스트에 새 커밋이 푸시되면 승인이 재설정됨을 보장합니다.
Resolve discussions required	`resolve_discussions_required`	머지가 허용되기 전에 모든 토론이 해결되어야 함을 보장합니다.
Restrict push/merge access	`restrict_push_merge_access`	보호된 브랜치에 푸시하거나 머지할 수 있는 사용자를 제한합니다.
Restricted build access	`restricted_build_access`	빌드 아티팩트와 파이프라인 출력에 대한 제한된 접근을 보장합니다.
Review and archive stale repositories	`review_and_archive_stale_repos`	오래된 리포지터리가 검토되고 아카이브됨을 보장합니다.
Review and remove inactive users	`review_and_remove_inactive_users`	비활성 사용자가 검토되고 제거됨을 보장합니다.
SAST running	`scanner_sast_running`	프로젝트의 기본 브랜치 파이프라인에서 정적 애플리케이션 보안 테스팅(SAST)이 구성되고 실행되고 있음을 보장합니다.
Secret detection running	`scanner_secret_detection_running`	프로젝트의 기본 브랜치 파이프라인에서 시크릿 탐지 스캐닝이 구성되고 실행되고 있음을 보장합니다.
Secure webhooks	`secure_webhooks`	웹훅이 안전하게 구성되어 있음을 보장합니다.
Stale branch cleanup enabled	`stale_branch_cleanup_enabled`	오래된 브랜치 자동 정리가 활성화되어 있음을 보장합니다.
Status checks required	`status_checks_required`	머지가 허용되기 전에 상태 검사가 통과해야 함을 보장합니다.
Status page configured	`status_page_configured`	프로젝트에 상태 페이지가 구성되어 있음을 보장합니다.
Strict Permission for Repository	`strict_permissions_for_repo`	리포지터리 접근에 엄격한 권한이 설정되어 있음을 보장합니다.
Terraform enabled	`terraform_enabled`	프로젝트에 Terraform 통합이 활성화되어 있음을 보장합니다.
User-defined CI/CD variables restricted to maintainers	`project_user_defined_variables_restricted_to_maintainers`	maintainer 권한 이상을 가진 사용자만 파이프라인을 트리거할 때 사용자 정의 변수를 전달할 수 있음을 보장합니다.
Vulnerabilities SLO days over threshold	`vulnerabilities_slo_days_over_threshold`	취약점이 SLO 임계값(180일) 내에 해결됨을 보장합니다.

외부 컨트롤#

히스토리

GitLab 18.1에서 외부 컨트롤 이름이 도입되었습니다.

외부 컨트롤은 외부 시스템에 대한 API 호출로, 외부 컨트롤이나 요구 사항의 상태를 요청합니다.

서드파티 도구로 데이터를 보내는 외부 컨트롤을 생성할 수 있습니다.

컴플라이언스 스캔이 실행되면 GitLab은 알림을 보냅니다. 그러면 사용자나 자동화된 워크플로가 GitLab 외부에서 컨트롤의 상태를 업데이트할 수 있습니다.

이 통합으로 ServiceNow 같은 서드파티 워크플로 도구나 원하는 커스텀 도구와 연동할 수 있습니다. 서드파티 도구는 연결된 상태로 응답합니다. 이 상태는 컴플라이언스 상태 리포트에 표시됩니다.

외부 컨트롤은 개별 프로젝트마다 구성할 수 있습니다. 외부 컨트롤은 프로젝트 간에 공유되지 않습니다. 외부 컨트롤이 6시간 넘게 보류 상태로 남아 있으면 상태 검사가 실패합니다.

외부 컨트롤 추가#

프레임워크를 생성하거나 편집할 때 외부 컨트롤을 추가하려면:

상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Frameworks 탭을 선택합니다.
New framework를 선택하거나 기존 프레임워크를 편집합니다.
Requirements 섹션에서 New requirement를 선택합니다.
Add an external control을 선택합니다.
필드에서 External Control Name, External URL, HMAC shared secret을 편집합니다.
선택 사항. 컴플라이언스 스캔 중에 GitLab이 외부 서비스로 알림을 보낼지 제어하려면 Ping enabled 토글을 끕니다.
Save changes to the framework를 선택하여 요구 사항을 저장합니다.

Ping enabled 설정#

히스토리

GitLab 18.5에서 도입되었습니다.

Ping enabled 설정은 GitLab이 12시간마다 외부 시스템에 외부 컨트롤 상태 업데이트를 요청할지 제어합니다.

활성화(기본값): GitLab은 12시간마다 외부 서비스 URL로 HTTP 요청을 자동으로 보내고, 응답에 따라 외부 컨트롤 상태를 업데이트합니다.
비활성화: GitLab은 외부 서비스로 알림을 보내지 않으며, 외부 컨트롤에는 컴플라이언스 프레임워크 UI에서 Disabled 배지가 표시됩니다. 외부 컨트롤의 상태를 요청하려면 외부 컨트롤 API를 수동으로 사용해야 합니다.

외부 컨트롤 라이프사이클#

외부 컨트롤은 비동기 워크플로로 동작합니다. 컴플라이언스 스캔은 언제든 외부 서비스로 페이로드를 내보냅니다.

Mermaid 다이어그램 (8줄)

소스 코드 보기

%%{init: { "fontFamily": "GitLab Sans" }}%%
sequenceDiagram
    accTitle: Workflow for external compliance controls
    accDescr: GitLab sends a requirement payload to an external service and receives a control response for compliance validation.
GitLab-&gt;&gt;+External service: Requirement payload
External service--&gt;&gt;-GitLab: Control response
Note over External service,GitLab: Response includes SHA at HEAD</code></pre></details></div>

페이로드를 받은 후 외부 서비스는 필요한 프로세스를 실행할 수 있습니다. 그런 다음 외부 서비스는 REST API를 사용하여
머지 리퀘스트에 응답을 다시 게시할 수 있습니다.
외부 컨트롤은 세 가지 상태 중 하나를 가질 수 있습니다.



상태
설명




pending
기본 상태입니다. 외부 서비스에서 응답을 받지 못했습니다.


pass
외부 서비스에서 응답을 받았고 외부 서비스가 외부 컨트롤을 승인했습니다.


fail
외부 서비스에서 응답을 받았고 외부 서비스가 외부 컨트롤을 거부했습니다.



GitLab 외부에서 무언가 변경되면 API를 사용하여 외부 컨트롤의 상태를 설정할 수 있습니다. 페이로드가 먼저 전송될 때까지 기다릴 필요가 없습니다.
외부 컨트롤 페이로드 예시#
GitLab이 컴플라이언스 스캔 중에 외부 서비스로 알림을 보낼 때는 페이로드에 자세한 프로젝트 정보가 포함됩니다. 다음은 JSON 페이로드 구조의 예시입니다.
{
  "id": 123456,
  "description": "Project for compliance testing and validation",
  "name": "Compliance Test Project",
  "name_with_namespace": "acme-corp / engineering / security / compliance-test-project",
  "path": "compliance-test-project",
  "path_with_namespace": "acme-corp/engineering/security/compliance-test-project",
  "created_at": "2024-01-15T10:30:00.000Z",
  "tag_list": ["compliance", "security"],
  "topics": ["governance", "audit"],
  "ssh_url_to_repo": "git@gitlab.com:acme-corp/engineering/security/compliance-test-project.git",
  "http_url_to_repo": "https://gitlab.com/acme-corp/engineering/security/compliance-test-project.git",
  "web_url": "https://gitlab.com/acme-corp/engineering/security/compliance-test-project",
  "avatar_url": "https://gitlab.com/uploads/-/system/project/avatar/123456/avatar.png",
  "star_count": 5,
  "last_activity_at": "2024-11-20T14:25:30.000Z",
  "visibility": "private",
  "namespace": {
    "id": 654321,
    "name": "Security Group",
    "path": "security",
    "kind": "group",
    "full_path": "acme-corp/engineering/security",
    "parent_id": 654320,
    "avatar_url": "https://gitlab.com/uploads/-/system/group/avatar/654321/avatar.png",
    "web_url": "https://gitlab.com/groups/acme-corp/engineering/security"
  },
  "container_registry_image_prefix": "registry.gitlab.com/acme-corp/engineering/security/compliance-test-project",
  "_links": {
    "self": "https://gitlab.com/api/v4/projects/123456",
    "issues": "https://gitlab.com/api/v4/projects/123456/issues",
    "merge_requests": "https://gitlab.com/api/v4/projects/123456/merge_requests",
    "repo_branches": "https://gitlab.com/api/v4/projects/123456/repository/branches",
    "labels": "https://gitlab.com/api/v4/projects/123456/labels",
    "events": "https://gitlab.com/api/v4/projects/123456/events",
    "members": "https://gitlab.com/api/v4/projects/123456/members",
    "cluster_agents": "https://gitlab.com/api/v4/projects/123456/cluster_agents"
  },
  "marked_for_deletion_at": null,
  "marked_for_deletion_on": null,
  "packages_enabled": true,
  "empty_repo": false,
  "archived": false,
  "resolve_outdated_diff_discussions": false,
  "container_expiration_policy": {
    "cadence": "1d",
    "enabled": false,
    "keep_n": 10,
    "older_than": "90d",
    "name_regex": ".*",
    "name_regex_keep": null,
    "next_run_at": "2024-01-16T10:30:00.000Z"
  },
  "repository_object_format": "sha1",
  "issues_enabled": true,
  "merge_requests_enabled": true,
  "wiki_enabled": true,
  "jobs_enabled": true,
  "snippets_enabled": true,
  "container_registry_enabled": true,
  "service_desk_enabled": true,
  "can_create_merge_request_in": false,
  "issues_access_level": "enabled",
  "repository_access_level": "enabled",
  "merge_requests_access_level": "enabled",
  "forking_access_level": "enabled",
  "wiki_access_level": "enabled",
  "builds_access_level": "enabled",
  "snippets_access_level": "enabled",
  "pages_access_level": "private",
  "analytics_access_level": "enabled",
  "container_registry_access_level": "enabled",
  "security_and_compliance_access_level": "private",
  "releases_access_level": "enabled",
  "environments_access_level": "enabled",
  "feature_flags_access_level": "enabled",
  "infrastructure_access_level": "enabled",
  "monitor_access_level": "enabled",
  "model_experiments_access_level": "enabled",
  "model_registry_access_level": "enabled",
  "package_registry_access_level": "enabled",
  "emails_disabled": false,
  "emails_enabled": true,
  "show_diff_preview_in_email": true,
  "shared_runners_enabled": true,
  "lfs_enabled": true,
  "creator_id": 111222,
  "import_status": "none",
  "open_issues_count": 3,
  "description_html": "<p>Project for compliance testing and validation</p>",
  "updated_at": "2024-11-20T14:25:30.000Z",
  "public_jobs": true,
  "shared_with_groups": [],
  "only_allow_merge_if_pipeline_succeeds": false,
  "allow_merge_on_skipped_pipeline": null,
  "request_access_enabled": true,
  "only_allow_merge_if_all_discussions_are_resolved": false,
  "remove_source_branch_after_merge": true,
  "printing_merge_request_link_enabled": true,
  "merge_method": "merge",
  "merge_request_title_regex": null,
  "merge_request_title_regex_description": null,
  "squash_option": "default_off",
  "enforce_auth_checks_on_uploads": true,
  "suggestion_commit_message": null,
  "merge_commit_template": null,
  "squash_commit_template": null,
  "issue_branch_template": null,
  "warn_about_potentially_unwanted_characters": true,
  "autoclose_referenced_issues": true,
  "max_artifacts_size": null,
  "approvals_before_merge": 0,
  "mirror": false,
  "external_authorization_classification_label": "",
  "requirements_enabled": true,
  "requirements_access_level": "enabled",
  "security_and_compliance_enabled": false,
  "compliance_frameworks": ["SOC 2 Compliance Framework"],
  "merge_pipelines_enabled": false,
  "merge_trains_enabled": false,
  "merge_trains_skip_train_allowed": false,
  "only_allow_merge_if_all_status_checks_passed": false,
  "allow_pipeline_trigger_approve_deployment": false,
  "prevent_merge_without_jira_issue": false,
  "auto_duo_code_review_enabled": false,
  "duo_remote_flows_enabled": true,
  "duo_foundational_flows_enabled": true,
  "spp_repository_pipeline_access": false,
  "project_control_compliance_status": {
    "status": "pending",
    "compliance_requirements_control_id": 100001,
    "project_id": 123456,
    "compliance_requirement_id": 200001,
    "namespace_id": 654321,
    "id": 300001,
    "created_at": "2024-11-26T10:00:00.000Z",
    "updated_at": "2024-11-26T10:00:00.000Z",
    "requirement_status_id": null
  }
}

외부 서비스는 이 정보를 사용하여 컴플라이언스 검사를 수행한 다음, 외부 컨트롤 API를 사용하여 적절한 컨트롤 상태로 응답할 수 있습니다.
요구 사항 추가#
프레임워크를 생성하거나 편집할 때 요구 사항을 추가하려면:

상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Frameworks 탭을 선택합니다.
New framework를 선택하거나 기존 프레임워크를 편집합니다.
Requirements 섹션에서 New requirement를 선택합니다.
대화 상자에서 Name과 Description을 추가합니다.
컨트롤을 더 추가하려면 Add a GitLab control을 선택합니다.
컨트롤 드롭다운 목록에서 컨트롤을 검색하여 선택합니다.
Save changes to the framework를 선택하여 요구 사항을 저장합니다.

요구 사항 편집#
프레임워크를 생성하거나 편집할 때 요구 사항을 편집하려면:

상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Frameworks 탭을 선택합니다.
New framework를 선택하거나 기존 프레임워크를 편집합니다.
Requirements 섹션에서 Action > Edit를 선택합니다.
대화 상자에서 Name과 Description을 편집합니다.
컨트롤을 더 추가하려면 Add a GitLab control을 선택합니다.
컨트롤 드롭다운 목록에서 컨트롤을 검색하여 선택합니다.
컨트롤을 제거하려면 [remove]를 선택합니다.
Save changes to the framework를 선택하여 요구 사항을 저장합니다.

문제 해결#
컴플라이언스 프레임워크를 사용할 때 다음 문제가 발생할 수 있습니다.
오류: Unable to determine the correct upload URL#
JSON 템플릿과 같은 이름의 컴플라이언스 프레임워크가 이미 있으면 컴플라이언스 프레임워크 가져오기 중에
이 오류가 발생합니다.

상태	설명
`pending`	기본 상태입니다. 외부 서비스에서 응답을 받지 못했습니다.
`pass`	외부 서비스에서 응답을 받았고 외부 서비스가 외부 컨트롤을 승인했습니다.
`fail`	외부 서비스에서 응답을 받았고 외부 서비스가 외부 컨트롤을 거부했습니다.

홈/GitLab/사용자/컴플라이언스/Compliance frameworks/컴플라이언스 프레임워크

`컴플라이언스 프레임워크`

GitLab v19.5

Tier: Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

원문 보기
번역일: 2026-09-18

요약
프로젝트에 특정 컴플라이언스 요구 사항이 있거나 추가 감독이 필요하다는 것을 식별하는 레이블인 컴플라이언스 프레임워크를 생성할 수 있습니다. Ultimate 티어에서는 컴플라이언스 프레임워크가 적용된 프로젝트에 선택적으로 컴플라이언스 파이프라인 구성과 보안 정책을 적용할 수 있습니다.

프로젝트에 특정 컴플라이언스 요구 사항이 있거나 추가 감독이 필요하다는 것을 식별하는 레이블인 컴플라이언스 프레임워크를 생성할 수 있습니다.


Ultimate 티어에서는 컴플라이언스 프레임워크가 적용된 프로젝트에 선택적으로
컴플라이언스 파이프라인 구성과
보안 정책을 적용할 수 있습니다.
컴플라이언스 프레임워크는 최상위 그룹에 생성됩니다. 프로젝트가 기존 최상위 그룹 외부로 이동되면
해당 프로젝트의 프레임워크가 제거됩니다.
각 프로젝트에 최대 20개의 컴플라이언스 프레임워크를 적용할 수 있습니다.
클릭스루 데모는 커스텀 컴플라이언스 프레임워크를 참고합니다.

사전 요구 사항#

컴플라이언스 프레임워크를 생성, 편집, 삭제하려면 사용자는 다음 중 하나를 충족해야 합니다.

최상위 그룹에 대한 Owner 또는 Security Manager 권한이 있습니다.
커스텀 역할을 할당받고, 그 역할에 admin_compliance_framework
커스텀 권한이 있습니다.


프로젝트에 컴플라이언스 프레임워크를 추가하거나 제거하려면 프로젝트가 속한 그룹에
컴플라이언스 프레임워크가 있어야 합니다.

템플릿으로 컴플라이언스 프레임워크 생성#
히스토리
GitLab 19.0에서 compliance_framework_templates라는 이름의 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
GitLab 19.1에서 일반 공개되었습니다. 기능 플래그 compliance_framework_templates가 제거되었습니다.
컴플라이언스 프레임워크를 처음부터 구축하지 않고, 미리 정의된
즉시 사용 가능한(OOTB) 템플릿으로 생성할 수 있습니다. 템플릿에는 일반적인 컴플라이언스 표준에 맞춘
요구 사항과 컨트롤이 미리 구성되어 있어, 수동 설정 없이 빠르게 시작할 수 있습니다.
다음 템플릿을 사용할 수 있습니다.



템플릿
설명




CIS CSC v8.1
기초 보안 컨트롤, 기초 보안 컨트롤, 조직 보안 컨트롤을 포괄하는 Center for Internet Security Controls v8.1 프레임워크입니다.


CSA CCM v4
클라우드 보안 보증을 위한 Cloud Security Alliance Cloud Controls Matrix v4 프레임워크입니다.


Cyber Essentials
다섯 가지 핵심 기술 컨트롤을 포괄하는 영국 정부 지원 Cyber Essentials 체계입니다.


DORA
금융 부문 ICT 리스크 관리를 위한 Digital Operational Resilience Act 프레임워크입니다.


FedRAMP High
미국 연방 클라우드 서비스를 위한 Federal Risk and Authorization Management Program High 기준선입니다.


FedRAMP Low
미국 연방 클라우드 서비스를 위한 Federal Risk and Authorization Management Program Low 기준선입니다.


FedRAMP Moderate
미국 연방 클라우드 서비스를 위한 Federal Risk and Authorization Management Program Moderate 기준선입니다.


IRAP Official
호주 Information Security Registered Assessors Program Official 분류 프레임워크입니다.


IRAP Protected
호주 Information Security Registered Assessors Program Protected 분류 프레임워크입니다.


IRAP Secret
호주 Information Security Registered Assessors Program Secret 분류 프레임워크입니다.


IRAP Top Secret
호주 Information Security Registered Assessors Program Top Secret 분류 프레임워크입니다.


ISMAP
일본 Information System Security Management and Assessment Program 프레임워크입니다.


ISO 27001:2022
정보 보안 관리 시스템에 관한 국제 표준입니다.


NIS 2
핵심 기반 시설을 위한 EU Network and Information Security Directive 2 프레임워크입니다.


NIST 800-171 Rev. 3 CMMC
NIST SP 800-171 Revision 3 Cybersecurity Maturity Model Certification 프레임워크입니다.


NIST SP 800-218
NIST Secure Software Development Framework(SSDF) v1.1입니다.


NIST 800-53 Revision 5
정보 시스템을 위한 NIST SP 800-53 Rev. 5 보안 및 프라이버시 컨트롤입니다.


SOC 2
COSO 원칙에 매핑된 요구 사항을 갖추고 취약점 스캐닝, 액세스 컨트롤, 변경 관리를 포괄하는 System and Organization Controls 2 프레임워크입니다.


TISAX
자동차 산업의 정보 보안 요구 사항을 위한 Trusted Information Security Assessment Exchange 프레임워크입니다.



UI로 템플릿에서 프레임워크 생성#
템플릿으로 컴플라이언스 프레임워크를 생성하려면:

상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Frameworks 탭을 선택합니다.
New framework를 선택합니다.
Create from template를 선택합니다.
사용 가능한 템플릿을 살펴보고 하나를 선택하여 그 요구 사항과 컨트롤을 미리 봅니다.
선택 사항. 프레임워크를 사용자화하려면 Name, Description, Color를 재정의합니다.
선택 사항. 이 프레임워크를 그룹의 기본 프레임워크로 지정하려면 Set as default를 선택합니다.
Create framework를 선택합니다.

템플릿의 모든 요구 사항과 컨트롤이 미리 채워진 상태로 프레임워크가 생성됩니다.
이후 프레임워크를 편집하여 필요에 따라 요구 사항을 추가, 제거, 수정할 수 있습니다.
API 기반 생성은 템플릿으로 컴플라이언스 프레임워크 생성을 참고합니다.
컴플라이언스 프레임워크 가져오기#
히스토리
GitLab 17.11에서 도입되었습니다.
이 기능으로 공유되거나 백업된 컴플라이언스 프레임워크를 사용할 수 있습니다. JSON 파일은 기존 컴플라이언스 프레임워크와 같은 이름을 사용할 수 없습니다.
JSON 템플릿 라이브러리는
Compliance Adherence Templates 프로젝트에서 제공됩니다.
이 사전 정의된 템플릿은 완성된 프레임워크를 제공합니다. 수동 설정이 필요하지 않으므로
빠르게 시작하는 데 도움이 됩니다.
사전 정의된 컴플라이언스 프레임워크 가져오기#
미리 만들어진 컴플라이언스 프레임워크를 가져오려면:

Compliance Adherence Templates 프로젝트로 이동합니다.
사용 가능한 프레임워크 템플릿을 살펴보고 원하는 프레임워크의 JSON 파일을 다운로드합니다.
상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Frameworks 탭을 선택합니다.
New framework를 선택합니다.
Import framework를 선택합니다.
표시되는 대화 상자에서 로컬 시스템의 JSON 파일을 선택합니다.
가져오기가 성공하면 새 컴플라이언스 프레임워크가 목록에 나타납니다.

이제 프레임워크를 프로젝트에 적용할 수 있습니다. 프로젝트에 컴플라이언스 프레임워크 적용을 참고합니다.
JSON 파일에서 컴플라이언스 프레임워크 가져오기#
JSON 템플릿을 사용하여 컴플라이언스 프레임워크를 가져오려면:

상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Frameworks 탭을 선택합니다.
New framework를 선택합니다.
Import framework를 선택합니다.
표시되는 대화 상자에서 로컬 시스템의 JSON 파일을 선택합니다.

가져오기가 성공하면 새 컴플라이언스 프레임워크가 목록에 나타납니다. 오류가 있으면 수정할 수 있도록 표시됩니다.
컴플라이언스 프레임워크 생성, 편집 또는 삭제#
컴플라이언스 프레임워크 리포트 또는 컴플라이언스 프로젝트 리포트를 사용하여 컴플라이언스 프레임워크를 생성, 편집, 삭제할 수 있습니다.
컴플라이언스 프레임워크 리포트 사용에 관한 자세한 내용은 다음을 참고합니다.

새 컴플라이언스 프레임워크 생성.
컴플라이언스 프레임워크 편집.
컴플라이언스 프레임워크 삭제.

컴플라이언스 프로젝트 리포트 사용에 관한 자세한 내용은 다음을 참고합니다.

새 컴플라이언스 프레임워크 생성.
컴플라이언스 프레임워크 편집.
컴플라이언스 프레임워크 삭제.
하위 그룹과 프로젝트는 최상위 그룹에 생성된 모든 컴플라이언스 프레임워크에 접근할 수 있습니다. 그러나 하위 그룹이나 프로젝트를 사용해서는 컴플라이언스 프레임워크를 생성, 편집,
삭제할 수 없습니다. 프로젝트 Owner는 자신의 프로젝트에 적용할 프레임워크를 선택할 수 있습니다.

프로젝트에 컴플라이언스 프레임워크 적용#
히스토리
GitLab 17.3에서 여러 컴플라이언스 프레임워크 적용이 도입되었습니다.
GitLab 17.11에서 컴플라이언스 프레임워크를 통해 프로젝트에 컴플라이언스 프레임워크를 적용하는 기능이 도입되었습니다.
프로젝트에 여러 컴플라이언스 프레임워크를 적용할 수 있지만, 개인 네임스페이스의 프로젝트에는 컴플라이언스 프레임워크를 적용할 수 없습니다.
프로젝트에 컴플라이언스 프레임워크를 적용하려면
컴플라이언스 프로젝트 리포트를 통해 컴플라이언스 프레임워크를 적용합니다.
GraphQL API를 사용하여 프로젝트에 하나 또는 여러 개의
컴플라이언스 프레임워크를 적용할 수 있습니다.
GraphQL로 하위 그룹에 컴플라이언스 프레임워크를 생성하면, 사용자에게 올바른 권한이 있는 경우 프레임워크가 루트 상위 그룹에
생성됩니다. GitLab UI는 이 동작을 권장하지 않기 위해 읽기 전용 보기를 제공합니다.
컴플라이언스 프레임워크를 통해 프로젝트에 컴플라이언스 프레임워크를 적용하려면:

상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Projects 탭을 선택합니다.
컴플라이언스 프레임워크에 마우스를 올리고 Edit Framework 탭을 선택합니다.
Projects 섹션을 선택합니다.
목록에서 프로젝트를 선택합니다.
Update Framework를 선택합니다.

기본 컴플라이언스 프레임워크#
그룹 Owner는 기본 컴플라이언스 프레임워크를 설정할 수 있습니다. 기본 프레임워크는 해당 그룹에 생성되는 모든 새 프로젝트와 가져온
프로젝트에 적용됩니다. 기존 프로젝트에 적용된 프레임워크에는 영향을 주지 않습니다. 기본
프레임워크는 삭제할 수 없습니다.
기본값으로 설정된 컴플라이언스 프레임워크에는 default 레이블이 붙습니다.
컴플라이언스 센터를 사용하여 기본값 설정 및 제거#
컴플라이언스 프로젝트 리포트에서 기본값으로 설정하거나 기본값을 제거하려면:

상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Projects 탭을 선택합니다.
컴플라이언스 프레임워크에 마우스를 올리고 Edit Framework 탭을 선택합니다.
Set as default를 선택합니다.
Save changes를 선택합니다.

컴플라이언스 프레임워크 리포트에서 기본값으로 설정하거나 기본값을 제거하려면:

상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Frameworks 탭을 선택합니다.
컴플라이언스 프레임워크에 마우스를 올리고 Edit Framework 탭을 선택합니다.
Set as default를 선택합니다.
Save changes를 선택합니다.

프로젝트에서 컴플라이언스 프레임워크 제거#
그룹의 한 개 또는 여러 프로젝트에서 컴플라이언스 프레임워크를 제거하려면
컴플라이언스 프로젝트 리포트를 통해 컴플라이언스 프레임워크를 제거합니다.
컴플라이언스 프레임워크를 JSON 파일로 내보내기#
히스토리
GitLab 17.11에서 도입되었습니다.
이 기능으로 컴플라이언스 프레임워크를 공유하고 백업할 수 있습니다.
컴플라이언스 센터에서 컴플라이언스 프레임워크를 내보내려면:

상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Frameworks 탭을 선택합니다.
내보내려는 컴플라이언스 프레임워크를 찾습니다.
세로 줄임표(⋮)를 선택합니다.
Export as JSON file을 선택합니다.

JSON 파일이 로컬 시스템에 다운로드됩니다.
JSON 템플릿 구조 및 스키마#
컴플라이언스 프레임워크 JSON 템플릿은 프레임워크 메타데이터, 요구 사항, 연결된 컨트롤을 정의하는 특정 스키마 구조를 따릅니다. 이 구조를 이해하면 조직의 특정 컴플라이언스 요구에 맞게 커스텀 템플릿을 만들거나 기존 템플릿을 수정할 수 있습니다.
프레임워크 속성#
각 JSON 템플릿에는 다음 최상위 속성이 포함됩니다.



속성
유형
필수
설명




name
String
Yes
컴플라이언스 프레임워크의 표시 이름입니다.


description
String
Yes
프레임워크 목적에 관한 자세한 설명입니다.


color
String
Yes
프레임워크의 16진수 색상 코드입니다(예: #1f75cb).


requirements
Array
No
컴플라이언스 컨트롤을 정의하는 요구 사항 객체 배열입니다.



요구 사항 구조#
requirements 배열의 각 요구 사항에는 다음이 포함됩니다.



속성
유형
필수
설명




name
String
Yes
컴플라이언스 요구 사항의 이름입니다.


description
String
Yes
요구 사항이 적용하는 내용에 관한 자세한 설명입니다.


controls
Array
Yes
요구 사항을 구현하는 컨트롤 객체 배열입니다.



컨트롤 구조#
controls 배열의 각 컨트롤은 특정 검사를 정의합니다.



속성
유형
필수
설명




name
String
Yes
GitLab 컨트롤 ID입니다(예: scanner_sast_running).


control_type
String
Yes
GitLab 컨트롤에서는 항상 "internal"입니다.


expression
Object
Yes
컨트롤의 평가 로직을 정의합니다.



표현식 객체#
expression 객체는 컨트롤이 평가되는 방식을 정의합니다.



속성
유형
필수
설명




field
String
Yes
평가할 필드 이름입니다(컨트롤 이름과 일치).


operator
String
Yes
비교 연산자입니다(=, >=, <=, >, <).


value
Mixed
Yes
예상 값입니다(불리언, 숫자 또는 문자열).



JSON 템플릿 구조 예시#
전체 구조를 보여주는 간단한 예시입니다.
{
  "name": "Example Compliance Framework",
  "description": "Example framework demonstrating JSON structure",
  "color": "#1f75cb",
  "requirements": [
    {
      "name": "Security Scanning Requirement",
      "description": "Ensure security scanning is enabled for all projects",
      "controls": [
        {
          "name": "scanner_sast_running",
          "control_type": "internal",
          "expression": {
            "field": "scanner_sast_running",
            "operator": "=",
            "value": true
          }
        },
        {
          "name": "minimum_approvals_required_2",
          "control_type": "internal",
          "expression": {
            "field": "minimum_approvals_required",
            "operator": ">=",
            "value": 2
          }
        }
      ]
    }
  ]
}

요구 사항#
히스토리
GitLab 17.11에서 enable_standards_adherence_dashboard_v2라는 이름의 기능 플래그와 함께 도입되었습니다. 기본적으로 활성화되어 있습니다.
GitLab 18.3에서 일반 공개되었습니다. 기능 플래그 enable_standards_adherence_dashboard_v2가 제거되었습니다.
GitLab Ultimate에서는 컴플라이언스 프레임워크에 대한 특정 요구 사항을 정의할 수 있습니다. 요구 사항은 하나 또는
여러 개의 컨트롤로 구성되며, 컨트롤은 해당 프레임워크가 할당된 프로젝트의 구성이나 동작을 검사합니다. 각 요구 사항은 컨트롤을 최대 5개까지 가집니다.
각 컨트롤에는 GitLab이 예약된 스캔이나 트리거된 스캔 중에 프로젝트의 준수 여부를 평가할 때 사용하는 로직이 포함됩니다.
준수 여부를 추적하는 방식에 관한 자세한 내용은 컴플라이언스 상태 리포트를 참고합니다.
프레임워크 요구 사항에는 GitLab 컴플라이언스 컨트롤 또는 외부 컨트롤을 사용할 수 있습니다.
GitLab 컴플라이언스 컨트롤#
히스토리
GitLab 18.7 이상에서 보안 스캐너 컨트롤에 더 이상 성공한 파이프라인이 필요하지 않습니다.
GitLab 컴플라이언스 컨트롤은 GitLab 컴플라이언스 프레임워크에서 사용할 수 있습니다. 컨트롤은 컴플라이언스 프레임워크에 할당된 프로젝트의 구성이나
동작을 검사합니다.
GitLab 컴플라이언스 컨트롤을 조합하여
컴플라이언스 표준을 충족하는 데 활용합니다.
Note
실행 중인 스캐너를 확인하는 보안 스캐너 컨트롤은
하위 파이프라인에 구성된 스캐너를 탐지하지 못합니다.
이러한 컨트롤이 통과하려면 상위 파이프라인에 보안 스캐너를 구성해야 합니다.
자세한 내용은
이슈 595632를 참고합니다.





컨트롤 이름
컨트롤 ID
설명




API security running
scanner_api_security_running
프로젝트의 기본 브랜치 파이프라인에서 API 보안 스캐닝이 구성되고 실행되고 있음을 보장합니다.


At least one approval
minimum_approvals_required_1
머지 전에 머지 리퀘스트가 최소 하나의 승인을 요구함을 보장합니다.


At least two approvals
minimum_approvals_required_2
머지 전에 머지 리퀘스트가 최소 두 개의 승인을 요구함을 보장합니다.


Auth SSO enabled
auth_sso_enabled
프로젝트에 SSO(Single Sign-On) 인증이 활성화되어 있음을 보장합니다.


Author approved merge request is forbidden
merge_request_prevent_author_approval
머지 리퀘스트 작성자가 자신의 변경 사항을 승인할 수 없음을 보장합니다.


Branch deletion disabled
branch_deletion_disabled
브랜치를 삭제할 수 없음을 보장합니다.


CI/CD job token scope enabled
cicd_job_token_scope_enabled
CI/CD job 토큰 범위 제한이 활성화되어 있음을 보장합니다.


Code changes require code owners
code_changes_requires_code_owners
코드 변경 사항이 코드 소유자의 승인을 요구함을 보장합니다.


Code owner approval required
code_owner_approval_required
코드 소유자 파일이 구성되어 있음을 보장합니다.


Code quality running
scanner_code_quality_running
프로젝트의 기본 브랜치 파이프라인에서 코드 품질 스캐닝이 구성되고 실행되고 있음을 보장합니다.


Committers approved merge request is forbidden
merge_request_prevent_committers_approval
머지 리퀘스트에 커밋한 사용자가 이를 승인할 수 없음을 보장합니다.


Container scanning running
scanner_container_scanning_running
프로젝트의 기본 브랜치 파이프라인에서 컨테이너 스캐닝이 구성되고 실행되고 있음을 보장합니다.


DAST running
scanner_dast_running
프로젝트의 기본 브랜치 파이프라인에서 동적 애플리케이션 보안 테스팅(DAST)이 구성되고 실행되고 있음을 보장합니다.


Default branch protected
default_branch_protected
기본 브랜치에 보호 규칙이 활성화되어 있음을 보장합니다.


Default branch protected from direct push
default_branch_protected_from_direct_push
기본 브랜치에 직접 푸시하는 것을 방지합니다.


Default branch users can merge
default_branch_users_can_merge
사용자가 기본 브랜치에 변경 사항을 머지할 수 있는지를 제어합니다.


Default branch users can push
default_branch_users_can_push
사용자가 기본 브랜치에 직접 푸시할 수 있는지를 제어합니다.


Duo Agentic Flow audit events streaming
duo_agentic_flow_audit_events_streaming
그룹 수준의 활성 감사 이벤트 스트리밍 대상이 GitLab Duo Agent Platform 이벤트를 수집함을 보장합니다. 그룹에서 Agent Platform이 비활성화되어 있으면 통과합니다.


Dependency scanning running
scanner_dep_scanning_running
프로젝트의 기본 브랜치 파이프라인에서 의존성 스캐닝이 구성되고 실행되고 있음을 보장합니다. 참고: GitLab Self-Managed 인스턴스(18.4 이상)에서는 SBOM 기반 의존성 스캐닝을 사용할 때 아티팩트 차이로 인해 이 컨트롤이 실패할 수 있습니다. 호환성 고려 사항을 참고합니다.


Ensure two administrators per repository
ensure_2_admins_per_repo
각 프로젝트에 최소 두 명의 Owner가 할당되어 있음을 보장합니다.


Error tracking enabled
error_tracking_enabled
프로젝트에 오류 추적이 활성화되어 있음을 보장합니다.


Force push disabled
force_push_disabled
리포지터리에 강제 푸시하는 것을 방지합니다.


Forks exist for the project
has_forks
프로젝트가 포크되었음을 보장합니다


GitLab license level Ultimate
gitlab_license_level_ultimate
GitLab 인스턴스가 Ultimate 라이선스를 사용하고 있음을 보장합니다.


Has valid CI/CD configuration
has_valid_ci_config
프로젝트에 유효한 CI/CD 구성이 있음을 보장합니다.


IaC scanning running
scanner_iac_running
프로젝트의 기본 브랜치 파이프라인에서 IaC(Infrastructure as Code) 스캐닝이 구성되고 실행되고 있음을 보장합니다.


Internal visibility is forbidden
project_visibility_not_internal
프로젝트가 내부 가시성으로 설정되지 않았음을 보장합니다.


Issue tracking enabled
issue_tracking_enabled
프로젝트에 이슈 추적이 활성화되어 있음을 보장합니다.


License compliance running
scanner_license_compliance_running
프로젝트의 기본 브랜치 파이프라인에서 라이선스 컴플라이언스 스캐닝이 구성되고 실행되고 있음을 보장합니다.


Merge request commit resets approvals
merge_request_commit_reset_approvals
머지 리퀘스트에 새 커밋이 추가되면 승인이 재설정됨을 보장합니다.


Merge requests approval rules prevent editing
merge_requests_approval_rules_prevent_editing
머지 리퀘스트 승인 규칙을 편집할 수 없음을 보장합니다.


Merge requests require code owner approval
merge_requests_require_code_owner_approval
머지 리퀘스트가 코드 소유자의 승인을 요구함을 보장합니다.


Model experiments access level configured
model_experiments_access_level_configured
ML 모델 실험이 프로젝트 멤버에게만 제한되어 있음을 보장합니다.


Model registry access level configured
model_registry_access_level_configured
ML 모델 레지스트리가 프로젝트 멤버에게만 제한되어 있음을 보장합니다.


More members than admins
more_members_than_admins
프로젝트에 할당된 관리자(Owner 또는 Maintainer)가 전체 멤버보다 적음을 보장합니다.


Package Hunter no findings untriaged
package_hunter_no_findings_untriaged
모든 Package Hunter 발견 사항이 심사되었음을 보장합니다.


Project not archived
project_archived
프로젝트가 아카이브되었는지를 확인합니다. 일반적으로 false가 준수입니다.


Project not marked for deletion
project_marked_for_deletion
프로젝트가 삭제 표시되었는지를 확인합니다. false가 준수입니다.


Project pipelines not public
project_pipelines_not_public
프로젝트 파이프라인이 공개적으로 표시되지 않음을 보장합니다. 프로젝트 가시성은 고려하지 않습니다.


Project repository exists
project_repo_exists
프로젝트에 Git 리포지터리가 있음을 보장합니다.


Project visibility not public
project_visibility_not_public
프로젝트가 공개 가시성으로 설정되지 않았음을 보장합니다.


Protected branches exist
protected_branches_set
프로젝트에 보호된 브랜치가 있음을 보장합니다.


Push protection enabled
push_protection_enabled
프로젝트에 시크릿 푸시 보호가 활성화되어 있음을 보장합니다.


Require branch up to date
require_branch_up_to_date
머지 전에 소스 브랜치가 대상 브랜치와 최신 상태로 유지됨을 보장합니다.


Require linear history
require_linear_history
머지 커밋을 금지하여 선형 커밋 히스토리를 보장합니다.


Require MFA at organization level
require_mfa_at_org_level
조직 수준에서 다중 인증이 요구됨을 보장합니다.


Require MFA for contributors
require_mfa_for_contributors
기여자가 다중 인증을 활성화했음을 보장합니다.


Requires signed commits
require_signed_commits
서명된 커밋이 요구됨을 보장합니다.


Reset approvals on push
reset_approvals_on_push
머지 리퀘스트에 새 커밋이 푸시되면 승인이 재설정됨을 보장합니다.


Resolve discussions required
resolve_discussions_required
머지가 허용되기 전에 모든 토론이 해결되어야 함을 보장합니다.


Restrict push/merge access
restrict_push_merge_access
보호된 브랜치에 푸시하거나 머지할 수 있는 사용자를 제한합니다.


Restricted build access
restricted_build_access
빌드 아티팩트와 파이프라인 출력에 대한 제한된 접근을 보장합니다.


Review and archive stale repositories
review_and_archive_stale_repos
오래된 리포지터리가 검토되고 아카이브됨을 보장합니다.


Review and remove inactive users
review_and_remove_inactive_users
비활성 사용자가 검토되고 제거됨을 보장합니다.


SAST running
scanner_sast_running
프로젝트의 기본 브랜치 파이프라인에서 정적 애플리케이션 보안 테스팅(SAST)이 구성되고 실행되고 있음을 보장합니다.


Secret detection running
scanner_secret_detection_running
프로젝트의 기본 브랜치 파이프라인에서 시크릿 탐지 스캐닝이 구성되고 실행되고 있음을 보장합니다.


Secure webhooks
secure_webhooks
웹훅이 안전하게 구성되어 있음을 보장합니다.


Stale branch cleanup enabled
stale_branch_cleanup_enabled
오래된 브랜치 자동 정리가 활성화되어 있음을 보장합니다.


Status checks required
status_checks_required
머지가 허용되기 전에 상태 검사가 통과해야 함을 보장합니다.


Status page configured
status_page_configured
프로젝트에 상태 페이지가 구성되어 있음을 보장합니다.


Strict Permission for Repository
strict_permissions_for_repo
리포지터리 접근에 엄격한 권한이 설정되어 있음을 보장합니다.


Terraform enabled
terraform_enabled
프로젝트에 Terraform 통합이 활성화되어 있음을 보장합니다.


User-defined CI/CD variables restricted to maintainers
project_user_defined_variables_restricted_to_maintainers
maintainer 권한 이상을 가진 사용자만 파이프라인을 트리거할 때 사용자 정의 변수를 전달할 수 있음을 보장합니다.


Vulnerabilities SLO days over threshold
vulnerabilities_slo_days_over_threshold
취약점이 SLO 임계값(180일) 내에 해결됨을 보장합니다.



외부 컨트롤#
히스토리
GitLab 18.1에서 외부 컨트롤 이름이 도입되었습니다.
외부 컨트롤은 외부 시스템에 대한 API 호출로, 외부 컨트롤이나 요구 사항의 상태를 요청합니다.
서드파티 도구로 데이터를 보내는 외부 컨트롤을 생성할 수 있습니다.
컴플라이언스 스캔이 실행되면 GitLab은 알림을 보냅니다. 그러면 사용자나 자동화된 워크플로가 GitLab 외부에서 컨트롤의 상태를 업데이트할 수 있습니다.
이 통합으로 ServiceNow 같은 서드파티 워크플로 도구나 원하는 커스텀 도구와 연동할 수 있습니다. 서드파티 도구는
연결된 상태로 응답합니다. 이 상태는 컴플라이언스 상태 리포트에 표시됩니다.
외부 컨트롤은 개별 프로젝트마다 구성할 수 있습니다. 외부 컨트롤은 프로젝트 간에 공유되지 않습니다.
외부 컨트롤이 6시간 넘게 보류 상태로 남아 있으면 상태 검사가 실패합니다.
외부 컨트롤 추가#
프레임워크를 생성하거나 편집할 때 외부 컨트롤을 추가하려면:

상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Frameworks 탭을 선택합니다.
New framework를 선택하거나 기존 프레임워크를 편집합니다.
Requirements 섹션에서 New requirement를 선택합니다.
Add an external control을 선택합니다.
필드에서 External Control Name, External URL, HMAC shared secret을 편집합니다.
선택 사항. 컴플라이언스 스캔 중에 GitLab이 외부 서비스로 알림을 보낼지 제어하려면 Ping enabled 토글을 끕니다.
Save changes to the framework를 선택하여 요구 사항을 저장합니다.

Ping enabled 설정#
히스토리
GitLab 18.5에서 도입되었습니다.
Ping enabled 설정은 GitLab이 12시간마다 외부 시스템에 외부 컨트롤 상태 업데이트를 요청할지 제어합니다.

활성화(기본값): GitLab은 12시간마다 외부 서비스 URL로 HTTP 요청을 자동으로 보내고, 응답에 따라 외부 컨트롤 상태를 업데이트합니다.
비활성화: GitLab은 외부 서비스로 알림을 보내지 않으며, 외부 컨트롤에는 컴플라이언스 프레임워크 UI에서 Disabled 배지가 표시됩니다.
외부 컨트롤의 상태를 요청하려면 외부 컨트롤 API를 수동으로 사용해야 합니다.

외부 컨트롤 라이프사이클#
외부 컨트롤은 비동기 워크플로로 동작합니다. 컴플라이언스 스캔은 언제든 외부 서비스로 페이로드를 내보냅니다.
Mermaid 다이어그램 (8줄)
소스 코드 보기
%%{init: { "fontFamily": "GitLab Sans" }}%%
sequenceDiagram
    accTitle: Workflow for external compliance controls
    accDescr: GitLab sends a requirement payload to an external service and receives a control response for compliance validation.
GitLab-&gt;&gt;+External service: Requirement payload
External service--&gt;&gt;-GitLab: Control response
Note over External service,GitLab: Response includes SHA at HEAD</code></pre></details></div>

페이로드를 받은 후 외부 서비스는 필요한 프로세스를 실행할 수 있습니다. 그런 다음 외부 서비스는 REST API를 사용하여
머지 리퀘스트에 응답을 다시 게시할 수 있습니다.
외부 컨트롤은 세 가지 상태 중 하나를 가질 수 있습니다.



상태
설명




pending
기본 상태입니다. 외부 서비스에서 응답을 받지 못했습니다.


pass
외부 서비스에서 응답을 받았고 외부 서비스가 외부 컨트롤을 승인했습니다.


fail
외부 서비스에서 응답을 받았고 외부 서비스가 외부 컨트롤을 거부했습니다.



GitLab 외부에서 무언가 변경되면 API를 사용하여 외부 컨트롤의 상태를 설정할 수 있습니다. 페이로드가 먼저 전송될 때까지 기다릴 필요가 없습니다.
외부 컨트롤 페이로드 예시#
GitLab이 컴플라이언스 스캔 중에 외부 서비스로 알림을 보낼 때는 페이로드에 자세한 프로젝트 정보가 포함됩니다. 다음은 JSON 페이로드 구조의 예시입니다.
{
  "id": 123456,
  "description": "Project for compliance testing and validation",
  "name": "Compliance Test Project",
  "name_with_namespace": "acme-corp / engineering / security / compliance-test-project",
  "path": "compliance-test-project",
  "path_with_namespace": "acme-corp/engineering/security/compliance-test-project",
  "created_at": "2024-01-15T10:30:00.000Z",
  "tag_list": ["compliance", "security"],
  "topics": ["governance", "audit"],
  "ssh_url_to_repo": "git@gitlab.com:acme-corp/engineering/security/compliance-test-project.git",
  "http_url_to_repo": "https://gitlab.com/acme-corp/engineering/security/compliance-test-project.git",
  "web_url": "https://gitlab.com/acme-corp/engineering/security/compliance-test-project",
  "avatar_url": "https://gitlab.com/uploads/-/system/project/avatar/123456/avatar.png",
  "star_count": 5,
  "last_activity_at": "2024-11-20T14:25:30.000Z",
  "visibility": "private",
  "namespace": {
    "id": 654321,
    "name": "Security Group",
    "path": "security",
    "kind": "group",
    "full_path": "acme-corp/engineering/security",
    "parent_id": 654320,
    "avatar_url": "https://gitlab.com/uploads/-/system/group/avatar/654321/avatar.png",
    "web_url": "https://gitlab.com/groups/acme-corp/engineering/security"
  },
  "container_registry_image_prefix": "registry.gitlab.com/acme-corp/engineering/security/compliance-test-project",
  "_links": {
    "self": "https://gitlab.com/api/v4/projects/123456",
    "issues": "https://gitlab.com/api/v4/projects/123456/issues",
    "merge_requests": "https://gitlab.com/api/v4/projects/123456/merge_requests",
    "repo_branches": "https://gitlab.com/api/v4/projects/123456/repository/branches",
    "labels": "https://gitlab.com/api/v4/projects/123456/labels",
    "events": "https://gitlab.com/api/v4/projects/123456/events",
    "members": "https://gitlab.com/api/v4/projects/123456/members",
    "cluster_agents": "https://gitlab.com/api/v4/projects/123456/cluster_agents"
  },
  "marked_for_deletion_at": null,
  "marked_for_deletion_on": null,
  "packages_enabled": true,
  "empty_repo": false,
  "archived": false,
  "resolve_outdated_diff_discussions": false,
  "container_expiration_policy": {
    "cadence": "1d",
    "enabled": false,
    "keep_n": 10,
    "older_than": "90d",
    "name_regex": ".*",
    "name_regex_keep": null,
    "next_run_at": "2024-01-16T10:30:00.000Z"
  },
  "repository_object_format": "sha1",
  "issues_enabled": true,
  "merge_requests_enabled": true,
  "wiki_enabled": true,
  "jobs_enabled": true,
  "snippets_enabled": true,
  "container_registry_enabled": true,
  "service_desk_enabled": true,
  "can_create_merge_request_in": false,
  "issues_access_level": "enabled",
  "repository_access_level": "enabled",
  "merge_requests_access_level": "enabled",
  "forking_access_level": "enabled",
  "wiki_access_level": "enabled",
  "builds_access_level": "enabled",
  "snippets_access_level": "enabled",
  "pages_access_level": "private",
  "analytics_access_level": "enabled",
  "container_registry_access_level": "enabled",
  "security_and_compliance_access_level": "private",
  "releases_access_level": "enabled",
  "environments_access_level": "enabled",
  "feature_flags_access_level": "enabled",
  "infrastructure_access_level": "enabled",
  "monitor_access_level": "enabled",
  "model_experiments_access_level": "enabled",
  "model_registry_access_level": "enabled",
  "package_registry_access_level": "enabled",
  "emails_disabled": false,
  "emails_enabled": true,
  "show_diff_preview_in_email": true,
  "shared_runners_enabled": true,
  "lfs_enabled": true,
  "creator_id": 111222,
  "import_status": "none",
  "open_issues_count": 3,
  "description_html": "<p>Project for compliance testing and validation</p>",
  "updated_at": "2024-11-20T14:25:30.000Z",
  "public_jobs": true,
  "shared_with_groups": [],
  "only_allow_merge_if_pipeline_succeeds": false,
  "allow_merge_on_skipped_pipeline": null,
  "request_access_enabled": true,
  "only_allow_merge_if_all_discussions_are_resolved": false,
  "remove_source_branch_after_merge": true,
  "printing_merge_request_link_enabled": true,
  "merge_method": "merge",
  "merge_request_title_regex": null,
  "merge_request_title_regex_description": null,
  "squash_option": "default_off",
  "enforce_auth_checks_on_uploads": true,
  "suggestion_commit_message": null,
  "merge_commit_template": null,
  "squash_commit_template": null,
  "issue_branch_template": null,
  "warn_about_potentially_unwanted_characters": true,
  "autoclose_referenced_issues": true,
  "max_artifacts_size": null,
  "approvals_before_merge": 0,
  "mirror": false,
  "external_authorization_classification_label": "",
  "requirements_enabled": true,
  "requirements_access_level": "enabled",
  "security_and_compliance_enabled": false,
  "compliance_frameworks": ["SOC 2 Compliance Framework"],
  "merge_pipelines_enabled": false,
  "merge_trains_enabled": false,
  "merge_trains_skip_train_allowed": false,
  "only_allow_merge_if_all_status_checks_passed": false,
  "allow_pipeline_trigger_approve_deployment": false,
  "prevent_merge_without_jira_issue": false,
  "auto_duo_code_review_enabled": false,
  "duo_remote_flows_enabled": true,
  "duo_foundational_flows_enabled": true,
  "spp_repository_pipeline_access": false,
  "project_control_compliance_status": {
    "status": "pending",
    "compliance_requirements_control_id": 100001,
    "project_id": 123456,
    "compliance_requirement_id": 200001,
    "namespace_id": 654321,
    "id": 300001,
    "created_at": "2024-11-26T10:00:00.000Z",
    "updated_at": "2024-11-26T10:00:00.000Z",
    "requirement_status_id": null
  }
}

외부 서비스는 이 정보를 사용하여 컴플라이언스 검사를 수행한 다음, 외부 컨트롤 API를 사용하여 적절한 컨트롤 상태로 응답할 수 있습니다.
요구 사항 추가#
프레임워크를 생성하거나 편집할 때 요구 사항을 추가하려면:

상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Frameworks 탭을 선택합니다.
New framework를 선택하거나 기존 프레임워크를 편집합니다.
Requirements 섹션에서 New requirement를 선택합니다.
대화 상자에서 Name과 Description을 추가합니다.
컨트롤을 더 추가하려면 Add a GitLab control을 선택합니다.
컨트롤 드롭다운 목록에서 컨트롤을 검색하여 선택합니다.
Save changes to the framework를 선택하여 요구 사항을 저장합니다.

요구 사항 편집#
프레임워크를 생성하거나 편집할 때 요구 사항을 편집하려면:

상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
페이지에서 Frameworks 탭을 선택합니다.
New framework를 선택하거나 기존 프레임워크를 편집합니다.
Requirements 섹션에서 Action > Edit를 선택합니다.
대화 상자에서 Name과 Description을 편집합니다.
컨트롤을 더 추가하려면 Add a GitLab control을 선택합니다.
컨트롤 드롭다운 목록에서 컨트롤을 검색하여 선택합니다.
컨트롤을 제거하려면 [remove]를 선택합니다.
Save changes to the framework를 선택하여 요구 사항을 저장합니다.

문제 해결#
컴플라이언스 프레임워크를 사용할 때 다음 문제가 발생할 수 있습니다.
오류: Unable to determine the correct upload URL#
JSON 템플릿과 같은 이름의 컴플라이언스 프레임워크가 이미 있으면 컴플라이언스 프레임워크 가져오기 중에
이 오류가 발생합니다.