히스토리

• Python용 실험으로 GitLab 17.1에서 도입되었습니다.
• 17.2에서 Go 및 Java 지원이 추가되었습니다.
• GitLab 17.2에서 실험에서 베타로 변경되었습니다.
• 17.3에서 JavaScript, TypeScript, C# 지원이 추가되었습니다.
• GitLab 17.3에서 일반 공개되었습니다.
• GitLab 17.4에서 Java Server Pages(JSP) 지원이 추가되었습니다.
• GitLab 18.1에서 PHP 지원이 추가되었습니다.
• GitLab 18.6에서 C/C++ 지원이 추가되었습니다.
• GitLab 19.3에서 Swift 및 Objective-C 지원이 베타로 추가되었습니다.

GitLab Advanced SAST는 교차 함수 및 교차 파일 오염 분석을 사용해 전통적인 SAST보다 거짓 양성을 줄이면서 복잡한 취약점을 탐지하는 정적 애플리케이션 보안 테스트(SAST) 분석기입니다.

GitLab Advanced SAST를 활성화하면 사전 정의된 규칙셋으로 지원되는 모든 언어 파일을 스캔합니다. Semgrep 기반 SAST 분석기는 일부 언어의 스캔을 중단하고 나머지 언어는 계속 보고합니다. SAST와 GitLab Advanced SAST의 탐지 범위는 완전히 같지 않습니다. 각 분석기는 다른 쪽이 탐지하지 못하는 취약점을 탐지합니다. 두 분석기가 같은 취약점을 탐지하면 자동화된 전환 프로세스가 중복 발견 항목을 제거합니다.

GitLab Advanced SAST는 표준 Semgrep 기반 SAST 분석기보다 더 깊은 분석을 수행합니다. 이 포괄적인 접근은 정확도를 높이고 거짓 양성을 줄일 수 있지만, 더 많은 컴퓨팅 리소스와 더 긴 스캔 시간이 필요합니다.

개요는 GitLab Advanced SAST: Accelerating Vulnerability Resolution을 참고합니다.

제품 투어는 GitLab Advanced SAST 제품 투어를 참고합니다.

기능#

GitLab Advanced SAST 켜기#

프로젝트에서 GitLab Advanced SAST를 켜려면 다음 단계를 따릅니다.

사전 요구 사항:

• 프로젝트에 대한 Maintainer 또는 Owner 권한.
• 표준 SAST 분석기를 켭니다. 자세한 내용은 SAST 사전 요구 사항을 참고합니다.
• 프로젝트에 자동 해결 정책이 적용되고 Semgrep 취약점이 있다면 먼저 기존 Semgrep 취약점을 검토합니다.
• GitLab Self-Managed에서는 지원되는 GitLab 버전을 사용합니다:
  • 최소 버전: GitLab 17.1 이상
  • 권장 버전: GitLab 17.4 이상(코드 흐름 보기, 취약점 중복 제거, 갱신된 템플릿 포함)
  • 템플릿 호환성:
    • 안정 템플릿: GitLab 17.3 이상
    • 최신 템플릿: GitLab 17.2 이상
    • 같은 프로젝트에서 안정 템플릿과 최신 템플릿을 섞어 쓰지 않습니다

GitLab Advanced SAST 켜기:

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

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

3. .gitlab-ci.yml 파일을 생성하거나 편집합니다.

4. Advanced SAST를 활성화하는 적절한 변수를 추가합니다:

   • C/C++를 제외한 모든 지원 언어: GITLAB_ADVANCED_SAST_ENABLED: 'true'

   • C/C++: GITLAB_ADVANCED_SAST_CPP_ENABLED: 'true'

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

   Simulation completed successfully 메시지는 파일이 유효함을 확인해 줍니다.

6. Edit 탭을 선택합니다.

7. 필드를 입력합니다.

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

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

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

이 시점에서 GitLab Advanced SAST가 파이프라인에서 활성화됩니다. 파이프라인이 실행되면 지원되는 소스 코드에서 취약점을 스캔합니다. 해당 job은 파이프라인의 test Stage에 표시됩니다.

이 단계를 완료한 뒤에는 다음을 할 수 있습니다:

• 취약점 결과를 평가하는 방법을 자세히 알아봅니다.
• 스캔 성능 팁을 검토합니다.
• 더 많은 프로젝트로 확대하는 계획을 세웁니다.

취약점 결과#

GitLab Advanced SAST 취약점에는 보안 문제를 평가하고 수정하는 데 도움이 되는 상세 정보가 포함됩니다. 각 취약점에는 다음이 표시됩니다:

• 설명: 취약점의 원인, 잠재적 영향, 권장 수정 단계를 설명합니다.
• 상태: 취약점이 심사되었는지 또는 해결되었는지 나타냅니다.
• 심각도: 영향에 따라 6개 수준으로 분류됩니다. 심각도 수준 자세히 알아보기.
• 위치: 문제가 발견된 파일명과 줄 번호를 표시합니다. 파일 경로를 선택하면 코드 보기에서 해당 줄이 열립니다.
• 코드 흐름: 사용자 입력(소스)에서 취약한 코드 줄까지 데이터가 이동하는 경로입니다.
• 스캐너: 취약점을 탐지한 분석기를 식별합니다.
• 식별자: CWE 식별자와 취약점을 탐지한 규칙의 ID처럼 취약점을 분류하는 데 사용되는 참조 목록입니다.

SAST 취약점은 발견된 취약점의 기본 공통 취약점 열거(Common Weakness Enumeration, CWE) 식별자에 따라 이름이 정해집니다. SAST 커버리지에 대한 자세한 내용은 SAST 규칙을 참고합니다.

결과 보기#

사전 요구 사항:

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

파이프라인에서 취약점을 보려면 다음과 같이 합니다:

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Build > Pipelines를 선택합니다.
3. 파이프라인을 선택합니다.
4. Security 탭을 선택합니다.
5. 결과를 내려받거나, 취약점을 선택해 세부 정보를 확인합니다(Ultimate 전용).

코드 흐름#

히스토리

• GitLab 17.3에서 여러 플래그와 함께 도입되었습니다. 기본적으로 활성화됩니다.
• GitLab 17.7에서 GitLab Self-Managed 및 GitLab Dedicated에서 활성화되었습니다.
• GitLab 17.7에서 일반 공개되었습니다. 모든 기능 플래그가 제거되었습니다.

특정 유형의 취약점에 대해 GitLab Advanced SAST는 코드 흐름 정보를 제공합니다. 취약점의 코드 흐름은 사용자 입력(소스)에서 취약한 코드 줄(싱크)까지 모든 할당, 조작, 정제를 거쳐 데이터가 이동하는 경로입니다. 이 정보는 취약점의 컨텍스트, 영향, 위험을 이해하고 평가하는 데 도움이 됩니다. 코드 흐름 정보는 소스에서 싱크까지 입력을 추적해 탐지하는 취약점에 제공되며, 다음이 포함됩니다:

• SQL 인젝션
• 명령 인젝션
• 교차 사이트 스크립팅(XSS)
• 경로 순회

코드 흐름 정보는 취약점 세부 정보 페이지의 Data flow 섹션에 표시되며 다음이 포함됩니다:

• 소스에서 싱크까지의 단계.
• 코드 스니펫을 포함한 관련 파일.

지원 언어#

히스토리

• GitLab 18.6에서 C# 버전 지원이 10.0에서 13.0으로 확대되었습니다.
• GitLab 19.4에서 Dart 지원이 베타로 추가되었습니다.
• GitLab 19.4에서 Scala 지원이 베타로 추가되었습니다.
• GitLab 19.4에서 Kotlin 지원이 베타로 추가되었습니다.
• GitLab 19.5에서 Rust 지원이 베타로 추가되었습니다.

GitLab Advanced SAST는 다음 언어를 지원합니다:

• C#(13.0까지 포함)
• C/C++
• Dart(베타)
• Go
• Java, Java Server Pages(JSP) 포함
• JavaScript, TypeScript
• Kotlin(베타)
• Objective-C(베타)
• PHP
• Python
• Ruby
• Rust(베타)
• Scala(베타)
• Swift(베타)

GitLab Advanced SAST CPP는 컴파일 데이터베이스를 포함한 추가 구성이 필요합니다. 자세한 내용은 C/C++ 구성을 참고합니다. C/C++ 프로젝트에서는 GitLab Advanced SAST CPP와 Semgrep이 모두 실행되며, 각각 다른 규칙셋을 사용합니다.

Dart, Kotlin, Objective-C, Rust, Scala, Swift 지원은 베타 단계입니다. GitLab Advanced SAST가 활성화되고 리포지터리에 이 언어 중 하나의 파일이 있으면 분석은 별도의 CI/CD job인 gitlab-advanced-sast-ext로 실행됩니다. 추가 변수는 필요하지 않습니다. Swift와 Objective-C는 Swift 및 Objective-C 구성을 참고합니다.

Kotlin, Objective-C, Scala, Swift에서는 semgrep-sast도 함께 실행되며, gitlab-advanced-sast-ext는 Semgrep이 이미 보고하는 약점을 semgrep-sast에 맡깁니다. 그래서 같은 약점 분류가 두 번 보고되지 않습니다. Kotlin의 경우 CWE-89, CWE-78, CWE-22, CWE-79, CWE-327, CWE-295가 해당합니다. Swift의 경우 Keychain 접근성 검사(CWE-922)가 해당합니다. 이 동작을 변경하거나 끄려면 GITLAB_ADVANCED_SAST_EXT_DEDUP_LANGUAGES를 사용합니다. Dart와 Rust에서는 SAST 템플릿이 .dart 또는 .rs 파일을 semgrep-sast로 전달하지 않으므로 semgrep-sast가 실행되지 않습니다.

C/C++를 제외하고 이 목록에 있는 다른 언어는 GitLab Advanced SAST를 활성화하면 semgrep-sast가 해당 파일의 스캔을 중단합니다.

PHP 알려진 문제#

PHP 코드를 분석할 때 GitLab Advanced SAST에는 다음과 같은 알려진 문제가 있습니다:

• 동적 파일 포함: 파일 경로에 변수를 사용하는 동적 파일 포함 문(include, include_once, require, require_once)은 이 릴리스에서 지원되지 않습니다. 교차 파일 분석에서는 정적 파일 포함 경로만 지원됩니다. 이슈 527341을 참고합니다.
• 대소문자 구분: 함수 이름, 클래스 이름, 메서드 이름에 대해 대소문자를 구분하지 않는 PHP의 특성은 교차 파일 분석에서 완전히 지원되지 않습니다. 이슈 526528을 참고합니다.

스캔 성능 개선#

GitLab Advanced SAST 스캔 성능은 주로 코드 커버리지와 러너 리소스로 결정됩니다. GitLab Advanced SAST 스캔 성능을 개선하려면 코드 커버리지와 러너 리소스를 조정할 수 있습니다.

스캔 성능 진단#

설정을 변경하기 전에 무엇이 느린지 찾습니다. GitLab Advanced SAST는 스캔마다 스캔 시간이 어디에 쓰이는지 보여 주는 타이밍 아티팩트 두 개를 생성할 수 있습니다. 이 아티팩트는 기본적으로 업로드되지 않습니다.

아티팩트를 수집하려면 .gitlab-ci.yml 파일에 있는 job의 기존 artifacts 구성에 다음 경로를 추가합니다:

gitlab-advanced-sast:
  artifacts:
    paths:
      - '**/scan_metrics.csv'
      - '**/lightz_times.json'
    when: always

이 job에서 이미 artifacts를 재정의하고 있다면(예: 증분 스캔을 위해), 기존 artifacts.paths 목록에 이 경로들을 추가합니다. gitlab-advanced-sast 블록을 두 번째로 추가하면 SAST 리포트 같은 다른 아티팩트가 빠질 수 있습니다.

scan_metrics.csv와 lightz_times.json에는 규칙별, 파일별 타이밍 정보가 담깁니다. 이 정보로 스캔에 가장 오래 걸리는 규칙과 파일을 찾을 수 있습니다. scan_metrics.csv는 스프레드시트에서 타이밍 칼럼을 기준으로 정렬할 수 있습니다. lightz_times.json에는 파일별로 더 상세한 타이밍이 담기며 GitLab 지원팀이 해석을 도울 수 있습니다. 분석기는 job이 성공적으로 완료될 때만 이 아티팩트를 생성합니다. 타임아웃된 job은 생성하지 않습니다. job이 타임아웃되고 있다면 먼저 스캔이 완료될 수 있도록 job timeout을 늘린 다음 아티팩트를 수집합니다.

가장 느린 규칙과 파일을 확인한 뒤에는 경로를 제외하거나 특정 규칙을 비활성화할 수 있습니다.

코드 커버리지 조정#

코드 커버리지는 코드베이스가 얼마나 많이 분석되는지를 나타냅니다. GitLab Advanced SAST는 사전 정의된 규칙셋으로 지원되는 모든 언어 파일을 스캔합니다. Semgrep 기반 SAST 분석기는 이 파일들을 스캔하지 않습니다. 두 분석기가 같은 취약점을 탐지하면 자동화된 전환 프로세스가 중복 발견 항목을 제거합니다.

선택적으로 소스에서 싱크까지의 전체 경로가 식별되지 않는 미검증 취약점을 보고할 수 있습니다.

기본적으로 GitLab Advanced SAST는 리포지터리 전체를 스캔합니다. 다음 방법으로 코드 커버리지를 조정할 수 있습니다:

• 리포지터리 경로를 제외해 분석하는 코드 양을 줄입니다.
• 인라인 주석으로 개별 줄을 제외해 특정 발견 항목을 억제합니다.
• 차등 스캔을 켜서 머지 리퀘스트에서 수정된 파일(및 그 종속 파일)만 분석합니다.
• 증분 스캔을 켜서 이전 스캔 결과를 캐시하고 컴퓨팅 부하를 줄입니다.

차등 스캔과 증분 스캔은 독립적으로 또는 함께 사용해 스캔 성능을 개선할 수 있습니다.

차등 스캔 : 머지 리퀘스트 연관 파이프라인(머지 리퀘스트 파이프라인 또는 머지 리퀘스트와 연관된 브랜치 파이프라인)에서 변경된 파일과 그 종속 파일만 스캔하며, 전체 커버리지 대신 속도를 택합니다.

증분 스캔 : 이전 스캔 결과를 캐시해 이후 파이프라인에서 재사용하므로, 전체 파일 커버리지를 유지하면서 스캔 시간을 줄입니다. 모든 파이프라인에서 사용할 수 있습니다.

경로 제외#

스캔 시간을 줄이려면 취약점이 있을 가능성이 낮은 경로를 GitLab Advanced SAST 스캔에서 제외합니다.

경로를 제외할 때는 취약점을 숨기지 않도록 선별적으로 처리합니다. 변경은 점진적으로 하고 제외할 때마다 스캔 시간에 미치는 영향을 테스트합니다.

GitLab Advanced SAST는 테스트, node_modules, vendor, 빌드 출력을 포함한 여러 일반적인 경로를 기본적으로 제외합니다. 기본값이 다루지 않는 프로젝트 고유의 추가 경로에는 SAST_EXCLUDED_PATHS를 사용합니다.

다음을 포함하는 경로를 제외하는 것을 검토합니다:

• 데이터베이스 마이그레이션
• 단위 테스트
• node_modules/ 같은 의존성
• 빌드 파일
• 구성 정보
• 정적 에셋
• 테스트 데이터
• 코드형 인프라

제외 후보를 찾으려면 리포지터리의 파일 유형 분포를 나열합니다:

git ls-files | grep -o '\.[^.]*$' | sort | uniq -c | sort -nr

번들된 UI 의존성이 흔한 후보입니다. 예를 들어 swagger-ui 또는 swagger-ui-dist/ 디렉터리를 제외하면 스캔 시간을 줄일 수 있습니다. 번들 파일이 스캔 시간을 늘리기 때문입니다. 와일드카드 패턴 **/*.min.js도 최소화된 콘텐츠를 제외합니다.

사전 요구 사항:

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

경로를 제외하려면 다음과 같이 합니다:

• SAST_EXCLUDED_PATHS CI/CD 변수에 제외할 경로를 나열합니다.

제외를 추가한 뒤에는 발견 항목 수를 이전 전체 스캔과 비교합니다. 수가 줄었다면 실제 코드가 있는 경로를 제외했다는 신호일 수 있습니다. 각 패턴이 무엇을 제거했는지 검토하고 필요하면 제외 범위를 좁힙니다.

발견 항목 수는 제외한 파일 수와 직접 대응하지 않습니다. 합계보다는 변경이 어떤 경로에 영향을 주었는지로 판단합니다. 부하가 걸리면 파일마다 타임아웃(GITLAB_ADVANCED_SAST_RULE_TIMEOUT)에 도달한 규칙을 건너뛸 수 있으므로, 실행마다 어느 정도 차이가 날 수 있습니다. 특정 제외 경로와 연결되어 지속적으로 줄어든다면 커버리지가 사라졌다는 신호일 가능성이 더 높습니다.

줄 제외#

특정 줄의 발견 항목을 억제하려면 소스 코드에 gitlab-advanced-sast-exclude를 주석으로 추가합니다. 이 태그는 대소문자를 구분하지 않으며 #, //, -- 등 모든 주석 문법에서 동작합니다.

주석은 발견 항목과 같은 줄에 두거나, 바로 앞 줄에 둡니다:

# Suppress all findings on the next line (previous-line comment):
# gitlab-advanced-sast-exclude
result = db.execute(query)

# Suppress all findings inline:
result = db.execute(query)  # gitlab-advanced-sast-exclude

특정 규칙의 발견 항목만 억제하려면 : 또는 =를 붙인 다음 쉼표로 구분한 규칙 ID를 하나 이상 적습니다:

# gitlab-advanced-sast-exclude: rule-id-1, rule-id-2
result = db.execute(query)

규칙 ID를 지정하지 않으면 해당 줄의 모든 발견 항목이 억제됩니다.

차등 스캔#

히스토리

• GitLab 18.5에서 vulnerability_partial_scans라는 이름의 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
• GitLab 18.5에서 GitLab.com, GitLab Self-Managed, GitLab Dedicated에서 활성화되었습니다.
• GitLab 18.6에서 일반 공개되었습니다. 기능 플래그 vulnerability_partial_scans가 제거되었습니다.

차등 스캔은 머지 리퀘스트에서 수정된 파일과 그 종속 파일만 분석합니다. 이 표적 방식은 스캔 시간을 줄여 개발 중에 더 빠른 피드백을 제공합니다.

전체 커버리지를 보장하기 위해 머지 리퀘스트가 머지된 뒤 기본 브랜치에서 전체 스캔이 실행됩니다.

차등 스캔은 다음 조건에서 머지 리퀘스트 파이프라인과 브랜치 파이프라인 모두에서 지원됩니다:

• 머지 리퀘스트 파이프라인: GitLab Advanced SAST가 머지 리퀘스트 파이프라인에서 실행되도록 구성된 경우 차등 스캔이 수행됩니다.
• 브랜치 파이프라인: 브랜치에 연관된 열린 머지 리퀘스트가 정확히 하나일 때 차등 스캔이 수행됩니다. 없거나 둘 이상이면 브랜치를 어떤 커밋과 비교해야 하는지 판단할 수 없으므로 전체 스캔으로 되돌아갑니다.

차등 스캔이 활성 상태일 때는 다음과 같습니다:

• 머지 리퀘스트에서 수정되거나 추가된 파일과 그 종속 파일만 스캔됩니다.
• job 로그에 Running differential scan 출력이 포함됩니다. (비활성 상태이면 Running full scan을 출력합니다.)
• 머지 리퀘스트 보안 스캔 리포트에서 전용 Diff-based 탭이 관련 스캔 발견 항목을 보여 줍니다.
• 파이프라인 보안 탭에서 Partial SAST report 레이블이 붙은 알림은 일부 발견 항목만 포함되었음을 나타냅니다.

차등 스캔에는 다음과 같은 알려진 문제가 있습니다:

• 거짓 음성 및 거짓 양성: 차등 스캔은 스캔한 파일의 전체 호출 그래프를 파악하지 못할 수 있어, 취약점을 놓치거나(거짓 음성) 이미 해결된 취약점이 다시 나타날(거짓 양성) 수 있습니다. 이 절충은 스캔 시간을 줄이고 개발 중에 더 빠른 피드백을 제공합니다. 포괄적인 커버리지를 위해 기본 브랜치에서는 항상 전체 스캔이 실행됩니다.
• C/C++ 헤더 파일 커버리지: 차등 스캔은 C/C++ 헤더 파일을 완전히 지원하지 않습니다. 헤더 파일과 소스 파일에 걸친 취약점은 탐지할 수 있지만, 헤더 파일 안에만 있는 취약점은 탐지되지 않을 수 있습니다.
• 수정된 취약점 미보고: 오해를 일으키는 결과를 피하기 위해 차등 스캔에서는 수정된 취약점을 제외합니다. 파일의 일부만 분석하므로 전체 호출 그래프를 확보할 수 없고, 따라서 취약점이 수정되었는지 확인할 수 없습니다. 머지 후 기본 브랜치에서는 항상 전체 스캔이 실행되며, 거기에서 수정된 취약점이 보고됩니다. 그 결과 차등 스캔에서 생길 수 있는 공백은 기본 브랜치로 머지할 때 자동으로 실행되는 전체 스캔으로 완화되어 포괄적인 커버리지가 보장됩니다. 이 계층적 방식은 개발 중의 빠른 피드백 루프와 코드가 운영에 도달하기 전의 철저한 보안 분석 사이에서 균형을 맞춥니다.

차등 스캔 켜기#

사전 요구 사항:

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

머지 리퀘스트 파이프라인에서 차등 스캔을 켜려면 다음과 같이 합니다:

• 프로젝트의 .gitlab-ci.yml 파일에서 ADVANCED_SAST_PARTIAL_SCAN CI/CD 변수를 differential로 설정합니다.

종속 파일#

수정된 파일을 넘어서는 교차 파일 취약점을 놓치지 않도록, 차등 스캔은 직접 종속 파일을 포함합니다. 이렇게 하면 빠른 스캔을 유지하면서 거짓 음성을 줄이지만, 더 깊은 의존성 체인에서는 부정확한 결과가 나올 수 있습니다.

스캔에 포함되는 파일은 다음과 같습니다:

• 수정된 파일(머지 리퀘스트에서 변경되거나 추가된 파일)
• 종속 파일(수정된 파일을 임포트하는 파일)

이 설계는 수정된 함수에서 그 함수를 임포트하는 호출자로 오염된 데이터가 이동하는 것처럼 교차 파일 데이터 흐름을 탐지하는 데 도움이 됩니다.

수정된 파일이 임포트하는 파일은 일반적으로 수정된 코드의 동작이나 데이터 흐름에 영향을 주지 않으므로 스캔하지 않습니다.

예를 들어 파일 B를 수정하는 머지 리퀘스트를 생각해 봅니다:

• 파일 A가 파일 B를 임포트하면 파일 A와 B가 스캔됩니다.
• 파일 B가 파일 C를 임포트하면 파일 B만 스캔됩니다.

증분 스캔#

히스토리

• GitLab 18.11에서 도입되었습니다.

증분 스캔은 파이프라인 실행 사이에 오염 서명 분석 결과를 캐시합니다. 이후 스캔에서는 변경되지 않은 코드가 다시 분석되지 않고 캐시된 서명을 재사용하며, 변경되거나 새로 추가된 코드는 전체 분석됩니다. 이렇게 하면 커밋 사이에 대부분의 파일이 변경되지 않는 대규모 코드베이스에서 스캔 시간이 줄어듭니다.

증분 스캔은 다음과 같이 동작합니다:

1. 첫 스캔(콜드 런): 분석기가 전체 분석을 수행하고 오염 서명 캐시를 생성합니다. 캐시는 CI 아티팩트(ts-cache.sqlite.gz)로 저장됩니다.
2. 이후 스캔(웜 런): 분석기가 이전 커밋에서 캐시 아티팩트를 담은 성공한 파이프라인을 찾습니다. 찾으면 캐시를 가져와 변경되지 않은 결과를 재사용합니다. 스캔이 완료되면 갱신된 캐시가 새 아티팩트로 저장됩니다.

분석기가 캐시를 가져올 수 없으면 전체 스캔을 실행하므로 스캔 속도는 개선되지 않습니다. 다음과 같은 경우에 발생할 수 있습니다:

• 아직 캐시 아티팩트가 있는 이전 파이프라인이 없는 경우(예: 첫 실행).
• 캐시 아티팩트가 만료되었거나 GITLAB_ADV_SAST_INCR_SCAN_SEARCH_PERIOD 범위를 벗어난 경우.
• GITLAB_ADV_SAST_INCR_SCAN_CUSTOM_JOB_NAME을 설정하지 않고 job 이름을 바꾼 경우.
• 캐시가 아티팩트 크기 제한을 초과한 경우.

증분 스캔으로 스캔 속도가 개선되지 않으면 job 로그에서 다음으로 시작하는 줄을 확인합니다. 콜론 뒤의 사유를 읽습니다:

Failed to retrieve cache, continuing without cache:

캐시 무효화#

정확성을 보장하면서 재사용을 최대화하기 위해 캐시가 무효화됩니다:

부분 무효화: 영향받은 항목만 다시 계산하고 나머지 캐시는 재사용합니다:

• 신규 또는 변경된 파일: 파일이 추가, 수정, 삭제되거나 이름이 바뀌면 그 파일의 캐시된 서명이 무효화되고 다음 스캔에서 다시 계산됩니다.
• 신규 또는 변경된 규칙: 탐지 규칙이 추가되거나 수정되면 해당 규칙만 코드베이스에 대해 다시 계산됩니다.

전체 무효화: 캐시 전체를 다시 만듭니다:

• 엔진 변경: 엔진 수준 변경으로 기존 캐시가 호환되지 않게 되면 전체 스캔에서 새 캐시가 자동으로 생성됩니다.

증분 스캔 켜기#

증분 스캔을 켜려면 다음과 같이 합니다:

• 프로젝트의 .gitlab-ci.yml 파일에서 GITLAB_ADV_SAST_INCR_SCAN CI/CD 변수를 true로 설정합니다:

  gitlab-advanced-sast:
    variables:
      GITLAB_ADV_SAST_INCR_SCAN: "true"
  

캐시 보존 구성#

SAST CI/CD 템플릿은 캐시 아티팩트의 만료 기간을 설정하지 않으므로 인스턴스의 Default artifacts expiration 설정을 따릅니다. GITLAB_ADV_SAST_INCR_SCAN_SEARCH_PERIOD 변수는 분석기가 캐시 아티팩트를 얼마나 과거까지 검색하는지 제어합니다(기본값: 3 days).

검색 기간이 아티팩트 만료 기간을 초과하면 분석기가 이미 만료된 아티팩트를 검색합니다.

캐시의 만료 기간을 명시적으로 설정하고 검색 기간을 거기에 맞추려면 artifacts:expire_in을 재정의하고 검색 기간 변수를 설정합니다. expire_in은 artifacts 블록 전체에 적용되므로 보안 리포트가 보관되는 기간도 함께 바뀝니다:

gitlab-advanced-sast:
  variables:
    GITLAB_ADV_SAST_INCR_SCAN: "true"
    GITLAB_ADV_SAST_INCR_SCAN_SEARCH_PERIOD: "7 days"
  artifacts:
    paths:
      - gl-sast-report.json
      - ts-cache.sqlite.gz
    expire_in: 7 days

검색 기간은 숫자 뒤에 d, day 또는 days를 붙인 형식을 지원합니다(예: 7 days, 14d).

사용자 정의 job 이름 구성#

분석기는 CI/CD job 이름으로 어느 job의 아티팩트에 캐시가 있는지 식별합니다. gitlab-advanced-sast job의 이름을 바꿨다면 캐시 조회가 올바른 job을 찾도록 GITLAB_ADV_SAST_INCR_SCAN_CUSTOM_JOB_NAME에 그 사용자 정의 이름을 설정합니다:

my-custom-sast-job:
  variables:
    GITLAB_ADV_SAST_INCR_SCAN: "true"
    GITLAB_ADV_SAST_INCR_SCAN_CUSTOM_JOB_NAME: "my-custom-sast-job"

캐시 크기 제한#

캐시는 압축된 CI/CD 아티팩트로 저장됩니다. 아티팩트 크기 제한이 적용됩니다:

• GitLab.com: 최대 아티팩트 크기 1 GB.
• GitLab Self-Managed: 기본 최대 아티팩트 크기 100 MB. 관리자는 CI/CD 설정에서 이 제한을 조정할 수 있습니다.

외부 오브젝트 스토리지에 캐시 저장#

CI/CD 아티팩트 스토리지 대신 증분 스캔 캐시를 외부 오브젝트 스토리지에 저장할 수 있습니다. 아티팩트 스토리지 제한이 제약이 되거나 캐시 수명 주기를 독립적으로 관리하려는 경우 이 저장 방식을 사용합니다. AWS S3를 지원합니다.

인증은 OpenID Connect(OIDC)를 사용해 클라우드 공급자와 단기 토큰을 교환합니다. 장기 자격 증명을 CI/CD 변수로 저장할 필요는 없습니다.

사전 요구 사항:

• S3 버킷.
• GitLab용으로 구성된 IAM OIDC 자격 증명 공급자.
• 버킷에 대해 다음 권한을 가진 IAM 역할:
  • s3:GetObject
  • s3:PutObject
  • s3:HeadObject
• IAM 역할의 신뢰 정책은 액세스가 필요한 프로젝트 또는 그룹으로 범위를 좁혀야 합니다 (예: 그룹의 모든 프로젝트에는 project_path:myorg/*).

S3에 캐시를 저장하려면 다음과 같이 합니다:

1. .gitlab-ci.yml에 다음 구성을 추가합니다:

   gitlab-advanced-sast:
     id_tokens:
       GITLAB_ADV_SAST_INCR_SCAN_OIDC_TOKEN:
         aud: https://gitlab.com
     variables:
       GITLAB_ADV_SAST_INCR_SCAN: "true"
       GITLAB_ADV_SAST_INCR_SCAN_STORAGE: "s3"
       GITLAB_ADV_SAST_INCR_SCAN_S3_BUCKET: "advanced-sast-cache"
       GITLAB_ADV_SAST_INCR_SCAN_S3_REGION: "us-east-1"
       GITLAB_ADV_SAST_INCR_SCAN_S3_ROLE_ARN: "arn:aws:iam::<account-id>:role/<role-name>"
   

2. GitLab Self-Managed 또는 GitLab Dedicated에서는 aud: https://gitlab.com을 GitLab 인스턴스 URL로 바꿉니다.

3. 캐시 객체가 자동으로 만료되도록 S3 수명 주기 정책을 구성합니다.

   오래된 캐시 파일이 남지 않도록 만료 기간은 GITLAB_ADV_SAST_INCR_SCAN_SEARCH_PERIOD 값(기본값: 3일)에 맞춰야 합니다.

캐시는 S3의 <project-path>/<commit-sha>/ts-cache.sqlite.gz에 저장됩니다. 분석기는 부모 커밋에서 가장 최근 캐시를 검색하며, 이는 아티팩트 기반 캐싱 동작과 같습니다.

미검증 취약점 보고#

히스토리

• GitLab 18.11에서 베타로 도입되었습니다.

GitLab Advanced SAST는 오염 분석을 사용해 신뢰할 수 없는 소스에서 취약한 싱크까지의 데이터 흐름을 추적합니다. 기본적으로 분석기는 전체 경로를 추적할 수 있을 때만 취약점을 보고하며, 이는 커버리지보다 정확도를 우선합니다. 더 많은 잠재적 데이터 흐름을 탐지하려면 미검증 취약점을 활성화할 수 있습니다. 이 기능은 전체 데이터 흐름 경로를 확정할 수 없을 때도 발견 항목을 보고하므로 커버리지가 늘어나지만 거짓 양성 수도 늘어날 수 있습니다.

미검증 취약점 보고를 활성화하면 분석기는 부분 오염 흐름이 탐지되었지만 소스에서 싱크까지 완전히 검증할 수 없었던 발견 항목도 보고합니다. 이런 근접 발견 항목은 위험한 코드가 악용 가능해지기 전에 찾아 선제적으로 고치는 데 도움이 됩니다. 미검증 발견 항목은 보안 심각도가 Medium 이상인 규칙에만 보고됩니다.

미검증 발견 항목은 다음과 같은 방식으로 완전히 검증된 취약점과 명확히 구분됩니다:

• 파이프라인 Security 탭에서 취약점 설명은 (Unverified) 접두사로 시작합니다.
• Vulnerability report에서도 미검증 발견 항목에 같은 접두사가 붙습니다.
• 취약점 세부 정보 페이지의 Data flow 섹션에서 미검증 취약점에는 소스 노드가 없습니다. 흐름의 첫 노드는 Trace Entry Point이며, 부분 추적이 시작되는 지점을 나타냅니다.

미검증 취약점 보고 켜기#

스캔 결과에 미검증 발견 항목을 포함하려면 .gitlab-ci.yml 파일에서 REPORT_UNVERIFIED_VULNS CI/CD 변수를 참 값으로 설정합니다:

gitlab-advanced-sast:
  variables:
    REPORT_UNVERIFIED_VULNS: "true"

러너 리소스 조정#

러너 리소스는 스캔 시간에 직접 영향을 줍니다. GitLab Advanced SAST는 기본적으로 검사를 병렬로 실행하므로 여러 CPU 코어와 코어당 최소 4 GB 메모리가 필요합니다. 러너 리소스는 자동으로 감지되지만, 필요하면 일부 설정을 조정할 수 있습니다.

분석기는 다음 우선순위에 따라 사용 가능한 CPU와 메모리를 판단합니다:

1. GitLab SaaS 러너 태그(CI_RUNNER_TAGS):
   • GitLab 호스팅 러너에서는 분석기가 러너 태그(예: saas-linux-large-amd64)를 읽고 해당 러너 유형의 알려진 CPU 및 메모리 값을 조회합니다.
2. 컨테이너 리소스 제한(/sys/fs/cgroup/cpu.max, /sys/fs/cgroup/memory.max):
   • self-managed 러너에서는 분석기가 Linux cgroups에서 컨테이너 리소스 제한을 읽습니다. cgroups에는 리소스 제한만 반영됩니다. 요청은 컨테이너 수준에서 적용되지 않으며 아무 효과가 없습니다.
3. CI/CD 변수 재정의(ADVANCED_SAST_AVAILABLE_CPUS, ADVANCED_SAST_AVAILABLE_MEMORY):
   • 설정되어 있으면 이 값이 1단계나 2단계에서 감지된 값을 재정의합니다.

1단계와 2단계에서 감지에 실패하면 분석기는 기본값으로 코어 1개와 메모리 4 GB를 사용합니다.

CPU 및 메모리 할당을 확인하려면 gitlab-advanced-sast job 로그를 보고 GitLab Advanced SAST 항목을 찾습니다. 예를 들면 다음과 같습니다:

[INFO] [GitLab Advanced SAST] [2026-03-30T02:38:09Z] ▶ Detected 2 CPU Cores
[INFO] [GitLab Advanced SAST] [2026-03-30T02:38:09Z] ▶ No Memory limit is detected

권장 시작점#

스캔이 느린 대규모 리포지터리에서는 CPU 코어 여러 개와 코어당 4 GB를 채울 만큼의 메모리로 시작합니다. 그다음 관찰한 스캔 시간에 따라 조정합니다. 구성 예시는 러너 리소스 설정 구성을 참고합니다. job timeout은 첫 전체 스캔이 완료될 수 있을 만큼 충분히 높게 설정합니다.

러너 리소스 설정 구성#

다음과 같은 경우 CI/CD 변수로 분석기의 CPU 및 메모리 설정을 직접 조정할 수 있습니다:

• 러너에 cgroup 제한이 설정되지 않은 경우(예: 베어메탈 또는 제약이 없는 VM).
• 감지된 값이 러너의 실제 용량과 맞지 않는 경우.
• 분석기가 사용하는 리소스를 사용 가능한 양보다 낮게 제한하려는 경우.

GitLab Advanced SAST 러너 리소스를 조정하려면 다음 CI/CD 설정을 사용합니다:

• ADVANCED_SAST_AVAILABLE_CPUS - 분석기가 사용할 수 있는 CPU 코어를 지정합니다
• ADVANCED_SAST_AVAILABLE_MEMORY - 분석기가 사용할 수 있는 전체 메모리를 지정합니다
• MAX_UNVERIFIED_CORES - 자동 코어 감지의 상한을 설정합니다
• DISABLE_MULTI_CORE - 멀티 코어 스캔을 완전히 비활성화합니다

self-managed 러너에서는 보안 스캐너 구성의 --multi-core 플래그로 requested 코어 수를 지정할 수 있습니다.

자세한 내용은 구성을 참고합니다.

프로젝트에 가장 알맞은 구성을 찾으려면 한 번에 설정 하나만 변경하고 스캔 시간을 모니터링합니다.

다음 예시에서는 GitLab Advanced SAST 분석기가 CPU 코어 4개와 메모리 16 GB를 사용할 수 있습니다. 워커 4개는 각각 메모리 4 GB를 사용할 수 있습니다.

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

variables:
  GITLAB_ADVANCED_SAST_ENABLED: 'true'
  ADVANCED_SAST_AVAILABLE_CPUS: '4'
  ADVANCED_SAST_AVAILABLE_MEMORY: '16384'  # 16 GB for 4 cores

러너 리소스 조정 적용 확인#

ADVANCED_SAST_AVAILABLE_CPUS 또는 ADVANCED_SAST_AVAILABLE_MEMORY를 설정한 뒤에는 gitlab-advanced-sast job 로그에서 실제 적용된 값을 확인합니다. 로그는 감지된 CPU를 보고하고, 메모리가 설정된 경우 감지된 메모리도 보고합니다. 예를 들면 다음과 같습니다:

Detected 2 CPU Cores
Detected 8192 MB of Memory

실제 적용된 값이 요청한 값보다 낮으면 다음을 확인합니다:

1. 러너의 실제 CPU와 메모리를 확인합니다. 분석기는 재정의 값을 설정한 대로 적용하고 러너 용량에 맞춰 제한하지 않습니다. 실제 용량을 넘는 값은 스캔을 빠르게 하는 대신 리소스 경합을 일으킵니다. GitLab 호스팅 러너는 호스팅 러너 사양을 참고합니다. self-managed 러너에서는 러너 호스트의 nproc과 cgroup 제한을 확인합니다.
2. 변수가 올바른 범위에 설정되어 있고 다른 것이 재정의하지 않는지 확인합니다.

기본적으로 분석기는 MAX_UNVERIFIED_CORES(기본값 4)보다 최대 1개 적은 코어를 사용하므로 코어 3개를 사용합니다. 이 동작 때문에 설정을 전혀 변경하지 않아도 job 로그에 다음과 같은 줄이 표시될 수 있습니다:

Detected 8 cores but using 3; set --multi-core or MAX_UNVERIFIED_CORES for more

더 많은 코어를 사용하려면 MAX_UNVERIFIED_CORES를 높이거나, SAST_SCANNER_ALLOWED_CLI_OPTS를 통해 --multi-core로 특정 개수를 요청합니다:

variables:
  SAST_SCANNER_ALLOWED_CLI_OPTS: "--multi-core 6"

구성#

다음 변수를 사용해 GitLab Advanced SAST 동작을 조정할 수 있습니다:

GitLab Advanced SAST 스캔은 기본적으로 비활성화되어 있습니다. 상위 수준(예: 그룹)에서 활성화된 경우 명시적으로 비활성화하려면 GITLAB_ADVANCED_SAST_ENABLED(또는 C/C++ 프로젝트의 경우 GITLAB_ADVANCED_SAST_CPP_ENABLED)를 false로 설정합니다.

롤아웃#

한 프로젝트에서 GitLab Advanced SAST 결과에 확신이 생기면, 다른 프로젝트와 그룹으로 확대합니다. GitLab Advanced SAST를 포함하는 공유 CI/CD 구성을 만들고 원하는 그룹과 프로젝트에 적용하는 것이 좋습니다. 먼저 각 프로젝트의 사전 요구 사항을 확인합니다.

자세한 내용은 보안 구성을 참고합니다.

취약점 탐지 기준#

GitLab Advanced SAST는 오염 분석과 함께 교차 파일, 교차 함수 스캔을 사용해 프로그램으로 들어오는 사용자 입력의 흐름을 추적합니다. 이를 통해 SQL 인젝션과 교차 사이트 스크립팅(XSS) 같은 인젝션 취약점을 여러 함수와 파일에 걸쳐 있어도 탐지합니다.

분석기는 신뢰할 수 없는 사용자 입력을 소스에서 신뢰할 수 없는 데이터가 보안 취약점을 유발할 수 있는 지점까지 전달하는 검증 가능한 흐름이 있을 때만 오염 기반 취약점을 보고합니다. 이 방식은 검증을 덜 하고 취약점을 보고할 수 있는 다른 제품에 비해 노이즈를 최소화합니다.

탐지는 HTTP 요청에서 온 값처럼 신뢰 경계를 넘는 입력을 중시하지만, 명령줄 인자, 환경 변수, 또는 프로그램을 실행하는 사용자가 일반적으로 제공하는 다른 입력은 제외합니다.

GitLab Advanced SAST가 탐지하는 취약점 유형에 대한 자세한 내용은 GitLab Advanced SAST CWE 커버리지를 참고합니다.

Semgrep에서 GitLab Advanced SAST로 전환#

Semgrep에서 GitLab Advanced SAST로 마이그레이션하면 자동화된 전환 프로세스가 취약점의 중복을 제거합니다. 이 프로세스는 이전에 탐지된 Semgrep 취약점을 대응하는 GitLab Advanced SAST 발견 항목과 연결하고, 일치하는 항목을 찾으면 대체합니다.

기존 Semgrep 취약점 검토#

기존 Semgrep 취약점이 있는 프로젝트에 자동 해결 정책이 적용된다면, 정책이 취약점을 해결하기 전에 해당 취약점을 검토합니다.

사전 요구 사항:

• 자동 해결 정책을 관리할 수 있는 권한.

1. 프로젝트의 Secure > Policies 페이지에서 관련된 자동 해결 정책을 모두 찾습니다. 각 정책의 policy_scope에서 projects: excluding에 프로젝트를 추가한 다음 보안 정책 프로젝트의 변경 사항을 머지합니다. enabled: false로 설정하지 않습니다. 그렇게 하면 정책 범위에 있는 모든 프로젝트에서 정책이 꺼집니다.

   정책 범위가 match_mode: any를 사용한다면 프로젝트를 제외하지 않습니다. 다른 조건이 프로젝트와 일치하면 프로젝트는 계속 범위에 남고, 제외 설정이 다른 프로젝트에 정책을 적용하게 만들 수 있습니다. 대신 어떤 조건도 프로젝트와 일치하지 않도록 범위를 변경합니다. 자세한 내용은 match_mode 이해하기를 참고합니다.

2. 프로젝트의 .gitlab-ci.yml 파일에서 GitLab Advanced SAST를 활성화합니다. 스캔 실행 정책에서 활성화하면 GitLab Advanced SAST가 해당 정책 범위의 모든 프로젝트에 적용되므로, 이전 단계에서 각 프로젝트를 제외합니다.

3. 기본 브랜치에서 파이프라인을 실행합니다. 프로젝트의 취약점 보고서에서 Security reports last updated에 해당 파이프라인이 표시될 때까지 기다립니다.

4. 취약점 보고서에서 Scanner 필터를 Semgrep으로 설정합니다. 파이프라인이 semgrep-sast job을 실행했다면 Activity 필터도 No longer detected로 설정합니다. 실행하지 않았다면 표시된 취약점이 없는 것입니다. 이 job을 실행하는 이후 파이프라인이 이러한 취약점을 표시하며, 다음 단계 후에 정책이 이를 해결합니다. 각 취약점을 검토합니다.

   • GitLab Advanced SAST가 같은 약점을 보고한다면 Semgrep 취약점을 해결합니다. 자세한 내용은 중복 취약점 해결을 참고합니다.
   • 어느 분석기도 해당 약점을 보고하지 않는다면 코드에 여전히 있는지 확인합니다. 있다면 취약점이 열려 있는 동안 프로젝트를 정책에서 계속 제외해 둡니다. 없다면 다음 단계 후에 정책이 해결하도록 취약점을 그대로 둡니다.

5. 이전의 범위 변경을 되돌리고 머지합니다.

자동 해결 정책이 이미 해결한 취약점 찾기#

취약점을 검토하기 전에 자동 해결 정책이 실행되었다면 정책이 해결한 취약점을 찾습니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Secure > Vulnerability report를 선택합니다.
3. 필터 바에서 다음을 설정합니다.
   • Scanner를 Semgrep으로.
   • Activity를 No longer detected로.
   • Status를 Resolved로.

이러한 각 취약점에는 정책과 파이프라인을 명시한 GitLab Security Policy Bot의 노트가 있습니다.

Semgrep은 더 이상 이러한 취약점을 보고하지 않습니다. 취약점을 다시 열면 Semgrep job을 실행하는 다음 기본 브랜치 스캔에서 정책이 이를 다시 해결합니다. 상태를 변경하기 전에 관련된 모든 자동 해결 정책에서 프로젝트를 제외합니다.

중복 제거 조건#

기본 브랜치에서 Advanced SAST 스캔을 활성화한 뒤 스캔이 실행되어 취약점을 탐지하면, 다음 조건에 따라 그 취약점 중 기존 Semgrep 취약점을 대체해야 하는 것이 있는지 확인합니다.

1. 일치하는 식별자:

   • GitLab Advanced SAST 취약점의 식별자 중 하나 이상(CWE와 OWASP 제외)이 기존 Semgrep 취약점의 기본 식별자와 일치해야 합니다.
   • 기본 식별자는 SAST 리포트에 있는 취약점의 식별자 배열에서 첫 번째 식별자입니다.
   • 예를 들어 GitLab Advanced SAST 취약점의 식별자에 bandit.B506이 포함되어 있고 Semgrep 취약점의 기본 식별자도 bandit.B506이면 이 조건이 충족됩니다.
   • 모든 GitLab Advanced SAST 규칙이 Semgrep 식별자를 가지는 것은 아닙니다. 어떤 GitLab Advanced SAST 규칙에도 Semgrep 취약점의 기본 식별자가 없다면, 두 분석기가 같은 줄을 보고하더라도 그 취약점은 변환되지 않습니다.

2. 일치하는 위치:

   • 두 취약점은 코드의 같은 위치와 연관되어야 합니다. 이는 SAST 리포트에 있는 취약점의 다음 필드 중 하나로 판단합니다:
     • Tracking 필드(있는 경우)
     • Location 필드(Tracking 필드가 없는 경우)
   • GitLab Advanced SAST가 같은 약점을 다른 줄에서 보고하면 위치가 일치하지 않습니다. 예를 들어 GitLab Advanced SAST가 구문의 시작이 아니라 싱크를 보고할 수 있습니다. 이 경우 두 취약점이 모두 남습니다. GitLab Advanced SAST 발견 항목이 보고되고 Semgrep 취약점은 변환되지 않습니다. 자세한 내용은 중복 취약점 해결을 참고합니다.

취약점 변경 사항#

조건이 충족되면 기존 Semgrep 취약점이 GitLab Advanced SAST 취약점으로 변환됩니다. 갱신된 이 취약점은 Vulnerability Report에 다음 변경 사항과 함께 표시됩니다:

• 스캐너 유형이 Semgrep에서 GitLab Advanced SAST로 갱신됩니다.
• GitLab Advanced SAST 취약점에 있는 추가 식별자가 기존 취약점에 추가됩니다.
• 취약점의 다른 세부 정보는 모두 그대로 유지됩니다.

조건이 충족되지 않으면 Semgrep 취약점은 변환되지 않습니다. 이후 취약점이 어떻게 되는지는 Semgrep job이 계속 실행되는지에 따라 달라집니다.

• 프로젝트에 Java 속성 파일과 Spring 구성 파일을 포함해 Semgrep이 스캔하는 파일이 여전히 있다면 Semgrep job이 실행됩니다. semgrep-sast가 스캔을 중단한 언어의 Semgrep 취약점은 다음 기본 브랜치 스캔에서 No longer detected로 표시됩니다. 이러한 취약점의 상태는 취약점 관리 정책이 변경할 때만 바뀝니다.
• 프로젝트에 그러한 파일이 없다면 Semgrep job이 실행되지 않습니다. Semgrep 취약점은 이후 파이프라인이 Semgrep job을 실행할 때까지(예: Semgrep이 스캔하는 파일이 추가된 뒤) 상태를 유지합니다. 그 파이프라인이 이러한 취약점을 No longer detected로 표시합니다.

중복 취약점 해결#

중복 제거 조건이 충족되지 않으면 Semgrep 취약점이 여전히 중복으로 표시될 수 있습니다. Vulnerability Report에서 이를 해결하려면 다음과 같이 합니다:

1. Advanced SAST 스캐너로 취약점을 필터링하고 결과를 CSV 형식으로 내보냅니다.
2. Semgrep 스캐너로 취약점을 필터링합니다. 이 취약점들이 중복 제거되지 않은 항목일 가능성이 높습니다.
3. 각 Semgrep 취약점에 대해 내보낸 Advanced SAST 결과에 대응하는 항목이 있는지 확인합니다.
4. 중복이 있으면 Semgrep 취약점을 적절히 해결합니다.

GitLab Advanced SAST의 LGPL 라이선스 컴포넌트 소스 코드 요청#

GitLab Advanced SAST의 LGPL 라이선스 컴포넌트 소스 코드에 대한 정보를 요청하려면 GitLab 지원팀에 문의합니다.

빠른 응답을 받으려면 요청에 GitLab Advanced SAST 분석기 버전을 포함합니다.

이 기능은 Ultimate 티어에서만 사용할 수 있으므로, 해당 수준의 지원 권한이 있는 조직과 연관되어 있어야 합니다.