파이프라인에 동일한 유형의 여러 보안 보고서를 생성하는 job이 포함된 경우, 동일한 취약점이 여러 보고서에 존재할 수 있습니다. 이 중복은 커버리지를 높이기 위해 다양한 스캐너를 사용할 때 일반적이지만, 단일 보고서 내에도 존재할 수 있습니다. 취약점 중복 제거는 스캔 전반에 걸쳐 중복된 취약점을 자동으로 통합하여 전체 스캔 커버리지를 유지하면서 고유한 취약점에 집중할 수 있도록 도와줍니다.

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

• SAST 취약점은 범위-오프셋 알고리즘을 사용하여 중복 제거됩니다.

• 시크릿 탐지 취약점은 값 및 파일별로 중복 제거됩니다.

• 다른 모든 취약점은 스캔 유형, 위치 및 식별자가 동일할 때 다른 취약점의 중복으로 간주됩니다.

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

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

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

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으로 식별되므로 취약점이 중복 제거됩니다.