2026년 ML-DSA 코드 서명은 CI/CD에 어떻게 도입하나요?

빌드는 성공했지만 배포 환경에서 새 서명을 검증할 수 있는지 불확실한가요?

ML-DSA CI/CD 코드 서명은 격리된 파이프라인에서 키 관리와 서명·검증 흐름, 소비자 호환성을 먼저 확인한 뒤 단계적으로 적용하세요. FIPS 204 표준화가 전체 빌드와 배포 생태계의 지원을 뜻하지는 않습니다.

이 글은 소프트웨어 배포 파일에 서명을 적용하는 DevSecOps 엔지니어를 위한 내용입니다.
배포 기반 환경을 관리한다면 서명하는 쪽과 검증하는 쪽의 의존성을 함께 확인할 수 있습니다.
코드 서명 이전을 계획하는 보안 담당자라면 시험 범위와 중단 조건을 정하는 데 활용하세요.

첫 단계: 서명 대상과 신뢰 경계를 정하세요

먼저 서명할 대상을 하나로 특정하세요. 실행 파일인지, 업데이트 묶음인지, 컨테이너 이미지인지에 따라 서명 데이터의 표현 방식과 이를 읽는 소비자가 달라집니다. 빌드 산출물, 서명 단계, 게시 저장소, 설치 또는 배포 환경을 연결해 어디에서 누가 무엇을 검증하는지 그려 보세요.

ML-DSA는 NIST의 FIPS 204 최종 표준에 정의된 알고리즘입니다. 따라서 시험 구현이 표준 알고리즘을 따르는지, 암호 라이브러리가 어떤 인터페이스와 입력 형식을 제공하는지, 산출물 형식과 소비자 도구가 그 결과를 받아들이는지를 각각 확인해야 합니다. 알고리즘, 구현, 서명 봉투 형식, 클라이언트 지원은 서로 다른 확인 항목입니다.

서명은 생성됐지만 소비자 쪽 도구가 형식을 해석하지 못하면 배포를 신뢰할 근거가 이어지지 않습니다. 빌드 작업의 식별 정보와 결과물 다이제스트를 감사 기록에 연결하면, 나중에 어떤 빌드가 어떤 파일을 만들었는지 조사하기 쉬워집니다. SLSA 출처 정보 명세는 빌드 출처 정보를 다루는 참고 자료입니다. 서명 자체와 출처 정보가 같은 기능이라고 간주하지 말고, 필요한 증거를 따로 정의하세요.

두 번째 단계: 키 수명 주기와 권한을 설계하세요

키를 만들기 전에 책임자를 정하세요. 생성, 보관, 사용 승인, 교체, 폐기 권한이 한 작업 계정이나 한 사람에게 무분별하게 집중되지 않도록 역할을 나눕니다. 키 저장 위치와 파이프라인의 연결 방식은 선택한 암호 라이브러리와 키 관리 제품의 공식 지침을 기준으로 설계해야 합니다. 여기서는 제품에 관계없이 쓸 수 있는 생성 명령이나 보편적인 보관 방식을 제시하지 않습니다.

파이프라인 비밀값은 일반 설정값과 다르게 취급해야 합니다. 비밀키가 저장되는 위치, 작업에 전달되는 경로, 작업 종료 뒤의 처리, 접근 기록을 실제 선택한 도구에서 확인하세요. GitHub Actions의 비밀값 보호 문서는 해당 플랫폼에서 비밀값을 다룰 때 참고할 자료입니다. 이 지침을 다른 CI/CD 제품의 동작으로 그대로 확대 해석하지 말고, 사용 중인 플랫폼의 문서도 별도로 확인하세요.

교체나 폐기 때 검증 소비자가 어떤 공개키를 신뢰할지 정하지 않았다면, 키를 바꾸는 순간 유효한 배포 파일까지 검증 불가 상태가 될 수 있습니다. 키 식별자와 신뢰 갱신 절차, 사고 시 폐기 절차를 사전에 문서화하세요. NIST의 후양자 암호 이전 FAQ도 이전 계획을 세울 때 참고할 수 있지만, 구체적인 키 조작은 선택한 제품 문서를 따라야 합니다.

시험 키를 운영 키처럼 취급하지 마세요. 시험 키의 접근 범위와 폐기 방법을 먼저 정하고, 비밀값이 일반 로그나 저장소에 남지 않는지 시험 결과로 확인하세요.

세 번째 단계: 서명 검사를 파이프라인에 연결하세요

서명 단계는 빌드가 끝난 뒤 적절한 권한을 가진 작업에서 실행하고, 서명 대상이 앞 단계에서 만든 결과물과 일치하는지 검사하도록 설계하세요. 서명 입력에 파일 자체만 넣을지, 파일의 다이제스트와 빌드 출처 정보를 함께 연결할지는 채택하는 서명 형식과 소비자의 요구에 맞춰 결정합니다. 예를 들어 DSSE 구현 자료는 서명된 엔벌로프 형식을 검토할 때 참고할 수 있습니다. 이 자료가 곧바로 모든 배포 도구의 호환성을 보장하는 것은 아닙니다.

암호 라이브러리의 문서도 반드시 구현과 버전을 맞춰 확인하세요. OpenSSL의 ML-DSA 서명 인터페이스 문서는 그 인터페이스에서 다루는 내용을 보여 주지만, 다른 라이브러리나 CI/CD 환경이 같은 기능을 제공한다는 증거는 아닙니다. 구체적인 명령이나 설정은 선택한 제품의 공식 문서와 실제 지원 버전을 확인한 뒤 적용하세요.

서명 작업이 실패하면 게시를 중단하도록 하고, 일반 빌드 로그에 비밀키나 민감한 입력이 찍히지 않는지 확인하세요. 성공 기록에는 빌드 식별 정보, 결과물 다이제스트, 사용한 서명 키의 식별자, 결과 상태를 남기되 비밀키 자체는 기록하지 않습니다.

네 번째 단계: 검증 도구와 소비자를 시험하세요

개발자 환경에서 한 번 통과하는 것으로 검증을 마치지 마세요. 실제 배포 과정에서 파일을 받아 확인하는 클라이언트와 운영 도구가 같은 서명 방식과 파일 형식을 처리하는지 확인해야 합니다. 소비자 환경에 필요한 검증 도구가 없거나, 설치 경로에서 서명 정보가 보존되지 않으면 서명 작업의 성공만으로는 배포 안전성을 판단할 수 없습니다.

검증 시험에서는 정상 파일뿐 아니라 변조된 파일과 잘못된 공개키를 사용하세요. 정상 파일은 통과하고, 변조되었거나 신뢰되지 않는 키로 검증한 파일은 거부되는지 확인합니다. 실패 시 배포가 실제로 중단되는지도 봐야 합니다. 결과를 기록할 때는 파일 식별 정보, 시험 조건, 소비자 도구의 버전, 검증 결과를 남기고 비밀값은 기록에서 제외하세요.

다섯 번째 단계: 조건에 따라 시험을 넓히거나 되돌리세요

비핵심 산출물 하나를 골라 격리된 시험을 시작하세요. 기존 게시 절차를 바로 대체하지 말고, 새 서명 경로와 기존 검증 경로를 병행할 수 있는지 살펴보세요. 이미지 저장소, 업데이트 시스템, 오래된 설치 클라이언트에서 새 서명 정보가 유지되는지도 확인해야 합니다.

다음 조건으로 적용 범위를 결정하세요.

• 소비자 전부가 같은 서명 형식을 검증하고, 변조 시험에서 배포가 차단되면 비핵심 범위부터 확대합니다.
• 일부 소비자의 지원 여부가 확인되지 않으면 기존 검증을 유지하고 해당 소비자만 별도 시험합니다.
• 서명 실패에도 게시가 계속되거나 키 접근 기록을 확인할 수 없으면 전환을 중단하고 기존 절차로 되돌립니다.
• 키 교체와 폐기 뒤에도 소비자가 유효한 파일을 검증할 수 있는지 확인되지 않으면 운영 전환을 보류합니다.

숫자로 확인하는 서명 데이터 크기

FIPS 204는 ML-DSA 매개변수 집합별 키와 서명 데이터 크기를 정의합니다. 다음 값은 암호 알고리즘의 정해진 데이터 크기이며, CI/CD의 처리 시간이나 전체 패키지 크기를 뜻하지 않습니다. 정확한 값은 FIPS 204 표준에서 확인할 수 있습니다.

이 값은 전송 경로와 저장 형식을 점검할 때 참고할 수 있지만, 특정 저장소나 클라이언트가 해당 데이터를 지원한다는 뜻은 아닙니다. 제품 선택과 지원 여부는 각 프로젝트의 공식 문서와 버전 안내에서 별도로 검증하세요.

자주 묻는 질문

배포 파일 서명에 ML-DSA를 적용할 수 있나요?
적용 여부는 표준에 알고리즘이 정의됐는지만으로 결정되지 않습니다. 사용할 암호 구현, 서명 정보를 담는 형식, 저장소, 소비자 검증기가 같은 방식을 지원하는지 확인해야 합니다. 우선 비핵심 파일에 서명하고, 실제 배포 경로의 독립된 검증 환경에서 정상 파일과 변조 파일을 시험하세요.

CI/CD에서 서명과 검증은 어떻게 시험하나요?
시험 전용 파이프라인에서 빌드 결과의 식별 정보와 다이제스트를 기록한 뒤 승인된 키로 서명합니다. 이후 소비자와 가까운 환경에서 원본 파일, 수정된 파일, 신뢰되지 않는 공개키를 각각 검증하세요. 예상과 다른 결과가 나오거나 비밀값이 로그에 드러나면 게시를 막고 원인을 해결하기 전까지 시험 범위를 늘리지 않습니다.

이전 클라이언트가 새 서명도 검증할 수 있나요?
클라이언트 이름만 보고 호환된다고 판단하지 마세요. 실제 배포에 쓰는 버전과 암호 라이브러리, 서명 데이터 형식을 조합해 검증해야 합니다. 호환성이 입증되지 않은 소비자가 남아 있다면 기존 검증 경로를 유지하고, 새 서명은 해당 소비자에서 시험을 마친 뒤 단계적으로 필수화하세요.

시범 적용을 멈춰야 할 때는 언제인가요?
검증 실패가 배포를 막지 못하거나, 키를 누가 썼는지 추적할 수 없거나, 키 폐기 뒤 소비자 동작을 설명할 수 없다면 확대하지 마세요. 기존 서명 검증과 게시 흐름을 유지하면서 새 경로를 격리하는 조건을 미리 정하세요. 재시험 결과와 승인 기록이 준비되기 전에는 운영 범위에 넣지 않는 편이 안전합니다.

마지막으로: 실행 환경을 확인하고 임시 시험 범위를 고르세요

공유 CI 작업 환경은 실행 조건을 세밀하게 통제하기 어려울 수 있고, 자체 장비를 상시 운영하면 업데이트와 접근 권한 관리 책임이 팀에 남습니다. 장비를 바로 구매하면 초기 비용과 유지 관리 부담을 함께 고려해야 합니다. 반면 임시 개발 환경은 기간과 전달 방식에 따라 적합성이 달라지므로, 선택한 암호 라이브러리와 검증 도구가 실제로 동작하는지 먼저 확인해야 합니다.

시범 파이프라인을 재현할 환경이 잠시 필요하다면 ZavCloud의 한국 맥 미니 대여 안내를 검토할 수 있습니다. 환경을 빌리는 일은 ML-DSA 지원을 보장하지 않으므로, 라이브러리와 CI/CD 도구의 호환성을 직접 확인하세요. 운영 환경 안내가 필요하면 ZavCloud 도움말 센터에서 제공 범위를 확인한 뒤, 시험 결과에 맞춰 적용 여부를 결정하세요.