우리가 쓰는 소프트웨어, 정말 믿을 수 있을까요
요즘 소프트웨어 개발에서 가장 뜨거운 보안 주제를 하나 꼽으라면 단연 '공급망 보안'이에요. 공급망(supply chain)이 뭐냐면, 소스 코드가 작성되고, 빌드되고, 패키징되고, 배포돼서 사용자에게 도달하기까지의 전체 과정을 말해요. 우리가 npm install이나 pip install을 칠 때마다 이 공급망을 통째로 신뢰하고 있는 셈인데요, 최근 몇 년간 이 신뢰가 반복적으로 배신당했어요. 2020년 솔라윈즈(SolarWinds) 사태에서는 빌드 서버가 해킹돼서 정식 서명이 붙은 업데이트에 백도어가 심겼고, 2024년에는 압축 라이브러리 xz-utils에 수년에 걸친 위장 기여로 백도어가 삽입될 뻔했죠. npm 생태계에서는 인기 패키지 관리자의 계정을 탈취해 악성 코드를 배포하는 사건이 끊이지 않고 있고요.
이런 배경에서 다시 주목받는 프로젝트가 in-toto예요. 뉴욕대학교의 보안 연구실에서 시작돼 지금은 CNCF(클라우드 네이티브 컴퓨팅 재단)에서 관리하는 오픈소스 프레임워크인데, 목표가 명확해요. '소프트웨어가 만들어지는 전 과정이 계획대로, 정해진 사람에 의해, 변조 없이 수행됐는지를 암호학적으로 검증하자'는 거예요.
어떻게 동작하냐면요
in-toto의 구조는 세 가지 개념으로 이해할 수 있어요.
첫째, 레이아웃(layout)이에요. 프로젝트 책임자가 '우리 소프트웨어는 이런 단계를 거쳐 만들어진다'는 설계도를 미리 정의하고 서명해요. 예를 들면 '1단계 코드 작성은 개발팀이, 2단계 테스트는 CI 서버가, 3단계 빌드는 빌드 서버가, 4단계 패키징은 릴리스 담당자가 한다'는 식이죠. 각 단계를 누가 수행할 수 있는지도 공개키로 지정해요. 이 수행 주체를 functionary라고 불러요.
둘째, 링크(link) 메타데이터예요. 각 단계가 실제로 수행될 때마다, 수행 주체가 '내가 이 입력을 받아서 이 출력을 만들었다'는 기록을 남기고 자기 키로 서명해요. 입력과 출력은 파일의 해시값으로 기록되기 때문에, 중간에 파일이 1바이트라도 바뀌면 다음 단계의 입력 해시와 안 맞아서 바로 들통나요.
셋째, 최종 검증이에요. 사용자나 배포 시스템은 레이아웃과 링크들을 모아서 전체 사슬을 검사해요. 정해진 단계가 모두 수행됐는지, 각 단계를 권한 있는 주체가 했는지, 단계와 단계 사이에서 산출물이 바뀌지 않았는지를 확인하는 거죠. 비유하자면 택배 상자에 붙은 봉인 스티커를 출발지부터 도착지까지 매 구간마다 확인하는 것, 또는 식품의 생산 이력 추적제와 비슷해요. '농장에서 식탁까지' 대신 '커밋에서 배포까지' 전 구간의 이력을 추적하는 거예요.
솔라윈즈 같은 공격에 이게 왜 효과적이냐면, 공격자가 빌드 서버 하나를 장악해도 다른 단계의 서명 키까지 모두 손에 넣지 않는 한 검증을 통과하는 변조를 만들 수 없기 때문이에요. 한 지점의 침해가 전체의 침해로 이어지지 않게 하는 구조인 거죠.
업계 맥락: 표준의 뼈대가 된 프로젝트
in-toto가 재미있는 건, 이름은 낯설어도 이미 업계 곳곳에 스며들어 있다는 점이에요. 구글이 주도한 공급망 보안 표준 SLSA의 출처 증명(provenance) 문서가 in-toto의 증명(attestation) 형식을 기반으로 하고 있고, GitHub Actions에서 제공하는 아티팩트 증명 기능도 이 형식을 써요. 서명 인프라를 쉽게 만들어주는 Sigstore 생태계와도 맞물려 돌아가고요. 말하자면 in-toto는 최종 사용자 도구라기보다, 공급망 보안 생태계의 공용 언어이자 뼈대 역할을 하고 있는 셈이에요. 비슷한 계열로는 소프트웨어에 들어간 구성 요소 목록을 만드는 SBOM이 있는데, SBOM이 '뭐가 들어 있는지'의 목록이라면 in-toto는 '어떻게 만들어졌는지'의 증명이라는 점에서 서로 보완 관계예요.
한국 개발자에게 주는 시사점
'우리 회사가 이걸 당장 도입해야 하나?' 싶을 수 있는데, 진입로는 생각보다 가까워요. GitHub Actions를 쓰고 있다면 아티팩트 증명 기능을 켜는 것만으로 in-toto 형식의 빌드 증명을 만들어볼 수 있거든요. 오픈소스 라이브러리를 배포하는 분들에게 특히 의미가 있고요. 금융권이나 공공 쪽 일을 하신다면 더 눈여겨볼 만해요. 미국과 유럽을 중심으로 소프트웨어 납품 시 공급망 증빙을 요구하는 규제가 강화되는 흐름이라, 국내에도 비슷한 요구가 들어오는 건 시간문제거든요. 지금은 개념과 용어를 익혀두고, CI/CD 파이프라인의 각 단계에서 '이 산출물이 변조되지 않았음을 어떻게 증명할까'라는 질문을 던져보는 것만으로도 충분한 출발이에요.
마무리
한 줄로 정리하면, 'in-toto는 소프트웨어가 만들어지는 모든 단계에 서명을 남겨 공급망 전체를 검증 가능하게 만드는 프레임워크'예요. 여러분 팀의 빌드 파이프라인은 어느 단계까지 신뢰를 검증하고 있나요? 의존성 패키지, 어디까지 믿고 계신가요?
🔗 출처: Hacker News