<소프트웨어 공급망 보안 분야의 학술 연구 동향과 정책 요구사항 간 격차 분석: LDA 토픽 모델링 활용> 논문을 읽고

https://www.earticle.net/Article/A475383

소프트웨어 공급망 보안 분야의 학술 연구 동향과 정책 요구사항 간 격차 분석 : LDA 토픽 모델링

1. 서론

SolarWinds 침해 사고와 Log4Shell 취약점 사태는 신뢰받는 소프트웨어 채널이나 널리 사용되는 오픈소스 라이브러리가 어떻게 전체 시스템을 마비시키는 연쇄적 파급 효과를 낳을 수 있는지 명확히 보여준다. 다수의 오픈소스 컴포넌트와 제3자 라이브러리에 대한 의존성이 높은 현대 소프트웨어 개발 환경의 구조적 취약성을 드러낸다.

 

본 연구는 소프트웨어 공급망 보안 분야의 최신 학술 연구 흐름을 정밀하게 분석하고자 한다. 2018~2024년까지 발표된 학술 논문 데이터를 수집하고, 텍스트 마이닝 기법 중 하나인 LDA(Latent Dirichlet Allocation) 토픽 모델링을 적용하여 핵심 연구 주제들을 식별하고 특성을 체계적으로 정리할 것이다.

 

텍스트 마이닝 (Text Mining)

인간이 쓰는 자연어 데이터는 컴퓨터가 바로 이해하기 어려운 비정형 데이터이다. 텍스트 마이닝은 자연어 처리(NLP) 기술을 활용해 방대한 텍스트 데이터를 컴퓨터가 처리할 수 있는 구조로 바꾸고, 의미 있는 패턴, 트렌드, 정보, 혹은 숨겨진 지식을 발굴하는 빅데이터 분석 기법이다.

LDA (Latent Dirichlet Allocation, 잠재 디리클레 할당)

텍스트 마이닝 기법 중에서도 토픽 모델링의 가장 대표적인 알고리즘.

방대한 문서 집합을 입력하면, 컴퓨터가 통계적 확률 분포를 기반으로 "이 문서들에는 대략 이런 핵심 주제들이 섞여 있고, 각 주제는 이런 단어들로 구성되어 있다"를 자동으로 찾아내는 기술이다.

 

나아가 도출된 학술 연구 동향과 주요국의 정책 요구사항을 비교 분석하여 둘 사이의 구조적 격차(gap)을 규명하고, 나아가야 할 연구 방향성을 제안하고자 한다. 실효성 있는 정책 수립 및 실무 적용에 있어 중요한 자료로 활용될 것으로 기대된다.

2. 이론적 배경 및 선행 연구 분석

2.1 소프트웨어 공급망의 개념과 보안 위협

소프트웨어 공급망 - 소프트웨어가 기획, 개발, 배포, 운영 및 유지, 보수되는 전 과정을 포괄하는 복잡한 생태계.

현대 소프트웨어 개발 환경은 생산성 극대화를 위해 오픈소스와 서드파티(3rd-party) 구성 요소에 크게 의존하는데, 이런 개방성은 공격자에게 다양한 침투 경로를 제공하는 구조적 취약점으로 작용한다.

 

최근 공격은 개발 프로세스의 상류(upstream) 단계에 침투하여 악성코드를 삽입하는 방식으로 진화하고 있다.

XZ Utils 백도어 사건 - 공급망의 작은 보안 결함이 전체 시스템의 붕괴로 이어질 수 있는 연쇄적 위험을 보여주었다.

이런 심각성 때문에 미국 CISA와 NIST 등은 공급망 공격을 국가 차원의 위협으로 규정하고 적극적인 대응을 촉구하고 있다.

 

소프트웨어 공급망에서 '상류(upstream)' 단계란

- 상류(Upstream): 소프트웨어의 재료와 기반을 만드는 단계. 오픈소스 라이브러리 개발, 개발자의 소스 코드 작성, 외부 패키지 가져오기 등.

- 하류(Downstream): 완성된 소프트웨어를 조립, 빌드하여 기업이나 최종 사용자(User)에게 배포하고 운영하는 단계.

XZ Utils 백도어 사건 (CVE-2024-3094)

배경

XZ Utils는 리눅스 운영체제에서 널리 쓰이는 데이터 압축 프로그램이다. 서버, 클라우드, 임베디드 장비 등 리눅스가 돌아가는 거의 모든 곳에 기본으로 설치되어 있는 핵심적인 오픈소스이다.

해커의 치밀한 잠입 (몇 년에 걸친 빌드업)

Jia Tan이라는 가명의 해커(배후에 국가 정보기관이 있을 것으로 추정)는 2021년부터 이 오픈소스 프로젝트에 기여하기 시작.

오랜 기간 성실하게 오류를 수정하며 기존 관리자의 신뢰를 얻었다. 기존 관리자가 번아웃과 압박에 시달리자, 해커는 자연스럽게 이 프로젝트의 공동 관리자 권한을 승계 받았다. 

독(백도어) 주입과 연쇄 위험

권한을 얻은 해커는 교묘하게 암호화된 악성코드(백도어)를 XZ Utils 최신 버전에 포함해 배포했다.

이 백도어의 목적은 원격 접속 기능(SSH)을 무력화하는 것. 만약 이 버전이 리눅스 정식 배포판에 그대로 탑재되어 전 세계 서버에 깔렸다면, 해커는 비밀번호 없이 전 세계 리눅스 서버에 접속해 통제권을 쥘 수 있는 대재앙이 일어날 뻔했다.

어떻게 발견했는가

마이크로소프트 엔지니어인 안드레스 프뢴드가 성능 테스트 중 "왜 SSH 로그인을 할 때 평소보다 0.5초(500ms) 정도 느리고 CPU 사용량이 약간 높지?"라는 사소한 의문을 품고 코드를 깊게 파헤치다가 발견해냈다.

2.2 소프트웨어 공급망 보안 정책 동향 및 핵심 요구사항 분석

공급망의 투명성과 책임성을 강화하고, 개발 전 단계의 보안을 통합하는 방향으로 정책 및 제도적 장치가 수렴되고 있다.

미국은 SBOM 제출을 의무화했으며, 보안 개발 관행 준수를 증명하는 증명서(Attestation) 제출을 요구하며 공급자의 책임을 법적 수준으로 강화했다. 유럽 연합은 사이버 복원력 법(이하 CRA)을 통해 제품의 전 생애주기에 걸친 포괄적인 보안 요구사항을 법제화했다. 한국은 KISA의 소프트웨어 공급망 보안 가이드라인을 통해 산업계의 자율적인 보안 내재화를 유도하고 있다.

 

본 연구는 4가지 핵심 요구사항 분석 프레임워크를 다음과 같이 도출했다.

- 증명 가능한 보안(Verifiable Security):

정책들은 단순한 보안 활동의 수행 여부를 넘어, 그 활동이 실제로 수행되었음을 제3자가 검증할 수 있는 증거 제출을 요구한다. SBOM 데이터의 위변조 방지, 암호학적 증명, 자동화된 감사 추적 등이 가능한 아키텍처 구축이 필요함을 의미한다.

- 설계 기반 보안(Secure-by-Design):

CRA는 개발 초기 단계부터 보안 요구사항을 의무적으로 내재화하는 Shift-Left 패러다임을 법제화하고 있다. 개발 이후 단계에서 취약점을 찾는 소극적 대응에서 벗어나, 제품 설계 단계부터 보안을 고려하는 능동적 방어 체계를 요구한다.

 

Shift-Left 패러다임

왼쪽으로 이동한다. 여기서 왼쪽은 소프트웨어 개발 생명주기(SDLC)의 시간 순서 배치를 의미한다.

요구사항 정의 -> 설계 -> 개발(코딩) -> 테스트 -> 배포/운영

과거의 전통적인 보안은 개발이 다 끝나고 배포하기 직전인 테스트(오른쪽) 단계에서 모의해킹을 하거나 취약점을 점검하는 방식이었다. 반면 Shift-Left는 보안 점검과 요구사항 반영을 개발 프로세스의 가장 초기 단계인 요구사항 정의 및 설계(왼쪽) 단계로 대폭 앞당기자는 패러다임이다.

 

- 지능형 보안 자동화 (Intelligent Security Automation): 

AI를 통한 이상 징후 탐지 및 정책 기반의 자동화된 위협 대응 필요성이 주요 정책에서 공통으로 강조되고 있다. 

복잡한 공급망 환경에서 발생하는 수많은 이벤트를 인간의 개입 없이 실시간으로 분석하고 방어하는 지능형 체계로의 전환을 촉구한다.

- 상호운용성 (Interoperability):

SPDX, CycloneDX 등 다양한 표준과 국가별로 상이한 제출 체계는 다국적 기업에 큰 부담이다.

여러 정책 요구사항을 자동으로 매핑하고 변환할 수 있는 통합 플랫폼이나 메타모델은 글로벌 공급망에 참여하기 위한 필수적인 요구사항이다.

 

2.3 LDA 토픽 모델링을 활용한 선행 연구 고찰

LDA의 한계
키워드로 수집한 데이터 전체를 정량적 검증 과정 없이 분석에 바로 활용한다. 주제와 관련성이 낮은 데이터가 분석에 포함되어 토픽의 명확성을 저해하고 결과의 신뢰도를 낮출 수 있다.

2.4 본 연구의 필요성 및 차별성

소프트웨어 공급망 위협과 정책적 대응이 빠르게 구체화되는 상황에서 해당 분야의 학술 연구 동향을 체계적으로 분석하여 향후 연구 방향을 제시하는 것은 시의적절하다.

앞선 LDA의 방법론적 한계를 극복하고 신뢰성을 극대화하는 데 핵심적인 목적과 차별성을 둔다.

 

핵심적인 차별성

1) 분석 데이터의 주제 적합성을 기계 학습을 통해 체계적으로 확보했다. 

전문가가 분류한 데이터를 기반으로 SVM(Support Vector Machine) 분류 모델을 학습시켜 연구 주제와 관련성이 높은 문헌만을 엄격하게 선별하여 분석 데이터의 품질을 극대화했다.

 

SVM?

머신러닝 알고리즘 중 하나. 두 그룹을 완벽하게 갈라치기하는 최적의 경계선을 찾는 알고리즘이다. 분류하는 문제에 탁월한 성능을 보인다.

 

2) 최적의 토픽 수를 결정하기 위해 객관적이고 통합적인 기준을 적용했다.

토픽의 의미적 일관성(Coherence)과 모델의 예측 성능(Perplexity) 지표를 정규화한 통합 점수 모델을 활용하여 연구자의 주관적 판단을 배제하고 데이터 기반의 의사결정을 수행했다.

 

이처럼 본 연구는 방법론적 엄밀성을 통해 소프트웨어 공급망 보안 분야의 학술 연구 동향을 정밀하게 분석하고, 학계가 향후 정책적 수요에 부응하는 연구를 기획하는 데 필요한 신뢰도 높은 기초 자료와 실질적인 로드맵을 제공하고자 한다.

 

3. 연구 설계 및 분석 방법론

3.1 분석 데이터의 수집 및 정제

3.2 머신러닝 기반 연구 주제 필터링 및 데이터셋 구축

머신 러닝 기반의 분류 모델을 도입하였다. (양적 연구와 차별화되는 점)

3.3 LDA 토픽 모델링 및 최적 토픽 수 결정

(데이터 모으는 방법보다 공급망 보안 트렌드를 알기 위해 논문을 읽고 있어서 이 과정들은 대충 훑어 읽기만 했음)

4. 연구 동향 분석 결과 및 정책적 함의

4.1 소프트웨어 공급망 보안 핵심 학술 연구 토픽

4.2 토픽별 학술 연구 동향 분석

4.2.1 SBOM 구조화 및 취약점 분석

SBOM은 소프트웨어 내부 구성 요소와 의존성을 문서화하여, 보안 취약점의 추적과 대응을 가능하게 하는 핵심 메커니즘으로 부상하였다.

Mirakhorli et al(2024) - SBOM 도구들을 포맷 지원, CI/CD 연동, 자동 생성 여부 등의 기준으로 분류하고 기술적 상호운용성 확보가 실무 수용성을 좌우함을 강조.

Black Duck(2025) - 기업 다수가 SBOM을 도입하고 있으나 불완전, 업데이트 지연 등으로 실효성에 제약이 있다는 점을 지적했다.

SBOM의 기술적 토대를 마련하는 현재의 연구들은, 향후 정책이 요구하는 증명 가능한 보안 체계를 완성하기 위해 SBOM 데이터의 무결성 보장 및 자동화된 검증 아키텍처 연구로 나아갈 수 있는 중요한 디딤돌 역할을 한다.

 

Mirakhorli et al. (2024) - 기술적 상호운용성

소프트웨어를 만들 때 A가 SPDX 포맷으로 SBOM을 만들고, B가 CycloneDX 포맷으로 만들면, 최종 사용자는 이 두 성분표를 합쳐서 분석하기 매우 어렵다.

상호운용성 확보

서로 다른 도구와 개발 환경(CI/CD 파이프라인)에서 만들어진 SBOM 데이터가 호환되고 통합되어야만 실무자들이 수용할 수 있다.

Black Duck (2025) - 불완전성과 업데이트 지연

많은 기업이 정부 규제 때문에 SBOM을 발행하긴 하지만, 맹점이 있다.

불완전성

오픈소스 안에 또 다른 오픈소스가 숨겨져 있는 '간접 의존성(Transitive Dependency)'를 보지 못하고 껍데기만 기술하는 경우

업데이트 지연

소프트웨어는 수시로 패치되고 업데이트되는데, SBOM은 개발할 때 한 번 만들어두고 방치되어 '과거의 기록'으로 남는 문제가 발생한다. 성분표와 실제 제품이 따로 노는 현상.

4.2.2 오픈소스 기반 개발 프로세스 및 위협 모델링

소프트웨어 공급망의 전 주기적 위협에 대응하기 위한 보안 설계 속성과, 이를 구현하기 위한 프레임워크 중심의 연구에 해당한다.

기존의 취약점 기반 대응을 넘어, 공급망 침해의 전 단계 - 침입, 변조, 전파, 악용 - 에 걸친 구조적 방어를 설계 단계부터 고려하는 흐름이 반영되어 있다.

Okafor et al.(2022) - 다양한 공급망 공격 사례를 기반으로 위협을 침해(compromise), 변조(alteration), 전파(propagation), 악용(exploitation) 4단계로 구분하고, 이를 예방하기 위한 핵심 보안 설계 속성으로 투명성(transparency), 유효성(validity), 분리성(separation)을 제시했다. 각 속성은 SBOM, 서명 기반 검증, 컨테이너화 등 다양한 기술로 구체화되며, 개별 기술이 아닌 속성 중심의 접근이라는 점에서 주목할 만하다.

ODNI et al. (2023) - 미국 CISA 및 NIST의 권고안은 위 속성 기반 접근을 제도화하고 있으며, SLSA, SSDF, CNCF Secure Software Factory 등 다양한 프레임워크가 실제 구현 지침으로 활용되고 있다. 기술 간 파편화를 줄이고, 조직의 보안 성숙도를 정량화할 수 있는 기준이 된다.

 

공급망 침해의 4단계 (Okafor et al., 2022)

앞서 얘기한 XZ Utils 사건을 대입해보자.

1. 침해 (compromise)

해커가 타겟 시스템이나 오픈소스 프로젝트의 관리 권한을 획득하는 단계.

해커 지아 탄이 XZ Utils 메인테이너의 신뢰를 얻어 권한을 얻은 것

2. 변조 (alteration)

정상적인 소스 코드나 빌드 파이프라인 내부에 몰래 악성코드(백도어)를 삽입하는 단계.

XZ Utils 소스 코드 내부에 암호화된 백도어 코드를 심은 것

3. 전파 (propagation)

변조된 소프트웨어가 정식 업데이트나 패키지 저장소를 통해 하류로 흘러 내려가는 단계.

백도어가 심어진 XZ 버전이 리눅스 테스트 배포판들에 탑재되어 전 세계로 배포된 것

4. 악용 (exploitation)

최종 사용자의 시스템에 깔린 악성코드를 해커가 원격에서 활성화하여 정보를 탈취하거나 제어권을 장악하는 단계.

전 세계 리눅스 서버의 SSH 권한을 얻으려고 했던 최종 목적.

이를 예방하기 위한 3대 보안 설계 속성

1. 투명성 (transparency)

소프트웨어가 어떤 오픈소스, 내부 모듈로 만들어지는지 숨김없이 추적 가능해야 한다.

SBOM이 대표적. 투명성이 확보되어야 변조나 전파 단계에서 무엇이 오염되었는지 즉시 인지할 수 있다.

2. 유효성 (Validity)

소스코드나 빌드 결과물이 중간에 해커에 의해 바뀌지 않고, 신뢰할 수 있는 개발자가 만든 정품이 맞는지 계속해서 검증한다.

코드 커밋, 서명, 해시값 비교 등이 있다. 변조된 코드가 빌드되거나 전파되는 것을 원천 차단한다.

3. 분리성 (Separation)

개발, 빌드, 실행 환경을 서로 철저히 분리하여 하나의 서브시스템이 침해당하더라도 전체 시스템이나 하류 단계로 오염이 전파되는 것을 물리적, 논리적으로 막는다.

컨테이너화(Docker, Kubernetes), 일회성 빌드 환경(Ephemeral Build Environments), 권한 최소화 등이 있다.

실무 지침이 되는 글로벌 프레임워크 (ODNI et al., 2023)

- SLSA (Supply-chain Levels for Software Artifacts)

구글이 주도한 프레임워크. 소프트웨어 빌드 과정의 무결성을 지키기 위한 보안 등급을 정의한다. 주로 유효성과 투명성을 정량화한다.

- SSDF (Secure Software Development Framework)

NIST가 제정한 안전한 소프트웨어 개발 프레임워크. 기획부터 배포까지 전 주기에서 개발사가 지켜야 할 보안 실천 수칙을 담고 있다. Shift-Left의 실천판.

- CNCF Secure Software Factory

클라우드 네이티브 환경에서 소스코드가 아티팩트(결과물)로 빌드되는 공장 파이프라인 전체를 분리성과 유효성 관점에서 격리, 보호하는 아키텍처 표준.

 

이런 속성 기반 접근법은 다양한 구현 기술과 보안 속성을 체계적으로 매핑하고, 조직의 특성에 맞는 속성 간 우선순위를 결정하는 프레임워크를 연구로 발전시켜 정책이 요구하는 설계 기반 보안을 구체화할 수 있는 잠재력을 보여준다.

4.2.3 펌웨어 및 빌드 컴포넌트 취약점 분석

IoT 환경에서 발생하는 공급망 보안 취약성과 대응 방안을 다룬다. IoT 생태계는 물리적 장치의 다양성, 불균형한 보안 수준, 공급망 내 구성 요소의 복잡한 연계성으로 인해 전통적 IT 시스템보다 더 높은 보안 위험에 노출되어 있다.

Zhu et al. (2023) - IoT 소프트웨어 공급망 보안의 위험 평가 기법을 구조화하여 제안. 위협 시나리오, 자산-취약점-공격 벡터 간 연계를 기반으로 하는 종합적 위험 분석 프레임워크를 도출했다. 특히 IoT 장치 특유의 제약 조건 (저전력, 실시간성, 단편화된 펌웨어 구조)이 공급망 전체의 취약성 평가를 더욱 복잡하게 만든다는 점을 강조했다.

Bitdefender(2024) - 실증 데이터 기반 보안 이벤트 분석. 스마트 TV, DVR, 스마트 플러그 등 다양한 장치에서 심각한 취약점이 지속적으로 발견되고 있음을 보고했다. TV나 라우터와 같이 장기간 사용되면서 제조사 지원이 중단된 장치는 이른바 n-day 취약점을 장기간 방치하게 되는 경향이 있다. 공격자들은 대부분 기존에 알려진 취약점 CVE를 재활용하여 IoT 장치에 접근하고 있으며, 높은 위험도를 지닌 CVE(9~10점대)에 공격이 집중되고 있다는 점은 대응 우선순위 결정의 필요성을 시사한다.

 

IoT 공급망 보안이 전통적 IT보다 훨씬 어려운 이유 (Zhu et al., 2023)

IoT 장치 특유의 물리적, 환경적 제약 조건.

- 단편화된 펌웨어 구조 (Fragmented Firmware)

윈도우나 리눅스 같은 표준 OS와 달리 IoT 기기는 제조사마다, 심지어 모델마다 펌웨어 구조가 제각각이다. 침셋 제조사(AP), OS 공급사, 오픈소스 라이브러리, 최종 기기 제조사의 코드가 복잡하게 얽혀 있어 "이 펌웨어 안에 정확히 어떤 컴포넌트와 취약점이 숨어있는지" 전수조사(SBOM 생성)하기가 물리적으로 매우 어렵다.

- 하드웨어 자원의 제약 (저전력, 저사양)

IoT 기기는 전력 소모를 최소화해야 하고 연산 능력이 낮다. 무거운 보안 솔루션을 기기 내부에서 돌릴 수 없다. 실시간성을 보장해야 하는 기기라면 보안 패치나 검증 프로세스로 인해 동작이 조금이라도 지연되는 것을 용납할 수 없다.

실무 현실: N-day 취약점의 방치 (Bitdefender, 2024)

운영 및 유지보수 단계에서 발생하는 보안 붕괴를 보여준다.

- 제조사 지원 중단과 N-day 취약점의 영속화

스마트 TV나 인터넷 공유기(라우터)는 소비자가 한 번 사면 5년에서 10년 이상 장기간 사용한다. 하지만 중소 제조사들은 출시 후 1~2년만 지나면 비용 문제로 패치 지원을 중단한다. 이로 인해 이미 수정 패치와 취약점 번호(CVE)가 공개된 N-day 취약점들이 기기 내부에 치료되지 않은 채 영원히 방치된다.

- 공격자들의 가성비 전략 (CVE 재활용)

해커들은 힘들게 새로운 취약점을 찾지 않는다. 기기에 방치된 초고위험도 CVE를 그대로 재활용하여 대량의 IoT 기기를 자동화된 스크립트로 감염시킨다. 이 기기들은 좀비 PC가 되어 거대한 미라이(Mirai) 같은 봇넷을 형성하고, 타겟 시스템을 마비시키는 전파 기지로 악용된다.

 

IoT 공급망의 이질성과 복잡성을 다루는 연구는 개별 장치 보안을 넘어, 공급망 전체의 위험을 정량적으로 평가하고 이종(heterogeneous) 장치 간 신뢰할 수 있는 정보 공유 체계를 구축하는 후속 연구의 필요성을 제기한다.

4.2.4 공격 표면 분석 및 종속성 기반 위협 탐지

소프트웨어 공격 표면(attack surface)을 구성하는 종속성과 라이브러리, 빌드 파이프라인 등에서 발생하는 위협을 탐지하고 분석하는 기술적 접근을 중심으로 한다. SolarWinds, Log4Shell 사태 이후 더욱 중요해진 직접, 간접적 종속성 내에 숨겨진 악성코드를 식별하고, 빌드 과정 자체의 무결성을 확보하려는 연구 흐름을 반영한다.

Seshadri et al.(2024) - OmniBOR라는 시스템을 통해 소프트웨어 아티팩트 간의 관계를 콘텐츠 기반 고유 식별자(gitoid)로 추적하는 아티팩트 종속성 그래프(Artifact Dependency Graph, ADG) 체계를 제안했다. 소스코드부터 라이브러리, 최종 빌드된 바이너리까지 모든 구성 요소의 계보를 명확히 하여 특정 취약점이나 악성코드가 포함된 라이브러리가 어떤 경로로 최종 제품에 포함됐는지 정확히 추적할 수 있게 한다. 복잡한 종속성 트리 전체를 가시화하여 잠재적 위협을 식별하는 데 매우 효과적인 도구이다.

Red Hat (2024) - 실제 산업 현장에서는 빌드 단계의 보안 성숙도가 조직별로 큰 편차를 보인다. 보안 성숙도가 높은 조직은 CI/CD 파이프라인에 자동화된 보안 검사를 포함시켜 컴플라이언스 충족 여부를 확인하지만 57%의 개발팀은 빌드 정보를 파이프라인 컴플라이언스 검증에 활용하지 않고 있다. 개발팀의 67%가 CI/CD 파이프라인에 여러 보안 관행을 포함하고 있지만, 주로 반복 작업을 줄이는 데 초점이 맞춰져 있어, 정교한 공격을 방어하기 위한 심층적인 종속성 분석 및 검증 체계는 여전히 부족한 것으로 나타났다.

 

아티팩트 종속성 그래프 (Seshadri et al., 2024)

직접 종속성과 간접 종속성

- 직접 종속성 (Direct Dependency) : 개발자가 라이브러리 사용 여부를 코드에 명시적으로 적어놓은 것.

- 간접/이행적 종속성 (Transitive Dependency) : 그 라이브러리가 구동하기 위해 내부적으로 가져오는 수많은 하위 라이브러리들이다.

- 문제점: 과거 Log4Shell 사태는, 기업들이 Log4j를 직접 쓰지 않았더라도 그들이 구매한 대형 소프트웨어의 간접 종속성 깊은 곳에 Log4j가 숨어있었기 때문이다.

OmniBOR의 해결책

소프트웨어가 빌드되는 전 과정을 감시하여 아티팩트 종속성 그래프(ADG)라는 족보를 그린다.

- gitoid (Git Object ID): 파일 이름이 아니라, 파일의 '실제 내용물(콘텐츠)'을 해시 함수로 변환한 고유한 주민등록번호이다. 해커가 파일 이름은 그대로 둔 채 내부 코드만 1바이트 슬쩍 바꾸더라도 gitoid가 완전히 바뀌기 때문에 변조를 즉각 탐지할 수 있다.

- 나중에 새로운 취약점이 발견됐을 때 "취약한 라이브러리의 gitoid를 포함하고 있는 최종 제품이 우리 회사에 하나라도 있는가?"를 몇 초 만에 완벽하게 가시화(추적)할 수 있다.

빌드 파이프라인의 보안 성숙도 편차 (Red Hat, 2024)

Red Hat의 실증 데이터는 실제 개발 현장(산업계)의 보안 불감증을 이야기하고 있다.

- 껍데기만 남은 자동화 (CI/CD의 맹점)

대부분의 개발팀 67%는 코드를 올리면 자동으로 빌드하고 배포해 주는 CI/CD 파이프라인을 쓴다. 하지만 이 자동화는 보안을 위해서가 아니라 단순히 매번 빌드하기 귀찮으니까 편하려고 (반복 작업 감소) 쓰는 경우가 대부분이다.

- 컴플라이언스 검증의 부재 (57%의 방치)

개발팀의 57%는 빌드 과정에서 나오는 다양한 정보(어떤 라이브러리가 결합했는지 등)를 수집만 할 뿐, 정부 규제나 조직의 보안 정책(컴플라이언스)에 부합하는지 검증하는 절차를 파이프라인에 연동하지 않고 있다. 

- 심층 분석의 부족

빌드가 성공했는지, 기본적인 정적 분석에서 에러가 안 났는지 수준만 체크할 뿐, 정교한 간접 종속성 검증이나 빌드 도구 자체의 오염 여부를 확인하는 심층 방어는 부족하다.

 

개별 컴포넌트 분석을 넘어, 복잡한 종속성 그래프 전체를 자동으로 분석하고 잠재적 위협을 예측하는 지능형 보안 자동화 연구로 발전할 수 있는 중요한 가능성을 보여준다.

4.2.5 SBOM 기반 공급망 위험 관리 및 정책 거버넌스

기술적 탐지를 넘어, 정부와 산업 수준의 표준을 조직의 보안 프로세스에 내재화하려는 시도를 보여준다.

Xia et al. (2023) - 기존 SBOM 공유 방식이 데이터 위변조 및 민감 정보 노출 위험에 직면하고 있다는 문제를 지적한다. 이를 해결하기 위한 솔루션으로 블록체인 기반의 SBOM 공유 아키텍처를 제안했다. 검증 가능한 자격증명(VC)을 활용하여 SBOM 데이터의 무결성을 보장하고, 선택적 정보 공개를 통해 기업의 민감 정보를 보호하면서도 신뢰 기반의 관리 체계를 구축할 수 있다.

또한, 향후 AI 컴포넌트까지 관리 대상으로 포함하는 AIBOM(AI Bill of Materials)으로의 확장을 제시하며, AI 기반 소프트웨어 위험 관리라는 새로운 과제에 대응하는 미래지향적 거버넌스 모델이다.

Anchore(2025) - Policy-as-Code(PaC)를 통해 거버넌스를 자동화하는 방안을 제시했다. 조직의 보안 정책을 사람이 읽는 문서가 아닌, 실행 가능한 코드로 정의하여 CI/CD 파이프라인에 통합하는 방식이다. 

"특정 라이선스를 포함하거나 CVSS 9.0 이상의 취약점이 발견된 컴포넌트가 포함된 빌드는 자동으로 차단한다"와 같은 정책을 코드로 구현하고, SBOM 스캔 결과와 연동하여 실시간으로 정책을 강제할 수 있다.

수동 검사에 의존하던 기존의 관리 방식을 자동화된 거버넌스 체계로 전환하여 일관성과 효율성을 극대화한다.

 

안전한 신뢰 체계의 구축

1. SBOM 유통의 딜레마: 위변조와 정보 노출

- 위변조 위험: 공급업체가 소프트웨어를 넘길 때 SBOM을 같이 주는데, 중간에 해커가 SBOM 내용을 조작해 취약점이 없는 것처럼 속이거나, 공급업체가 과실을 숨기기 위해 성분표를 위조할 수 있다.

- 민감 정보 노출: SBOM에는 기업이 독자적으로 개발한 소스 코드 구조나 영업 비밀에 해당하는 핵심 라이브러리 목록까지 다 들어있다. 협력사에 그대로 넘기면 기술 유출이 우려된다.

2. 해결책: 블록체인, VC(검증 가능한 자격증명), 선택적 공개

- 블록체인과 VC : SBOM을 블록체인 네트워크에 기록하여 데이터의 절대적인 무결성(위변조 불가능성)을 보장한다. VC 기술을 결합하면 "이 SBOM은 공인된 기관이나 신뢰할 수 있는 개발사가 발행한 진짜 성분표가 맞다"는 것을 수학적으로 증명할 수 있다.

- 선택적 정보 공개: 대외적으로 검증이 필요한 보안 취약점 여부나 컴플라이언스 충족 사실만 선택적으로 인증해서 보여준다. 기업의 기밀은 지키면서 신뢰는 확보한다.

3. 미래 확장: AIBOM

AI 모델을 만들 때 사용된 학습 데이터의 출처, 데이터 정제 방식, 사용된 기반 모델의 버전, 가중치의 무결성 등을 문서화한다. 데이터 오염이나 편향성 위협을 막기 위한 필수적인 미래 거버넌스 모델이다.

수동 검사에서 자동 통제로: Policy-as-Code

CI/CD 파이프라인은 구축했지만 보안 검증은 방치하는 실무적 한계를 정면 돌파하는 솔루션이다.

1. Policy-as-Code(PaC)가 왜 필요할까

기존 기업 보안 정책은 보안 지침 문서로서만 존재했다. 개발자들이 바쁘면 문서를 무시하거나, 보안 담당자가 출시 직전에 수동으로 일일이 검사하느라 배포가 지연되는 병목 현상이 발생했다.

2. 작동 원리: 코드가 정책 집행

PaC는 지침 문서를 스크립트로 짜서 개발 파이프라인에 심어버리는 기술이다.

개발자가 코드를 커밋하면, 시스템이 자동으로 SBOM을 스캔한다.

스캔 결과 데이터가 파이프라인에 심어진 PaC를 통과한다.

만약 SBOM에 GPL 라이선스가 발견되거나 CVSS 9.2점짜리 취약점이 감지되면, 시스템이 인간의 개입 없이 그 즉시 빌드를 자동으로 실패(Block) 처리하고 개발자에게 에러 메시지를 보낸다.

 

블록체인 및 PaC와 같은 기술을 활용하는 연구는 향후 다양한 국가의 규제와 산업 표준을 동적으로 반영하고, 조직의 거버넌스 정책을 코드로 자동 변환, 검증하는 정책 상호 운용성 확보 연구로 나아갈 중요한 방향을 제시한다.

4.2.6 악성 패키지 및 사이버 공격 탐지 프레임워크

소프트웨어 공급망을 위협하는 악성 패키지 탐지 기술 및 대응 전략에 집중된 연구로 구성된다.

NPM, PyPI, Maven 등 공개 저장소를 악용한 타이포스쿼팅(typosquatting), 악성코드 삽입 등과 같은 정교한 공격 시나리오에 대응하기 위한 기술적 접근을 중점적으로 다룬다.

Sejfia et al. (2022) - 머신러닝 기반의 정적 분석 및 메타데이터 이상 탐지를 결합하여 악성 NPM 패키지를 사전 탐지하는 자동화된 프레임워크를 제안했다. 악성코드 삽입이 아닌 의심스러운 배포 패턴, 권한 요구 이상징후, 패키지명 유사도 등을 종합적으로 고려하여 탐지율을 향상시키고, 개발 환경에 통합 가능한 경량 탐지 모델을 구현한 것이 특징이다.

Linskens (2025) - Sonatype의 SCA(Software Composition Analysis) 기반 악성 패키지 탐지 기술을 소개하며 현재까지 식별된 오픈소스 악성 패키지가 778,500개를 초과한다는 통계를 제시했다. Sonatype은 수집된 패키지 메타데이터, 코드, 배포 로그를 기반으로 이상 행위를 머신러닝으로 식별하고, 개발 환경 내 실시간 경고 및 차단 기능을 제공하며 SDLC 전 주기에서 보안성을 확보할 수 있었다. 규제 준수 및 공급망 전반의 무결성 확보를 지원하는 핵심 기술로 발전하고 있다.

 

해커의 공격 방식: 오픈소스 저장소 오염

유명한 오픈소스 패키지 이름과 유사하게 이름을 지어 업로드하는 타이포스쿼팅

Sejfia et al. (2022): 행동과 패턴으로 잡는다

소스 코드만 검사하는 한계를 넘어, 패키지의 행동과 메타데이터를 머신러닝으로 분석한다.

- 갑자기 평소와 다른 이상한 배포 패턴을 보이는 경우

- 단순한 기능의 패키지가 과도한 시스템 권한을 요구하는 경우

- 유명 패키지랑 이름이 비슷한 경우

이런 정황 증거들을 종합하여 악성 패키지가 개발자 PC에 깔리기 전에 미리 차단하는 경량화 모델을 만들었다.

Linskens (2025) - 실전 빅데이터 기반의 실시간 차단

글로벌 보안 기업인 Sonatype의 실전 데이터를 바탕으로 SDLC를 보호하는 기술.

Sonatype은 전 세계 코드, 배포 로그, 메타데이터를 24시간 긁어모아 머신러닝으로 감시한다. 개발자가 코딩 중 악성 패키지를 다운로드하려고 하면 실시간으로 경고를 띄우고 차단해버리는 강력한 방어 체계를 구축했다.

 

향후 SBOM 상의 의심 요소와 실시간으로 연계하여 탐지 정확도를 높이고, 알려진 악성 패키지의 변종까지 예측하는 지능형 탐지 프레임워크 연구로 심화될 수 있는 기반을 마련한다.

4.2.7 DevSecOps 워크플로우 및 코드 저장소 보안

CI/CD 파이프라인의 자동화된 보안 통제에 주목한 연구들을 포함한다.

GitHub Actions, Jenkins, GitLab CI 등 대표되는 자동화된 개발 환경 내 보안 정책을 코드 수준에서 구현하고, 무단 변경이나 취약 설정을 사전에 차단하는 기술을 중심으로 전개된다.

Benedetti et al. (2022) - GitHub Actions 워크플로우 설정에서 발생할 수 있는 보안 취약성을 자동으로 탐지하는 정적 분석 프레임워크를 제안했다. 외부 액션의 무분별한 참조, run 명령어를 통한 임의 실행 등 구성 문제를 구조화된 정책(rule set) 기반으로 분석, 실제 프로젝트에 적용하여 취약 사례를 실증적으로 식별했다. DevSecOps 실현을 위한 사전 검증(pre-deployment validation)의 핵심 사례로 평가된다.

Checkmarx (2025) - DevSecOps 성숙도 모델을 기반으로 보안 자동화의 확산 수준을 진단하고, 조직 내 보안 정책의 코드화 수준이 낮은 기업일수록 파이프라인 내 보안 사고 노출 가능성이 높다는 것을 지적했다. 조직의 20%는 여전히 AppSec 자동화를 도입하지 않았고, 정책 기반 배포 차단 같은 고급 자동화 기능 활용률은 30% 내외에 불과하다.

 

Benedetti et al. (2022) - GitHub 설정 파일 빈틈 잡기

GitHub Actions 워크플로우 설정 파일 자체를 검사하는 정적 분석 도구

- 외부 액션 무분별 참조 탐지: 검증되지 않은 타인의 오픈소스 배포 액션을 필터링 없이 가져다 쓰는 위험 찾아냄

- 임의 명령어 실행(Injections) 차단: 악성 스크립트가 빌드 과정에 끼어들어 실행될 수 있는 보안 구멍 찾아냄

- 사전 검증(Pre-deployment Validation): 코드가 서버에 배포되기 직전에 설정 오류를 미리 통제하는 실증적 프레임워크를 제시함.

Checkmarx (2025) - DevSecOps의 이상과 현실

현업에서 얼마나 안 쓰이고 있는지를 보여주는 통계이다.

- 자동화의 부재: 전체 기업의 20%는 여전히 앱 보안 자동화 검사를 전혀 도입하지 않았다.

- 고급 기능 활용 저조: 취약점이 나오면 자동으로 배포를 막아버리는 '정책 기반 배포 차단' 같은 고급 자동화를 쓰는 곳은 고작 30% 내외

- 설정을 코드로 꼼꼼하게 관리하지 않는 기업일수록 해커의 파이프라인 침해 사고에 매우 취약하다.

 

향후 워크플로우 자체의 보안성을 증명하고, 여기서 생성된 로그를 법적 증거로 활용하는 증명 가능한 보안 체계 연구로 확장될 수 있다.

4.3 학술 연구 동향과 정책 요구사항의 연계성 분석

학술 연구의 세부적인 초점과 정책의 궁극적인 지향점 사이에는 특정 간극이 존재한다. 개별 기술의 기능 향상이나 특정 취약점 탐지에 집중하는 반면, 정책은 이런 기술들을 활용하여 증명 가능하고(verifiable) 신뢰할 수 있으며(attested) 상호운용 가능한(interoperable) 보안 생태계를 법적으로 구축하는 것을 목표로 한다.

4.4 학술 연구와 정책 요구사항 간의 격차 및 향후 연구 기회

학계의 정책적 기여도를 높이기 위한 4가지 구체적인 연구 기회 영역을제시한다. 학술적 논의를 정책적 실효성으로 연결하기 위한 미래 연구의 청사진이 될 수 있다.

1) 증명 가능한 보안(Verifiable Security) 구현을 위한 아키텍처 연구 기회

증명서는 단순히 SBOM 목록을 제출하는 것을 넘어, 그 내용의 진실성과 개발 과정의 보안성이 법적으로 증명될 수 있다.

현재 학술 연구는 SBOM 생성, 분석, 블록체인 기반 거버넌스, DevSecOps 워크플로우 보안 등을 다루며 데이터 생성 및 관리 기술에 집중하는 경향이 있다. 향후 학계가 개별 기술을 넘어 기계 판독 가능한 표준 증명서 포맷 설계, SBOM 데이터와 개발 아티팩트 간의 암호학적 연결을 통한 무결성 보장 기술, CI/CD 파이프라인에서 생성되는 로그를 자동화된 감사 증거로 활용하는 신뢰 체계 구축 등 포괄적인 증명 아키텍처 연구로 나아갈 수 있다.

2) 설계 기반 보안(Security-by-Design) 원칙의 실질적 구현을 위한 자동화 연구 기회

SDLC 초기 단계부터 보안을 의무적으로 내재화하는 Shift-Left 패러다임을 법제화하고 있다.

현재 학계 연구는 위협 모델링이나 CI/CD 보안 자동화를 다루며 이 원칙에 접근하고 있으나, 대부분 개발 이후 단계의 취약점 탐지나 방어 기술에 더 집중되어 있다. 

조직의 보안 정책을 개발 초기 단계의 요구사항으로 자동 변환하는 기술, 설계 단계에서부터 공급망 위험을 정량적으로 모델링하고 시뮬레이션하는 도구, 안전한 코딩 표준을 강제하고 검증하는 개발 프레임워크 연구 등. 심도 있는 연구가 필요하다.

3) 지능형 보안 자동화(Intelligent Security Automation)의 고도화 연구 기회

정책이 AI를 활용한 지능형 방어 체계를 요구하는 반면, 현재 학술 연구는 주로 종속성 분석, 악성 패키지 탐지, CI/CD 파이프라인 내 보안 자동화 등에 머물러 있다. AI의 잠재력을 완전히 활용하지 못하고 있는 단계로, 유망한 연구 분야가 존재한다.

4) 상호운용성(Interoperability) 확보를 위한 실용적 연구 기회

다국적 기업들은 SPDX, CycloneDX 등 다양한 표준과 상이한 제출 체계로 인해 규제 준수에 큰 어려움을 겪는 현실적인 문제가 있다.

5. 결론

현재 학계의 주요 관심사가 기술 기반의 취약점 분석과 방어 체계 구축에 있음을 보여준다.