취약점 중복 제거 프로세스

보안 스캔 결과의 취약점 중복 제거 방법 및 동작 방식을 설명합니다.

파이프라인에 동일한 유형의 여러 보안 보고서를 생성하는 job이 포함된 경우, 동일한 취약점이 여러 보고서에 존재할 수 있습니다. 이 중복은 커버리지를 높이기 위해 다양한 스캐너를 사용할 때 일반적이지만, 단일 보고서 내에도 존재할 수 있습니다. 취약점 중복 제거는 스캔 전반에 걸쳐 중복된 취약점을 자동으로 통합하여 전체 스캔 커버리지를 유지하면서 고유한 취약점에 집중할 수 있도록 도와줍니다. 취약점 중복 제거 로직은 스캔 유형에 따라 다릅니다: SAST 취약점은 범위-오프셋 알고리즘 을 사용하여 중복 제거됩니다. 시크릿 탐지 취약점은 값 및 파일별 로 중복 제거됩니다. 다른 모든 취약점은 스캔 유형 , 위치 및 식별자 가 동일할 때 다른 취약점의 중복으로 간주됩니다. 각 스캔 유형은 취약점 위치에 대한 자체 정의를 가질 수 있으므로 스캔 유형이 일치해야 합니다. 예를 들어 정적 분석기는 파일 경로와 줄 번호를 찾을 수 있지만, 컨테이너 스캔 분석기는 대신 이미지 이름을 사용합니다. 식별자를 비교할 때 GitLab은 중복 제거 중에 CWE 와 WASC 를 비교하지 않습니다. 이는 이들이 "유형 식별자"이며 취약점 그룹을 분류하는 데 사용되기 때문입니다. 이러한 식별자를 포함하면 많은 취약점이 잘못 중복으로 간주될 수 있습니다. 식별자가 하나도 일치하지 않으면 두 취약점은 고유한 것으로 간주됩니다. 중복된 취약점 세트에서 취약점의 첫 번째 발생은 유지되고 나머지는 건너뜁니다. 보안 보고서는 알파벳 파일 경로 순서로 처리되고, 취약점은 보고서에 나타나는 순서대로 순차적으로 처리됩니다. SAST와 같이 두 개 이상의 GitLab 분석기를 실행할 수 있는 스캔 유형의 경우, 스캐너 우선순위도 어떤 취약점을 유지할지 결정합니다. 두 GitLab 분석기가 동일한 취약점을 탐지할 경우, 우선순위가 높은 분석기의 결과가 유지됩니다. 이는 GitLab이 한 분석기가 다른 분석기를 대체할 때 연속성을 유지하는 방법입니다. 예를 들어 Gemnasium 분석기의 결과는 동일한 의존성을 다루는 더 이상 사용되지 않는 분석기의 결과보다 우선합니다. 중복 제거 적용 방법 # GitLab은 두 개 이상의 단계에서 취약점을 중복 제거합니다: 단일 보고서 내에서. GitLab 분석기는 보고서가 GitLab에 전송되기 전에 자체 보고서에서 중복 취약점을 제거합니다. 서드파티 스캐너의 보고서는 이 단계를 포함하지 않습니다. 파이프라인 내 동일한 스캔 유형의 보고서 전반에서. 파이프라인이 동일한 스캔 유형의 여러 보고서를 생성할 경우, GitLab은 해당 보고서 전반에서 취약점을 중복 제거합니다. 파이프라인 실행 전반에서. GitLab은 파이프라인 실행 전반에 걸쳐 각 취약점을 추적하므로 이후 실행에서 다시 탐지된 취약점은 새로운 것이 아닌 동일한 취약점으로 인식됩니다. GitLab은 서로 다른 스캔 유형 간에는 취약점을 절대 중복 제거하지 않습니다. 자세한 내용은 스캔 유형 을 참고하세요. 기본 식별자 안정성 # 중복 제거 및 파이프라인 간 추적은 스캔 전반에 걸쳐 기본