주요 내용
- NIS2 제21조는 공급망 보안을 필수 조치로 규정하고 있으며, 해당 기관들이 각 직접 공급업체의 취약점을 평가하도록 하고 있다.
- EU 사이버보안 기관인 ENISA는 구속력이 없는 병원 조달 지침에서 오픈소스 유지보수 담당자를 직접 공급업체로 간주하지 않을 수 있다고 밝혔습니다.
- 개발자가 추가한 오픈소스의 경우, 문의할 공급업체가 없을 수 있으므로 이를 검토하는 일은 귀사의 팀 몫이 됩니다.
- 관리 기관은 제21조에 따른 조치를 승인하며 이에 대한 책임을 질 수 있으므로, 해당 조치가 개발자가 추가한 오픈소스까지 포함하는지 확인해야 합니다.
계약을 바탕으로 작성된 공급업체 명부는 겉보기에는 완벽해 보일 수 있지만, 소프트웨어 내에 포함된 오픈소스 코드는 누락될 수 있습니다. 제2차 네트워크 및 정보 보안 지침 (NIS2)에 명시된 공급망 보안 조치는 귀사의 직접 공급업체만을 대상으로 합니다. 하지만 귀사 개발자가 직접 추가한 오픈소스 코드의 경우, 설문지를 보낼 공급업체가 없을 수도 있습니다.
그렇다면 코드가 오픈 소스일 때 누가 공급업체로 간주될까요? 그 답에 따라 공급업체에 어떤 질문을 할 수 있고, 어떤 확인 절차는 귀사의 팀이 직접 수행해야 하는지가 결정됩니다.
답이 무엇이든 간에, 공급업체로부터 제품을 구매한다고 해서 NIS2에 따른 의무가 해당 공급업체로 이전되는 것은 아닙니다. 이 지침은 적용 대상 기관들이 자체적인 조치를 통해 공급업체 위험을 관리할 것을 요구하고 있으며, 유럽연합 사이버보안청(ENISA)은 구속력이 없는 ‘기술적 이행 지침’을 통해 위험을 외주화한다고 해서 그에 대한 책임이 면제되는 것은 아니라고 밝히고 있습니다.
NIS2 공급망 보안 조치가 여러분에게 요구하는 사항
이 조치는 NIS2가 정의한 두 가지 범주, 즉 해당 부문이나 서비스의 중요도와 조직의 규모에 따라 분류된 필수 및 중요 기관에 적용됩니다. 실제로 이는 일반적으로 해당 목록에 포함된 부문의 중견 및 대기업과 일부 소규모 기업을 의미하므로, 모든 기업이 이 조치의 적용을 받는 것은 아닙니다.
제21조 제2항은 사업체가 최소한 취해야 할 10가지 조치를 열거하고 있다. 그중 (d)항은 공급망 보안을 다룹니다. 여기에는 각 주체가 직접 공급업체 또는 서비스 제공업체와 맺고 있는 관계의 보안 측면이 포함됩니다. 이어 제21조 제3항은 해당 조치에 있어 고려해야 할 사항들을 구체적으로 명시하고 있습니다. 즉, 각 직접 공급업체 및 서비스 제공업체에 특정한 취약점, 공급업체의 제품 전반적 품질 및 사이버 보안 관행(안전한 개발 절차 포함), 그리고 핵심 공급망에 대한 유럽연합 차원의 조정된 위험 평가 결과 등이 포함됩니다.
이것이 지침에 명시된 공급망 보안 요건입니다. 지침은 기업이 아닌 회원국에 구속력을 가지므로, 이러한 규칙은 각국의 국내법을 통해 해당 기관에 적용됩니다. 또한 제21조 제1항은 위험에 적절하고 비례적인 조치를 요구하고 있으므로, 구체적인 방안의 일부는 귀하에게 맡겨져 있습니다.
NIS2 및 기타 여러 EU 문서들의 서문에서도 공급자에 대해 언급하고 있습니다. 이 중 유일하게 구속력을 갖는 것은 NIS2의 요구에 따라 유럽집행위원회가 채택한 규정인 ‘이행 규정 (EU) 2024/2690’입니다. 이 규정은 클라우드 및 관리형 서비스 제공업체와 같은 특정 디지털 서비스 제공업체를 대상으로, 공급자 정책을 포함하여 제21조에 대한 세부 규칙을 정하고 있습니다.
| 문서 | 공급업체에 대한 설명 | 적용 대상 | 결속? | 기초 |
|---|---|---|---|---|
| NIS2 (지침 (EU) 2022/2555), 제21조 제2항 (d)호 및 제21조 제3항 | 직접 공급업체와의 관계를 포함한 공급망 보안; 직접 공급업체의 취약점; 공급업체의 제품 품질, 사이버 보안 관행 및 보안 개발 절차 | 필수적이고 중요한 개체들 | 네, 국내법을 통해 | EU 지침 |
| NIS2, 서문 85항 | 소프트웨어 공급업체를 명시하고, 직접 공급업체와의 계약 조건을 권장하며, 그 외의 공급업체 단계도 고려할 수 있다 | 필수적이고 중요한 개체들 | 아니요 | 리사이틀, 해석을 돕는 수단 |
| 2024년 10월 17일자 집행위원회 이행규정 (EU) 2024/2690 | 직접 공급업체를 위한 공급망 보안 정책 및 선정 기준 | 클라우드 및 관리형 서비스 제공업체와 같은 나열된 디지털 엔티티 유형 | 네, 그런 유형의 경우라면요 | 시행령 |
| ENISA 기술 구현 지침, 버전 1.0, 2025년 6월 | 집행 규정에 대한 실용적인 조언 및 예시 증거 | 나열된 디지털 엔티티 유형; 타인에게 알릴 수 있음 | 아니요 | ENISA 지침 |
| EU ICT 공급망 보안 툴박스, 2026년 2월 | ICT 공급망 위험을 평가하고 완화하기 위한 일반적인 접근 방식 | 회원국 및 공공·민간 주체 | 아니요, 자발적인 | NIS 협력 그룹 지침 |
오픈소스 유지보수자는 직접 공급업체로 간주되지 않을 수 있다
NIS2의 제85조 서문은 소프트웨어 개발사를 위험 요인이 있는 공급업체 중 하나로 명시하고 있으며, 직접 공급업체를 넘어 더 넓은 범위를 검토하는 것을 사업체가 고려할 수 있는 사항으로 다루고 있다. 다만, 서문 자체만으로는 의무가 발생하지 않으며, 제21조에 명시된 공급업체 관계는 직접 공급업체와의 관계를 의미한다.
ENISA가 2026년 7월에 발표한 병원 및 의료 서비스 제공자의 사이버 보안을 위한 조달 지침은, 적어도 보건 분야에서는 오픈소스 유지보수자가 직접 공급자에 해당하는지 여부를 다루고 있다.
ENISA에 따르면: “무료 및 오픈소스 소프트웨어(OSS)의 경우, 소프트웨어를 공개적으로 유지 관리하고 배포하는 주체는 직접적인 서비스 제공자로 간주되지 않을 수 있다.”
지침에 따르면, 이는 표준 저작권 라이선스 이외에 해당 프로젝트와 계약 관계가 없거나, 오픈소스 소프트웨어 관리자와 계약을 체결한 경우에도 적용된다고 덧붙이고 있다. 이 용어는 별도의 법률인 ‘사이버 복원력법’에 정의되어 있으며, 제조업체를 제외한 법인으로, 특정 오픈소스 제품의 개발을 지속적으로 지원하는 주체를 의미한다.
이 지침은 구속력이 없으며 보건 분야 조달을 위해 작성된 것이므로, 국가 당국이 제21조를 어떻게 해석할지를 확정하는 것은 아닙니다. 이 지침은 지침의 문언과 일치하며, 지침 어디에도 기관이 오픈소스 프로젝트의 유지보수 담당자를 심사하도록 명시적으로 요구하고 있지 않습니다. 코드 자체가 초래하는 위험은 공급망 보안 조치의 대상은 아닐지라도, 여전히 귀하가 취해야 할 제21조 조치의 범위에 포함됩니다.
벤더는 제품 내에 오픈 소스를 포함하여 출하할 수 있고, 서비스 제공자는 이를 서비스의 일부로 제공할 수 있으며, 귀사의 개발자가 직접 개발하는 소프트웨어에 오픈 소스를 추가할 수도 있습니다. 벤더나 제공자는 일반적으로 귀사의 직접 공급업체이므로, 보안 개발을 포함한 제21조(3)항의 요건이 해당 업체에 적용됩니다. 귀사의 개발자가 직접 오픈 소스를 추가하는 경우에는 계약상 의미의 공급업체가 존재하지 않을 수 있습니다. 취약점 처리를 포함한 네트워크 및 정보 시스템의 취득, 개발, 유지보수 시 보안에 관한 제21조(2)(e)항은 공급망 보안 조치보다 해당 코드에 더 잘 부합합니다.
소프트웨어를 판매하는 경우, 고객이 문의하는 직접 공급업체가 될 수 있습니다. NIS2는 업종과 규모에 따라 조직을 대상으로 하므로, 단순히 누군가의 공급업체라는 사실만으로는 이 규정의 적용 대상이 되지는 않습니다. 귀사가 필수 또는 중요 기관에 해당할 경우, 귀사 자체적으로도 이행해야 할 의무가 있습니다. 귀사의 지위가 어떠하든, 고객은 자체적인 조치 과정에서 귀사가 제공하는 제품을 어떻게 개발하고 유지 관리하는지 문의할 수 있습니다.
설문조사가 끝나는 곳에서, 여러분이 직접 확인해야 할 부분이 시작됩니다
NIS2는 오픈 소스 패키지에 대한 구체적인 점검 사항을 규정하고 있지 않습니다. 아래의 점검 항목들은 제21조 제2항 (e)호 및 해당 조항의 취약점 처리 규정에 부합하는 실질적인 조치들입니다.
공급업체 검토가 효과적인 이유는 직접 물어볼 수 있기 때문입니다. 설문지를 보내고, 계약을 체결해 두면 공급업체는 답변할 이유가 생깁니다. 하지만 자사 개발자가 오픈소스를 도입할 때는, 라이선스 하에 코드를 공개했을 뿐 귀사에 대해 들어본 적조차 없을지도 모르는 유지보수자에게는 이러한 조건이 거의 적용되지 않습니다. 설문지만으로는 여러분이 실행하는 패키지가 유지보수자가 공개한 코드와 일치하는지 확인할 수 없으며, 설문지를 보낼 공급업체가 없기 때문에 해당 패키지가 여러분에게 전달되기 전에 이를 검토할 책임이 있는 사람도 대개 없습니다. 수정 사항 공개를 중단한 유지보수자는 보안 관련 질문에도 답변하지 않을 수 있습니다.
그러면 패키지 자체에 대한 검증이 남습니다. 공개된 소스 코드와 일치하는가? 악성 코드가 포함되어 있을 가능성은 없는가? 현재 사용 중인 버전에 대한 수정 작업이 여전히 진행되고 있는가? 팀이 직접 검사를 수행하든, 해당 서비스를 이용하든 간에 이러한 검증이 확실히 이루어지도록 해야 합니다.
또한 소프트웨어에 무엇이 포함되어 있고 각 구성 요소가 어디서 유래했는지에 대한 기록도 마련해 두어야 합니다. 목록으로 제시할 수 없는 구성 요소에 대해서는 공급업체가 제기하는 질문에 답변할 수 없기 때문입니다. 일반적으로 사용되는 기록으로는 소프트웨어 자재 명세서(SBOM) 와, 특정 아티팩트의 출처 및 구축 과정을 보여주는 출처 데이터가 있습니다. VEX(Vulnerability Exploitability eXchange) 명세서는 제품에 존재하는 알려진 취약점의 상태를 추가로 제공합니다. 각 기록의 신뢰성은 이를 작성한 주체에 따라 달라지므로, 누가 작성했는지와 마지막 업데이트 시점을 반드시 확인해야 합니다.
이사회는 제21조 조치를 승인하며, 이에 대한 책임을 질 수 있다
제20조 제1항에 따라, 회원국은 필수 및 중요 기관의 경영진이 제21조에 따른 조치를 승인하고, 그 이행 상황을 감독하며, 해당 기관이 제21조를 위반할 경우 책임을 질 수 있도록 보장해야 한다. 이 조항은 개별 구성원이 개인적으로 책임을 지는지 여부에 대해서는 명시하지 않는다. 개인에 대한 명시적인 규정은 제32조 제6항에 있다. 회원국은 필수 기관을 대표하거나, 의사 결정을 내리거나, 통제할 권한을 가진 자가 해당 기관의 규정 준수 의무를 위반한 경우 책임을 물을 수 있도록 해야 하며, 제33조 제5항은 이를 중요 기관으로 확대 적용한다.
교육도 중요합니다: 제20조 제2항에 따라, 경영진 구성원은 위험을 파악하고 사이버 보안 위험 관리 관행 및 이러한 관행이 해당 기관의 서비스에 미치는 영향을 평가하기 위한 교육을 이수해야 합니다.
계약된 공급업체만을 대상으로 작성된 조치를 승인하는 관리 기관이 정확히 그 범위만을 승인했습니다. 이 지침은 여전히 귀사의 개발자들이 추가하는 오픈 소스에서 비롯된 위험을 다루고 있습니다. 문제는 조치를 작성할 때 해당 위험이 공급망 보안 조치나 (e)항에 명시된 개발 조치 중 어느 쪽에도 명확히 귀속되지 않을 수 있으며, 공급업체 등록부를 검토하는 관리 기관이 이를 전혀 파악하지 못할 수도 있다는 점입니다. 해당 코드에 대한 검증을 어떤 조치가 다루는지, 그리고 누가 이를 수행하는지 조치 초안을 작성한 담당자에게 문의하십시오.
공급업체 평가와 실제 구축 간의 격차 해소
공급업체 계약이 없는 오픈 소스 코드의 경우, TuxCare의 SecureChain이 패키지 자체에 대해 이 세 가지 검사를 수행합니다. 이 솔루션은 오픈 소스 코드에서 숨겨진 악성코드를 탐지하고, 강화되고 격리된 환경에서 검사된 코드를 기반으로 오픈 소스 패키지를 재빌드하며, 검사에 실패한 항목은 사용자의 환경에 도달하기 전에 차단합니다. 활성 패키지는 서비스 수준 계약(SLA)에 따라 패치되며, 업스트림 유지보수가 종료된 후에도 ‘무한 수명 주기 지원(ELS) ’을 통해 지속적으로 수정 사항이 제공됩니다. 지원 범위는 JavaScript, Python, Java, Go, PHP를 아우르며, 빌드에는 SLSA(Supply-chain Levels for Software Artifacts) 레벨 3 출처 정보, SBOM 및 VEX 레코드가 포함됩니다.
빌드에 어떤 내용이 포함되었는지 파악할 수 없거나, 더 이상 유지보수되지 않는 패키지의 취약점 보고가 해결되지 않은 채 남아 있다면, SecureChain이 각 빌드를 어떻게 기록하고 해당 패키지에 패치를 적용하는지 확인해 보세요.
자주 묻는 질문
NIS2는 공급망 보안을 어떻게 다루고 있나요?
EU 사이버보안 지침인 NIS2는 제21조에서 공급망 보안을 10가지 최소 조치 중 하나로 명시하고 있습니다. 이 조치에는 해당 기관과 직접 공급업체 또는 서비스 제공업체 간의 관계에서 보안 측면이 포함됩니다. 제21조 제3항은 해당 기관이 각 직접 공급업체의 취약점뿐만 아니라 공급업체의 제품 품질 및 안전한 개발 절차도 종합적으로 평가할 것을 요구하고 있습니다.
누가 NIS2 공급망 조치를 준수해야 합니까?
필수적이고 중요한 기관. EU 사이버보안 지침인 NIS2는 해당 부문이나 서비스의 중요도와 조직의 규모를 기준으로 조직을 두 가지 범주로 분류합니다. 이 지침은 일반적으로 지정된 부문의 중견 및 대기업은 물론, 특정 기준을 충족하는 일부 소규모 조직까지 포함합니다.
NIS2는 공급업체에 의무를 부과하나요?
직접적으로는 아닙니다. EU 사이버보안 기관인 ENISA는 2026년 7월 발표한 병원용 조달 지침에서, NIS2가 정보통신기술(ICT) 공급업체에 직접적인 요건을 부과하지는 않는다고 밝혔습니다. 다만 NIS2의 적용을 받는 고객사는 자체 조치의 일환으로 공급업체에 보증 조치를 요청할 수 있습니다.
NIS2 공급망 보안에 관한 ENISA의 지침은 구속력을 갖는가?
아닙니다. EU 사이버보안 기관인 ENISA는 2025년 6월 발표한 ‘기술적 이행 지침’을 구속력이 없는 것으로 규정하고 있습니다. 이 지침은 클라우드 및 관리형 서비스 제공업체와 같은 지정된 디지털 사업체 유형을 다루는 유럽집행위원회 이행규정 (EU) 2024/2690을 뒷받침합니다. ENISA가 2026년 7월에 발표한 병원 조달 지침 역시 권고 사항입니다.
제21조 조치 위반 시 NIS2 과징금은 최대 얼마까지 부과될 수 있나요?
EU 사이버보안 지침인 NIS2 제34조에 따라, 회원국은 핵심 기관의 경우 최소 1,000만 유로 또는 전 세계 연간 총매출액의 2% 중 더 높은 금액을, 중요 기관의 경우 최소 700만 유로 또는 1.4% 중 더 높은 금액을 과태료 상한선으로 설정해야 합니다. 여기서 ‘매출액’이란 해당 기관이 속한 기업 전체의 직전 회계연도 실적을 의미합니다. 이 과징금은 제21조 또는 제23조의 사고 보고 규정을 위반한 경우에 적용되며, 구체적인 금액은 각국의 법률에 따라 정해집니다.
NIS2는 모든 EU 회원국에서 동일한 방식으로 적용되나요?
아닙니다. 의무 사항은 각 회원국의 국내법을 통해 기업에 적용되므로 세부 사항은 국가마다 다릅니다. 현재 많은 회원국에서 관련 법률이 시행 중이지만, 대부분은 2024년 10월이라는 법안 채택 기한을 지키지 못했습니다. 2026년 7월, 유럽집행위원회는 아일랜드, 스페인, 프랑스, 네덜란드가 법안의 완전한 이행을 통보하지 않았다는 이유로 이들 국가를 유럽연합 사법재판소에 제소했습니다. 귀사가 사업을 영위하는 각 국가의 관련 법률을 확인하시기 바랍니다.



