보안 구성
GitLab v19.5Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
요약
보안 스캐너는 프로젝트별로 구성하거나 여러 프로젝트가 공유하는 스캐너 구성을 만들어 적용할 수 있습니다. 예를 들어 동일한 보안 스캐닝 구성을 수동으로 적용한 프로젝트가 10개 있다면 한 번의 변경을 10번 반복해야 합니다.
보안 스캐너는 프로젝트별로 구성하거나 여러 프로젝트가 공유하는 스캐너 구성을 만들어 적용할 수 있습니다. 프로젝트마다 직접 구성하면 유연성이 가장 높지만 규모가 커질수록 유지 관리가 어려워집니다. 여러 프로젝트나 그룹에는 공유 스캐너 구성이 관리하기 더 쉬우면서도 필요한 부분에 대한 사용자 정의를 허용합니다.
예를 들어 동일한 보안 스캐닝 구성을 수동으로 적용한 프로젝트가 10개 있다면 한 번의 변경을 10번 반복해야 합니다. 반면 공유 CI/CD 구성을 만들어 두면 같은 변경을 한 번만 수행하면 됩니다.
개별 프로젝트 구성#
개별 프로젝트에서 보안 스캐닝을 구성하는 방법은 다음과 같습니다.
- CI/CD 구성 파일을 편집합니다.
- UI에서 CI/CD 구성을 편집합니다.
CI/CD 파일 사용#
개별 프로젝트의 보안 스캐닝을 수동으로 활성화하는 방법은 다음과 같습니다.
- 개별 보안 스캐너를 활성화합니다.
- AutoDevOps를 사용하여 모든 보안 스캐너를 활성화합니다.
AutoDevOps는 대부분의 보안 스캐너를 가장 적은 노력으로 활성화하는 경로를 제공합니다. 다만 개별 보안 스캐너를 활성화하는 방식에 비해 사용자 정의 선택지가 제한됩니다.
개별 보안 스캐너 활성화#
설정을 사용자 정의하면서 개별 보안 스캐닝 도구를 활성화하려면
.gitlab-ci.yml 파일에 해당 보안 스캐너의 템플릿을 포함합니다.
개별 보안 스캐너를 활성화하는 방법은 각 스캐너의 문서를 참고합니다.
Auto DevOps를 사용한 보안 스캐닝 활성화#
다음 보안 스캐닝 도구를 기본 설정으로 활성화하려면 Auto DevOps를 활성화합니다.
Auto DevOps 자체를 직접 사용자 정의할 수는 없지만
프로젝트의 .gitlab-ci.yml 파일에 Auto DevOps 템플릿을 포함한 다음
필요에 따라 설정을 재정의할 수 있습니다.
UI 사용#
Security configuration 페이지에서 프로젝트의 보안 테스트 및 취약점 관리 설정을 확인하고 구성합니다.
Security testing 탭은 기본 브랜치의 최신 커밋에 있는 CI/CD 파이프라인을 확인하여 각 보안 도구의 상태를 보여 줍니다.
Enabled : 파이프라인 출력에서 보안 테스트 도구의 아티팩트가 발견되었습니다.
Not enabled : CI/CD 파이프라인이 없거나 파이프라인 출력에서 보안 테스트 도구의 아티팩트가 발견되지 않았습니다.
보안 구성 페이지 보기#
사전 요구 사항:
- 프로젝트에 대한 Security Manager, Maintainer 또는 Owner 권한.
프로젝트의 보안 구성을 확인하려면 다음 단계를 수행합니다.
- 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
- 왼쪽 사이드바에서 Secure > Security configuration을 선택합니다.
CI/CD 구성 파일의 변경 이력을 확인하려면 Configuration history를 선택합니다.
프로젝트의 보안 구성 편집#
사전 요구 사항:
- 프로젝트에 대한 Security Manager, Maintainer 또는 Owner 권한.
프로젝트의 보안 구성을 편집하려면 다음 단계를 수행합니다.
- 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
- 왼쪽 사이드바에서 Secure > Security configuration을 선택합니다.
- 활성화하거나 구성할 보안 스캐너를 선택하고 안내를 따릅니다.
개별 보안 스캐너를 활성화하고 구성하는 자세한 방법은 각 스캐너의 문서를 참고합니다.
공유 구성 만들기#
동일한 보안 스캐닝 구성을 여러 프로젝트에 적용하려면 다음 방법 중 하나를 사용합니다.
이 방법들은 보안 스캐닝을 포함한 CI/CD 구성을 한 번만 정의하여 여러 프로젝트와 그룹에 적용합니다. 프로젝트마다 개별적으로 구성하는 방식에 비해 다음과 같은 이점이 있습니다.
- 구성 변경을 프로젝트마다 반복하지 않고 한 번만 수행하면 됩니다.
- 구성을 변경할 수 있는 권한이 제한되어 직무 분리가 이루어집니다.
보안 스캐닝 사용자 정의#
요구 사항과 환경에 맞게 보안 스캐닝을 사용자 정의할 수 있습니다. 개별 보안 스캐너를 사용자 정의하는 방법은 각 스캐너의 문서를 참고합니다.
모범 사례#
보안 스캐닝 구성을 사용자 정의할 때는 다음 사항을 지킵니다.
- 기본 브랜치에 변경 사항을 병합하기 전에 머지 리퀘스트를 사용하여 보안 스캐닝 도구의 모든 사용자 정의를 테스트합니다. 그렇게 하지 않으면 다수의 오탐을 포함한 예기치 않은 결과가 나올 수 있습니다.
- 스캐닝 도구의 CI/CD 템플릿을 include합니다. 템플릿의 내용을 복사하지 않습니다.
- 템플릿의 값은 필요한 경우에만 재정의합니다. 나머지 값은 모두 템플릿에서 상속됩니다.
- 운영 워크플로에는 각 템플릿의 stable 에디션을 사용합니다. stable 에디션은 변경 빈도가 낮고 호환성이 깨지는 변경은 GitLab 메이저 버전 사이에서만 이루어집니다. latest 버전은 최신 변경 사항을 담고 있지만 GitLab 마이너 버전 사이에도 큰 변경이 있을 수 있습니다.
템플릿 에디션#
GitLab 애플리케이션 보안 도구에는 최대 세 가지 템플릿 에디션이 있습니다.
- Stable: stable 템플릿이 기본값입니다. 안정적이고 일관된 애플리케이션 보안 경험을 제공합니다. CI/CD 파이프라인에서 안정성과 예측 가능한 동작이 필요한 대부분의 사용자와 프로젝트는 stable 템플릿을 사용해야 합니다.
- Latest: latest 템플릿은 최신 기능을 먼저 사용하고 테스트하려는 경우를 위한 것입니다.
템플릿 이름에
latest라는 단어가 포함되어 있습니다. 안정 버전으로 간주되지 않으며 다음 메이저 릴리스에 예정된, 호환성이 깨지는 변경이 포함될 수 있습니다. 이 템플릿을 사용하면 새 기능과 업데이트가 stable 릴리스에 포함되기 전에 미리 사용해 볼 수 있습니다. - Versioned: versioned 템플릿에는 stable 템플릿과 하위 호환되지 않는,
호환성이 깨지는 변경이 포함됩니다. versioned 템플릿의 이름에는
v2,v3같은 버전 접미사가 붙습니다. 각 버전은 해당 메이저 버전 안에서는 안정적이지만 호환성이 깨지는 변경이 있으므로 사용자가 직접 선택해 적용해야 합니다. versioned 템플릿을 제공하는 도구는 의존성 스캐닝뿐이며 (Dependency-Scanning.v2.gitlab-ci.yml), 이 템플릿은 SBOM 기반 의존성 스캐닝을 실행합니다. 자세한 내용은 마이그레이션 가이드를 참고합니다.
같은 프로젝트에서 Stable과 Latest 보안 템플릿을 함께 사용하지 않습니다. 서로 다른 보안 템플릿 에디션을 섞어 쓰면 머지 리퀘스트 파이프라인과 브랜치 파이프라인이 모두 실행될 수 있습니다.
기본 레지스트리 기본 주소 재정의#
기본적으로 GitLab 보안 스캐너는 Docker 이미지의 기본 주소로
registry.gitlab.com/security-products를 사용합니다. 대부분의 스캐너는 CI/CD 변수
SECURE_ANALYZERS_PREFIX를 다른 위치로 설정하여 이 값을 재정의할 수 있습니다. 이 설정은 모든 스캐너에 한 번에 적용됩니다.
컨테이너 스캐닝 분석기는 예외이며
SECURE_ANALYZERS_PREFIX 변수를 사용하지 않습니다. 이 분석기의 Docker 이미지를 재정의하는 방법은
오프라인 환경에서 컨테이너 스캐닝 실행
안내를 참고합니다.
머지 리퀘스트 파이프라인에서 보안 스캐닝 도구 사용#
기본적으로 애플리케이션 보안 job은 브랜치 파이프라인에서만 실행되도록 구성되어 있습니다. 머지 리퀘스트 파이프라인에서 사용하려면 다음 중 하나를 수행합니다.
- CI/CD 변수
AST_ENABLE_MR_PIPELINES를"true"로 설정합니다(18.0에서 도입). (권장) - 머지 리퀘스트 파이프라인이 기본으로 활성화된
latest에디션 템플릿을 사용합니다.
예를 들어 머지 리퀘스트 파이프라인을 활성화한 상태에서 SAST와 의존성 스캐닝을 함께 실행하려면 다음 구성을 사용합니다.
include:
- template: Jobs/Dependency-Scanning.v2.gitlab-ci.yml
- template: Jobs/SAST.gitlab-ci.yml
variables:
AST_ENABLE_MR_PIPELINES: "true"
사용자 정의 스캐닝 스테이지 사용#
보안 스캐너 템플릿은 기본적으로 미리 정의된 test Stage를 사용합니다. 다른 Stage에서
실행하려면 .gitlab-ci.yml 파일의 stages: 섹션에 사용자 정의 Stage 이름을
추가합니다.
보안 job 재정의에 대한 자세한 내용은 다음 문서를 참고합니다.
문제 해결#
보안 스캐닝을 구성할 때 다음 문제가 발생할 수 있습니다.
오류: chosen stage test does not exist#
파이프라인을 실행할 때 chosen stage test does not exist 오류가 발생할 수 있습니다.
이 문제는 보안 스캐닝 job이 사용하는 Stage가 .gitlab-ci.yml 파일에 선언되어 있지 않을 때 발생합니다.
이를 해결하려면 다음 중 하나를 수행합니다.
-
.gitlab-ci.yml에testStage를 추가합니다.stages: - test - unit-tests include: - template: Jobs/Dependency-Scanning.v2.gitlab-ci.yml - template: Jobs/SAST.gitlab-ci.yml - template: Jobs/Secret-Detection.gitlab-ci.yml custom job: stage: unit-tests script: - echo "custom job" -
각 보안 job의 기본 Stage를 재정의합니다. 예를 들어 미리 정의된
unit-testsStage를 사용하려면 다음과 같이 구성합니다.stages: - unit-tests include: - template: Jobs/Dependency-Scanning.v2.gitlab-ci.yml inputs: stage: unit-tests - template: Jobs/SAST.gitlab-ci.yml - template: Jobs/Secret-Detection.gitlab-ci.yml sast: stage: unit-tests .secret-analyzer: stage: unit-tests custom job: stage: unit-tests script: - echo "custom job"