오늘날 금융, 국방, 의료 등 보안이 중요한 분야에서는 외부 네트워크와 물리적으로 분리된 에어갭(Air-gap) 환경을 운영합니다. 에어갭 환경에 소프트웨어를 반입하려면 보안 검증을 위해 SBOM(Software Bill of Materials, 소프트웨어 자재 명세서)을 제출해야 합니다. 최근 국내에서는 공공기관을 중심으로 SBOM 제출 요구가 점점 확대되고 있습니다.
SBOM은 소프트웨어에 포함된 모든 라이브러리, 버전, 라이선스 정보를 기록한 목록입니다. 문제는 SBOM을 수동으로 작성하는 과정이 비효율적이라는 점입니다. 이미지당 작업에 1-2시간 이상 걸리고, 소프트웨어 버전이 업데이트될 때마다 내용을 반복 수정해야 합니다.
그러나 Syft와 n8n으로 SBOM 생성을 자동화하면 이 과정을 크게 간소화할 수 있습니다. 작업 시간을 수 분 내로 단축하고, 인적 오류를 최소화하며, 컴플라이언스 요건을 신속하게 충족할 수 있습니다. 이 글에서는 에어갭 환경을 위한 SBOM 생성 자동화의 필요성과 구현 방법, 확장 아이디어를 살펴보겠습니다.
에어갭 환경을 위한 SBOM 생성 자동화의 필요성
먼저 에어갭 환경 맥락에서 SBOM 생성 자동화가 왜 필요한지, 그 필요성이 어떤 배경에서 비롯됐는지 알아보겠습니다.
수동 SBOM 작성의 비효율 해소
에어갭 환경은 외부 네트워크와 물리적으로 분리된 폐쇄망입니다. 이 환경에서는 소프트웨어를 반입한 뒤, 외부에서 라이브러리를 다운로드하거나 실시간으 로 패치를 적용하기 어렵습니다. 따라서 소프트웨어 반입 전 단계에서 철저한 보안 검증이 필수이며, 이를 위해 SBOM을 제출해야 합니다.
그러나 SBOM을 수동으로 작성하는 과정은 번거롭습니다. 예를 들어, GitLab과 같은 복합 애플리케이션 이미지는 베이스 OS, 런타임(예: Ruby·Node.js), 수백 개의 오픈 소스 라이브러리로 구성됩니다. 이러한 구성 요소를 직접 추적해 SBOM을 작성하면 이미지당 작업에 1-2시간이 소요됩니다.
반면에 Syft와 같은 자동화 도구를 사용하면, 이미지 크기와 환경에 따라 수초-수 분 내에 SBOM을 생성할 수 있습니다. 이로써 작업 시간을 대폭 줄이고, 품질이 일관되며 재현성이 높은 SBOM을 자동으로 확보할 수 있습니다. 그 결과, 반입 검증 과정에서 필수 정보 누락, 인적 오류 가능성을 최소화할 수 있습니다.
규제 대응 속도 향상
요즘 국내외에서는 SBOM 제출을 법적·정책적으로 요구하는 추세입니다. 미국은 2021년 행정명령 EO 14028 이후, 연방 조달 소프트웨어에 NIST SSDF(보안 개발 기준) 준수와 공급자 자체확인서 제출을 요구하고 있습니다. 또한 OMB M-22-18로 소프트웨어의 중요도에 따라 연방 기관이 SBOM 제출을 요구할 수 있는 근거를 명시하고 있습니다.
국내에서도 정부·공공기관·금융권을 중심으로 SBOM 관련 요구와 가이드라인이 확대되고 있습니다. 과학기술정보통신부, 한국인터넷진흥원, 국가정보원에서는 소프트웨어 공급망 보안 강화 차원에서 SBOM 작성·관리를 권고합니다. 금융권에서도 금융보안원을 중심으로 SBOM 관리 필요성을 강조하고 관련 가이드라인을 마련하고 있습니다.
컴플라이언스 담당자는 보안 감사·계약·사고 조사 시 SBOM을 요구할 수 있습니다. 그러나 SBOM을 수동으로 생성·정리해 제출하려면, 조직의 프로세스에 따라 수 시간에서 수일 걸릴 수 있습니다. 반면에 SBOM 생성을 자동화하고 중앙 저장·인덱싱 체계를 도입하면, 과거에 생성된 SBOM을 빠르게 조회·추출해 즉시 제출할 수 있습니다. 이는 감사·계약·사고 대응 시간을 크게 줄여줍니다.
선제적 보안 대응
오늘날 소프트웨어는 다수의 오픈 소스 구성 요소에 의존하고 있습니다. 이로써 공격 표면이 확대되고 공급망 공격 위험은 더 커졌습니다. 대표 사례인 Log4j 취약점(CVE-2021-44228)은 2021년 전 세계적으로 광범위한 영향을 미쳤습니다. 최근 npm 생태계에서는 악성 코드가 패키지 의존성으로 전파되는 공급망 공격도 지속적으로 보고되고 있습니다.
에어갭 환경에서는 소프트웨어를 반입한 뒤, 수정하기가 어렵습니다. 이에 Syft로 자동 생성한 SBOM을 Grype와 같은 취약점 스캐너와 연동하면 소프트웨어를 반입하기 전에 오픈 소스의 알려진 취약점을 사전에 탐지하고, 원활하게 대응할 수 있습니다.
자동 생성된 SBOM은 오픈 소스 구성 요소와 버전을 빠르고 명확하게 파악하도록 지원합니다. 이는 취약점의 영향 범위를 파악하고 대응의 우선순위를 신속히 결정하는 데 핵심 자료로 활용할 수 있습니다. 이로써 에어 갭 환경에 소프트웨어를 안전하게 반입하는 데 도움이 됩니다.
Syft·n8n 기반 SBOM 생성 자동화 실습
지금부터 Syft와 n8n을 활용해 SBOM 생성 과정을 자동화하는 실습을 진행하겠습니다. 이미지 다운로드부터 SBOM 생성, 파일 업로드까지 전 과정을 하나의 워크플로로 구성하는 방법을 다룹니다.
이번 섹션에서 설명하는 워크플로와 스크립트는 예시입니다. 실제 환경에서는 시스템 구성, 도구 버전, 경로 설정에 따라 수정이 필요할 수 있습니다.
시나리오: 에어갭 환경 Docker 이미지 반입, SBOM 생성
이 시나리오에서는 에어갭 환경을 대상으로, Docker 이미지 반입과 SBOM 생성 절차를 자동화하는 방법을 살펴봅니다.
상황 가정
에어갭 환경에 Docker 이미지를 정기적으로 반입해야 하는 상황을 가정합니다. 이미지 버전이 업데이트될 때마다 새로운 버 전으로 재반입하고, 매번 SBOM을 작성해 제출해야 합니다.
문제점
외부에서 작업할 때는 노트북 PC를 사용할 때가 많아 네트워크 속도가 불안정하거나 느릴 수 있습니다. 이는 대용량 Docker 이미지 다운로드와 SBOM 생성 작업에 지장을 줄 수 있습니다. 또한 작업 중 네트워크가 끊기면 처음부터 다시 시작해야 해 번거롭습니다.
해결 방안
안정적인 네트워크 환경을 갖춘 n8n 서버에서 워크플로를 구성하면 이러한 문제를 해결할 수 있습니다. 서버는 24시간 안정적으로 운영되며, 고속 네트워크에 연결돼 작업을 빠르고 안정적으로 수행할 수 있습니다. 이제 n8n을 활용해 SBOM 생성을 자동화하는 워크플로를 구축하겠습니다.
사전 준비: 필수 도구 설치
워크플로를 실행하기 전에 n8n 서버에 다음 도구를 설치해야 합니다.
- Docker: 컨테이너 이미지를 다운로드하고 관리
- Syft: Docker 이미지에서 SBOM을 자동 생성
설치 확인
# Docker 설치 확인
docker --version
# Syft 설치 확인
syft version
워크플로 구성
이제 n8n으로 SBOM 생성과 업로드 과정을 자동화하는 워크플로를 단계별로 구성합니다.
전체 워크플로 개요
이 워크플로는 다음과 같이 동작합니다.
- Execute workflow: 사용자가 수동으로 워크플로 시작
- SSH 노드 (execute: command): Docker 이미지 다운로드, SBOM 생성
- SSH 노드 (download: file): 생성된 SBOM 파일을 n8n으로 가져오기
- Upload file (upload: file): Google Drive에 SBOM 업로드
마우스로 클릭해 워크플로를 수동으로 실행하고, 자동 생성된 SBOM 결과물을 Google Drive에 저장할 수 있습니다.

SSH 노드 (execute: command)
n8n의 SSH 노드는 원격 서버에서 명령을 실행할 수 있습니다. 여러 명령을 순차적으로 실행하려면 세미콜론(;)으로 구분해 명령어를 한 줄로 작성해야 합니다.
- SSH 노드는 n8n 서버 자체가 아닌, SSH로 연결된 원격 서버에서 명령을 실행합니다.
- 생성된 SBOM 파일은 원격 서버에 저장되며, 이후 ‘download: file’ 노드를 통해 n8n으로 가져옵니다.
docker pull alpine:latest; syft alpine:latest --output cyclonedx-json@1.5=/Users/jaehun/sbom.json
이 명령어는 두 단계를 자동으로 수행합니다.
alpine:latest이미지를 다운로드- 다운로드한 이미지의 SBOM을 CycloneDX 1.5 형식으로 생성
SSH 노드 (download: file)
SSH 노드의 download: file 작업을 사용해 생성된 SBOM 파일을 다운로드합니다. 이 노드를 실행하면 SBOM 파일이 Binary 데이터($binary.data) 형태로 다음 노드에 전달됩니다. 이후 파일 업로드 단계에서 그대로 사용할 수 있습니다.

Upload file (upload: file)
전달받은 파일을 원하는 Google Drive 위치에 업로드합니다. 이 노드는 OAuth2 인증 또는 서비스 계정 인증이 설정돼 있어야 합니다.