늘어나는 문의량은 인력 충원으로 해결되지 않으며, 분류 속도를 끝없이 높일 수도 없습니다. PSIRT는 대부분의 "영향을 받았는가?" 질문에 각 버전을 빌드할 때 기록해 둔 데이터로 답하고, 고객이 묻기 전에 답을 게시함으로써 확장됩니다. 오늘날 비용이 가장 많이 드는 단계는 제품에 무엇이 들어 있는지 엔지니어링에 묻는 일입니다. 그 단계를 빌드 시점으로 옮기면, 대부분의 문의는 지원팀이 조회만으로 종결할 수 있는 일이 됩니다.
이 글은 이미 PSIRT를 운영하고 있다고 가정합니다. 새로 구축하는 중이라면 PSIRT란 무엇이며 어떻게 구축하는가부터 읽어 보세요. 아래에서는 문의량이 왜 바뀌었는지, 일반적인 파이프라인에서 시간이 어디에 쓰이는지, 그리고 무엇을 어떤 순서로 바꿔야 하는지 설명합니다.
문의량이 바뀐 이유
이 증가는 한 분기의 일시적 현상이 아니라 구조적인 변화입니다. 네 가지 요인이 동시에 같은 대기열을 압박하고 있습니다.
CVE가 늘었습니다. CVE Program은 2024년에 39,718건, 2025년에 47,801건의 CVE 레코드를 게시했습니다. 2026년에는 연말이 되기 훨씬 전에 2025년 연간 총계를 넘어섰으며, 실시간 CVE 게시 추이에서 이를 매일 추적하고 있습니다. FIRST의 2026년 취약점 예측 업데이트(2026년 6월 15일)는 올해 예상치를 약 66,000건으로 올리고 원인을 분명히 밝혔습니다. AI는 인간 분석가보다 훨씬 많은 결함을 찾아낼 수 있으며, "제약은 더 이상 발견이 아니라 검증하고, 조정하고, 패치하는 인간의 역량"이라는 것입니다. PSIRT가 바로 그 인간의 역량입니다.
고객이 귀사 제품을 스캔합니다. 고객은 귀사의 이미지, 펌웨어, 어플라이언스에 스캐너를 돌리고, 모든 결과를 티켓으로 전달합니다. 그 결과의 대부분은 출시하지 않은 구성 요소나 영향받지 않는 버전에 관한 스캐너 노이즈이며, 그 노이즈가 그대로 귀사의 접수 대상이 됩니다. 스캐너 측면은 취약점 노이즈 줄이기에서 다룹니다.
규제가 기한을 더합니다. 2026년 9월 11일부터 EU Cyber Resilience Act의 보고 의무가 적용됩니다. EU에서 판매되는 제품에서 실제로 악용되고 있는 취약점은 제조사가 이를 인지한 후 24시간 안에 조기 경보를 보내야 합니다.
NVD의 도움이 줄었습니다. 2026년 4월 15일 NIST는 National Vulnerability Database를 위험 기반 보강 방식으로 전환했습니다. CISA KEV 카탈로그에 있는 CVE, 연방 정부가 사용하는 소프트웨어, EO 14028 핵심 소프트웨어가 우선이며, 나머지는 "Lowest Priority - not scheduled for immediate enrichment"(최하위 우선순위, 즉시 보강 예정 없음)로 표시됩니다. CPE 데이터가 붙어 오는 CVE가 줄어들기 때문에, 문의량이 늘어나는 바로 그때 제품 이름으로 대조하는 방식은 더 부정확해집니다.
| 요인 | PSIRT 대기열에 미치는 영향 |
|---|---|
| CVE 증가, AI 활용 발견 | 매달 제품별로 평가해야 할 서드파티 CVE 증가 |
| 고객의 스캔 | CVE당 문의 증가, 상당수는 출시하지 않은 구성 요소에 관한 것 |
| CRA 보고 | 실제로 악용되고 있는 취약점에 대한 24시간 기한 |
| NVD 보강 감소 | CVE를 영향받는 제품에 연결하는 수작업 증가 |
시간이 쓰이는 곳: 일반적인 문의 파이프라인
제품 보안팀에서 같은 파이프라인 이야기를 거듭 듣습니다. 한 하드웨어 벤더의 2인 PSIRT는 이렇게 설명했습니다. 고객이 지원 데스크에 문의하면, 지원팀이 CRM을 통해 PSIRT로 질문을 넘기고, 케이스가 PSIRT의 트래커에 들어오고, PSIRT는 고객이 가장 많이 묻는 제품부터 조사한 뒤, 질문을 엔지니어링에 넘기고 기다립니다.
예시 문의를 하나 들어 보겠습니다. 고객이 펌웨어 버전 X에 대해 40개의 CVE를 나열한 스캐너 보고서를 전달합니다. 지원팀은 케이스를 열고 보고서를 첨부하지만, 고객이 실행하는 정확한 빌드는 첨부하지 않습니다. PSIRT는 40개 중 이미 평가한 것을 확인하고, 평가하지 않은 열두 개를 찾아내, 담당 엔지니어링 팀에 해당 구성 요소가 버전 X에 들어 있는지 묻습니다. 엔지니어링은 버전 X의 소스를 찾고, 어떤 종속성 버전이 들어갔는지 파악한 뒤 답해야 합니다. 숫자는 지어낸 것이지만, 흐름은 실제와 같습니다.
시간이 걸리는 것은 분석 자체인 경우가 드뭅니다. 숨은 비용은 두 가지입니다.
- 묻는 고객마다 같은 CVE를 다시 조사합니다. 답이 이메일 스레드 안에만 있으면, 다음 고객이 물을 때 조사가 처음부터 다시 시작됩니다.
- "가장 많이 묻는 제품부터"는 롱테일을 답하지 않은 채로 남깁니다. 아직 현장에서 쓰이는 오래된 제품은 끝내 확인되지 않으며, 위험은 흔히 바로 그곳에 있습니다. 오래된 구성 요소, 드문 업데이트, 그리고 어떻게 빌드되었는지 기억하는 사람이 더 적기 때문입니다.
접수: 질문과 보고 분리하기
연구자의 취약점 보고와 고객의 "영향을 받았는가?"는 다른 일이며, 다른 경로가 필요합니다. FIRST PSIRT Services Framework는 이미 정돈되지 않은 입력을 전제로 합니다. PSIRT는 "다양한 채널을 통해 다양한 품질의 취약점을 받을 것으로 예상해야" 한다고 합니다(하위 기능 2.1.1.1). 분류(triage) 서비스 영역은 한 걸음 더 나아갑니다. "취약점 보고를 대량으로 받는 조직은 케이스를 생성하기 전에 보고를 검증하는 초기 분류를 수행하는 것을 고려할 수 있다." 이를 모든 문의마다 PSIRT 케이스를 열지 않아도 된다는 근거로 삼으세요.
지원 데스크에서 문의를 세 가지 경로로 나누세요.
| 고객이 묻는 대상 | 경로 | 답하는 사람 |
|---|---|---|
| 이미 평가한 서드파티 구성 요소의 게시된 CVE | 게시된 VEX 문서나 권고로 답변. PSIRT 케이스 없음 | 지원팀 |
| 아직 평가하지 않은 게시된 CVE | 고객별이 아니라 CVE별로 PSIRT 케이스 하나. 모든 문의를 그 케이스에 연결 | PSIRT, 이후 지원팀이 연결된 모든 고객에게 답변 |
| 자사 코드의 새 취약점 | 취약점 보고: 전체 조정된 취약점 공개 프로세스 | PSIRT |
지원팀이 첫 번째 경로를 처리하려면 두 가지가 필요합니다. 제품과 버전별로 평가를 마친 CVE를 검색할 수 있는 목록, 그리고 답변 템플릿입니다. 공급망 공격 후 고객에게 답하는 방법에 바로 고쳐 쓸 수 있는 템플릿이 있습니다.
접수 단계에서 제품과 고객이 실행하는 정확한 버전을 기록하세요. 버전이 없으면 모든 답이 "경우에 따라 다릅니다"가 되고, 케이스는 되돌아옵니다.
인기도만이 아니라 노출을 기준으로 우선순위 정하기
"가장 많이 묻는 제품부터"는 합리적인 경험칙입니다. 다만 두 번째 축이 필요합니다. 인기도(설치 기반, 매출, 지원팀이 묻는 빈도)는 유지하고 노출을 더하세요. 제품이 아직 지원 대상인가, 일반적인 배포 환경에서 인터넷에 노출되는가, 그리고 CVE가 CISA의 KEV 카탈로그에 있거나 EPSS 점수가 높은가? 신호에 대한 자세한 내용은 취약점 우선순위 지정 가이드에서 다룹니다.
| 낮은 노출 | 높은 노출 | |
|---|---|---|
| 넓은 설치 기반 | 인벤토리로 답변. 영향받지 않는 버전에 대해 VEX 게시 | 가장 먼저 조사. 가장 짧은 기한으로 권고와 수정 |
| 좁은 설치 기반 | 요청이 있으면 인벤토리로 답변. 선제적 작업 없음 | 건너뛰지 마세요. 인벤토리로 답한 뒤 수정 또는 완화 공지를 결정 |
이 매트릭스의 핵심은 왼쪽 열과 아래쪽 행입니다. 롱테일은 아무도 시간을 낼 수 없는 조사가 아니라 데이터로 답을 받습니다.
CRA에서는 각 제품에 대해 선언한 지원 기간이, 어떤 오래된 제품에 대해 아직 답변과 보안 업데이트를 제공할 의무가 있는지를 결정합니다(CRA가 요구하는 것).
엔지니어링 인계가 병목입니다
이 섹션은 PSIRT의 에스컬레이션을 받는 엔지니어링 리드를 위한 것입니다.
PSIRT의 기한은 외부에 드러나 있습니다. 고객, 규제 기관, 또는 공개일이 기다리고 있습니다. 엔지니어링의 기한은 대개 그렇지 않으므로, 그 차이를 PSIRT가 떠안습니다. 월요일에 넘긴 Critical 이슈에 화요일까지 답이 없으면, 공개 답변 기한까지 이틀밖에 남지 않습니다.
PSIRT는 엔지니어링에 두 가지 다른 질문을 보내는데, 엔지니어링이 필요한 것은 그중 하나뿐이어야 합니다.
- "구성 요소가 제품에 들어 있는가?" 질문은 데이터 질문입니다. 사람이 빌드 파일을 읽어서가 아니라 기록으로 답해야 합니다.
- "X일까지 수정할 수 있는가?" 질문은 작업 질문입니다. 이 질문은 엔지니어링의 몫입니다.
FIRST 프레임워크는 첫 번째 질문을 엔지니어링의 책상에서 덜어내는 방법을 제시합니다. 기능 2.3.5는 PSIRT에 "식별된 서드파티 취약점 알림을 영향받는 제품의 개발팀에 직접 배포하는 자동화된 채널을 구축"하도록 요구합니다. 그러면 서드파티 권고가 개발 프로세스 안에서 처리되고, PSIRT가 수작업으로 다루는 건수가 줄어듭니다.
엔지니어링과 세 가지를 합의하세요.
- 제품별 담당자. 대규모 벤더에서는 수정 작업이 여러 제품팀에 분산되어 있습니다. 프레임워크의 분산형 모델은 제품을 담당하는 엔지니어를 통해 PSIRT의 임무를 확장할 수 있게 하기 때문에 존재합니다.
- 심각도별 대응 목표. 조사가 아니라 수정에 대한 목표를 문서로 남기세요.
- 목표를 놓쳤을 때 일어나는 일. 기능 4.2.4는 "내부 SLA 기한 내에 수정되지 않은 모든 취약점에 대한 공식적인 위험 수용 프로세스"를 요구합니다. 권한 있는 사람이 위험에 서명해야 하며, 그냥 열린 채로 두어서는 안 됩니다.
수정 주기는 제각각입니다. 어떤 팀은 하룻밤 사이에 패치를 내고, 다른 팀은 6개월짜리 플랫폼 업그레이드가 필요합니다. 고객이 계획을 세울 수 있도록 권고에 어느 쪽인지 밝혀야 합니다.
"우리는 영향을 받았는가?"를 조회로 바꾸기: 출시한 모든 버전의 SBOM
이것이 가장 많은 작업을 없애는 변화입니다. FIRST 기능 2.3.1, 즉 제품 구성 요소 인벤토리는 이를 "상속된 취약점에 대해 영향받는 제품을 신속하게 식별하는 데 필수적"이라고 표현합니다. PSIRT 성숙도 수준은 종속성 매핑을 갖춘 제품 레지스트리를 중급 수준에, 제품 구성 요소 취약점 모니터링을 고급 수준에 둡니다.
인벤토리는 대량의 문의를 감당할 수 있을 때만 작업을 줄여 줍니다. 아래의 각 요건에는 이유가 있습니다.
- 출시한 버전마다 SBOM 하나. 리포지토리별도, 기본 브랜치의 SBOM도 아닙니다. 고객은 브랜치가 아니라 버전을 실행합니다.
- 릴리스를 만든 빌드에서 생성. 나중에 다시 빌드하거나 오늘의 리포지토리를 스캔하면 다른 소프트웨어를 기술하게 됩니다(빌드 시점 SBOM).
- 전이적 종속성과 숨은 종속성 포함. 취약한 패키지는 직접 추가한 것인 경우가 드물며(전이적 종속성), 설치 스크립트, 베이스 이미지, 복원된 캐시는 어떤 잠금 파일에도 나오지 않는 구성 요소를 들여옵니다.
- 완전성 신호. 부분적인 기록을 완전한 기록으로 취급하면, 자신 있게 내놓은 "영향 없음" 답변이 틀리게 됩니다.
- 버전이 지원되는 동안 보관. 3년 전 버전의 기록은, 그 버전이 어떻게 빌드되었는지 아무도 기억하지 못할 때 필요해지는 바로 그 기록입니다.
- 외부에서 들여온 구성 요소에 대한 벤더 SBOM. 서드파티 소프트웨어도 자사 소프트웨어와 같은 인벤토리에 들어갑니다.
- 지속적인 재대조. 누군가 물을 때 다시 스캔하는 대신, 새 CVE가 게시될 때마다 대조합니다.
예를 들어 보겠습니다. 널리 쓰이는 압축 라이브러리에서 새 CVE가 게시됩니다. 인벤토리가 없으면 PSIRT는 모든 제품팀에 묻고, 답은 며칠에 걸쳐 띄엄띄엄 들어오며, 가장 오래된 제품은 끝내 확인되지 않습니다. 인벤토리가 있으면 한 번의 조회로 영향받는 제품과 버전, 그리고 취약한 버전이 들어 있던 첫 빌드와 마지막 빌드가 나옵니다. 그것이 고객이 다음으로 묻는 노출 기간입니다. 단일 사례에서 이를 산정하는 방법은 우리는 영향을 받았는가?에서 볼 수 있습니다.
임베디드와 Yocto 포트폴리오가 가장 어렵습니다. 완성된 펌웨어 이미지를 읽는 스캐너는 그 안에 무엇이 컴파일되었는지 추측해야 하며, 저희가 대화한 팀들 중에는 Yocto 기반 제품에서 스캐너 개념 증명이 실패한 경우가 있습니다. 빌드가 실행되는 동안 기록하면 추측할 필요가 없습니다(CRACI의 Yocto 빌드).
이후 고객이 특정 형식의 SBOM 자체를 요청한다면 고객 SBOM 요청에 답하기를 참고하세요.
출력 측면: 누가 묻기 전에 답하는 권고와 VEX
가장 저렴한 문의는 아예 오지 않는 문의입니다.
- "영향 없음"은 VEX로 게시하세요. 그러면 고객의 스캐너가 해당 CVE를 더 이상 표시하지 않습니다. "영향 있음"과 "수정됨"은 정확한 버전을 명시한 권고로 게시하세요.
- 기계가 읽을 수 있게 만드세요. FIRST 하위 기능 5.3.2.3은 PSIRT에 "Common Security Advisory Framework(CSAF)와 같은 기계 판독 가능한 형식으로 권고를 게시하는 것을 고려"하라고 제안합니다. 그러면 고객이 자체 도구로 권고를 처리할 수 있습니다. 웹 페이지와 RSS 피드에서 CSAF로 옮겨 가는 방법은 CSAF 가이드에서 다룹니다.
- 게시하기 전에 지원팀에 미리 알리세요. 기능 5.3.4는 이렇게 말합니다. "다가올 권고에 대해 사전 기밀 통지와 FAQ를 제공하면, 게시 시점에 질문을 받을 수 있는 사람들이 대비할 수 있다." 그러면 지원팀이 당일에 답할 수 있습니다.
- 게시만 하지 말고 전달하세요. 하위 기능 5.4.1.3은 권고의 페이지 조회 수가 낮다면 "선제적 통지 쪽으로 전략을 바꾸는 계기가 될 수 있다"고 지적합니다. 피드와 알림은 권고 페이지를 한 번도 방문하지 않는 고객에게도 닿습니다.
CRA는 이 중 일부를 의무로 만듭니다. Article 14(8)는 제조사가 실제로 악용되고 있는 취약점이나 심각한 사고를 인지한 후 영향을 받는 사용자에게 "그리고 적절한 경우 모든 사용자에게" 알리도록 하며, 이를 "적절한 경우 쉽게 자동 처리할 수 있는 구조화된 기계 판독 가능한 형식으로" 하도록 요구합니다. 규정은 특정 형식을 지정하지 않습니다.
자동화 순서
각 단계는 한 종류의 작업을 없애며, 지표가 실제로 그랬는지를 보여 줍니다.
| 단계 | 없어지는 작업 | 효과를 보여 주는 지표 |
|---|---|---|
| 1. 빌드에서 만든 버전별 인벤토리 | 엔지니어링에 묻는 "무엇이 들어 있는가?" 질문 | 월별 엔지니어링 조사 요청 감소 |
| 2. 지원되는 모든 버전과 새 CVE의 지속적 대조 | 요청 시 재스캔 | CVE 게시부터 영향 있음/없음 결정까지의 시간 |
| 3. CVE당 케이스 하나, 문의는 연결 | 중복 조사 | 케이스당 문의 수 증가, CVE당 케이스는 하나로 유지 |
| 4. 영향받는 결과를 담당 팀에 자동 라우팅(FIRST 2.3.5) | 수작업 인계 | 결정부터 담당자가 확인하기까지의 시간 |
| 5. 게시된 VEX 문서와 권고의 검색 가능한 라이브러리 | 반복 질문에 대한 PSIRT 관여 | 지원팀이 종결한 문의 비율 |
| 6. 기계 판독 가능한 게시(CSAF) | 고객 도구가 가져올 수 있었던 정보에 대한 문의 | 게시된 권고당 문의 수 감소 |
| 7. 권고와 답변 작성을 위한 AI 지원 | 작성 시간 | 결정부터 권고 게시까지의 시간 |
AI가 마지막인 데는 이유가 있습니다. AI는 기록된 데이터 위에서 초안을 잘 작성하지만, "영향 있음" 결정의 출처가 되어서는 안 됩니다.
자동화해서는 안 되는 것도 있습니다. "영향 없음" 판단과 심각도 판정은 증거를 첨부한 채 사람이 맡습니다. 자동화가 결정하는 것은 그 사람이 얼마나 빨리 증거를 받느냐입니다.
PSIRT가 확장되고 있음을 보여 주는 지표
- PSIRT 케이스 없이 답한 문의의 비율.
- 제품별, CVE 게시부터 영향 있음/없음 결정까지의 시간.
- 월별 엔지니어링 조사 요청 수. 줄어들어야 합니다.
- 심각도별 기한 내 수정 비율. 프레임워크의 하위 기능 4.4.2.4는 이를 제품팀이 보고부터 수정까지 합의된 시간을 얼마나 잘 지키는지로 정의합니다.
- 아직 지원하는 버전에 대한 VEX와 권고의 적용 범위.
이 지표들에 대한 업계 벤치마크는 인용하지 않습니다. 저희가 신뢰하는 1차 출처 중 이를 게시하는 곳이 없기 때문입니다.
CRACI의 역할
CRACI는 GitHub Actions에서 빌드되는 소프트웨어에 대해 1단계와 2단계, 그리고 4단계와 5단계의 일부를 담당합니다. 빌드는 CRACI 러너에서 실행되며, CRACI는 각 작업이 실행되는 동안 실제로 가져온 것을 기록합니다. 직접 및 전이적 종속성, 스크립트가 설치한 패키지, CI 캐시에서 복원된 패키지입니다. 각 작업의 SBOM에는 완전성 상태가 붙어 있으므로, 부분적인 기록이 완전한 기록으로 오인되는 일이 없습니다.
CRACI는 빌드 기록을 보관하므로, 새 CVE가 게시되면 어떤 빌드에 취약한 종속성이 들어 있었는지, 그리고 언제부터였는지를 보존 기간이 허용하는 범위까지 확인할 수 있습니다. 모니터링되는 SBOM은 지속적으로 재평가되고, 결과는 빌드와 리포지토리 전반에 걸쳐 집계되며, 벤더 SBOM을 추가해 외부에서 들여온 구성 요소도 자사 빌드와 함께 모니터링할 수 있습니다. CRACI는 새 취약점과 그 심각도를 관련 담당자에게 알립니다. 인벤토리 보기는 어떤 소프트웨어 버전이 어떤 제품에 배포되었는지 보여주며, 보안 팀은 CRACI에서 각 결과를 분류해 수정 담당 팀에 배정합니다. CRACI는 VEX를 지원합니다. PSIRT를 위한 CRACI와 취약점 추적을 참고하세요.
출시한 버전 중 어느 것에 CVE가 들어 있는지 확인해 보세요.
CRACI가 답이 아닌 경우
- 병목이 접수와 케이스 관리, 즉 CRM에서 트래커로 이어지는 부분에 있는 경우. CRACI는 케이스 관리 도구도, 권고 게시 도구도 아닙니다. 그 절반에는 케이스 도구가 필요합니다(PSIRT 도구 비교).
- 제품이 Linux 러너의 GitHub Actions에서 빌드되지 않는 경우. 현재 지원되는 CI는 GitHub Actions이며, GitLab CI와 Jenkins는 로드맵에 있지만 일정은 정해지지 않았습니다.
- 직접 빌드하지 않은 제품의 바이너리나 펌웨어 분석이 필요한 경우. 그것은 출력물 분석 도구가 하는 일입니다(임베디드 보안 도구 비교).
- "영향 없음"을 주장하기 위해 도달 가능성 분석이 필요한 경우. CRACI는 이를 제공하지 않습니다.
자주 묻는 질문
인력을 충원하지 않고 PSIRT를 확장하려면 어떻게 해야 합니까?
같은 질문을 반복해서 조사하는 일을 멈추세요. 출시하는 모든 버전에 무엇이 들어 있는지 빌드 시점에 기록하고, 새 CVE를 지속적으로 대조하고, CVE당 한 번 결정하고, 그 결정을 지원팀이 안내할 수 있는 VEX나 권고로 게시하세요. 그러면 PSIRT는 정말로 열려 있는 케이스에 집중하고, 엔지니어링에는 조사가 아니라 수정만 요청하게 됩니다.
PSIRT는 고객의 "우리는 영향을 받았는가?" 문의를 어떻게 처리해야 합니까?
취약점 보고와는 별도의 접수 흐름으로 다루세요. 이미 평가한 CVE에 관한 질문은 지원팀이 게시된 자료로 답합니다. 아직 평가하지 않은 CVE에는 PSIRT 케이스를 하나 열고, 모든 고객 문의를 그 케이스에 연결합니다. 자사 코드의 새 취약점만 전체 공개 프로세스를 거칩니다.
FIRST PSIRT Services Framework는 문의량과 자동화에 대해 무엇이라고 합니까?
"다양한 채널을 통해 다양한 품질의" 보고를 예상하고, 문의량이 많으면 케이스를 생성하기 전에 분류하는 것을 허용하며, 제품 구성 요소 인벤토리를 "영향받는 제품을 신속하게 식별하는 데 필수적"이라고 부르고, 서드파티 취약점 알림을 영향받는 제품의 개발팀에 바로 보내는 자동화된 채널을 요구합니다(기능 2.3.5).
PSIRT는 무엇부터 자동화해야 합니까?
빌드에서 만든 버전별 인벤토리, 그다음 지원되는 모든 버전과 새 CVE의 지속적 대조입니다. 이 두 가지가 가장 많은 반복 작업, 즉 엔지니어링에 묻는 "무엇이 들어 있는가?" 질문과 요청 시 재스캔을 없앱니다. 케이스 중복 제거, 라우팅, 검색 가능한 VEX 및 권고 라이브러리, CSAF 게시는 그 뒤에 옵니다.
엔지니어링이 PSIRT의 질문에 제때 답하게 하려면 어떻게 해야 합니까?
엔지니어링에 질문을 덜 하세요. "구성 요소가 제품에 들어 있는가?"는 빌드 기록으로 답하고, 엔지니어링에는 "이 날짜까지 수정할 수 있는가?"만 보내세요. 제품별 담당자, 수정에 대한 심각도별 대응 목표, 그리고 목표를 놓쳤을 때의 공식적인 위험 수용을 합의하세요.
릴리스별 SBOM이 PSIRT에 왜 중요합니까?
고객은 특정 버전, 그것도 흔히 오래된 버전을 실행합니다. 기본 브랜치의 SBOM은 2년 전 버전 X에 대해 아무것도 알려 주지 않습니다. 출시한 버전마다 그 버전을 만든 빌드에서 기록하고 지원 기간 동안 보관하는 SBOM이 있어야, PSIRT가 노출 기간을 포함해 아직 현장에서 쓰이는 모든 버전에 대해 답할 수 있습니다.
고객은 VEX와 권고 중 무엇을 원합니까?
상태에 따라 둘 다 원합니다. VEX는 어떤 CVE가 제품에 영향을 주지 않는지 고객의 스캐너에 알려 주므로 해당 결과가 더 이상 표시되지 않습니다. 권고는 무엇이 영향을 받는지, 무엇이 수정되었는지, 무엇을 해야 하는지 사람에게 알려 줍니다. 가능한 한 기계 판독 가능한 형식으로 둘 다 게시하면, 대부분의 질문에 묻기 전에 답할 수 있습니다.
