--- title: "세온이앤에스, 임베디드 코드에서 숨은 오픈소스까지 잡는 SBOM 분석 도구 출시" published: 2026-06-29T00:05:02.843Z canonical: https://jeff.news/article/4369 --- # 세온이앤에스, 임베디드 코드에서 숨은 오픈소스까지 잡는 SBOM 분석 도구 출시 세온이앤에스가 임베디드 소스코드 안에 직접 복사돼 들어간 오픈소스까지 찾아내는 Seon Code Analyzer를 출시했다. 의존성 파일만 보는 일반 소프트웨어 구성 분석(SCA)과 달리 코드 자체의 디지털 지문을 대조해 CycloneDX SBOM, CVE 취약점, SPDX 라이선스 리포트를 한 번에 만든다는 게 핵심이다. - 세온이앤에스가 임베디드 소프트웨어용 오픈소스 분석 도구 `Seon Code Analyzer`를 출시함 - 핵심은 패키지 의존성 파일만 보는 게 아니라, 소스코드 자체를 분석해 실제로 들어간 오픈소스를 찾는 방식임 - 임베디드 제품은 오픈소스가 의존성 선언 없이 소스에 복사돼 들어가는 경우가 많아서, 기존 SCA 방식만으로는 빠지는 게 생김 - 이 도구가 노리는 문제는 요즘 규제 흐름과 딱 맞물려 있음 - 미국 행정명령 14028, EU 사이버복원력법(CRA) 같은 흐름 때문에 SBOM 관리가 점점 필수가 되는 분위기임 - 그런데 펌웨어 코드에서 오픈소스를 수작업으로 대조하는 건 보안팀·품질팀 입장에선 거의 노동집약 끝판왕임 - 분석 결과는 보안팀이 바로 쓸 수 있는 형태로 묶어서 나온다고 함 - 국제 표준 `CycloneDX` 형식의 SBOM을 생성함 - NVD·OSV 기반 CVE 취약점 정보를 붙이고, 미국 CISA의 알려진 악용 취약점(KEV)도 포함함 - SPDX 기반 라이선스 컴플라이언스 리포트까지 한 번에 산출하는 구조임 > [!IMPORTANT] > 임베디드 쪽에서 중요한 포인트는 “의존성 파일에 없으면 안 쓴 것”이 아니라는 점임. 코드에 복사돼 들어간 오픈소스까지 잡아야 SBOM이 실제 보안 자산이 됨. - 원본 소스코드를 서버로 보내지 않는 설계도 강조 포인트임 - 고객사의 핵심 코드(IP)를 직접 전송하지 않고, 코드의 디지털 지문을 사용해 대조하는 방식이라고 설명함 - 보안 도구를 쓰려다가 오히려 소스 유출 리스크가 생기는 상황을 줄이려는 접근임 - 세온이앤에스는 국내에서 이런 형태의 임베디드용 통합 파이프라인이 드물다고 보고 있음 - 일반 SCA 도구는 의존성 선언 파일을 읽는 쪽에 강함 - Seon Code Analyzer는 복사·이식된 오픈소스까지 대조하고, SBOM·취약점·라이선스를 한 흐름으로 묶는 쪽을 내세움 - 회사 측은 OTA 환경에서 이 문제가 더 커진다고 봄 - 임베디드 기기가 무선 업데이트(OTA)로 계속 바뀌면 “어떤 오픈소스가 어떤 버전으로 들어갔는지”를 수작업으로 추적하기 어려움 - 코드 한 줄 단위의 근거와 표준 SBOM 자동화를 통해 규제 대응 비용과 보안 점검 비용을 같이 줄일 수 있다는 주장임 - 제품 데모는 7월 1일 수원 컨벤션센터에서 열리는 `AID 2026`에서 제공될 예정임 - 세온이앤에스는 자동차 전장 중심의 임베디드 소프트웨어, 기능 안전, 보안 컨설팅, 국제 인증 대응을 해온 회사임 - ASPICE, ISO 26262, ISO 21434 같은 자동차·임베디드 표준 대응 경험을 제품 배경으로 내세우고 있음 --- ## 기술 맥락 - 임베디드에서 SBOM이 어려운 이유는 의존성이 항상 예쁘게 선언돼 있지 않기 때문이에요. 서버나 웹 프로젝트처럼 패키지 매니저 파일만 보면 끝나는 구조가 아니라, 특정 오픈소스 코드가 펌웨어 안에 직접 복사돼 들어가는 경우가 많거든요. - 그래서 이 제품의 선택은 “매니페스트 분석”보다 “코드 지문 기반 대조”에 가까워요. 원본 소스 전체를 외부로 보내지 않고 디지털 지문을 쓰겠다는 건, 보안 분석을 하면서도 고객사의 핵심 코드 노출 부담을 줄이려는 판단이에요. - CycloneDX, CVE, SPDX를 한 파이프라인에 묶는 것도 실무적으로 의미가 있어요. SBOM만 만들고 끝나면 문서가 되지만, 취약점과 라이선스 리스크까지 붙이면 배포 전 점검이나 규제 대응에서 바로 쓸 수 있는 자료가 되거든요. - 특히 자동차 전장이나 OTA 업데이트가 있는 제품군에서는 버전 추적이 계속 누적돼요. 한 번 출시하고 끝나는 소프트웨어가 아니라 업데이트가 반복되기 때문에, 어떤 코드가 언제 들어갔는지 자동화하지 않으면 나중에 취약점 대응 비용이 확 커질 수 있어요. ## 핵심 포인트 - 의존성 선언 없이 복사된 오픈소스까지 코드 분석으로 탐지 - CycloneDX SBOM, NVD·OSV 기반 CVE, CISA KEV, SPDX 라이선스 리포트를 단일 파이프라인으로 산출 - 원본 소스 대신 디지털 지문만 사용해 고객사 핵심 코드 유출 우려를 낮추는 구조 - 자동 검토와 증거 점수로 보안·품질팀의 수작업 부담을 줄이는 방향 ## 인사이트 임베디드 쪽은 패키지 매니페스트가 깔끔하게 남아 있는 웹·서버 생태계와 달라서, 복붙된 오픈소스 추적이 진짜 골칫거리다. 자동차 전장, 펌웨어, OTA 업데이트가 걸린 조직이라면 SBOM을 문서 작업이 아니라 코드 추적 문제로 봐야 하는 흐름이 더 강해질 듯하다.