剣 KENSAI
← 블로그로 돌아가기
NIS2 연구 ⏱️ 읽는 데 12분

NIS2하의 공급망 보안: 공급업체의 취약점에 대한 책임은 귀사에 있습니다

NIS2 제21조는 제3자 위험 관리를 근본적으로 바꿉니다. 이제 공급업체의 보안 실패에 대해 귀사가 법적 책임을 집니다. 공급업체의 취약점으로 인해 귀사에 침해 사고가 발생하면, 귀사가 아무런 잘못을 하지 않았더라도 동일하게 €10M의 과징금에 처할 수 있습니다. 자신을 보호하는 방법은 다음과 같습니다.


📜 NIS2 제21조: 공급망 보안 요건

NIS2 지침(EU 2022/2555) 제21조는 다음과 같이 규정합니다.

"회원국은 필수 및 중요 기관이 운영하거나 서비스를 제공하기 위해 사용하는 네트워크 및 정보 시스템의 보안에 제기되는 위험을 관리하고 해당 기관의 서비스 수신자와 기타 서비스에 미치는 사고의 영향을 방지하거나 최소화하기 위해 적절하고 비례적인 기술적·운영적·조직적 조치를 취하도록 보장해야 한다."

쉽게 말하면 다음과 같습니다. 제3자 소프트웨어, 클라우드 서비스, SaaS 플랫폼, API, 공급업체 인프라를 포함한 전체 공급망의 보안을 책임져야 합니다. 공급업체의 취약점으로 인해 귀사에 침해 사고가 발생하면 책임은 귀사에 있습니다. 공급업체에 있는 것이 아닙니다.

NIS2에서 말하는 "공급망 보안"의 의미

NIS2의 공급망 의무는 다음을 포괄합니다.

⚠️ 핵심 법적 원칙: 면책 규정 없음

계약을 통해 일부 책임을 처리자에게 이전할 수 있는 GDPR과 달리, NIS2에는 공급망 실패에 대한 면책 규정이 없습니다. 계약을 통해 NIS2 책임을 공급업체에 전가할 수 없습니다. 공급업체 계약이 완벽하더라도 그 취약점으로 인해 귀사에 침해 사고가 발생하면 BSI의 제재 대상이 됩니다.

💥 최근 공급망 공격: 사례 연구

사례 연구 1: SolarWinds(2020) — 전환점이 된 사건

역사상 가장 정교한 공급망 공격으로 남아 있는 사건은 SolarWinds Orion 침해 사고입니다 . 러시아 APT29(Cozy Bear)는 SolarWinds의 소프트웨어 빌드 파이프라인에 악성코드를 삽입해 이를 정상 업데이트로 위장하고, NATO, Pentagon, Fortune 500 기업을 포함한 18,000개 고객에게 배포했습니다.

공격 타임라인:

NIS2 관점의 시사점: 침해된 SolarWinds 업데이트를 설치한 모든 조직은 피해자였음에도 NIS2에 따른 책임을 지게 됩니다. BSI는 사고 통지, 포렌식 조사, 공급망 실사 증명을 요구할 것입니다.

사례 연구 2: Kaseya VSA 랜섬웨어(2021)

REvil 랜섬웨어 조직은 Kaseya VSA(원격 관리 소프트웨어)의 제로데이 취약점을 악용하여 관리형 서비스 제공업체(MSP)를 통해 1,500개 조직을 동시에 암호화했습니다 . 한 소프트웨어 공급업체의 단일 취약점이 연쇄적으로 확산해 역사상 최대 규모의 랜섬웨어 공격으로 이어졌습니다.

공격 방식:

NIS2 관점의 시사점: MSP를 이용하는 조직은 MSP의 보안 실패에 대한 책임을 집니다. BSI에 "우리 MSP가 해킹당했다"고 항변할 수 없습니다. 규정 준수는 귀사의 책임입니다.

사례 연구 3: MOVEit Transfer(2023)

Cl0p 랜섬웨어 조직은 MOVEit Transfer SQL 인젝션 취약점(CVE-2023-34362)을 무기화해 Shell, British Airways, BBC 및 EU 전역의 정부기관을 포함하여 전 세계 2,000곳 이상의 조직을 침해했습니다.

NIS2에서 중요한 이유:

사례 연구 4: Log4Shell(2021) — 종속성 위기

CVE-2021-44228(Log4Shell)은 널리 사용되는 Java 로깅 라이브러리인 Log4j의 원격 코드 실행 취약점이었습니다. Log4j는 전이 종속성 (다른 소프트웨어에 내장된 종속성)이기 때문에 조직들은 자신이 취약하다는 사실조차 알지 못했습니다.

📊 Log4Shell 피해 수치

NIS2 관점의 시사점: 존재조차 몰랐던 종속성을 포함한 모든 종속성의 취약점에 대해 책임을 집니다. BSI는 소프트웨어 자재 명세서(SBOM)를 유지하고 중요 CVE 공개 후 14일 이내에 패치할 것을 기대합니다.

🔍 공급업체 감사 방법(NIS2 준수 절차)

NIS2는 "적절하고 비례적인" 공급망 보안 조치를 요구합니다. 다음은 BSI 감사를 충족할 수 있는 실용적인 공급업체 위험 관리 프레임워크입니다.

1단계: 모든 제3자 종속성 목록화

무엇이 있는지 모르면 보호할 수도 없습니다. 포괄적인 공급업체 목록을 작성하십시오.

범주 문서화할 항목 위험 수준
소프트웨어 공급업체 모든 상용 소프트웨어, 라이선스, 업데이트 메커니즘 중요
오픈 소스 종속성 직접 종속성 + 전이 종속성(SBOM 사용) 중요
클라우드 제공업체 AWS/Azure/GCP 서비스, 접근 방법, 데이터 위치 중요
SaaS 플랫폼 CRM, 이메일, 분석, 데이터 접근 권한이 있는 API 높음
관리형 서비스 제공업체 IT 지원, SOC, 백업 서비스, 원격 접근 중요
하드웨어 공급업체 네트워크 장비, 펌웨어 버전, 업데이트 정책 중간

2단계: 공급업체 보안 설문지

모든 중요 공급업체를 대상으로 보안 평가를 수행하십시오. 다음은 BSI가 확인할 것으로 예상되는 질문입니다.

🔐 NIS2 준수 공급업체 보안 설문지

  1. 인증: ISO 27001, SOC 2 Type II 또는 이에 상응하는 인증을 보유하고 있습니까? (최신 보고서 제출)
  2. 취약점 관리: 중요 CVE 패치 SLA는 얼마입니까? (NIS2 준수를 위해 ≤14일이어야 함)
  3. 사고 통지: 보안 사고 발생 후 24시간 이내에 당사에 통지합니까? (NIS2 요건)
  4. 접근 통제: 모든 관리 접근에 MFA를 사용합니까? (NIS2 기본 통제)
  5. 데이터 소재지: 당사의 데이터는 어디에 저장됩니까? (GDPR/NIS2는 필수 기관에 EU 데이터 주권을 요구)
  6. 암호화: 저장 데이터(AES-256)와 전송 중 데이터(TLS 1.3)가 암호화됩니까?
  7. 백업 보안: 백업이 격리되거나 오프라인으로 보관됩니까? (랜섬웨어 방어)
  8. 공급망: 귀사의 중요 공급업체는 누구입니까? (연쇄 위험 분석)
  9. 보험: 사이버 책임보험에 가입되어 있습니까? (€10M+ 보장 권장)
  10. 감사권: 제3자 보안 감사를 허용합니까? (NIS2에서 요구할 수 있음)

3단계: 지속적인 모니터링(일회성 평가 아님)

NIS2는 공급망 위험을 지속적으로 관리할 것을 요구합니다. 연례 설문지만으로는 충분하지 않습니다. 다음과 같은 지속적 모니터링을 구현하십시오.

🛡️ 소프트웨어 공급망 보안(SBOM 요건)

Log4Shell 사고는 조직들이 자체 인프라에서 어떤 소프트웨어가 실행 중인지 알지 못한다는 사실을 입증했습니다. 소프트웨어 자재 명세서(SBOM)는 이제 사실상 NIS2 요건입니다.

SBOM이란?

SBOM은 직접 종속성과 전이 종속성(종속성의 종속성)을 모두 포함한 모든 소프트웨어 구성요소의 완전한 목록입니다.

일반적인 웹 애플리케이션의 SBOM 예시:

구성요소 버전 라이선스 알려진 CVE
express 4.18.2 MIT 0
lodash 4.17.19 MIT CVE-2020-8203(프로토타입 오염)
axios 0.21.1 MIT CVE-2021-3749(SSRF)
log4j-core(전이 종속성) 2.14.0 Apache 2.0 CVE-2021-44228(Log4Shell RCE)

주목할 점은 log4j-core가 바로 전이 종속성이라는 것입니다. 애플리케이션이 이를 직접 가져오지는 않지만 다른 라이브러리가 가져옵니다. SBOM이 없다면 Log4Shell에 취약하다는 사실을 결코 알 수 없었을 것입니다.

SBOM 생성 방법

최신 도구를 사용하면 SBOM을 자동으로 생성할 수 있습니다.

NIS2 준수를 위한 SBOM 모범 사례

  1. 모든 릴리스에 SBOM 생성: CI/CD 파이프라인에 SBOM 생성을 포함하십시오(수동이 아닌 자동화 방식).
  2. 버전 관리 시스템에 SBOM 저장: 시간 경과에 따른 변경 사항을 추적하십시오(취약한 종속성 X가 코드베이스에 언제 유입되었는가?).
  3. CVE 대조 자동화: 매일 SBOM을 NVD 데이터베이스와 대조하십시오(기존 종속성에 영향을 미치는 신규 CVE 탐지).
  4. 패치 SLA 설정: NIS2는 중요 CVE를 14일 이내에 패치할 것을 기대합니다. 절차를 문서화하십시오.
  5. 고객과 SBOM 공유: 소프트웨어 공급업체라면 고객이 자체 NIS2 준수를 위해 귀사에 SBOM을 요구할 것입니다.

🚨 NIS2 집행 시나리오

가상의 BSI 감사 질문: "사고 보고서에는 제3자 라이브러리의 CVE-2024-XXXXX를 통해 침해당했다고 기재되어 있습니다. 이 CVE는 언제 공개되었습니까? 귀사의 환경에서 언제 발견했습니까? 패치하지 않은 이유는 무엇입니까?"

규정을 준수한 답변: "당사는 자동화된 SBOM 스캔을 운영합니다. CVE-2024-XXXXX는 1월 15일에 공개되었고, 당사 스캐너는 1월 16일에 이를 탐지했습니다. 당사는 8일 이내에 패치하여 14일 SLA를 준수했습니다. 이번 침해는 스캐너 적용 대상이 아니었던 레거시 시스템에 취약한 라이브러리가 존재해 발생했으며, 이후 해당 시스템도 적용 대상에 추가했습니다."

규정을 준수하지 못한 답변: "해당 라이브러리를 사용하고 있는지 몰랐습니다."

📋 NIS2 공급망 규정 준수 체크리스트

이 체크리스트를 활용하여 BSI 감사에 대비하십시오.

✅ 공급망 보안 체크리스트

💡 실용적인 공급업체 보안 전략

전략 1: 공급업체 등급별 관리

모든 공급업체의 위험이 동일하지는 않습니다. 보안 활동의 우선순위를 정하십시오.

등급 기준 보안 요건
중요 프로덕션 데이터 접근, 원격 관리자 접근 또는 필수 서비스 ISO 27001 + SOC 2 Type II 필수, 연례 감사, 24시간 이내 침해 통지
높음 민감한 데이터 또는 핵심 비즈니스 기능에 접근 SOC 2 또는 이에 상응하는 인증, 보안 설문지, 침해 통지 SLA
중간 데이터 접근 권한은 없지만 인프라/도구 제공 기본 보안 설문지, MFA 필수
낮음 데이터 접근 권한 없음, 비핵심 서비스 표준 계약 조건, 별도 평가 없음

전략 2: 공급업체 통합

모든 공급업체는 잠재적인 공격 경로입니다. 공급업체를 통합하여 공격 표면을 줄이십시오.

전략 3: 공급업체 접근에 제로 트러스트 적용

공급업체에 직접적인 네트워크 접근 권한을 부여하지 마십시오. 다음과 같은 제로 트러스트 통제를 구현하십시오.

🔧 소프트웨어 공급망 도구

수동 공급망 관리는 규모 확장이 어렵습니다. 자동화를 활용하십시오.

도구 범주 용도 예시
SBOM 생성 소프트웨어 목록 자동 생성 Syft, OWASP Dependency-Check, KENSAI
CVE 스캔 종속성을 NVD와 대조 Grype, Trivy, Snyk, KENSAI
공급업체 위험 모니터링 공급업체 보안 태세 추적 SecurityScorecard, BitSight, UpGuard
계약 관리 공급업체 계약 + SLA 중앙 관리 OneTrust, ServiceNow VRM, Archer
접근 관리 공급업체 원격 접근 통제 CyberArk, BeyondTrust, Okta

60초 만에 공급망 스캔

KENSAI는 NIS2 준수 SBOM을 자동으로 생성하고, 8개 프로그래밍 언어에서 취약한 종속성을 탐지하며, BSI 감사에 바로 활용할 수 있는 보고서를 제공합니다. 설치할 필요 없이 CI/CD 파이프라인이나 웹 대시보드에서 스캔할 수 있습니다.

무료 공급망 스캔 시작 →

📚 추가 자료


공급업체의 취약점에 대한 책임은 귀사에 있습니다.
KENSAI 보안 연구팀
2026년 3월 2일 — 14:00 CET