%%{init: { "fontFamily": "GitLab Sans" }}%%
stateDiagram
    accTitle: Vulnerability lifecycle
    accDescr: Typical lifecycle of a vulnerability
direction LR
Needs_triage: Needs triage

[*] --> Needs_triage
Needs_triage --> Confirmed
Needs_triage --> Dismissed
Dismissed --> [*]
Confirmed --> Resolved
Resolved --> Needs_triage: If reintroduced and detected again
Resolved --&gt; [*]</code></pre></details></div>

취약점이 더 이상 감지되지 않는 경우#
히스토리
취약점을 해결한 커밋에 대한 링크가 GitLab 17.9에서 도입되고 GitLab Self-Managed 및 GitLab Dedicated에서 일반적으로 사용 가능하게 됨. 피처 플래그 vulnerability_representation_information 제거됨.
취약점이 의도적으로 수정되었거나 다른 변경의 부작용으로 더 이상 감지되지 않을 수 있습니다. 보안 스캔이 실행되고 기본 브랜치에서 취약점이 더 이상 감지되지 않으면, 스캐너는 레코드의 활동 로그에 더 이상 감지되지 않음을 추가하지만 레코드의 상태는 변경되지 않습니다. 대신 취약점이 해결되었는지 확인하고 그렇다면 수동으로 상태를 Resolved로 변경해야 합니다. 또한 취약점 관리 정책을 사용하여 특정 기준과 일치하는 취약점의 상태를 자동으로 Resolved로 변경할 수 있습니다.
취약점 페이지의 상단 또는 하단에서 취약점을 해결한 커밋에 대한 링크를 찾을 수 있습니다.
취약점 무시 이유#
히스토리
GitLab 15.11에서 dismissal_reason이라는 플래그와 함께 도입.
GitLab 16.0에서 GitLab Self-Managed 및 GitLab Dedicated에서 활성화.
GitLab 16.2에서 일반적으로 사용 가능. 피처 플래그 dismissal_reason 제거됨.
취약점을 무시할 때 다음 이유 중 하나를 선택해야 합니다:

Acceptable risk (허용 가능한 위험): 취약점이 알려져 있고 수정되거나 완화되지 않았지만 허용 가능한 비즈니스 위험으로 간주됩니다.
False positive (거짓 양성): 시스템에 취약점이 없는데도 취약점이 있다고 잘못 표시하는 보고 오류.
Mitigating control (완화 제어): 취약점의 위험이 정보 시스템에 동등하거나 비교 가능한 보호를 제공하는 조직이 사용하는 관리, 운영 또는 기술 제어(즉, 보호 장치 또는 대책)에 의해 완화됩니다.
Used in tests (테스트에 사용됨): 결과가 테스트의 일부이거나 테스트 데이터이기 때문에 취약점이 아닙니다.
Not applicable (해당 없음): 취약점이 알려져 있고 수정되거나 완화되지 않았지만 업데이트되지 않을 애플리케이션 부분에 있는 것으로 간주됩니다.

취약점 상태 변경#
히스토리
Developer 역할의 사용자가 취약점 상태를 변경(admin_vulnerability)할 수 있는 권한이 GitLab 16.4에서 더 이상 사용되지 않음으로 표시되고 GitLab 17.0에서 제거됨.
코멘트 텍스트 상자가 GitLab 17.9에서 추가됨.
필수 조건:

프로젝트에 대한 Maintainer 또는 Owner 역할 또는 admin_vulnerability 권한이 있는 사용자 정의 역할이 있어야 합니다.

취약점 페이지에서 취약점 상태를 변경하려면:

상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
Secure > 취약점 보고서를 선택합니다.
취약점 설명을 선택합니다.
상태 변경을 선택합니다.
상태 드롭다운 목록에서 상태 또는 취약점 상태를 Dismissed로 변경하려는 경우 무시 이유를 선택합니다.
코멘트 텍스트 상자에서 무시 이유에 대한 자세한 내용이 포함된 코멘트를 입력합니다. Dismissed 상태를 적용할 때 코멘트가 필요합니다.

누가 변경했는지, 언제 변경했는지를 포함한 상태 변경 세부 정보가 취약점의 조치 로그에 기록됩니다.
취약점에 대한 GitLab 이슈 생성#
취약점을 해결하거나 완화하기 위해 취한 조치를 추적하는 GitLab 이슈를 생성할 수 있습니다. 취약점에 대한 GitLab 이슈를 생성하려면:

상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
Secure > 취약점 보고서를 선택합니다.
취약점 설명을 선택합니다.
이슈 생성을 선택합니다.

취약점 보고서의 정보가 포함된 GitLab 프로젝트에 이슈가 생성됩니다.
Jira 이슈를 생성하려면 취약점에 대한 Jira 이슈 생성을 참조하세요.
취약점을 GitLab 및 Jira 이슈에 연결#
취약점을 하나 이상의 기존 GitLab 또는 Jira 이슈에 연결할 수 있습니다. 한 번에 하나의 연결 기능만 사용할 수 있습니다. 링크를 추가하면 취약점을 해결하거나 완화하는 이슈를 추적하는 데 도움이 됩니다.
취약점을 기존 GitLab 이슈에 연결#
필수 조건:

Jira 이슈 통합이 활성화되어 있지 않아야 합니다.

취약점을 기존 GitLab 이슈에 연결하려면:

상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
Secure > 취약점 보고서를 선택합니다.
취약점 설명을 선택합니다.
연결된 이슈 섹션에서 더하기 아이콘 (+)을 선택합니다.
연결할 각 이슈에 대해 다음 중 하나를 수행합니다:

이슈에 대한 링크를 붙여넣습니다.
이슈의 ID(해시 # 앞에 추가)를 입력합니다.


추가를 선택합니다.

선택한 GitLab 이슈가 연결된 항목 섹션에 추가되고 연결된 이슈 카운터가 업데이트됩니다.
취약점에 연결된 GitLab 이슈는 취약점 보고서와 취약점 페이지에 표시됩니다.
취약점과 연결된 GitLab 이슈 간의 다음 조건에 주의하세요:

취약점 페이지에는 관련 이슈가 표시되지만 이슈 페이지에는 관련 취약점이 표시되지 않습니다.
이슈는 한 번에 하나의 취약점에만 관련될 수 있습니다.
이슈는 그룹과 프로젝트 간에 연결될 수 있습니다.

취약점을 기존 Jira 이슈에 연결#
필수 조건:

Jira 이슈 통합이 구성되고 취약점에 대한 Jira 이슈 생성 체크박스가 선택되어 있어야 합니다.

취약점을 기존 Jira 이슈에 연결하려면 Jira 이슈 설명에 다음 줄을 추가합니다:
/-/security/vulnerabilities/<id>

<id>는 모든 취약점 ID입니다. 하나의 설명에 다른 ID가 있는 여러 줄을 추가할 수 있습니다.
적절한 설명이 있는 Jira 이슈가 관련 Jira 이슈 섹션에 추가되고 연결된 이슈 카운터가 업데이트됩니다.
취약점에 연결된 Jira 이슈는 취약점 페이지에만 표시됩니다.
취약점과 연결된 Jira 이슈 간의 다음 조건에 주의하세요:

취약점 페이지와 이슈 페이지 모두 관련 취약점을 표시합니다.
이슈는 동시에 하나 이상의 취약점과 관련될 수 있습니다.

취약점 해결#
일부 취약점의 경우 이미 솔루션이 알려져 있지만 수동으로 구현해야 합니다. 취약점 페이지의 솔루션 필드는 보안 결과를 보고한 보안 스캔 도구가 제공하거나 취약점을 수동으로 생성할 때 입력됩니다. GitLab 도구는 GitLab 어드바이저리 데이터베이스의 정보를 활용합니다.
또한 일부 도구에는 제안된 솔루션을 적용하기 위한 소프트웨어 패치가 포함될 수 있습니다. 이러한 경우 취약점 페이지에 머지 리퀘스트로 해결 옵션이 포함됩니다.
다음 스캐너가 이 기능을 지원합니다:


의존성 스캔. 자동 패치 생성은 yarn으로 관리되는 Node.js 프로젝트에만 사용 가능합니다. 자동 패치 생성은 FIPS 모드가 비활성화된 경우에만 지원됩니다.


컨테이너 스캔.


취약점을 해결하려면 다음 중 하나를 사용할 수 있습니다:

머지 리퀘스트로 취약점 해결.
취약점을 수동으로 해결.

머지 리퀘스트로 취약점 해결#
머지 리퀘스트로 취약점을 해결하려면:

상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
Secure > 취약점 보고서를 선택합니다.
취약점 설명을 선택합니다.
머지 리퀘스트로 해결 드롭다운 목록에서 머지 리퀘스트로 해결을 선택합니다.

취약점을 해결하는 데 필요한 패치를 적용하는 머지 리퀘스트가 생성됩니다. 표준 워크플로에 따라 머지 리퀘스트를 처리합니다.
취약점 수동 해결#
GitLab이 취약점에 대해 생성한 패치를 수동으로 적용하려면:

상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
Secure > 취약점 보고서를 선택합니다.
취약점 설명을 선택합니다.
머지 리퀘스트로 해결 드롭다운 목록에서 해결을 위한 패치 다운로드를 선택합니다.
로컬 프로젝트에 패치를 생성하는 데 사용된 것과 동일한 커밋이 체크아웃되어 있는지 확인합니다.
git apply remediation.patch를 실행합니다.
변경 사항을 확인하고 브랜치에 커밋합니다.
변경 사항을 메인 브랜치에 적용하는 머지 리퀘스트를 생성합니다.
표준 워크플로에 따라 머지 리퀘스트를 처리합니다.

취약점에 대한 보안 교육 활성화#
Note
보안 교육은 공공 인터넷에서 격리된 컴퓨터인 오프라인 환경에서는 접근할 수 없습니다. 특히, GitLab 서버는 활성화하도록 선택한 교육 공급업체의 API 엔드포인트를 쿼리할 수 있어야 합니다. 일부 타사 교육 공급업체는 무료 계정 가입이 필요할 수 있습니다. Secure Code Warrior, Kontra, 또는 SecureFlag 중 하나에서 계정을 등록하세요. GitLab은 이러한 타사 공급업체에 사용자 정보를 보내지 않습니다. GitLab은 CWE 또는 OWASP 식별자와 파일 확장자의 언어 이름만 보냅니다.

보안 교육은 개발자가 취약점을 수정하는 방법을 배우는 데 도움이 됩니다. 개발자는 감지된 취약점과 관련된 선택한 교육 공급업체의 보안 교육을 볼 수 있습니다.
프로젝트의 취약점에 대한 보안 교육을 활성화하려면:

상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 Secure > 보안 구성을 선택합니다.
탭 바에서 취약점 관리를 선택합니다.
보안 교육 공급업체를 활성화하려면 토글을 켭니다.

각 통합은 CWE 또는 OWASP와 같은 취약점 식별자와 언어를 보안 교육 공급업체에 제출합니다. 결과 링크는 GitLab 취약점에 공급업체 교육으로 표시됩니다.
취약점에 대한 보안 교육 보기#
보안 교육이 활성화된 경우 취약점 페이지에 감지된 취약점과 관련된 교육 링크가 포함될 수 있습니다. 교육의 사용 가능 여부는 활성화된 교육 공급업체가 특정 취약점과 일치하는 콘텐츠를 가지고 있는지에 따라 다릅니다. 교육 콘텐츠는 취약점 식별자를 기반으로 요청됩니다. 취약점에 부여된 식별자는 취약점마다 다르며 공급업체 간에 사용 가능한 교육 콘텐츠가 다릅니다. 일부 취약점은 교육 콘텐츠를 표시하지 않습니다. CWE가 있는 취약점이 교육 결과를 반환할 가능성이 가장 높습니다.
취약점에 대한 보안 교육을 보려면:

상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
Secure > 취약점 보고서를 선택합니다.
보안 교육을 보려는 취약점을 선택합니다.
교육 보기를 선택합니다.

전이적 의존성에서 취약점 위치 보기#
히스토리
의존성 경로 보기 옵션이 dependency_paths라는 플래그와 함께 GitLab 17.11에서 도입. 기본적으로 비활성화됨.
의존성 경로 보기 옵션이 GitLab 18.2에서 일반적으로 사용 가능. 피처 플래그 dependency_paths 기본적으로 활성화됨.
Feature flag
이 기능의 사용 가능 여부는 피처 플래그로 제어됩니다.
자세한 내용은 이력을 참조하세요.

취약점 세부 정보에서 의존성에서 발견된 취약점을 관리할 때 위치 아래에서 다음을 볼 수 있습니다:

취약점이 발견된 직접 의존성의 위치.
사용 가능한 경우 취약점이 발생하는 특정 줄 번호.

취약점이 하나 이상의 전이적 의존성에서 발생하는 경우, 직접 의존성만 아는 것으로는 충분하지 않을 수 있습니다. 전이적 의존성은 직접 의존성을 조상으로 가진 간접 의존성입니다.
전이적 의존성이 있는 경우, 취약점을 포함한 전이적 의존성을 포함한 모든 의존성에 대한 경로를 볼 수 있습니다.

취약점 세부 정보 페이지의 위치 아래에서 의존성 경로 보기를 선택합니다. 의존성 경로 보기가 나타나지 않으면 전이적 의존성이 없습니다.