InfoGrab Docs

취약점 중복 제거 프로세스

요약

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

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

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

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

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

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

스캔 유형별 위치 정의#

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

컨테이너 스캔#

  • 위치는 일반적으로 이미지 태그가 아닌 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은 다음 정보를 사용하여 각 취약점에 대한 고유한 "지문"을 생성합니다:

  • 파일명: 취약점이 포함된 파일.
  • 범위: 취약점이 있는 코드 컨텍스트(함수 이름 또는 클래스 이름 등).
  • 오프셋: 해당 범위에 대한 상대적 위치.

이 조합은 동일한 범위 내에 있는 한 코드가 이동해도 동일하게 유지되는 서명을 생성합니다.

예시#

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

취약점 중복 제거 프로세스

Tier: Free, Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기
요약

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

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

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

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

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

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

스캔 유형별 위치 정의#

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

컨테이너 스캔#

  • 위치는 일반적으로 이미지 태그가 아닌 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은 다음 정보를 사용하여 각 취약점에 대한 고유한 "지문"을 생성합니다:

  • 파일명: 취약점이 포함된 파일.
  • 범위: 취약점이 있는 코드 컨텍스트(함수 이름 또는 클래스 이름 등).
  • 오프셋: 해당 범위에 대한 상대적 위치.

이 조합은 동일한 범위 내에 있는 한 코드가 이동해도 동일하게 유지되는 서명을 생성합니다.

예시#

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