세온이앤에스, 임베디드 코드에서 숨은 오픈소스까지 잡는 SBOM 분석 도구 출시

• 세온이앤에스가 임베디드 소프트웨어용 오픈소스 분석 도구 Seon Code Analyzer를 출시함

  • 핵심은 패키지 의존성 파일만 보는 게 아니라, 소스코드 자체를 분석해 실제로 들어간 오픈소스를 찾는 방식임
  • 임베디드 제품은 오픈소스가 의존성 선언 없이 소스에 복사돼 들어가는 경우가 많아서, 기존 SCA 방식만으로는 빠지는 게 생김

• 이 도구가 노리는 문제는 요즘 규제 흐름과 딱 맞물려 있음

  • 미국 행정명령 14028, EU 사이버복원력법(CRA) 같은 흐름 때문에 SBOM 관리가 점점 필수가 되는 분위기임
  • 그런데 펌웨어 코드에서 오픈소스를 수작업으로 대조하는 건 보안팀·품질팀 입장에선 거의 노동집약 끝판왕임

• 분석 결과는 보안팀이 바로 쓸 수 있는 형태로 묶어서 나온다고 함

  • 국제 표준 CycloneDX 형식의 SBOM을 생성함
  • NVD·OSV 기반 CVE 취약점 정보를 붙이고, 미국 CISA의 알려진 악용 취약점(KEV)도 포함함
  • SPDX 기반 라이선스 컴플라이언스 리포트까지 한 번에 산출하는 구조임

• 원본 소스코드를 서버로 보내지 않는 설계도 강조 포인트임

  • 고객사의 핵심 코드(IP)를 직접 전송하지 않고, 코드의 디지털 지문을 사용해 대조하는 방식이라고 설명함
  • 보안 도구를 쓰려다가 오히려 소스 유출 리스크가 생기는 상황을 줄이려는 접근임

• 세온이앤에스는 국내에서 이런 형태의 임베디드용 통합 파이프라인이 드물다고 보고 있음

  • 일반 SCA 도구는 의존성 선언 파일을 읽는 쪽에 강함
  • Seon Code Analyzer는 복사·이식된 오픈소스까지 대조하고, SBOM·취약점·라이선스를 한 흐름으로 묶는 쪽을 내세움

• 회사 측은 OTA 환경에서 이 문제가 더 커진다고 봄

  • 임베디드 기기가 무선 업데이트(OTA)로 계속 바뀌면 “어떤 오픈소스가 어떤 버전으로 들어갔는지”를 수작업으로 추적하기 어려움
  • 코드 한 줄 단위의 근거와 표준 SBOM 자동화를 통해 규제 대응 비용과 보안 점검 비용을 같이 줄일 수 있다는 주장임

• 제품 데모는 7월 1일 수원 컨벤션센터에서 열리는 AID 2026에서 제공될 예정임

  • 세온이앤에스는 자동차 전장 중심의 임베디드 소프트웨어, 기능 안전, 보안 컨설팅, 국제 인증 대응을 해온 회사임
  • ASPICE, ISO 26262, ISO 21434 같은 자동차·임베디드 표준 대응 경험을 제품 배경으로 내세우고 있음

---

기술 맥락

• 임베디드에서 SBOM이 어려운 이유는 의존성이 항상 예쁘게 선언돼 있지 않기 때문이에요. 서버나 웹 프로젝트처럼 패키지 매니저 파일만 보면 끝나는 구조가 아니라, 특정 오픈소스 코드가 펌웨어 안에 직접 복사돼 들어가는 경우가 많거든요.

• 그래서 이 제품의 선택은 “매니페스트 분석”보다 “코드 지문 기반 대조”에 가까워요. 원본 소스 전체를 외부로 보내지 않고 디지털 지문을 쓰겠다는 건, 보안 분석을 하면서도 고객사의 핵심 코드 노출 부담을 줄이려는 판단이에요.

• CycloneDX, CVE, SPDX를 한 파이프라인에 묶는 것도 실무적으로 의미가 있어요. SBOM만 만들고 끝나면 문서가 되지만, 취약점과 라이선스 리스크까지 붙이면 배포 전 점검이나 규제 대응에서 바로 쓸 수 있는 자료가 되거든요.

• 특히 자동차 전장이나 OTA 업데이트가 있는 제품군에서는 버전 추적이 계속 누적돼요. 한 번 출시하고 끝나는 소프트웨어가 아니라 업데이트가 반복되기 때문에, 어떤 코드가 언제 들어갔는지 자동화하지 않으면 나중에 취약점 대응 비용이 확 커질 수 있어요.