히스토리

• 취약점 해결 활동 아이콘이 GitLab 17.5에서 vulnerability_report_vr_badge라는 플래그와 함께 도입. 기본적으로 비활성화됨.
• GitLab 17.6에서 기본적으로 활성화.
• GitLab 18.0에서 일반적으로 사용 가능. 피처 플래그 vulnerability_report_vr_badge 제거됨.
• 멀웨어 배지가 GitLab 19.4에서 vulnerability_malware_detection이라는 피처 플래그와 함께 베타 기능으로 도입. 기본적으로 활성화됨.
• 멀웨어 배지가 GitLab 19.5에서 일반적으로 사용 가능. 피처 플래그 vulnerability_malware_detection 제거됨.

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

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

성능상의 이유로 취약점 총 개수가 1000개를 초과하면, 취약점 보고서는 정확한 개수 대신 **1000+**로 표시합니다. 이 제한은 페이지 상단에 표시되는 개수에만 영향을 줍니다. 표에서는 여전히 모든 취약점을 확인할 수 있습니다.

정확한 개수를 표시하는 개선 사항은 이슈 547510에서 제안되어 있습니다. 정확한 개수를 확인하려면 이슈 480378의 해결 방법 중 하나를 사용합니다.

개요는 취약점 관리 - 고급 보안 테스팅을 참고합니다.

취약점 보고서 내용#

보고서에는 기본 브랜치의 데이터가 담기며, 성공한 모든 보안 스캔 job의 누적 결과를 보여줍니다. 스캔 결과는 job이 완료된 후 또는 수동 job 때문에 파이프라인이 차단될 때 표시됩니다.

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

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

일부 취약점의 세부 정보에는 기본 브랜치의 해당 파일과 줄 번호로 연결되는 링크가 포함됩니다. CVE 취약점의 경우 취약점 보고서에서 KEV 상태, CVSS 및 EPSS 점수, 도달 가능성 정보도 확인할 수 있습니다.

프로젝트의 취약점 보고서에는 다음도 포함됩니다.

• 기본 브랜치가 마지막으로 업데이트된 시점을 보여주는 타임스탬프이며, 최신 파이프라인 링크가 함께 표시됩니다. 기본 브랜치가 아닌 브랜치에서 실행되는 파이프라인은 이 타임스탬프를 갱신하지 않습니다.
• 가장 최근 파이프라인에서 발생한 실패 횟수입니다. 실패 알림을 선택하면 파이프라인 페이지의 Failed jobs 탭이 표시됩니다.

Activity 칼럼에는 해당 행의 취약점에 대해 수행된 활동이 있으면 이를 나타내는 아이콘이 표시됩니다.

• 이슈 [work-item-issue]: 취약점에 대해 생성된 이슈로 연결됩니다.
• 머지 리퀘스트 [merge-request]: 취약점에 대해 생성된 머지 리퀘스트로 연결됩니다.
• 체크된 원 [check-circle-dashed]: 취약점이 수정되었습니다.
• 거짓 양성 [false-positive]: 스캐너가 이 취약점을 거짓 양성으로 판단했습니다.
• 솔루션 [bulb]: 취약점에 사용할 수 있는 솔루션이 있음을 나타냅니다.
• 취약점 해결 [tanuki-ai]: 취약점에 사용할 수 있는 AI 해결책이 있음을 나타냅니다.
• 거짓 양성 감지 [tanuki-ai]: GitLab Duo가 이 취약점의 거짓 양성 여부를 분석했음을 나타냅니다. 아이콘 위에 포인터를 올리면 신뢰도 점수와 설명이 표시됩니다.

취약점에 대해 생성된 이슈를 열려면 Activity 항목 위에 포인터를 올린 다음 링크를 선택합니다. 이슈 아이콘([work-item-issue])은 이슈의 상태를 나타냅니다. Jira 이슈 지원이 활성화되어 있으면 Activity 항목의 이슈 링크가 Jira의 이슈로 연결됩니다. GitLab 이슈와 달리 Jira 이슈의 상태는 GitLab UI에 표시되지 않습니다.

Activity 칼럼의 빨간색 Malware 배지는 해당 취약점이 GitLab 멀웨어 어드바이저리를 근거로 멀웨어로 식별되었음을 나타냅니다.

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

취약점 보고서 보기#

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

사전 요구 사항:

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

취약점 보고서를 보려면 다음을 수행합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Secure > Vulnerability report를 선택합니다.

취약점 필터링#

히스토리

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

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

다음 항목으로 필터링할 수 있습니다.

• Status: 취약점의 현재 상태이며 needs triage, confirmed, dismissed, resolved 중 하나입니다. 무시된 취약점은 무시한 이유에 따라 함께 필터링하거나 개별적으로 필터링할 수 있습니다.
• Severity: 취약점의 심각도 값이며 critical, high, medium, low, info, unknown 중 하나입니다.
• Report type: SAST 또는 Container fuzzing 등 취약점을 감지한 보고서 유형입니다.
• Scanner: 취약점을 식별한 특정 스캐너입니다.
• Activity: 취약점에 이슈, 머지 리퀘스트, 사용 가능한 솔루션이 있는지 여부 등 취약점의 추가 속성입니다.
• Identifier: 취약점의 식별자입니다(고급 취약점 관리 필요. 고급 취약점 관리가 없으면 취약점이 최대 20,000개인 프로젝트와 그룹으로 제한됩니다).
• Project: 특정 프로젝트의 취약점을 필터링합니다(그룹에서만 사용 가능).
• Reachability: 도달 가능성 상태(yes, not found, not available)로 취약점을 필터링합니다. 이 필터를 사용하려면 고급 취약점 관리가 활성화되어 있어야 합니다.
• Validity check: 유효성 상태(active, inactive, possibly active)로 취약점을 필터링합니다. 이 필터를 사용하려면 고급 취약점 관리가 활성화되어 있어야 합니다.
• Malware: 멀웨어로 식별되었는지 여부(yes 또는 no)로 취약점을 필터링합니다. 프로젝트에서는 이 필터의 이름이 **Malware (default branch only)**입니다. 이 필터를 사용하려면 고급 취약점 관리가 활성화되어 있어야 합니다.
• Tracked ref: 취약점이 감지된 브랜치나 태그인 추적 ref로 취약점을 필터링합니다(프로젝트에서만 사용 가능). 이 필터를 사용하려면 고급 취약점 관리가 활성화되어 있어야 합니다.
• Policy violation: 우회 이유로 취약점을 필터링합니다. 경고 모드인 보안 정책의 정책 위반을 사용자가 우회했을 때 도입된 취약점을 표시합니다. 사용자는 경고 모드인 정책의 위반을 우회할 때 이유를 입력해야 합니다. 이 필터를 사용하려면 고급 취약점 관리가 활성화되어 있어야 합니다.

취약점 필터 적용#

히스토리

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

취약점 보고서를 필터링해 일부 취약점에 집중합니다.

취약점 목록을 필터링하려면 다음을 수행합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Secure > Vulnerability report를 선택합니다.
3. 선택 사항. 기본 필터를 제거하려면 Clear([clear])를 선택합니다.
4. 취약점 목록 위에서 필터 바를 선택합니다.
5. 표시되는 드롭다운 목록에서 필터링할 속성을 선택한 다음, 드롭다운 목록에서 값을 선택합니다.
6. 필터 필드 바깥쪽을 선택합니다. 취약점 심각도 합계와 조건에 맞는 취약점 목록이 업데이트됩니다.
7. 여러 속성으로 필터링하려면 앞의 세 단계를 반복합니다. 여러 속성은 논리 AND로 결합됩니다.

보고서 유형 필터#

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

Manually added 속성을 사용해 수동으로 추가된 취약점을 필터링합니다.

스캐너 필터#

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

프로젝트 필터#

Project 필터의 내용은 다음과 같이 달라집니다.

• Security Center: 개인 보안 센터에 추가한 프로젝트만 해당합니다.
• Group: 그룹의 모든 프로젝트입니다.
• Project: 해당 없음.

활동 필터#

히스토리

• 활동 필터 옵션 GitLab Duo (AI):
• GitLab 17.5에서 vulnerability_report_vr_filter라는 플래그와 함께 도입. 기본적으로 비활성화됨.
• 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 제거됨.

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

활동 필터를 사용할 때의 선택 동작은 다음과 같습니다.

• Activity
  • All activity: 활동 상태와 무관한 모든 취약점입니다(이 필터를 무시하는 것과 같습니다). 이 항목을 선택하면 다른 모든 활동 필터 옵션이 선택 해제됩니다.
• Detection
  • Still detected(기본값): default 브랜치의 최신 파이프라인 스캔에서 여전히 감지되는 취약점입니다.
  • No longer detected: default 브랜치의 최신 파이프라인 스캔에서 더 이상 감지되지 않는 취약점입니다.
• Issue
  • Has issues: 연결된 이슈가 하나 이상 있는 취약점입니다.
  • Does not have issue: 연결된 이슈가 없는 취약점입니다.
• Merge request
  • Has merge request: 연결된 머지 리퀘스트가 하나 이상 있는 취약점입니다.
  • Does not have merge request: 연결된 머지 리퀘스트가 없는 취약점입니다.
• Solution available
  • Has a solution: 자동 머지 리퀘스트로 해결할 수 있는 취약점입니다.
  • Does not have a solution: 자동 머지 리퀘스트 해결을 사용할 수 없는 취약점입니다.
• GitLab Duo resolution:
  • Vulnerability Resolution available: 사용 가능한 AI 해결책이 있는 취약점입니다.
  • Vulnerability Resolution unavailable: 사용 가능한 AI 해결책이 없는 취약점입니다.
• GitLab Duo FP detection:
  • False positive: GitLab Duo가 거짓 양성일 가능성이 높다고 표시한 취약점입니다.
  • Not identified as false positive: 거짓 양성으로 식별되지 않았거나 GitLab Duo가 표시하지 않은 취약점입니다.

GitLab Duo (AI) 필터는 다음 경우에 사용할 수 있습니다.

• 보안 센터 취약점 보고서: 보안 센터의 프로젝트 중 하나라도 GitLab Duo 토글이 켜져 있는 경우.
• 그룹 취약점 보고서: 해당 그룹에서 GitLab Duo features가 On by default로 설정된 경우.
• 프로젝트 취약점 보고서: 해당 프로젝트에서 GitLab Duo 토글이 켜져 있는 경우.

도달 가능성 필터#

히스토리

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

그룹과 프로젝트에서는 도달 가능성 값을 기준으로 취약점을 필터링할 수 있습니다. 기본적으로 취약점 보고서는 도달 가능성 값과 무관하게 모든 취약점을 나열합니다.

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

유효성 검사 필터#

히스토리

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

그룹과 프로젝트에서는 유효성 검사 값을 기준으로 취약점을 필터링할 수 있습니다. 기본적으로 취약점 보고서는 possibly active 상태의 취약점을 나열합니다.

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

멀웨어 필터#

히스토리

• GitLab 19.4에서 vulnerability_malware_detection이라는 피처 플래그와 함께 베타 기능으로 도입. 기본적으로 활성화됨.
• GitLab 19.5에서 일반적으로 사용 가능. 피처 플래그 vulnerability_malware_detection 제거됨.

그룹과 프로젝트에서는 멀웨어로 식별되었는지 여부를 기준으로 취약점을 필터링할 수 있습니다. 기본적으로 취약점 보고서는 멀웨어 상태와 무관하게 모든 취약점을 나열합니다.

멀웨어 감지는 프로젝트의 기본 브랜치에서만 실행되므로, 이 필터는 해당 브랜치에서 발견된 취약점만 다룹니다. 추적 ref로 필터링도 할 수 있는 프로젝트 취약점 보고서에서는 이 필터의 이름이 **Malware (default branch only)**입니다. 추적 ref 필터가 없는 그룹 취약점 보고서에서는 이 필터의 이름이 Malware입니다.

멀웨어 상태는 추적 ref 필터가 기본 브랜치 하나만으로 설정되어 있을 때에만 선택할 수 있습니다. 그 밖의 추적 ref를 선택한 경우 이 필터에는 Yes 및 No 옵션 대신 To filter by malware, remove the filter for other tracked refs 메시지가 표시됩니다. 멀웨어 필터를 이미 적용한 뒤 추적 ref 필터를 변경하면 GitLab은 멀웨어 필터를 제거합니다.

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

추적 ref 필터#

히스토리

• GitLab 18.7에서 vulnerabilities_across_contexts라는 피처 플래그와 함께 도입. 기본적으로 비활성화됨.
• GitLab 19.3에서 기본적으로 활성화.

프로젝트에서는 GitLab이 보안 발견 항목을 추적하는 브랜치나 태그인 추적 ref를 기준으로 취약점을 필터링할 수 있습니다. Branches와 Tags 아래에 묶인 옵션과 All tracked refs 옵션에서 한 번에 두 개 이상의 ref를 선택할 수 있습니다. 기본적으로 이 필터는 프로젝트의 기본 브랜치로 설정됩니다.

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

취약점 그룹화#

히스토리

• 그룹별 취약점 그룹화:
• GitLab 16.7에서 group_level_vulnerability_report_grouping이라는 플래그와 함께 도입. 기본적으로 비활성화됨.
• GitLab 17.2에서 GitLab Self-Managed 및 GitLab Dedicated에서 활성화.
• GitLab 17.3에서 일반적으로 사용 가능. 피처 플래그 group_level_vulnerability_report_grouping 제거됨.
• 그룹별 OWASP top 10 취약점 그룹화:
• GitLab 16.8에서 vulnerability_owasp_top_10_group이라는 피처 플래그와 함께 도입. 기본적으로 비활성화됨.
• GitLab 17.4에서 GitLab Self-Managed 및 GitLab Dedicated에서 활성화.
• GitLab 17.4에서 일반적으로 사용 가능. 피처 플래그 vulnerability_owasp_top_10_group 제거됨.
• OWASP top 10 그룹화의 비 OWASP 범주:
• GitLab 17.1에서 owasp_top_10_null_filtering이라는 피처 플래그와 함께 도입. 기본적으로 비활성화됨.
• 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에서 활성화.
• GitLab 18.11에서 일반적으로 사용 가능.
• OWASP 2025 top 10 그룹화:
• GitLab 19.4에서 owasp2025_vulnerability_filter라는 플래그와 함께 도입. GitLab.com과 GitLab Dedicated에서 활성화됨.
• GitLab 19.5에서 일반적으로 사용 가능. 피처 플래그 owasp2025_vulnerability_filter 제거됨.

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

다음 항목으로 그룹화할 수 있습니다.

• Status
• Severity
• Report Type
• Scanner
• OWASP top 10 2017
• OWASP top 10 2021(고급 취약점 관리 필요)
• OWASP top 10 2025(고급 취약점 관리 필요)

취약점 그룹 지정#

취약점을 그룹화하려면 다음을 수행합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Secure > Vulnerability report를 선택합니다.
3. Group By 드롭다운 목록에서 그룹을 선택합니다.

취약점은 선택한 그룹에 따라 그룹화됩니다. 각 그룹은 접힌 상태로 표시되며, 그룹별 총 취약점 개수가 그룹 이름 옆에 표시됩니다. 각 그룹의 취약점을 보려면 그룹 이름을 선택합니다.

취약점 세부 정보 보기#

취약점의 세부 정보를 더 보려면 취약점의 Description을 선택합니다. 취약점 세부 정보 페이지가 열립니다.

취약점 상태 변경#

취약점을 분류하면서 무시 처리를 포함해 상태를 변경할 수 있습니다.

취약점을 무시하면 감사 로그에 누가 무시했는지, 언제 무시했는지, 무시한 이유가 기록됩니다. 취약점 레코드는 삭제할 수 없으므로 영구 기록이 항상 남습니다.

사전 요구 사항:

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

취약점의 상태를 변경하려면 다음을 수행합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Secure > Vulnerability report를 선택합니다.
3. 다음과 같이 선택합니다.
   • 취약점 하나 이상을 선택하려면 각 취약점 옆의 체크박스를 선택합니다.
   • 페이지의 모든 취약점을 선택하려면 표 헤더의 체크박스를 선택합니다.
4. Set status 드롭다운 목록에서 원하는 상태를 선택합니다.
5. Dismiss 상태를 선택한 경우 Set dismissal reason 드롭다운 목록에서 원하는 이유를 선택합니다.
6. Add a comment 입력란에 코멘트를 입력할 수 있습니다. Dismiss 상태에서는 코멘트가 필수입니다.
7. Change status를 선택합니다.

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

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

히스토리

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

특정 경우에는 감지된 취약점의 심각도를 조직의 우선순위에 더 잘 맞게 조정해야 할 수 있습니다. 예를 들어 스캐너는 낮은 심각도로 보고하지만, 사용 환경이나 구성에 따라 더 치명적이라고 판단할 수 있습니다. 이 기능을 사용하면 스캐너가 할당한 기본 심각도를 재정의할 수 있습니다.

사전 요구 사항:

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

취약점의 심각도를 수동으로 재정의하려면 다음을 수행합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. Secure > Vulnerability report로 이동합니다.
3. 취약점을 선택합니다.
   • 개별 취약점을 선택하려면 각 취약점 옆의 체크박스를 선택합니다.
   • 페이지의 모든 취약점을 선택하려면 표 헤더의 체크박스를 선택합니다.
4. Select action 드롭다운 목록에서 Change severity를 선택합니다.
5. Select severity 드롭다운 목록에서 원하는 심각도 수준을 선택합니다.
6. Add reason for the severity change (required) 텍스트 상자에 심각도를 변경하는 이유를 간단히 설명합니다.
7. Change severity를 선택합니다.

선택한 각 취약점에는 다음이 적용됩니다.

• Vulnerability details page와 Vulnerability report 양쪽에서 심각도가 업데이트됩니다.
• 심각도에 배지가 추가되어 심각도가 재정의되었음을 나타냅니다.
• 수동 심각도 조정은 취약점의 history에 기록됩니다.

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

히스토리

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

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

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

hide_vulnerability_severity_override 플래그를 활성화하려면 피처 플래그로 배포된 GitLab 기능 활성화 및 비활성화를 참고합니다.

기존 이슈에 취약점 추가#

히스토리

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

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

사전 요구 사항:

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

취약점을 기존 이슈에 첨부하려면 다음을 수행합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
2. Secure > Vulnerability report로 이동합니다.
3. 취약점을 선택합니다.
   • 개별 취약점을 선택하려면 각 취약점 옆의 체크박스를 선택합니다.
   • 페이지의 모든 취약점을 선택하려면 표 헤더의 체크박스를 선택합니다.
4. Select action 드롭다운 목록에서 Attach to existing issue를 선택합니다.
5. Enter issue URL or <#issue ID> 텍스트 상자에 자동 완성할 이슈의 ID를 입력하거나 이슈의 URL을 추가합니다. 취약점을 추가할 이슈를 여러 개 입력할 수 있습니다.
6. Add를 선택합니다.

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

새 이슈에 취약점 추가#

히스토리

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

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

사전 요구 사항:

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

취약점을 새 이슈에 첨부하려면 다음을 수행합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
2. Secure > Vulnerability report로 이동합니다.
3. 취약점을 선택합니다.
   • 개별 취약점을 선택하려면 각 취약점 옆의 체크박스를 선택합니다.
   • 페이지의 모든 취약점을 선택하려면 표 헤더의 체크박스를 선택합니다.
4. Select action 드롭다운 목록에서 Attach to new issue를 선택합니다.
5. Create issue를 선택합니다.

새 이슈로 이동합니다. 선택한 각 취약점은 이미 해당 이슈에 연결되어 있습니다.

AI 플로 일괄 실행#

히스토리

• GitLab 19.3에서 bulk_vulnerabilities_duo_workflow_api라는 피처 플래그와 함께 베타 기능으로 도입. 기본적으로 비활성화됨.
• GitLab 19.4에서 GitLab.com과 GitLab Self-Managed에 대해 기본적으로 활성화.

GitLab Duo SAST 거짓 양성 감지와 취약점 해결을 여러 취약점에 대해 한 번에 실행할 수 있습니다. 자세한 내용은 여러 취약점 해결과 여러 취약점 분석을 참고합니다.

감지 날짜별 취약점 정렬#

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

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

내보내기#

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

포함되는 필드는 다음과 같습니다.

• Status(상태 값이 어떻게 내보내지는지는 다음 표를 참고합니다.)
• Group name
• Project name
• Report type
• Scanner name
• Vulnerability
• Basic details
• Additional information
• Severity
• CVE (Common Vulnerabilities and Exposures)
• CWE (Common Weakness Enumeration)
• Other identifiers
• Detected At
• Location
• Activity: 기본 브랜치에서 취약점이 해결되었으면 true를, 그렇지 않으면 false를 반환합니다.
• Comments
• Full Path
• CVSS Vectors
• Dismissal Reason
• Vulnerability ID

취약점 보고서에 표시되는 Status 필드 값은 취약점 내보내기에 포함되는 값과 다릅니다. 다음 참조 표를 사용해 대응 관계를 확인합니다.

세부 정보 내보내기#

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

내보낸 세부 정보가 준비되면 이메일이 발송됩니다. 내보낸 세부 정보를 다운로드하려면 이메일의 링크를 선택합니다.

취약점 수동 추가#

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

취약점을 수동으로 추가하려면 다음을 수행합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Secure > Vulnerability report를 선택합니다.
3. Submit vulnerability를 선택합니다.
4. 필드를 작성하고 양식을 제출합니다.

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

고급 취약점 관리#

히스토리

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

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

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

1. 프로젝트 또는 그룹의 취약점 보고서에서 OWASP 2021 범주별 데이터 그룹화.
2. 프로젝트 또는 그룹의 취약점 보고서에서 OWASP 2025 범주별 데이터 그룹화.
3. 프로젝트 또는 그룹의 취약점 보고서에서 취약점 식별자 기반 필터링.
4. 프로젝트 또는 그룹의 취약점 보고서에서 도달 가능성 값 기반 필터링.
5. 프로젝트 또는 그룹의 취약점 보고서에서 유효성 검사 상태 기반 필터링.
6. 프로젝트 또는 그룹의 취약점 보고서와 의존성 목록에서 멀웨어 상태 기반 필터링.
7. 프로젝트의 취약점 보고서와 의존성 목록에서 추적 ref 기반 필터링.
8. 프로젝트 또는 그룹의 취약점 보고서에서 정책 위반 우회 이유 기반 필터링.
9. 새 보안 대시보드의 패널 및 전체 대시보드 데이터 필터링.

고급 검색은 다른 필터와 함께 사용하는 경우를 포함해 이러한 특정 기능에만 사용됩니다. 다른 필터를 단독으로 사용하면 계속 표준 PostgreSQL 필터링을 사용합니다.

요구 사항#

고급 취약점 관리의 기능을 사용하려면 다음 조건을 충족해야 합니다.

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

운영 취약점#

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