---
title: "세온이앤에스, 임베디드 코드까지 파고드는 실시간 보안 분석 솔루션 출시"
published: 2026-06-29T01:05:03.162Z
canonical: https://jeff.news/article/4401
---
# 세온이앤에스, 임베디드 코드까지 파고드는 실시간 보안 분석 솔루션 출시

세온이앤에스가 C/C++ 기반 임베디드 소프트웨어의 오픈소스 구성 요소를 분석해 소프트웨어 자재명세서와 취약점 리포트를 자동 생성하는 ‘Seon Code Analyzer’를 출시했다. 패키지 매니페스트만 보는 방식이 아니라 소스코드에 복사·이식된 오픈소스까지 추적한다는 점을 내세운다.

- 세온이앤에스가 임베디드 소프트웨어용 보안 분석 솔루션 ‘Seon Code Analyzer’를 정식 출시함
  - C/C++ 기반 임베디드 소프트웨어 내부의 오픈소스 구성 요소를 분석하는 제품임
  - 결과로 소프트웨어 자재명세서(SBOM)와 보안 취약점 리포트를 자동 생성함
  - 7월 1일 수원컨벤션센터에서 열리는 ‘AID 2026’에서 실시간 분석과 소프트웨어 자재명세서 생성 데모를 공개할 예정임

- 이 제품이 겨냥하는 문제는 “패키지 매니저에 안 잡히는 오픈소스”임
  - 자동차, 전력, 제어기기 같은 임베디드 제품은 웹·앱 소프트웨어처럼 의존성 파일이 깔끔하게 남아 있지 않은 경우가 많음
  - 오픈소스 코드가 소스 내부에 직접 복사·이식되는 경우가 흔해서, 기존 소프트웨어 구성 분석 도구가 놓치기 쉬움
  - 결국 보안·품질 검증 부서가 방대한 펌웨어 코드를 사람이 직접 대조하는 병목이 생겼다는 게 기사에서 짚은 배경임

> [!IMPORTANT]
> 임베디드 보안에서 진짜 까다로운 건 “선언된 의존성”보다 “누군가 예전에 복사해 넣은 코드”인 경우가 많음. 이걸 못 잡으면 소프트웨어 자재명세서도 취약점 추적도 반쪽짜리가 됨.

- Seon Code Analyzer는 의존성 파일 유무와 상관없이 소스코드 자체를 분석한다고 함
  - 소스코드의 구조적 특징을 보고 누락된 오픈소스 라이브러리를 역추적하는 방식임
  - 원본 소스코드를 외부 서버로 보내지 않고, 고유한 코드 지문만 추출해 대조한다고 설명함
  - 기업 입장에선 핵심 지식재산인 소스코드를 외부로 내보내지 않는다는 점이 꽤 중요한 차별점임

- 산출물은 컴플라이언스 쪽에 맞춰져 있음
  - 국제 표준인 CycloneDX 포맷의 소프트웨어 자재명세서를 생성함
  - 미국 국립표준기술연구소 취약점 데이터베이스와 오픈소스 취약점 데이터베이스를 연동해 취약점 식별자인 CVE 정보를 실시간 매핑함
  - 미 사이버보안·인프라보안국이 지정한 알려진 악용 취약점(KEV) 데이터까지 함께 검토해 우선순위 선정을 돕는 구조임

- 라이선스 리스크도 같은 흐름에서 처리함
  - SPDX 규격의 라이선스 컴플라이언스 분석서를 단일 파이프라인으로 생성한다고 함
  - 오픈소스 취약점만 보는 게 아니라, 라이선스 위반 가능성까지 같이 다루려는 설계임
  - 기업 납품, 인증, 수출 규제 대응에서는 보안 취약점만큼 라이선스 증거도 골치 아픈 영역임

- 오탐을 줄이기 위해 인공지능 기반 ‘증거 점수’도 넣었다고 함
  - 분석 결과가 실제 오픈소스 사용 증거로 얼마나 강한지 점수화하는 방식으로 보임
  - 관리자가 모든 후보를 수동으로 확인해야 하는 부담을 줄이는 게 목표임
  - 보안 도구에서 탐지는 많지만 쓸 수 있는 결과가 적은 문제를 겨냥한 기능임

- 무선 업데이트(OTA) 환경에서는 이런 자동화가 더 중요해짐
  - 임베디드 기기가 한 번 출고되고 끝나는 게 아니라, 무선 업데이트로 계속 바뀌는 환경이 늘고 있음
  - 업데이트마다 소프트웨어 구성 요소와 취약점 상태를 사람이 추적하는 건 현실적으로 빡셈
  - 세온이앤에스는 코드 한 줄 단위의 근거 데이터와 자동화된 컴플라이언스 체계가 보안 점검 비용을 줄일 수 있다고 강조함

---

## 기술 맥락

- 임베디드 소프트웨어에서 소프트웨어 자재명세서가 어려운 이유는 의존성 선언이 항상 남아 있지 않기 때문이에요. 웹 서비스는 패키지 파일을 보면 실마리가 잡히지만, 펌웨어는 필요한 코드만 복사해서 넣는 일이 흔하거든요.

- 그래서 이 솔루션은 패키지 목록이 아니라 코드 자체의 특징을 본다고 해요. 왜냐하면 실제 위험은 “문서에 적힌 라이브러리”가 아니라 “제품 안에 들어간 코드”에서 터지기 때문이에요.

- 원본 소스코드를 외부로 보내지 않고 코드 지문만 대조하는 방식도 현실적인 선택이에요. 임베디드 제조사 입장에선 펌웨어 소스가 핵심 지식재산이라, 보안 점검 때문에 외부 서버에 올리는 것 자체가 또 다른 리스크가 돼요.

- CycloneDX, SPDX, CVE, KEV를 한 흐름으로 묶는 건 규제 대응 시간을 줄이려는 의도예요. 개발팀은 구성 요소를 찾고, 보안팀은 취약점을 보고, 법무나 품질팀은 라이선스를 봐야 하니 결과물이 흩어지면 검토 비용이 확 늘어나거든요.

## 핵심 포인트

- 임베디드 소프트웨어에서 패키지 선언 없이 직접 복사된 오픈소스 코드를 탐지하는 데 초점을 맞춤
- CycloneDX 기반 소프트웨어 자재명세서, 취약점 정보, SPDX 라이선스 분석서를 단일 흐름으로 생성함
- 원본 소스코드를 외부 서버로 보내지 않고 코드 지문만 추출해 대조하는 방식을 강조함
- 국립표준기술연구소 취약점 데이터베이스, 오픈소스 취약점 데이터베이스, 알려진 악용 취약점 데이터를 함께 매핑함

## 인사이트

자동차·전력·제어기기 쪽 임베디드 개발은 웹 서비스처럼 의존성 파일만 보면 끝나는 세계가 아님. 공급망 보안 규제가 빡세지는 상황에서, ‘복붙된 오픈소스까지 증거로 잡아내는가’가 실제 컴플라이언스 비용을 가르는 포인트가 될 수 있음.