취약점 중복 제거 프로세스

요약

파이프라인에 동일한 유형의 보안 보고서를 여러 개 생성하는 job이 포함되어 있으면, 동일한 취약점이 여러 보고서에 존재할 수 있습니다. 취약점 중복 제거 로직은 스캔 유형에 따라 다릅니다. 각 스캔 유형은 취약점 위치에 대한 자체 정의를 가질 수 있으므로 스캔 유형이 일치해야 합니다.

파이프라인에 동일한 유형의 보안 보고서를 여러 개 생성하는 job이 포함되어 있으면, 동일한 취약점이 여러 보고서에 존재할 수 있습니다. 이러한 중복은 커버리지를 높이려고 서로 다른 스캐너를 사용할 때 흔히 발생하지만, 단일 보고서 안에서도 생길 수 있습니다. 취약점 중복 제거는 스캔 전반의 중복 취약점을 자동으로 통합하므로, 전체 스캔 커버리지를 유지하면서 고유한 취약점에 집중할 수 있습니다.

취약점 중복 제거 로직은 스캔 유형에 따라 다릅니다.

SAST 취약점은 범위-오프셋 알고리즘으로 중복 제거됩니다.
시크릿 탐지 취약점은 값과 파일 단위로 중복 제거됩니다.
그 밖의 모든 취약점은 스캔 유형, 위치, 식별자가 모두 같을 때 다른 취약점의 중복으로 간주됩니다.

각 스캔 유형은 취약점 위치에 대한 자체 정의를 가질 수 있으므로 스캔 유형이 일치해야 합니다. 예를 들어 정적 분석기는 파일 경로와 줄 번호를 찾을 수 있지만, 컨테이너 스캔 분석기는 대신 이미지 이름을 사용합니다.

식별자를 비교할 때 GitLab은 중복 제거 과정에서 CWE, WASC, OWASP를 비교하지 않습니다. 이 둘은 "유형 식별자"이며 취약점 그룹을 분류하는 데 사용되기 때문입니다. 이러한 식별자를 포함하면 많은 취약점이 중복으로 잘못 간주됩니다. 식별자가 하나도 일치하지 않으면 두 취약점은 고유한 것으로 간주됩니다.

중복된 취약점 집합에서는 취약점의 첫 번째 발생이 유지되고 나머지는 건너뜁니다. 보안 보고서는 알파벳순 파일 경로 순서로 처리되며, 취약점은 보고서에 나타난 순서대로 순차적으로 처리됩니다.

SAST처럼 GitLab 분석기를 두 개 이상 실행할 수 있는 스캔 유형에서는 스캐너 우선순위도 어떤 취약점을 유지할지 결정합니다. 두 GitLab 분석기가 동일한 취약점을 탐지하면 우선순위가 높은 분석기의 결과가 유지됩니다. GitLab은 이렇게 한 분석기가 다른 분석기를 대체할 때 연속성을 유지합니다. 예를 들어 Gemnasium 분석기의 결과는 동일한 의존성을 다루던 더 이상 사용되지 않는 분석기의 결과보다 우선합니다.

중복 제거 적용 방법#

GitLab은 두 개 이상의 단계에서 취약점을 중복 제거합니다.

단일 보고서 내부. GitLab 분석기는 보고서를 GitLab으로 전송하기 전에 자체 보고서에서 중복 취약점을 제거합니다. 서드파티 스캐너의 보고서에는 이 단계가 없습니다.
파이프라인 내 동일한 스캔 유형의 보고서 전반. 파이프라인이 동일한 스캔 유형의 보고서를 여러 개 생성하면 GitLab은 해당 보고서 전반에서 취약점을 중복 제거합니다.
파이프라인 실행 전반. GitLab은 파이프라인 실행 전반에 걸쳐 각 취약점을 추적하므로, 이후 실행에서 다시 탐지된 취약점은 새 취약점이 아니라 동일한 취약점으로 인식됩니다.

GitLab은 서로 다른 스캔 유형 사이에서는 취약점을 중복 제거하지 않습니다. 자세한 내용은 스캔 유형을 참고합니다.

기본 식별자 안정성#

중복 제거와 파이프라인 간 추적은 스캔 전반에서 기본 식별자가 안정적으로 유지되는 데 의존합니다. 기본 식별자는 취약점 식별자 목록의 첫 번째 항목입니다.

스캐너가 이후 실행에서 동일한 취약점에 대해 다른 기본 식별자를 보고하면, GitLab은 새 결과를 기존 결과와 매칭할 수 없습니다. 기존 취약점은 더 이상 탐지되지 않는 것으로 표시되고, 새 결과는 별도의 취약점으로 기록됩니다.

서드파티 스캐너는 SonarQube 규칙 키처럼 안정적인 규칙 키를 기본 식별자로 사용해야 합니다. 스캔마다 생성되는 값처럼 실행 간에 바뀌는 기본 식별자는 추적을 망가뜨리고 중복 취약점을 만들어 냅니다.

스캔 유형별 위치 정의#

중복 제거에 사용하는 위치는 스캔 유형에 따라 다릅니다.

컨테이너 스캔#

위치는 일반적으로 이미지 태그가 아니라 Docker 이미지 이름으로만 정의됩니다.
다만 이미지 태그가 시맨틱 버전 관리(semver) 구문과 일치하고 Git 커밋 해시처럼 보이지 않으면 이미지 태그도 위치의 일부로 간주됩니다. 예를 들면 다음과 같습니다.
다음 위치는 중복으로 처리됩니다.
- registry.gitlab.com/group-name/project-name/image1:12345019:libcrypto3
- registry.gitlab.com/group-name/project-name/image1:libcrypto3
다음 위치는 고유한 것으로 처리됩니다.
- registry.gitlab.com/group-name/project-name/image1:v19202021:libcrypto3
- registry.gitlab.com/group-name/project-name/image1:libcrypto3

동적 애플리케이션 보안 테스트(DAST)#

위치는 URL 경로, HTTP 메서드, HTTP 매개변수로 정의됩니다.
두 취약점이 동일한 HTTP 메서드로 동일한 URL 엔드포인트에서 발생하면 중복으로 간주됩니다.

의존성 스캐닝#

위치는 패키지 이름과 버전으로 정의됩니다.
두 취약점이 동일한 패키지 버전에 영향을 미치면 중복으로 간주됩니다.

범위-오프셋 서명#

보안 스캐너가 코드를 분석할 때, 특히 코드가 리팩터링되거나 이동한 경우 동일한 취약점을 여러 번 보고하기도 합니다. 고급 취약점 추적은 지능적인 중복 제거 체계를 사용해 이것이 새로운 문제가 아니라 실제로는 동일한 문제임을 인식합니다.

어떤 함수에 보안 문제가 있다고 가정합니다. 개발자가 코드를 리팩터링해 그 함수를 다른 줄로 옮기면 스캐너는 이를 새 취약점으로 보고할 수 있습니다. 중복 제거가 없으면 동일한 문제에 대한 중복 알림이 표시되어, 실제로 수정해야 할 대상을 추적하기가 어려워집니다.

범위-오프셋 서명을 사용할 때 GitLab은 다음 정보로 각 취약점의 고유한 "지문"을 생성합니다.

파일명: 취약점이 들어 있는 파일입니다.
범위: 취약점이 위치한 코드 컨텍스트입니다(함수 이름이나 클래스 이름 등).
오프셋: 해당 범위를 기준으로 한 상대 위치입니다.

이 조합은 동일한 범위 안에 머무르는 한 코드가 이동해도 그대로 유지되는 서명을 만들어 냅니다.

범위-오프셋 추적은 필요한 추적 데이터를 보고서에 포함하는 GitLab SAST 분석기에 적용됩니다. 이 추적 데이터는 GitLab 보고서 형식에 한정되므로 서드파티 SARIF 업로드로는 제공할 수 없습니다. 서드파티 SARIF 업로드는 대신 파일 경로와 줄 번호를 기반으로 하는 위치 지문을 사용합니다. 이 지문을 사용하면 관련 없는 코드 변경으로 줄 번호가 밀릴 때 취약점이 새로운 결과로 기록될 수 있습니다.

예시#

다음과 같은 Ruby 코드가 있다고 가정합니다.

class OuterClass
  class InnerClassA
    def function_A(x)
      puts "calling call1"
      call1(x)        # ← Vulnerability found here on line 5
    end
    call2("calling call 2")
  end
end

스캐너가 5번째 줄에서 취약점을 찾습니다. GitLab은 그 취약점이 OuterClass, InnerClassA, function_A 중 어디에 있는지 판단해야 합니다. 스캐너는 취약점에서 각 범위의 시작과 끝까지의 거리를 측정해 가장 적합한 범위를 계산합니다.

OuterClass(1-9번째 줄): 거리 = (5-1) + (9-5) = 8
InnerClassA(2-8번째 줄): 거리 = (5-2) + (8-5) = 6
function_A(3-6번째 줄): 거리 = (5-3) + (6-5) = 3

거리가 가장 작은 범위가 선택되므로 GitLab은 function_A를 범위로 식별합니다.

GitLab은 취약점의 위치를 식별하려고 lib/outer_class.rb|OuterClass[0]|InnerClassA[0]|function_A[0]:2 와 같은 서명을 만듭니다. 취약점이 들어 있는 함수나 클래스가 상위 범위 안에서 다른 위치로 이동하더라도 취약점은 다시 유입되지 않습니다. 다만 OuterClass의 이름이 바뀌면 범위가 달라지므로 새 취약점이 생성됩니다.

중복 제거 예시#

취약점 중복 제거가 어떻게 동작하는지 보여 주는 예시입니다.

일치하는 식별자와 위치, 불일치하는 스캔 유형#

첫 번째 취약점:
- 스캔 유형: dependency_scanning
- 위치 지문: adc83b19e793491b1c6ea0fd8b46cd9f32e592fc
- 식별자: CVE-2022-25510
두 번째 취약점:
- 스캔 유형: container_scanning
- 위치 지문: adc83b19e793491b1c6ea0fd8b46cd9f32e592fc
- 식별자: CVE-2022-25510
중복 제거 결과: 스캔 유형이 다르므로 중복 제거가 수행되지 않습니다.

일치하는 위치와 스캔 유형, 불일치하는 유형 식별자#

첫 번째 취약점:
- 스캔 유형: sast
- 위치 지문: adc83b19e793491b1c6ea0fd8b46cd9f32e592fc
- 식별자: CWE-259
두 번째 취약점:
- 스캔 유형: sast
- 위치 지문: adc83b19e793491b1c6ea0fd8b46cd9f32e592fc
- 식별자: CWE-798
중복 제거 결과: CWE 식별자는 무시되므로 중복 제거가 수행되지 않습니다.

일치하는 스캔 유형, 위치 및 식별자#

첫 번째 취약점:
- 스캔 유형: container_scanning
- 위치 지문: adc83b19e793491b1c6ea0fd8b46cd9f32e592fc
- 식별자: CVE-2019-12345, CVE-2022-25510, CWE-259
두 번째 취약점:
- 스캔 유형: container_scanning
- 위치 지문: adc83b19e793491b1c6ea0fd8b46cd9f32e592fc
- 식별자: CVE-2022-25510, CWE-798
중복 제거 결과: 두 취약점의 스캔 유형과 위치 지문이 같고 둘 다 CVE-2022-25510으로 식별되므로 취약점이 중복 제거됩니다.