소스 코드도 서명하는 시대가 왔다

여러분이 오픈소스 라이브러리를 npm install 혹은 pip install 한 번으로 가져올 때, 그 패키지가 정말 원작자가 배포한 것인지 확인해 본 적이 있으신가요? 2024~2025년을 거치며 소프트웨어 공급망 공격이 급증하면서, 업계는 마침내 코드 자체에 '신원'을 부여하는 기술, 소프트웨어 공급망 보안(Software Supply Chain Security) 을 개발 표준으로 격상시키고 있습니다. 프로그래밍을 막 시작한 분들도 곧 마주치게 될 흐름이기에, 오늘은 그 핵심을 짚어 드립니다.

왜 지금인가

2020년 SolarWinds 사태 이후 공급망 공격은 국가·기업 모두에게 실존적 위협으로 떠올랐습니다. 악의적 행위자는 인기 오픈소스 패키지에 악성 코드를 몰래 심어 수천 개의 하위 서비스를 한꺼번에 감염시킵니다. 이 방식은 방화벽이나 침입 탐지 시스템을 우회하기 때문에 기존 보안 도구로는 사실상 탐지가 어렵습니다.

Sonatype의 「2024 State of the Software Supply Chain」 보고서에 따르면, 오픈소스 생태계를 겨냥한 악성 패키지 수는 전년 대비 156% 증가했으며, 2024년 한 해에만 50만 개 이상이 탐지되었습니다.

미국 정부는 2021년 행정명령(EO 14028)을 통해 연방 조달 소프트웨어에 SBOM(Software Bill of Materials, 소프트웨어 구성 목록) 제출을 의무화했고, EU의 사이버복원력법(Cyber Resilience Act) 역시 2025년부터 단계적으로 시행에 들어갔습니다. 규제가 현실이 된 것입니다.

코드에 서명하고, 출처를 증명한다

공급망 보안의 실체는 세 가지 핵심 기술 축으로 이루어집니다.

Sigstore: 코드 서명의 민주화

전통적인 코드 서명은 고가의 인증서와 복잡한 키 관리를 요구했습니다. Sigstore는 이를 혁파한 오픈소스 프로젝트입니다. 개발자가 GitHub Actions 등 CI 환경에서 빌드하면, OpenID Connect(OIDC) 토큰을 활용해 단기 서명 인증서를 자동 발급받고, 그 기록을 공개 투명성 로그(Rekor)에 불변 저장합니다. 별도의 비밀 키 관리 없이도 "이 아티팩트는 이 사람이, 이 시점에, 이 파이프라인에서 빌드했다"는 사실을 누구나 검증할 수 있게 됩니다. PyPI와 npm은 이미 Sigstore 기반 서명을 기본 지원 방향으로 전환하고 있습니다.

SBOM: 재료 목록처럼 소프트웨어를 해부하다

식품에 성분표가 있듯, SBOM은 소프트웨어에 포함된 모든 오픈소스 컴포넌트, 버전, 라이선스, 의존성을 기계 가독 형태로 기술한 문서입니다. SPDX와 CycloneDX가 현재 양대 표준 포맷으로 자리 잡았으며, syft, cdxgen 같은 도구로 기존 프로젝트에서도 손쉽게 생성할 수 있습니다. SBOM이 있으면 Log4Shell처럼 특정 라이브러리 취약점이 발표되었을 때 영향받는 서비스를 즉시 식별할 수 있습니다.

SLSA: 빌드 과정 자체를 신뢰하다

SLSA(Supply-chain Levels for Software Artifacts, 살사)는 구글이 제안하고 OpenSSF가 관리하는 보안 프레임워크입니다. 소스 코드 관리부터 빌드 환경 격리, 검증 가능한 프로비넌스(provenance, 출처 증명) 생성까지 4단계 성숙도 레벨을 제시합니다. 쉽게 말해, "코드가 어떤 경로로 배포됐는지"를 제3자가 감사할 수 있게 만드는 체계입니다.

현장의 변화

Google은 내부 모노레포 빌드 시스템 전반에 SLSA Level 3 이상을 적용하고 있으며, Android 오픈소스 프로젝트(AOSP)의 배포 아티팩트에도 Sigstore 서명을 단계적으로 도입했습니다.

Python 패키지 생태계에서는 PyPI 운영 주체인 PSF(Python Software Foundation)가 2024년부터 신규 패키지에 Sigstore 기반 Trusted Publisher 서명을 도입했습니다. 현재 주요 패키지 상당수가 GitHub Actions 파이프라인과 연동해 자동 서명을 제공하고 있어, pip install 단계에서 서명 검증이 가능해졌습니다.

국내에서도 변화는 감지됩니다. 금융보안원은 2025년 금융권 SW 개발·납품 가이드라인 개정을 통해 SBOM 제출 권고 사항을 명시하였으며, 공공 조달 소프트웨어 검증 체계에 공급망 보안 항목을 추가하는 논의가 진행 중입니다.

시사점: 우리가 갖춰야 할 것

• 의존성을 직접 눈으로 확인하는 습관: npm ls, pip list, gradle dependencies 명령어로 내 프로젝트의 전체 의존성 트리를 한 번쯤 출력해 보세요. 생각보다 많은 간접 의존성에 놀라게 됩니다.
• SBOM 생성 도구를 학습 과정에 포함: syft 또는 cdxgen으로 실습 프로젝트의 SBOM을 직접 뽑아 보는 경험이 포트폴리오에도 차별점이 됩니다.
• CI/CD 파이프라인에서 서명 실습: GitHub Actions와 Sigstore의 cosign 도구를 연동해 컨테이너 이미지에 서명하는 워크플로를 구성해 보세요. 실무 감각을 익히기에 충분한 난이도입니다.
• CVE 대응 사고방식 훈련: SBOM이 갖춰져 있으면 새 취약점 공시(CVE) 즉시 영향 범위를 파악할 수 있습니다. OSV(Open Source Vulnerabilities) 데이터베이스를 정기적으로 확인하는 루틴을 만들어 두세요.
• 라이선스 컴플라이언스도 공급망 문제: SBOM은 보안뿐 아니라 GPL·MIT 등 라이선스 충돌 여부도 자동 검사해 줍니다. 상업 프로젝트 진입 전 반드시 이해해야 할 영역입니다.

맺음말

코드를 작성하는 것만큼, 그 코드가 어디서 왔고 어디로 가는지를 증명하는 능력이 개발자의 필수 역량으로 자리 잡고 있습니다. 공급망 보안은 더 이상 보안 엔지니어 전담 영역이 아닙니다. pip install 한 줄을 치는 순간부터 이미 공급망의 소비자이자 참여자가 된다는 사실을 기억하시길 바랍니다. 오늘 당장 여러분의 프로젝트에서 syft .을 실행해 보는 것, 그것이 첫걸음입니다.

참고 자료

• Sonatype, 「2024 State of the Software Supply Chain Report」
• OpenSSF, 「SLSA Framework Documentation」(slsa.dev)
• The White House, 「Executive Order 14028 on Improving the Nation's Cybersecurity」, 2021
• Python Software Foundation, PyPI Trusted Publishers 공식 문서 (docs.pypi.org)
• 금융보안원, 「금융분야 소프트웨어 공급망 보안 가이드」, 2025
• CISA, 「Software Bill of Materials (SBOM) Resources」(cisa.gov)

테크창 연구팀 | 인천대학교 창의인재개발학과 전공심화연구모임
본 칼럼은 AI 보조로 작성되었으며, 수치·출처는 참고용입니다.