요약

  • RFC 9943는 범위가 한정된 주장을 가능하게 합니다: 투명성 서비스가 어떤 정책 하에서 서명된 진술문을 등록하고, 검증 가능한 데이터 구조 증명이 담긴 영수증을 발급했다는 것입니다. 이는 기록에 대한 증거이지, 기록이 설명하는 아티팩트에 대한 일괄 승인이 아닙니다.
  • 책임 있는 조직은 여전히 발급자를 선택하고, 관련 영수증을 검증하고, 자체 규칙을 적용하고, 공개를 허용하거나 보류할 수 있는 사람 또는 기구를 지명하고, 정정 경로를 유지해야 합니다. 영수증이 이러한 선택을 몰래 대신해 줄 수는 없습니다.

강력한 기록도 여전히 좁은 기록일 수 있다

공급망 검토를 안심시키는 한 문장으로 압축하고 싶은 유혹이 있습니다: “그 아티팩트에는 투명성 영수증이 있다.” 이 문장은 결론처럼 들립니다. 그러나 RFC 9943 아래에서는 질문 사슬의 시작으로 읽는 것이 더 정확합니다.

2026년 6월에 IETF 표준 트랙 문서로 발표된 이 RFC는 공급망 아티팩트에 관한 서명된 진술문을 위한 아키텍처를 기술합니다. 생산자, 분석가, 감사인 또는 다른 발급자가 서명된 진술문을 작성합니다. 진술문은 SBOM, 보증, 수명 종료 통지, 권고, 또는 아티팩트에 대한 다른 직렬화 가능한 설명을 다룰 수 있습니다. 투명성 서비스(Transparency Service, TS)는 서명된 진술문을 등록받아들일 수 있습니다. 등록은 서비스의 등록 정책(Registration Policy)을 적용하고, 진술문을 검증 가능한 데이터 구조(Verifiable Data Structure)에 추가하며, 영수증(Receipt)을 생성합니다. 그 결과로 만들어진 투명 진술문은 해당 진술문이 그 특정 구조에 들어갔다는 증거를 담고 있습니다.

이것은 실질적인 증거입니다. 영수증은 포함 증명(inclusion proof)을 뒷받침할 수 있습니다. 일부 시스템은 일관성 증명이나 다른 증명 유형도 제공할 수 있습니다. 이 구조는 감사인이 항목들이 일관된, 추가 전용 이력을 이루는지 물을 수 있게 도와줍니다. 이후의 독자는 변경 가능한 웹페이지를 기록 전체로 받아들이는 대신, 발급자가 아티팩트에 대해 어떤 진술문을 만들었는지 검토할 수 있습니다.

그러나 이러한 성질 중 어느 것도 코드를 출시하라는 지시가 아닙니다. 기록에는 아티팩트에 대한 진술문이 담길 수 있습니다. 하지만 그것이 진술문을 리스크 평가로 바꾸거나, 릴리스 관리자를 구속하거나, 상업적 책임을 수용하거나, 영향을 받는 모든 시스템을 식별하거나, 롤백 기준을 선택하거나, 조직이 어느 공급자를 신뢰해도 되는지 결정하지는 않습니다. 이 차이는 구현상의 사소한 문제가 아닙니다. 책임이 여전히 보이는 곳, 그것이 바로 이 지점입니다.

서로의 권위를 빌려서는 안 되는 네 가지 명제

훈련된 검토는 최소한 네 가지 명제를 구분합니다.

첫째, 발급자가 진술문에 서명했습니다. 유효한 서명은 적용되는 암호학적 규칙 아래에서 진술문과 명시된 메타데이터를 하나의 키에 결부할 수 있습니다. 그러나 단순히 유효하다는 이유만으로, 발급자가 의존하는 주체가 신뢰하려던 조직이라는 것, 발급자가 이런 종류의 주장을 할 권한이 있었다는 것, 또는 주장이 정확하다는 것을 증명하지 않습니다.

둘째, 특정 TS가 그 진술문을 등록했습니다. RFC 9943는 등록을 제출, TS의 등록 정책 적용, 검증 가능한 구조에의 삽입, 영수증 생성으로 정의합니다. 정책은 불투명하지 않은 엔벨로프 헤더와 메타데이터에서 도출되는 전제 조건입니다. 그것은 까다로울 수도, 소박할 수도, 특정 부문에 특화될 수도, 그리고 설계상 한정적일 수도 있습니다. 따라서 등록 결과는 지명된 서비스가 지명된 정책 하에서 수행한 검사에 대해 말할 뿐, 하류 조직이 필요로 할 수 있는 모든 검사로 확대되어서는 안 됩니다.

셋째, 의존하는 주체가 자신이 수용 가능하다고 판단하는 영수증을 검증했습니다. 이것은 독립적인 행위입니다. RFC는 의존하는 주체가 최소한 하나의 영수증 발급자의 검증 키 또는 인증서와 연관된 신원을 신뢰할 것을 요구합니다. 또한 의존하는 주체가 하나의 영수증을 수용하고, 투명 진술문을 확인한 후 임의의 검증 정책을 적용하는 것을 허용합니다. 간단히 말해, 영수증 안에는 보편적인 수용 규칙이 들어 있지 않습니다. 어느 서비스 키, 어느 발급자 신원, 어느 증명 프로필, 어느 신선도 조건, 어느 진술문 유형이 이 용도에 해당하는지 누군가 결정해야 합니다.

넷째, 책임 있는 권위가 운영상의 결정을 내렸습니다. 릴리스 심의회는 아티팩트의 프로덕션 진입을 허용할 수 있습니다. 보안 팀은 조사가 끝날 때까지 이를 보류할 수 있습니다. 조달 부서는 정해진 계약을 위해 이를 수용할 수 있습니다. 운영자는 다음 버전을 거절하면서 현재 실행 중인 버전을 유지할 수 있습니다. 각 결정은 서로 다른 권한, 결과, 수습 경로를 갖습니다. 어느 것도 암호학적 기록이 잘 만들어졌다는 이유만으로 참이 되지는 않습니다.

이 네 가지 사건은 건전한 순서로 발생할 수 있지만, 서로 바꿔 쓸 수 없습니다. 특정 고객이 발급자를 수용하지 않더라도 서명된 주장은 등록될 수 있습니다. 의존하는 주체가 영수증을 검증한 후에도, 로컬 노출, 라이선스, 호환성 문제 또는 긴급 정책이 결정을 바꾸면 아티팩트를 보류할 수 있습니다. 조직은 긴급 절차를 통해 버전을 배포한 뒤 나중에 증거를 완성하려 할 수 있습니다. 마지막 예는 권장되는 지름길이 아니라, 예외를 숨기는 대신 감사할 수 있으려면 증거 기록과 결정 기록이 구분 가능한 상태로 유지되어야 하는 이유를 보여줍니다.

정책에는 시계가 있고, 로그에는 범위가 있다

RFC 9943는 이 시간적 경계를 이례적으로 명확하게 만듭니다. TS 운영자는 등록 정책이나 신뢰 앵커를 갱신할 수 있습니다. 동시에 TS는 감사인이 등록 시점의 정책이 정의한 검사를 재현할 수 있도록 충분한 자료를 제공해야 합니다. 따라서 영수증을 받은 후의 올바른 질문은 단지 “이 증명이 검증되는가?”만이 아닙니다. “이 결과는 어떤 정책 하에서, 어떤 시점에, 어떤 키로, 어떤 진술문에 대해 만들어졌는가?”라는 질문이기도 합니다.

이것은 정책 변경에 반대하는 논거가 아닙니다. 서비스는 키 자료를 교체하거나, 수용 규칙을 강화하거나, 새로운 프로필을 채택해야 할 수 있습니다. 요점은, 나중의 정책이 이전의 등록을 몰래 설명할 수 없고, 이전의 영수증이 조직의 현재 릴리스 정책을 몰래 대변할 수 없다는 것입니다. 양쪽 모두 날짜와 범위를 갖습니다.

같은 주의는 순서에도 적용됩니다. 검증 가능한 구조는 등록된 진술문의 추가 전용 순서를 제시할 수 있습니다. RFC 9943는 등록 정책이 그 성질을 광고하지 않는 한, 의존하는 주체가 이 순서가 진술문이 발급된 순서와 일치한다고 가정할 수 없다고 말합니다. 따라서 로그 위치는 그 자체로 어떤 보안 통지가 먼저 작성되었는지, 수정이 권고에 앞섰는지, 운영 결정 전에 관리자가 증거를 보았는지를 확립하지 않습니다. 이들은 각자 자신의 타임스탬프와 관리자를 필요로 하는 별개의 사실들입니다.

투명성이 진실을 확정하지도 않습니다. RFC 9943는 발급자가 의도적이든 의도치 않든 거짓 진술을 할 수 있다고 직접 말합니다. 진술문은 나중에 대체될 수 있고, 서로 다른 발급자가 같은 아티팩트에 대해 상충하는 진술문을 만들 수 있습니다. 이 아키텍처는 의존하는 주체가 이력을 검토하고 어느 발급자를 신뢰할지 결정하게 해 줍니다. 그러나 모든 불일치의 심판으로 아키텍처를 임명하지는 않습니다.

빠진 것은 종종 또 다른 서명이 아니라 결정이다

많은 조직이 이미 기술적 부분은 보존합니다: 아티팩트 다이제스트, 서명된 증명서, 영수증, 아마도 정책 이름. 그런 다음 결정적인 단계는 채팅 메시지, 문서화되지 않은 긴급 승인, 또는 대시보드 토글에 맡깁니다. 시스템은 취약하거나, 호환되지 않거나, 논쟁 중인 아티팩트가 어떻게 통과되었는지 누군가 묻기 직전까지 투명해 보입니다.

작은 릴리스 결정 영수증은 내부 검토를 공개 감시로 바꾸지 않으면서 그 단계를 드러낼 수 있습니다. 실질적인 허용, 보류, 거부 또는 예외 각각에 대해, 변경 불가능한 아티팩트 버전, 관련 진술문과 발급자, 지명된 TS, 등록 정책 버전과 등록 시각, 영수증 검증 결과와 재확인 시각, 사건이 판단된 로컬 정책 또는 예외, 권한을 가진 결정자, 결과, 다음 검토 또는 만료 트리거, 그리고 정정·롤백·항소 경로를 식별해야 합니다.

이것은 새로운 SCITT 요구사항이 아닙니다. SCITT 증거를 소비하되 그것을 흉내 내지 않는 거버넌스 기록입니다. 회사는 기밀 테스트 세부사항, 고객 식별자, 익스플로잇 민감 자료를 보호할 수 있습니다. 그러면서도 감사하고, 정정하고, 결정에 도전해야 하는 사람들에게 책임 경계를 검토 가능하게 만들 수 있습니다.

이 구분은 자동화도 정직하게 유지합니다. 파이프라인은 영수증을 자동으로 검증하고 미리 선언된 로컬 규칙을 적용할 수 있습니다. 유용한 감사 기록은 규칙이 실행되었다는 사실, 어느 버전이 실행되었는지, 무엇을 평가했는지, 어느 권위가 그 규칙을 채택했는지 말해야 합니다. 실제 시스템이 몇 달 전 인간이나 조직이 선택한 규칙 때문에 허용했다면, “로그가 허용했다”는 것은 충분한 설명이 아닙니다.

표준은 로컬 판단을 위한 적절한 공간을 남겨둔다

RFC 9943는 그렇지 않다고 가장하지 않습니다. 진술문의 관리와 저장, 그리고 참여자들이 변경 사항을 서로 발견하고 통지하는 방식은 표준의 범위 밖에 둡니다. 의존하는 주체가 검증 후 자체 정책을 적용하는 것을 허용합니다. 이러한 한계는 표준을 덜 사용 가능하게 만드는 것이 아니라 더 사용 가능하게 만듭니다. 소프트웨어 생산자, 공공 조달자, 규제 대상 운영자, 자원봉사 유지보수자는 같은 영수증을 검증할 수 있다는 이유만으로 하나의 리스크 권한을 공유하지 않습니다.

위험이 시작되는 지점은 기술적 통제가 그 권한의 대체물로 제시될 때입니다. 구매자는 공급자의 등록된 진술문이 실사 완료를 의미한다고 말할 수 있습니다. 릴리스 팀은 포함 증명이 리스크 소유자의 승인을 의미한다고 말할 수 있습니다. 서비스 운영자는 발급자 서명이 새로 발견된 결함 이후에도 구성 요소가 여전히 적절함을 의미한다고 말할 수 있습니다. 각 사례에서, 참이지만 범위가 한정된 기술적 사실이, 기록에 아무도 올려놓지 않은 결정을 짊어지도록 요구받고 있습니다.

더 나은 자세는 더 소박하고 동시에 더 요구적입니다: 영수증이 증명하는 성질에 대해서만 영수증을 검증하고, 그것에 의미를 부여하는 정책과 시점을 보존한 다음, 그 증거로 무엇을 할지 누가 선택했는지 기록하십시오. 이 순서는 암호학적 실패와 거버넌스 실패를 각각 찾아낼 수 있게 합니다. 둘을 같은 종류의 실패인 것처럼 가장할 필요는 결코 없습니다.

출처

  1. RFC 9943: An Architecture for Trustworthy and Transparent Digital Supply Chains
  2. IETF Datatracker: RFC 9943
  3. RFC 9942: CBOR 주체 Signing and Encryption (COSE) Receipts
  4. RFC 9162: Certificate Transparency Version 2.0
  5. RFC 9052: CBOR 주체 Signing and Encryption (COSE): Structures and Process