몇 시간 안에 첫 공지를 보내고, 증명할 수 있게 되는 즉시 확정 답변을, 그리고 무엇이든 바뀔 때마다 후속 공지를 보내세요. 알고 있는 것, 아직 확인 중인 것, 그리고 언제 업데이트할지를 밝히세요. 모든 "영향 없음"은 오늘의 잠금 파일이 아니라, 공격 기간 동안 빌드가 실제로 설치한 것에 근거해야 합니다.
이 글은 무엇을, 언제, 어떤 근거로 말할지를 다룹니다. 조사 자체, 즉 취약한 구성 요소가 제품에 들어 있는지와 언제부터인지를 알아내는 방법은 우리는 영향을 받았는가?를 참고하세요.
고객이 패키지 레지스트리가 아니라 귀사에 묻는 이유
널리 보도된 공격이 있은 다음 주, 한 소규모 소프트웨어 공급업체 대표는 고객들이 문자 메시지를 보내왔다고 저희에게 말했습니다. 당신네 제품은 안전한가요? 우리 시스템은 안전한가요? 그의 고객들은 민감한 데이터를 다루고, 그의 팀에는 보안 전문가가 없었으며, 그 질문에는 그날 안에 답해야 했습니다.
고객은 패키지가 침해되었는지를 묻는 것이 아닙니다. 그것은 레지스트리와 연구자들이 이미 밝혔습니다. 고객이 묻는 것은 귀사가 고객에게 출시한 것에 그것이 들어 있는지입니다. 귀사의 제품이 곧 고객의 노출이기 때문입니다. 고객에게도 같은 질문을 던지는 그들의 고객, 감사인, 규제 기관이 있습니다. 반도체, 산업 장비, 헬스케어처럼 규제를 받는 공급망에서 이 질문은 호기심이 아니라 계약상의 문제입니다.
답을 검증할 수 없다면 고객은 다시 물을 것입니다. 아무 근거 없는 "영향을 받지 않았습니다"는 약속일 뿐입니다. "3월 24일부터 31일까지의 모든 릴리스 빌드를 확인했으며, 영향받는 버전을 설치한 빌드는 없었습니다"는 고객이 신뢰할 수 있는 진술입니다.
최근의 네 가지 공격과 각각이 제기한 질문
올바른 답은 공격이 어떻게 작동했는지에 따라 달라지므로, 템플릿만으로는 충분하지 않습니다. 아래 각 공격에서는 하나의 사실이 공급업체에게 "영향 있음"이 무엇을 의미하는지를 결정합니다.
xz Utils 백도어(CVE-2024-3094), 2024년 3월 29일 공개. Andres Freund가 발견한 백도어는 xz 5.6.0과 5.6.1 버전에 있었습니다. 릴리스 tarball에는 Git 리포지토리에 없는 코드가 들어 있었고, 이 코드가 빌드 중에 백도어를 주입했습니다. NVD와 Red Hat은 모두 CVSS 3.1 기준 10.0점을 매겼습니다. 주로 롤링 및 테스트 배포판에 도달했습니다. Debian testing, unstable, experimental, Fedora Rawhide와 41, openSUSE Tumbleweed, Kali이며, 안정 릴리스는 영향을 받지 않았습니다. 이 공격이 제기한 질문: 우리가 출시한 이미지나 장치 중 xz 5.6.0 또는 5.6.1이 포함된 것이 있는가, 그리고 각 빌드는 어떤 베이스 이미지를 사용했는가?
Shai-Hulud npm 웜, 2025년 9월부터 여러 차례에 걸쳐 발생. 감염된 패키지는 설치 시점에 스크립트를 실행해 npm, GitHub, 클라우드 자격 증명을 훔치고, 이를 이용해 더 많은 패키지의 감염된 버전을 게시합니다. 이 공격이 제기한 질문: CI 작업 중 감염된 버전을 설치한 것이 있는가, 그리고 우리의 게시 토큰이 노출되어 우리가 확산자가 되었는가? Shai-Hulud 항목에 모든 차수와 확인 방법이 정리되어 있습니다.
PyPI의 LiteLLM, 2026년 3월 24일. 1.82.7과 1.82.8 버전은 프로젝트의 GitHub 리포지토리에는 한 번도 없었던 자격 증명 탈취 코드와 함께 PyPI에 직접 업로드되었습니다. 1.82.8에서는 .pth 파일이 LiteLLM을 가져올 때만이 아니라 Python 인터프리터가 시작될 때마다 페이로드를 실행했으며, 환경 변수, SSH 키, 클라우드 자격 증명, Kubernetes 시크릿을 수집했습니다. HiddenLayer는 이 공격을 TeamPCP와 연결하는데, TeamPCP는 같은 달 Trivy와 Checkmarx 도구도 공격했습니다. 초기 침투 경로에 대해 LiteLLM 자체 권고는 두 가지 설명을 내놓습니다. CI 보안 스캔 워크플로의 Trivy 종속성을 원인으로 지목하면서, 메인테이너의 PyPI 계정이 침해되었을 수 있다고도 밝힙니다. 노출 기간조차 같은 권고 안에서 다르게 기술되어, 한 곳에서는 약 40분, 다른 곳에서는 UTC 10:39부터 16:00까지라고 합니다. 이 공격이 제기한 질문: 빌드나 출시한 컨테이너에 그 버전들이 포함되었는가, 그리고 그 환경에는 어떤 시크릿이 있었는가?
npm의 axios, 2026년 3월 31일. 공격자가 메인테이너의 npm 계정을 탈취해 axios 1.14.1과 0.30.4를 게시했습니다. 이 버전들은 [email protected]이라는 종속성을 추가했고, 그 설치 스크립트가 macOS, Windows, Linux용 원격 접근 트로이 목마를 설치했습니다. Datadog은 기간을 UTC 00:21부터 03:25까지로 보며, Snyk에 따르면 해당 버전은 UTC 03:29에 삭제되었습니다. 이 공격이 제기한 질문: 그 기간에 그 버전들을 해석한 빌드가 있는가? 기간 이전에 커밋된 잠금 파일은 그것을 사용한 빌드에 대해서는 "아니요"라고 답해 주지만, 잠금 파일 없이 npm install을 실행한 빌드에 대해서는 아무것도 알려 주지 않습니다.
| 공격 | 생태계 | 영향받는 버전 | 기간 | 공급업체에게 "영향 있음"의 의미 |
|---|---|---|---|---|
| xz Utils | Linux 배포판 | 5.6.0, 5.6.1 | 2024년 3월 29일 공개까지 수 주 | 영향받는 배포판 기반으로 빌드한 이미지나 장치에 포함해 출시함 |
| Shai-Hulud | npm | 차수마다 수백 개 패키지 | 차수마다 수 시간에서 수일 | 그것으로 빌드했고, 귀사 토큰이 확산에 쓰였을 수 있음. 출시했을 수도 있음 |
| LiteLLM | PyPI | 1.82.7, 1.82.8 | 2026년 3월 24일 UTC 10:39부터(종료 시점은 출처마다 다름) | 그것으로 빌드했거나 출시했고, 그 환경의 시크릿이 탈취되었을 수 있음 |
| axios | npm | 1.14.1, 0.30.4 | 2026년 3월 31일 UTC 약 00:21부터 03:25까지 | 기간 중에 그것으로 빌드함. 트로이 목마가 빌드 머신에서 실행됨 |
공급망 공격이 아닌 Critical 취약점에서도 같은 질문이 나옵니다. 2026년 10월 PHP2Shell이 악용되었을 때, PHP를 포함해 출시하는 모든 제품의 고객들은 자신이 쓰는 버전 중 어느 것에 영향받는 PHP가 들어 있는지 물었습니다. 아래 단계는 그대로 적용됩니다.
답변은 세 단계로 이루어집니다
| 단계 | 시점 | 보내는 내용 |
|---|---|---|
| 첫 공지(holding statement) | 뉴스가 나온 후 몇 시간 안 | 알고 있는 것, 확인 중인 것, 업데이트 시점 |
| 확정 답변 | 증명할 수 있게 되는 즉시, 대개 첫날 | 명시한 버전에 대한 "영향 없음", 또는 조치 방법을 담은 "영향 있음" |
| 후속 공지 | 수정이 출시될 때, 새로운 사실을 알게 될 때, 케이스를 종결할 때 | 같은 공지의 개정판 |
첫 한 시간: 첫 공지
첫 공지는 사실이 모두 확인되기 전에 내는 최초의 공식 입장입니다. 사실인 것을, 빨리 말하세요. 침묵은 추측으로 채워지며, 귀사로부터 아무 소식도 듣지 못한 고객은 귀사가 아직 알아차리지 못했다고 생각합니다.
- 누가, 어디서. 이름이 명시된 발신자 한 명이, 고객이 사용한 채널로 보내고, 보안 페이지에도 게시합니다. 그때그때의 개별 답변보다 공유된 하나의 문안이 낫습니다. 일관성이 유지되고, 법무 검토도 한 번이면 됩니다.
- 담을 내용. 공격을 알고 있다는 것, 제품과 빌드 시스템을 확인하고 있다는 것, 지금까지 알게 된 것, 다음 업데이트 시점, 그리고 연락처입니다.
- 담아서는 안 되는 내용. 확인하기 전의 "영향을 받지 않았습니다", 공격자에 대한 추측, 책임 전가입니다.
템플릿 1: 첫 공지
제목: [공격 이름] 관련 당사의 1차 입장
당사는 보도된 [패키지 또는 프로젝트] 침해 사실을 인지하고 있습니다. 영향받는 버전은 [영향받는 버전]이며, [날짜]에 게시되었습니다. 당사 보안팀은 [제품]의 모든 릴리스와 당사 빌드 시스템에 영향받는 버전이 있는지 확인하고 있습니다. 현재까지 [확인한 제품에서 영향받는 버전을 발견하지 못했습니다 / 확인을 아직 완료하지 못했습니다]. [날짜 및 시간, 시간대]까지 업데이트를 보내 드리겠습니다. 그사이 문의 사항이 있으시면 [이름, 보안 담당 연락처]로 연락해 주시기 바랍니다. 확인이 완료되기 전에는 영향에 대해 추측하여 말씀드리지 않겠습니다.문자 메시지나 채팅이라면 두 문장으로 충분합니다.
[공격 이름] 침해 건을 인지하고 있으며, 지금 [제품]의 모든 릴리스와 당사 빌드를 확인하고 있습니다. [시간]까지 확정된 답변을 드리겠습니다.필요해지기 전에 세 가지 템플릿 모두 법률 자문의 승인을 받아 두세요.
첫날: 증거와 함께 확정하기
가능한 결과는 두 가지이며, 각각 고유한 증거가 필요합니다. "영향 없음" 답변을 위해서는 다음을 모으세요.
- 권고나 연구자의 분석에 나온 영향받는 패키지와 버전
- 귀사의 제품과 고객이 실제로 실행하는 버전
- 그 각 버전에 대해, 그것을 만든 빌드와 그 빌드가 설치한 것의 기록(현재 잠금 파일이 아님)
- 릴리스를 만들지 않은 CI 작업을 포함해, 공격 기간 동안 실행된 모든 빌드
- 토큰을 훔치는 웜의 경우, 악성 코드를 실행했을 수 있는 작업에 CI 시크릿이 있었는지 여부
각각을 산정하는 방법은 우리는 영향을 받았는가?에서 설명합니다.
모든 진술에는 보여 줄 수 있는 근거가 있어야 합니다.
| 진술 | 보여 줄 수 있어야 하는 것 | 충분하지 않은 것 |
|---|---|---|
| "제품 X 버전 Y에는 패키지 Z가 들어 있지 않습니다" | 버전 Y의 릴리스 빌드에서 기록된 SBOM | 현재 리포지토리의 스캔 |
| "당사 빌드 중 침해된 버전을 설치한 것은 없습니다" | 기간 내 모든 빌드의 설치 기록 | 일부 작업이 우회하는 잠금 파일 |
| "당사 릴리스 파이프라인은 침해되지 않았습니다" | 기간 동안의 네트워크 및 시크릿 사용 기록 | 경보가 없었다는 사실 |
| "버전 Y 고객은 업그레이드 후 안전합니다" | 수정된 빌드의 기록과 교체한 자격 증명 | 변경 로그 항목 |
템플릿 2: 영향 없음
제목: [공격 이름] 관련 [제품]은 영향을 받지 않았습니다
당사는 [패키지] 침해 건(영향받는 버전: [영향받는 버전])에 대한 확인을 완료했습니다. 다음 [제품] 버전은 영향을 받지 않았습니다: [확인한 제품 및 버전 목록]. 당사는 [시작일]부터 [종료일]까지 실행된 모든 릴리스 빌드와 CI 빌드를 확인했습니다. 본 안내는 현재 소스 코드의 스캔이 아니라, 각 릴리스 빌드가 설치한 구성 요소의 기록에 근거합니다. 이들 빌드 중 영향받는 버전을 설치한 것은 없습니다. 증거가 필요하시면 사용 중이신 버전의 SBOM 또는 VEX 문서를 보내 드릴 수 있습니다. 이 평가를 바꿀 만한 사실을 알게 되면 알려 드리겠습니다. 연락처: [이름, 보안 담당 연락처]."영향 없음"은 명시한 버전에 대해서만 말하세요. "100% 안전"이라고는 절대 쓰지 마세요. 이후 고객이 전체 SBOM을 요청하면 고객 SBOM 요청에 답하기를 참고하세요.
템플릿 3: 영향 있음, 완화 조치 포함
제목: [공격 이름] 관련 [제품] [x~y] 버전에 조치가 필요합니다
[패키지] 침해 건에 대한 당사의 확인 결과, [제품] [x~y] 버전이 영향을 받은 것으로 확인되었습니다. 최초로 영향받은 빌드는 [날짜]에 만들어졌으며, [날짜]에 출시된 [z] 버전에는 더 이상 [패키지 버전]이 들어 있지 않습니다.
의미: [쉬운 말로 설명한 위험, 예: "이 버전들에 설치된 구성 요소가 실행 중인 시스템의 자격 증명을 외부 서버로 전송할 수 있습니다"].
지금 하실 일: [제품] [z]로 업그레이드해 주십시오. 즉시 업그레이드하실 수 없다면 [완화 조치, 예: 목록에 있는 호스트로의 아웃바운드 연결 차단]. [환경]에서 [제품] [x~y] 버전을 사용하셨다면, 해당 환경에서 사용할 수 있었던 [자격 증명 또는 키]를 교체해 주십시오.
당사가 취한 조치: 영향받는 버전을 당사 빌드에서 제거하고, 깨끗한 종속성으로 [제품]을 다시 빌드했으며, 당사 빌드 시스템이 사용하는 자격 증명을 교체하고 [기타 조치]를 수행했습니다. [필요한 경우 관계 당국에 통지했습니다.]
다음 업데이트는 [날짜]까지, 또는 변동 사항이 있으면 그보다 일찍 보내 드리겠습니다. 연락처: [이름, 보안 담당 연락처]."영향 있음" 공지는 법적 의무일 수도 있습니다. 아래의 보고 섹션을 참고하세요.
VEX와 CSAF의 역할. "영향 없음" 또는 "수정됨" 진술은 VEX로 게시할 수 있으며, 그러면 고객의 스캐너가 해당 패키지를 더 이상 표시하지 않습니다. 대규모 고객은 기계 판독 가능한 권고도 기대할 수 있으며, 대부분이 요청하는 형식은 CSAF입니다.
후속 공지: 제대로 마무리하기
수정이 출시될 때, 조사에서 새로운 사실이 나올 때 후속 공지를 보내고, 케이스를 종결할 때 최종 공지를 보내세요. 사고마다 권고를 하나만 두고, 매번 새로 보내는 대신 개정하세요(교체하지 말고 업데이트하기). 누구에게 언제 무엇을 알렸는지 기록하세요. 다음 감사나 고객 보안 설문에서 물어볼 것입니다.
아직 모를 때 할 말
"아직 모릅니다"는 나중에 철회해야 하는 "영향 없음"보다 더 큰 신뢰를 쌓습니다. 누구도 불안하게 만들지 않으면서 정직한 표현은 다음과 같습니다.
- "[지금까지 확인한 제품]에서 [패키지]를 발견하지 못했습니다. [남은 제품 또는 빌드 시스템]을 계속 확인하고 있으며, [시간]까지 업데이트를 드리겠습니다."
- "사용 중이신 버전은 공격 기간 이전에 빌드되었습니다. 이후의 빌드가 이를 대체하지 않았는지 확인하고 있습니다."
- "당사 빌드 시스템 중 영향받는 버전을 실행한 것이 있는지 확인하고 있습니다. 설치하신 제품은 별개의 문제이며, 두 가지 모두에 답을 드리겠습니다."
피해야 할 표현:
- "전혀 영향이 없습니다"
- "완벽하게 안전합니다"
- "어떤 공급망 공격에도 영향을 받지 않습니다"
- "당사 스캐너에서 아무것도 발견되지 않았습니다"
공격이 보고 의무가 될 때
EU에서 디지털 요소가 있는 제품을 판매한다면, Cyber Resilience Act의 보고 의무가 2026년 9월 11일부터 적용되고 있습니다. 이날은 ENISA가 Single Reporting Platform을 출시한 날입니다. 제품에서 실제로 악용되고 있는 취약점, 또는 제품의 보안에 영향을 미치는 심각한 사고는, 이를 인지한 후 24시간 안의 조기 경보, 72시간 안의 통지, 그리고 최종 보고서를 요구하며, 이는 플랫폼을 통해 담당 조정 CSIRT와 ENISA에 제출됩니다. 단계별 내용은 CRA 가이드에서 설명합니다.
출시한 침해된 종속성이나 자사 빌드 파이프라인의 침해가 그 정의에 해당하는지는 이 글이 아니라 귀사와 법률 자문이 판단할 문제입니다. 규정은 용어를 다음과 같이 정의합니다.
- "실제로 악용되고 있는 취약점"이란 "악의적 행위자가 시스템 소유자의 허가 없이 시스템에서 이를 악용했다는 신뢰할 수 있는 증거가 있는 취약점"입니다(Article 3 point 42).
- 사고는 "디지털 요소가 있는 제품이 민감하거나 중요한 데이터 또는 기능의 가용성, 진정성, 무결성 또는 기밀성을 보호하는 능력에 부정적인 영향을 미치거나 미칠 수 있는" 경우, 또는 제품이나 사용자 시스템에서 "악성 코드의 유입 또는 실행으로 이어졌거나 이어질 수 있는" 경우 심각한 것입니다(Article 14(5)).
Article 14(8)는 사용자에 대한 의무를 더합니다. 영향을 받는 사용자에게, 그리고 적절한 경우 모든 사용자에게, 취약점이나 사고와 사용자가 적용할 수 있는 완화 조치를 "적절한 경우 쉽게 자동 처리할 수 있는 구조화된 기계 판독 가능한 형식으로" 알려야 합니다. 템플릿 3은 그 의무를 이행하는 일의 일부가 될 수 있습니다.
다른 제도도 적용됩니다. NIS2에 따라 필수 및 중요 기관은 중대한 사고를 담당 CSIRT나 관할 당국에 통지해야 하며, 많은 고객 계약에는 고유한 기한을 둔 자체 통지 조항이 있습니다.
다음 공격에 미리 대비하기
- 각 릴리스 빌드가 설치한 것의 기록을 제품의 지원 기간 동안 보관(빌드 시점 SBOM).
- 어떤 고객이 어떤 버전을 실행하는지에 대한 목록.
- 법무 승인을 받은 위의 세 가지 템플릿.
- 고객 유형별로 이름이 명시된 발신자와 채널.
- 업데이트를 게시할 보안 페이지와
security.txt파일(조정된 취약점 공개). - 침해된 패키지가 빌드에 필요 없는 호스트로 시크릿을 보낼 수 없도록 하는 CI 이그레스 제어(GitHub Actions 이그레스 정책).
사고가 한 건씩이 아니라 수백 건씩 들어온다면 PSIRT 확장하기를 참고하세요.
CRACI의 역할
위의 증거 표가 거듭 요구하는 것은 한 가지, 각 릴리스 빌드가 설치한 것의 기록입니다. CRACI가 보관하는 것이 바로 그것입니다. CRACI는 GitHub Actions 빌드를 자체 러너에서 실행하고, 설치 스크립트가 가져온 패키지와 캐시에서 복원된 패키지를 포함해 각 작업이 실제로 가져온 모든 패키지를 기록합니다. 과거 모든 빌드의 SBOM이 보관되므로, "기간 중에 axios 1.14.1을 설치한 빌드가 있었는가?"에 영향을 받은 기간과 함께 빌드 기록으로 답할 수 있으며, 보존 기간이 허용하는 범위까지 거슬러 올라갈 수 있습니다.
xz 백도어처럼 CVE가 게시된 알려진 악성 릴리스는 다른 취약점과 마찬가지로 표시되며, 정책 게이트로 이를 포함한 빌드를 차단할 수 있습니다. CRACI는 새로운 악성 패키지를 동작이나 평판으로 탐지하지 않습니다.
CRACI의 이그레스 정책은 빌드에 필요 없는 호스트로의 연결을 차단하므로, 아무도 본 적 없는 공격에서도 악성 설치 스크립트가 외부로 보낼 수 있는 것이 제한됩니다. 고객이 증거를 요청하면, 고객이 실행하는 버전의 SBOM을 CycloneDX 또는 SPDX로 내보내 보낼 수 있습니다. CRACI는 VEX를 지원합니다.
빌드 기록으로 "우리는 영향을 받았는가?"에 답해 보세요. 또는 공급망 공격의 작동 방식을 더 읽어 보세요.
CRACI가 답이 아닌 경우
- 커뮤니케이션 자체에 대한 도움이 필요한 경우. PR과 법률 자문은 다른 일입니다.
- 영향받는 소프트웨어가 CRACI에서 빌드되지 않은 경우. CRACI는 자체 러너에서 실행되는 GitHub Actions 빌드를 기록합니다. 다른 CI 시스템은 로드맵에 있습니다.
- 직접 빌드하지 않은 벤더 제품에 관한 질문인 경우. 벤더 SBOM을 CRACI에 추가할 수 있지만, 답의 품질은 벤더 SBOM의 품질을 넘지 못합니다.
- 권고가 나오기 전에 완전히 새로운 악성 패키지를 잡아내야 하는 경우. CRACI는 CVE가 포함된 권고가 게시된 후에 알려진 악성 릴리스를 표시하며, 동작이나 평판으로 악성 코드를 탐지하지 않습니다(제로데이 취약점 대응).
자주 묻는 질문
공급망 공격이 뉴스에 나오면 고객에게 무엇을 말해야 합니까?
몇 시간 안에 첫 공지를 보내세요. 공격을 알고 있다는 것, 제품과 빌드를 확인하고 있다는 것, 지금까지 알게 된 것, 그리고 언제 업데이트할지를 담습니다. 빌드 기록으로 뒷받침할 수 있게 되는 즉시 명시한 제품 버전에 대한 확정 답변을 보내고, 무엇이든 바뀌면 후속 공지를 보내세요.
첫 공지에는 무엇을 담아야 합니까?
무슨 일이 일어났는지 한 문장으로, 제품과 빌드 시스템을 확인하고 있다는 것, 지금까지 발견한 것, 다음 업데이트 시각, 그리고 연락처입니다. 확인하기 전에 "영향 없음"이라고 말하거나, 공격자에 대해 추측하거나, 누군가를 탓해서는 안 됩니다.
과도한 약속 없이 "영향을 받지 않았습니다"라고 말하려면 어떻게 해야 합니까?
확인한 제품과 버전, 확인한 빌드의 날짜 범위, 그리고 각 릴리스 빌드가 설치한 구성 요소의 기록처럼 사용한 증거를 명시하세요. 그 버전들에 대해 "영향 없음"이라고 말하고, SBOM이나 VEX 문서를 제공하겠다고 하고, 무엇이든 바뀌면 업데이트하겠다고 약속하세요. "100% 안전"이나 "완벽하게 안전"은 피하세요.
고객에게 보내는 "영향을 받았습니다" 공지에는 무엇이 들어가야 합니까?
어떤 제품과 버전이 영향을 받았는지, 언제부터 어느 수정 버전까지인지, 쉬운 말로 설명한 위험, 고객이 지금 해야 할 일(업그레이드, 자격 증명 교체, 호스트 차단), 귀사가 이미 한 일, 다음 업데이트 시점, 그리고 연락처입니다.
"영향 없음" 진술은 어떤 증거로 뒷받침해야 합니까?
고객이 실행하는 각 버전에 대해, 오늘의 잠금 파일이 아니라 그 버전을 만든 빌드가 설치한 것의 기록입니다. 공격 기간 동안 실행된 모든 빌드의 기록을 더하고, 자격 증명을 훔치는 공격이라면 악성 코드를 실행했을 수 있는 작업에 시크릿이 있었는지도 확인하세요.
Cyber Resilience Act에 따라 공급망 공격을 보고해야 합니까?
그럴 수 있습니다. 2026년 9월 11일부터 EU에서 판매되는 디지털 요소가 있는 제품의 제조사는 실제로 악용되고 있는 취약점과 제품 보안에 영향을 미치는 심각한 사고를 보고해야 합니다. 24시간 안의 조기 경보, 72시간 안의 통지, 그리고 최종 보고서입니다. 특정 공격이 이에 해당하는지는 귀사와 법률 자문이 판단할 문제입니다.
고객에게 얼마나 빨리 답해야 합니까?
몇 시간 안에 첫 공지로 답하세요. 확인 중이며 언제 업데이트할지만 담더라도 괜찮습니다. 확정 답변은 증명할 수 있게 되는 즉시 뒤따릅니다. 빠르고 정직한 "확인 중입니다"가 늦은 "영향 없음"보다 신뢰에 더 도움이 됩니다.
