인사이트리포트

들어가며

오픈소스 소프트웨어(Open Source Software, 이하 OSS)는 디지털 산업의 성장을 이끄는 핵심 동력 중 하나로 자리 잡았다. OSS는 코드 공유와 협업을 통해 기술 혁신을 가속화하며, 비용 절감과 개발 효율성 향상이라는 명확한 장점을 제공해왔다. 많은 선도 기업들은 자체 제품과 서비스를 OSS 기반으로 구축하고 있으며, 클라우드, 빅데이터, 인공지능(AI) 등 ICT 주요 분야에서 OSS 기술은 사실상 표준으로 받아들여지고 있다.

그러나 개방성을 기반으로 하는 OSS의 특성은 동시에 위험을 내포하고 있다. 불분명한 출처, 낮은 유지보수 수준, 보안 취약점의 방치, 라이선스 위반 등은 OSS 도입의 이면에 존재하는 잠재적 위험들이다. 특히 누구나 기여할 수 있는 OSS의 개방성은 악성코드와 보안 취약점의 내재 가능성을 높이는 요인이다.

2021년 12월에 발생했던 Log4j 취약점은 OSS의 보안취약점, 소프트웨어 의존성에 대한 관리가 필요하다는 사실을 세상에 각인시켰다. Log4j 취약점으로 인해 OSS의 사용으로 인한 비용 절감이라는 장점에 가려진 보안 취약점, 소프트웨어 의존성이라는 리스크를 더 이상 외면할 수 없게 되었다.

OSS와 소프트웨어 공급망(Software Supply Chain) 리스크 관리를 위해 EO(Executive Order, 이하 EO) 14028, EU CRA(Cyber Resilience Act, 이하 CRA) 관련 법/규제들이 생겨나면서 소프트웨어 의존성 관리를 위한 SBOM(Software Bill of Materials, 이하 SBOM)의 의무화 또한 함께 진행되고 있다.

이러한 트렌드 이해하고 미리 대비하기 위해 OSS 리스크와 관련 규제를 알아보고자 한다.

OSS의 주요 리스크

OSS는 도입 단계에서부터 체계적인 리스크 관리가 반드시 수반되어야 한다. 그러려면 OSS사용 시 만나게 될 주요 리스크에 대한 분석이 우선적으로 필요하다. 다음은 OSS 사용 시 마주하게 될 주요 리스크이다.

OSS 리스크가 규제가 된 이유

초기 OSS 도입은 전적으로 기업의 자율적 판단에 맡겨졌으며, 컴플라이언스와 보안은 내부 관리 수준으로만 이루어졌다. 하지만 OSS 리스크로부터 파생된 소프트웨어 공급망 보안 사고가 증가하면서, 더 이상 단순한 선택의 문제가 아니게 되었다.

소프트웨어 공급망 복잡성, 잦아진 공격·취약점 사례, 법적·거버넌스 공백이 맞물려 OSS 리스크 관리를 법제화·규제화해야 한다는 필요성이 전 세계적으로 공감대를 얻어, 정부와 규제기관은 OSS를 포함한 전체 소프트웨어 공급망의 보안성 확보를 국가 사이버 보안 전략의 핵심 과제로 인식하기 시작했다.

국내외 OSS 주요 법과 표준의 시기별 변화 흐름을 살펴보면, 표준→가이드→법제화” 단계로 권고 수준 문서가 규제·인증 요건으로 상향되는 양상을 보이고 있다. 주요 키워드는 “보안 강화, SBOM 의무화, 역할·책임 명확화”이다.

아래 이미지는 시기별 트렌드를 정리한 내용이다.

• 시기별 흐름

• 주요 법과 표준 Timeline

• OSS 관련 주요 법과 표준 주요 내용

국내외 OSS 리스크 규제화의 핵심 배경은 소프트웨어 공급망 보안 사고의 증가와 생명주기 전반에 대한 관리 공백이 맞물린 데 있다. 소프트웨어 의존성으로 인한 취약점 한 개로 파생된 전체 소프트웨어 공급망 위협 및 OSS의 공개된 코드 특성을 악용한 대규모 보안 사고는 기업의 자율 관리만으론 해결되지 않았다. 이에, 공통의 규제 마련과 기업간 보안 수준 격차 해소를 위해 정부 부처에서 권고 수준의 표준·가이드를 ‘표준→가이드→법제화’ 순으로 강화한 것이다. 이것은 OSS 리스크 관리가 더 이상 보안을 위한 선택 사항이 아닌 필수 요소라는 의미로 해석할 수 있다.

SBOM을 중심으로 한 규제 트렌드

SBOM은 소프트웨어를 구성하는 OSS 및 서드파티 컴포넌트 목록을 구조화한 문서다. 식품 포장지의 영양 정보처럼, 최종 소프트웨어 패키지에 포함된 구성 요소들의 공급망을 투명하게 드러내 보안 취약점 추적과 라이선스 검증의 기초 자료로 활용된다.

• SBOM 정의:
  • Software Bill of Materials의 약어
  • 소프트웨어 제품을 구성하는 모든 구성 요소와 그 관계를 체계적으로 나열한 명세서
  • 미국 국립기술정보청(NTIA)은 아래와 같이 정의
  • “SBOM은 소프트웨어 자산 내 포함된 모든 구성 요소의 이름, 버전, 고유 식별자, 제조자 및 라이선스 정보를 기술한 구조화된 목록이다.”

• SBOM 주요 특징:
  • 컴포넌트명, 버전, 공급자, 해시값, 종속성 정보 포함
  • SPDX, CycloneDX 등 국제 표준 포맷 존재
  • 라이선스 컴플라이언스 검증, 소프트웨어 공급망 공격 대응, 감사규제 대응 등에서 활용

• SBOM 관련 규제:
  • 미국: EO 14028에서 연방 계약 시 SBOM 제출 의무화
  • EU: CRA(사이버복원력법)으로 디지털 제품 SBOM 관리 및 보안 이슈 대응 의무화
    1. 1. 대상: 디지털 요소(Digital Element)가 포함된 모든 제품의 제조수입·유통업체
       2. 제출시점: 제품 출시 전 기술문서 완비, 시장감시 당국 요청이 있을 경우 제출
       3. 제출범위: 컴포넌트명버전·공급자·해시·라이선스·종속성 정보 포함
       4. 공개: SBOM 공개 의무는 없음, SBOM 자체에 기밀보호 라이선스 적용가능
  • 국내: 공공 소프트웨어 사업 및 금융권 중심으로 SBOM 권고 → 확대 예상

SBOM은 단순한 문서가 아니라, 소프트웨어 구성의 신뢰성과 보안성을 보장하는 요소로서, 향후 OSS 및 소프트웨어 공급망 전반의 보안 인증과 연계될 전망이다. 이에 따라 기업은 글로벌 표준 준수, PoC 참여, 내부 정책 수립·자동화 도구 도입을 통해 SBOM 관련 규제에 대한 선제적 준비가 필요하다.

기업이 준비해야 될 것들

기업이 OSS와 SBOM 관련 규제를 준수하면서 안전하게 사용하기 위해 준비해야 하는 것은 아래와 같다.

준비 항목의 체계적 이행을 위한 OSS 관리 프레임워크 목표 모델은 아래와 같다. Lv0 → Lv5로 갈 수록 OSS 관리 성숙도가 높다고 평가할 수 있다.

[에스코어가 제시하는 OSS 관리 프레임워크 목표 모델]

다음은 각 단계에 대한 설명이다.

Lv0은 OSS 사용 및 활용하는 단계로, 인프라 및 서비스를 OSS로 구축하여 사용하는 단계이다.

Lv1은 OSS를 관리하기 위한 시스템들을 도입하여 사용하는 단계이다. OSS를 관리하기 위한 시스템은 OSS 점검도구, 저장소, SBOM 관리도구, EOS 관리 도구 등이 있다.

Lv2는 OSS를 내부 시스템과 연계하여 활용하는 단계이다. 연계 도구들을 내부/외부로 나뉘고, 외부 연계 도구는 Repository, 점검도구 Knownalge DB, 망연계 등이있다. 내부 연계는 인증, 인사정보, 결재시스템, 품질관리, 자원관리, 알림등을 연계하여 사용할 수 있다.

Lv3은 OSS 관리 포털을 구축하여 OSS를 관리하는 단계이다. OSS 관리 포털의 주요 목적은 OSS를 안전하게 사용할 수 있도록, 리스크를 관리하는 것에 있다.

Lv4는 OSS 관리를 위한 거버넌스 체계 구축 단계이다. 전담인력이나 전담 조직을 구성하여 정책과 프로세스를 수립하여 OSS 리스크 관리 프레임워크를 임직원에게 내재화 할 수 있도록 교육까지 수행하는 단계이다.

Lv5는 OSS를 안전하게 사용하기 위한 모든 체계가 구축이 되어, 안전하게 사용하고 있는 관리 체계를 인증하는 단계이다.

기업은 해당 모델을 기반으로 현행 OSS 관리 체계를 진단하여 단계별 성숙도를 평가하고, 이를 바탕으로 실행 전략을 수립해야 한다. 단기적으로는 OSS 관리 도구를 도입해 자동화와 효율성을 강화하고, 중장기적으로는 개발·운영·보안 전 부문에 OSS 관리 체계를 구축한 뒤 전담 인력을 배치해 체계에 대한 내재화가 필요하다. 이 모든 과정을 원활히 진행하기 위해서는 CISO, 보안팀, 법무팀, 개발 부서 간 긴밀한 협업이 반드시 필요하다.

국내 산업별 리스크 및 규제

국내의 규제 및 가이드는 공통적으로 산업별 주관 부처에서 별도의 가이드를 제공하고 있다. 기업이 어떤 도메인에서 활동하느냐에 따라 규제 환경이 다르므로 산업별 리스크 및 규제를 분석하여 그에 맞는 대응 전략 수립이 필요하다.

아래 표는 산업별 리스크와 규제, 그에 따른 대응 전략 예시이다.

금융·의료는 개인/민감정보를 다루는 분야의 특성상 규제 강도가 높고, OSS 활용 시 신뢰성과 책임 소재 확보를 중요시 하고 있다. 그 외 산업은 보안 취약점 및 SBOM을 중심으로 한 OSS관리를 권고하고 있으나, OSS 리스크로 파생되는 보안 사고 사례가 발생함에 따라 권고에 머무르지 않고 규제/법령으로 확산될 전망이다.

마치며

OSS는 기술 발전과 혁신의 원동력으로 자리 잡았으며, 이에 따른 법적·보안적 리스크에 대한 인식이 중요해지고 있다. 이러한 배경 속에서 주요 국가들은 OSS의 신뢰성과 투명성을 확보하기 위해 규제 리스트와 제도적 장치를 마련하고 있다.

특히, OSS에 대한 규제는 단순한 제한이 아니라 소프트웨어 공급망 내의 보안성과 책임을 강화하고 지속 가능한 생태계를 조성하기 위한 방향으로 작용한다. 궁극적으로 OSS 관련 법과 규제는 자유로운 기술 활용을 보장하면서도 책임 있는 관리의 균형을 추구하는 제도적 기반이 된다.

따라서 기업들은 OSS를 활용함에 있어 법적·기술적 위험을 사전에 검토하고, 효과적인 내부 거버넌스 체계를 구축하는 노력이 필요하다. 특히, 주 시장이 미국과 EU인 의료·제조 관련 기업은 SBOM 제출에 대한 규제와 의무에 대해 적극적인 대비가 필요하다. 따라서, 관련 규제에 대응해야 하는 기업 담당자는 오픈소스 뿐만 아니라 소프트웨어 공급망 관련 입법 동향을 지속 확인하고 적시에 대응할 수 있도록 해야 한다.