정적 애플리케이션 보안 테스팅(SAST)은 소스 코드의 취약점을 프로덕션에 도달하기 전에 찾아냅니다. CI/CD 파이프라인에 직접 통합되어, 수정이 가장 쉽고 비용도 가장 적게 드는 개발 단계에서 보안 문제를 식별합니다.

개발 후반에 발견되는 보안 취약점은 비용이 큰 지연과 침해 위험으로 이어집니다. SAST 스캔은 커밋마다 자동으로 실행되므로, 워크플로를 방해하지 않고 즉시 피드백을 받을 수 있습니다.

GitLab Duo로 거짓 양성 감소 및 취약점 해결#

SAST 스캐너는 취약점 리포트에 노이즈를 만드는 거짓 양성을 생성할 수 있습니다. GitLab Duo는 취약점 관리를 지원합니다.

거짓 양성 탐지#

GitLab Duo 거짓 양성 탐지는 심각도가 Critical 및 High인 SAST 취약점을 자동으로 분석해 거짓 양성일 가능성이 높은 항목을 식별합니다. 이로써 보안 팀은 실제 취약점에 집중하고 수동 분류에 드는 시간을 줄일 수 있습니다.

GitLab Duo 애드온을 보유한 Ultimate 티어 고객의 경우, 거짓 양성 탐지는 보안 스캔이 끝날 때마다 자동으로 실행되며 평가마다 신뢰도 점수와 설명을 함께 제공합니다.

에이전틱 SAST 취약점 해결#

에이전틱 SAST 취약점 해결은 심각도가 High 및 Critical인 SAST 취약점에 대해 컨텍스트를 반영한 코드 수정이 담긴 머지 리퀘스트를 자동으로 생성합니다. 이 에이전틱 방식은 멀티샷 추론으로 사람의 개입을 최소화하면서 취약점을 해결합니다.

Ultimate 티어 고객의 경우, 취약점이 특정 조건을 충족하면 보안 스캔이 끝날 때마다 에이전틱 취약점 해결이 자동으로 실행됩니다.

기능#

다음 표는 각 기능을 사용할 수 있는 GitLab 티어를 정리한 것입니다.

시작하기#

UI를 사용하거나 프로젝트의 GitLab CI/CD 구성 파일을 편집하여 프로젝트에서 SAST를 활성화합니다.

UI를 사용하여 SAST 활성화#

UI를 사용하여 기본 설정 또는 커스터마이징을 적용해 SAST를 활성화하고 구성할 수 있습니다. 사용할 수 있는 방법은 GitLab 라이선스 티어에 따라 다릅니다.

커스터마이징을 사용하여 SAST 활성화#

사전 요구 사항:

• 프로젝트에 대한 Maintainer 또는 Owner 권한.
• Docker 또는 Kubernetes 실행기를 사용하는 Linux 기반 GitLab Runner. GitLab.com의 호스팅 러너를 사용하는 경우 Docker 또는 Kubernetes 실행기가 기본적으로 활성화되어 있습니다.
  • Windows 러너에서 실행되는 GitLab Runner는 지원되지 않습니다.
  • AMD64 이외의 CPU 아키텍처는 지원되지 않습니다.
• GitLab CI/CD 구성(.gitlab-ci.yml)에 test stage가 포함되어야 하며, 기본적으로 포함되어 있습니다. .gitlab-ci.yml 파일에서 stage를 재정의하는 경우 test stage가 필요합니다.

커스터마이징을 적용해 SAST를 활성화하고 구성하려면 다음을 수행합니다:

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.

2. 왼쪽 사이드바에서 Secure > Security configuration을 선택합니다.

3. 프로젝트 기본 브랜치의 최신 파이프라인이 완료되어 유효한 SAST 아티팩트를 생성했다면 Configure SAST를 선택하고, 그렇지 않으면 정적 애플리케이션 보안 테스팅(SAST) 행에서 Enable SAST를 선택합니다.

4. 사용자 지정 SAST 값을 입력합니다.

   사용자 지정 값은 .gitlab-ci.yml 파일에 저장됩니다. SAST 구성 페이지에 없는 CI/CD 변수는 GitLab SAST 템플릿의 값을 상속합니다.

5. Create merge request를 선택합니다.

6. 머지 리퀘스트를 검토하고 머지합니다.

이제 파이프라인에 SAST job이 포함됩니다. 지원되는 소스 코드가 있으면 파이프라인 실행 시 해당 분석기와 기본 규칙이 자동으로 취약점을 스캔합니다. 해당 job은 프로젝트 파이프라인의 test stage 아래에 표시됩니다.

기본 설정만으로 SAST 활성화#

사전 요구 사항:

• 프로젝트에 대한 Maintainer 또는 Owner 권한.
• Docker 또는 Kubernetes 실행기를 사용하는 Linux 기반 GitLab Runner. GitLab.com의 호스팅 러너를 사용하는 경우 Docker 또는 Kubernetes 실행기가 기본적으로 활성화되어 있습니다.
  • Windows 러너에서 실행되는 GitLab Runner는 지원되지 않습니다.
  • AMD64 이외의 CPU 아키텍처는 지원되지 않습니다.
• GitLab CI/CD 구성(.gitlab-ci.yml)에 test stage가 포함되어야 하며, 기본적으로 포함되어 있습니다. .gitlab-ci.yml 파일에서 stage를 재정의하는 경우 test stage가 필요합니다.

기본 설정으로 SAST를 활성화하고 구성하려면 다음을 수행합니다:

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.

2. 왼쪽 사이드바에서 Secure > Security configuration을 선택합니다.

3. SAST 섹션에서 Configure with a merge request를 선택합니다.

   머지 리퀘스트 페이지가 열립니다.

4. 필드를 입력합니다.

5. Create merge request를 선택합니다.

6. SAST를 활성화하려면 머지 리퀘스트를 검토하고 머지합니다.

이제 파이프라인에 SAST job이 포함됩니다. 지원되는 소스 코드가 있으면 파이프라인 실행 시 해당 분석기와 기본 규칙이 자동으로 취약점을 스캔합니다. 해당 job은 프로젝트 파이프라인의 test stage 아래에 표시됩니다.

CI/CD 파일을 편집하여 SAST 활성화#

사전 요구 사항:

• 프로젝트에 대한 Developer, Maintainer 또는 Owner 권한.
• Docker 또는 Kubernetes 실행기를 사용하는 Linux 기반 GitLab Runner. GitLab.com의 호스팅 러너를 사용하는 경우 Docker 또는 Kubernetes 실행기가 기본적으로 활성화되어 있습니다.
  • Windows 러너에서 실행되는 GitLab Runner는 지원되지 않습니다.
  • AMD64 이외의 CPU 아키텍처는 지원되지 않습니다.
• GitLab CI/CD 구성(.gitlab-ci.yml)에 test stage가 포함되어야 하며, 기본적으로 포함되어 있습니다. .gitlab-ci.yml 파일에서 stage를 재정의하는 경우 test stage가 필요합니다.

프로젝트에서 SAST를 활성화하려면 다음을 수행합니다:

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.

2. Build > Pipeline editor로 이동합니다.

3. SAST CI/CD 템플릿 또는 컴포넌트를 추가합니다.

   템플릿을 사용하려면 다음 줄을 추가합니다:

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

   CI/CD 컴포넌트를 사용하려면 다음 줄을 추가합니다:

   include:
     - component: gitlab.com/components/sast/sast@main
   

4. Validate 탭을 선택한 다음 Validate pipeline을 선택합니다.

   Simulation completed successfully 메시지는 파일이 유효하다는 뜻입니다.

5. Edit 탭을 선택합니다.

6. 다음 필드를 입력합니다:

   • 커밋 메시지.
   • 브랜치. 예를 들어 add-sast.

7. Start a new merge request with these changes 체크박스를 선택한 다음 Commit changes를 선택합니다.

   머지 리퀘스트 페이지가 열립니다.

8. 표준 워크플로에 따라 필드를 입력한 다음 Create merge request를 선택합니다.

9. 표준 워크플로에 따라 머지 리퀘스트를 검토하고 편집한 다음 Merge를 선택합니다.

이제 파이프라인에 SAST job이 포함됩니다. 지원되는 소스 코드가 있으면 파이프라인 실행 시 해당 분석기와 기본 규칙이 자동으로 취약점을 스캔합니다. 해당 job은 프로젝트 파이프라인의 test stage 아래에 표시됩니다.

동작하는 예시는 SAST 예시 프로젝트에서 확인할 수 있습니다.

다음 단계#

SAST를 활성화한 다음에는 아래 작업을 수행할 수 있습니다:

• 결과 이해하기에 관해 자세히 알아봅니다.
• 최적화 팁을 검토합니다.
• 추가 프로젝트로 롤아웃을 계획합니다.

결과 이해하기#

사전 요구 사항:

• 프로젝트에 대한 Security Manager, Developer, Maintainer 또는 Owner 권한.

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

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Build > Pipelines를 선택합니다.
3. 파이프라인을 선택합니다.
4. Security 탭을 선택합니다.
5. 결과를 다운로드하거나, 취약점을 선택해 세부 정보를 확인합니다(Ultimate 전용). 세부 정보는 다음과 같습니다:
   • 설명: 취약점의 원인, 잠재적 영향, 권장 수정 단계를 설명합니다.
   • 상태: 취약점이 분류되었는지 또는 해결되었는지를 나타냅니다.
   • 심각도: 영향에 따라 여섯 개 수준으로 분류됩니다. 심각도 수준 자세히 알아보기.
   • 위치: 문제가 발견된 파일명과 줄 번호를 표시합니다. 파일 경로를 선택하면 코드 보기에서 해당 줄이 열립니다.
   • 스캐너: 취약점을 탐지한 분석기를 식별합니다.
   • 식별자: CWE 식별자와 탐지한 규칙 ID 등 취약점을 분류하는 데 사용되는 참조 목록입니다.

SAST 취약점은 발견된 취약점의 기본 공통 취약점 열거(Common Weakness Enumeration, CWE) 식별자에 따라 이름이 정해집니다. 각 취약점 결과의 설명을 읽으면 스캐너가 탐지한 구체적인 문제를 파악할 수 있습니다. SAST 커버리지에 관한 자세한 내용은 SAST 규칙을 참고합니다.

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

사전 요구 사항:

• 프로젝트에 대한 Security Manager, Developer, Maintainer 또는 Owner 권한.

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Build > Pipelines를 선택합니다.
3. 파이프라인을 선택합니다.
4. Security 탭을 선택합니다.
5. 파이프라인의 Security 탭에서 Download results를 선택합니다.

자세한 내용은 파이프라인 보안 리포트를 참고합니다.

SAST 결과를 확인하는 다른 방법은 다음과 같습니다:

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

파이프라인은 SAST와 DAST 스캔을 포함한 여러 job으로 구성됩니다. 어떤 이유로든 job 하나가 완료되지 않으면 보안 대시보드에 SAST 스캐너 출력이 표시되지 않습니다. 예를 들어 SAST job은 완료되었지만 DAST job이 실패하면 보안 대시보드에 SAST 결과가 표시되지 않습니다. 실패 시 분석기는 종료 코드를 출력합니다.

머지 리퀘스트 리포트#

머지 리퀘스트의 SAST 결과는 머지 리퀘스트 리포트를 참고합니다.

머지 리퀘스트 변경 사항 보기#

SAST 결과는 머지 리퀘스트 Changes 보기에 표시됩니다. SAST 문제가 있는 줄은 거터 옆의 기호로 표시됩니다. 기호를 선택하면 문제 목록이 나타나고, 문제를 선택하면 세부 정보를 확인할 수 있습니다.

최적화#

요구 사항에 맞게 SAST를 최적화하려면 다음을 수행할 수 있습니다:

• 규칙을 비활성화합니다.
• 스캔 대상에서 파일이나 경로를 제외합니다.

규칙 비활성화#

사전 요구 사항:

• 프로젝트에 대한 Developer, Maintainer 또는 Owner 권한.

거짓 양성이 너무 많이 생기는 등의 이유로 규칙을 비활성화하려면 다음을 수행합니다:

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.

2. 프로젝트 루트에 .gitlab/sast-ruleset.toml 파일이 없으면 생성합니다.

3. 취약점 세부 정보에서 해당 결과를 발생시킨 규칙의 ID를 확인합니다.

4. 규칙 ID로 규칙을 비활성화합니다. 예를 들어 gosec.G107-1을 비활성화하려면 .gitlab/sast-ruleset.toml에 다음을 추가합니다:

   [semgrep]
     [[semgrep.ruleset]]
       disable = true
       [semgrep.ruleset.identifier]
         type = "semgrep_id"
         value = "gosec.G107-1"
   

룰셋 커스터마이징에 관한 자세한 내용은 룰셋 커스터마이징을 참고합니다.

스캔에서 파일 또는 경로 제외#

사전 요구 사항:

• 프로젝트에 대한 Developer, Maintainer 또는 Owner 권한.

테스트 코드나 임시 코드처럼 스캔에서 제외할 파일이나 경로가 있으면 SAST_EXCLUDED_PATHS 변수를 설정합니다. 예를 들어 rule-template-injection.go를 건너뛰려면 .gitlab-ci.yml에 다음을 추가합니다:

variables:
  SAST_EXCLUDED_PATHS: "rule-template-injection.go"

구성 옵션에 관한 자세한 내용은 사용 가능한 CI/CD 변수를 참고합니다.

롤아웃#

단일 프로젝트의 SAST 결과에 확신이 생기면 다른 프로젝트로 적용 범위를 넓힐 수 있습니다:

• 강제 스캔 실행으로 그룹 전체에 SAST 설정을 적용합니다.
• 원격 구성 파일 지정으로 중앙 룰셋을 공유하고 재사용합니다.
• 별도 요구 사항이 있으면 오프라인 환경이나 SELinux 제약 아래에서도 SAST를 실행할 수 있습니다.

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

GitLab SAST는 다음 언어와 프레임워크의 스캔을 지원합니다.

사용할 수 있는 스캔 옵션은 GitLab 티어에 따라 다릅니다:

• Ultimate에서는 GitLab Advanced SAST가 더 정확한 결과를 제공합니다. 지원되는 언어에는 이 방식을 사용합니다.
• 모든 티어에서 오픈 소스 스캐너 기반의 GitLab 제공 분석기로 코드를 스캔할 수 있습니다.

SAST의 언어 지원 계획에 관한 자세한 내용은 카테고리 방향 페이지를 참고합니다.

완전 지원 언어#

다음 언어는 GitLab Advanced SAST(Ultimate)와 표준 분석기(모든 티어) 양쪽에서 지원됩니다:

표준 분석기만 지원되는 언어#

다음 언어는 표준 분석기(모든 티어)에서 지원되지만 GitLab Advanced SAST에서는 지원되지 않습니다:

GitLab Advanced SAST만 지원되는 언어#

다음 언어는 GitLab Advanced SAST(Ultimate)에서 베타로 지원되지만 표준 분석기에서는 지원되지 않습니다:

분석은 별도의 gitlab-advanced-sast-ext CI/CD job으로 실행되며, GITLAB_ADVANCED_SAST_ENABLED CI/CD 변수로 GitLab Advanced SAST와 함께 활성화됩니다. 자세한 내용은 GitLab Advanced SAST를 참고합니다.

SAST CI/CD 템플릿에는 Kubernetes 매니페스트와 Helm 차트를 스캔할 수 있는 분석기 job도 포함되어 있으며, 이 job은 기본적으로 꺼져 있습니다. Kubesec 분석기 활성화를 참고하거나, 더 많은 플랫폼을 지원하는 IaC 스캔을 대신 고려합니다.

더 이상 지원되지 않는 SAST 분석기는 지원 종료에 도달한 분석기를 참고합니다.

고급 취약점 추적#

소스 코드는 계속 변합니다. 개발자가 변경을 가하면 소스 코드는 같은 파일 안에서 이동하거나 다른 파일로 옮겨질 수 있습니다. 보안 분석기가 이미 보고한 취약점은 취약점 리포트에서 추적되고 있습니다. 이 취약점들은 문제가 되는 특정 코드 조각과 연결되어 있어 찾아서 수정할 수 있습니다. 코드 조각이 이동할 때 안정적으로 추적되지 않으면 같은 취약점이 다시 보고될 수 있어 취약점 관리가 어려워집니다.

GitLab SAST는 고급 취약점 추적 알고리즘을 사용해, 리팩터링이나 무관한 변경으로 같은 파일 안에서 같은 취약점이 이동한 경우를 더 정확하게 식별합니다.

고급 취약점 추적 지원 범위는 사용하는 언어와 분석기에 따라 다릅니다.

GitLab Advanced SAST 분석기와 Semgrep 기반 분석기 양쪽에서 지원되는 언어:

• C
• C++
• C#
• Go
• Java
• JavaScript
• Python

Semgrep 기반 분석기에서만 지원되는 언어:

• PHP
• Ruby

더 많은 언어와 분석기 지원은 에픽 5144에서 추적하고 있습니다.

자세한 내용은 비공개 프로젝트 https://gitlab.com/gitlab-org/security-products/post-analyzers/tracking-calculator를 참고합니다. 이 프로젝트의 콘텐츠는 GitLab 팀원만 열람할 수 있습니다.

자동 취약점 해결#

아직 유효한 취약점에 집중할 수 있도록, GitLab SAST는 다음 경우에 취약점을 자동으로 해결됨으로 표시합니다:

• 미리 정의된 규칙을 비활성화한 경우.
• 기본 룰셋에서 규칙이 제거된 경우.

자동 해결은 Semgrep 기반 분석기의 결과에만 적용됩니다. 취약점 관리 시스템은 자동으로 해결된 취약점에 댓글을 남기므로, 해당 취약점의 이력 기록은 그대로 남습니다.

나중에 규칙을 다시 활성화하면 해당 결과는 분류 대상으로 다시 열립니다.

지원되는 배포판#

기본 스캐너 이미지는 크기와 유지 보수성을 고려해 Alpine 기반 이미지 위에 빌드됩니다.

FIPS 지원 이미지#

GitLab은 FIPS 140 검증 암호화 모듈을 사용하는 Red Hat UBI 기반 이미지 버전을 제공합니다. FIPS 지원 이미지를 사용하려면 다음 중 하나를 수행합니다:

• SAST_IMAGE_SUFFIX를 -fips로 설정합니다.
• 기본 이미지 이름에 -fips 확장자를 추가합니다.

예를 들어 다음과 같습니다:

variables:
  SAST_IMAGE_SUFFIX: '-fips'

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

FIPS를 준수하는 이미지는 GitLab Advanced SAST와 Semgrep 기반 분석기에만 제공됩니다.

SAST 리포트 다운로드#

사전 요구 사항:

• 프로젝트에 대한 Developer, Maintainer 또는 Owner 권한.

각 SAST 분석기는 job 아티팩트로 JSON 리포트를 출력합니다. 이 파일에는 탐지된 모든 취약점의 세부 정보가 담겨 있습니다. 파일을 내려받아 GitLab 외부에서 처리할 수 있습니다.

자세한 내용은 다음을 참고합니다:

• SAST 리포트 파일 스키마
• SAST 리포트 파일 예시

구성#

GitLab SAST는 기본 구성 그대로 사용하도록 설계되었습니다. 필요에 따라 구성 변수를 변경하거나 탐지 규칙을 커스터마이징할 수 있습니다.

안정 버전 대 최신 SAST 템플릿#

SAST는 프로덕션 용도로 기본 사용되는 stable 템플릿과, 최신 기능을 시험하기 위한 latest 템플릿을 제공합니다. 차이점과 각각의 사용 시점은 템플릿 에디션을 참고합니다.

SAST job 재정의#

variables, dependencies, rules 같은 속성을 커스터마이징하려면 SAST job을 재정의합니다.

사전 요구 사항:

• 프로젝트에 대한 Developer, Maintainer 또는 Owner 권한.

job 정의를 재정의하려면 다음을 수행합니다:

• 재정의할 SAST job과 같은 이름으로 job을 선언합니다.

  이 새 job은 템플릿을 포함한 뒤에 배치하고, 그 아래에 추가할 키를 지정합니다.

다음 예시에서는 spotbugs 분석기에 대해 CI/CD 변수 FAIL_NEVER를 활성화합니다:

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

spotbugs-sast:
  variables:
    FAIL_NEVER: 1

분석기 이미지 버전 고정#

파이프라인에서 특정 분석기 이미지 버전을 사용하려면 이미지 버전을 고정합니다. GitLab 관리 CI/CD 템플릿은 메이저 버전을 지정하고 해당 메이저 버전 안에서 최신 분석기 릴리스를 자동으로 가져옵니다. 경우에 따라 특정 버전을 사용해야 할 수 있습니다. 예를 들어 이후 릴리스에서 생긴 회귀를 피해야 하는 경우가 있습니다.

태그는 다음 옵션 중 하나로 설정할 수 있습니다:

• 메이저 버전. 예를 들어 3. 파이프라인은 이 메이저 버전 안에서 릴리스되는 마이너 또는 패치 업데이트를 모두 사용합니다.
• 마이너 버전. 예를 들어 3.7. 파이프라인은 이 마이너 버전 안에서 릴리스되는 패치 업데이트를 모두 사용합니다.
• 패치 버전. 예를 들어 3.7.0. 파이프라인은 업데이트를 받지 않습니다.

이 변수는 특정 job 안에서만 설정합니다. 최상위 수준에서 설정하면 지정한 버전이 모든 SAST 분석기에 적용됩니다.

사전 요구 사항:

• 프로젝트에 대한 Developer, Maintainer 또는 Owner 권한.

분석기 이미지를 특정 버전으로 고정하려면 다음을 수행합니다:

• 프로젝트의 .gitlab-ci.yml 파일에 SAST_ANALYZER_IMAGE_TAG CI/CD 변수를 설정합니다. 이 CI/CD 변수는 SAST.gitlab-ci.yml 템플릿을 포함한 뒤에 나열해야 합니다.

다음 예시에서는 semgrep 분석기의 특정 마이너 버전과 brakeman 분석기의 특정 패치 버전을 설정합니다:

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

semgrep-sast:
  variables:
    SAST_ANALYZER_IMAGE_TAG: "3.7"

brakeman-sast:
  variables:
    SAST_ANALYZER_IMAGE_TAG: "3.1.1"

CI/CD 변수를 사용하여 프라이빗 리포지터리에 자격 증명 전달#

일부 분석기는 분석을 수행하기 위해 프로젝트의 의존성을 내려받아야 합니다. 이러한 의존성이 프라이빗 Git 리포지터리에 있으면 내려받는 데 사용자 이름과 비밀번호 같은 자격 증명이 필요합니다. 분석기에 따라 이러한 자격 증명은 커스텀 CI/CD 변수로 전달할 수 있습니다.

CI/CD 변수를 사용하여 프라이빗 Maven 리포지터리에 사용자 이름과 비밀번호 전달#

프라이빗 Maven 리포지터리에 로그인 자격 증명이 필요하면 MAVEN_CLI_OPTS CI/CD 변수를 사용할 수 있습니다.

자세한 내용은 프라이빗 Maven 리포지터리 사용 방법을 참고합니다.

Kubesec 분석기 활성화#

사전 요구 사항:

• 프로젝트에 대한 Developer, Maintainer 또는 Owner 권한.

Kubesec 분석기를 활성화하려면 SCAN_KUBERNETES_MANIFESTS를 "true"로 설정해야 합니다. .gitlab-ci.yml에 다음을 정의합니다:

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

variables:
  SCAN_KUBERNETES_MANIFESTS: "true"

Semgrep 기반 분석기로 다른 언어 스캔#

GitLab 관리 룰셋이 지원하지 않는 언어를 스캔하도록 Semgrep 기반 SAST 분석기를 커스터마이징할 수 있습니다. 다만 GitLab은 이러한 다른 언어의 룰셋을 제공하지 않으므로, 해당 언어를 다루려면 기본 규칙을 교체하거나 추가해야 합니다. 또한 관련 파일이 수정될 때 job이 실행되도록 semgrep-sast CI/CD job의 rules도 수정해야 합니다.

OCaml 애플리케이션 스캔#

사전 요구 사항:

• 프로젝트에 대한 Developer, Maintainer 또는 Owner 권한.

OCaml 애플리케이션을 스캔하려면 다음 단계를 수행합니다:

1. OCaml용 커스텀 룰셋을 제공합니다. 리포지터리 루트의 .gitlab/ 디렉터리에 sast-ruleset.toml 파일을 생성합니다.

   다음 예시는 Semgrep 레지스트리의 OCaml 룰셋을 사용합니다:

   [semgrep]
     description = "OCaml ruleset for Semgrep"
     targetdir = "/sgrules"
     timeout = 60
   
     [[semgrep.passthrough]]
       type  = "url"
       value = "https://semgrep.dev/c/p/ocaml"
       target = "ocaml.yml"
   

   자세한 내용은 미리 정의된 규칙 교체 또는 추가를 참고합니다.

2. OCaml(.ml) 파일을 탐지하는 규칙을 추가하도록 semgrep-sast job을 재정의합니다.

   .gitlab-ci.yml 파일에 다음을 정의합니다:

   include:
     - template: Jobs/SAST.gitlab-ci.yml
   
   semgrep-sast:
     rules:
       - if: $CI_COMMIT_BRANCH
         exists:
           - '**/*.ml'
           # include any other file extensions you need to scan from the semgrep-sast template: Jobs/SAST.gitlab-ci.yml
   

SpotBugs 분석기의 JDK21 지원#

SpotBugs 분석기 버전 6은 JDK21 지원을 추가하고 JDK11을 제거합니다. 이슈 517169에서 논의된 대로 기본 버전은 5로 유지됩니다.

버전 6을 사용하려면 분석기 버전을 고정합니다. 자세한 내용은 분석기 이미지 버전 고정을 참고합니다.

spotbugs-sast:
  variables:
    SAST_ANALYZER_IMAGE_TAG: "6"

SpotBugs 분석기에서 사전 컴파일 사용#

SpotBugs 기반 분석기는 Groovy 프로젝트의 컴파일된 바이트코드를 스캔합니다. 기본적으로 스캔이 가능하도록 의존성을 가져오고 코드를 컴파일하는 작업을 자동으로 시도합니다.

다음 경우에는 자동 컴파일이 실패할 수 있습니다:

• 프로젝트에 커스텀 빌드 구성이 필요한 경우.
• 분석기에 내장되지 않은 언어 버전을 사용하는 경우.

이 문제를 해결하려면 분석기의 컴파일 단계를 건너뛰고, 파이프라인의 앞 단계에서 만든 아티팩트를 직접 제공합니다. 이 방식을 사전 컴파일이라고 합니다.

사전 컴파일된 아티팩트 공유#

사전 요구 사항:

• 프로젝트에 대한 Developer, Maintainer 또는 Owner 권한.

사전 컴파일된 아티팩트를 공유하려면 프로젝트의 .gitlab-ci.yml 파일을 다음과 같이 변경합니다:

1. 컴파일 job(보통 build)으로 프로젝트를 컴파일하고, CI/CD artifacts: paths 변수로 컴파일 결과물을 job artifact로 저장합니다.

   • Maven 프로젝트에서 출력 폴더는 보통 target 디렉터리입니다.
   • Gradle 프로젝트에서는 일반적으로 build 디렉터리입니다.
   • 프로젝트가 커스텀 출력 위치를 사용하면 아티팩트 경로를 그에 맞게 설정합니다.

2. spotbugs-sast job에 COMPILE: "false" CI/CD 변수를 설정해 자동 컴파일을 비활성화합니다.

3. dependencies 키워드를 설정해 spotbugs-sast job이 컴파일 job에 의존하도록 합니다. 이렇게 하면 spotbugs-sast job이 컴파일 job에서 생성한 아티팩트를 내려받아 사용할 수 있습니다.

다음 예시는 Gradle 프로젝트를 사전 컴파일하고 컴파일된 바이트코드를 분석기에 제공합니다:

stages:
  - build
  - test

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

build:
  image: gradle:7.6-jdk8
  stage: build
  script:
    - gradle build
  artifacts:
    paths:
      - build/

spotbugs-sast:
  dependencies:
    - build
  variables:
    COMPILE: "false"
    SECURE_LOG_LEVEL: debug

의존성 지정 (Maven 전용)#

사전 요구 사항:

• 프로젝트에 대한 Developer, Maintainer 또는 Owner 권한.

분석기가 외부 의존성을 인식해야 하고 Maven을 사용하고 있다면, MAVEN_REPO_PATH 변수로 로컬 리포지터리 위치를 지정할 수 있습니다.

의존성 지정은 Maven 기반 프로젝트에서만 지원됩니다. Gradle 같은 다른 빌드 도구에는 의존성을 지정하는 동등한 방식이 없습니다. 이 경우 컴파일된 아티팩트에 필요한 의존성이 모두 포함되도록 합니다.

Maven 의존성을 지정하려면 프로젝트의 .gitlab-ci.yml 파일을 다음과 같이 변경합니다:

1. MAVEN_REPO_PATH 변수가 로컬 Maven 리포지터리를 가리키도록 설정합니다.
2. 빌드 job이 해당 경로에 리포지터리를 생성하도록 합니다(예: mvn package -Dmaven.repo.local=./.m2/repository 실행).
3. spotbugs-sast job이 빌드 job에 의존하도록 구성하고 컴파일을 비활성화합니다.

다음 예시는 Maven 프로젝트를 사전 컴파일하고 컴파일된 바이트코드와 의존성을 분석기에 제공합니다:

stages:
  - build
  - test

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

build:
  image: maven:3.6-jdk-8-slim
  stage: build
  script:
    - mvn package -Dmaven.repo.local=./.m2/repository
  artifacts:
    paths:
      - .m2/
      - target/

spotbugs-sast:
  dependencies:
    - build
  variables:
    MAVEN_REPO_PATH: $CI_PROJECT_DIR/.m2/repository
    COMPILE: "false"
    SECURE_LOG_LEVEL: debug

이제 분석기가 스캔 중에 프로젝트의 의존성을 인식합니다.

사용 가능한 CI/CD 변수#

SAST는 .gitlab-ci.yml의 variables 파라미터로 구성할 수 있습니다.

GitLab SAST 템플릿을 사용하면 모든 표준 SAST 구성 CI/CD 변수와 커스텀 변수가 기반 SAST 분석기 이미지로 전파됩니다.

다음 예시는 모든 job에서 SEARCH_MAX_DEPTH 변수를 10으로 재정의하기 위해 SAST 템플릿을 포함합니다. 템플릿은 파이프라인 구성보다 먼저 평가되므로, 변수를 마지막에 언급한 쪽이 우선합니다.

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

variables:
  SEARCH_MAX_DEPTH: 10

커스텀 인증 기관(CA)#

커스텀 인증 기관(Certificate Authority, CA) 지원은 다음 분석기 버전에서 도입되었습니다.

커스텀 인증 기관 사용#

사전 요구 사항:

• 프로젝트에 대한 Maintainer 또는 Developer 권한.

• X.509 PEM 공개 키 인증서의 텍스트 표현.

  다음 방법 중 하나로 인증서를 제공할 수 있습니다:

  • 프로젝트의 .gitlab-ci.yml 파일에 인증서를 직접 추가합니다.
  • 인증서 경로를 제공하는 file CI/CD 변수를 생성합니다.
  • 인증서의 텍스트 표현이 담긴 UI의 커스텀 변수를 설정합니다.

커스텀 CA 인증서를 신뢰하려면 다음을 수행합니다:

• SAST 환경에서 신뢰할 CA 인증서 번들을 ADDITIONAL_CA_CERT_BUNDLE 변수에 설정합니다.

예를 들어 프로젝트의 .gitlab-ci.yml 파일에서 이 값을 구성하려면 다음과 같이 작성합니다:

variables:
  ADDITIONAL_CA_CERT_BUNDLE: |
      -----BEGIN CERTIFICATE-----
      MIIGqTCCBJGgAwIBAgIQI7AVxxVwg2kch4d56XNdDjANBgkqhkiG9w0BAQsFADCB
      ...
      jWgmPqF3vUbZE0EyScetPJquRFRKIesyJuBFMAs=
      -----END CERTIFICATE-----

Docker 이미지#

다음은 Docker 이미지 관련 CI/CD 변수입니다.

취약점 필터#

SAST는 파일 경로와 검색 깊이를 기준으로 코드를 제외하도록 구성할 수 있습니다. 다음 CI/CD 변수는 어떤 파일을 스캔할지, 분석기가 코드베이스를 얼마나 깊이 탐색할지를 제어합니다.

  </td>
  <td rowspan="2">
    <code>
      <a href="https://gitlab.com/gitlab-org/gitlab/-/blob/v17.3.0-ee/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml#L54">20</a>
    </code>
  </td>
  <td>
    <a href="https://gitlab.com/gitlab-org/security-products/analyzers/semgrep">Semgrep</a>
  </td>
</tr>
<tr>
  <td>
    <a href="https://docs.gitlab.com/user/application_security/sast/gitlab_advanced_sast/">GitLab Advanced SAST</a>
  </td>
</tr>
<tr>
  <td>
    <code>
      <a href="https://gitlab.com/gitlab-org/gitlab/blob/v17.3.0-ee/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml#L26">4</a>
    </code>
  </td>
  <td>
    기타 모든 SAST 분석기
  </td>
</tr>

각주:

1. 빌드 도구가 사용하는 임시 디렉터리는 거짓 양성을 만들 수 있으므로 제외해야 할 수 있습니다. 경로를 제외하려면 기본 제외 경로를 복사해 붙여넣은 다음, 제외할 경로를 추가합니다. 기본 제외 경로를 지정하지 않으면 기본값이 재정의되어 지정한 경로만 SAST 스캔에서 제외됩니다.

2. 이 분석기들에서 SAST_EXCLUDED_PATHS는 스캔 실행 전에 적용되는 사전 필터로 구현됩니다.

   분석기는 경로가 쉼표로 구분된 패턴 중 하나와 일치하는 파일이나 디렉터리를 건너뜁니다.

   예를 들어 SAST_EXCLUDED_PATHS가 *.py,tests로 설정된 경우는 다음과 같습니다:

   • *.py는 다음을 무시합니다:
     • foo.py
     • src/foo.py
     • foo.py/bar.sh
   • tests는 다음을 무시합니다:
     • tests/foo.py
     • a/b/tests/c/foo.py

   각 패턴은 gitignore와 동일한 구문을 사용하는 glob 스타일 패턴입니다.

3. 이 분석기들에서 SAST_EXCLUDED_PATHS는 스캔 실행 후에 적용되는 사후 필터로 구현됩니다.

   패턴은 glob(지원되는 패턴은 doublestar.Match 참고)이거나 파일 또는 폴더 경로(예: doc,spec)일 수 있습니다. 상위 디렉터리도 패턴과 일치합니다.

   SAST_EXCLUDED_PATHS의 사후 필터 구현은 모든 SAST 분석기에서 사용할 수 있습니다. 위 첨자 2가 붙은 분석기처럼 일부 SAST 분석기는 SAST_EXCLUDED_PATHS를 사전 필터와 사후 필터 양쪽으로 구현합니다. 사전 필터는 스캔할 파일 수를 줄이므로 더 효율적입니다.

   SAST_EXCLUDED_PATHS를 사전 필터와 사후 필터 양쪽으로 지원하는 분석기에서는 사전 필터가 먼저 적용되고, 그다음 남아 있는 취약점에 사후 필터가 적용됩니다.

4. 이 변수의 경로 패턴은 glob일 수 있습니다 (지원되는 패턴은 doublestar.Match 참고). 경로 패턴이 지원되는 빌드 파일과 일치하면 해당 디렉터리는 빌드 프로세스에서 제외됩니다:

   • build.sbt
   • grailsw
   • gradlew
   • build.gradle
   • mvnw
   • pom.xml
   • build.xml

   예를 들어 project/subdir/pom.xml 경로에 빌드 파일이 있는 maven 프로젝트를 빌드 및 스캔에서 제외하려면, project/*/*.xml이나 **/*.xml처럼 빌드 파일과 명시적으로 일치하는 glob 패턴이나 project/subdir/pom.xml 같은 정확한 경로를 전달합니다.

   project 또는 project/subdir처럼 상위 디렉터리를 패턴으로 전달하면 이 경우 빌드 파일이 패턴과 명시적으로 일치하지 않으므로 해당 디렉터리는 빌드에서 제외되지 않습니다.

5. SAST CI/CD 템플릿은 리포지터리를 검색해 사용된 프로그래밍 언어를 탐지하고 일치하는 분석기를 선택합니다. 그다음 각 분석기가 코드베이스를 검색해 스캔할 특정 파일이나 디렉터리를 찾습니다. 분석기의 검색 단계가 몇 개의 디렉터리 단계까지 미칠지는 SEARCH_MAX_DEPTH 값으로 지정합니다.

분석기 설정#

일부 분석기는 CI/CD 변수로 커스터마이징할 수 있습니다.

보안 스캐너 구성#

SAST 분석기는 내부적으로 OSS 보안 스캐너를 사용해 분석을 수행합니다. GitLab이 보안 스캐너의 권장 구성을 설정해 두므로 스캐너를 직접 조정할 필요는 없습니다. 다만 드물게는 기본 스캐너 구성이 사용자의 요구 사항에 맞지 않을 수 있습니다.

스캐너 동작을 일부 커스터마이징할 수 있도록, 기반 스캐너에 제한된 범위의 플래그를 추가할 수 있습니다. 플래그는 SAST_SCANNER_ALLOWED_CLI_OPTS CI/CD 변수에 지정합니다. 이 플래그는 스캐너의 CLI 옵션에 추가됩니다.

분석에서 코드 제외#

개별 코드 줄이나 코드 블록을 취약점 분석 대상에서 제외하도록 표시할 수 있습니다. 결과 하나하나에 주석을 다는 이 방법을 쓰기 전에, 취약점은 취약점 관리로 처리하거나 SAST_EXCLUDED_PATHS로 스캔 대상 파일 경로를 조정하는 편이 좋습니다.

Semgrep 기반 분석기를 사용할 때는 다음 옵션도 사용할 수 있습니다:

• 코드 한 줄 무시 - 줄 끝에 // nosemgrep: 주석을 추가합니다(접두사는 개발 언어에 따라 다릅니다).

  Java 예시:

  vuln_func(); // nosemgrep
  

  Python 예시:

  vuln_func(); # nosemgrep
  

• 특정 규칙에 대해 코드 한 줄 무시 - 줄 끝에 // nosemgrep: RULE_ID 주석을 추가합니다(접두사는 개발 언어에 따라 다릅니다).

• //nosemgrep 주석은 탐지된 줄 바로 앞 줄에 추가할 수도 있습니다. 무시 주석과 탐지된 코드 사이에는 다른 주석을 포함해 어떤 줄도 있어서는 안 됩니다.

• 파일 또는 디렉터리 무시 - 리포지터리 루트 디렉터리나 프로젝트 작업 디렉터리에 .semgrepignore 파일을 만들고 파일과 폴더 패턴을 추가합니다. GitLab Semgrep 분석기는 사용자가 만든 .semgrepignore 파일을 GitLab 기본 무시 패턴과 자동으로 병합합니다.

자세한 내용은 Semgrep 문서를 참고합니다.

오프라인 환경에서 SAST 실행#

인터넷을 통한 외부 리소스 접근이 제한되거나 차단되어 있거나 간헐적인 환경의 인스턴스에서는 SAST job이 정상적으로 실행되도록 몇 가지 조정이 필요합니다. 자세한 내용은 오프라인 환경을 참고합니다.

오프라인 SAST 요구 사항#

오프라인 환경에서 SAST를 사용하려면 다음이 필요합니다:

• docker 또는 kubernetes 실행기를 사용하는 GitLab Runner. 자세한 내용은 사전 요구 사항을 참고합니다.
• SAST 분석기 이미지의 로컬 사본을 갖춘 Docker 컨테이너 레지스트리.
• 패키지의 인증서 검사 구성(선택 사항).

GitLab Runner는 pull_policy 기본값이 always이므로, 로컬 사본이 있어도 GitLab 컨테이너 레지스트리에서 Docker 이미지를 가져오려고 시도합니다. 로컬에 있는 Docker 이미지만 사용하려면 오프라인 환경에서 GitLab Runner의 pull_policy를 if-not-present로 설정할 수 있습니다. 다만 오프라인 환경이 아니라면 풀 정책을 always로 유지합니다. 이 설정을 유지하면 CI/CD 파이프라인에서 업데이트된 스캐너를 사용할 수 있습니다.

Docker 레지스트리에서 GitLab SAST 분석기 이미지 제공#

지원되는 모든 언어와 프레임워크로 SAST를 실행하려면, 다음 기본 SAST 분석기 이미지를 registry.gitlab.com에서 로컬 Docker 컨테이너 레지스트리로 가져옵니다:

registry.gitlab.com/security-products/clangsa:1
registry.gitlab.com/security-products/gitlab-advanced-sast:2
registry.gitlab.com/security-products/gitlab-advanced-sast-ext:0
registry.gitlab.com/security-products/kubesec:6
registry.gitlab.com/security-products/pmd-apex:6
registry.gitlab.com/security-products/semgrep:6
registry.gitlab.com/security-products/sobelow:6
registry.gitlab.com/security-products/spotbugs:5

Docker 이미지를 로컬 오프라인 Docker 레지스트리로 가져오는 절차는 네트워크 보안 정책에 따라 다릅니다. 외부 리소스를 가져오거나 일시적으로 접근할 수 있는 승인된 절차는 IT 담당자와 확인합니다. 이 스캐너들은 새 정의로 주기적으로 업데이트되며, 필요에 따라 직접 업데이트할 수도 있습니다.

Docker 이미지를 파일로 저장하고 옮기는 방법은 다음 Docker 문서를 참고합니다:

• docker save
• docker load
• docker export
• docker import

로컬 SAST 분석기 사용#

사전 요구 사항:

• 프로젝트에 대한 Developer, Maintainer 또는 Owner 권한.

로컬 SAST 분석기를 사용하려면 다음을 수행합니다:

• 프로젝트의 .gitlab-ci.yml 파일에서 로컬 Docker 컨테이너 레지스트리를 가리키도록 CI/CD 변수 SECURE_ANALYZERS_PREFIX를 정의합니다.

예를 들어 다음과 같습니다:

variables:
  SECURE_ANALYZERS_PREFIX: "localhost:5000/analyzers"

이제 SAST job은 로컬에 있는 SAST 분석기 사본으로 코드를 스캔하고, 인터넷 접속 없이 보안 리포트를 생성합니다.

패키지의 인증서 검사 구성#

SAST job이 패키지 관리자를 호출한다면 해당 패키지 관리자의 인증서 검증을 구성해야 합니다. 오프라인 환경에서는 외부 소스를 통한 인증서 검증이 불가능합니다. 자체 서명 인증서를 사용하거나 인증서 검증을 비활성화합니다. 구체적인 방법은 해당 패키지 관리자의 문서를 참고합니다.

SELinux에서 SAST 실행#

기본적으로 SAST 분석기는 SELinux에서 호스팅되는 GitLab 인스턴스에서 지원됩니다. SELinux에서 호스팅되는 러너는 권한이 제한되어 있으므로, 재정의한 SAST job에 before_script를 추가하는 방식은 동작하지 않을 수 있습니다.