Infrastructure as Code 스캔

요약

Infrastructure as Code(IaC) 스캔은 CI/CD 파이프라인에서 실행되며 알려진 취약성에 대해 인프라 정의 파일을 확인합니다. IaC 스캔 분析기는 JSON 형식 보고서를 작업 아티팩트로 출력합니다.

Infrastructure as Code(IaC) 스캔은 CI/CD 파이프라인에서 실행되며 알려진 취약성에 대해 인프라 정의 파일을 확인합니다. 기본 브랜치에 커밋되기 전에 취약성을 식별하여 애플리케이션에 대한 위험을 사전에 처리합니다.

IaC 스캔 분析기는 JSON 형식 보고서를 작업 아티팩트로 출력합니다.

GitLab Ultimate를 사용하면 IaC 스캔 결과도 처리되어 다음을 수행할 수 있습니다:

머지 리퀘스트에서 확인.
승인 워크플로우에 사용.
취약성 보고서에서 검토.

시작하기#

IaC 스캔이 처음인 경우 다음 단계에 따라 프로젝트에서 활성화합니다.

사전 요구사항:

프로젝트에 대한 Maintainer 또는 Owner 역할.
일관된 성능을 보장하기 위해 최소 4GB RAM.
Docker 또는 Kubernetes 실행기가 있는 Linux 기반 GitLab Runner. GitLab.com의 호스팅 러너를 사용하는 경우 Docker 또는 Kubernetes 실행기가 기본적으로 활성화됩니다.
- Windows의 GitLab Runner는 지원되지 않습니다.
- AMD64 이외의 CPU 아키텍처는 지원되지 않습니다.
GitLab CI/CD 구성(.gitlab-ci.yml)은 test 스테이지를 포함해야 합니다. test 스테이지는 기본적으로 포함되지만 스테이지를 재정의하는 경우 명시적으로 추가해야 합니다.

IaC 스캔을 활성화하려면:

상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
빌드 > 파이프라인 편집기로 이동합니다.
IaC 스캔 CI/CD 템플릿 또는 구성요소를 추가합니다.

템플릿을 사용하려면 다음 줄을 추가합니다:
```
include:
  - template: Jobs/SAST-IaC.gitlab-ci.yml
```
CI/CD 구성요소를 사용하려면 다음 줄을 추가합니다:
```
include:
  - component: gitlab.com/components/sast/iac-sast@main
```
유효성 검사 탭을 선택한 다음 파이프라인 유효성 검사를 선택합니다.

시뮬레이션이 성공적으로 완료되었습니다 메시지는 파일이 유효하다는 것을 확인합니다.
편집 탭을 선택합니다.
다음 필드를 완성합니다:
- 커밋 메시지.
- 브랜치. 예를 들어 add-iac.
이 변경 사항으로 새 머지 리퀘스트 시작 체크박스를 선택한 다음 변경 사항 커밋을 선택합니다.

머지 리퀘스트 페이지가 열립니다.
표준 워크플로우에 따라 필드를 완성한 다음 머지 리퀘스트 생성을 선택합니다.
표준 워크플로우에 따라 머지 리퀘스트를 검토하고 편집한 다음 병합을 선택합니다.

이 시점에서 파이프라인에 IaC 스캔이 활성화됩니다:

IaC 스캔 작업은 모든 파이프라인에서 실행되고 KICS 分析기를 실행합니다.
分析기는 프로젝트에 지원되는 IaC 파일이 포함되어 있는지 확인합니다.
지원되는 파일이 발견되면 分析기는 취약성을 스캔합니다.
지원되는 파일이 없으면 작업이 결과 없이 완료됩니다.

해당 작업은 파이프라인의 test 스테이지에 표시됩니다.

IaC 스캔 예제 프로젝트에서 작동하는 예제를 볼 수 있습니다.

다음 단계#

IaC 스캔을 활성화한 후 다음을 수행할 수 있습니다:

결과 이해하기에 대해 더 알아보기
최적화 팁 검토
더 많은 프로젝트로의 도입 계획

결과 이해하기#

사전 요구사항:

프로젝트에 대한 Developer, Maintainer 또는 Owner 역할.

파이프라인에서 취약성을 검토할 수 있습니다:

상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 빌드 > 파이프라인을 선택합니다.
파이프라인을 선택합니다.
보안 탭을 선택합니다.
취약성을 선택하여 다음을 포함한 세부 정보를 봅니다:
- 설명: 취약성의 원인, 잠재적 영향, 권장 수정 단계를 설명합니다.
- 상태: 취약성이 분류되었는지 해결되었는지를 나타냅니다.
- 심각도: 심각도 수준에 대해 자세히 알아보기.
- 위치: 문제가 발견된 파일명과 줄 번호를 표시합니다. 파일 경로를 선택하면 코드 보기에서 해당 줄이 열립니다.
- 스캐너: 취약성을 감지한 分析기를 식별합니다.
- 식별자: CWE 식별자 및 탐지한 규칙의 ID와 같이 취약성을 분류하는 데 사용되는 참조 목록.

Ultimate에서는 보안 스캔 결과를 다운로드할 수도 있습니다:

사전 요구사항:

프로젝트에 대한 Developer, Maintainer 또는 Owner 역할.

상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 빌드 > 파이프라인을 선택합니다.
파이프라인을 선택합니다.
보안 탭을 선택합니다.
파이프라인의 보안 탭에서 결과 다운로드를 선택합니다.

자세한 내용은 파이프라인 보안 보고서를 참조하세요.

Note

결과는 피처 브랜치에서 생성됩니다. 기본 브랜치에 병합되면 취약성이 됩니다. 보안 상태를 평가할 때 이 구분이 중요합니다.

IaC 스캔 결과를 볼 수 있는 추가적인 방법:

머지 리퀘스트 위젯: 새로 도입되거나 해결된 결과를 표시합니다.
머지 리퀘스트 변경 사항 보기: 변경된 줄에 대한 인라인 주석을 표시합니다.
취약성 보고서: 기본 브랜치의 확인된 취약성을 표시합니다.

지원되는 언어 및 프레임워크#

IaC 스캔은 다양한 IaC 구성 파일을 지원합니다. 프로젝트에서 지원되는 구성 파일이 감지되면 KICS를 사용하여 스캔됩니다. 여러 IaC 구성 파일이 혼합된 프로젝트도 지원됩니다.

지원되는 구성 형식:

Ansible
AWS CloudFormation
Azure Resource Manager

[!note] IaC 스캔은 JSON 형식의 Azure Resource Manager 템플릿을 分析할 수 있습니다. Bicep으로 템플릿을 작성하는 경우 IaC 스캔이 分析할 수 있도록 Bicep CLI를 사용하여 Bicep 파일을 JSON으로 변환해야 합니다.
Dockerfile
Google Deployment Manager
Kubernetes
OpenAPI
Terraform

[!note] 사용자 정의 레지스트리의 Terraform 모듈은 취약성 스캔이 되지 않습니다. 제안된 기능에 대한 자세한 내용은 이슈 357004를 참조하세요.

IaC 스캔 최적화#

IaC 스캔을 최적화하여 노이즈를 줄이고 관련 결과에 집중할 수 있습니다:

sast-ruleset.toml 파일을 사용하여 특정 규칙을 비활성화합니다.
sast-ruleset.toml 파일을 사용하여 규칙 속성(심각도 등)을 재정의합니다.
해당 파일의 KICS 어노테이션을 사용하여 특정 파일 스캔을 비활성화합니다.

규칙을 비활성화하거나 규칙 속성을 재정의하려면 sast-ruleset.toml 파일을 사용합니다. 이 방법은 다음을 제공합니다:

규칙이 비활성화될 때 기존 결과를 자동으로 해결하기 위한 GitLab 취약성 관리와의 통합.
보안 정책 결정에 대한 버전 관리 문서.
IaC 스캔을 도입할 때 여러 프로젝트에서 룰셋을 공유하고 재사용하는 옵션.

룰셋 정의#

모든 IaC 스캔 규칙은 다음을 포함하는 ruleset 섹션에 포함되어 있습니다:

규칙의 type 필드. IaC 스캔의 경우 식별자 유형은 kics_id입니다.
규칙 식별자의 value 필드. KICS 규칙 식별자는 영숫자 문자열입니다. 규칙 식별자를 찾으려면:
- JSON 보고서 아티팩트에서 찾습니다.
- KICS 쿼리 목록에서 규칙 이름을 검색하고 표시되는 영숫자 식별자를 복사합니다. 규칙 이름은 규칙 위반이 감지될 때 취약성 세부 정보 페이지에 표시됩니다.

규칙 비활성화#

특정 IaC 스캔 규칙을 비활성화할 수 있습니다. 비활성화된 규칙에 의해 이전에 감지된 결과는 자동으로 해결됩니다.

사전 요구사항:

프로젝트에 대한 Maintainer 또는 Owner 역할.

分析기 규칙을 비활성화하려면:

루트 프로젝트에 .gitlab 디렉토리가 없는 경우 생성합니다.
.gitlab 디렉토리에 sast-ruleset.toml이라는 사용자 정의 룰셋 파일이 없는 경우 생성합니다.
ruleset 섹션의 컨텍스트에서 disabled 플래그를 true로 설정합니다.
하나 이상의 ruleset 하위 섹션에서 비활성화할 규칙을 나열합니다.

sast-ruleset.toml 파일을 기본 브랜치에 병합한 후 비활성화된 규칙에 대한 기존 결과는 자동으로 해결됩니다.

다음 예제 sast-ruleset.toml 파일에서 비활성화된 규칙은 식별자의 type과 value를 일치시켜 kics 分析기에 할당됩니다:

[kics]
  [[kics.ruleset]]
    disable = true
    [kics.ruleset.identifier]
      type = "kics_id"
      value = "8212e2d7-e683-49bc-bf78-d6799075c5a7"

  [[kics.ruleset]]
    disable = true
    [kics.ruleset.identifier]
      type = "kics_id"
      value = "b03a748a-542d-44f4-bb86-9199ab4fd2d5"

파일 스캔 비활성화#

파일의 스캔을 완전히 또는 특정 규칙에 대해서만 비활성화하려면 해당 파일에서 KICS 어노테이션을 사용합니다.

이 기능은 일부 IaC 파일 유형에서만 사용할 수 있습니다. 지원되는 파일 유형 목록은 KICS 문서를 참조하세요.

전체 파일 스캔을 건너뛰려면 파일 맨 위에 # kics-scan ignore를 주석으로 추가합니다.
전체 파일에서 특정 규칙을 비활성화하려면 파일 맨 위에 # kics-scan disable=<kics_id>를 주석으로 추가합니다.

규칙 재정의#

특정 IaC 스캔 규칙을 사용자 정의하기 위해 재정의할 수 있습니다. 예를 들어 규칙에 더 낮은 심각도를 할당하거나 결과를 수정하는 방법에 대한 자체 문서에 링크합니다.

사전 요구사항:

프로젝트에 대한 Maintainer 또는 Owner 역할.

규칙을 재정의하려면:

루트 프로젝트에 .gitlab 디렉토리가 없는 경우 생성합니다.
.gitlab 디렉토리에 sast-ruleset.toml이라는 사용자 정의 룰셋 파일이 없는 경우 생성합니다.
하나 이상의 ruleset.identifier 하위 섹션에서 재정의할 규칙을 나열합니다.
ruleset 섹션의 ruleset.override 컨텍스트에서 재정의할 키를 제공합니다. 키의 어떤 조합도 재정의할 수 있습니다. 유효한 키는 다음과 같습니다:
- description
- message
- name
- severity (유효한 옵션: Critical, High, Medium, Low, Unknown, Info)

다음 예제 sast-ruleset.toml 파일에서 규칙은 식별자의 type과 value로 매칭되고 재정의됩니다:

[kics]
  [[kics.ruleset]]
    [kics.ruleset.identifier]
      type = "kics_id"
      value = "8212e2d7-e683-49bc-bf78-d6799075c5a7"
    [kics.ruleset.override]
      description = "OVERRIDDEN description"
      message = "OVERRIDDEN message"
      name = "OVERRIDDEN name"
      severity = "Info"

오프라인 구성#

오프라인 환경은 인터넷을 통한 외부 리소스에 대한 제한적이거나 간헐적인 접근이 있습니다. 이러한 환경의 인스턴스에서 IaC는 일부 구성 변경이 필요합니다. 이 섹션의 지침은 오프라인 환경에 자세히 설명된 지침과 함께 완료해야 합니다.

GitLab Runner 구성#

기본적으로 실행기는 로컬 복사본이 있더라도 GitLab 컨테이너 레지스트리에서 Docker 이미지를 가져오려 합니다. Docker 이미지를 최신 상태로 유지하려면 이 기본 설정을 사용해야 합니다. 그러나 네트워크 연결이 없는 경우 기본 GitLab Runner pull_policy 변수를 변경해야 합니다.

GitLab Runner CI/CD 변수 pull_policy를 if-not-present로 구성합니다.

로컬 IaC 分析기 이미지 사용#

GitLab 컨테이너 레지스트리 대신 로컬 Docker 레지스트리에서 이미지를 가져오려면 로컬 IaC 分析기 이미지를 사용합니다.

사전 요구사항:

프로젝트에 대한 Maintainer 또는 Owner 역할.
Docker 이미지를 로컬 오프라인 Docker 레지스트리로 가져오는 것은 네트워크 보안 정책에 따라 다릅니다. IT 직원과 상담하여 외부 리소스를 가져오거나 일시적으로 액세스하는 데 허용되고 승인된 프로세스를 찾으세요.

로컬 IaC 分析기 이미지를 사용하려면:

registry.gitlab.com에서 기본 IaC 分析기 이미지를 로컬 Docker 컨테이너 레지스트리로 가져옵니다:
```
registry.gitlab.com/security-products/kics:6
```
IaC 分析기의 이미지는 주기적으로 업데이트되므로 로컬 복사본을 주기적으로 업데이트해야 합니다.

CI/CD 변수 SECURE_ANALYZERS_PREFIX를 로컬 Docker 컨테이너 레지스트리로 설정합니다.

include:
  - template: Jobs/SAST-IaC.gitlab-ci.yml

variables:
  SECURE_ANALYZERS_PREFIX: "localhost:5000/analyzers"

이제 IaC 작업은 인터넷 접근 없이 分析기 Docker 이미지의 로컬 복사본을 사용해야 합니다.

특정 分析기 버전 사용#

GitLab 관리 CI/CD 템플릿은 주요 버전을 지정하고 해당 주요 버전에서 최신 分析기 릴리스를 자동으로 가져옵니다. 경우에 따라 특정 버전을 사용해야 할 수 있습니다. 예를 들어 나중 릴리스의 회귀를 방지해야 할 수 있습니다.

사전 요구사항:

프로젝트에 대한 Maintainer 또는 Owner 역할.

특정 分析기 버전을 사용하려면:

상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 빌드 > 파이프라인 편집기를 선택합니다.
SAST-IaC.gitlab-ci.yml 템플릿을 포함하는 줄 뒤에 SAST_ANALYZER_IMAGE_TAG CI/CD 변수를 추가합니다.

[!note] 이 변수는 특정 작업에서만 설정하세요. 최상위 수준에서 설정하면 설정한 버전이 다른 SAST 分析기에도 사용됩니다.

태그를 다음으로 설정합니다:
- 3과 같은 주요 버전. 파이프라인은 이 주요 버전에서 릴리스되는 마이너 또는 패치 업데이트를 사용합니다.
- 3.7과 같은 마이너 버전. 파이프라인은 이 마이너 버전에서 릴리스되는 패치 업데이트를 사용합니다.
- 3.7.0과 같은 패치 버전. 파이프라인은 업데이트를 받지 않습니다.

이 예제는 IaC 分析기의 특정 마이너 버전을 사용합니다:

include:
  - template: Jobs/SAST-IaC.gitlab-ci.yml

kics-iac-sast:
  variables:
    SAST_ANALYZER_IMAGE_TAG: "3.1"

지원되는 배포판#

GitLab 스캐너는 크기와 유지 관리성을 위해 기본 Alpine 이미지로 제공됩니다.

FIPS 지원 이미지 사용#

GitLab은 표준 이미지 외에도 스캐너 이미지의 FIPS 지원 Red Hat UBI 버전을 제공합니다.

파이프라인에서 FIPS 지원 이미지를 사용하려면 SAST_IMAGE_SUFFIX를 -fips로 설정하거나 표준 태그에 -fips 확장자를 추가합니다.

다음 예제는 SAST_IMAGE_SUFFIX CI/CD 변수를 사용합니다.

variables:
  SAST_IMAGE_SUFFIX: '-fips'

include:
  - template: Jobs/SAST-IaC.gitlab-ci.yml

자동 취약성 해결#

히스토리

GitLab 15.9에서 sec_mark_dropped_findings_as_resolved라는 프로젝트 수준 플래그와 함께 도입됨.
GitLab 16.2에서 일반 가용성. 기능 플래그 sec_mark_dropped_findings_as_resolved 제거됨.

여전히 관련 있는 취약성에 집중할 수 있도록 IaC 스캔은 다음 경우에 취약성을 자동으로 해결합니다:

미리 정의된 규칙을 비활성화할 때.
기본 룰셋에서 규칙을 제거할 때.

나중에 규칙을 다시 활성화하면 결과가 분류를 위해 다시 열립니다.

취약성 관리 시스템은 취약성을 자동으로 해결할 때 메모를 추가합니다.

보고서 JSON 형식#

IaC 스캐너는 기존 SAST 보고서 형식으로 JSON 보고서 파일을 출력합니다. 자세한 내용은 이 보고서의 스키마를 참조하세요.

JSON 보고서 파일은 다음에서 다운로드할 수 있습니다:

CI/CD 파이프라인 페이지.
artifacts: paths를 gl-sast-report.json으로 설정하여 머지 리퀘스트의 파이프라인 탭.

자세한 내용은 아티팩트 다운로드를 참조하세요.

도입#

한 프로젝트에 대한 IaC 스캔 결과를 검증한 후 추가 프로젝트에 동일한 접근 방식을 구현할 수 있습니다.

스캔 실행 강제를 사용하여 그룹 전반에 IaC 스캔 설정을 적용합니다.
원격 구성 파일 지정으로 중앙 룰셋을 공유하고 재사용합니다.

트러블슈팅#

IaC 스캔 작업 시 다음과 같은 문제가 발생할 수 있습니다.

IaC 스캔 결과가 예기치 않게 `더 이상 감지되지 않음`으로 표시#

이전에 감지된 결과가 예기치 않게 더 이상 감지되지 않음으로 표시되는 경우 스캐너 업데이트 때문일 수 있습니다. 업데이트로 인해 비효과적이거나 거짓 양성으로 발견된 규칙이 비활성화될 수 있으며 결과가 더 이상 감지되지 않음으로 표시됩니다.

작업 로그의 `exec /bin/sh: exec format error` 메시지#

exec /bin/sh: exec format error가 나타나는 작업 로그에 오류가 있을 수 있습니다. 이 문제는 AMD64 이외의 아키텍처에서 IaC 스캔 分析기를 실행하려 할 때 발생합니다. IaC 스캔 사전 요구사항에 대한 자세한 내용은 사전 요구사항을 참조하세요.

Infrastructure as Code 스캔

Tier: Premium, Ultimate
Offering: GitLab Self-Managed

원문 보기

번역일: 2026-05-22

요약

IaC 스캔 분析기는 JSON 형식 보고서를 작업 아티팩트로 출력합니다.

GitLab Ultimate를 사용하면 IaC 스캔 결과도 처리되어 다음을 수행할 수 있습니다:

머지 리퀘스트에서 확인.
승인 워크플로우에 사용.
취약성 보고서에서 검토.

시작하기#

IaC 스캔이 처음인 경우 다음 단계에 따라 프로젝트에서 활성화합니다.

사전 요구사항:

프로젝트에 대한 Maintainer 또는 Owner 역할.
일관된 성능을 보장하기 위해 최소 4GB RAM.
Docker 또는 Kubernetes 실행기가 있는 Linux 기반 GitLab Runner. GitLab.com의 호스팅 러너를 사용하는 경우 Docker 또는 Kubernetes 실행기가 기본적으로 활성화됩니다.
- Windows의 GitLab Runner는 지원되지 않습니다.
- AMD64 이외의 CPU 아키텍처는 지원되지 않습니다.
GitLab CI/CD 구성(.gitlab-ci.yml)은 test 스테이지를 포함해야 합니다. test 스테이지는 기본적으로 포함되지만 스테이지를 재정의하는 경우 명시적으로 추가해야 합니다.

IaC 스캔을 활성화하려면:

상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
빌드 > 파이프라인 편집기로 이동합니다.
IaC 스캔 CI/CD 템플릿 또는 구성요소를 추가합니다.

템플릿을 사용하려면 다음 줄을 추가합니다:
```
include:
  - template: Jobs/SAST-IaC.gitlab-ci.yml
```
CI/CD 구성요소를 사용하려면 다음 줄을 추가합니다:
```
include:
  - component: gitlab.com/components/sast/iac-sast@main
```
유효성 검사 탭을 선택한 다음 파이프라인 유효성 검사를 선택합니다.

시뮬레이션이 성공적으로 완료되었습니다 메시지는 파일이 유효하다는 것을 확인합니다.
편집 탭을 선택합니다.
다음 필드를 완성합니다:
- 커밋 메시지.
- 브랜치. 예를 들어 add-iac.
이 변경 사항으로 새 머지 리퀘스트 시작 체크박스를 선택한 다음 변경 사항 커밋을 선택합니다.

머지 리퀘스트 페이지가 열립니다.
표준 워크플로우에 따라 필드를 완성한 다음 머지 리퀘스트 생성을 선택합니다.
표준 워크플로우에 따라 머지 리퀘스트를 검토하고 편집한 다음 병합을 선택합니다.

이 시점에서 파이프라인에 IaC 스캔이 활성화됩니다:

IaC 스캔 작업은 모든 파이프라인에서 실행되고 KICS 分析기를 실행합니다.
分析기는 프로젝트에 지원되는 IaC 파일이 포함되어 있는지 확인합니다.
지원되는 파일이 발견되면 分析기는 취약성을 스캔합니다.
지원되는 파일이 없으면 작업이 결과 없이 완료됩니다.

해당 작업은 파이프라인의 test 스테이지에 표시됩니다.

IaC 스캔 예제 프로젝트에서 작동하는 예제를 볼 수 있습니다.

다음 단계#

IaC 스캔을 활성화한 후 다음을 수행할 수 있습니다:

결과 이해하기에 대해 더 알아보기
최적화 팁 검토
더 많은 프로젝트로의 도입 계획

결과 이해하기#

사전 요구사항:

프로젝트에 대한 Developer, Maintainer 또는 Owner 역할.

파이프라인에서 취약성을 검토할 수 있습니다:

상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 빌드 > 파이프라인을 선택합니다.
파이프라인을 선택합니다.
보안 탭을 선택합니다.
취약성을 선택하여 다음을 포함한 세부 정보를 봅니다:
- 설명: 취약성의 원인, 잠재적 영향, 권장 수정 단계를 설명합니다.
- 상태: 취약성이 분류되었는지 해결되었는지를 나타냅니다.
- 심각도: 심각도 수준에 대해 자세히 알아보기.
- 위치: 문제가 발견된 파일명과 줄 번호를 표시합니다. 파일 경로를 선택하면 코드 보기에서 해당 줄이 열립니다.
- 스캐너: 취약성을 감지한 分析기를 식별합니다.
- 식별자: CWE 식별자 및 탐지한 규칙의 ID와 같이 취약성을 분류하는 데 사용되는 참조 목록.

Ultimate에서는 보안 스캔 결과를 다운로드할 수도 있습니다:

사전 요구사항:

프로젝트에 대한 Developer, Maintainer 또는 Owner 역할.

상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 빌드 > 파이프라인을 선택합니다.
파이프라인을 선택합니다.
보안 탭을 선택합니다.
파이프라인의 보안 탭에서 결과 다운로드를 선택합니다.

자세한 내용은 파이프라인 보안 보고서를 참조하세요.

Note

결과는 피처 브랜치에서 생성됩니다. 기본 브랜치에 병합되면 취약성이 됩니다. 보안 상태를 평가할 때 이 구분이 중요합니다.

IaC 스캔 결과를 볼 수 있는 추가적인 방법:

머지 리퀘스트 위젯: 새로 도입되거나 해결된 결과를 표시합니다.
머지 리퀘스트 변경 사항 보기: 변경된 줄에 대한 인라인 주석을 표시합니다.
취약성 보고서: 기본 브랜치의 확인된 취약성을 표시합니다.

지원되는 언어 및 프레임워크#

지원되는 구성 형식:

Ansible
AWS CloudFormation
Azure Resource Manager

[!note] IaC 스캔은 JSON 형식의 Azure Resource Manager 템플릿을 分析할 수 있습니다. Bicep으로 템플릿을 작성하는 경우 IaC 스캔이 分析할 수 있도록 Bicep CLI를 사용하여 Bicep 파일을 JSON으로 변환해야 합니다.
Dockerfile
Google Deployment Manager
Kubernetes
OpenAPI
Terraform

[!note] 사용자 정의 레지스트리의 Terraform 모듈은 취약성 스캔이 되지 않습니다. 제안된 기능에 대한 자세한 내용은 이슈 357004를 참조하세요.

IaC 스캔 최적화#

IaC 스캔을 최적화하여 노이즈를 줄이고 관련 결과에 집중할 수 있습니다:

sast-ruleset.toml 파일을 사용하여 특정 규칙을 비활성화합니다.
sast-ruleset.toml 파일을 사용하여 규칙 속성(심각도 등)을 재정의합니다.
해당 파일의 KICS 어노테이션을 사용하여 특정 파일 스캔을 비활성화합니다.

규칙을 비활성화하거나 규칙 속성을 재정의하려면 sast-ruleset.toml 파일을 사용합니다. 이 방법은 다음을 제공합니다:

규칙이 비활성화될 때 기존 결과를 자동으로 해결하기 위한 GitLab 취약성 관리와의 통합.
보안 정책 결정에 대한 버전 관리 문서.
IaC 스캔을 도입할 때 여러 프로젝트에서 룰셋을 공유하고 재사용하는 옵션.

룰셋 정의#

모든 IaC 스캔 규칙은 다음을 포함하는 ruleset 섹션에 포함되어 있습니다:

규칙의 type 필드. IaC 스캔의 경우 식별자 유형은 kics_id입니다.
규칙 식별자의 value 필드. KICS 규칙 식별자는 영숫자 문자열입니다. 규칙 식별자를 찾으려면:
- JSON 보고서 아티팩트에서 찾습니다.
- KICS 쿼리 목록에서 규칙 이름을 검색하고 표시되는 영숫자 식별자를 복사합니다. 규칙 이름은 규칙 위반이 감지될 때 취약성 세부 정보 페이지에 표시됩니다.

규칙 비활성화#

특정 IaC 스캔 규칙을 비활성화할 수 있습니다. 비활성화된 규칙에 의해 이전에 감지된 결과는 자동으로 해결됩니다.

사전 요구사항:

프로젝트에 대한 Maintainer 또는 Owner 역할.

分析기 규칙을 비활성화하려면:

루트 프로젝트에 .gitlab 디렉토리가 없는 경우 생성합니다.
.gitlab 디렉토리에 sast-ruleset.toml이라는 사용자 정의 룰셋 파일이 없는 경우 생성합니다.
ruleset 섹션의 컨텍스트에서 disabled 플래그를 true로 설정합니다.
하나 이상의 ruleset 하위 섹션에서 비활성화할 규칙을 나열합니다.

sast-ruleset.toml 파일을 기본 브랜치에 병합한 후 비활성화된 규칙에 대한 기존 결과는 자동으로 해결됩니다.

다음 예제 sast-ruleset.toml 파일에서 비활성화된 규칙은 식별자의 type과 value를 일치시켜 kics 分析기에 할당됩니다:

[kics]
  [[kics.ruleset]]
    disable = true
    [kics.ruleset.identifier]
      type = "kics_id"
      value = "8212e2d7-e683-49bc-bf78-d6799075c5a7"

  [[kics.ruleset]]
    disable = true
    [kics.ruleset.identifier]
      type = "kics_id"
      value = "b03a748a-542d-44f4-bb86-9199ab4fd2d5"

파일 스캔 비활성화#

파일의 스캔을 완전히 또는 특정 규칙에 대해서만 비활성화하려면 해당 파일에서 KICS 어노테이션을 사용합니다.

이 기능은 일부 IaC 파일 유형에서만 사용할 수 있습니다. 지원되는 파일 유형 목록은 KICS 문서를 참조하세요.

전체 파일 스캔을 건너뛰려면 파일 맨 위에 # kics-scan ignore를 주석으로 추가합니다.
전체 파일에서 특정 규칙을 비활성화하려면 파일 맨 위에 # kics-scan disable=<kics_id>를 주석으로 추가합니다.

규칙 재정의#

사전 요구사항:

프로젝트에 대한 Maintainer 또는 Owner 역할.

규칙을 재정의하려면:

루트 프로젝트에 .gitlab 디렉토리가 없는 경우 생성합니다.
.gitlab 디렉토리에 sast-ruleset.toml이라는 사용자 정의 룰셋 파일이 없는 경우 생성합니다.
하나 이상의 ruleset.identifier 하위 섹션에서 재정의할 규칙을 나열합니다.
ruleset 섹션의 ruleset.override 컨텍스트에서 재정의할 키를 제공합니다. 키의 어떤 조합도 재정의할 수 있습니다. 유효한 키는 다음과 같습니다:
- description
- message
- name
- severity (유효한 옵션: Critical, High, Medium, Low, Unknown, Info)

다음 예제 sast-ruleset.toml 파일에서 규칙은 식별자의 type과 value로 매칭되고 재정의됩니다:

[kics]
  [[kics.ruleset]]
    [kics.ruleset.identifier]
      type = "kics_id"
      value = "8212e2d7-e683-49bc-bf78-d6799075c5a7"
    [kics.ruleset.override]
      description = "OVERRIDDEN description"
      message = "OVERRIDDEN message"
      name = "OVERRIDDEN name"
      severity = "Info"

오프라인 구성#

GitLab Runner 구성#

GitLab Runner CI/CD 변수 pull_policy를 if-not-present로 구성합니다.

로컬 IaC 分析기 이미지 사용#

GitLab 컨테이너 레지스트리 대신 로컬 Docker 레지스트리에서 이미지를 가져오려면 로컬 IaC 分析기 이미지를 사용합니다.

사전 요구사항:

프로젝트에 대한 Maintainer 또는 Owner 역할.
Docker 이미지를 로컬 오프라인 Docker 레지스트리로 가져오는 것은 네트워크 보안 정책에 따라 다릅니다. IT 직원과 상담하여 외부 리소스를 가져오거나 일시적으로 액세스하는 데 허용되고 승인된 프로세스를 찾으세요.

로컬 IaC 分析기 이미지를 사용하려면:

registry.gitlab.com에서 기본 IaC 分析기 이미지를 로컬 Docker 컨테이너 레지스트리로 가져옵니다:
```
registry.gitlab.com/security-products/kics:6
```
IaC 分析기의 이미지는 주기적으로 업데이트되므로 로컬 복사본을 주기적으로 업데이트해야 합니다.

CI/CD 변수 SECURE_ANALYZERS_PREFIX를 로컬 Docker 컨테이너 레지스트리로 설정합니다.

include:
  - template: Jobs/SAST-IaC.gitlab-ci.yml

variables:
  SECURE_ANALYZERS_PREFIX: "localhost:5000/analyzers"

이제 IaC 작업은 인터넷 접근 없이 分析기 Docker 이미지의 로컬 복사본을 사용해야 합니다.

특정 分析기 버전 사용#

사전 요구사항:

프로젝트에 대한 Maintainer 또는 Owner 역할.

특정 分析기 버전을 사용하려면:

상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 빌드 > 파이프라인 편집기를 선택합니다.
SAST-IaC.gitlab-ci.yml 템플릿을 포함하는 줄 뒤에 SAST_ANALYZER_IMAGE_TAG CI/CD 변수를 추가합니다.

[!note] 이 변수는 특정 작업에서만 설정하세요. 최상위 수준에서 설정하면 설정한 버전이 다른 SAST 分析기에도 사용됩니다.

태그를 다음으로 설정합니다:
- 3과 같은 주요 버전. 파이프라인은 이 주요 버전에서 릴리스되는 마이너 또는 패치 업데이트를 사용합니다.
- 3.7과 같은 마이너 버전. 파이프라인은 이 마이너 버전에서 릴리스되는 패치 업데이트를 사용합니다.
- 3.7.0과 같은 패치 버전. 파이프라인은 업데이트를 받지 않습니다.

이 예제는 IaC 分析기의 특정 마이너 버전을 사용합니다:

include:
  - template: Jobs/SAST-IaC.gitlab-ci.yml

kics-iac-sast:
  variables:
    SAST_ANALYZER_IMAGE_TAG: "3.1"

지원되는 배포판#

GitLab 스캐너는 크기와 유지 관리성을 위해 기본 Alpine 이미지로 제공됩니다.

FIPS 지원 이미지 사용#

GitLab은 표준 이미지 외에도 스캐너 이미지의 FIPS 지원 Red Hat UBI 버전을 제공합니다.

파이프라인에서 FIPS 지원 이미지를 사용하려면 SAST_IMAGE_SUFFIX를 -fips로 설정하거나 표준 태그에 -fips 확장자를 추가합니다.

다음 예제는 SAST_IMAGE_SUFFIX CI/CD 변수를 사용합니다.

variables:
  SAST_IMAGE_SUFFIX: '-fips'

include:
  - template: Jobs/SAST-IaC.gitlab-ci.yml

자동 취약성 해결#

히스토리

GitLab 15.9에서 sec_mark_dropped_findings_as_resolved라는 프로젝트 수준 플래그와 함께 도입됨.
GitLab 16.2에서 일반 가용성. 기능 플래그 sec_mark_dropped_findings_as_resolved 제거됨.

여전히 관련 있는 취약성에 집중할 수 있도록 IaC 스캔은 다음 경우에 취약성을 자동으로 해결합니다:

미리 정의된 규칙을 비활성화할 때.
기본 룰셋에서 규칙을 제거할 때.

나중에 규칙을 다시 활성화하면 결과가 분류를 위해 다시 열립니다.

취약성 관리 시스템은 취약성을 자동으로 해결할 때 메모를 추가합니다.

보고서 JSON 형식#

IaC 스캐너는 기존 SAST 보고서 형식으로 JSON 보고서 파일을 출력합니다. 자세한 내용은 이 보고서의 스키마를 참조하세요.

JSON 보고서 파일은 다음에서 다운로드할 수 있습니다:

CI/CD 파이프라인 페이지.
artifacts: paths를 gl-sast-report.json으로 설정하여 머지 리퀘스트의 파이프라인 탭.

자세한 내용은 아티팩트 다운로드를 참조하세요.

도입#

한 프로젝트에 대한 IaC 스캔 결과를 검증한 후 추가 프로젝트에 동일한 접근 방식을 구현할 수 있습니다.

스캔 실행 강제를 사용하여 그룹 전반에 IaC 스캔 설정을 적용합니다.
원격 구성 파일 지정으로 중앙 룰셋을 공유하고 재사용합니다.

트러블슈팅#

IaC 스캔 작업 시 다음과 같은 문제가 발생할 수 있습니다.

Infrastructure as Code 스캔

시작하기#

다음 단계#

결과 이해하기#

지원되는 언어 및 프레임워크#

IaC 스캔 최적화#

룰셋 정의#

규칙 비활성화#

파일 스캔 비활성화#

규칙 재정의#

오프라인 구성#

GitLab Runner 구성#

로컬 IaC 分析기 이미지 사용#

특정 分析기 버전 사용#

지원되는 배포판#

FIPS 지원 이미지 사용#

자동 취약성 해결#

보고서 JSON 형식#

도입#

트러블슈팅#

IaC 스캔 결과가 예기치 않게 더 이상 감지되지 않음으로 표시#

작업 로그의 exec /bin/sh: exec format error 메시지#

시작하기#

다음 단계#

결과 이해하기#

지원되는 언어 및 프레임워크#

IaC 스캔 최적화#

룰셋 정의#

규칙 비활성화#

파일 스캔 비활성화#

규칙 재정의#

오프라인 구성#

GitLab Runner 구성#

로컬 IaC 分析기 이미지 사용#

특정 分析기 버전 사용#

지원되는 배포판#

FIPS 지원 이미지 사용#

자동 취약성 해결#

보고서 JSON 형식#

도입#

트러블슈팅#

IaC 스캔 결과가 예기치 않게 더 이상 감지되지 않음으로 표시#

작업 로그의 exec /bin/sh: exec format error 메시지#

IaC 스캔 결과가 예기치 않게 `더 이상 감지되지 않음`으로 표시#

작업 로그의 `exec /bin/sh: exec format error` 메시지#

IaC 스캔 결과가 예기치 않게 `더 이상 감지되지 않음`으로 표시#

작업 로그의 `exec /bin/sh: exec format error` 메시지#