제품 팀을 위한 취약점 관리 라이프사이클 가이드

취약점 관리 라이프사이클이란 무엇입니까?

취약점 관리 라이프사이클은 제품 공급업체가 출시한 소프트웨어의 취약점을 처리하기 위해 따르는 반복 가능한 프로세스입니다. 취약점을 접수하거나 발견하고, 검증하고, 영향 범위를 파악하고, 수정하고, 수정 사항을 릴리스하고, 고객에게 알립니다. 공급업체 조직에서는 보통 제품 보안 사고 대응팀(PSIRT)이 이를 운영하고, 엔지니어링 팀이 수정을 담당합니다.

이 페이지는 공급업체 관점을 다룹니다. 조직이 운영하는 서버와 노트북을 스캔하고 패치하는 IT 취약점 관리는 용어는 같지만 어려운 부분은 다릅니다. 공급업체는 고객이 사용하는 모든 지원 릴리스에 대해 답해야 하고, 발견한 내용을 공개해야 합니다.

라이프사이클의 단계

접수 또는 발견. 취약점은 공개 프로그램을 통한 외부 연구자, 고객, 국가 CSIRT 같은 조정 기관, 그리고 자체 모니터링에서 들어옵니다. 자체 모니터링에는 오픈 소스 종속성의 새 CVE, 스캐너 발견 사항, 내부 테스트가 포함됩니다. 각 건을 추적 ID와 함께 기록하고 외부 보고자에게 접수를 확인해 줍니다.
검증 및 분류. 문제를 재현하거나 종속성 일치를 확인하고, 제품의 취약점인지 판단한 뒤 심각도와 긴급도를 평가합니다. 해당하지 않는 건은 나중에 제시할 수 있는 사유와 함께 종료합니다. EPSS와 CISA KEV 카탈로그 같은 우선순위 신호가 남은 건의 순위를 정하는 데 도움이 됩니다.
영향받는 제품과 버전 평가. 취약한 코드나 구성 요소를 포함하는 모든 제품, 릴리스, 지원 브랜치와 이를 실행하는 모든 고객 배포를 찾습니다. 이 단계가 수정과 권고문의 범위를 결정합니다.
해결. 담당 팀이 수정을 개발하고 테스트합니다. 종속성 업그레이드, 코드 변경, 또는 아직 수정이 불가능할 때는 구성 변경 같은 완화 조치가 해당합니다.
수정 릴리스. 영향받는 각 지원 브랜치에 대해 업데이트된 버전을 고객이 신뢰할 수 있는 채널로 출시합니다.
권고 및 공개. 영향 범위, 심각도, 조치 방법을 담은 권고문을 공개하고, CVE ID를 할당하거나 참조하며, 보고자의 공로를 밝힙니다. CSAF와 VEX 같은 기계 판독 형식을 사용하면 고객이 권고문을 자동으로 처리할 수 있습니다.
모니터링 및 학습. 악용 여부와 새로운 정보를 주시하고, 권고문을 업데이트하며, 같은 유형의 결함이 다시 출시되지 않도록 근본 원인을 개발에 반영합니다.

ISO/IEC 30111과 ISO/IEC 29147

두 국제 표준이 공급업체를 위한 이 라이프사이클을 설명합니다. 두 표준은 조직의 경계를 기준으로 역할을 나눕니다.

	ISO/IEC 30111:2019	ISO/IEC 29147:2018
제목	Vulnerability handling processes(취약점 처리 프로세스)	Vulnerability disclosure(취약점 공개)
범위	내부에서 일어나는 일: 검증, 조사, 우선순위 지정, 해결	외부 접점: 보고 접수와 권고문 공개
핵심 내용	정책과 조직, PSIRT의 책임, 처리 단계, 공급망 고려 사항	이해관계자 역할, 보고 처리, 권고문 내용, 조정, 공개 정책
대상	보고된 취약점을 처리하는 공급업체	보고를 접수하고 취약점을 공개하는 공급업체

두 표준은 함께 사용하도록 설계되었습니다. ISO/IEC 30111은 준비, 접수, 검증, 해결책 개발, 릴리스, 릴리스 후의 6개 처리 단계를 정의합니다. 또한 프로세스 모니터링, 취약점 정보의 기밀 유지, 그리고 공급망에 대한 주의를 요구합니다. 많은 취약점이 직접 작성하지 않은 구성 요소에 있기 때문입니다. 두 표준 모두 마지막 ISO 검토에서 확인된 현행판이며, 개정 대상으로 지정되어 있습니다.

다른 프레임워크도 같은 구조를 따릅니다. FIRST PSIRT Services Framework는 업무를 취약점 발견, 분류 및 분석, 해결, 공개로 묶으며, IEC 62443-4-1은 산업용 제품의 보안 개발 라이프사이클에 보안 업데이트 및 결함 관리를 포함합니다.

역할

PSIRT 또는 제품 보안팀: 프로세스를 책임지고, 보고를 접수하고, 분류하고, 수정을 조정하고, 권고문을 공개합니다. PSIRT 팀을 위한 CRACI와 PSIRT가 CSIRT와 어떻게 다른지 참조하세요.
제품 및 엔지니어링 팀: 코드를 책임지고, 수정을 개발하고 테스트하며, 릴리스를 출시합니다.
릴리스 관리: 어떤 지원 브랜치에 언제 수정을 적용할지 결정합니다.
고객 지원 및 커뮤니케이션: 고객 문의와 권고문 수신자를 담당합니다.
법무: 공개, 계약, 규제 통지에 대해 조언합니다.
외부 당사자: 보고자, CERT/CC나 국가 CSIRT 같은 조정 기관, 영향받는 구성 요소의 업스트림 메인테이너, 그리고 수정을 배포해야 하는 고객.

일정과 SLA

정해진 단일 일정은 없습니다. 대부분의 공급업체는 심각도별로 내부 목표를 정하고, 외부 목표는 공개 정책에 게시합니다. 일반적인 구조는 다음과 같습니다.

접수 확인: 외부 보고는 영업일 기준 며칠 이내에 확인합니다.
분류: 며칠 이내에 진행해 보고자와 담당 팀이 현황을 알 수 있게 합니다.
해결: 심각도와 악용 여부에 따라 기한을 정하며, 치명적인 발견 사항과 악용이 확인된 건은 가장 짧은 기한을 적용합니다.
공개: 수정이 제공될 때, 또는 수정이 늦어지면 합의된 기한에 공개합니다.

외부 압력이 최대 한도를 정합니다. 연구자는 흔히 공개 기한을 정하며(Google Project Zero는 공급업체에 90일을 줍니다), 규제도 자체 기한을 추가하고 있습니다. EU Cyber Resilience Act는 제조업체가 취약점을 "without delay"(지체 없이) 해결하도록 요구하고, 실제로 악용되는 취약점에 대한 보고 기한을 정합니다(CRA의 요구 사항 참조). 제로데이처럼 취약점이 이미 악용되고 있다면 모든 단계가 가장 짧은 기한으로 진행됩니다.

라이프사이클이 무너지는 지점

대부분의 지연은 수정을 작성하는 데서 생기지 않습니다. 무엇을 출시했는지 모르는 데서 생깁니다.

어떤 릴리스에 구성 요소가 들어 있는지 모름. 라이브러리에 새 CVE가 등장합니다. 작년 릴리스 중 어떤 것이 이를 포함하고, 어떤 고객이 그 릴리스를 사용합니까? 릴리스별 기록이 없으면 팀은 오래된 태그를 다시 빌드하거나 저장소를 수작업으로 검색하며, 권고문의 영향받는 버전 목록은 추측이 됩니다.
전이적 종속성. 취약한 패키지 중 상당수는 직접 선택한 것이 아닙니다. 여러 계층 아래의 전이적 종속성으로 들어오므로, 매니페스트를 검색해서는 찾을 수 없습니다.
개발 종속성 노이즈. 잠금 파일을 읽는 스캐너는 출시되지 않는 테스트 프레임워크와 빌드 도구까지 보고합니다. 각각이 분류 시간을 잡아먹고 중요한 발견 사항을 묻어 버립니다.
패키지 관리자 밖의 구성 요소. 빌드 스크립트가 내려받는 바이너리, 베이스 이미지, 공급업체 구성 요소는 잠금 파일에 아예 나타나지 않습니다.
불분명한 소유권. 담당 팀이 없는 발견 사항은 방치됩니다. 분류는 수정의 담당자가 정해져야 끝납니다.
유지되지 않는 수정. 다음 빌드에 들어가는 것을 막는 장치가 없어서, 취약한 버전이 다른 종속성이나 오래된 브랜치를 통해 다시 들어옵니다.

이 단절은 소규모 팀에서 가장 먼저 나타납니다. 모든 CVE마다 하나하나가 반복되기 때문입니다. 취약점 관리 자동화는 무엇을 어떤 순서로 자동화할지 설명하고, 취약점 노이즈를 줄이는 방법은 중요한 발견 사항을 묻어 버리는 개발 종속성, 중복, 담당자 없는 발견 사항을 다룹니다.

지표

지표	보여 주는 것
접수 확인 소요 시간	정책에 명시한 기한 내에 보고자가 회신을 받는지 여부
분류 소요 시간	발견 사항이 중요한지 누군가 알게 되기까지 대기하는 시간
심각도별 해결 소요 시간	접수부터 릴리스 제공까지 측정한 수정 출시 속도
권고문 소요 시간	수정 후 고객이 정보를 받기까지 기다리는 시간
목표 준수 비율	내부 SLA가 지켜지는지 여부, 특히 치명적이거나 악용된 발견 사항의 경우
경과 기간별 백로그	정체된 발견 사항과 그 위치
영향 없음 비율	해당하지 않는 발견 사항에 들어가는 분류 노력의 양

각 단계를 따로 측정하세요. 해결 소요 시간이 길다면, 실제로는 영향받는 릴리스를 찾는 데 오래 걸리는 경우가 많습니다.

출시한 것의 기록을 바탕으로 라이프사이클 운영하기

분류 이후의 모든 단계는 각 릴리스에 무엇이 들어 있는지 아는 데 달려 있습니다. CRACI는 GitHub Actions 빌드를 CRACI가 운영하는 러너에서 실행하고, 각 작업이 실제로 가져온 패키지를 기록합니다. 여기에는 전이적 종속성, CI 캐시에서 복원된 패키지, 어떤 잠금 파일에도 나오지 않는 종속성이 포함됩니다. 각 SBOM에는 완전성 상태가 표시되며, CycloneDX 또는 SPDX로 내보낼 수 있습니다.

CRACI는 모니터링 대상 SBOM을 지속적으로 재평가하고 빌드와 저장소 전반에 걸쳐 집계하며, 공급업체 SBOM을 추가해 외부에서 구매한 구성 요소도 자체 구성 요소와 함께 모니터링할 수 있습니다. 새 CVE가 등장하면 빌드 기록을 통해 과거 어떤 빌드에 직접 또는 전이적으로 취약한 종속성이 포함되었는지 확인할 수 있으므로 영향을 받은 기간을 알 수 있고, 인벤토리 뷰는 어떤 소프트웨어 버전이 어떤 제품에 배포되어 있는지 보여 줍니다. 보안 팀은 CRACI에서 발견 사항을 분류해 수정을 담당하는 팀에 전달하며, CRACI는 VEX를 지원하고, 정책 게이트는 특정 CVE를 포함하는 빌드를 차단해 수정된 취약점이 다시 들어오지 않도록 합니다. 취약점 추적을 참조하세요.

취약점 관리 라이프사이클: 자주 묻는 질문

취약점 관리 라이프사이클의 단계는 무엇입니까?

제품 공급업체의 경우, 취약점을 접수하거나 발견하고, 검증 및 분류하고, 영향받는 제품과 버전을 찾고, 해결책을 개발하고, 수정을 릴리스하고, 권고문을 공개한 뒤, 모니터링하고 학습합니다. ISO/IEC 30111은 단계를 준비, 접수, 검증, 해결책 개발, 릴리스, 릴리스 후로 정의합니다.

ISO/IEC 30111이란 무엇입니까?

ISO/IEC 30111:2019는 취약점 처리 프로세스에 관한 국제 표준입니다. 정책과 PSIRT의 역할부터 처리 단계와 공급망 고려 사항까지, 공급업체가 자사 제품과 서비스에서 보고된 취약점을 처리하고 해결하기 위한 요구 사항과 권장 사항을 제공합니다.

ISO/IEC 30111과 ISO/IEC 29147의 차이는 무엇입니까?

ISO/IEC 29147은 외부와 맞닿는 부분, 즉 보고 접수와 권고문 공개를 다룹니다. ISO/IEC 30111은 그 사이의 내부 처리, 즉 검증, 조사, 우선순위 지정, 수정을 다룹니다. 두 표준은 함께 사용하도록 만들어졌습니다. 29147 측면은 조정된 취약점 공개를 참조하세요.

취약점 분류란 무엇입니까?

분류는 보안 팀이 보고되거나 발견된 취약점이 실제인지 확인하고, 제품에 대한 심각도와 긴급도를 판단하고, 수정을 담당하는 팀에 전달하는 단계입니다. 좋은 분류는 해당하지 않는 발견 사항을 기록된 사유와 함께 종료하는 것까지 포함합니다.

제품 취약점 관리는 IT 취약점 관리와 어떻게 다릅니까?

IT 취약점 관리는 조직이 운영하는 시스템을 패치합니다. 제품 취약점 관리는 조직이 빌드해 다른 이에게 출시하는 소프트웨어의 결함을 처리하므로, IT 팀에는 없는 단계가 추가됩니다. 어떤 출시 버전이 영향을 받는지 파악하고, 고객에게 수정을 제공하고, 권고문으로 이를 알리는 단계입니다.

취약점 처리 프로세스는 어떤 지표를 추적해야 합니까?

심각도별 보고 접수 확인 소요 시간, 분류 소요 시간, 해결 소요 시간, 권고문 소요 시간과 함께, 내부 목표를 충족한 발견 사항의 비율, 경과 기간별 미결 백로그, 영향 없음으로 종료된 발견 사항의 수를 추적해야 합니다.

소프트웨어 공급업체를 위한 취약점 관리 라이프사이클