블랙덕 제병주 부장이 오픈소스가 일부 개발 조직의 선택지를 넘어 기업 소프트웨어 개발의 기본 구성 요소가 됐다고 강조했다.

[디지털데일리 이상일기자] 블랙덕(Black Duck)과 케이엠에스테크놀로지(KMS Technology)가 공동 주최한 웨비나에서 기업이 오픈소스 취약점과 라이선스 리스크, 유지보수 중단 컴포넌트, 소프트웨어 자재명세서(SBOM·Software Bill of Materials) 대응 과제를 어떻게 관리해야 하는지 다뤄졌다.

9일 '2026 오픈소스 보안·위험 분석(OSSRA·Open Source Security and Risk Analysis) 리포트로 보는 오픈소스 보안 리스크와 대응 전략'을 주제로 <디지털데일리> 웨비나 플랫폼 'DD튜브'에서 진행된 웨비나에서 블랙덕 제병주 부장은 오픈소스가 일부 개발 조직의 선택지를 넘어 기업 소프트웨어 개발의 기본 구성 요소가 됐다고 강조했다.

제 부장은 "어떤 오픈소스가 사용되고 있는지, 취약점이나 라이선스 리스크가 비즈니스에 어떤 영향을 줄 수 있는지 체계적으로 점검하고 대응하는 것이 중요해지고 있다"고 말했다.

OSSRA 리포트는 블랙덕이 매년 수행하는 오픈소스 감사 결과를 토대로 작성된다. 이번 분석은 인수합병(M&A) 과정의 오픈소스 실사와 코드베이스 검토 결과를 기반으로 했다. 제 부장은 "오픈소스가 포함된 코드베이스는 98% 수준으로 사실상 대부분의 소프트웨어 프로젝트가 오픈소스를 사용한다"고 설명했다. 복잡성이 증가하면서 코드베이스당 평균 취약점 수도 전년보다 크게 늘었다고 지적했다.

발표 자료에 따르면 코드베이스당 오픈소스 취약점은 전년보다 107% 증가해 평균 581건에 달했다. 고위험 취약점 포함 코드베이스 비율은 78%였다. 매니페스트 파일 없이 외부에서 직접 유입된 컴포넌트는 16%, 라이선스 충돌이 있는 코드베이스는 68%였다. 4년 이상 노후화된 컴포넌트를 포함한 코드베이스는 92%, 2년 이상 유지보수가 중단된 이른바 '좀비 컴포넌트' 포함 코드베이스는 93%에 달했다.

제 부장은 AI 도입이 오픈소스 리스크 양상을 바꾸고 있다고 진단했다. 그는 "AI가 생성한 코드로 인해 보안 취약점과 라이선스 문제가 더 많이 발생하고 있다"며 "소프트웨어 구성 분석(SCA·Software Composition Analysis)으로 사용 중인 오픈소스와 취약점을 지속 관리해야 한다"고 말했다.

KMS테크놀로지 전솔 매니저는 OSSRA 리포트의 글로벌 지표가 국내 기업 환경에서는 산업별로 다른 위험 형태로 나타난다고 설명했다.

이어 발표에 나선 KMS테크놀로지 전솔 매니저는 OSSRA 리포트의 글로벌 지표가 국내 기업 환경에서는 산업별로 다른 위험 형태로 나타난다고 설명했다.

대기업과 금융권은 규제 준수, 전이 의존성에 따른 공급망 취약점, 평판·과징금 리스크가 과제로 지목됐다. IT 스타트업과 테크 기업은 AI 코딩 도구 확산에 따른 라이선스 세탁, 지식재산권(IP) 소송, 투자·M&A 실사 리스크가 부각됐다. 전통 제조업과 시스템통합(SI) 기업은 레거시 시스템 장기 운용, 외주 산출물 검증 미흡이 핵심 위험으로 제시됐다.

전 매니저는 "AI가 가져온 개발 속도 이면에 사상 최대 규모의 보안 취약점과 라이선스 위협이 숨어 있다"며 "AI 생성 코드까지 포함한 소프트웨어 공급망 전체를 통제하는 거버넌스를 전면 혁신해야 한다"고 말했다.

국내 기업이 우선 점검해야 할 과제로는 스니펫 스캐닝의 소프트웨어개발생명주기(SDLC·Software Development Life Cycle) 내재화, SBOM 관리의 자산화, 좀비 오픈소스 퇴출 프로세스, 금지가 아닌 거버넌스 기반 AI·오픈소스 관리 체계가 제시됐다. 전 매니저는 "AI는 오픈소스 코드를 잘게 쪼개 짜깁기하기 때문에 패키지나 파일 단위 검사만으로는 라이선스 리스크를 걸러낼 수 없다"고 설명했다.

SBOM은 단순한 규제 대응 문서가 아니라 소프트웨어 자산을 수집·추적하는 가시성 확보 수단으로 제시됐다. 전 매니저는 "직접 의존성뿐 아니라 전이 의존성과 사내에서 활용한 오픈소스 AI 모델 정보까지 SBOM에 포함해 자산화해야 한다"고 강조했다.

웨비나에서는 오픈소스 리스크 관리 수준을 스스로 점검할 수 있는 다섯 가지 질문도 소개됐다. ▲AI가 복사·붙여넣기 한 코드를 추적하고 있는가 ▲방치된 좀비 오픈소스를 파악하고 있는가 ▲4년 이상 노후화된 버전을 그대로 쓰고 있지 않은가 ▲외주 산출물 검증 책임을 계약서에 명시했는가 ▲규제 당국이나 고객사 요구 시 SBOM을 즉시 제출할 수 있는가 등이다. 전 매니저는 "'보안 툴을 도입했는가'가 아니라 '사각지대까지 실제로 추적하고 통제하고 있는가'로 질문의 패러다임을 바꿔야 한다"고 말했다.

전사적 거버넌스의 필요성도 다뤄졌다. 오픈소스 리스크 관리는 개발·보안 부서만의 책임이 아니며 경영진, 보안, 개발, 법무·컴플라이언스, 구매·사업 조직이 함께 참여하는 오픈소스검토위원회(OSRB·Open Source Review Board) 체계가 필요하다는 설명이다. 전 매니저는 "보안, 법무, 구매, 경영진이 유기적으로 맞물리는 전사적 거버넌스를 구축해야 한다"고 강조했다.