히스토리

• 취약점 해결 활동 아이콘이 GitLab 17.5에서 vulnerability_report_vr_badge 플래그와 함께 도입. 기본적으로 비활성화됨.
• GitLab 17.6에서 기본적으로 활성화.
• GitLab 18.0에서 일반적으로 사용 가능. 피처 플래그 vulnerability_report_vr_badge 제거됨.

취약점 보고서는 코드베이스에서 발견된 보안 취약점의 통합 뷰를 제공합니다. 심각도, 보고서 유형, 스캐너(프로젝트만), 기타 속성으로 취약점을 정렬하여 먼저 처리해야 할 이슈를 결정합니다. 수정 진행 상황을 보여주는 상태 표시기 및 활동 아이콘을 통해 취약점의 수명 주기를 추적합니다.

각 취약점에 대해 사용 가능한 경우 Common Vulnerability Scoring System(CVSS) 점수와 파일 위치를 포함한 자세한 정보에 접근합니다. 유사한 취약점을 필터링하고 그룹화하여 체계적으로 처리합니다.

성능상의 이유로 취약점의 총 수가 1000을 초과하면 취약점 보고서에는 정확한 수 대신 **1000+**로 표시됩니다. 이 제한은 페이지 상단에 표시된 카운트에만 영향을 미칩니다. 테이블에서는 여전히 모든 취약점을 찾을 수 있습니다.

정확한 카운트를 표시하는 개선 사항이 이슈 547510에서 제안되어 있습니다. 정확한 카운트를 찾으려면 이슈 480378의 해결 방법 중 하나를 사용하세요.

개요는 취약점 관리 - 고급 보안 테스팅을 참조하세요.

취약점 보고서 내용#

보고서에는 기본 브랜치의 데이터가 포함되어 있으며 모든 성공적인 보안 스캔 작업의 누적 결과를 표시합니다. 스캔 결과는 작업 완료 후 또는 수동 작업으로 파이프라인이 차단될 때 표시됩니다.

프로젝트와 그룹의 경우 취약점 보고서에 다음이 포함됩니다:

• 심각도 수준별 취약점 합계.
• 일반적인 취약점 속성에 대한 필터.
• 표로 표시된 각 취약점의 세부 정보.

일부 취약점의 경우 세부 정보에 기본 브랜치의 관련 파일과 줄 번호에 대한 링크가 포함됩니다. CVE 취약점의 경우 취약점 보고서에서 KEV 상태, CVSS 및 EPSS 점수, 도달 가능성 정보를 볼 수 있습니다.

프로젝트의 경우 취약점 보고서에 다음도 포함됩니다:

• 기본 브랜치가 마지막으로 업데이트된 시간 스탬프(최신 파이프라인에 대한 링크 포함). 기본 브랜치가 아닌 브랜치에서 실행되는 파이프라인은 시간 스탬프를 업데이트하지 않습니다.
• 가장 최근 파이프라인에서 발생한 실패 횟수. 실패 알림을 선택하면 파이프라인 페이지의 실패한 작업 탭이 표시됩니다.

활동 열에는 해당 행의 취약점에서 취해진 활동(있는 경우)을 나타내는 아이콘이 포함됩니다:

• 이슈 [work-item-issue]: 취약점에 대해 생성된 이슈 링크.
• 머지 리퀘스트 [merge-request]: 취약점에 대해 생성된 머지 리퀘스트 링크.
• 체크된 원 [check-circle-dashed]: 취약점이 수정됨.
• 거짓 양성 [false-positive]: 스캐너가 이 취약점을 거짓 양성으로 판단함.
• 솔루션 [bulb]: 취약점에 사용 가능한 솔루션이 있음을 나타냄.
• 취약점 해결 [tanuki-ai]: 취약점에 사용 가능한 AI 해결책이 있음을 나타냄.
• 거짓 양성 감지 [tanuki-ai]: GitLab Duo가 이 취약점의 거짓 양성을 분석했음을 나타냄. 아이콘 위에 마우스를 올리면 신뢰도 점수와 설명을 볼 수 있음.

취약점에 대해 생성된 이슈를 열려면 활동 항목 위에 마우스를 올리고 링크를 선택합니다. 이슈 아이콘([work-item-issue])은 이슈 상태를 나타냅니다. Jira 이슈 지원이 활성화된 경우 활동 항목에서 찾은 이슈 링크가 Jira의 이슈로 연결됩니다. GitLab 이슈와 달리 Jira 이슈의 상태는 GitLab UI에 표시되지 않습니다.

취약점이 멀티 프로젝트 파이프라인 설정에서 발생하는 경우, 이 페이지에는 선택한 프로젝트에서 발생한 취약점이 표시됩니다.

취약점 보고서 보기#

취약점 보고서를 보려면 프로젝트 또는 그룹의 모든 취약점을 나열합니다.

필수 조건:

• 프로젝트 또는 그룹에 대한 Security Manager, Developer, Maintainer 또는 Owner 역할이 있어야 합니다.

취약점 보고서를 보려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾습니다.
2. Secure > 취약점 보고서를 선택합니다.

취약점 필터링#

히스토리

• 식별자 필터가 vulnerability_filtering_by_identifier라는 플래그와 함께 GitLab 17.7에서 도입. 기본적으로 활성화됨.
• 식별자 필터가 GitLab 17.9에서 일반적으로 사용 가능. 피처 플래그 vulnerability_filtering_by_identifier 제거됨.
• 정책 위반 필터:
• policy_violations_es_filter 및 security_policy_approval_warn_mode라는 플래그와 함께 GitLab 18.6에서 도입. GitLab.com에서 활성화됨.
• GitLab 18.9에서 일반적으로 사용 가능. 피처 플래그 security_policy_approval_warn_mode 제거됨.

취약점 보고서에서 취약점을 필터링하여 더 효율적으로 분류할 수 있습니다.

다음으로 필터링할 수 있습니다:

• 상태: 취약점의 현재 상태: needs triage, confirmed, dismissed, resolved. 무시된 취약점은 무시된 이유에 따라 함께 또는 개별적으로 필터링할 수 있습니다.
• 심각도: 취약점의 심각도 값: critical, high, medium, low, info, unknown.
• 보고서 유형: SAST 또는 컨테이너 퍼징 등 취약점을 감지한 보고서 유형.
• 스캐너: 취약점을 식별한 특정 스캐너.
• 활동: 취약점에 이슈, 머지 리퀘스트, 또는 솔루션이 있는지 여부 등 취약점의 추가 속성.
• 식별자: 취약점의 식별자(고급 취약점 관리 필요. 고급 취약점 관리 없이는 최대 20,000개 취약점이 있는 프로젝트 및 그룹으로 제한됨).
• 프로젝트: 특정 프로젝트의 취약점 필터링(그룹에서만 사용 가능).
• 도달 가능성: 도달 가능성 상태로 취약점 필터링: 예, 찾을 수 없음, 사용할 수 없음. 이 필터를 사용하려면 고급 취약점 관리가 활성화되어 있어야 합니다.
• 유효성 검사: 유효성 상태로 취약점 필터링: 활성, 비활성, 또는 가능하면 활성. 이 필터를 사용하려면 고급 취약점 관리가 활성화되어 있어야 합니다.
• 정책 위반: 우회 이유로 취약점 필터링. 사용자가 경고 모드의 보안 정책에서 정책 위반을 우회할 때 도입된 취약점을 보여줍니다. 사용자는 경고 모드의 정책에서 위반을 우회할 때 이유를 제공해야 합니다. 이 필터를 사용하려면 고급 취약점 관리가 활성화되어 있어야 합니다.

취약점 필터링#

히스토리

• vulnerability_report_advanced_filtering이라는 플래그와 함께 GitLab 16.9에서 개선된 필터링 도입. 기본적으로 비활성화됨.
• GitLab 17.1에서 GitLab.com, GitLab Self-Managed, GitLab Dedicated에서 활성화.
• GitLab 17.2에서 일반적으로 사용 가능. 피처 플래그 vulnerability_report_advanced_filtering 제거됨.

취약점 보고서를 필터링하여 취약점의 하위 집합에 집중합니다.

취약점 목록을 필터링하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. Secure > 취약점 보고서를 선택합니다.
3. 선택 사항. 기본 필터를 제거하려면 지우기 ([clear])를 선택합니다.
4. 취약점 목록 위에서 필터 바를 선택합니다.
5. 나타나는 드롭다운 목록에서 필터링할 속성을 선택한 다음 드롭다운 목록에서 값을 선택합니다.
6. 필터 필드 외부를 선택합니다. 취약점 심각도 합계와 일치하는 취약점 목록이 업데이트됩니다.
7. 여러 속성으로 필터링하려면 이전 세 단계를 반복합니다. 여러 속성은 논리 AND로 결합됩니다.

보고서 유형 필터#

감지된 보고서 유형에 따라 취약점을 필터링할 수 있습니다. 기본적으로 취약점 보고서는 모든 보고서 유형의 취약점을 나열합니다.

수동으로 추가됨 속성을 사용하여 수동으로 추가된 취약점을 필터링합니다.

스캐너 필터#

프로젝트의 경우 감지한 스캐너에 따라 취약점을 필터링할 수 있습니다. 기본적으로 취약점 보고서는 모든 스캐너의 취약점을 나열합니다.

프로젝트 필터#

프로젝트 필터의 내용은 다양합니다:

• 보안 센터: 개인 보안 센터에 추가한 프로젝트만.
• 그룹: 그룹의 모든 프로젝트.
• 프로젝트: 해당 없음.

활동 필터#

히스토리

• activity_filter_has_remediations라는 플래그와 함께 GitLab 16.7에서 도입. 기본적으로 비활성화됨.
• GitLab 16.9에서 일반적으로 사용 가능. 피처 플래그 activity_filter_has_remediations 제거됨.
• 활동 필터 옵션 GitLab Duo (AI):
• vulnerability_report_vr_filter 플래그와 함께 GitLab 17.5에서 도입. 기본적으로 비활성화됨.
• GitLab 17.6에서 기본적으로 활성화.
• GitLab 18.0에서 일반적으로 사용 가능. vulnerability_report_vr_filter 플래그 제거됨.
• GitLab 18.10에서 GitLab Duo (AI) 필터 이름이 GitLab Duo resolution으로 변경됨.
• 활동 필터 옵션 GitLab Duo FP detection이 GitLab 18.10에서 vulnerability_report_ai_fp_filter라는 플래그와 함께 도입. 기본적으로 비활성화됨.
• GitLab 18.11에서 일반적으로 사용 가능. 피처 플래그 vulnerability_report_ai_fp_filter 제거됨.

활동 필터는 다른 필터와 다르게 동작합니다. 각 카테고리에서 하나의 값만 선택할 수 있습니다. 필터를 제거하려면 활동 필터 드롭다운 목록에서 제거하려는 필터를 선택합니다.

활동 필터 사용 시 선택 동작:

• 활동
  • 모든 활동: 활동 상태에 관계없이 취약점(이 필터를 무시하는 것과 동일). 이를 선택하면 다른 모든 활동 필터 옵션이 선택 해제됩니다.
• 감지
  • 여전히 감지됨 (기본값): default 브랜치의 최신 파이프라인 스캔에서 여전히 감지되는 취약점.
  • 더 이상 감지되지 않음: default 브랜치의 최신 파이프라인 스캔에서 더 이상 감지되지 않는 취약점.
• 이슈
  • 이슈 있음: 하나 이상의 관련 이슈가 있는 취약점.
  • 이슈 없음: 관련 이슈가 없는 취약점.
• 머지 리퀘스트
  • 머지 리퀘스트 있음: 하나 이상의 관련 머지 리퀘스트가 있는 취약점.
  • 머지 리퀘스트 없음: 관련 머지 리퀘스트가 없는 취약점.
• 솔루션 사용 가능
  • 솔루션 있음: 자동화된 머지 리퀘스트로 해결할 수 있는 취약점.
  • 솔루션 없음: 자동화된 머지 리퀘스트 해결이 없는 취약점.
• GitLab Duo resolution:
  • 취약점 해결 사용 가능: 사용 가능한 AI 해결책이 있는 취약점.
  • 취약점 해결 사용 불가: 사용 가능한 AI 해결책이 없는 취약점.
• GitLab Duo FP detection:
  • 거짓 양성: GitLab Duo가 잠재적 거짓 양성으로 표시한 취약점.
  • 거짓 양성으로 식별되지 않음: 거짓 양성으로 식별되지 않거나 GitLab Duo가 표시하지 않은 취약점.

GitLab Duo (AI) 필터는 다음 경우에 사용 가능합니다:

• 보안 센터 취약점 보고서: 보안 센터의 프로젝트 중 하나에 GitLab Duo 토글이 켜져 있는 경우.
• 그룹 취약점 보고서: 해당 그룹에 GitLab Duo 기능이 기본적으로 켜짐으로 설정된 경우.
• 프로젝트 취약점 보고서: 해당 프로젝트에 GitLab Duo 토글이 켜져 있는 경우.

도달 가능성 필터#

히스토리

• GitLab 18.3에서 GitLab.com 및 GitLab Dedicated에 도입.
• GitLab 18.7에서 GitLab Self-Managed에서 활성화.

그룹 및 프로젝트의 경우 도달 가능성 값을 기반으로 취약점을 필터링할 수 있습니다. 기본적으로 취약점 보고서는 도달 가능성 값에 관계없이 취약점을 나열합니다.

이 필터는 고급 취약점 관리가 필요합니다.

유효성 검사 필터#

히스토리

• validity_check_es_filter 플래그와 함께 GitLab 18.5에서 도입. 기본적으로 비활성화됨.
• GitLab 18.7에서 GitLab.com, GitLab Self-Managed, GitLab Dedicated에서 활성화.
• GitLab 18.7에서 일반적으로 사용 가능. 피처 플래그 validity_check_es_filter 제거됨.

그룹 및 프로젝트의 경우 유효성 검사 값을 기반으로 취약점을 필터링할 수 있습니다. 기본적으로 취약점 보고서는 가능하면 활성 상태의 취약점을 나열합니다.

이 필터는 고급 취약점 관리가 필요합니다.

취약점 그룹화#

히스토리

• 프로젝트별 취약점 그룹화:
• vulnerability_report_grouping이라는 플래그와 함께 GitLab 16.4에서 도입. 기본적으로 비활성화됨.
• GitLab 16.5에서 GitLab Self-Managed 및 GitLab Dedicated에서 활성화.
• GitLab 16.6에서 일반적으로 사용 가능. 피처 플래그 vulnerability_report_grouping 제거됨.
• 그룹별 취약점 그룹화:
• group_level_vulnerability_report_grouping 플래그와 함께 GitLab 16.7에서 도입. 기본적으로 비활성화됨.
• GitLab 17.2에서 GitLab Self-Managed 및 GitLab Dedicated에서 활성화.
• GitLab 17.3에서 일반적으로 사용 가능. 피처 플래그 group_level_vulnerability_report_grouping 제거됨.
• 그룹별 OWASP Top 10 취약점 그룹화:
• vulnerability_owasp_top_10_group이라는 플래그와 함께 GitLab 16.8에서 도입. 기본적으로 비활성화됨.
• GitLab 17.4에서 GitLab Self-Managed 및 GitLab Dedicated에서 활성화.
• GitLab 17.4에서 일반적으로 사용 가능. 피처 플래그 vulnerability_owasp_top_10_group 제거됨.
• OWASP Top 10 그룹화의 비 OWASP 카테고리:
• owasp_top_10_null_filtering이라는 플래그와 함께 GitLab 17.1에서 도입. 기본적으로 비활성화됨.
• GitLab 17.5에서 GitLab Self-Managed, GitLab Dedicated에서 활성화.
• GitLab 17.6에서 일반적으로 사용 가능. 피처 플래그 owasp_top_10_null_filtering 제거됨.
• OWASP 2021 Top 10 그룹화:
• GitLab 18.1에서 GitLab.com 및 GitLab Dedicated에 도입.
• GitLab 18.7에서 GitLab Self-Managed에서 활성화.

취약점 보고서 페이지에서 취약점을 그룹화하여 더 효율적으로 분류할 수 있습니다.

다음으로 그룹화할 수 있습니다:

• 상태
• 심각도
• 보고서 유형
• 스캐너
• OWASP Top 10 2017
• OWASP Top 10 2021(고급 취약점 관리 필요)

취약점 그룹화#

취약점을 그룹화하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾습니다.
2. Secure > 취약점 보고서를 선택합니다.
3. 그룹화 기준 드롭다운 목록에서 그룹을 선택합니다.

취약점은 선택한 그룹에 따라 그룹화됩니다. 각 그룹은 이름 옆에 표시된 그룹당 총 취약점 수와 함께 축소됩니다. 각 그룹의 취약점을 보려면 그룹 이름을 선택합니다.

취약점 세부 정보 보기#

취약점의 더 자세한 내용을 보려면 취약점의 설명을 선택합니다. 취약점 세부 정보 페이지가 열립니다.

취약점 상태 변경#

히스토리

• 코멘트 및 무시 이유 제공이 GitLab 16.0에서 도입.

취약점을 분류할 때 무시하는 것을 포함하여 상태를 변경할 수 있습니다.

취약점이 무시될 때 감사 로그에는 누가 무시했는지, 언제 무시되었는지, 무시된 이유에 대한 메모가 포함됩니다. 취약점 레코드는 삭제할 수 없으므로 영구 레코드가 항상 남습니다.

필수 조건:

• 프로젝트에 대한 Maintainer 또는 Owner 역할이 있어야 합니다. admin_vulnerability 권한은 GitLab 17.0에서 Developer 역할에서 제거되었습니다.

취약점의 상태를 변경하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. Secure > 취약점 보고서를 선택합니다.
3. 선택하려면:
   • 하나 이상의 취약점을 선택하려면 각 취약점 옆의 체크박스를 선택합니다.
   • 페이지의 모든 취약점을 선택하려면 테이블 헤더의 체크박스를 선택합니다.
4. 상태 설정 드롭다운 목록에서 원하는 상태를 선택합니다.
5. 무시 상태를 선택한 경우 무시 이유 설정 드롭다운 목록에서 원하는 이유를 선택합니다.
6. 코멘트 추가 입력란에서 코멘트를 제공할 수 있습니다. 무시 상태의 경우 코멘트가 필요합니다.
7. 상태 변경을 선택합니다.

선택한 취약점의 상태가 업데이트되고 취약점 보고서의 내용이 새로 고침됩니다.

취약점 심각도 변경 또는 재정의#

히스토리

• vulnerability_severity_override라는 플래그와 함께 GitLab 17.9에서 도입. 기본적으로 비활성화됨.
• GitLab 17.10에서 GitLab.com, GitLab Self-Managed, GitLab Dedicated에서 활성화.
• GitLab 18.1에서 일반적으로 사용 가능. 피처 플래그 vulnerability_severity_override 제거됨.
• hide_vulnerability_severity_override라는 플래그와 함께 관리자가 GitLab 18.1에서 사용자가 심각도 수준을 변경하거나 재정의하는 것을 방지하는 피처 플래그를 추가. 기본적으로 비활성화됨.

특정 경우에는 감지된 취약점의 심각도를 조직의 우선순위를 더 잘 반영하도록 조정해야 할 수 있습니다. 예를 들어, 스캐너가 낮은 심각도를 보고하지만 환경이나 설정에 따라 더 치명적으로 간주될 수 있습니다. 이 기능을 통해 스캐너가 할당한 기본 심각도를 재정의할 수 있습니다.

필수 조건:

• 프로젝트에 대한 Maintainer 또는 Owner 역할 또는 admin_vulnerability 권한이 있어야 합니다.

취약점의 심각도를 수동으로 재정의하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. Secure > 취약점 보고서로 이동합니다.
3. 취약점 선택:
   • 개별 취약점을 선택하려면 각 취약점 옆의 체크박스를 선택합니다.
   • 페이지의 모든 취약점을 선택하려면 테이블 헤더의 체크박스를 선택합니다.
4. 작업 선택 드롭다운 목록에서 심각도 변경을 선택합니다.
5. 심각도 선택 드롭다운 목록에서 원하는 심각도 수준을 선택합니다.
6. 심각도 변경 이유 추가(필수) 텍스트 상자에서 심각도를 변경하는 이유에 대한 간략한 설명을 추가합니다.
7. 심각도 변경을 선택합니다.

선택한 각 취약점에 대해:

• 심각도가 취약점 세부 정보 페이지와 취약점 보고서 모두에서 업데이트됩니다.
• 심각도에 배지가 추가되어 심각도가 재정의되었음을 나타냅니다.
• 수동 심각도 조정이 취약점의 이력에 기록됩니다.

사용자가 취약점 심각도를 재정의하지 못하도록 방지#

히스토리

• hide_vulnerability_severity_override라는 플래그와 함께 GitLab 18.1에서 도입. 기본적으로 비활성화됨.

일부 환경에서는 사용자가 취약점의 심각도를 재정의하는 것을 방지해야 할 수 있습니다. hide_vulnerability_severity_override 피처 플래그를 통해 관리자는 취약점 보고서에서 심각도 재정의 기능을 숨길 수 있습니다. 이 기능은 조직이 프로젝트 전체에서 표준화된 취약점 심각도 등급을 유지하는 데 도움이 됩니다. 활성화하면 이 기능은:

• 취약점 보고서의 작업 드롭다운 목록에서 심각도 변경 옵션을 숨깁니다.
• 사용자가 UI를 통해 수동으로 심각도 수준을 변경하지 못하도록 하여 스캐너 결과를 기반으로 일관된 취약점 점수를 보장합니다.
• 취약점 심각도 수정과 관련된 모든 API 엔드포인트를 비활성화하여 모든 접근 방법에서 일관성을 유지합니다.

hide_vulnerability_severity_override 플래그를 활성화하려면 피처 플래그 뒤에 배포된 GitLab 기능 활성화 및 비활성화를 참조하세요.

기존 이슈에 취약점 추가#

히스토리

• enhanced_vulnerability_bulk_actions라는 플래그와 함께 GitLab 17.9에서 도입. 기본적으로 비활성화됨.
• GitLab 18.0에서 GitLab.com, GitLab Self-Managed, GitLab Dedicated에서 활성화.
• GitLab 18.1에서 일반적으로 사용 가능. 피처 플래그 enhanced_vulnerability_bulk_actions 제거됨.

취약점 보고서에서 하나 이상의 취약점을 기존 이슈에 연결할 수 있습니다.

필수 조건:

• 프로젝트에 대한 Maintainer 또는 Owner 역할 또는 사용자 정의 역할의 admin_vulnerability 권한이 있어야 합니다. admin_vulnerability 권한은 GitLab 17.0에서 Developer 역할에서 제거되었습니다.

취약점을 기존 이슈에 첨부하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾습니다.
2. Secure > 취약점 보고서로 이동합니다.
3. 취약점 선택:
   • 개별 취약점을 선택하려면 각 취약점 옆의 체크박스를 선택합니다.
   • 페이지의 모든 취약점을 선택하려면 테이블 헤더의 체크박스를 선택합니다.
4. 작업 선택 드롭다운 목록에서 기존 이슈에 첨부를 선택합니다.
5. 이슈 URL 또는 <#이슈 ID> 입력 텍스트 상자에서 자동 완성할 이슈의 ID를 입력하거나 이슈의 URL을 추가합니다. 취약점을 추가할 여러 이슈를 입력할 수 있습니다.
6. 추가를 선택합니다.

선택한 각 취약점이 지정된 모든 이슈에 연결됩니다.

새 이슈에 취약점 추가#

히스토리

• new_issue_attachment_from_vulnerability_bulk_action이라는 플래그와 함께 GitLab 17.9에서 도입. 기본적으로 비활성화됨.
• GitLab 18.0에서 GitLab.com, GitLab Self-Managed, GitLab Dedicated에서 활성화.
• GitLab 18.1에서 일반적으로 사용 가능. 피처 플래그 new_issue_attachment_from_vulnerability_bulk_action 제거됨.

하나 이상의 취약점을 새 이슈에 연결할 수 있습니다.

필수 조건:

• 프로젝트에 대한 Maintainer 또는 Owner 역할 또는 사용자 정의 역할의 admin_vulnerability 권한이 있어야 합니다. admin_vulnerability 권한은 GitLab 17.0에서 Developer 역할에서 제거되었습니다.

취약점을 새 이슈에 첨부하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾습니다.
2. Secure > 취약점 보고서로 이동합니다.
3. 취약점 선택:
   • 개별 취약점을 선택하려면 각 취약점 옆의 체크박스를 선택합니다.
   • 페이지의 모든 취약점을 선택하려면 테이블 헤더의 체크박스를 선택합니다.
4. 작업 선택 드롭다운 목록에서 새 이슈에 첨부를 선택합니다.
5. 이슈 생성을 선택합니다.

새 이슈로 리디렉션됩니다. 선택한 각 취약점이 이미 연결되어 있습니다.

감지 날짜별 취약점 정렬#

기본적으로 취약점은 심각도 수준별로 정렬되며 가장 높은 심각도의 취약점이 맨 위에 나열됩니다.

각 취약점이 감지된 날짜별로 취약점을 정렬하려면 "감지됨" 열 헤더를 선택합니다.

내보내기#

히스토리

• CSV 내보내기의 열로 "무시 이유"가 GitLab 16.8에서 도입.

취약점 보고서에 나열된 취약점의 세부 정보를 내보낼 수 있습니다. 내보내기 형식은 CSV(쉼표로 구분된 값)입니다. 필터는 내보내기에 적용되지 않으므로 모든 취약점이 포함됩니다.

포함된 필드:

• 상태(상태 값 내보내기 방법에 대한 자세한 내용은 다음 표를 참조하세요.)
• 그룹 이름
• 프로젝트 이름
• 보고서 유형
• 스캐너 이름
• 취약점
• 기본 세부 정보
• 추가 정보
• 심각도
• CVE (Common Vulnerabilities and Exposures)
• CWE (Common Weakness Enumeration)
• 기타 식별자
• 감지 시기
• 위치
• 활동: 기본 브랜치에서 취약점이 해결된 경우 true, 그렇지 않은 경우 false를 반환합니다.
• 코멘트
• 전체 경로
• CVSS 벡터
• 무시 이유
• 취약점 ID

취약점 보고서에 표시된 상태 필드 값은 취약점 내보내기에 포함된 값과 다릅니다. 다음 참조 표를 사용하여 일치시키세요.

세부 정보 내보내기#

취약점 보고서에 나열된 모든 취약점의 세부 정보를 내보내려면 내보내기를 선택합니다.

내보낸 세부 정보가 사용 가능하면 이메일을 받게 됩니다. 내보낸 세부 정보를 다운로드하려면 이메일의 링크를 선택합니다.

취약점 수동 추가#

GitLab 취약점 데이터베이스에 없는 경우 취약점을 수동으로 추가합니다. 프로젝트의 취약점 보고서에서만 취약점을 추가할 수 있습니다.

취약점을 수동으로 추가하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. Secure > 취약점 보고서를 선택합니다.
3. 취약점 제출을 선택합니다.
4. 필드를 완성하고 양식을 제출합니다.

새로 생성된 취약점의 세부 정보 페이지가 열립니다.

고급 취약점 관리#

히스토리

• 고급 검색에서 OWASP 2021 그룹화 및 식별자 필터:
• advanced_vulnerability_management 피처 플래그와 함께 GitLab 18.2에서 도입. GitLab.com 및 GitLab Dedicated에서 사용 가능. 기본적으로 활성화됨.
• GitLab 18.7에서 GitLab Self-Managed에서 활성화.
• 고급 검색에서 정책 위반 필터:
• policy_violations_es_filter 및 security_policy_approval_warn_mode 피처 플래그와 함께 GitLab 18.6에서 도입. GitLab.com 및 GitLab Dedicated에서 사용 가능. 기본적으로 활성화됨.
• GitLab 18.7에서 GitLab Self-Managed에서 활성화.
• GitLab 18.9에서 일반적으로 사용 가능. 피처 플래그 security_policy_approval_warn_mode 제거됨. 피처 플래그 policy_violations_es_filter 및 security_policy_approval_warn_mode 제거됨.

GitLab은 주로 취약점 보고서의 필터링에 PostgreSQL을 사용합니다. 여러 필터를 적용할 때 데이터베이스 인덱싱 제한과 성능 문제로 인해 GitLab은 특정 취약점 관리 기능에 고급 검색을 사용합니다.

고급 검색은 다음 기능을 지원합니다:

1. 프로젝트 또는 그룹의 취약점 보고서에서 OWASP 2021 카테고리별 데이터 그룹화.
2. 프로젝트 또는 그룹의 취약점 보고서에서 취약점의 식별자 기반 필터링.
3. 프로젝트 또는 그룹의 취약점 보고서에서 도달 가능성 값 기반 필터링.
4. 프로젝트 또는 그룹의 취약점 보고서에서 유효성 검사 상태 기반 필터링.
5. 프로젝트 또는 그룹의 취약점 보고서에서 정책 위반 우회 이유 기반 필터링.
6. 새 보안 대시보드의 패널 및 전체 대시보드 데이터 필터링.

고급 검색은 다른 필터와 결합할 때도 포함하여 이러한 특정 기능에만 사용됩니다. 독립적으로 사용되는 다른 필터는 계속해서 표준 PostgreSQL 필터링을 사용합니다.

요구 사항#

고급 취약점 관리의 기능을 사용하려면:

• 고급 검색이 활성화되어 있어야 합니다.
• GitLab Self-Managed에서 고급 검색을 설정한 후 고급 검색으로 검색 체크박스가 선택되어 있는지 확인합니다.

운영 취약점#

운영 취약점 탭에는 운영 컨테이너 스캔에서 발견된 취약점이 나열됩니다. 이 탭은 프로젝트, 그룹 및 보안 센터 취약점 보고서에 나타납니다.