에스코어 인사이트
원문에 앞서 국내 개발·보안 조직이 함께 점검할 만한 사항을 간단히 정리했습니다.
•
반입 지점을 정책 통제 지점으로 운영: 에어갭 경계를 통과하는 패키지, 컨테이너, 모델을 승인하기 전에 악성 여부뿐 아니라 구성요소, 라이선스, 출처와 정책 적합성까지 함께 확인합니다.
•
오프라인 SBOM 재평가 체계: 반입 시점에 생성한 SBOM을 기준선으로 보관하고, 승인된 채널로 취약점 인텔리전스를 정기 반입해 내부 소프트웨어를 다시 평가합니다.
•
AI 산출물 추적: AI가 선택한 의존성, 모델 가중치, 생성 코드가 어떤 출처와 버전에서 들어왔는지 별도 증적으로 남겨 이후 변경과 위험을 추적할 수 있게 합니다.
Sonatype 원문 번역
수년간 에어갭 환경은 기밀 시스템과 핵심 인프라를 보호하는 대표적인 방식으로 자리 잡았습니다. 네트워크를 분리해 접근 경로를 차단하면 위험도 줄어든다는 논리입니다. 이 원칙은 지금도 유효합니다. 에어갭은 설계 목적대로 작동합니다.
문제는 격리가 실패했다는 데 있지 않습니다. 격리만으로는 통제의 절반밖에 완성되지 않는다는 점입니다. 이동 경로는 막을 수 있어도 그 경로로 들어오는 내용물까지 검증해 주지는 않습니다.
오늘날 소프트웨어는 외부 공급업체가 제공하는 소스 코드, 컨테이너 이미지, 언어별 패키지, 그리고 갈수록 비중이 커지는 모델 가중치 형태로 들어옵니다. 위험은 바로 이 내용물에 숨어 있습니다.
두 가지 변화가 동시에 일어났다
첫째, 미 국방부는 속도를 높이기로 했습니다. 2026 AI 가속화 전략은 거버넌스 프레임워크보다 속도, 반복 개발, 작전 통합에 무게를 두고 미 국방부 최고디지털·인공지능실(CDAO)이 운영하는 7개 선도 프로젝트를 제시합니다. 국방부는 의도적으로 기조를 바꿨고 그렇게 판단할 만한 이유도 있습니다. 적의 역량은 우리의 검토가 끝날 때까지 기다려 주지 않기 때문입니다.
둘째, 연방정부의 소프트웨어 조달에 적용되는 최소 보증 기준이 낮아졌습니다. 2026년 1월 발표된 OMB Memorandum M-26-05는 보안 소프트웨어 확인서를 의무화한 기존 지침을 폐기하고 민간 기관이 위험을 바탕으로 자체 판단하는 방식으로 전환했습니다. 이제 확인서와 공통 양식은 모두 선택 사항입니다.
국가 안보 시스템은 사정이 다릅니다. ICD 503과 CNSSI 1253을 따르는 프로그램은 운영 승인 담당자의 승인을 받아야 하며, 1월 정책 변경도 이 인증 체계를 완화하지 않았습니다. 그렇다고 이들 프로그램이 모든 소프트웨어를 처음부터 직접 만드는 것은 아닙니다. 다른 조직과 마찬가지로 오픈소스 생태계와 상용 제품을 활용하고 공개 데이터로 학습한 모델도 점점 더 많이 사용합니다.
정부 전체의 조달 기준이 낮아져도 기밀 프로그램 자체의 엄격한 기준은 바뀌지 않습니다. 달라지는 것은 에어갭 경계에 도착하는 외부 소프트웨어의 보증 수준입니다.
이 두 변화가 겹치면서 임무 수행 체계에는 소프트웨어를 더 빨리 투입해야 하는 반면, 소프트웨어 공급망 상류에 적용되는 의무 검토는 1년 전보다 줄었습니다. 정책이 잘못됐다는 뜻은 아닙니다. 이제 이 통제 체계는 규정 준수가 아니라 엔지니어링 관점에서 필요성을 입증해야 합니다.
실제로 경계를 통과하는 것
분리 환경에 저절로 들어오는 소프트웨어는 없습니다. 소프트웨어는 인증된 크로스도메인 솔루션, 보증된 파일 전송 절차, 단방향 전송 장치인 데이터 다이오드, 허용된 경우에는 통제된 이동식 매체를 거쳐 반입됩니다. 방식은 달라도 전송은 모두 통제 지점에서 필요에 따라 한 건씩 이루어지며 건수도 파악할 수 있습니다. 연결된 환경에서 같은 수준의 통제를 구현하려면 막대한 비용이 들지만, 에어갭 환경은 처음부터 이런 구조를 갖추고 있습니다.
현재 반입 절차는 각 아티팩트의 악성코드 여부를 검사하고 파일 형식과 출처를 확인하며, 필요한 경우 두 명의 담당자가 교차 확인합니다. 그러나 소프트웨어의 구성을 확인하지는 않습니다. 콘텐츠 검사와 구성 분석은 별개의 영역입니다.
전송 과정에서 파일이 설명과 일치하고 알려진 악성코드 징후가 없는지는 확인할 수 있습니다. 하지만 내부 구성요소와 의존성, 취약점 현황을 파악하지 않은 소프트웨어도 반입될 수 있습니다. 출처와 기본 안전성은 확인하면서 정작 구성은 검증하지 않는 셈입니다.
현재 에어갭 환경으로 반입되는 아티팩트는 크게 네 종류로 나뉘며, 종류마다 관리 수준이 다릅니다.
첫 번째는 오픈소스 패키지입니다. 여기에는 AI 코딩 어시스턴트가 선택한 패키지도 포함됩니다. 코딩 어시스턴트는 생태계의 현재 상태가 아니라 특정 시점에 고정된 지식을 바탕으로 의존성을 추천합니다. 따라서 지난주에 등록된 타이포스쿼팅 패키지와 정상 패키지를 구별할 수 있는 장치가 없습니다. 과거에는 개발자가 패키지 이름을 직접 입력하는 과정이 뜻하지 않게 검토 단계가 되곤 했습니다. 이제 그 단계는 사라졌지만 이를 대신할 통제 장치는 마련되지 않았습니다.
두 번째는 모델 가중치입니다. 기밀 환경에서는 호스팅 API를 호출할 수 없어 자체 호스팅이 가능한 오픈 가중치 모델을 채택하고 있습니다. 이런 모델은 공개 허브에서 파일 형태로 들어오며 각각의 라이선스와 출처 이력, 의존성이 있습니다. 미 의회도 이 문제를 인식하고 있습니다. 2026 회계연도 국방수권법(FY2026 National Defense Authorization Act) 제6603조는 기밀 환경에서 공개 AI 모델을 사용하는 문제를 직접 다룹니다.
현재 모델 반입 여부는 주로 어느 국가에서 왔는지와 악성 여부를 기준으로 판단합니다. 반면 라이선스 상태, 학습 데이터의 출처, 내장된 의존성, 어느 버전의 가중치가 어느 구역에 반입됐는지를 구성 단위로 기록하는 곳은 거의 없습니다.
세 번째는 자격증명입니다. 지난 1년 동안 발생한 침해 사고 가운데 특히 시사적인 한 사례에서는 자율 에이전트가 13시간도 안 돼 단일 파드의 코드 실행 권한에서 여러 클러스터의 관리자 권한까지 확보했습니다. 유효한 토큰을 발급하고 재사용한 뒤 다시 발급하는 방식을 주로 썼습니다. 취약한 오픈소스 구성요소가 원인은 아니었고 SBOM으로도 공격 자체를 막을 수는 없었습니다.
외부로 빠져나가는 경로는 인터넷에 연결된 아티팩트 프록시였지만, 제대로 분리된 환경에는 이런 경로가 없습니다. 필요한 것은 격리를 강화하는 일이 아니라 격리 환경이 무엇을 받아들이는지 볼 수 있는 가시성입니다.
네 번째는 AI가 실제로 만든 결과물의 기록입니다. 아직 관리 체계가 제대로 자리 잡지 않았고 변화 속도는 네 종류 가운데 가장 빠릅니다. 최근 CISA, NSA, FBI와 국제 파트너가 함께 발표한 지침은 2021년 NTIA의 SBOM 최소 요소 지침을 대체하며, AI를 포함한 일부 소프트웨어 유형에는 추가 항목이 필요할 수 있다고 명시합니다.
임무 속도에 맞춰 예방하고 통제하고 입증하기
분리 환경에서 역량을 더 빨리 배치하라는 요구를 받는 사업 담당 조직이라면 지금부터가 중요합니다.
예방은 납품을 늦추는 관문이 아닙니다. 가장 적은 비용으로 문제를 막는 방법입니다. 반입 단계에서 악성 또는 존재하지 않는 구성요소를 차단하는 데는 몇 초면 충분합니다. 승인 검토 중에 발견하면 릴리스 주기 하나를 잃습니다. 분리 구역에 배포한 뒤 발견하면 반입 주기보다 빠르게 보완할 수 없습니다. 매주 정기적으로 업데이트하는 프로그램이라면 며칠이 걸리지만, 전송을 예외적으로만 허용하는 프로그램이라면 한 분기까지 걸릴 수 있습니다. 연결성이 낮을수록 사전 예방의 비용 효과는 커집니다.
거버넌스는 발견 항목이 늘어나도 인력 문제로 번지지 않게 해 줍니다. 최근 오픈소스 비행 제어 스택을 분석한 결과, 지원 툴체인에서 정책 위반 47건이 발견됐습니다. 가장 심각한 항목은 지원이 종료된 암호화 라이브러리의 치명적 취약점이었습니다. 하지만 실제 펌웨어에 연결되지 않는 빌드 단계의 테스트 의존성으로 확인됐습니다. 이 판단을 VEX 주석으로 남기고 근거와 함께 해당 항목을 억제했습니다.
분리 환경에서는 이 구분이 특히 중요합니다. 불필요한 보완 작업을 한 번 할 때마다 경계를 넘는 통제된 전송이 추가로 필요할 수 있기 때문입니다.
실제 바이너리에 포함된 구성요소만 검사하자 정책 위반은 0건이었습니다. 모든 구성요소가 취약점 데이터의 식별자와 일치했지만 발견 항목은 하나도 없었습니다. 깨끗하다고 판단하기 쉽지만 사실은 달랐습니다.
구성요소의 약 3분의 1은 원 저장소가 버전을 명시하지 않아 확인 가능한 버전 정보가 없었습니다. 버전이 자리표시자뿐인 구성요소는 이름을 식별할 수 있어도 취약 버전 범위에 해당하는지는 판단할 수 없습니다. 구성요소가 무엇인지는 알지만 평가할 수 없는 상태입니다. 버전도 범위도 없으니 발견 항목과 위반도 0건이고 화면은 녹색으로 표시됩니다.
그래서 증거가 필요합니다. SBOM은 단순히 제출용으로 만드는 산출물이 아닙니다. 자체 도구가 어디까지 확인할 수 있었고 무엇을 놓쳤는지 보여 주는 기록입니다. 분리 환경에서는 실제로 무엇을 배포했는지 오래 남길 수 있는 유일한 기록이기도 합니다. SBOM이 없으면 녹색 대시보드가 정말 문제가 없는지, 정보가 빠져 녹색으로 보이는지 구분할 수 없습니다.
연결이 없을 때 '지속적'이라는 말의 의미
에어갭 보안을 다루는 거의 모든 벤더가 지속적 모니터링을 약속하지만 구체적인 방법을 설명하는 곳은 드뭅니다. 지속적 모니터링에는 새로운 정보가 계속 들어와야 합니다. 분리 구역에는 전송이 이뤄질 때만 새 정보가 도착합니다.
소프트웨어를 반입하는 통제 채널로 소프트웨어 관련 인텔리전스도 들여올 수 있습니다. 서명된 취약점 데이터를 정해진 주기에 맞춰 데이터 다이오드, 보증된 전송 절차 또는 승인된 매체로 반입한 뒤 고정된 BOM과 대조해 다시 평가하는 방식입니다. 네트워크 연결이 없는 환경에서 지속적 재검증은 이렇게 이루어집니다.
이때 BOM은 정적인 스냅샷에 머물지 않습니다. 외부에서 새로운 사실이 확인될 때마다 다시 평가하는 기준이 됩니다. 반입 당시 별문제가 없던 구성요소도 내부에서는 아무 변화가 없었는데 어느 날 가장 시급한 대응 대상이 될 수 있습니다.
현재 경계가 허용하는 반입 주기에 맞추면 지금도 구현할 수 있습니다. 다만 내부에 무엇이 있는지 모르면 시작할 수 없습니다.
아키텍처 관점의 핵심
오프라인이라고 해서 안전한 것은 아닙니다. 이미 오래전부터 알려진 사실입니다.
에어갭은 소프트웨어 공급망을 없애지 않습니다. 다만 공급망의 모든 흐름을 경계에 집중시킵니다. 모든 의존성, 모델, 업데이트, 취약점 인텔리전스는 여전히 경계를 넘어야 합니다.
이 반입 지점은 기밀 프로그램에서 가장 중요한 보안 통제 지점입니다. 현재는 출처와 기본 안전성을 확인하는 데 쓰입니다. 여기에 구성 분석과 정책 적용을 더하고 반입된 모든 것과 이를 바탕으로 만든 모든 것의 출처를 기록할 수 있습니다. 이 작업에 필요한 도구는 경계 안에서 완전히 작동해야 하며, 프로그램이 신뢰하는 기존 경로로 업데이트할 수 있어야 합니다.
그러려면 반입 결정을 행정 절차가 아니라 엔지니어링 통제로 다뤄야 합니다. 더 넓은 공급망의 조달 기준은 낮아지는 반면 AI 기반 역량은 전시 속도로 배치해야 하는 상황입니다. 이는 규정 준수를 위한 주장이 아닙니다. 일정을 지킬 수 있는 유일한 방법입니다.
Sonatype이 분리 환경에서 소프트웨어 공급망 가시성과 거버넌스를 구현하는 방법은 Sonatype Air-Gapped Environment(SAGE)에서 확인할 수 있습니다.
에스코어는 Sonatype 공식 파트너로서 소프트웨어 공급망 보안 및 오픈소스 거버넌스 구축을 지원합니다.
도입이나 구축이 필요하시면 언제든 문의해 주세요.
지원 솔루션: Nexus Repository · Repository Firewall · Lifecycle · Sonatype Guide