소프트웨어 공급망 보안, '믿으세요'에서 '검증하세요'로 패러다임 전환

소프트웨어 공급망 공격은 2020년 솔라윈즈(SolarWinds) 사태를 기점으로 급격히 증가했습니다. 당시 공격자들은 솔라윈즈의 빌드 플랫폼을 통해 소프트웨어에 악성코드를 주입하는 방식으로 침투했습니다. 이처럼 공격자들의 전략이 코드가 아닌 빌드 파이프라인으로 옮겨가면서, 소프트웨어의 개발 및 배포 과정 전반의 보안 취약성이 크게 부각되고 있습니다.

이러한 공급망 공격의 증가는 일회성 사건이 아닌 지속적인 위협으로 나타나고 있습니다. 구글 뉴스에서 '공급망 공격'을 검색하면 매일 새로운 공격 사례가 보고될 정도로 그 심각성이 크다는 지적이 나옵니다. 이는 소프트웨어 개발자들이 더 이상 내부 코드 보안에만 집중해서는 안 되며, 소프트웨어 공급망 전체를 아우르는 포괄적인 보안 전략이 필요하다는 점을 시사합니다.

공격 지점이 빌드 플랫폼으로 이동함에 따라, 단순히 코드를 테스트하고 보안 스캔을 수행하는 것만으로는 충분하지 않다는 인식이 확산되고 있습니다. 이제는 어떤 소프트웨어가 어떻게 빌드되었고, 그 과정에서 변조되지 않았음을 입증할 수 있는 능력이 현대 소프트웨어 보안의 핵심 역량으로 떠오르고 있습니다.

소프트웨어 공급망 보안의 핵심은 소비자가 생산자의 주장을 독립적으로 검증할 수 있는 능력에 달려 있습니다. 단순히 생산자가 "이 소프트웨어는 안전하다", "우리가 만들었다"고 주장하는 것을 넘어, 소비자가 해당 주장을 객관적으로 확인할 수 있어야 진정한 보안이 확보될 수 있다는 설명입니다. 이는 신뢰(Trust)에 기반한 전통적인 보안 모델에서 검증(Verify)에 기반한 새로운 모델로의 전환을 의미합니다.

배포되는 소프트웨어의 출처와 무결성을 검증하는 것은 단순한 기술적 절차를 넘어섭니다. 이는 소프트웨어가 예상대로 작동하고, 악성코드나 변조 없이 안전하게 배포되었음을 보장하는 근본적인 신뢰를 구축하는 과정입니다. 이러한 검증 과정이 없다면, 아무리 견고한 내부 보안 시스템을 갖추더라도 외부 공급망의 취약점으로 인해 전체 시스템이 위협받을 수 있습니다.

따라서 소프트웨어 개발 및 배포 과정 전반에 걸쳐 검증 가능한 증거를 생성하고, 이를 소비자가 손쉽게 확인할 수 있는 메커니즘을 구축하는 것이 중요합니다. 이 접근 방식은 현대 소프트웨어 개발의 복잡성과 오픈소스 의존성 증가로 인해 더욱 절실해지고 있습니다.

오늘날 프로덕션에 배포되는 소프트웨어는 더 이상 전적으로 사내에서 자체 개발되지 않습니다. 2022년 연구 결과에 따르면, 모든 최신 솔루션에 배포되는 소프트웨어의 70%에서 90%가 오픈소스 기반인 것으로 나타났습니다. 이는 소프트웨어 기업들이 배포하는 코드의 상당 부분을 외부, 특히 오픈소스 프로젝트에 의존하고 있음을 의미합니다.

이러한 높은 오픈소스 의존성은 효율성과 개발 속도 향상이라는 장점을 제공하지만, 동시에 심각한 보안 위험을 수반합니다. 기업들은 배포하는 소프트웨어의 최대 90%에 해당하는 오픈소스 구성요소를 맹목적으로 신뢰해야 하는 상황에 놓여 있습니다. 오픈소스 프로젝트의 투명성에도 불구하고, 각 구성요소의 출처, 빌드 과정, 그리고 변조 여부를 개별적으로 검증하는 것은 현실적으로 매우 어렵습니다.

결국, 오픈소스 구성요소 중 하나라도 악의적인 공격에 노출되거나 의도치 않은 취약점을 포함하고 있다면, 이를 사용하는 모든 소프트웨어에 치명적인 영향을 미칠 수 있습니다. 따라서 오픈소스 기반의 소프트웨어 공급망에서도 생산자의 주장을 검증하고 무결성을 확인하는 새로운 방법론이 필수적입니다.

아티팩트 서명은 소프트웨어 공급망 보안에 필수적인 요소이지만, 그 구현 방식에 따라 보안 강도가 크게 달라집니다. 특히 태그 기반 서명은 '이 태그로 참조되는 아티팩트를 신뢰한다'는 의미로 사용되는데, 이 방식에는 치명적인 약점이 있습니다. 태그는 언제든지 변경될 수 있어, 오늘 서명된 1.0.0 버전의 아티팩트가 내일 다른 악성 아티팩트로 대체될 가능성이 존재합니다. 이는 서명의 무결성을 심각하게 훼손할 수 있습니다.

이에 반해 다이제스트 기반 서명은 아티팩트의 정확한 콘텐츠를 해시(hash) 값으로 변환하여 서명하는 방식입니다. 이 방식은 콘텐츠가 단 1비트라도 변경되면 다이제스트 값이 달라지므로, 새로운 서명이 필요하게 됩니다. 따라서 다이제스트 기반 서명은 아티팩트의 무결성을 강력하게 보장하며, 콘텐츠 변조 시 즉시 감지할 수 있도록 합니다. 소프트웨어 공급망 보안에서는 이러한 다이제스트 기반 서명 방식이 표준으로 채택되어야 할 필요가 있습니다.

아티팩트 서명은 소프트웨어의 무결성을 보장하는 데 필수적인 절차이며, 이를 위한 표준 도구로 '코사인(cosign)'이 활용되고 있습니다. 코사인은 아티팩트의 서명을 생성하는 데 사용되는 사실상의 표준 도구로 자리매김하고 있습니다. 이 도구를 사용하려면 사설 키와 같은 인증 정보가 필요하며, 일반적으로 기업들은 자체 인증서를 사용합니다.

이번 발표에서는 코사인을 활용한 아티팩트 서명 과정과 함께, '푸키오(Fukio)'라는 새로운 도구가 소개될 예정입니다. 푸키오는 임시 인증서를 생성하여 코사인 서명에 활용할 수 있도록 지원하는 도구입니다. 이는 특히 개발 환경이나 테스트 환경에서 신속하게 서명을 생성해야 할 때 유용하게 사용될 수 있습니다.

공급망 보안에서 서명 기록을 확인하는 것은 중요하지만, 공용 도구를 사용할 때는 신중해야 합니다. '레코(rekor)'와 같은 공개 도구는 서명 기록을 확인할 수 있게 해주지만, 이러한 공개성은 양날의 검이 될 수 있습니다. 서명 기록이 공개적으로 이용 가능해짐에 따라 공격자들도 '새로운 서명이 무엇으로 만들어졌는지' 등 민감한 정보를 파악할 수 있게 되기 때문입니다.

이러한 정보 노출은 공격자들이 서명 체계를 분석하고, 잠재적인 취약점을 찾아내 악용할 수 있는 빌미를 제공합니다. 따라서 서명 기록의 투명성을 확보하면서도 민감한 정보를 보호할 수 있는 방안 마련이 필요합니다. 공용 도구의 편리함과 보안 취약성 사이에서 균형을 찾는 것이 중요한 과제로 지적됩니다.

소프트웨어 아티팩트의 무결성을 검증하는 과정에서 게시자의 신원을 확인하는 것은 중요한 단계입니다. 깃허브 계정을 통해 생성된 서명을 활용하면 이러한 신원 확인이 가능해집니다. 사용자가 깃허브 계정으로 로그인하여 아티팩트에 서명했을 경우, 해당 서명에는 사용자의 이메일 주소와 깃허브 사용자 정보가 포함됩니다.

이는 아티팩트 서명이 누가 만들었는지에 대한 최소한의 검증 가능한 증거를 제공합니다. 이러한 방식으로 아티팩트 게시자의 신원을 확보하면, 악의적인 아티팩트가 유포되었을 때 그 출처를 추적하고 책임 소재를 명확히 하는 데 도움이 됩니다. 깃허브와 같은 신뢰할 수 있는 플랫폼의 계정 정보를 활용하는 것은 소프트웨어 공급망의 투명성과 신뢰성을 높이는 중요한 방법입니다.

아티팩트 서명의 사실상 표준 도구인 코사인(cosign)으로 서명된 아티팩트조차 위조될 수 있다는 경고가 나왔습니다. CI(지속적 통합) 비밀, npm 패키지, 또는 레드햇(Red Hat) 관련 파이프라인으로 유입되는 모든 서명 정보가 추출될 위험이 있습니다. 이는 이미지를 서명하는 데 사용되는 개인 인증서 또한 추출될 수 있음을 의미합니다.

이러한 위협은 공격자들이 빌드 시스템 내부의 취약점을 악용하여 유효한 서명 정보를 탈취한 후, 이를 이용해 악성 아티팩트를 마치 정품인 것처럼 위장할 수 있음을 보여줍니다. 따라서 단순히 서명이 존재한다는 사실만으로는 소프트웨어의 무결성을 완전히 보장하기 어렵습니다. 우리는 빌드나 아티팩트가 예상한 소스에서 빌드되었음을 확실히 하기 위해 더 많은 검증 가능한 증거가 필요하다는 지적입니다.

이는 서명 자체의 보안을 강화하는 것을 넘어, 빌드 파이프라인의 보안과 아티팩트 생성 과정 전반에 대한 추가적인 검증 메커니즘을 도입해야 한다는 것을 시사합니다. '신뢰'가 아닌 '검증'에 기반한 접근 방식의 중요성이 다시 한번 강조되는 대목입니다.

소프트웨어 공급망 보안의 또 다른 위협으로 '혼란스러운 대리인 공격(Confused Deputy Attack)'이 제기되었습니다. 특히 오픈소스 프로젝트에서 널리 사용되는 '디펜더봇(Dependabot)'과 같은 자동화 도구가 이러한 공격에 악용될 수 있다는 우려가 나옵니다. 디펜더봇은 의존성 업데이트를 자동화하여 개발 편의성을 높이지만, 특정 기능이 악성 공격의 통로가 될 수 있습니다.

디펜더봇의 '다시 생성(recreate)' 기능은 풀 리퀘스트(pull request)나 이슈에서 명령어를 통해 기존 풀 리퀘스트를 다시 생성하도록 지시할 수 있는 기능입니다. 이 기능 자체는 유용하지만, 공격자가 이를 악용하여 우리가 신뢰하는 디펜더봇에게 의도하지 않은 행동을 하도록 속일 수 있다는 점이 문제입니다. 즉, 디펜더봇이 '혼란스러운 대리인'이 되어 공격자의 지시를 수행함으로써 시스템을 위협할 수 있습니다.

이러한 공격은 자동화된 도구의 편의성과 신뢰에 기반한 시스템의 취약점을 파고듭니다. 따라서 자동화 도구의 기능을 사용할 때도 그 잠재적 위험을 인지하고, 추가적인 검증 절차를 마련하는 것이 중요합니다.

널리 사용되는 'Dependabot'과 같은 자동화된 도구가 의도치 않게 악성 코드 유포에 악용될 수 있다는 경고가 제기되었습니다. 이 도구를 사용하는 사람들이 악성 코드를 소프트웨어에 삽입하여 오용할 수 있는 잠재적 위험이 존재한다는 것입니다.

이는 사용자들이 Dependabot의 기능을 무심코 사용하거나, 그 작동 방식을 완전히 이해하지 못한 채 의존할 경우 발생할 수 있는 문제입니다. 공격자들은 이러한 사용자들의 심리를 이용하여 악성 코드를 시스템에 주입할 수 있으며, 이로 인해 소프트웨어 공급망 전체가 위협받을 수 있습니다.

이러한 공급망 공격과 오용 가능성을 방지하기 위해 Open Source Security Foundation(OSSF)은 'SALSA(Supply chain Levels for Software Artifacts) 프레임워크'를 채택했습니다. SALSA는 특정 기술이나 도구를 지칭하는 것이 아니라, 소프트웨어 공급망 보안에 대한 공통의 용어와 개념을 정의하여 생산자와 소비자 간에 표준화된 신뢰를 구축하기 위한 체계입니다.

SALSA 프레임워크는 소프트웨어 아티팩트의 무결성과 출처를 검증하는 데 필요한 다양한 보안 수준(레벨 1, 2, 3 등)을 제시합니다. 이를 통해 소프트웨어 생산자는 자신의 빌드 프로세스가 어떤 보안 수준을 달성하는지 명확히 선언할 수 있고, 소비자는 배포되는 소프트웨어가 자신이 요구하는 보안 수준을 충족하는지 확인할 수 있습니다. 이는 공급망 전반에 걸쳐 투명성과 신뢰성을 높이는 데 기여할 것으로 기대됩니다.

소프트웨어 공급망 보안 표준인 SALSA 프레임워크와 관련하여 주요 빌드 플랫폼들의 실제 적용 수준에 대한 논의가 있었습니다. GitHub는 자신들이 SALSA 레벨 3에 도달했다고 주장하지만, 실제로는 그렇지 않다는 반박이 제기되었습니다. 발표자는 강연 말미에 GitHub가 왜 레벨 3을 충족하지 못하는지 구체적으로 설명할 예정입니다.

반면, 마이크로소프트의 Azure DevOps는 SALSA 프레임워크에 대한 데모를 통해 자신들이 현재 SALSA 레벨 1만을 달성할 수 있다고 솔직히 인정했습니다. 이는 빌드 플랫폼이 위조 불가능한 빌드 출처 정보를 생성하는 능력이 SALSA 레벨 달성의 핵심 기준임을 보여줍니다. 주요 플랫폼들의 실제 SALSA 레벨에 대한 투명한 정보 공개와 개선 노력이 요구되는 대목입니다.

소프트웨어 공급망의 신뢰를 구축하기 위해서는 빌드 출처 정보인 '증명(attestation)'을 소비자에게 배포하는 것이 필수적입니다. 소비자는 이 증명 정보를 통해 소프트웨어의 버전, 빌드에 사용된 브랜치, 트리거된 워크플로 등 자신이 신뢰하는 아티팩트인지 확인하는 데 필요한 모든 종류의 정보를 얻을 수 있어야 합니다. 이는 단순한 서명을 넘어, 소프트웨어 생성 과정에 대한 상세한 '인증된 진술'을 제공하는 것을 목표로 합니다.

SALSA 프레임워크 용어집에 따르면, 증명은 소프트웨어 아티팩트 또는 소프트웨어 아티팩트 컬렉션에 대한 '인증된 진술'로 정의됩니다. 이는 소프트웨어가 특정 조건 하에 빌드되었음을 객관적으로 입증하는 문서 역할을 합니다. 증명은 소프트웨어의 출처와 무결성에 대한 소비자의 질문에 답할 수 있는 핵심적인 정보이며, 공급망 보안의 투명성을 높이는 데 결정적인 역할을 합니다.

빌드 파이프라인을 통해 생성되는 아티팩트에는 중요한 두 가지 참조가 첨부됩니다. 첫 번째는 '코사인(cosign) 서명'인데, 이는 '이 사용자가 이 아티팩트에 어떤 종류의 서명을 했다'는 기본적인 내용만을 나타냅니다. 이는 누가 아티팩트를 서명했는지를 알 수 있는 기본적인 신원 확인 도구입니다.

두 번째 참조는 빌드 파이프라인에서 생성되는 '빌드 출처 정보'와 '자재 명세서(Bill of Material, SBOM)'입니다. 빌드 출처 정보는 소프트웨어가 어떻게, 어디서, 언제 빌드되었는지에 대한 상세한 기록을 담고 있습니다. 이는 소프트웨어의 무결성과 신뢰성을 검증하는 데 핵심적인 증거가 됩니다. 자재 명세서는 소프트웨어에 포함된 모든 구성요소(특히 오픈소스 라이브러리)의 목록을 제공하여 잠재적인 취약점을 식별하고 관리하는 데 도움을 줍니다. 이번 발표에서는 자재 명세서의 중요성이 강조되지는 않았지만, 컨테이너에 증명되는 형태로 활용될 수 있음을 언급했습니다.

OCI(Open Container Initiative) 아티팩트는 본래 컨테이너 이미지를 관리하기 위해 설계된 OCI 레지스트리의 개념을 확장하여, 다양한 유형의 소프트웨어 구성요소와 관련 정보를 저장하고 관리하는 데 활용되고 있습니다. Azure 컨테이너 레지스트리 또한 OCI 레지스트리의 일종으로, 컨테이너 이미지를 푸시할 때 전체가 아닌 특정 레이어 단위로 처리하며 다이제스트와 같은 중요한 정보가 포함됩니다.

특히 OCI 아티팩트의 '레퍼런스(References)' 기능은 그 활용성이 매우 높습니다. 이 기능은 서명을 매니페스트에 연결하는 데 사용될 뿐만 아니라, 소프트웨어 자재 명세서(SBOM) 파일이나 빌드 증명과 같은 부가적인 정보들을 OCI 레지스트리에 업로드하고, 해당 아티팩트의 레퍼런스를 생성하여 서명하는 데 활용될 수 있습니다. 이는 컨테이너 이미지 외에도 소프트웨어 공급망의 다른 중요한 요소들을 OCI 생태계 안에서 안전하게 관리하고 검증할 수 있게 함으로써, 전체적인 공급망 보안을 강화하는 데 기여합니다.

'ORAS(Open Container Initiative Registry As Storage)'는 웹 모듈, Terraform 모듈, 머신러닝 모듈 등 사실상 모든 유형의 자원을 OCI 아티팩트로 생성하고 안전하게 배포할 수 있는 강력한 도구로 소개되었습니다. 이 도구는 소프트웨어 개발에서 다양한 형태의 모듈이 생산자와 소비자 간에 교환되는 현대적 환경에서 특히 유용합니다.

예를 들어, 플랫폼 팀이 워크로드 팀이 데이터베이스를 배포하는 데 사용하는 Terraform 모듈을 개발했다고 가정해봅시다. ORAS를 사용하면 이 Terraform 모듈을 OCI 아티팩트로 만들고, 플랫폼 팀의 키로 서명할 수 있습니다. 이렇게 되면 워크로드 팀은 해당 모듈을 가져와 사용할 때, "이 모듈이 플랫폼 팀에 의해 서명된 것이 맞나?"라고 자체적으로 확인할 수 있게 됩니다. 만약 서명이 일치하면 신뢰하고 사용하지만, 그렇지 않다면 사용을 거부하여 잠재적인 보안 위험을 차단할 수 있습니다.

이러한 방식은 다양한 형태의 소프트웨어 자원이 교환되는 복잡한 공급망 환경에서 생산자와 소비자 간의 신뢰를 구축하고, 아티팩트의 무결성을 보장하는 데 핵심적인 역할을 합니다. ORAS는 OCI 레지스트리를 단순한 컨테이너 저장소를 넘어 범용 아티팩트 저장소로 활용하는 가능성을 보여줍니다.

지금까지는 소프트웨어 아티팩트에 대한 증거를 생성하는 생산자 측면을 주로 다뤘지만, 공급망 보안은 소비자의 검증 없이는 완성될 수 없습니다. SALSA 프레임워크는 소비자 관점에서도 증명(attestation)을 활용하는 방법을 설명합니다. 소비자가 증명을 활용하는 첫 번째 단계는 빌드 증명 파일에 명시된 SALSA 빌드 레벨을 확인하는 것입니다. 실제 빌드 레벨이 증명에 추가되어, 이 아티팩트가 레벨 1, 2, 또는 3 중 어떤 수준에서 생성되었는지 소비자가 명확히 알 수 있도록 합니다.

이를 통해 소비자는 자신이 수용할 수 있는 보안 위험 수준에 따라 아티팩트를 선별할 수 있습니다. 예를 들어, 어떤 소비자는 "레벨 1에서 생성된 아티팩트를 허용하는 것은 너무 많은 위험을 수반한다. 나는 레벨 3에서 빌드된 것만 허용하겠다"고 정책을 설정할 수 있습니다. 이는 소프트웨어의 보안 수준에 대한 명확한 기준을 제공하며, 소비자가 의사결정을 내릴 때 중요한 지표가 됩니다.

두 번째 단계는 아티팩트를 수락하기로 결정했다면, 증명 파일에 있는 아티팩트 생성 방식에 대한 모든 정보를 바탕으로 몇 가지 기대치를 확인하는 것입니다. 이는 아티팩트가 약속된 방식으로 빌드되었는지, 예상치 못한 변경 사항은 없는지 등을 추가적으로 검증하는 과정입니다. 이처럼 SALSA 프레임워크는 생산자와 소비자 모두에게 명확한 기준을 제시하여 소프트웨어 공급망의 신뢰도를 높이는 데 기여합니다.

누겟(NuGet) 패키지, 특히 공개 누겟 피드에서 패키지를 가져오는 과정에서 심각한 문제가 발생하고 있습니다. 이 문제는 2024년부터 오랫동안 제기되어 왔으며, 소프트웨어 공급망의 무결성 검증을 어렵게 만드는 주요 원인 중 하나로 지목됩니다.

문제의 핵심은 생산자가 누겟 패키지를 공개 누겟 피드에 업로드할 때, 마이크로소프트 누겟 시스템이 패키지에 '마법 같은' 일부 변경 사항을 적용한다는 점입니다. 이는 주로 인증서 추가 등 특정 목적을 위해 업로드된 아티팩트에 가해지는 자동적인 변경 때문입니다.

이러한 변경으로 인해 빌드 파이프라인에서 생성된 패키지의 다이제스트(해시 값)와 공개 누겟 피드에서 가져온 패키지의 다이제스트가 서로 일치하지 않는 현상이 발생합니다. 이는 "생산자가 빌드한 것과 소비자가 실제로 받는 것이 동일하다"는 중요한 무결성 검증 원칙을 훼손합니다.

결과적으로, 소비자는 누겟 패키지의 무결성을 다이제스트를 통해 직접 검증하기 어렵게 되며, 이는 잠재적으로 악의적인 변경이나 변조를 감지하기 어렵게 만듭니다. 이 문제는 마이크로소프트의 시스템 변경 방식과 공급망 보안 검증 표준 간의 불일치에서 비롯된 것으로 보입니다.