📝 강연의 핵심 흐름

시대별 인식 변화 → 현재의 핵심 이슈 (SBOM 등) → 최신 연구 동향 → Q&A

[목차]

1. 서론: 공급망 보안의 중요성 대두
2. 시대별 변화: OSS를 바라보는 관점의 변천
3. 공급망 보안의 핵심 이슈: 취약점 전파와 3대 보안 문서 (SBOM, VDR, VEX)
4. 공급망 보안 주요 연구 동향: (교수님 연구 포함)
5. 결론 및 당부의 말
6. Q&A

1. 서론: 소프트웨어 공급망 보안의 대두

• 최근 ‘소프트웨어 공급망 보안’은 산업계와 학계 전반의 핵심 이슈로 부상했습니다.

2. 시대별 오픈소스(OSS) 인식의 변화

• 1990년대: “OSS의 재사용은 위험하다"는 인식이 지배적이었습니다.

• 2000년대: “OSS를 쓰는 것이 해롭다는 생각 자체가 해롭다"는 인식의 전환이 일어났습니다.

• 2010년대: OSS를 사용할 뿐만 아니라, 대형 기업(e.g., Google, Facebook)이 직접 OSS 개발을 주도하기 시작했습니다.

  • 이 시기, 패키지 매니저(npm, PyPI 등) 중심의 코드 재사용 연구가 급증했습니다.

  • 동시에 관련 보안 위협에 대한 대응 연구가 본격적으로 시작되었습니다.

• 2020년대: 공급망 보안 이슈가 심각해지자, 정부 차원의 규제가 등장했습니다. (예: 특정 SW 판매 시 SBOM 제출 의무화)

3. 공급망 보안의 핵심 이슈

3-1. 취약점 전파 (N-day Vulnerability)

• 0-day 취약점: 아직 패치가 존재하지 않는 알려지지 않은 취약점.

• N-day 취약점: 이미 패치가 공개되었으나, 사용자가 아직 적용하지 않은 취약점. (이미 공격 방법이 알려져 공격이 더 쉬울 수 있음)

• 문제점: 현대 소프트웨어 생태계는 의존성이 매우 복잡하게 얽혀있어, N-day 취약점이 패치되지 않은 채 방치되는 경우가 많습니다.

3-2. 3대 공급망 보안 명세서

• SBOM (Software Bill of Materials): 소프트웨어 구성 명세서

  • 해당 SW가 어떤 OSS 및 상용 라이브러리 (Commercial lib.)의 ‘어떤 버전’을 사용하는지 명시합니다.

  • 소비자는 SW 바이너리 구매 시 SBOM을 함께 받아, 포함된 라이브러리 버전에 취약점이 있는지 확인하고 공급자에게 수정을 요구할 수 있습니다.

• VDR (Vulnerability Disclosure Report): 취약점 기술서

  • SW에 포함된 구체적인 취약점 정보를 기술합니다.

  • 프로그램 규모가 크므로 보통 정적 분석 (Static Analysis)을 통해 생성됩니다.

  • 한계: 정적 분석의 특성상 오탐 (False Positive)이 많거나, 실제 빌드 과정에서 제외되는 코드, 혹은 논리적으로 도달 불가능한 (Unreachable) 코드의 취약점까지 포함할 수 있습니다.

• VEX (Vulnerability Exploitability Exchange): 취약점 영향 분석서

  • VDR 등에서 발견된 취약점이 실제로 해당 SW에서 공격 가능한지 (Exploitable) 그 영향을 판단합니다.

  • 이 분석 과정에서 지향성 퍼징 (Directed Fuzzing) 같은 기법이 활용될 수 있습니다.

4. 공급망 보안 관련 주요 연구 동향

4-1. 취약점 검색 (Vulnerability Detection)

• 코드 블록 (Block) 단위 검색 (ReDeBug, S&P ‘12):

  • 취약점 패치로 인해 사라졌어야 할 코드 블록을 검색합니다.

  • 적절한 정규식 (regex)을 사용합니다.

  • (한계) 속도가 느리고, 블록 단위가 너무 작아 오탐이 많습니다.

• 함수 (Function) 단위 검색 (VUDDY, S&P ‘17 - 교수님 연구):

  • 취약한 함수 단위를 검색합니다.

  • 적절한 요약 (Abstraction)을 사용합니다.

  • (한계) 미탐이 많습니다.

• 핵심 코드 라인 (Line) 검색 (MOVERY, Security ‘22):

  • 패치에서 ‘삭제된’ 코드 라인과, 해당 라인과 실행/데이터 흐름 의존성이 있는 라인들을 ‘집합’으로 저장하여 비교합니다.

  • (한계) 탐지에서 코드 순서가 고려되지 않습니다.

• Taint (Def-Use) 분석 (e.g., FIRE, Security ‘24):

  • 타겟 함수 내의 모든 <Source, Sink> 쌍을 식별하고, Taint Path를 CodeBERT로 벡터화하여 검색합니다.

  • (한계) 패치가 전혀 없는 함수만 대상으로 하며, 변수명 등 구문에 의존적입니다.

• Taint의 한계를 뛰어넘을 수 있을 것임.

4-2. 소프트웨어 구성 분석 (SCA: Software Composition Analysis)

• 배경: 어떤 OSS가 재사용되었는지 파악하는 기술. (특히 C, C++는 코드 레벨의 복사-붙여넣기 (Ctrl+C/V) 재사용이 많아 탐지가 매우 어려움)

• (교수님 연구 - CENTRIS, ICSE ‘21): 해당 OSS에만 존재하는 고유한 (unique) 코드 조각을 식별하여, 일부만 사용되어도 재사용으로 탐지하는 기술.

• 취약점 탐지를 도울 수도 있을 것임.

4-3. 공개 취약점 정보 검증 (CVE 검증)

• 문제점: 매우 광범위하게 사용되는 라이브러리의 CVE임에도 불구하고, CVE 공식 웹사이트에는 영향을 받는 제품 중 극히 일부만 경고되는 등 정보가 불완전한 경우가 많습니다.

• 이러한 공개 취약점 정보의 불일치성을 검증하고 보완할 수 있을 것임.

• (교수님 비슷한 연구? - VOFinder, Security ‘21): 공개 취약점의 최초 발생지를 찾아내어 틀린 CVE 정보를 고침

4-4. AI 활용 탐지 및 문서 자동 생성

• AI 기반 취약점 탐지:

  • (교수님 연구 - CRYPTBARA, ASE ‘25): 정적 분석을 활용해 AI의 탐지 정확도를 높이는 연구. (파이썬 암호화 라이브러리 대상 Real-world 취약점 172개 탐지 및 20여 개 보고 완료)

• 공급망 보안 문서 자동 생성:

  • 문제점: SBOM이 표준 형식 (e.g., SPDX, CycloneDX)은 있지만, ‘여러 버전의 라이브러리가 혼재된 경우’ 등 모호한 케이스를 어떻게 기록할지에 대한 명확한 규정이나 관행이 없습니다.

  • (교수님 연구 - TIVER, ICSE ‘25): 이러한 까다로운 부분들을 정확하게 나눠 정리해주는 기술.

• 기타: 바이너리 분석 및 취약점 탐지를 돕는 다양한 AI 연구 진행 중.

5. 기타 이슈 및 결론

• 라이선스 이슈: OSS 라이선스 간의 호환성 문제 역시 공급망 보안의 중요한 주제 중 하나입니다.

• 결론: 공급망 보안은 산업계와 매우 가까우면서, 동시에 학계에서도 다양한 연구가 시급히 필요합니다.

• 교수님의 당부 (대학원생 대상):

  • “논문을 위한 연구"가 아닌 “연구를 위한 연구"를 합시다.

  • 연구 자체가 주가 되면, 실적 (논문)은 자연스럽게 따라옵니다. (연사 본인도 첫 논문 이후 ‘논문을 위한 연구’를 하다가 실적이 정체되었던 경험이 있음)

6. Q&A

• Q: Closed-source SW가 어떤 OSS를 사용하는지 탐지하는 연구는?

  • A: 과거에는 CFG (제어 흐름 그래프)를 비교하는 연구 (e.g., Binary AIDA)가 많았으나, 정확도가 처참했습니다. 최근에는 BinaryAI를 활용한 연구가 압도적으로 좋은 정확도를 보여주고 있습니다.

• Q (내 질문): VEX에서 지향성 퍼징 시, SBOM 정보나 해당 취약점의 PoC를 참고하나요?

  • A: PoC가 없는 경우가 훨씬 많습니다. (‘25년 관련 세미나에서 확인 결과, 아직은 해커들이 수동으로 PoC를 제작하는 단계에 머물러 있습니다.)

• Q (내 질문): AI가 생성한 코드는 어디선가 보고 배운 매우 잘게 쪼개진 코드 조각 (snippet) 형태일 텐데, 기존 SCA 기술로 탐지가 가능한가요?

  • A: 기존 기술로는 탐지가 어렵습니다. 다만, 해당 코드가 ‘AI에 의해 생성되었는지’를 판별하는 기술은 (Gen-AI의 고유한 특성을 활용하여) 별도로 존재합니다.

• Q: AI 생성 코드도 SBOM에 포함되나요?

  • A: 조만간 관련 규정이 생길 것으로 보이며, AIBOM (AI Bill of Materials)에는 포함될 것입니다.

• Q: 해커 입장에서 SBOM을 보면, 의존성 네트워크를 그려서 가장 취약한 지점을 공략하는 데 도움이 될 것 같습니다.

  • A: 맞습니다. 가장 많이 연결되고 (의존성 높음) 취약한 지점 (e.g., Log4Shell)을 찾아 공격하는 것이 가능합니다.

  • 아마 그래서인지, 기업의 자산인 Closed-source SW의 SBOM은 (판매 시 고객에게만 제공될 뿐) 공개적으로 수집되지 않으며, 이를 모아놓은 연구도 아직까지 없습니다.

_교수님 홈페이지: https://ssp.korea.ac.kr