정보관리기술사 학습 노트
← 목록으로
보안·개인정보
#Sigstore#키리스 서명#소프트웨어 공급망 보안#투명성 로그#코드 서명
최종 업데이트 · 2026-11-04

Sigstore 기반 소프트웨어 아티팩트 키리스 서명과 투명성 로그

1. 개요

Sigstore는 개발자가 장기 보관하는 개인키 없이도 OpenID Connect(OIDC) 신원을 근거로 짧은 수명의 인증서를 발급받아 소프트웨어 아티팩트에 서명하고, 그 서명 사건을 공개 투명성 로그(transparency log)에 기록하여 누구나 검증·감사할 수 있게 하는 오픈소스 코드 서명 체계다.

소프트웨어 공급망 공격이 늘면서 "이 바이너리·컨테이너 이미지·패키지가 정말 신뢰할 수 있는 주체가 만들었는가"를 증명하는 문제가 중요해졌다. 전통적 코드 서명은 개발자나 조직이 개인키를 발급받아 오래 보관하고, 그 키로 산출물에 서명하는 방식이었다. 그러나 이 모델은 키를 안전하게 보관·회수·폐기하는 운영 부담이 크고, 키가 유출되면 과거·미래의 모든 서명이 한꺼번에 위협받는다. 또한 "서명이 존재한다"는 사실만으로는 그 서명이 언제, 어떤 신원으로, 위조 없이 만들어졌는지를 외부에서 독립적으로 확인하기 어렵다.

Sigstore는 이 문제를 두 축으로 재구성한다. 첫째, 장기 키 보관을 없애는 키리스(keyless) 서명이다. 서명 시점에만 임시 키 쌍을 만들고, 조직의 OIDC 신원(예: GitHub Actions 워크플로 신원, 구글·깃허브 계정)을 증명하면 인증기관이 수 분짜리 단기 인증서를 발급한다. 서명이 끝나면 개인키는 폐기되므로 "보관된 키의 유출"이라는 공격 표면 자체가 사라진다. 둘째, 서명 사건을 공개 추가 전용(append-only) 로그에 남기는 투명성이다. 서명 주체·인증서·시각이 변조 불가능한 로그에 기록되므로, 검증자는 인증서가 이미 만료되었더라도 "서명 당시 그 신원이 유효했다"는 점을 로그로 확인할 수 있다.

논술 답안에서 Sigstore를 단순한 "무료 서명 도구"로 설명하면 부족하다. 첫째, SBOM(구성요소 목록)·SLSA(생성 과정 증거)와 Sigstore(서명·신원 증명)의 역할 차이를 구분해야 한다. 둘째, "키가 없으니 더 안전하다"는 식으로 단정하지 말고, 신뢰가 OIDC 신원 공급자와 루트 신뢰 배포 체계로 이동했을 뿐임을 설명해야 한다. 셋째, 개발자 편의와 검증 강건성을 함께 고려한 단계적 도입 전략을 제시해야 한다.

가. 등장 배경과 필요성

첫 번째 배경은 키 관리의 구조적 한계다. GPG나 사설 PKI로 오픈소스 산출물에 서명하려면 각 프로젝트가 개인키를 생성·보관하고 만료·회수를 운영해야 한다. 현실에서는 키가 노트북이나 CI 설정에 평문으로 남거나, 담당자가 떠나며 분실되는 사례가 흔했다. Sigstore는 "서명할 때만 잠깐 존재하고 곧 버려지는 키"로 이 운영 부담과 유출 위험을 동시에 줄인다.

두 번째 배경은 배포 생태계의 서명 공백이다. npm, PyPI, 컨테이너 레지스트리처럼 매일 수백만 건이 배포되는 생태계에서, 산출물이 실제로 어느 소스·빌드에서 왔는지 검증 가능한 증거가 거의 없었다. Sigstore는 CI 워크플로의 신원에 서명을 묶어 "이 패키지는 이 저장소의 보호된 워크플로가 만들었다"는 식의 정책 검증을 가능하게 한다.

세 번째 배경은 독립적 감사 가능성 요구다. 공공·금융 조달과 각종 공급망 보안 규제·가이드라인은 서명 존재 여부뿐 아니라 "언제 누가 서명했는지"를 사후 추적할 수 있을 것을 요구한다. 공개 투명성 로그는 서명 주체가 사후에 "나는 서명한 적 없다"고 부인하기 어렵게 만들고(부인 방지), 악의적 서명이 끼어들면 로그 모니터링으로 탐지할 길을 연다.

나. 목표와 범위

Sigstore의 목표는 모든 취약점을 막는 것이 아니라, 서명을 쉽고 검증 가능하게 만들어 산출물의 출처 신뢰를 자동 판정할 수 있게 하는 것이다. 예를 들어 "운영에 배포되는 이미지는 승인된 저장소의 GitHub Actions 신원으로 서명되고, 그 서명이 공개 로그에 존재해야 한다"는 정책을 세우고, 검증 단계에서 자동으로 판정할 수 있다. 범위는 임시 키 생성, 신원 증명(OIDC), 단기 인증서 발급, 서명, 로그 기록, 루트 신뢰 배포, 배포 전 검증으로 이어진다. 반면 소스 코드 자체의 취약점, 빌드 격리 수준, 런타임 보호는 Sigstore 하나가 대신하지 않으므로 SLSA·SBOM·런타임 보안과 함께 설계해야 한다.

2. Sigstore의 핵심 구성요소와 구조

Sigstore를 이해하는 핵심은 Fulcio(단기 인증서 발급 CA), Rekor(서명 투명성 로그), Cosign(클라이언트 도구), 그리고 TUF(The Update Framework)로 배포되는 루트 신뢰의 관계다. 서명자는 Cosign으로 임시 키를 만들고 OIDC로 신원을 증명해 Fulcio에서 단기 인증서를 받은 뒤, 아티팩트에 서명하고 그 사건을 Rekor에 올린다. 검증자는 TUF로 받은 Fulcio 루트 CA와 Rekor 공개키를 신뢰 기준으로 삼아, 서명·인증서·로그 항목을 함께 검사한다.

flowchart LR
    DEV["개발자 / CI 워크플로"] --> COSIGN["Cosign 클라이언트\n임시 키 생성·서명"]
    OIDC["OIDC 신원 공급자\n(GitHub·Google 등)"] --> COSIGN
    COSIGN --> FULCIO["Fulcio\n단기 인증서 발급 CA"]
    FULCIO --> COSIGN
    COSIGN --> REKOR["Rekor\n서명 투명성 로그"]
    COSIGN --> ART["서명된 아티팩트\n이미지·패키지·바이너리"]
    TUF["TUF 루트 신뢰 배포\n(루트 CA·로그 공개키)"] --> VERIFY["검증자 / 정책 엔진"]
    ART --> VERIFY
    REKOR --> VERIFY
    VERIFY --> DECIDE["배포 허용 또는 차단"]

가. Fulcio — 단기 인증서 발급 CA

Fulcio는 서명자의 OIDC 신원을 확인한 뒤, 그 신원을 임시 공개키에 묶은 수 분 수준의 단기 X.509 인증서를 발급하는 인증기관이다. 핵심은 인증서 수명이 매우 짧아 "장기 보관되는 비밀"이 존재하지 않는다는 점이다. 인증서가 만료되어도 서명의 유효성은 Rekor에 남은 "서명 당시 시각" 기록으로 보장된다. Fulcio는 신원값(예: 이메일, 워크플로 식별자)을 인증서 확장 필드에 담아, 검증자가 "누가 서명했는가"를 인증서만 보고 판정할 수 있게 한다. 예컨대 GitHub Actions에서 서명하면 저장소·워크플로·트리거 정보가 신원으로 박히므로, "이 저장소의 release 워크플로만 서명 주체로 허용"하는 정책이 가능하다.

나. Rekor — 서명 투명성 로그

Rekor는 서명 사건(서명값·인증서·시각 등)을 추가 전용·변조 불가 로그에 기록하는 투명성 로그다. 구조적으로는 머클 트리(Merkle tree) 기반이어서, 특정 항목이 로그에 포함되어 있다는 "포함 증명(inclusion proof)"과 로그가 과거를 조작하지 않았다는 "일관성 증명"을 암호학적으로 제공한다. 이로써 단기 인증서의 약점을 보완한다. 검증자는 "인증서가 지금 만료됐는가"가 아니라 "서명이 로그에 기록된 그 시점에 인증서가 유효했는가"를 본다. 또한 공개 로그는 감사·모니터링의 근거가 된다. 조직은 자신의 신원으로 올라온 서명을 모니터링하다가 예상치 못한 항목이 보이면 신원 오용을 조기에 탐지할 수 있다.

다. Cosign — 서명·검증 클라이언트

Cosign은 Fulcio·Rekor·OCI 레지스트리를 묶어 실제 서명과 검증을 수행하는 클라이언트 도구다. 컨테이너 이미지뿐 아니라 일반 파일(blob), SBOM·SLSA provenance 같은 증명서(attestation)도 서명·첨부할 수 있어, 서명과 공급망 메타데이터를 한 체계에서 다룬다. 키리스 모드가 기본 흐름이지만, 조직 상황에 따라 KMS 키나 하드웨어 키를 쓰는 방식도 지원해 점진적 전환을 돕는다. 검증 시에는 서명·인증서·로그 항목을 함께 확인하고, 허용 신원·발급자 등 정책 조건을 명시해 "서명만 있으면 통과"하는 느슨한 검증을 막는다.

라. TUF 루트 신뢰 — 신뢰의 출발점

검증이 성립하려면 Fulcio 루트 CA 인증서와 Rekor 공개키를 안전하게 획득·갱신해야 하는데, 이를 담당하는 것이 TUF(The Update Framework)다. TUF는 서명된 메타데이터로 루트 자료를 배포하고, 키 로테이션·폐기에도 중간자 공격에 견디도록 설계되어 있다. 즉 Sigstore의 신뢰는 "개발자의 장기 키"에서 "OIDC 신원 공급자 + TUF로 배포되는 루트 신뢰"로 이동한 것이지, 사라진 것이 아니다. 따라서 기술사 관점에서는 신원 공급자·루트 신뢰 배포 체계의 가용성과 무결성이 새로운 핵심 통제점이 된다.

3. 키리스 서명·검증 프로세스

키리스 서명은 "임시 키 생성 → 신원 증명 → 단기 인증서 발급 → 서명 → 로그 기록"의 순서로 진행되며, 검증은 이를 역으로 짚는다. 아래 시퀀스는 서명 주체(개발자/CI)와 Fulcio·Rekor·검증자 사이의 상호작용을 보여준다.

sequenceDiagram
    participant D as "서명자(CI/개발자)"
    participant O as "OIDC 공급자"
    participant F as "Fulcio(CA)"
    participant R as "Rekor(로그)"
    participant V as "검증자"
    D->>D: "임시 키쌍 생성"
    D->>O: "신원 인증 요청"
    O-->>D: "OIDC 토큰 발급"
    D->>F: "토큰 + 공개키 제출"
    F-->>D: "단기 인증서 발급(신원 바인딩)"
    D->>D: "아티팩트 서명"
    D->>R: "서명·인증서·시각 기록"
    R-->>D: "포함 증명(로그 항목)"
    V->>R: "서명 항목 조회·포함 증명 확인"
    V->>V: "인증서·신원·정책 검증 후 허용/차단"

서명 단계에서 가장 중요한 설계점은 임시 키의 즉시 폐기다. 서명이 끝나면 개인키를 메모리에서 버리므로 이후 탈취 대상이 없고, 신뢰는 "짧은 순간 유효했던 신원"으로 수렴한다. 로그 기록 단계에서는 서명 시각이 로그에 남아, 나중에 인증서가 만료돼도 "그 시점에 유효했다"는 점을 증명한다. 검증 단계에서는 (1) 서명이 아티팩트 digest와 일치하는가, (2) 인증서가 신뢰 루트 아래에서 발급됐는가, (3) 신원·발급자가 정책에 맞는가, (4) 서명 사건이 Rekor에 존재하는가를 모두 확인한다. 네 가지 중 하나라도 빠지면 "서명은 있으나 신뢰할 수 없는" 상태가 되므로, 검증 정책을 명시적으로 설계하는 것이 핵심이다.

4. 전통적 코드 서명·유사 체계와의 비교

Sigstore의 가치는 기존 PKI 코드 서명과의 차이가 생기는 이유를 짚을 때 분명해진다. 전통적 방식은 장기 키의 신뢰도가 높을 수 있으나 보관·회수 부담과 유출 시 광범위한 피해가 약점이다. Sigstore는 그 부담을 없애는 대신 신원 공급자·로그·루트 신뢰라는 외부 의존성을 받아들인다. 또한 certificate-transparency(인증서 투명성)가 TLS 인증서 오발급을 로그로 감시하는 것과 유사하게, Rekor는 "서명 사건"을 로그로 감시한다는 점에서 개념적 사촌 관계다.

구분 전통적 PKI 코드 서명 Sigstore(키리스)
키 보관 장기 개인키 보관 필요 임시 키, 서명 후 폐기
신뢰 근거 발급 CA + 보관 키 OIDC 신원 + TUF 루트 + 로그
유출 영향 과거·미래 서명 광범위 위협 보관 키 없음, 영향 국소화
감사 별도 체계 필요 공개 투명성 로그 내장
주요 부담 키 운영·회수 신원 공급자·로그 가용성 의존

구체 사례로, 컨테이너 이미지를 GitHub Actions에서 Cosign으로 키리스 서명하면 저장소·워크플로 신원이 인증서에 박히고 서명이 Rekor에 기록된다. 배포 클러스터의 정책 컨트롤러는 "승인된 저장소의 워크플로 신원 + 로그 존재"를 만족하는 이미지만 허용하도록 강제할 수 있다. 또 다른 사례로, SBOM이나 SLSA provenance를 attestation으로 서명해 이미지에 첨부하면, 공급망 메타데이터 자체의 위변조도 함께 검증된다. 이처럼 Sigstore는 단독 도구가 아니라 공급망 보안 스택의 서명·신원 계층으로 자리한다.

5. 심화 — 최신 동향과 생태계 적용

Sigstore는 2022년 10월 SigstoreCon에서 일반 공개(GA)를 선언했고, 이후 OpenSSF(Linux Foundation 산하)의 중립적 거버넌스 아래 운영되고 있다. GA 시점에 Cosign·Fulcio·Rekor의 v1.0을 기반으로 무료 공개 서명 서비스를 제공하며 99.5% 수준의 가용성 목표를 제시했다. 공개 자료에 따르면 GA 전후로 수천만 건의 서명이 로그에 기록되고 수만 개 프로젝트가 사용하는 등 빠르게 채택되었는데, 구체 수치는 발표 시점마다 다르므로 단정하기보다 추세로 인용하는 편이 안전하다.

생태계 적용도 넓어졌다. npm은 GA와 함께 서명 지원을 시작했고, Homebrew·PyPI·Maven 등도 Sigstore 연동을 도입·추진했으며, Kubernetes·Python 같은 대형 프로젝트가 릴리스 서명에 활용했다. 클라이언트 측에서는 플래그마다 URL을 지정하던 방식에서 서명 설정을 구성으로 관리하는 방향으로 진화했고, 서명 결과를 하나로 묶는 번들(bundle) 형식이 도입되는 등 포맷·도구가 계속 발전하고 있다. 다만 세부 릴리스·버전 동작은 시점에 따라 바뀌므로, 실제 적용 시에는 해당 버전의 릴리스 노트로 확인해야 한다. 깃 커밋 서명용 Gitsign, 배포 시 정책을 강제하는 policy-controller처럼 주변 도구도 함께 성장하면서, Sigstore는 CI/CD 전반의 서명·검증 표준 축으로 자리를 넓히고 있다.

6. 고려사항 및 시사점

기술사 관점에서 Sigstore 도입은 다음을 균형 있게 고려해야 한다.

첫째, 신뢰 이동(trust shift)에 대한 통제다. 장기 키를 없앤 대신 OIDC 신원 공급자와 TUF 루트 신뢰가 새 핵심 통제점이 된다. 신원 공급자의 설정 오류나 토큰 탈취가 곧 서명 권한 탈취로 이어질 수 있으므로, 신원 발급·권한 범위·단기성을 함께 설계해야 한다.

둘째, 검증 정책의 명시성이다. "서명이 존재한다"만으로 통과시키면 의미가 없다. 허용 신원·발급자·저장소·워크플로, 로그 포함 여부, digest 일치를 모두 정책으로 못 박고, 검증 실패 시 배포를 차단하는 게이트를 파이프라인에 넣어야 한다.

셋째, 가용성·주권 트레이드오프다. 공개 서비스에 의존하면 운영 부담은 줄지만 외부 가용성·정책 변화에 노출된다. 폐쇄망·규제 환경에서는 자체 Fulcio·Rekor를 운영하는 선택지가 있으나, 루트 신뢰 배포(TUF)와 로그 모니터링 운영 역량을 갖춰야 한다.

넷째, 단계적 도입과 연계 기술이다. 처음부터 전면 키리스를 강제하기보다, 우선 핵심 산출물부터 서명·검증을 적용하고 점차 확대한다. 또한 Sigstore는 서명·신원 계층일 뿐이므로 SBOM(구성요소)·SLSA(생성 과정 증거)·런타임 보안과 결합해야 공급망 전 구간의 신뢰가 완성된다.

다섯째, 프라이버시·로그 영속성이다. 서명 신원(이메일 등)이 공개 로그에 남아 추적 가능해지므로, 조직 계정·워크플로 신원을 쓰는 등 노출을 줄이는 신원 설계가 필요하다.

참고자료

한 줄 요약: Sigstore는 장기 개인키 없이 OIDC 신원 기반 단기 인증서로 아티팩트에 서명(Fulcio)하고 그 사건을 공개 투명성 로그(Rekor)에 남겨, 키 유출 위험을 줄이면서 서명의 출처·시점을 누구나 검증·감사할 수 있게 하는 소프트웨어 공급망 서명 체계다.