정적 애플리케이션 보안 테스팅(Static application security testing, SAST)은 소스 코드의 취약점이 프로덕션 환경에 도달하기 전에 발견합니다. CI/CD 파이프라인에 직접 통합된 SAST는 개발 중에 보안 문제를 식별하며, 이 시점이 수정이 가장 쉽고 비용 효율적입니다.

개발 후반부에 발견된 보안 취약점은 비용이 많이 드는 지연과 잠재적인 침해를 야기합니다. SAST 스캔은 각 커밋과 함께 자동으로 실행되어 워크플로를 방해하지 않고 즉각적인 피드백을 제공합니다.

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

DETAILS: Tier: Ultimate

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

거짓 양성 탐지#

GitLab Duo 거짓 양성 탐지는 심각도가 높고 치명적인 SAST 취약점을 자동으로 분석하여 거짓 양성 가능성이 있는 항목을 식별합니다. 이를 통해 보안 팀이 실제 취약점에 집중하고 수동 분류에 소요되는 시간을 줄일 수 있습니다.

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

에이전틱 SAST 취약점 해결#

에이전틱 SAST 취약점 해결(Agentic SAST Vulnerability Resolution)은 높음(High) 및 치명적(Critical) 심각도 SAST 취약점에 대해 컨텍스트 인식 코드 수정이 포함된 머지 리퀘스트를 자동으로 생성합니다. 이 에이전틱 접근 방식은 멀티샷 추론을 사용하여 최소한의 사람 개입으로 취약점을 해결합니다.

Ultimate 티어 고객의 경우, 에이전틱 취약점 해결은 특정 조건이 충족되는 취약점이 있을 때 각 보안 스캔 후 자동으로 실행됩니다.

기능#

다음 표에는 각 기능을 사용할 수 있는 GitLab 티어가 나와 있습니다.

시작하기#

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

UI를 사용하여 SAST 활성화#

히스토리

• GitLab 16.2에서 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를 활성화하고 구성하려면:

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

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

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

• 커스텀 SAST 값을 입력합니다.

커스텀 값은 .gitlab-ci.yml 파일에 저장됩니다. SAST 구성 페이지에 없는 CI/CD 변수의 경우 해당 값은 GitLab SAST 템플릿에서 상속됩니다.

• Create merge request를 선택합니다.

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

파이프라인에는 이제 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를 활성화하고 구성하려면:

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

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

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

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

• 필드를 작성합니다.

• Create merge request를 선택합니다.

• 머지 리퀘스트를 검토하고 머지하여 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를 활성화하려면:

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

• Build > Pipeline 편집기로 이동합니다.

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

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

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

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

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

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

Simulation completed successfully 메시지가 파일이 유효함을 확인합니다.

• Edit 탭을 선택합니다.

• 다음 필드를 작성합니다:

커밋 메시지.

• 브랜치. 예: add-sast.

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

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

• 표준 워크플로에 따라 필드를 작성한 다음 Create merge request를 선택합니다.

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

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

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

다음 단계#

SAST를 활성화한 후 다음을 수행할 수 있습니다:

• 결과 이해하기에 대해 자세히 알아보세요.

• 최적화 팁을 검토하세요.

• 더 많은 프로젝트로의 롤아웃을 계획하세요.

결과 이해하기#

전제 조건:

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

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

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

• 왼쪽 사이드바에서 Build > Pipelines를 선택합니다.

• 파이프라인을 선택합니다.

• Security 탭을 선택합니다.

• 결과를 다운로드하거나, 취약점을 선택하여 세부 정보를 확인합니다(Ultimate 전용). 세부 정보는 다음을 포함합니다:

설명: 취약점의 원인, 잠재적 영향 및 권장 수정 단계를 설명합니다.

• 상태: 취약점이 분류되었거나 해결되었는지 여부를 나타냅니다.

• 심각도: 영향에 따라 6개의 수준으로 분류됩니다. 심각도 수준에 대해 자세히 알아보기.

• 위치: 문제가 발견된 파일명과 줄 번호를 표시합니다. 파일 경로를 선택하면 코드 보기에서 해당 줄이 열립니다.

• 스캐너: 취약점을 탐지한 분석기를 식별합니다.

• 식별자: CWE 식별자 및 탐지한 규칙 ID 등 취약점을 분류하는 데 사용되는 참조 목록입니다.

SAST 취약점은 발견된 취약점의 기본 공통 취약점 열거(Common Weakness Enumeration, CWE) 식별자에 따라 명명됩니다. 각 취약점 결과의 설명을 읽어 스캐너가 탐지한 특정 문제에 대해 자세히 알아보세요. SAST 커버리지에 대한 자세한 내용은 SAST 규칙을 참조하세요.

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

전제 조건:

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

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

• 왼쪽 사이드바에서 Build > Pipelines를 선택합니다.

• 파이프라인을 선택합니다.

• Security 탭을 선택합니다.

• 파이프라인의 Security 탭에서 Download results를 선택합니다.

자세한 내용은 파이프라인 보안 리포트를 참조하세요.

SAST 결과를 확인하는 추가적인 방법:

• 머지 리퀘스트 위젯: 새로 도입되거나 해결된 결과를 표시합니다.

• 머지 리퀘스트 변경 사항 보기: 변경된 줄에 대한 인라인 주석을 표시합니다.

• 취약점 리포트: 기본 브랜치의 확인된 취약점을 표시합니다.

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

머지 리퀘스트 리포트#

머지 리퀘스트에서 SAST 결과를 확인하려면 머지 리퀘스트 리포트를 참조하세요.

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

DETAILS: Tier: Ultimate

히스토리

• sast_reports_in_inline_diff라는 플래그와 함께 GitLab 16.6에서 도입되었습니다. 기본적으로 비활성화되어 있습니다.

• GitLab 16.8에서 기본적으로 활성화되었습니다.

• GitLab 16.9에서 기능 플래그가 제거되었습니다.

SAST 결과는 머지 리퀘스트 Changes 보기에 표시됩니다. SAST 이슈가 포함된 줄은 여백 옆에 기호로 표시됩니다. 기호를 선택하면 이슈 목록이 표시되고, 이슈를 선택하면 세부 정보를 확인할 수 있습니다.

[

](/19.2/user/application_security/sast/img/sast_inline_indicator_v16_7.png)

최적화#

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

• 규칙 비활성화.

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

규칙 비활성화#

전제 조건:

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

예를 들어 거짓 양성이 너무 많이 생성되는 경우 규칙을 비활성화하려면:

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

• 아직 없는 경우 프로젝트 루트에 .gitlab/sast-ruleset.toml 파일을 생성합니다.

• 취약점 세부 정보에서 결과를 트리거한 규칙의 ID를 찾습니다.

• 규칙 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 설정을 적용합니다.

• 원격 구성 파일 지정으로 중앙 룰셋을 공유하고 재사용합니다.

• 고유한 요구 사항이 있는 경우 SAST는 오프라인 환경 또는 SELinux 제약 조건에서도 실행할 수 있습니다.

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

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

사용 가능한 스캔 옵션은 GitLab 티어에 따라 다릅니다:

• Ultimate에서는 GitLab Advanced SAST가 더 정확한 결과를 제공합니다. 지원하는 언어에 대해서는 이를 사용해야 합니다.

• 모든 티어에서 오픈 소스 스캐너를 기반으로 하는 GitLab 제공 분석기를 사용하여 코드를 스캔할 수 있습니다.

SAST의 언어 지원 계획에 대한 자세한 내용은 카테고리 방향 페이지를 참조하세요.

완전 지원 언어#

히스토리

• GitLab 18.6에서 C/C++ 지원이 도입되었습니다.

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

각주:

• GitLab Advanced SAST - Ultimate 티어 전용.

• 모든 티어. 별도 명시가 없는 경우 GitLab 관리 규칙이 포함된 Semgrep 분석기를 사용합니다.

• Java Server Pages(JSP) 및 Android 포함.

• Node.js 및 React 포함.

• Ruby on Rails 포함.

• YAML 지원은 다음 파일 패턴으로 제한됩니다:

application*.yml

• application*.yaml

• bootstrap*.yml

• bootstrap*.yaml

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

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

각주:

• 모든 티어. 별도 명시가 없는 경우 GitLab 관리 규칙이 포함된 Semgrep 분석기를 사용합니다.

• 참조된 에픽은 해당 언어에 대한 GitLab Advanced SAST 지원을 제안합니다.

• find-sec-bugs 플러그인이 포함된 SpotBugs. Gradle, Maven, SBT를 지원합니다. Gradle 래퍼, Grails, Maven 래퍼 등의 변형과도 함께 사용할 수 있습니다. 그러나 SpotBugs는 Ant 기반 프로젝트에 사용 시 제한 사항이 있습니다. Ant 기반 Java 또는 Scala 프로젝트에는 GitLab Advanced SAST 또는 Semgrep 기반 분석기를 사용해야 합니다.

• Android 포함.

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 15.9에서 sec_mark_dropped_findings_as_resolved라는 프로젝트 플래그와 함께 도입되었습니다.

• GitLab 15.10에서 기본적으로 활성화되었습니다.

• GitLab 16.2에서 기능 플래그가 제거되었습니다.

여전히 관련 있는 취약점에 집중할 수 있도록 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를 수정해야 합니다.

Rust 애플리케이션 스캔#

전제 조건:

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

Rust 애플리케이션을 스캔하려면 다음 단계를 완료합니다:

• Rust에 대한 커스텀 룰셋을 제공합니다. 리포지터리 루트의 .gitlab/ 디렉터리에 sast-ruleset.toml이라는 파일을 생성합니다.

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

[semgrep]
  description = "Rust ruleset for Semgrep"
  targetdir = "/sgrules"
  timeout = 60

  [[semgrep.passthrough]]
    type  = "url"
    value = "https://semgrep.dev/c/p/rust"
    target = "rust.yml"

자세한 내용은 사전 정의된 규칙 교체 또는 추가를 참조하세요.

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

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

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

semgrep-sast:
  rules:
    - if: $CI_COMMIT_BRANCH
      exists:
        - '**/*.rs'
        # 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 프로젝트의 컴파일된 바이트코드를 스캔합니다. 기본적으로 스캔할 수 있도록 의존성을 자동으로 가져오고 코드를 컴파일하려 시도합니다.

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

• 프로젝트에 커스텀 빌드 구성이 필요한 경우.

• 분석기에 내장되지 않은 언어 버전을 사용하는 경우.

이러한 문제를 해결하려면 분석기의 컴파일 단계를 건너뛰고 파이프라인의 이전 Stage에서 아티팩트를 직접 제공합니다. 이 전략을 사전 컴파일(pre-compilation)이라고 합니다.

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

전제 조건:

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

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

• 컴파일 job(일반적으로 build라고 함)을 사용하여 프로젝트를 컴파일하고, CI/CD artifacts: paths 변수를 사용하여 컴파일된 출력을 job artifact로 저장합니다.

Maven 프로젝트의 경우 출력 폴더는 일반적으로 target 디렉터리입니다.

• Gradle 프로젝트의 경우 일반적으로 build 디렉터리입니다.

• 프로젝트에서 커스텀 출력 위치를 사용하는 경우 아티팩트 경로를 적절히 설정합니다.

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

• 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 파일에 다음 변경 사항을 적용합니다:

• 로컬 Maven 리포지터리를 가리키도록 MAVEN_REPO_PATH 변수를 설정합니다.

• 빌드 job이 해당 경로에 리포지터리를 생성하도록 합니다(예: mvn package -Dmaven.repo.local=./.m2/repository 실행).

• 빌드 job에 의존하고 컴파일을 비활성화하도록 spotbugs-sast 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 변수는 스캔할 파일과 분석기가 코드베이스를 얼마나 철저하게 검색하는지를 제어합니다.

각주:

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

• 이러한 분석기의 경우 SAST_EXCLUDED_PATHS는 스캔이 실행되기 전에 적용되는 **사전 필터(pre-filter)**로 구현됩니다.

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

예를 들어 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 스타일 패턴입니다.

• 이러한 분석기의 경우 SAST_EXCLUDED_PATHS는 스캔이 실행된 후에 적용되는 **사후 필터(post-filter)**로 구현됩니다.

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

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

사전 필터와 사후 필터를 모두 지원하는 분석기의 경우 사전 필터가 먼저 적용되고, 그런 다음 남아 있는 취약점에 사후 필터가 적용됩니다.

• 이 변수의 경우 경로 패턴은 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와 같이 상위 디렉터리를 패턴으로 전달하면 이 경우 빌드 파일이 패턴에 의해 명시적으로 일치하지 않으므로 디렉터리가 빌드에서 제외되지 않습니다.

• 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로 설정할 수 있습니다. 그러나 오프라인 환경이 아닌 경우에는 pull 정책 설정을 always로 유지하세요. 이 설정을 통해 CI/CD 파이프라인에서 업데이트된 스캐너를 사용할 수 있습니다.

Docker 레지스트리 내부에서 GitLab SAST 분석기 이미지 사용 가능하게 하기#

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

registry.gitlab.com/security-products/gitlab-advanced-sast:2
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 파일에서 CI/CD 변수 SECURE_ANALYZERS_PREFIX를 로컬 Docker 컨테이너 레지스트리를 참조하도록 정의합니다.

예를 들어:

variables:
  SECURE_ANALYZERS_PREFIX: "localhost:5000/analyzers"

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

패키지의 인증서 확인 구성#

SAST job이 패키지 관리자를 호출하는 경우 인증서 확인을 구성해야 합니다. 오프라인 환경에서는 외부 소스와의 인증서 확인이 불가능합니다. 자체 서명 인증서를 사용하거나 인증서 확인을 비활성화하세요. 지침은 패키지 관리자 문서를 참조하세요.

SELinux에서 SAST 실행#

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