단일 레지스트리로 CRA, FedRAMP, NIS 2 및 PCI DSS에 대한 증거를 지원합니다

주요 내용

• CRA, FedRAMP, NIS 2 및 PCI DSS는 오픈 소스 구성 요소에 대해 다음과 같은 두 가지 동일한 질문을 제기합니다. 즉, 무엇을 배포하는지, 그리고 취약점이 발견되면 어떻게 대응하는지입니다.
• 이들 규정은 적용 기간(PCI DSS는 패치 출시일로부터, FedRAMP는 평가일로부터 계산하며, CRA와 NIS 2는 구체적인 기간을 정하지 않음), 기록을 검토하는 주체, 그리고 기록 보관 기간(CRA만이 최소 10년이라는 기간을 명시하고 있음)에 있어 차이가 있습니다.
• 이 중 어느 것도 구성 요소의 출처를 어떻게 파악해야 하는지, 또는 유지보수자가 작업을 중단한 후 누가 수정 사항을 제공할지에 대해서는 언급하지 않습니다.
• SecureChain은 이 두 가지 요구 사항을 모두 충족합니다. 패키지는 검증을 거치고, 소스 코드에서 재컴파일되며, SLA에 따라 패치가 적용된 후, 출처 정보, SBOM 및 VEX 명세서와 함께 제공됩니다.

‘사이버 복원력법(CRA)’, ‘연방 위험 및 승인 관리 프로그램(FedRAMP)’, ‘NIS 2’, 그리고 ‘지불 카드 산업 데이터 보안 표준(PCI DSS)’은 각각 소프트웨어 공급망 규정 준수 증빙 자료 그 이상을 다루고 있으며, 각 규정은 제품 내부의 오픈 소스 패키지까지 파고들 수 있는 질문들을 제기합니다. 이 중 한 가지 요구사항에는 이미 구체적인 기한이 정해져 있습니다. PCI DSS는 2025년 3월 31일부터 제3자 구성 요소 목록 제출을 의무화하고 있습니다.

EU 내에서 제품을 판매하고, NIS 2 대상 기업에 서비스를 제공하며, 연방 정부용 클라우드 서비스를 운영하고, 카드 소지자 데이터를 취급하는 가상의 회사를 가정해 보자. 하나의 오픈소스 패키지 하나만으로도 시장 감독 당국, NIS 2 고객사, 연방 기관, 결제 평가 기관으로부터 의문을 제기받을 수 있다. 그 패키지는 어디서 유래한 것이며, 유지보수자가 지원을 중단하면 누가 패치를 적용할 것인가?

이 네 가지 문서는 내용이 중복되지만, 누가 무엇을, 누구에게, 얼마나 오랫동안 공개하는지에 대해서는 차이가 있습니다. 제목에 언급된 레지스트리는 TuxCare의 SecureChain으로, 선별된 저장소를 통해 오픈소스 패키지를 제공합니다.

각 문서의 대상 독자

각 문서마다 대상 주체에 대해 고유한 용어를 사용하며, 이러한 용어들은 다른 문서로 이어지지 않습니다. CRA는 제조업체를 대상으로 하는데, 제3조(13)항에서는 제조업체를 디지털 요소가 포함된 제품을 개발하거나 제조하거나, 이를 위탁 제조하여 자사의 이름이나 상표로 판매하는 사람으로 정의하고 있습니다. FedRAMP의 플레이북은 보안 통제에 대한 주된 책임을 클라우드 서비스 제공자에게 부여하며, 2026년 규칙에서는 “제공자”라고 명시하고 있습니다. 이 플레이북은 Rev. 5 절차를 설명하고 있으며, FedRAMP는 2026년 규정으로 전환하는 동안 참고용으로 기존 사이트에 이를 게시하고 있다. NIS 2는 필수 및 중요 기관을 대상으로 하며, 제2조와 제3조에서는 주로 업종과 규모에 따라 이를 정의하고 있습니다. PCI DSS는 카드 소지자 데이터를 저장, 처리 또는 전송하거나 해당 데이터의 보안에 영향을 미칠 수 있는 기관에 적용됩니다. 여기에는 결제 브랜드를 제외한 기관으로서, 다른 기관을 대신하여 카드 소지자 데이터를 처리, 저장 또는 전송하거나, 카드 소지자 데이터 환경의 보안에 영향을 미칠 수 있는 서비스를 제공하는 서비스 제공업체가 포함됩니다.

한 기업이 CRA에 따른 제조업체이자 FedRAMP에 따른 클라우드 서비스 제공업체인 등, 이러한 역할을 동시에 여러 개 수행할 수 있으므로, 해당 기업의 역할에 따라 어떤 문서의 질문이 적용되는지가 결정됩니다. 소프트웨어 공급망 규정 준수를 입증하기 위해 제시해야 할 자료는 문서마다 명칭이 다릅니다. CRA는 기술 문서를 요구하고, FedRAMP의 플레이북은 결과물과 증빙 자료를 요구하며, NIS 2는 구현 증거를 요구하고, PCI DSS는 평가자가 문서를 검토할 것을 요구합니다.

참고: PCI DSS v4.0.1은 누가 규정을 준수해야 하거나 규정 준수 여부를 검증해야 하는지에 대한 결정 권한을 결제 브랜드, 가맹점 결제 대행사 및 규정 준수 프로그램을 관리하는 기타 기관에 위임하고 있습니다(제2절).

각각이 타사 구성 요소에 대해 묻는 질문

소프트웨어의 구성 요소는 문서마다 서로 다른 명칭으로 지칭됩니다. CRA는 오픈 소스 구성 요소를 명시적으로 언급합니다. NIS 2는 직접 공급업체와 서비스 제공업체에 대해 다룹니다. 오픈 소스나 소프트웨어 BOM(자재 명세서)에 대해서는 언급하지 않는 FedRAMP 플레이북은 자산 목록과 취약점을 다루며, PCI DSS는 맞춤형 및 주문 제작 소프트웨어 내의 제3자 구성 요소를 식별합니다.

참고: 제13조 제5항은 무료 및 오픈 소스 구성 요소가 상업적 활동의 일환으로 제공되지 않은 경우에도 이에 대해 적정 주의 의무를 적용합니다.

소프트웨어 공급망 규정 준수 증빙 자료가 중복되는 부분과 그렇지 않은 부분

두 질문의 내용은 일부 중복됩니다. 하나는 어떤 구성 요소를 출하하는지에 관한 것입니다. CRA, 플레이북, PCI DSS는 각각 어떤 형태로든 자산 목록을 요구합니다. NIS 2는 제21조(2)(i)의 조치 항목 중 하나로 자산 관리를 열거하고 공급업체에 대해 묻고 있으나, 제21조 자체에는 구성 요소 목록이 명시되어 있지 않습니다. 다른 하나는 취약점이 발견된 후 어떻게 처리해야 하는지이며, 네 가지 문서 모두 이 문제를 다루고 있습니다. CRA에 따르면, 취약점 시정은 지체 없이 이루어져야 합니다(부속서 I, 제2부(2)). NIS 2는 취약점 처리 및 공개를 규정하고 있습니다(제21조(2)(e)). PCI DSS는 중대한 취약점에 대한 패치 배포 기한을 공개일로부터 1개월로 정하고 있으며(6.3.3), FedRAMP의 2026년 규정에서는 평가 후 192일이 지나도 여전히 해결되지 않은 모든 취약점에 ‘승인된 취약점’ 라벨을 부여합니다(VER-TFR-MAV).

차이는 시점에서부터 시작됩니다. PCI DSS는 패치 출시 시점을 기준으로 계산하고, FedRAMP는 평가 시점을 기준으로 계산하는 반면, CRA와 NIS 2는 여기서 인용된 조항에서 구체적인 기간을 명시하지 않습니다. 또한, 어떤 자료를 언제, 누구에게 제시해야 하는지에 대해서도 차이가 있습니다. 시장 감시 당국은 CRA 기술 문서를 열람할 수 있으며, 기관들은 FedRAMP의 월별 제출물을 검토하고, 관할 당국은 NIS 2 대상 기관에 증거 제출을 요청할 수 있으며, PCI DSS 평가자는 해당 기관의 문서를 확인합니다. 특정 문서의 시점과 검토 주체를 기준으로 작성된 기록이 다른 문서의 기준에도 부합한다고 가정해서는 안 됩니다.

문서에서 판단을 맡긴 부분

이 네 가지 문서 모두 문제점을 제시하고 구체적인 방법론에 대해서는 상당 부분 열어두고 있습니다. CRA는 제조업체가 위험 수준에 상응하는 방식으로 제품의 사이버 보안 관련 사항을 문서화할 것을 요구하며(제13조 제7항), NIS 2는 적절하고 비례적인 조치를 요구합니다(제21조 제1항). PCI DSS는 중대한 취약점에 해당하지 않는 기타 적용 가능한 패치의 적용 시기를 해당 기관의 자체 위험 평가에 맡기고 있으며(6.3.3), FedRAMP의 탐지 규칙은 적절한 기법을 요구하고 있습니다(VDR-CSO-DET).

지금까지 인용한 조항들에는 두 가지 의문이 남아 있습니다. 첫 번째는 구성 요소의 출처입니다. CRA 제13조 제5항은 제3자 구성 요소가 제품의 보안을 훼손하지 않도록 실사를 요구하고 있으며, NIS 2 제21조 제3항은 사업자가 공급업체의 보안 개발 절차를 평가할 것을 요구합니다. 구속력이 없는 NIS 2의 서문 85항은 공격자가 제3자 제품 및 서비스의 취약점을 악용하여 기관을 침해하는 사례를 설명하고 있습니다. 두 조항 모두 구성 요소가 주장하는 출처와 일치하는지, 또는 악성 코드가 포함되어 있지 않은지 확인하는 방법에 대해서는 설명하고 있지 않습니다.

두 번째는 수정 프로그램의 출처입니다. PCI DSS 6.3.3은 패치 출시일로부터 1개월을 기준으로 삼으므로, 누군가가 패치를 출시했다고 가정합니다. CRA는 보안 업데이트 제공 의무를 제조업체에 부과하며(부속서 I, 제2부(2)), 제13조(8)항은 제품의 구성 요소에 존재하는 취약점을 CRA 지원 기간 전체에 걸쳐 적용 범위에 포함시킵니다. FedRAMP 개정판 5의 지속적인 모니터링 주기에 따르면, 상류에서 수정 프로그램이 제공되지 않는 발견 사항은 공급업체 의존 사항으로 월간 POA&M에 계속 남아 있습니다. 여러 기관 고객을 보유한 공급업체의 경우, 플레이북은 월간 협업 회의에서 기한이 지난 항목과 공급업체 의존 사항을 중점적으로 다룰 것을 지시합니다(제7절). 이러한 규정 중 어느 것도 유지 관리자가 수정 프로그램 제공을 중단한 후 수정 프로그램 자체가 어디서 제공되어야 하는지에 대해서는 명시하고 있지 않습니다.

오픈 소스 소프트웨어를 위한 SecureChain의 적용 분야

TuxCare의 SecureChain은 오픈소스 패키지의 소스 코드를 검사하여 숨겨진 악성코드를 탐지하고, 검사된 코드를 바탕으로 격리된 환경에서 패키지를 재빌드합니다. 검사에서 불합격된 패키지는 고객 환경에 도달하기 전에 차단되며, 나머지 패키지는 엄선된 저장소를 통해 제공됩니다.

각 패키지에는 출처 정보(SLSA 레벨 3 기준에 따라 빌드 과정을 기록한 서명된 기록), SBOM, VEX 명세서, 그리고 앞서 언급된 문서에서 요구하는 출처 및 수정 상태 기록이 포함되어 제공됩니다.

SecureChain은 서비스 수준 계약 ( SLA ) 에 따라 활성 구성 요소에 대한 패치를 제공하며, 업스트림에서 더 이상 유지보수되지 않는 버전의 경우, ‘무한 수명 주기 지원(ELS) ’을 통해 중대, 높음, 중간, 낮음 위험 등급의 취약점에 대한 수정 사항을 약속된 일정에 따라 사용 중인 버전으로 역포트합니다. SecureChain은 JavaScript, Python, Java, Go 및 PHP의 오픈 소스 패키지를 지원합니다.

아직 구성 요소의 출처를 파악하지 못했거나, 업스트림 지원이 중단된 후 누가 패치를 제공하는지 알 수 없다면, ‘오픈 소스 소프트웨어용 SecureChain’이 이 두 가지 문제를 어떻게 해결하는지 확인해 보세요.

자주 묻는 질문

CRA, FedRAMP, NIS 2 및 PCI DSS는 ‘증거(Evidence)’라는 용어를 어떻게 사용하고 있나요?

이 네 가지 모두 각기 다른 의미에서 이를 사용합니다. ‘사이버 복원력법(Cyber Resilience Act)’의 부속서 VII에는 기술 문서에 취약점 보고 연락처 주소가 명시되어 있음을 입증하는 증거가 나열되어 있습니다. NIS 2 제32조 및 제33조는 당국이 이행 증거를 요청할 수 있도록 허용하고 있습니다. 연방 위험 및 승인 관리 프로그램(FRAMP) 플레이북에는 뒷받침하는 증거에 대해 언급되어 있으며, 결제 카드 산업 데이터 보안 표준(PCI DSS)에서는 평가자가 문서를 검토하고 담당자와 면담하도록 규정하고 있습니다(6.3.2.a, 6.3.2.b).

CRA 기술 문서는 얼마나 오래 보관해야 합니까?

‘사이버 복원력법(CRA)’ 제13조 제13항에 따라, 제조업체는 제품을 시장에 출시한 후 최소 10년 동안, 또는 지원 기간이 더 긴 경우에는 해당 기간 동안 기술 문서를 시장 감시 당국이 열람할 수 있도록 보관해야 합니다. 부속서 VII에는 해당되는 경우 소프트웨어 부품 명세서를 포함하여 기술 문서의 구성 요소가 명시되어 있습니다.

CRA와 NIS 2는 어떤 과태료를 부과하나요?

‘사이버 복원력법’ 제64조 제2항은 부속서 I 및 제13조와 제14조를 위반할 경우, 최대 15,000,000유로 또는 직전 회계연도의 전 세계 연간 총매출액의 2.5%에 해당하는 과태료를 부과하도록 규정하고 있습니다. NIS 2 제34조는 회원국들이 필수 기관의 경우 최소 10,000,000유로 또는 매출액의 2%, 중요 기관의 경우 7,000,000유로 또는 매출액의 1.4%를 상한선으로 설정할 것을 요구하고 있습니다. 모든 경우에 있어 더 높은 금액이 적용됩니다.

NIS 2는 소프트웨어 공급업체에 어떻게 적용되나요?

NIS 2는 필수 및 중요 기관에 의무를 부과하므로, 공급업체는 대개 고객을 통해 파악됩니다. 제21조 제2항 (d)호 및 제21조 제3항은 해당 기관이 각 직접 공급업체의 취약점을 평가하고 개발 절차를 안전하게 마련할 것을 요구합니다. 공급업체 자체가 필수 또는 중요 기관인 경우, 회원국 법률에 따라 그 자체로 이 지침의 적용을 받습니다.

PCI DSS에서는 언제 제3자 구성 요소 목록 작성을 요구하나요?

업계 표준인 ‘지불 카드 산업 데이터 보안 표준(PCI DSS)’ v4.0.1의 요구사항 6.3.2는 맞춤형 및 주문 제작 소프트웨어에 통합된 제3자 구성 요소를 다룹니다. 이 요구사항은 2025년 3월 31일까지는 권장 사항이었으나, 그 이후부터는 필수 사항이 됩니다. 해당 기관이 유효성 검증을 수행해야 하는지 여부는 결제 브랜드, 가맹점 결제 대행사 및 기타 규정 준수 프로그램을 운영하는 기관의 재량에 맡겨집니다.

요약

기사 이름

다양한 프레임워크에 걸친 소프트웨어 공급망 규정 준수 증빙 자료

설명

CRA, FedRAMP, NIS 2 및 PCI DSS에 따라 소프트웨어 공급망 규정 준수 입증 요건은 서로 다릅니다. 각 규정이 무엇을 요구하고, 어떤 부분은 명확히 규정하지 않는지 확인해 보세요.

작성자

아르템 카라세프

게시자 이름

TuxCare

게시자 로고