인시던트 문제 관리

준수 관점에서 지속적 통합 및 지속적 준수 파이프라인의 일부로 인시던트 문제 (취약성, CVE) 를 작성, 저장 및 업데이트하는 것은 증거 콜렉션에 필수적입니다.

증거 수집이 활성화된 상태에서 PR 파이프라인, CI 및 CC 파이프라인을 실행하는 동안 collect-evidence 스크립트 은 인시던트 이슈를 생성하고 수집된 증거에 첨부하여 인시던트 이슈 리포지토리에 저장합니다.

collect-evidence 스크립트는 제공된 스캔 결과를 처리하고 취약성별로 제공된 저장소에서 새 인시던트 문제를 작성하거나 주제-인시던트 쌍을 기반으로 기존 인시던트 문제를 업데이트하는 코코아 인시던트 프로세스 명령의 기능을 사용합니다. 따라서 인시던트 문제는 자산에 바인드되고 특정 공구의 결과에 따라 작성됩니다. 자세한 정보는 CI및 CC 파이프라인의 문제 처리 간 차이 를 참조하십시오.

PR 파이프라인에서 인시던트 이슈 처리

증거 수집이 활성화된 PR 파이프라인은 취약성 또는 CVE가 발생했을 때 인시던트 이슈를 생성할 수 있습니다. PR 파이프라인에서 증거 수집을 활성화하려면 다음을 참조하세요:PR 파이프라인 증거 수집

인시던트 이슈에 대한 PR 파이프라인의 이슈 관리는 CI 파이프라인의 이슈 관리와 유사합니다. 유일한 차이점은 자동 닫기 로직에 있습니다.

PR 파이프라인에서 만든 인시던트 이슈는 동일한 PR에서 실행 중인 PR 파이프라인에 의해서만 자동 클로즈될 수 있습니다. PR 파이프라인에서 이슈를 자동 클로즈할 수 없는 경우는 다음과 같습니다:

이 문제는 다른 PR에서 실행 중인 PR 파이프라인에서 발견됩니다.
이 문제는 모든 CI 또는 CC 파이프라인에서 발견됩니다.

인시던트 문제 처리

CI및 CC 파이프라인에 공통 단계가 있는 경우에도 이러한 파이프라인의 문제 처리에는 몇 가지 차이점이 있습니다.

CI 파이프라인 중에 작성되는 인시던트 문제는 만료 날짜를 수반하지 않는 반면, CC 파이프라인 중에 작성되는 인시던트 문제는 만료 날짜를 수반합니다.
CI 파이프라인 중에 작성되는 인시던트 문제는 빌드 중에 발견되는 반면, CC 파이프라인 중에 작성되는 인시던트 문제는 프로덕션 환경에서 발견됩니다.

그림 1-6은 이러한 차이점을 기반으로 하는 가능한 유스 케이스를 보여줍니다.

문제 라이프사이클

문제 라이프사이클은 코드 PR에서 프로덕션 스캔까지 확장됩니다.

취약성 사용 사례 흐름 — DevSecOps/하나의 파이프라인 수명 주기

유스 케이스 1: 빌드에서 발견된 취약성

새 빌드는 허용되지 않는 취약성을 도입합니다. 변경 요청이 수동으로 승인된 응급 CR이 아닌 경우 배치가 차단됩니다.

에서 발견되었습니다.

취약점이 발견된 경우의 빌드 파이프라인 흐름과 그에 따른 사용자 조치는 다음 다이어그램에 설명되어 있습니다.

유스 케이스 2: 프로덕션에도 있는 빌드에서 발견된 취약성

새 빌드에는 현재 배치된 프로덕션에도 있는 취약성이 포함되어 있습니다. 팀에는 문제를 수정하기 위한 타임라인이 있지만 새 기능 또는 수정사항은 여전히 배치될 수 있습니다.

CC 파이프라인은 타임라인을 설정하여 프로덕션에서 발견된 이러한 취약성을 수정합니다. 취약성을 수정하기 위한 타임라인이 만료된 경우에만 실패합니다. 흐름은 다음 다이어그램에 요약되어 있습니다.

유스 케이스 2A: 프로덕션에서 발견된 취약성이 PR을 허용함

프로덕션에서의 취약성은 PR이 병합되는 것을 방해하지 않습니다.

사용 사례 3: 오탐 및 예외 처리

팀이 특정 이슈를 오탐으로 분류하거나 취약점에 대해 보안 예외 처리를 받은 경우, 해당 이슈에 ‘면제’ 라벨을 지정할 수 있습니다. 그런 다음 문제를 비차단 문제로 처리할 수 있습니다. 감사 추적을 유지보수하기 위해 변경 요청은 문제를 계속 표시합니다.

유스 케이스 4: 자동으로 수정된 문제 닫기

CC 파이프라인을 주기적으로 실행하면 열려 있고 만기 날짜가 설정된 문제를 닫을 수 있습니다. 또한 스캔에서 관련 취약성을 찾을 수 없습니다.

다음 다이어그램은 닫을 문제와 새로 작성할 문제를 발견하는 CC 파이프라인의 플로우차트를 설명합니다.

인시던트 이슈의 마감일 관리

운영 환경에서 인시던트 문제가 발견되면, 해당 문제를 해결해야 하는 유예 기간을 지정하기 위해 ‘ Due Date ’ 속성이 자동으로 추가됩니다. 유예 기간의 지속 기간은 발견된 취약성의 심각도에 의해 판별됩니다.

일반적인 만기일 사례

다음 시나리오에서는 마감일이 어떻게 관리되는지 설명합니다:

초기 마감일 할당: CC 파이프라인이 프로덕션 환경에서 이슈를 감지하면, 해당 이슈의 심각도에 따라 마감일을 자동으로 계산하여 설정합니다.
마감일 연장: 문제 해결에 더 많은 시간이 필요한 경우, 보안 담당자의 승인을 받은 후 마감일을 연장할 수 있습니다. 자세한 내용은 ‘납기일 연기’를 참조하십시오.
기한이 지난 이슈: 이슈의 기한이 지났더라도, 새로운 빌드가 운영 환경의 상태를 악화시키지 않는 한 CI 파이프라인은 배포를 계속 진행할 수 있습니다(순수한 위험 관리 접근 방식). 이를 통해 팀은 보안 문제를 해결하는 동시에 기능 제공을 계속할 수 있습니다.

유예 기간 사용자 정의에 대한 자세한 정보는 CC 파이프라인에서 사용자 정의 유예 기간 구성 을 참조하십시오.

인시던트 문제 레이블 지정

연속 통합 (CI) 또는 연속 준수 (CC) 파이프라인에 의해 작성되는 인시던트 문제에는 기본 레이블이 있을 수 있습니다.

코드 위험 분석기가 발견한 인시던트 문제의 레이블

CRA (Code Risk Analyzer) 는 앱 종속성 및 이미지 취약성과 같은 여러 유형의 취약성을 발견합니다.

취약성 유형은 name os, python, js, golang 또는 java 일 수 있습니다.

취약성 유형이 os 유형인 경우 os-vulnerability 레이블이 문제에 첨부됩니다. 다른 유형의 취약성의 경우 app-vulnerability 레이블이 문제에 첨부됩니다.

사용 가능한 수정사항이 있는 인시던트 문제의 레이블

연속 통합 (CI) 파이프라인 또는 연속 준수 (CC) 파이프라인에 의해 작성되는 인시던트 문제의 경우 스캐너에 스캔 결과의 일부로 교정 정보가 있을 수 있습니다. 조치방안 정보를 사용할 수 있는 경우 fix-available 레이블이 문제 설명 내의 수정사항 설명에 대한 링크와 함께 인시던트 문제에 추가됩니다.

fix-available 레이블이 없다고 해서 모든 스캐너가 스캔 결과에 수정사항 정보를 포함하는 것은 아니므로 문제가 조치 가능하지 않음을 의미하지는 않습니다. 스캐너는 수정사항 정보를 제안하며 해당 정보는 스캐너가 이 "수정사항" 데이터를 소스로 하는 모든 위치에서 제공됩니다. 일부 스캐너에는 최신 "수정사항" 사전이 없거나 수정사항에 대한 정보가 포함되어 있지 않을 수 있습니다.

만료 날짜가 있는 인시던트 문제

collect-증거 스크립트를 사용할 때 인시던트 문제가 작성되고 수집된 증거에 첨부됩니다. 프로덕션에서 문제가 발견되면 배치가 차단되지 않도록 수정해야 하는 지정된 기간이 있을 수 있습니다. 프로덕션에서 문제점을 수정하기 위해 제공되는 시간 프레임을 _유예 기간 (grace period)_이라고 합니다. 그러나 가독성을 높이기 위해 만기 날짜 를 이제 인시던트 문제에서 사용할 수 있으므로 사용자는 유예 기간 (grace period) 에서 계산하지 않고 수정사항이 만기되는 날짜를 알 수 있습니다.

취약성 또는 CVE와 같은 문제가 프로덕션에서 발견되고 동일한 문제가 빌드에서도 발견되는 경우 빌드는 상황을 더 악화시키지 않습니다. 기능을 배치할 수 있으며 팀은 프로덕션에서 문제를 수정하는 데 집중할 수 있습니다.

CC 파이프라인에서 사용자 정의 유예 기간 구성

연속 준수 (CC) 파이프라인은 문제의 심각도에 따라 인시던트 문제의 만료 날짜를 계산합니다. 기본 유예 기간 값을 변경하고 이를 사용자 정의 값으로 바꿀 수 있습니다.

파이프라인은 다음 테이블에 따라 유예 기간을 계산합니다.

기본 유예 기간
심각도(Severity)	유예 기간
정보용	180일
낮음	180일
중간	90일
높음	30일
위험	30일

기본 구성을 변경하려면 CC 파이프라인의 환경 특성 grace-period-configuration 에서 새 특성을 작성하십시오. 이 환경 특성은 JSON 문자열이어야 하며 다음 형식과 일치해야 합니다.

{
  "informational": 50,
  "low": 40,
  "medium": 30,
  "high": 20,
  "critical": 10
}

환경 특성이 예상 형식과 일치하지 않거나 올바른 JSON 문자열이 아닌 경우 파이프라인은 기본값을 사용합니다.

grace-period-configuration 환경 특성은 만기 날짜가 아직 설정되지 않은 문제의 만기 날짜를 설정합니다. 만기 날짜가 설정된 문제의 경우 grace-period-configuration 를 다시 구성해도 해당 만기 날짜가 업데이트되지 않습니다.

만기 날짜 계산

찾은 날짜는 지속적 준수 (CC) 파이프라인이 실행되고 프로덕션 환경에서 문제를 찾는 시점입니다. 문제가 있는 경우 CC는 해당 시점부터 계산된 만기 날짜 로 업데이트합니다.

<due date> = <date of finding the issue in prod> + <grace period in days (determined by severity)>

만기 날짜 형식

만기 날짜는 ISO 8601 형식이며 YYYY-MM-DD 로 표시됩니다.

예: Due Date: 2022-04-01

유스 케이스

CC 파이프라인에 의한 프로덕션의 기본 이미지 중 하나에서 취약성이 발견되었습니다. 팀은 취약성의 심각도에 따라 설정된 유예 기간이 있는 인시던트 문제에 대해 알림을 받습니다. 유예 기간은 팀이 수정사항을 배치해야 하는 일 수입니다.
팀은 새 기능을 사용하여 새 릴리스를 빌드합니다. 빌드는 애플리케이션에 사용되는 기본 이미지와 연관된 CVE를 찾습니다. 팀은 이미 프로덕션에 있는 아티팩트를 스캔하는 CC 파이프라인을 수동으로 실행합니다. 수동 CC 실행은 프로덕션의 동일한 애플리케이션에서 동일한 CVE를 발견하고 인시던트 문제에 유예 기간을 추가합니다. 이제 팀은 차단되지 않고 빌드 및 배치할 수 있습니다.

CI및 CC 파이프라인의 문제 처리 간 차이

인시던트 문제는 CI및 CC 파이프라인 모두에서 작성됩니다.

CI 에서 작성된 문제는 빌드 중에 발견되었음을 의미합니다.
CC 에서 작성된 문제는 프로덕션 환경에서 발견되었음을 의미합니다.

만료 날짜는 프로덕션 환경에서 발견된 문제와 관련된 경우에만 문제에 자동으로 추가될 수 있습니다. 이는 CC 파이프라인만 문제에 만료 날짜를 추가할 수 있음을 의미합니다. CI가 문제를 찾고 만기 날짜를 사용할 수 없는 경우 만기 날짜의 값은 n/a 입니다.

문제로 결과 처리

발견된 문제점에 대한 문제는 특정 도구의 결과에 따라 작성됩니다. collect-evidence 스크립트는 첨부 파일의 결과 파일을 처리하고 문제 목록을 작성하려고 시도합니다.

문제는 저장소 또는 요약이 있는 Docker 이미지에서 커미트될 수 있는 자산에 바인드됩니다.

모든 문제 ID에 대해 문제가 작성됩니다. 문제 ID는 다음 구성요소로 구성됩니다.

바인드된 자산
취약성을 발견한 도구
취약성 ID (예: CVE ID)

예를 들어, CVE-2022-001 가 두 개의 개별 도구에 의해 발견되는 경우 프로세스는 오늘 두 개의 문제를 작성합니다.

지원되는 도구

인시던트 문제 처리 기능은 ‘ DevSecOps ’ 파이프라인에 통합된 다양한 스캔 도구의 결과를 지원합니다. 현재 지원되는 스캔 도구 목록 및 해당 기능에 대해서는 ‘지원되는 스캔 도구’를 참조하십시오.

지원되지 않는 도구 또는 결과 형식

collect-evidence 스크립트가 지원되지 않는 도구에서 첨부 파일을 수신하거나 처리 중에 결과 파일 형식이 인식되지 않는 경우 스크립트는 문제 작성을 건너뛰고 결과 파일을 증거에 대한 단순 첨부로 사용합니다.

문제 컨텐츠

문제 는 문제 또는 취약성의 이름입니다.
만기 날짜 는 수정사항이 만기되는 날짜 또는 사용 가능한 만기 날짜가 없는 경우 해당사항 없음 을 표시합니다.
주제 는 문제가 바인드되는 자산입니다.
URL 는 에셋의 정확한 버전에 대한 링크입니다.
도구 유형 은 문제에 대한 컨텐츠를 생성한 도구입니다.

Git Repos and Issue Tracking 에서 만든 이슈의 경우 마감일은 이슈 설명 대신 GitLab 기본 마감일 필드에 설정됩니다.

문제 설명에는 문제가 처음 발견된 시간소인이 포함되어 있습니다. 예를 들어, First found on 2022-04-07. 입니다. 날짜는 YYYY-MM-DD 형식입니다. 문제가 발생하는 위치는 문제의 주석에 나열되어 있습니다.

사고 이슈의 마감일 연장

수정 사항을 적용하는 데 추가 시간이 필요한 경우, 인시던트 이슈의 마감일을 연장할 수 있습니다. 이를 위해서는 보안 취약점에 대한 적절한 감독을 보장하기 위해 보안 담당자의 승인이 필요합니다.

기한 연장 절차

보안 담당자에게 해당 기간 연장이 필요한 이유를 설명하는 검토 요청을 제출하십시오.
승인을 받은 후, 마감일을 업데이트하십시오:
- Git Repos and Issue Tracking 의 경우: 인시던트 이슈의 메타데이터 필드 중 ‘ Due date ’ 필드를 수정하십시오.
- GitHub Enterprise 의 경우: 이슈 설명에서 ‘ Due date ’ 필드를 수정하세요.
검토 또는 승인 문서에 대한 링크가 포함된 댓글을 추가하여, 해당 이슈에 대한 보안 담당자의 승인을 참조하십시오.

Git Repos and Issue Tracking 에서 마감일을 설정하고 업데이트합니다.

주석에 링크를 제공하는 것과 같이 문제의 보안 초점 검토를 참조해야 합니다.

보안 예외

보안 예외와 관련된 문제가 있는 경우, 해당 예외의 만료일에 맞춰 마감일을 연장할 수 있습니다. 이를 통해 예외 사항이 만료될 때까지 증거 수집 및 규정 준수 추적이 적절하게 지속되도록 보장합니다.

CC 파이프라인의 보류 중인 문제 및 기한이 지난 문제에 대한 슬랙 경보

연속 준수 (CC) 파이프라인은 인시던트 문제의 만료 날짜를 설정할 수 있습니다. 또한 파이프라인은 Slack 통합이 사용으로 설정된 경우 Slack을 사용하여 만료 날짜 및 기한이 지난 만료 날짜에 근접한 문제에 대해 사용자에게 알릴 수 있습니다.

자세한 정보는 CI(Continuous Integration)도구 체인 설정 을 참조하십시오. 만기 날짜에 대한 자세한 정보는 [만기 날짜가 있는 인시던트 문제](/docs/devse경찰? topic = devse경찰-incident-issues#devsecops-devse경찰-issues-due-date) 를 참조하십시오.

알림을 받는 문제는 다음과 같이 분류됩니다.

특정 시간 범위 내에 보류 중인 만기 날짜가 있는 문제: 열려 있고 만기 날짜가 있으며 시간 범위 내에 만기되는 문제입니다.
만기 날짜가 지난 문제: 시작된 문제, 만기 날짜가 있는 문제, 날짜가 경과된 문제입니다.

시간 범위 지속 기간은 overdue, due in 1 day, due in 2 days, due in 5 days 및 due in 10 days 입니다.

이 기능의 예는 다음과 같습니다.

Overdue issues:
- <issue url#1>
- <issue url#2>
- <issue url#3>
Issues due in 1 day:
- <issue url#4>
Issues due in 2 days:
- <issue url#5>
Issues due in 5 days:
- <issue url#6>
- <issue url#7>
Issues due in 10 days
- <issue url#8>
- <issue url#9>
- <issue url#10>
- <issue url#11>
- <issue url#12>

집계된 목록은 기한이 지난 문제가 먼저 나열되고 만기 날짜가 가장 가까운 문제가 만기 날짜가 더 늦은 문제보다 먼저 나열됩니다.

CC 파이프라인의 cc-finish 단계에서는 기준에 따라 문제를 조회하고 Slack 경보를 트리거합니다.