공급망
일본 중요 인프라에 소프트웨어를 판매하려면
2026년 10월 1일, 일본에서 두 가지 사이버 보안 변화가 시행되었습니다. 둘 다 해외 소프트웨어 공급업체를 겨냥한 것은 아니지만, 중요 인프라 운영자가 공급업체에 기대하는 수준을 높입니다. 무엇이 바뀌었는지, 고객이 이제 무엇을 요구할 수 있는지, 그 요구 중 어떤 것에 빌드로 답할 수 있는지 설명합니다.
업데이트
2026년 10월 1일에 바뀐 것
두 변화는 흔히 하나로 묘사되지만, 법적 근거와 대상이 서로 다릅니다.
| 능동적 사이버 방어법 | 통일 기준 | |
|---|---|---|
| 성격 | 2025년 법률 제42호, 일본어로 サイバー対処能力強化法 | 사이버 보안 전략본부가 2026년 7월 31일 결정한 기준 |
| 대상 | 지정된 기간 인프라(基幹インフラ) 운영자 | 정부 기관, 그리고 이를 통해 16개 중요 인프라 분야의 운영자 |
| 요구 사항 | 핵심 자산 신고와 정부에 대한 사고 보고 | 거버넌스와 공급망 위험부터 취약점 관리까지 분야 공통 보안 조치 |
| 구속력 | 벌칙이 있는 법적 의무 | 그 자체로는 강제력이 없음. 각 분야의 안전 기준을 통해 운영자에게 적용 |
16개 분야는 정보통신, 금융, 항공, 공항, 철도, 전력, 가스, 정부·행정 서비스, 의료, 수도, 물류, 화학, 신용, 석유, 항만, 우편입니다.
기준과 함께 일본 국가사이버통괄실은 안전 기준 작성을 위한 지침을 발표했으며, 이 지침도 10월 1일부터 시행되었습니다. 운영자가 구매처 기업에 대해 무엇을 해야 하는지를 구체적으로 밝히고 있으므로, 공급업체에 가장 유용한 문서입니다.
공급업체에 영향이 미치는 이유
의무는 운영자에게 있으므로, 공급업체에 미치는 영향은 법적이라기보다 상업적입니다. 계약 조건, 조달 기준, 설문지의 형태로 다가옵니다. 특정 고객에게 무엇이 적용되는지는 그 고객의 분야와 자체 안전 기준에 따라 다르므로, 추측하지 말고 고객에게 확인하세요.
통일 기준은 운영자에게 중요 시스템이 공급망에 어떻게 의존하는지 파악하고, 공급업체의 보안 수준을 알고, 제품과 서비스를 구매할 때 보안 요구 사항을 정하도록 요구합니다. 지침은 이를 구체적인 항목으로 풀어냅니다.
운영자가 요구할 수 있는 것
지침은 운영자가 취해야 할 조치와 바람직한 조치를 구분합니다. 아래 표는 둘 다 보여 주며, 증거 중 빌드에서 나올 수 있는 부분을 함께 표시합니다.
| 지침의 내용 | 수준 | 빌드에서 나오는 증거 |
|---|---|---|
| 계약서에 명시하는 보안 요구 사항. 예: 심각한 취약점의 처리 및 보고 방식(2.9 ②-2) | 취해야 할 조치 | 분류부터 수정 릴리스까지 각 취약점의 기록 |
| 구매한 시스템의 공급업체가 유지 보수 계약에 따라 취약점을 보고, 처리, 공개(3.6 ①-2) | 취해야 할 조치 | 출시한 제품의 지속적인 모니터링과 각 취약점이 영향을 미치는 릴리스 |
| 취약점이나 사고 발견 시 공급업체와 신속하게 정보를 공유하는 방법(2.9 ③-3) | 취해야 할 조치 | 어떤 릴리스에 특정 패키지가 포함되어 있는지 보여 주는 빌드 이력 |
| 조달에 투명성이 필요한 경우 공급업체에 SBOM 작성 및 제공 요청(2.9 ③-4) | 바람직한 조치 | CycloneDX 또는 SPDX로 내보내는 빌드별 SBOM |
| 공급업체가 안전한 소프트웨어 개발 관행에 따라 개발하는지 확인(2.9 ③-4) | 바람직한 조치 | 격리된 빌드 작업과 강제 적용되는 이그레스 정책 |
일본은 SBOM을 요구합니까?
통일 기준에서는 요구하지 않으며, 통일 기준은 SBOM을 언급하지 않습니다. 지침은 SBOM을 선택 사항으로 제시합니다. 조달에 투명성이 필요한 운영자는 공급업체에 SBOM 작성 및 제공을 요청할 수 있으며, 지침은 METI의 SBOM 가이드 2.0 버전을 참고하도록 안내합니다. 그래도 요청에는 응하는 편이 좋을 가능성이 큽니다. 계약으로 선택 사항이 구속력 있는 의무가 될 수 있기 때문입니다.
고객이 살펴볼 수 있는 그 밖의 사항
- 제3자 평가. 지침은 공급업체 확인 작업을 줄이기 위해 외부 평가를 활용하도록 제안합니다. ISMS 적합성 평가와, METI 및 국가사이버통괄실의 SCS 평가 제도를 들고 있으며, SCS 평가 제도는 일본 2026 회계연도 말경 시작될 예정입니다.
- 제품 및 서비스 제도. 또한 선정 기준을 정할 때 IoT 제품은 JC-STAR, 클라우드 서비스는 ISMAP, IT 제품은 JISEC을 참고하도록 운영자에게 안내합니다.
- 취약점 평가. 운영자는 자체 시스템을 정기적으로 평가하며, 계약 조건을 통해 평가와 보고가 공급업체로 확대될 수 있습니다.
- 데이터 조건. 계약은 데이터의 위치, 저장, 보관, 이전, 폐기를 다룰 수 있습니다.
이미 CRA에 대비하고 있다면
상당 부분을 그대로 활용할 수 있습니다. EU Cyber Resilience Act는 고유한 의무를 가진 별개의 제도이므로, CRA를 충족한다고 해서 일본 고객의 요구가 충족되지는 않습니다. 하지만 둘 다 결국 같은 질문으로 귀결됩니다. 출시한 소프트웨어에 무엇이 들어 있는지, 어떤 릴리스가 취약점의 영향을 받는지, 그에 대해 무엇을 했는지입니다. 이 답이 빌드에서 나온다면, 다시 모으지 않고 일본 고객에게도 재사용할 수 있습니다.
CRACI의 역할
CRACI는 각 GitHub Actions 작업이 실제로 가져온 것을 기록해 빌드에서 SBOM을 생성하고, 출시된 제품을 모니터링하며, 분류부터 수정 릴리스까지 취약점을 추적합니다. 이를 통해 위 표의 요청에 대한 증거를 확보할 수 있습니다.
CRACI는 운영자가 기대할 수 있는 것의 일부만 다룹니다. CRACI는 취약점 평가나 모의 침투 테스트를 수행하지 않고, 배포된 시스템을 패치하지 않으며, 일본 당국에 보고하지 않습니다. 어떤 분야의 기준에 대해서도 규정 준수를 보장하지 않습니다. CRACI는 유럽에서 호스팅되며 보유한 인증은 ISO/IEC 27001뿐이므로, 두 가지 모두 고객의 데이터 조건과 선정 기준에 맞는지 확인하세요.
일본 중요 인프라: 자주 묻는 질문
일본의 능동적 사이버 방어법은 해외 소프트웨어 공급업체에 적용됩니까?
신고 및 사고 보고 의무는 지정된 인프라 운영자에게 있습니다. 공급업체는 이러한 고객이 계약에서 요구하는 사항을 통해 영향을 받을 가능성이 더 크므로, 고객과 법률 자문가에게 확인하세요.
통일 기준은 의무 사항입니까?
그 자체로는 아닙니다. 주로 정부 기관을 대상으로 하며 분야별 안전 기준에 담아야 할 내용을 정하므로, 운영자를 구속하는 내용은 분야에 따라 다릅니다.
어떤 분야가 대상입니까?
16개 분야입니다. 정보통신, 금융, 항공, 공항, 철도, 전력, 가스, 정부·행정 서비스, 의료, 수도, 물류, 화학, 신용, 석유, 항만, 우편입니다.
일본은 SBOM을 요구합니까?
통일 기준에서는 요구하지 않으며, 통일 기준은 SBOM을 언급하지 않습니다. 안전 기준 작성 지침은 SBOM을 운영자가 공급업체에 요청할 수 있는 것으로 제시하며, 계약으로 이를 구속력 있게 만들 수 있습니다.
취약점 관리 항목은 무엇을 요구합니까?
통일 기준 3.3.6항은 AI로 인해 발견부터 악용까지의 시간이 짧아진다는 점을 고려해, 운영 중인 시스템에 취약점이 영향을 미치는지 확인하고, 시스템을 정기적으로 평가하며, 패치 절차를 정하도록 운영자에게 요구합니다.
CRA 대비로 일본의 요구 사항도 충족됩니까?
아닙니다. 하지만 증거의 상당 부분을 활용할 수 있습니다. SBOM, 어떤 릴리스가 취약점의 영향을 받는지에 대한 기록, 취약점을 어떻게 처리했는지에 대한 기록은 두 경우 모두에 유용합니다.