들어가며
안녕하세요!
오늘은 오픈소스 소프트웨어(Open Source Software, OSS)의 최신 법과 규제 동향, 그리고 SBOM에 대해 알아보려고 해요
오픈소스 소프트웨어는 디지털 산업의 성장을 이끄는 핵심 동력 중 하나로 자리 잡았습니다.
OSS는 코드 공유와 협업을 통해 기술 혁신을 가속화하며, 비용 절감과 개발 효율성 향상이라는 명확한 장점을 제공해왔어요.
많은 선도 기업들은 자체 제품과 서비스를 OSS 기반으로 구축하고 있으며, 클라우드, 빅데이터, 인공지능(AI) 등 ICT 주요 분야에서 OSS 기술은 사실상 표준으로 받아들여지고 있답니다.
하지만 개방성을 기반으로 하는 OSS의 특성은 동시에 위험을 내포하고 있어요.
불분명한 출처, 낮은 유지보수 수준, 보안 취약점의 방치, 라이선스 위반 등은 OSS 도입의 이면에 존재하는 잠재적 위험들이에요
특히 누구나 기여할 수 있는 OSS의 개방성은 악성코드와 보안 취약점의 내재 가능성을 높이는 요인이기도 합니다.
2021년 12월에 발생했던 Log4j 취약점 기억나시나요?
기억나시나요?이 사건은 OSS의 보안취약점과 소프트웨어 의존성에 대한 관리가 필요하다는 사실을 세상에 각인시켰어요.
Log4j 취약점으로 인해 OSS의 사용으로 인한 비용 절감이라는 장점에 가려진 보안 취약점, 소프트웨어 의존성이라는 리스크를 더 이상 외면할 수 없게 되었습니다.
OSS와 소프트웨어 공급망(Software Supply Chain) 리스크 관리를 위해 EO(Executive Order) 14028, EU CRA(Cyber Resilience Act) 관련 법/규제들이 생겨나면서 소프트웨어 의존성 관리를 위한 SBOM(Software Bill of Materials)의 의무화 또한 함께 진행되고 있어요.
이러한 트렌드를 이해하고 미리 대비하기 위해 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.
대상: 디지털 요소(Digital Element)가 포함된 모든 제품의 제조수입·유통업체
2.
제출시점: 제품 출시 전 기술문서 완비, 시장감시 당국 요청이 있을 경우 제출
3.
제출범위: 컴포넌트명버전·공급자·해시·라이선스·종속성 정보 포함
4.
공개: SBOM 공개 의무는 없음, SBOM 자체에 기밀보호 라이선스 적용 가능
국내: 공공 소프트웨어 사업 및 금융권 중심으로 SBOM 권고 → 확대 예상SBOM은 단순한 문서가 아니라, 소프트웨어 구성의 신뢰성과 보안성을 보장하는 요소로서, 향후 OSS 및 소프트웨어 공급망 전반의 보안 인증과 연계될 전망이에요.
이에 따라 기업은 글로벌 표준 준수, PoC 참여, 내부 정책 수립·자동화 도구 도입을 통해 SBOM 관련 규제에 대한 선제적 준비가 필요합니다
더 자세한 내용이 궁금하다면?
이어서 '기업이 준비해야 될 것들’과 '국내 산업별 리스크 및 규제'를 확인하려면 아래 링크에서 확인해주세요!
참고 자료
https://owasp.org/www-project-open-source-software-top-10/ https://github.com/OpenChain-Project/License-Compliance-Specification/blob/master/ISO-5230-2020/en/ISO-5230-2020.md https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity https://www.fsec.or.kr/bbs/detail?menuNo=222&bbsNo=11166 https://www.congress.gov/bill/118th-congress/senate-bill/917/text https://github.com/OpenChain-Project/Security-Assurance-Specification/blob/main/Security-Assurance-Specification/ISO-18974/en/ISO-18974.md https://www.nipa.kr/home/2-1/15458 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847 https://mfds.go.kr/brd/m_1060/down.do?brd_id=data0011&seq=15655&data_tp=A&file_seq=2
이윤정 프로
오픈소스 거버넌스 컨설팅 업무를 맡고 있으며, 삼성 관계사를 포함한 국내 주요 기업들을 대상으로 다수 프로젝트를 진행하고 있어요