소프트웨어 안전하게 배포하기

소프트웨어 및 애플리케이션을 빌드하는 수많은 조직에서 고객의 니즈를 충족하기 위한 최우선 사항으로 속도와 TTM(time to market)을 꼽습니다. 이러한 전략적 요구사항으로 인해 플랫폼 선택 시 컨테이너의 채택률이 엄청나게 증가하고 있습니다. 이러한 조직들은 지난 1년 동안 TTM 단축, 가용성 향상, 보안 강화, 확장성 개선, 비용 절감과 같은 컨테이너의 이점을 누리면서 서버리스 접근 방식에 대해서도 고민하기 시작했습니다.

소프트웨어 솔루션을 사용하면 새로운 기능이나 신규 제품을 출시하는 데 소요되는 시간을 단축할 수 있지만, 기존의 여러 보안 관행이 빨라진 속도를 따라잡지 못해 다음과 같은 3가지 문제가 발생하곤 합니다.

1. 기존 프로세스로 인해 개발자의 작업 속도가 느려져 지연 발생
2. 보안팀과 운영팀의 절충으로 조직이 위협에 노출됨
3. 개발팀이 기한을 준수하기 위해 기존 보안 프로세스를 우회하여 취약점 발생

지난 몇 년 동안 '소프트웨어 공급망' 공격으로 분류되는 수많은 보안 침해가 있었습니다.

Log4Shell은 2021년 12월에 발견된 Apache Log4j 소프트웨어의 심각한 취약점입니다. CVSS 점수가 최고점인 10으로 신고된 이 취약점은 자바 기반 로깅 프레임워크인 Log4j의 인기 때문에 더욱 치명적이었습니다. 2가지 사항이 문제를 더욱 심각하게 키웠습니다. 첫째, 악용하기가 매우 쉽고 완전한 원격 코드 실행이 가능했습니다. 둘째, 종속 항목 트리에서 매우 깊은 층에 위치한 경우가 많아 취약점을 놓치기 쉬웠습니다.

IT 관리 소프트웨어 기업인 SolarWinds의 경우 국가 배후 행위자들이 회사에서 사용하는 오픈소스 소프트웨어의 공식 빌드에 악성 코드를 삽입해 공격했습니다. 이 악성 업데이트가 미국 재무부와 상무부를 비롯한 18,000명의 고객에게 푸시되었습니다.

또 다른 IT 관리 소프트웨어 제공업체인 Kaseya는 제로데이 취약점을 통해 공격을 받았습니다. 해커들은 Kaseya VSA 서버를 손상시키고 악성 스크립트를 전송하여 감염된 시스템의 모든 파일을 암호화하는 랜섬웨어를 배포했습니다.

백악관은 이런 종류의 이슈에 긴급히 대응할 필요성을 절감하고, 2021년 5월 연방 정부와 거래하는 조직들이 특정 소프트웨어 보안 표준을 지키도록 의무화하는 행정 명령을 발표했습니다.

'소프트웨어 공급망'은 여러 가지 면에서 적절한 용어입니다. 소프트웨어 공급망을 구축하는 과정은 자동차 제조 과정과 매우 흡사합니다.

자동차 제조업체는 다양한 규격품을 조달하고, 독점적인 자체 구성품을 제조한 다음, 고도로 자동화된 프로세스를 통해 모든 구성품을 하나로 조립합니다. 서드 파티에서 조달하는 각 부품이 신뢰할 만한 출처로부터 공급되는지를 검증하여 안전한 작동을 보장합니다. 자체 생산 구성품은 다방면의 테스트를 거쳐 안전상의 문제가 없음을 확인합니다. 마지막으로, 신뢰할 수 있는 프로세스를 통해 조립을 수행하면 자동차가 완성됩니다.

소프트웨어 공급망은 여러 가지 면에서 이와 유사합니다. 소프트웨어 제조업체는 특정 기능을 수행하는 서드 파티 구성요소(일반적으로 오픈소스)를 확보한 뒤, 회사의 핵심적인 지적 재산에 해당하는 소프트웨어를 자체 개발합니다. 그런 다음 코드의 빌드 프로세스를 실행하여 이러한 구성요소를 배포 가능한 아티팩트로 결합한 후 프로덕션에 배포합니다.

소프트웨어 공급망을 구성하는 연결 고리 중 안전하지 않은 고리가 단 하나만 있어도 공급망 전체가 위협을 받습니다.

작년에 부각된 공격 사례에서 알 수 있듯이 프로세스 단계 하나하나가 공격자가 악용하는 취약점이 될 수 있습니다.

예를 들어 일반적인 NPM 패키지에는 직접 종속 항목이 12개, 간접 종속 항목이 약 300개 포함됩니다. 뿐만 아니라 게시된 모든 NPM 패키지 중 거의 40%가 알려진 취약점이 포함된 코드에 의존한다고 확인되었습니다.

이러한 취약점이 반드시 코드를 위험하게 만드는 것은 아닙니다. 예컨대 취약점이 있는 라이브러리가 실제로 사용되지 않을 수도 있습니다. 그러나 이러한 취약점도 반드시 점검하고 넘어가야 합니다.

문제가 발생하면 파장이 어마어마합니다. 취약점 중 단 하나만 패치되지 않아도 악의적인 행위자가 소프트웨어 공급망에 침입할 수 있습니다.

Google은 수십 년간 세계적인 규모의 애플리케이션을 빌드해 왔습니다. 이 과정에서 수많은 내부 프로젝트를 오픈소스로 제공하여 개발자의 작업 속도를 높이는 데 기여했습니다. 이와 동시에 다양한 내부 프로세스를 개발하여 소프트웨어 환경의 보안을 지원했습니다.

Google은 소프트웨어 공급망의 모든 요소를 더욱 강화하기 위해 다음과 같은 노력을 기울였습니다.

• 투자 확대 – Google은 2020년 8월, 제로 트러스트 프로그램 확장, 소프트웨어 공급망 보안 지원, 오픈소스 보안성 향상 등 사이버 보안을 강화하기 위해 향후 5년간 100억 달러를 투자하겠다는 계획을 발표했습니다.
• 소프트웨어 아티팩트에 대한 공급망 등급(SLSA) – SLSA는 공급망의 무결성을 위한 엔드 투 엔드 프레임워크로서, Google 내부에서 구현해온 수많은 프로세스와 동등한 오픈소스 프레임워크입니다. SLSA는 빌드 결과와 방식에 대해 감사 가능한 출처를 제공합니다.
• DORA(DevOps Research and Assessment) – Google의 DORA팀은 7년에 걸친 연구 프로그램을 통해 소프트웨어 배포 및 조직의 성과를 높이는 다양한 기술, 프로세스, 측정, 문화적 역량을 검증했습니다.
• Open Source Security Foundation – Google은 2019년에 공급망 보안에 관한 산업 간 포럼인 Open Source Security Foundation을 공동 설립했습니다.
• Allstar – Allstar는 보안 정책을 설정하고 시행하기 위해 조직 또는 저장소에 설치하는 GitHub 앱으로, GitHub 프로젝트에 보안 권장사항을 지속적으로 적용할 수 있도록 해 줍니다.
• 오픈소스 스코어카드 – 스코어카드는 명확한 보안 정책, 코드 검토 프로세스, 퍼징 및 정적 코드 분석 도구를 사용한 지속적 테스트 범위와 같은 평가 측정항목을 사용하여 오픈소스 프로젝트의 위험 점수를 제공합니다.

Google은 소프트웨어 공급망 보안 문제를 해결하려면 다음 2가지가 꼭 필요하다고 생각합니다.

1. 업계 전반의 표준 및 프레임워크
2. 최소 권한의 원칙을 사용하여 이러한 표준을 구현하는 관리형 서비스, 일명 제로 트러스트 아키텍처 (제로 트러스트 아키텍처란 누구에게도 또는 어떤 기기나 네트워크에도 내재적인 신뢰를 두지 않는 아키텍처로서, 어떤 상황에서든 신뢰를 획득해야만 정보 액세스가 허용됩니다.)

이 두 가지를 하나씩 살펴보겠습니다.

현재 SLSA는 업계의 합의에 따라 수립되고 있는 일련의 보안 가이드라인으로, 점진적으로 채택할 수 있습니다. 최종 완성된 형태의 SLSA는 시행 가능성 면에서 단순한 권장사항 목록과는 달리, 특정 패키지 또는 빌드 플랫폼에 'SLSA 인증'을 부여하도록 정책 엔진에 입력할 수 있는 감사 가능한 메타데이터의 자동 생성을 지원할 것입니다.

SLSA는 점진적이고 실행 가능하며 모든 단계에서 보안 이점을 제공하도록 설계되었습니다. 소비자는 최고 등급을 통과한 아티팩트가 변조되지 않았고 출처를 안전하게 역추적할 수 있다는 신뢰를 가질 수 있습니다. 오늘날 대부분의 소프트웨어로는 불가능하지는 않더라도 어려운 일입니다.

SLSA는 4등급으로 구성되어 있고 이상적인 최종 상태는 SLSA 4입니다. 하위 등급은 해당 수준까지만 점진적으로 무결성이 보장됨을 의미합니다. 현재 정의된 요구사항은 다음과 같습니다.

SLSA 1은 빌드 프로세스가 완전히 스크립트화/자동화되고 출처를 생성하도록 규정합니다. 출처란 빌드 프로세스, 최상위 소스, 종속 항목을 비롯하여 아티팩트가 빌드되는 방식에 대한 메타데이터를 말합니다. 출처가 제공되면 소프트웨어 소비자가 위험을 고려하여 보안과 관련한 의사 결정을 내릴 수 있습니다. SLSA 1에서 규정하는 출처는 변조를 막지는 못하지만, 기본적인 수준의 코드 소스 식별을 제공하며 취약점 관리에 도움이 될 수 있습니다.

SLSA 2는 버전 제어 및 인증된 출처를 생성하는 호스팅된 빌드 서비스를 사용하도록 규정합니다. 이러한 추가 요구사항 덕분에 소비자는 소프트웨어 출처를 더욱 신뢰할 수 있습니다. 이 등급에서는 빌드 서비스를 신뢰할 수 있는 범위까지 출처 변조가 방지됩니다. 또한 SLSA 2에서는 SLSA 3으로 간편하게 업그레이드할 수 있는 경로를 제공합니다.

SLSA 3은 소스 및 빌드 플랫폼이 각각 소스의 감사 가능성과 출처의 무결성을 보장하는 특정 표준을 충족하도록 규정합니다. SLSA 3은 교차 빌드 오염과 같은 특정 유형의 위협을 차단하여 하위 등급에서보다 훨씬 더 강력하게 변조를 방지합니다.

SLSA 4는 현행 최고 등급으로서 모든 변경사항에 대해 2인 검토를 요구하고 빌드 프로세스의 밀폐성과 재현 가능성을 규정합니다. 2인 검토는 실수를 찾아내고 비정상적인 동작을 방지하기 위한 업계 권장사항입니다. 빌드의 밀폐성은 출처의 종속 항목 목록이 완전함을 보장합니다. 빌드의 재현 가능성은 엄격히 요구되지는 않지만 감사 가능성 및 신뢰성 측면에서 많은 이점을 제공합니다. 종합적으로 볼 때 SLSA 4는 소비자에게 소프트웨어가 변조되지 않았다는 높은 수준의 확신을 줍니다. 이러한 등급 제안에 대한 자세한 내용과 해당 소스 및 빌드/출처 요구사항을 알아보려면 GitHub 저장소를 참조하세요.

소프트웨어 공급망은 코드, 빌드, 패키지, 배포, 실행의 5가지 단계로 나눌 수 있습니다. 이제 각 단계를 Google의 보안 접근 방식 관점에서 다뤄 보겠습니다.

Google Cloud는 코드 및 빌드부터 배포 및 실행에 이르기까지 앞서 설명한 표준과 권장사항을 기본적으로 구현하는 완전 관리형 도구를 제공합니다.

소프트웨어 공급망을 보호하려면 코드의 출처를 규명하고 프로덕션에서 실행 중인 코드가 의도한 것과 일치하도록 보장하는 신뢰 사슬을 확립, 검증, 유지해야 합니다. Google은 소프트웨어 개발 및 배포 프로세스 전반에 걸쳐 생성되고 검사되는 증명을 통해 이를 달성하면서 코드 검토, 코드 출처 검증, 정책 시행을 통해 전반적인 보안 수준을 높입니다. 이러한 프로세스는 개발자의 생산성을 높일 뿐만 아니라 소프트웨어 공급망의 위험을 최소화하는 데도 도움이 됩니다.

먼저 Google Cloud는 ID 및 액세스 관리, 감사 로깅 등의 일반적인 보안 인프라 서비스를 기본적으로 제공합니다. 다음으로 소프트웨어 수명 주기 전반에 걸쳐 증명을 정의, 점검, 시행하는 방식으로 고객의 소프트웨어 공급망을 보호합니다.

Google Cloud의 정책 및 출처를 통해 개발 프로세스에서 상시 활성화된 수준의 보안을 달성하는 방법을 더 자세히 살펴보겠습니다.

소프트웨어 공급망 보안은 개발자가 애플리케이션을 설계하고 코드를 작성하는 순간부터 시작됩니다. 퍼스트 파티 소프트웨어와 오픈소스 구성요소 또한 여기에 포함되는데, 각각 다른 문제를 수반합니다.

오픈소스 소프트웨어 및 종속 항목

오픈소스는 개발자의 빌드 속도를 높여 조직의 민첩성과 생산성을 향상시킵니다. 그러나 오픈소스 소프트웨어는 완벽성이 보장되지 않을 뿐 아니라, 업계의 의존도가 높음에도 불구하고 그 안에 어떠한 종속 항목이 있으며 어느 정도의 위험이 따르는지를 파악하기가 매우 어렵습니다. 대부분의 기업들이 겪는 위험의 주 원인은 취약점 또는 라이선스입니다.

오픈소스 소프트웨어, 패키지, 기본 이미지, 기타 개발자가 의존하는 아티팩트는 '신뢰 사슬'의 기초를 형성합니다.

예를 들어 조직에서 'a'라는 소프트웨어를 빌드하는 경우를 생각해 보겠습니다. 위는 신뢰 사슬, 즉 프로젝트에 내포된 종속 항목의 개수를 나타낸 다이어그램입니다. 다이어그램에서 'b'부터 'h'까지는 직접 종속 항목, 'i'부터 'm'까지는 간접 종속 항목입니다.

종속 항목 트리 심층부에 취약점이 있다고 가정해 보겠습니다. 이 경우 여러 구성요소에서 문제가 매우 빠르게 나타날 수 있습니다. 게다가 종속 항목이 매우 자주 변경됩니다. 하루 평균 40,000개의 NPM 패키지에서 종속 항목의 변경이 발생합니다.

Google Cloud에서 빌드한 도구인 Open Source Insights가 제공하는 전환적 종속 항목 그래프를 사용하면 종속 항목 트리를 샅샅이 살펴 모든 종속 항목을 계층적으로 파악할 수 있습니다. Open Source Insights는 지속적으로 업데이트되는 여러 언어에 걸친 보안 권고 사항, 라이선스 정보, 기타 보안 데이터를 한곳에 모아서 제공합니다. 오픈소스 프로젝트의 위험 점수를 제공하는 오픈소스 스코어카드와 Open Source Insights를 함께 사용하면 개발자는 가용한 수백만 개의 오픈소스 패키지에 대해 보다 합리적인 의사 결정을 내릴 수 있습니다.

이 문제를 해결하려면 코드로서의 종속 항목에 초점을 맞추는 것이 중요합니다. 종속 항목은 공급망의 끝으로 이동할수록 조사하기 더 어려워집니다. 종속 항목의 보안을 강화하려면 공급망 초기부터 시작하는 것이 좋습니다.

• Open Source Insights 및 OSS 스코어카드와 같은 도구를 사용하여 종속 항목을 철저히 파악하세요.
• 워크플로의 핵심인 자동화 프로세스를 통해 코드, 패키지, 기본 이미지를 모두 스캔하고 검증하세요.
• 개발자가 종속 항목에 액세스하는 방식을 제어하세요. 퍼스트 파티 코드와 오픈소스 코드의 저장소를 모두 세밀하게 제어하고 철저한 코드 검토 및 감사 요구사항을 강제하는 것이 매우 중요합니다.

빌드 및 배포 프로세스는 다음에 더 자세히 살펴보겠지만, 빌드의 출처 확인, 안전한 빌드 환경 활용, 이미지 서명 확인, 배포 시 후속 검증도 중요합니다.

또한 개발자는 다음과 같은 몇 가지 안전한 코딩 관행을 채택할 수 있습니다.

• 테스트 자동화
• 메모리 안전성을 갖는 소프트웨어 언어 사용 
• 코드 검토 의무화
• 커밋 진위성 보장
• 악성 코드 조기 식별
• 민감한 정보 노출 방지
• 로깅 및 빌드 출력 필수화 
• 라이선스 관리 활용

소프트웨어 공급망 보안을 위한 다음 단계는 안전한 빌드 환경을 대규모로 구축하는 것입니다. 빌드 프로세스는 본질적으로 저장소에서 여러 언어 중 하나로 된 소스 코드를 가져와서 구성 파일에 명시된 사양에 맞게 빌드를 실행할 때 시작됩니다.

Google과 같은 클라우드 제공업체는 사용자가 원하는 규모로 이미지를 빌드할 수 있는 최신 관리형 빌드 환경을 제공합니다.

빌드 프로세스를 진행할 때는 다음과 같이 여러 가지 사항을 고려해야 합니다.

• 빌드 프로세스 중은 물론 그 이후에도 보안 비밀이 안전하게 보호되나요?
• 빌드 환경에 누가 액세스할 수 있나요?
• 비교적 새로운 공격 벡터 또는 유출 위험은 어떠한가요?

안전한 빌드 환경을 구축하려면 보안 비밀에서부터 시작해야 합니다. 보안 비밀은 매우 중요하지만 비교적 쉽게 보호할 수 있습니다. 먼저, 보안 비밀은 일반 텍스트가 아니어야 하고 가급적 빌드에도 포함되지 않도록 해야 합니다. 대신 보안 비밀을 암호화하고 필요에 따라 외부 보안 비밀을 참조하도록 빌드를 매개변수화해야 합니다. 이렇게 하면 보안 비밀의 주기적 순환을 간소화하고 유출의 영향을 최소화할 수 있습니다.

다음으로는 빌드에 대한 권한을 설정합니다. 빌드 프로세스에는 다양한 사용자와 서비스 계정이 관여됩니다. 예를 들어 어떤 사용자는 보안 비밀을 관리할 수 있어야 하고, 다른 사용자는 단계를 추가하거나 수정하여 빌드 프로세스를 관리해야 하고, 또 다른 사용자는 로그만 보면 됩니다.

이 과정에서 다음과 같은 권장사항을 따르는 것이 중요합니다.

• 가장 중요한 것은 최소 권한의 원칙입니다. 권한을 세분화하여 사용자와 서비스 계정에 작업을 효과적으로 수행하는 데 필요한 정확한 권한을 부여하세요.
• 사용자와 서비스 계정이 상호작용하는 방식을 이해하고 빌드 설정부터 빌드 실행, 빌드의 다운스트림 효과에 이르기까지 책임 소재가 어떻게 연결되는지를 명확히 파악해야 합니다.

다음으로, 이 프로세스를 수직 확장할 때 빌드 주위에 가능한 범위까지 경계를 설정한 다음, 자동화를 사용하여 형상관리 및 매개변수화를 통해 수직 확장하세요. 이렇게 하면 빌드 프로세스의 변경사항을 효과적으로 감사할 수 있습니다. 또한 민감한 빌드와 배포에 대한 승인 통제, 인프라 변경에 대한 pull 요청, 사람에 의한 정기적 감사 로그 검토를 통해 규정 준수 요구사항을 충족해야 합니다.

마지막으로, 네트워크가 니즈에 맞는지 확인하세요. 대부분의 경우 방화벽으로 보호되는 비공개 네트워크에 자체 소스 코드를 호스팅하는 것이 가장 좋습니다. Google Cloud가 제공하는 자체 비공개 네트워크 경계 내부의 폐쇄형 서버리스 빌드 환경인 Cloud Build 비공개 풀, VPC 서비스 제어와 같은 기능에 액세스하여 지적 재산의 유출을 방지할 수 있습니다.

Binary Authorization

ID 및 액세스 관리(IAM)는 필수적이면서 논리적으로 합당한 출발점이지만 결코 만능이 아닙니다. 사용자 인증 정보가 유출되면 심각한 보안 위험으로 이어지므로, IAM에 대한 의존도를 낮추려면 오류가 발생할 가능성이 비교적 낮은 증명 기반 시스템으로 전환하는 것이 좋습니다. Google은 신뢰할 수 있는 워크로드만 배포를 허용하는 Binary Authorization이라는 시스템을 사용합니다.

Binary Authorization 서비스는 프로세스 전반에서 증명 및 정책 점검을 통해 신뢰 사슬을 확립하고 검증하고 유지합니다. 기본적으로 Binary Authorization은 코드 및 기타 아티팩트가 프로덕션으로 이동할 때 증명이라는 암호화 서명을 생성한 다음, 배포 전에 정책을 기반으로 해당 증명을 점검합니다.

Google Cloud Build를 사용하면 일련의 증명을 캡처해 신뢰 사슬 전반에 추가할 수 있습니다. 예를 들면 실행된 작업, 사용한 빌드 도구 및 프로세스 등에 대한 증명이 생성됩니다. 특히 Cloud Build는 빌드가 스크립트화되었음을 검증할 때 사용하는 빌드 구성 소스를 캡처하여 SLSA 1등급을 달성하도록 지원합니다. 스크립트화된 빌드는 수동 빌드보다 안전하며 SLSA 1등급 준수를 위한 필수 요소입니다. 또한 모든 이미지에 대해 고유한 시그니처를 생성하는 컨테이너 이미지 다이제스트를 사용하여 빌드의 출처와 기타 증명을 조회할 수 있으며, 이 기능 또한 SLSA 1등급 준수를 위한 요건입니다.

빌드가 완료되면 프로덕션에서 사용할 준비가 거의 완료된 컨테이너 이미지가 생성됩니다. 기존 이미지 변조 및 무단 이미지 업로드를 방지할 수 있도록 안전한 이미지 저장 위치를 확보하는 것이 중요합니다. 패키지 관리자는 애플리케이션에 사용하는 언어 패키지뿐만 아니라 퍼스트 파티 및 오픈소스 빌드에 대한 이미지가 모두 필요할 수 있습니다.

Google Cloud의 Artifact Registry는 이러한 저장소를 제공합니다. 조직은 Artifact Registry를 사용하여 컨테이너 이미지와 언어 패키지(예: Maven, NPM)를 모두 한곳에서 관리할 수 있습니다. Google Cloud의 도구 및 런타임과 완벽하게 통합되고 아티팩트 프로토콜을 기본적으로 지원합니다. 따라서 자동 파이프라인을 설정하는 과정에서 CI/CD 도구와 간편하게 통합할 수 있습니다.

빌드 단계와 마찬가지로 Artifact Registry에 대한 액세스 권한은 최소 권한의 원칙에 따라 신중하게 부여해야 합니다. Package Repository는 무단 액세스 제한 외에도 훨씬 더 많은 가치를 제공합니다. 예를 들어 Artifact Registry에는 이미지를 스캔하여 안전하게 배포할 수 있도록 하는 취약점 스캔 기능이 포함되어 있습니다. 이 서비스는 지속적으로 갱신 및 업데이트되는 취약점 데이터베이스와 대조해 이미지를 스캔하여 새로운 위협을 평가하고 취약점 발견 시 알림을 보낼 수 있습니다.

이 단계에서는 아티팩트의 취약점 결과가 특정한 보안 기준점을 충족하는지 여부에 대한 증명을 비롯한 추가 메타데이터가 생성됩니다. 이후에 이 정보가 Google의 분석 서비스에 저장되어 Binary Authorization에 바로 액세스할 수 있도록 아티팩트의 메타데이터를 구조화하고 정리하는 데 사용됩니다. 이를 통해 위험한 이미지가 Google Kubernetes Engine(GKE)에 배포되지 않도록 자동 방지할 수 있습니다.

소프트웨어 보안 공급망의 마지막 두 단계는 배포 및 실행입니다. 이 두 단계는 서로 별개지만, 승인된 빌드만 프로덕션에서 사용할 수 있도록 하는 방법이라는 점에서 묶어서 생각할 수 있습니다.

Google은 어떤 종류의 빌드를 승인할지 결정하기 위한 권장사항을 개발했습니다. 우선, 공급망의 무결성을 보장하여 신뢰할 수 있는 아티팩트만 생성되도록 해야 합니다. 다음으로, 취약점 관리를 소프트웨어 배포 수명 주기에 포함시켜야 합니다. 마지막으로, 이 두 요소를 결합하여 무결성 및 취약점 스캔을 위한 정책 기반 워크플로를 시행해야 합니다.

이 단계까지 왔으면 코드, 빌드, 패키지 단계는 이미 완료되었습니다. 공급망을 따라 캡처된 증명은 Binary Authorization을 통해 진위성을 검증할 수 있습니다. 시행 모드에서는 증명이 조직의 정책을 충족할 때만 이미지가 배포되고, 감사 모드에서는 정책 위반이 로깅되고 알림이 트리거됩니다. Binary Authorization을 사용하면 승인된 Cloud Build 프로세스를 사용하여 빌드한 결과물만 실행이 가능하도록 제한할 수도 있습니다. Binary Authorization은 적절한 검토와 승인을 거친 코드만 배포되도록 합니다.

신뢰할 수 있는 런타임 환경에 이미지를 배포하는 것은 중요합니다. Google의 관리형 Kubernetes 플랫폼인 GKE는 컨테이너에 대한 보안 우선 접근 방식을 사용합니다.

GKE는 클러스터 보안과 관련된 개발자의 부담을 크게 덜어줍니다. 자동 클러스터 업그레이드를 사용하면 출시 채널을 통해 Kubernetes를 자동으로 패치하고 최신 상태로 유지할 수 있습니다. 보안 부팅, 보안 노드, 무결성 검사는 노드의 커널 및 클러스터 구성요소가 수정되지 않았고 의도대로 실행되고 있으며 악성 노드가 클러스터에 조인할 수 없음을 보장합니다. 마지막으로, 컨피덴셜 컴퓨팅을 통해 메모리가 암호화된 노드에서 클러스터를 실행하여 데이터 처리 중에도 기밀성을 유지하세요. 여기에 저장 데이터 및 네트워크 전송 데이터의 암호화를 결합하면 GKE에서 컨테이너화된 워크로드를 실행하는 매우 안전한 비공개 기밀 환경을 제공합니다.

이뿐 아니라 GKE를 사용하면 부하 분산기의 인증서 관리, 워크로드 아이덴티티, 클러스터의 인그레스를 구성하고 보호하는 강력한 고급 네트워크 기능을 통해 애플리케이션 보안을 강화할 수 있습니다. 또한 GKE는 신뢰할 수 없는 애플리케이션을 실행할 때 나머지 워크로드를 보호하는 샌드박스 환경을 제공합니다.

GKE Autopilot을 사용하면 GKE의 보안 권장사항과 기능이 자동으로 구현되어 공격에 노출되는 영역이 더 축소되고 보안 문제로 이어질 수 있는 구성 오류가 최소화됩니다.

물론, 검증의 필요성은 배포에서 그치지 않습니다. Binary Authorization은 지속적 검증을 지원하므로 배포 후에도 규정 정책을 계속 준수할 수 있습니다. 실행 중인 애플리케이션이 기존 정책이나 새로 추가된 정책을 위반하면 알림이 생성되고 로깅되므로 프로덕션에서 실행하는 작업이 정확히 의도한 대로 실행된다는 확신을 가질 수 있습니다.

취약점 관리

무결성 보장과 더불어 공급망 보안을 구성하는 또 다른 면은 모든 취약점을 신속하게 발견하여 패치하는 것입니다. 공격자들의 수법은 취약점을 업스트림 프로젝트에 능동적으로 삽입하는 방식으로 진화화고 있습니다. 따라서 취약점 관리와 결함 감지를 소프트웨어 배포 수명 주기의 모든 단계에 통합해야 합니다.

코드를 배포할 준비가 되면 CI/CD 파이프라인을 사용하고 소스 코드 및 생성된 아티팩트를 포괄적으로 스캔할 수 있는 다양한 도구를 활용하세요. 이러한 도구로는 정적 분석기, 퍼징 도구, 다양한 유형의 취약점 스캐너 등이 있습니다.

워크로드를 프로덕션에 배포한 후 워크로드가 프로덕션에서 실행 중이며 사용자에게 서비스를 제공하는 동안 새로운 위협을 모니터링하고 즉각적인 해결 조치를 취할 계획을 세우세요.

결론

요약하면, 소프트웨어 공급망 보안의 관건은 SLSA와 같은 권장사항을 따르고 이러한 권장사항을 구현하는 데 유용한 신뢰할 수 있는 관리형 서비스를 사용하는 것입니다.

다음 사항을 명심하시기 바랍니다.

• 가장 먼저 코드 및 종속 항목의 신뢰성을 확인하세요.
• 빌드 시스템을 보호하고 증명을 사용하여 필요한 빌드 단계를 모두 따랐는지 확인하세요.
• 모든 패키지와 아티팩트가 신뢰할 수 있고 변조 불가능한지 확인하세요.
• 누가 무엇을 배포할 수 있는지를 제어하고 감사 추적을 유지하세요. Binary Authorization을 사용하여 배포할 모든 아티팩트의 증명을 검증하세요.
• 신뢰할 수 있는 환경에서 애플리케이션을 실행하고 실행 중에 누구도 애플리케이션을 변조할 수 없도록 조치하세요. 새로 발견되는 모든 취약점을 점검하여 배포를 보호하세요.

Google은 소프트웨어 배포 수명 주기의 각 단계별 권장사항을 토대로 구축한 제품 포트폴리오를 통해 개발 작업에 신뢰할 수 있는 기반을 제공하고 있습니다.

소프트웨어 공급망을 보호할 준비가 되셨나요? 분명히 말씀드리지만 첫 발걸음은 어디서 시작해도 좋습니다. 공급망 전체를 보호할 수 있는 단일 조치는 없으며, 총체적인 공급망 보안에 있어 어떤 조치가 다른 조치보다 특별히 더 중요하다고 말하기도 어렵습니다. 다만 시작하실 때 참고하실 만한 권장사항 4가지를 소개합니다.

1. 소프트웨어 패치하기

알려진 취약점이 포함된 코드를 프로덕션 환경에 배포했다면 공격자에게 협조한 것이나 다름없습니다. 그 시점부터는 공격자의 침입 경로가 이미 열려 있으므로, 소프트웨어 공급망을 아무리 잘 보호해도 소용이 없습니다. 따라서 패치가 매우 중요합니다.

2. 환경에서 실행 중인 요소 제어하기

패치를 완료했다면 이제 소프트웨어 공급망 자체를 제어할 수 있어야 합니다. 먼저, 실행 중인 요소의 실제 출처가 자체 빌드 도구 또는 신뢰할 수 있는 저장소인지 확인할 수 있어야 합니다. 이러한 수준의 제어를 구현하면 의도적인 공격과 의도치 않은 오류, 예컨대 개발자가 위험성을 인지하지 못하고 실수로 배포하는 경우를 함께 방지할 수 있습니다. 이와 같이 튼튼한 기반 위에 클릭 테스트, Binary Authorization 등의 도구를 추가해 나가세요.

3. 서드 파티 공급업체 패키지가 안전한지 확인하기

공급업체 소프트웨어 보안 침해는 공급망 보안에서 새로운 문제로 부각되고 있습니다. 이러한 소프트웨어가 고객 배포를 노리는 랜섬웨어 또는 무단 액세스의 도관이 되는 사례가 빈번하게 발생하고 있기 때문입니다. 자체 환경에서 실행하는 시스템 관리 제품, 네트워크 관리 제품, 보안 제품 등 서드 파티 공급업체 패키지는 높은 수준의 권한을 갖는 경우가 많습니다. 사용 중인 패키지에 대해 상투적인 보안 안내문에 그치지 않고 일정 수준의 보증을 제공하도록 공급업체에 요청하세요. 공급업체가 어떤 SLSA 등급을 준수하는지, 또는 최근의 행정 명령에서 요구하는 수준에 부합하는지 여부를 문의할 수도 있습니다.

4. 소스 코드의 비공개 사본 유지하기

오픈소스 소프트웨어를 사용하여 빌드하는 경우 인터넷에서 바로 가져온 버전을 사용하지 마세요. 대신 지속적으로 패치하는 비공개 사본을 보유하면 모든 빌드를 시작할 청정 환경을 마련하고 소스 코드의 출처를 100% 확신할 수 있습니다.

DevOps 권장사항

1. 6년 간의 State of DevOps 보고서: 소프트웨어 배포 성능을 예측하는 기능에 대한 심층 정보가 담긴 일련의 문서로서, 현황 및 개선 방법을 빠르게 점검하고 파악할 수 있습니다.
2. Google Cloud 2021 Accelerate State of DevOps Report
3. Google Cloud 백서: 클라우드 기반으로 재설계: 대규모의 개발자 생산성 향상을 위한 혁신적 접근 방식

소프트웨어 공급망 보호

1. Google Cloud 블로그: 제로 트러스트 ID 보안이란?
2. Google 보안 블로그: 공급망의 무결성을 위한 엔드 투 엔드 프레임워크인 SLSA 소개
3. Google Cloud 백서: 개발 초기부터 보안 문제 반영: 소프트웨어 공급망 보호