%%{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 제거됨.
취약점을 해결하려고 의도적으로 변경한 결과로, 또는 다른 변경의 부수 효과로 취약점이 더 이상
감지되지 않을 수 있습니다. 취약점을 보고한 분석기가 해당 언어를 더 이상 스캔하지 않아서
취약점이 더 이상 감지되지 않을 수도 있습니다. 예시는
취약점 변경을 참고합니다.
보안 스캔이 실행되었을 때 기본 브랜치에서 취약점이 더 이상 감지되지
않으면 스캐너는 해당 레코드의 활동 로그에 No longer detected를 추가하지만, 레코드의 상태는
바뀌지 않습니다. 대신 취약점이 해결되었는지 확인한 다음, 해결되었다면
상태를 수동으로 Resolved로 변경합니다.
취약점 관리 정책을 사용하면 특정 기준에
맞는 취약점의 상태를 자동으로 Resolved로
변경할 수도 있습니다.
취약점을 해결한 커밋에 대한 링크는 취약점 페이지의 Activity 섹션에서 확인할 수
있습니다.
취약점 무시 이유#
취약점을 무시할 때는 다음 이유 중 하나를 선택해야 합니다:

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

취약점 상태 변경#
히스토리
Developer 역할을 가진 사용자가 취약점 상태를 변경할 수 있게 하던 권한(admin_vulnerability)이 GitLab 16.4에서 더 이상 사용되지 않음으로 표시되고 GitLab 17.0에서 제거됨.
Comment 텍스트 상자가 GitLab 17.9에서 추가됨.
사전 요구 사항:

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

취약점 페이지에서 취약점 상태를 변경하려면 다음과 같이 진행합니다:

상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 Secure > Vulnerability report를 선택합니다.
취약점 설명을 선택합니다.
오른쪽 사이드바의 Status 섹션에서 Edit를 선택합니다.
Status 드롭다운 목록에서 상태를 선택하거나, 취약점 상태를 Dismissed로 변경하려면
무시 이유를 선택합니다.
Comment 텍스트 상자에 무시 이유에 대한 자세한 내용을 담은 코멘트를 입력합니다. Dismissed 상태를 적용할 때는 코멘트가 필요합니다.
Change status를 선택합니다.

변경한 사람과 변경 시점을 포함한 상태 변경 세부 정보가 취약점 페이지의
Activity 섹션에 기록됩니다.
취약점에 대한 GitLab 이슈 생성#
취약점을 해결하거나 완화하기 위해 취한 조치를 추적하는 GitLab 이슈를 생성할 수 있습니다.
취약점에 대한 GitLab 이슈를 생성하려면 다음과 같이 진행합니다:

상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 Secure > Vulnerability report를 선택합니다.
취약점 설명을 선택합니다.
Create issue를 선택합니다.

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

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

취약점을 기존 GitLab 이슈에 연결하려면 다음과 같이 진행합니다:

상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 Secure > Vulnerability report를 선택합니다.
취약점 설명을 선택합니다.
Related issues 섹션에서 Add existing issue를 선택합니다.
연결할 각 이슈에 대해 다음 중 하나를 수행합니다:

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


Add를 선택합니다.

선택한 GitLab 이슈가 Related issues 섹션에 추가되고 연결된 이슈 카운터가
업데이트됩니다.
취약점에 연결된 GitLab 이슈는 취약점 보고서와 취약점 페이지에 표시됩니다.
취약점과 연결된 GitLab 이슈 사이의 다음 조건에 유의합니다:

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

취약점을 기존 Jira 이슈에 연결#
사전 요구 사항:

Jira 이슈 통합이 구성되어
있고 Create Jira issues for vulnerabilities 체크박스가 선택되어 있어야 합니다.

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

<id>는 임의의 취약점 ID입니다.
서로 다른 ID를 담은 여러 줄을 하나의 설명에 추가할 수 있습니다.
적절한 설명이 포함된 Jira 이슈가 Related Jira issues 섹션에 추가되고 연결된 이슈 카운터가
업데이트됩니다.
취약점에 연결된 Jira 이슈는 취약점 페이지에만 표시됩니다.
취약점과 연결된 Jira 이슈 사이의 다음 조건에 유의합니다:

취약점 페이지와 이슈 페이지 모두 서로 관련된 취약점을 표시합니다.
이슈는 한 번에 하나 이상의 취약점에 연결될 수 있습니다.

취약점 해결 절차#
일부 취약점은 해결책이 이미 알려져 있지만 수동으로 구현해야 합니다. 취약점 페이지의
Remediation 섹션에는 보안 결과를 보고한 보안 스캔 도구가 제공한 해결책이나
취약점을 수동으로 생성할 때 입력한 해결책이 표시됩니다.
GitLab 도구는 GitLab 어드바이저리 데이터베이스의 정보를 활용합니다.
또한 일부 도구는 제안된 해결책을 적용하는 소프트웨어 패치를 포함할 수 있습니다. 이 경우
취약점 페이지의 Other actions 드롭다운 목록에 Resolve with scanner suggestion 작업이 포함됩니다.
이 기능이 지원하는 스캐너는 다음과 같습니다:


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


컨테이너 스캐닝.


취약점을 해결하려면 다음 중 하나를 수행합니다:

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

머지 리퀘스트로 취약점 해결#
머지 리퀘스트로 취약점을 해결하려면 다음과 같이 진행합니다:

상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 Secure > Vulnerability report를 선택합니다.
취약점 설명을 선택합니다.
오른쪽 위에서 Other actions를 선택한 다음 Resolve with scanner suggestion을 선택합니다.

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

상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 Secure > Vulnerability report를 선택합니다.
취약점 설명을 선택합니다.
오른쪽 위에서 Other actions를 선택한 다음 Download Patch를 선택합니다.
로컬 프로젝트에 패치를 생성할 때 사용한 것과 같은 커밋이 체크아웃되어 있는지 확인합니다.
git apply remediation.patch를 실행합니다.
변경 사항을 확인하고 브랜치에 커밋합니다.
변경 사항을 main 브랜치에 적용하는 머지 리퀘스트를 생성합니다.
표준 워크플로에 따라 머지 리퀘스트를 처리합니다.

취약점에 대한 보안 교육 활성화#
Note
보안 교육은 보안 조치로 공용 인터넷과 분리된 컴퓨터, 즉 오프라인 환경에서는 이용할 수 없습니다. 구체적으로는 활성화하려는 교육 제공업체의 API 엔드포인트를 GitLab 서버가 조회할 수 있어야 합니다. 일부 서드파티 교육 공급업체는 무료 계정 등록을 요구할 수 있습니다.
Secure Code Warrior, Kontra, SecureFlag 중 하나로 이동해 계정을 등록합니다.
GitLab은 이러한 서드파티 공급업체에 사용자 정보를 전송하지 않습니다. GitLab이 전송하는 것은 CWE 또는 OWASP 식별자와 파일 확장자의 언어 이름입니다.

보안 교육은 개발자가 취약점을 수정하는 방법을 익히는 데 도움이 됩니다. 개발자는 감지된 취약점과 관련된 보안 교육을 선택된 교육 제공업체로부터 확인할 수 있습니다.
프로젝트에서 취약점에 대한 보안 교육을 활성화하려면 다음과 같이 진행합니다:

상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 Secure > Security configuration을 선택합니다.
탭 바에서 Vulnerability Management를 선택합니다.
보안 교육 제공업체를 활성화하려면 토글을 켭니다.

각 통합은 CWE 또는 OWASP 같은 취약점 식별자와 언어를 보안 교육 공급업체에 제출합니다. 그 결과로 만들어진 공급업체 교육 링크가 GitLab 취약점에 표시됩니다.
취약점에 대한 보안 교육 보기#
보안 교육이 활성화되어 있으면 취약점 페이지에 감지된 취약점과 관련된 교육 링크가 표시될 수 있습니다.
교육 제공 여부는 활성화된 교육 공급업체가 해당 취약점에 맞는 콘텐츠를 보유하고 있는지에 따라 달라집니다.
교육 콘텐츠는 취약점 식별자를 기준으로 요청됩니다.
취약점에 부여되는 식별자는 취약점마다 다르고, 제공되는 교육 콘텐츠도 공급업체마다
다릅니다. 일부 취약점은 교육 콘텐츠를 표시하지 않습니다.
CWE가 있는 취약점은 교육 결과를 반환할 가능성이 가장 높습니다.
취약점에 대한 보안 교육을 보려면 다음과 같이 진행합니다:

상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 Secure > Vulnerability report를 선택합니다.
보안 교육을 보려는 취약점을 선택합니다.
Supplementary information 섹션의 Training 아래에서 View training을 선택합니다.

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

의존성에서 발견된 취약점을 관리할 때 취약점 페이지의 Details 섹션에는 다음이
표시됩니다:

취약점이 발견된 직접 의존성의 위치입니다.
가능한 경우 취약점이 발생하는 구체적인 줄 번호입니다.

취약점이 하나 이상의 전이적 의존성에서 발생하는 경우에는 직접 의존성만 알아서는 충분하지 않을 수 있습니다. 전이적 의존성은 직접 의존하는 항목을 상위에 두고 있는 간접 의존성입니다.
전이적 의존성이 있으면 취약점을 포함한 전이적 의존성을 비롯해 모든 의존성에 이르는 경로를 볼 수 있습니다.

취약점 페이지의 Details 섹션에서 View dependency paths를 선택합니다. View dependency paths가 표시되지 않으면 전이적 의존성이 없습니다.