오픈소스 보안 취약점·라이선스 리스크와 SBOM 대응 전략
Log4Shell이 드러낸 문제는 취약점 자체가 아니라 무엇을 쓰고 있는지 몰랐다는 점이었습니다. 오픈소스의 보안 취약점과 라이선스라는 두 리스크를 SCA·SBOM으로 함께 관리하는 방법과, 규제 동향에 대응하는 실무 절차를 정리합니다.
핵심 요약
- 상용 코드베이스의 98%에 오픈소스가 포함되어 있으며, 보안 취약점과 라이선스 컴플라이언스라는 두 가지 리스크를 동시에 관리해야 합니다.
- SBOM(Software Bill of Materials)은 소프트웨어 성분표로, 어떤 오픈소스가 어느 버전으로 포함됐는지를 체계적으로 추적할 수 있게 합니다.
- SCA(Software Composition Analysis) 도구와 SBOM을 빌드 파이프라인에 통합하면, 취약점과 라이선스 위반을 배포 전에 자동으로 감지하고 관리할 수 있습니다.
들어가며: "우리 시스템, Log4j 쓰나요?"
2021년 12월 10일, CVSS 10.0 만점 취약점이 공개됐습니다. Apache Log4j2에서 발견된 원격 코드 실행 취약점(CVE-2021-44228), 이른바 Log4Shell입니다. 특수하게 조작된 문자열 하나로 서버를 원격에서 장악할 수 있는 이 취약점은 공개 직후 수 시간 내에 다양한 환경에서 실제 공격 시도가 관찰되었고, 각국 보안 기관과 기업은 긴급 대응에 들어갔습니다.
당시 많은 조직에서 공통적으로 나온 질문은 이것이었습니다.
"우리 시스템에 Log4j 사용하고 있습니까?"
문제는 이 질문에 즉시 명확하게 답할 수 있는 조직이 많지 않았다는 것입니다. 일부 조직은 의존성 관리 도구(Maven/Gradle)를 통해 비교적 빠르게 확인할 수 있었지만, 전사 시스템 단위로는 어떤 서비스에 어떤 버전이 포함되어 있는지 일괄적으로 파악하는 데 시간이 소요된 사례가 많았습니다. 특히 전이 의존성(transitive dependency)까지 포함하면 단순 검색으로는 누락이 발생하기 쉬웠습니다.
Log4Shell은 단순한 보안 사고를 넘어, 우리는 우리가 사용하는 소프트웨어를 얼마나 정확히 파악하고 있는가라는 질문을 던진 사건이었습니다.
오픈소스 리스크의 두 얼굴
보안 취약점 — 속도의 문제
현대 소프트웨어에서 오픈소스는 선택이 아닌 기본값입니다. Black Duck의 2026 OSSRA 보고서에 따르면, 감사한 947개 상용 코드베이스 중 98%에 오픈소스가 포함되어 있었고, 오픈소스가 전혀 없는 코드베이스는 2%에 불과했습니다. Java 기반 애플리케이션의 경우 직접 선언한 의존성만 수십 개이지만, 전이 의존성까지 포함하면 수백 개에 달하는 경우가 흔합니다.
취약점의 발생 속도도 빨라지고 있습니다. 2025년에 공개된 CVE는 48,185건으로 역대 최다를 기록했고, 이는 전년(39,962건)보다 20.6% 늘어난 수치입니다. 2026년은 상반기에만 35,364건이 공개되어 전년 동기(23,656건) 대비 49.5% 증가했습니다.
더 중요한 것은 공격이 조치보다 빠르다는 점입니다. Mandiant가 집계하는 TTE(Time-to-Exploit, 패치 공개 전후를 통틀어 취약점이 실제 악용되기까지 걸린 평균 기간)는 20182019년 63일에서 20212022년 32일, 2023년에는 5일까지 줄었습니다. 반면 Edgescan의 2025년 통계에서 애플리케이션·API 영역의 평균 조치 기간(MTTR)은 74.3일이었습니다. 공격 코드가 며칠 안에 유통되는 동안 조치에는 두 달 이상이 걸리는 셈입니다. 금융 시스템에서 이 공백은 치명적입니다.
하위 전이 의존성의 취약점이 상위로 전파되는 범위
라이선스 — 조용히 쌓이는 법적 시한폭탄
보안 취약점만큼 주목받지는 않지만, 오픈소스 라이선스 리스크는 금융 기관에 법적·재무적으로 심각한 결과를 가져올 수 있습니다. 오픈소스 라이선스는 소스 공개 의무의 범위에 따라 크게 다섯 가지 유형으로 나뉩니다.
| 유형 | 대표 라이선스 | 소스 공개 의무 | 금융권 리스크 |
|---|---|---|---|
| Permissive | MIT, Apache 2.0, BSD | 없음 | 낮음 |
| Weak Copyleft | LGPL, MPL | 수정분만 | 중간 — 링크 방식 확인 필요 |
| Strong Copyleft | GPL v2/v3 | 파생 저작물 전체 | 높음 |
| Network Copyleft | AGPL v3 | 네트워크 서비스 포함 | 최고 |
| Source Available | SSPL, BSL | 상업적 이용 제한 | 중간 — 조건 정밀 검토 필요 |
특히 주의해야 할 것은 GPL 오염(GPL Contamination) 입니다. 개발팀이 Apache 2.0 라이선스 라이브러리를 가져왔더라도, 그 라이브러리의 전이 의존성에 GPL v3 코드가 포함되어 있다면 해당 모듈 전체에 소스코드 공개 의무가 발생할 수 있습니다. 개발자가 build.gradle에 직접 선언한 의존성에는 문제가 없어 보이지만, 2~3단계 아래 의존성 트리 어딘가에서 조용히 발생하는 것이 이 리스크의 특징입니다. 금융사 M&A 과정의 소프트웨어 실사(Technical Due Diligence)에서 라이선스 오염이 발견되어 거래 조건에 영향을 미친 사례는 국내외에서 지속적으로 보고되고 있습니다.
AGPL v3는 SaaS 형태의 금융 서비스에 특히 위험합니다. GPL이 소프트웨어를 "배포"할 때 소스 공개 의무를 부과하는 반면, AGPL은 네트워크를 통해 서비스를 제공하기만 해도 의무가 발생합니다. 인터넷뱅킹, 금융 API, 클라우드 기반 금융 플랫폼 등 거의 모든 현대 금융 서비스가 이 범주에 해당합니다. Elasticsearch가 AGPL 대신 SSPL로 라이선스를 전환한 것도 이 맥락에서 이해할 수 있습니다.
두 리스크를 동시에 관리하는 법 — SCA와 SBOM
SCA 도구 선택 기준
SCA(Software Composition Analysis)는 애플리케이션에 포함된 오픈소스 컴포넌트를 분석하여 취약점과 라이선스를 검출하는 도구입니다. 도구 선택 시 취약점 탐지 기능만 보는 경우가 많지만, 금융권에서는 라이선스 정책 게이트(배포 차단) 지원 여부를 함께 확인해야 합니다.
| 도구 | 비용 | 취약점 DB | 라이선스 분석 | 정책 게이트 | CI/CD 통합 |
|---|---|---|---|---|---|
| OWASP Dependency Check | 무료 | NVD | 제한적 | 미지원 | 가능 |
| Trivy | 무료(OSS) | 복수 DB | 기본 분류 | 제한적 | 우수 |
| Snyk | 유료 | 자체 DB | 고급 | 지원 | 우수 |
| Sonatype Nexus IQ | 유료 | OSS Index | 고급 | 지원 | 우수 |
| GitHub Dependabot | 무료 | Advisory DB | 제한 | 미지원 | GitHub 한정 |
무료 도구인 OWASP Dependency Check와 Trivy는 도입 장벽이 낮고 즉시 적용이 가능합니다. 다만 라이선스 정책 기반 배포 차단 기능은 유료 도구에 비해 제한적입니다. 금융 조직에서 외산 유료 도구 도입 시 보안 심의 절차가 필요하다는 현실적 제약도 고려해야 합니다. 취약점 탐지만이라도 먼저 자동화하는 것이 아무것도 하지 않는 것보다 낫습니다.
SBOM — 소프트웨어 성분 표기제
SBOM(Software Bill of Materials)은 애플리케이션에 포함된 오픈소스 컴포넌트의 목록, 버전, 라이선스, 의존 관계를 기계가 읽을 수 있는 형식으로 기록한 문서입니다. 식품의 성분 표시제에서 이름을 빌려온 개념으로, "이 소프트웨어에는 무엇이 들어 있는가"를 체계적으로 답하는 수단입니다.
대표적인 SBOM 포맷은 두 가지입니다. SPDX는 Linux Foundation이 주도하며 ISO/IEC 5962 국제표준으로 채택되어 라이선스 분석에 강점을 가집니다. CycloneDX는 OWASP가 주도하며 보안 취약점 및 공급망 분석에 최적화되어 있고, Gradle·Maven·GitHub Actions 등 도구 생태계 지원이 풍부합니다. 두 포맷 모두 JSON과 XML을 지원하며, 상호 변환 도구도 제공됩니다.
흔한 오해와 잘못된 접근
"우리는 유명하고 검증된 라이브러리만 쓰니까 괜찮아." Log4Shell은 Apache 재단의 공식 라이브러리에서 발생했습니다. 라이브러리의 인지도와 보안 취약점 발생 가능성은 무관합니다.
"취약점 패치를 위해 버전을 올렸다가 호환성 이슈로 장애가 발생하면 누가 책임집니까." 패치에 따른 부담은 이해할 수 있습니다. 그러나 현재 안정적으로 운영 중이라는 상태가 보안상 안전하다는 의미는 아닙니다. CVE가 공개된 순간 그 취약점은 공격자에게도 알려집니다. 패치를 미루는 시간만큼 위험은 조용히 누적됩니다.
"매번 빌드할 때마다 스캔하면 빌드 속도가 느려지지 않나요?" OWASP Dependency Check의 경우 초기 NVD DB 다운로드를 제외하면, 캐시를 유지한 증분 스캔 기준 일반적으로 30초~2분 수준입니다. CI 서버에서 캐시를 관리하면 실제 빌드 영향은 미미합니다.
파이프라인 통합과 금융 도메인 규제 동향
빌드 파이프라인 통합 흐름
오픈소스 보안 파이프라인(DevSecOps Pipeline)
라이선스 정책은 조직 내에서 사전에 Allow-list와 Deny-list 형태로 정의해야 합니다.
라이선스 정책 예시
- 허용(Allow) — MIT, Apache 2.0, BSD 2-Clause·3-Clause
- 검토 필요 — LGPL, MPL, EPL
- 금지(Deny) — GPL v2/v3, AGPL v3, SSPL
금융 도메인 규제 동향
오픈소스 보안과 SBOM은 이미 글로벌 규제의 핵심 의제로 자리잡고 있습니다. 미국 행정명령 EO 14028(2021)은 연방정부 납품 소프트웨어에 SBOM 제공을 요구하는 시발점이 됐으며, EU의 사이버복원력법(CRA)은 2024년 발효되어 EU 내 유통 디지털 제품의 사이버보안 의무를 강화했습니다. 금융보안원의 소프트웨어 공급망 보안 가이드라인도 오픈소스 취약점 관리를 명시적으로 다루고 있습니다.
금융 IT 감사 또는 외부 인증 과정에서 "사용 중인 오픈소스 현황과 취약점 관리 절차"를 요구받는 사례가 증가하는 추세입니다. SBOM은 이 질문에 즉시 답할 수 있는 가장 효율적인 수단입니다.
DevOn Boot, 프레임워크 레벨의 OSS 거버넌스
필요성은 공감하더라도, 시스템마다 개별적으로 대응하다 보면 적용 기준이 달라지고 어느 순간 어디에 무엇이 적용됐는지조차 파악이 어려워집니다. 그리고 감사 때가 되어서야 공백이 드러납니다.
DevOn Boot는 이 문제를 프레임워크 레벨에서 해결합니다.
DevOn Boot 프레임워크는 표준화된 Gradle 빌드 구조를 제공합니다. SCA·SBOM 도구는 이 구조 위에서 한 번만 설정하면 모든 프로젝트에 동일하게 적용됩니다. 릴리즈 주기별로 내장 오픈소스 컴포넌트의 취약점·라이선스 검토가 이루어지며, CVE 발생 시 DevOn R&D센터에서 즉각적으로 영향 범위를 분석하고 필요 시 패치를 제공합니다. 프로젝트 이행 시에는 시스템 오픈 전 검증 단계에서 OSS 검증을 수행하여, 운영 이관 전에 검증 결과를 확보합니다.
또한 안전하고 투명한 오픈소스 사용을 위해, 솔루션 납품 시 SBOM과 SCA 분석 결과 문서를 함께 제공합니다. 고객사는 별도의 분석 작업 없이도 시스템에 포함된 오픈소스 현황과 취약점·라이선스 검증 결과를 확보할 수 있어, 금융 IT 감사나 외부 인증 대응 시 즉시 활용할 수 있습니다.
개발·운영팀이 수백 개의 라이브러리를 직접 추적하지 않아도, DevOn Boot 프레임워크는 검증부터 증빙 문서 제공까지 보안 검증의 토대가 됩니다.
마치며: 지금 시작할 수 있는 3단계
오픈소스 리스크 관리는 완벽한 도구를 갖추는 것보다, 지금 가진 수단으로 시작하는 것이 더 중요합니다.
- 가시화 — 현재 프로젝트의 의존성 트리와 라이선스 현황을 파악합니다.
./gradlew dependencies명령 또는 Trivy 무료 스캔으로 즉시 시작할 수 있습니다. - 정책화 — 조직 내 허용·금지 라이선스 기준을 정의하고 문서화합니다.
- 자동화 — CI/CD 파이프라인에 SCA 스캔과 SBOM 생성을 통합하여, 매 빌드마다 자동으로 검증이 이루어지는 구조를 만듭니다.
어느 날 아침 갑자기 취약점을 파악해야 하는 상황은 준비된 조직과 그렇지 않은 조직을 명확히 가릅니다. SBOM은 그 준비의 가장 구체적인 형태입니다.
다음 콘텐츠에서는 외부 공격으로부터 시스템을 지킨 뒤, 내부 데이터를 어떻게 보호할 것인가를 다룰 예정입니다. 개인정보 보호를 위한 마스킹, DB 암호화, 알고리즘 선택, 설정 암호화 등을 실무 관점에서 정리합니다.
참고 자료
- Black Duck, 2026 Open Source Security and Risk Analysis Report — 상용 코드베이스 947개 감사 기준 오픈소스 포함 비율
- Jerry Gamblin, 2025 CVE Data Review / CVE Mid-Year 2026 Check-In — 연도별 CVE 공개 건수
- Google Cloud Threat Intelligence(Mandiant), An Analysis of 2023 Time-to-Exploit Trends — TTE 추이
- Edgescan, 『2025 Vulnerability Statistics Report』 (10th Edition) — 영역별 평균 조치 기간(MTTR)
- NVD, CVE-2021-44228 — Log4Shell 상세
- 미국 행정명령 EO 14028(2021), EU 사이버복원력법(CRA, 2024 발효), 금융보안원 소프트웨어 공급망 보안 가이드라인
※ 본 게시글의 이미지는 AI를 활용해 제작되었습니다.