요약

  • CRA는 특정 제품이 어떻게 공급되고 누가 지속해서 지원하는지 본다. Barry O’Donovan은 같은 조직이 무료판에서는 오픈소스 소프트웨어 관리 주체(open-source software steward), 유료판에서는 제조업체일 수 있다고 설명했다.
  • 비영리라는 표지만으로는 역할이 정해지지 않는다. 운영자는 제품별 자산 목록, 취약점 연락처, 패치 경로를 계속 관리해야 한다.

한 프로젝트가 오픈소스 코드를 무료로 공개하면서 기능이 더 많은 버전을 판매할 수 있다. CRA는 두 제품에 서로 다른 역할을 부여할 수 있다. Barry O’Donovan의 실무적 해석은 간단하다. 역할은 조직 이름이 아니라 제품을 따라간다.

O’Donovan은 INEX에서 IXP Manager 개발을 이끈다. RIPE 93의 소프트웨어 공급망 발표에서 그는 운영자가 확인해야 할 질문을 던졌다. 인터넷 교환 지점이나 네트워크가 오픈소스에 의존한다면, 그 프로젝트에 어떤 보안 작업을 기대할 수 있을까?

유럽위원회의 현행 안내는 제조업체와 오픈소스 소프트웨어 관리 주체를 구분한다. 오픈소스 제품을 시장에 내놓는 제조업체에는 제조업체 의무가 적용된다. 제품을 시장에 공급하지 않지만 상업 활동을 목적으로 한 특정 오픈소스 제품을 지속적이고 체계적으로 지원하고, 그 존속에 핵심 역할을 하는 법인은 관리 주체에 해당할 수 있다. 이 역할에는 사이버보안 정책, 취약점 처리, 시장감독기관과의 협력이 포함된다.

O’Donovan은 무료 오픈소스판과 추가 기능을 유료로 파는 판을 함께 운영하는 익숙한 사례를 들었다. 그의 설명대로라면 한 조직이 무료 제품의 관리 주체이자 유료 제품의 제조업체일 수 있다. 유럽위원회도 구체적인 제품과 공급 방식을 기준으로 설명한다. 재단이나 기업, 개발팀 전체에 CRA 표지를 하나 붙이는 것보다 제품별로 판단하는 편이 현실을 더 잘 보여준다.

법은 성급한 추론도 막는다. 기업 자금을 받거나 외부 기여를 수용하거나 정기적으로 새 버전을 내놓는 것만으로 소프트웨어가 상업 활동이 되지는 않는다. 비영리 조직이 비용을 뺀 수익 전부를 비영리 목적에 쓰도록 운영된다면 그 조직의 오픈소스 개발도 상업 활동으로 보지 않는다고 규정은 설명한다. 가격, 제품에 대한 책임, 지속적인 지원, 상업적 사용 의도를 함께 따져야 한다.

O’Donovan은 IXP Manager를 사례로 들었다. INEX는 이 프로젝트가 오픈소스 관리 주체에 해당한다고 판단했고, 다른 교환 지점이 공급망 자료를 요청한 뒤 안전한 개발 정책과 취약점 공개 정책을 내놓았다고 말했다. 그는 INEX가 비영리 조직이지만 교환 포트 요금을 받는다는 점도 설명했다. 이는 INEX의 운영상 해석이며, 규제기관이 IXP Manager를 분류한 결정은 아니다. 공개 기준은 여전히 제품과 조직의 실제 역할을 따진다.

NIS2 적용 대상 운영자는 자체 공급망 관리도 계속해야 한다. 제21조는 공급자 보안과 시스템의 구매·개발·유지보수를 다루며, 취약점 처리와 공개도 포함한다. O’Donovan은 소프트웨어 목록을 만들고, 취약점을 추적하고, 제때 패치하는 정책을 두라고 권했다.

질의응답에서 그는 명확한 사례와 법원 판단까지 이어질 회색지대가 있다고 내다봤다. 운영자는 각 의존 제품에 대해 누가 버전을 관리하고, 누가 신고를 받고, 누가 수정판을 낼 수 있으며, 어느 에디션을 쓰는지 확인해야 한다. 수익 모델이 달라지면 법적 역할도 바뀔 수 있다. 조직 이름만 적은 자산 목록으로는 이 변화를 잡지 못한다.

출처

RIPE 93 녹취록 · RIPE 93 세션 · 유럽위원회: CRA와 오픈소스 · 규정 (EU) 2024/2847 · NIS2 지침 · INEX 소개