고려대, 이름 바꾼 오픈소스 취약점도 추적하는 공급망 보안 기술 공개

• 고려대 연구팀이 소프트웨어 공급망 보안에서 꽤 현실적인 문제를 겨냥한 기술을 발표함

  • 패키지 이름을 바꾸거나 코드 형태를 살짝 바꿔도, 실제 알맹이 코드가 같으면 추적하겠다는 접근임
  • 연구 결과는 캐나다 몬트리올에서 열린 소프트웨어공학 최상위 학회 FSE 2026에서 논문 2편으로 발표됨

• 첫 번째 기술은 ‘SBridge’임. 소스코드 함수와 컴파일된 바이너리 함수를 비교해서 서로 대응되는 함수를 찾는 방식임

  • 단순히 함수 이름을 보는 게 아니라 조건문, 반복문 같은 실제 동작 단위를 세밀하게 비교함
  • 컴파일 과정에서 함수 이름이나 구조 정보가 사라져도, 제품 안에 어떤 오픈소스 코드와 취약점이 들어갔는지 추적할 수 있다는 얘기임

• 이게 중요한 이유는 바이너리 단계에서 오픈소스 사용 여부를 확인해야 하는 경우가 많기 때문임

  • 제품에 들어간 서드파티 코드가 취약한지 확인하려면 소스코드만 보는 걸로는 부족한 경우가 있음
  • 특히 함수 인라이닝처럼 컴파일 최적화가 들어가면 원래 코드 구조가 흐려져서 기존 방식이 놓치기 쉬움

• 두 번째 연구는 PyPI 패키지 생태계를 실제로 훑어본 쪽임

  • 연구팀은 파이썬 패키지 저장소 PyPI의 약 20만 개 패키지를 분석함
  • 인기 패키지 코드를 그대로 재사용한 복제 패키지 1361개를 발견함
  • 알려진 취약점이 그대로 복제된 패키지 256개와, 기존에 알려지지 않은 신규 악성 패키지 7개도 찾아냄

• 연구팀의 메시지는 결국 SBOM 정확도임

  • 오픈소스 사용이 늘수록 “우리 소프트웨어 안에 정확히 어떤 코드가 들어 있나”를 투명하게 확인해야 함
  • 이름·버전 기반 목록만으로는 부족하고, 실제 코드 유사성까지 봐야 공급망 보안의 빈틈을 줄일 수 있음

• 한국 개발자에게도 바로 닿는 이슈임

  • 파이썬 패키지, C·C++ 바이너리, 오픈소스 의존성은 국내 서비스와 제품에도 그대로 들어감
  • 보안팀만의 일이 아니라 백엔드·데브옵스·플랫폼팀이 의존성 관리 정책을 다시 봐야 하는 주제임

---

기술 맥락

• 이번 연구의 선택은 이름이나 버전 같은 메타데이터가 아니라 실제 코드 동작을 비교하는 쪽이에요. 공급망 공격자는 패키지 이름을 바꾸거나 관리자를 바꿔도 되지만, 재사용한 코드의 구조와 동작 흔적까지 완전히 숨기긴 어렵거든요.

• SBridge가 소스코드 함수와 바이너리 함수를 맞춰보는 이유는 컴파일 이후에도 취약 코드가 제품 안에 남아 있는지 확인해야 하기 때문이에요. 특히 C·C++ 제품은 배포 시점에 소스가 없거나, 최적화 때문에 함수 이름과 구조가 사라지는 경우가 많아요.

• PyPI 분석은 같은 문제를 패키지 저장소 레벨에서 본 사례예요. 이름과 버전만 보면 정상 패키지처럼 보여도, 실제 소스코드가 인기 패키지를 복제했거나 알려진 취약점을 그대로 품고 있을 수 있어요.

• 그래서 SBOM도 단순 목록에서 끝나면 약해요. 어떤 라이브러리를 썼는지 적는 것뿐 아니라, 실제 제품과 패키지 안에 그 코드가 어떤 형태로 들어갔는지 검증해야 공급망 보안이 실무에서 의미를 가져요.