InfoGrab DocsInfoGrab Docs

컴플라이언스 프레임워크

요약

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

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

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

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

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

클릭 데모를 보려면 Custom Compliance frameworks를 참조하세요.

사전 조건#

  • 컴플라이언스 프레임워크를 생성, 수정, 삭제하려면 사용자에게 다음 중 하나가 필요합니다:

최상위 그룹에 대한 Owner 또는 Security Manager 권한.

  • admin_compliance_framework 커스텀 권한이 있는 커스텀 권한을 할당받은 경우.

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

템플릿에서 컴플라이언스 프레임워크 만들기#

Tier: Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
히스토리
  • GitLab 19.0에서 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 5가지 핵심 기술 통제 항목을 포함하는 영국 정부 지원 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 호주 정보 보안 등록 평가 프로그램(IRAP) Official 분류 프레임워크.
IRAP Protected 호주 정보 보안 등록 평가 프로그램(IRAP) Protected 분류 프레임워크.
IRAP Secret 호주 정보 보안 등록 평가 프로그램(IRAP) Secret 분류 프레임워크.
IRAP Top Secret 호주 정보 보안 등록 평가 프로그램(IRAP) Top Secret 분류 프레임워크.
ISMAP 일본 정보 시스템 보안 관리 및 평가 프로그램(ISMAP) 프레임워크.
ISO 27001:2022 정보 보안 관리 시스템을 위한 국제 표준.
NIS 2 핵심 인프라를 위한 EU 네트워크 및 정보 보안 지침 2(NIS 2) 프레임워크.
NIST 800-171 Rev. 3 CMMC NIST SP 800-171 Revision 3 사이버보안 성숙도 모델 인증(CMMC) 프레임워크.
NIST SP 800-218 NIST 안전한 소프트웨어 개발 프레임워크(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 기반 생성은 템플릿에서 컴플라이언스 프레임워크 만들기를 참조하세요.

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

히스토리

이 기능을 사용하면 공유하거나 백업된 컴플라이언스 프레임워크를 사용할 수 있습니다. 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 파일로 내보내기#

히스토리

이 기능을 사용하면 컴플라이언스 프레임워크를 공유하거나 백업할 수 있습니다.

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

  • 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.

  • 왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.

  • 페이지에서 Frameworks 탭을 선택합니다.

  • 내보낼 컴플라이언스 프레임워크를 찾습니다.

  • 세로 줄임표( ellipsis_v )를 선택합니다.

  • 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 객체#

expression 객체는 통제가 평가되는 방식을 정의합니다:

속성 유형 필수 설명
field String Yes 평가할 필드 이름(통제 이름과 일치).
operator String Yes 비교 연산자(=, >=, <=, >, <).
value Mixed Yes 예상 값(boolean, number, 또는 string).

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
          }
        }
      ]
    }
  ]
}

요구사항#

Tier: Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
히스토리
  • GitLab 17.11에서 enable_standards_adherence_dashboard_v2라는 플래그와 함께 도입됨. 기본적으로 활성화됨.

GitLab Ultimate에서는 컴플라이언스 프레임워크에 대한 특정 요구사항을 정의할 수 있습니다. 요구사항은 하나 이상의 통제 항목으로 구성되며, 프레임워크가 할당된 프로젝트의 구성 또는 동작에 대한 검사입니다. 각 요구사항의 최대 통제 항목 수는 5개입니다.

각 통제 항목에는 GitLab이 예약 또는 트리거된 스캔 중에 프로젝트의 준수 여부를 평가하는 데 사용하는 로직이 포함됩니다. 준수 추적 방법에 대한 자세한 내용은 컴플라이언스 상태 보고서를 참조하세요.

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

GitLab 컴플라이언스 통제#

히스토리

GitLab 컴플라이언스 통제는 GitLab 컴플라이언스 프레임워크에서 사용할 수 있습니다. 통제 항목은 컴플라이언스 프레임워크에 할당된 프로젝트의 구성 또는 동작에 대한 검사입니다.

GitLab 컴플라이언스 통제를 조합하여 컴플라이언스 표준을 충족하는 데 도움을 받으세요.

Note

실행 중인 스캐너를 확인하는 보안 스캐너 통제는 하위 파이프라인에 구성된 스캐너를 감지하지 못합니다. 이러한 통제가 통과되려면 부모 파이프라인에 보안 스캐너를 구성해야 합니다. 자세한 내용은 이슈 595632를 참조하세요.

통제 이름 통제 ID 설명
API security running scanner_api_security_running 프로젝트의 기본 브랜치 파이프라인에서 API 보안 스캐닝이 구성되어 실행 중인지 확인합니다.
At least one approval minimum_approvals_required_1 머지 리퀘스트를 병합하기 전에 최소 1개의 승인이 필요한지 확인합니다.
At least two approvals minimum_approvals_required_2 머지 리퀘스트를 병합하기 전에 최소 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 코드 변경에 코드 Owner의 승인이 필요한지 확인합니다.
Code owner approval required code_owner_approval_required 코드 Owner 파일이 구성되어 있는지 확인합니다.
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 사용자가 기본 브랜치에 직접 푸시할 수 있는지 여부를 제어합니다.
Dependency scanning running scanner_dep_scanning_running 프로젝트의 기본 브랜치 파이프라인에서 종속성 스캐닝이 구성되어 실행 중인지 확인합니다. 참고: GitLab Self-Managed 인스턴스(18.4부터)에서는 아티팩트 차이로 인해 SBOM 기반 종속성 스캐닝 사용 시 이 통제가 실패할 수 있습니다. 호환성 고려사항을 참조하세요.
Ensure two administrators per repository ensure_2_admins_per_repo 각 프로젝트에 최소 2명의 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) 스캐닝이 구성되어 실행 중인지 확인합니다.
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 머지 리퀘스트에 코드 Owner의 승인이 필요한지 확인합니다.
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 조직 수준에서 다중 인증(MFA)이 요구되는지 확인합니다.
Require MFA for contributors require_mfa_for_contributors 기여자가 다중 인증(MFA)을 활성화했는지 확인합니다.
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 URLHMAC shared secret 필드를 편집합니다.

  • 선택 사항. Ping enabled 토글을 끄면 컴플라이언스 스캔 중 GitLab이 외부 서비스에 알림을 보내지 않습니다.

  • Save changes to the framework를 선택하여 요구사항을 저장합니다.

Ping enabled 설정#

히스토리

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

  • 활성화(기본값): GitLab이 12시간마다 외부 서비스 URL에 HTTP 요청을 자동으로 전송하고 응답에 따라 외부 통제 상태를 업데이트합니다.

  • 비활성화: GitLab이 외부 서비스에 알림을 보내지 않으며 외부 통제가 컴플라이언스 프레임워크 UI에 Disabled 배지로 표시됩니다. 외부 통제의 상태를 요청하려면 External Controls API를 수동으로 사용해야 합니다.

외부 통제 라이프사이클#

외부 통제는 비동기 워크플로를 가집니다. 컴플라이언스 스캔은 실행될 때마다 외부 서비스에 페이로드를 전송합니다.

%%{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->>&#43;External service: Requirement payload
External service-->>-GitLab: Control response
Note over External service,GitLab: Response includes SHA at HEAD

페이로드를 받은 후 외부 서비스는 필요한 프로세스를 실행할 수 있습니다. 그런 다음 외부 서비스는 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를 선택합니다.

  • 대화 상자에서 NameDescription을 추가합니다.

  • Add a GitLab control을 선택하여 통제 항목을 더 추가합니다.

  • 통제 드롭다운 목록에서 통제 항목을 검색하여 선택합니다.

  • Save changes to the framework를 선택하여 요구사항을 저장합니다.

요구사항 수정#

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

  • 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.

  • 왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.

  • 페이지에서 Frameworks 탭을 선택합니다.

  • New framework를 선택하거나 기존 프레임워크를 수정합니다.

  • Requirements 섹션에서 Action > Edit를 선택합니다.

  • 대화 상자에서 NameDescription을 수정합니다.

  • Add a GitLab control을 선택하여 통제 항목을 더 추가합니다.

  • 통제 드롭다운 목록에서 통제 항목을 검색하여 선택합니다.

  • remove를 선택하여 통제 항목을 제거합니다.

  • Save changes to the framework를 선택하여 요구사항을 저장합니다.

문제 해결#

컴플라이언스 프레임워크를 사용할 때 다음 문제가 발생할 수 있습니다.

오류: 올바른 업로드 URL을 확인할 수 없음#

컴플라이언스 프레임워크 가져오기 중에 JSON 템플릿과 동일한 이름의 컴플라이언스 프레임워크가 이미 존재하는 경우 이 오류가 발생합니다.

컴플라이언스 프레임워크

GitLab v19.2
Tier: Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기
요약

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

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

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

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

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

클릭 데모를 보려면 Custom Compliance frameworks를 참조하세요.

사전 조건#

  • 컴플라이언스 프레임워크를 생성, 수정, 삭제하려면 사용자에게 다음 중 하나가 필요합니다:

최상위 그룹에 대한 Owner 또는 Security Manager 권한.

  • admin_compliance_framework 커스텀 권한이 있는 커스텀 권한을 할당받은 경우.

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

템플릿에서 컴플라이언스 프레임워크 만들기#

Tier: Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
히스토리
  • GitLab 19.0에서 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 5가지 핵심 기술 통제 항목을 포함하는 영국 정부 지원 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 호주 정보 보안 등록 평가 프로그램(IRAP) Official 분류 프레임워크.
IRAP Protected 호주 정보 보안 등록 평가 프로그램(IRAP) Protected 분류 프레임워크.
IRAP Secret 호주 정보 보안 등록 평가 프로그램(IRAP) Secret 분류 프레임워크.
IRAP Top Secret 호주 정보 보안 등록 평가 프로그램(IRAP) Top Secret 분류 프레임워크.
ISMAP 일본 정보 시스템 보안 관리 및 평가 프로그램(ISMAP) 프레임워크.
ISO 27001:2022 정보 보안 관리 시스템을 위한 국제 표준.
NIS 2 핵심 인프라를 위한 EU 네트워크 및 정보 보안 지침 2(NIS 2) 프레임워크.
NIST 800-171 Rev. 3 CMMC NIST SP 800-171 Revision 3 사이버보안 성숙도 모델 인증(CMMC) 프레임워크.
NIST SP 800-218 NIST 안전한 소프트웨어 개발 프레임워크(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 기반 생성은 템플릿에서 컴플라이언스 프레임워크 만들기를 참조하세요.

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

히스토리

이 기능을 사용하면 공유하거나 백업된 컴플라이언스 프레임워크를 사용할 수 있습니다. 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 파일로 내보내기#

히스토리

이 기능을 사용하면 컴플라이언스 프레임워크를 공유하거나 백업할 수 있습니다.

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

  • 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.

  • 왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.

  • 페이지에서 Frameworks 탭을 선택합니다.

  • 내보낼 컴플라이언스 프레임워크를 찾습니다.

  • 세로 줄임표( ellipsis_v )를 선택합니다.

  • 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 객체#

expression 객체는 통제가 평가되는 방식을 정의합니다:

속성 유형 필수 설명
field String Yes 평가할 필드 이름(통제 이름과 일치).
operator String Yes 비교 연산자(=, >=, <=, >, <).
value Mixed Yes 예상 값(boolean, number, 또는 string).

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
          }
        }
      ]
    }
  ]
}

요구사항#

Tier: Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
히스토리
  • GitLab 17.11에서 enable_standards_adherence_dashboard_v2라는 플래그와 함께 도입됨. 기본적으로 활성화됨.

GitLab Ultimate에서는 컴플라이언스 프레임워크에 대한 특정 요구사항을 정의할 수 있습니다. 요구사항은 하나 이상의 통제 항목으로 구성되며, 프레임워크가 할당된 프로젝트의 구성 또는 동작에 대한 검사입니다. 각 요구사항의 최대 통제 항목 수는 5개입니다.

각 통제 항목에는 GitLab이 예약 또는 트리거된 스캔 중에 프로젝트의 준수 여부를 평가하는 데 사용하는 로직이 포함됩니다. 준수 추적 방법에 대한 자세한 내용은 컴플라이언스 상태 보고서를 참조하세요.

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

GitLab 컴플라이언스 통제#

히스토리

GitLab 컴플라이언스 통제는 GitLab 컴플라이언스 프레임워크에서 사용할 수 있습니다. 통제 항목은 컴플라이언스 프레임워크에 할당된 프로젝트의 구성 또는 동작에 대한 검사입니다.

GitLab 컴플라이언스 통제를 조합하여 컴플라이언스 표준을 충족하는 데 도움을 받으세요.

Note

실행 중인 스캐너를 확인하는 보안 스캐너 통제는 하위 파이프라인에 구성된 스캐너를 감지하지 못합니다. 이러한 통제가 통과되려면 부모 파이프라인에 보안 스캐너를 구성해야 합니다. 자세한 내용은 이슈 595632를 참조하세요.

통제 이름 통제 ID 설명
API security running scanner_api_security_running 프로젝트의 기본 브랜치 파이프라인에서 API 보안 스캐닝이 구성되어 실행 중인지 확인합니다.
At least one approval minimum_approvals_required_1 머지 리퀘스트를 병합하기 전에 최소 1개의 승인이 필요한지 확인합니다.
At least two approvals minimum_approvals_required_2 머지 리퀘스트를 병합하기 전에 최소 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 코드 변경에 코드 Owner의 승인이 필요한지 확인합니다.
Code owner approval required code_owner_approval_required 코드 Owner 파일이 구성되어 있는지 확인합니다.
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 사용자가 기본 브랜치에 직접 푸시할 수 있는지 여부를 제어합니다.
Dependency scanning running scanner_dep_scanning_running 프로젝트의 기본 브랜치 파이프라인에서 종속성 스캐닝이 구성되어 실행 중인지 확인합니다. 참고: GitLab Self-Managed 인스턴스(18.4부터)에서는 아티팩트 차이로 인해 SBOM 기반 종속성 스캐닝 사용 시 이 통제가 실패할 수 있습니다. 호환성 고려사항을 참조하세요.
Ensure two administrators per repository ensure_2_admins_per_repo 각 프로젝트에 최소 2명의 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) 스캐닝이 구성되어 실행 중인지 확인합니다.
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 머지 리퀘스트에 코드 Owner의 승인이 필요한지 확인합니다.
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 조직 수준에서 다중 인증(MFA)이 요구되는지 확인합니다.
Require MFA for contributors require_mfa_for_contributors 기여자가 다중 인증(MFA)을 활성화했는지 확인합니다.
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 URLHMAC shared secret 필드를 편집합니다.

  • 선택 사항. Ping enabled 토글을 끄면 컴플라이언스 스캔 중 GitLab이 외부 서비스에 알림을 보내지 않습니다.

  • Save changes to the framework를 선택하여 요구사항을 저장합니다.

Ping enabled 설정#

히스토리

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

  • 활성화(기본값): GitLab이 12시간마다 외부 서비스 URL에 HTTP 요청을 자동으로 전송하고 응답에 따라 외부 통제 상태를 업데이트합니다.

  • 비활성화: GitLab이 외부 서비스에 알림을 보내지 않으며 외부 통제가 컴플라이언스 프레임워크 UI에 Disabled 배지로 표시됩니다. 외부 통제의 상태를 요청하려면 External Controls API를 수동으로 사용해야 합니다.

외부 통제 라이프사이클#

외부 통제는 비동기 워크플로를 가집니다. 컴플라이언스 스캔은 실행될 때마다 외부 서비스에 페이로드를 전송합니다.

%%{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->>&#43;External service: Requirement payload
External service-->>-GitLab: Control response
Note over External service,GitLab: Response includes SHA at HEAD

페이로드를 받은 후 외부 서비스는 필요한 프로세스를 실행할 수 있습니다. 그런 다음 외부 서비스는 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를 선택합니다.

  • 대화 상자에서 NameDescription을 추가합니다.

  • Add a GitLab control을 선택하여 통제 항목을 더 추가합니다.

  • 통제 드롭다운 목록에서 통제 항목을 검색하여 선택합니다.

  • Save changes to the framework를 선택하여 요구사항을 저장합니다.

요구사항 수정#

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

  • 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.

  • 왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.

  • 페이지에서 Frameworks 탭을 선택합니다.

  • New framework를 선택하거나 기존 프레임워크를 수정합니다.

  • Requirements 섹션에서 Action > Edit를 선택합니다.

  • 대화 상자에서 NameDescription을 수정합니다.

  • Add a GitLab control을 선택하여 통제 항목을 더 추가합니다.

  • 통제 드롭다운 목록에서 통제 항목을 검색하여 선택합니다.

  • remove를 선택하여 통제 항목을 제거합니다.

  • Save changes to the framework를 선택하여 요구사항을 저장합니다.

문제 해결#

컴플라이언스 프레임워크를 사용할 때 다음 문제가 발생할 수 있습니다.

오류: 올바른 업로드 URL을 확인할 수 없음#

컴플라이언스 프레임워크 가져오기 중에 JSON 템플릿과 동일한 이름의 컴플라이언스 프레임워크가 이미 존재하는 경우 이 오류가 발생합니다.