소프트웨어 공급망 위협

소프트웨어 공급망의 공격 벡터는 누군가 의도적으로 또는 실수로 소프트웨어를 손상시킬 수 있는 여러 방법들을 의미합니다.

취약한 소프트웨어 위험에는 사용자 인증 정보 또는 인증 데이터 누출, 데이터 손상, 멀웨어 설치, 애플리케이션 중단 등이 포함됩니다. 이러한 문제는 시간, 비용, 고객 신뢰의 손실로 이어집니다.

위협의 진입점은 전체 소프트웨어 수명 주기 전반에 걸쳐 있으며 조직 내부 또는 외부에서 발생할 수 있습니다.

소프트웨어 공급망 공격의 진입점을 보여주는 다이어그램

다이어그램 범례에는 두 가지 위협 집합이 포함됩니다.

  • 문자 A~H는 Supply chain Levels for Software Artifacts(SLSA) 프레임워크에서 위협으로 설명하는 소프트웨어 공급망의 공격 벡터를 나타냅니다.
  • 숫자 1~4는 SLSA 프레임워크에 직접 설명되지 않은 추가적인 공격 벡터를 나타냅니다.

Google Cloud의 완전 관리형 소프트웨어 공급망 보안 솔루션인 Software Delivery Shield는 권장사항에 따라 두 가지 위협을 모두 해결할 수 있게 도와줍니다.

이 문서의 하위 섹션에서는 소스, 빌드, 배포, 종속 항목과 관련된 위협을 설명합니다.

소스 위협

이러한 위협은 소스 코드의 무결성에 영향을 줍니다.

  • 1: 안전하지 않은 코드 작성. 보안 코딩 방식을 사용하지 않으면 의도치 않게 취약점이 포함된 코드가 생성될 수 있습니다. 안전하지 않은 개발자 워크스테이션도 악성 또는 안전하지 않은 코드의 원인이 될 수 있습니다. 해결 방법은 다음과 같습니다.

    • 개발자 워크스테이션의 정책을 설정합니다. Cloud Workstations는 요구사항에 맞게 맞춤설정할 수 있는 사전 구성된 완전 관리형 워크스테이션을 제공합니다.
    • 로컬 코드 스캔. Cloud Code source protect(비공개 미리보기)는 종속 항목의 취약점 및 라이선스 정보를 포함한 실시간 보안 피드백을 제공합니다. 개발자는 On-Demand Scanning API를 사용하여 컨테이너 이미지를 스캔하여 OS 및 언어 패키지 취약점을 검사할 수도 있습니다.
    • 코드 보안 강화 방법에 대한 교육

  • A: 소스 저장소에 악성 코드를 제출합니다. 여기에는 악성 코드뿐만 아니라 교차 사이트 스크립팅과 같은 공격에 대해 의도치 않은 취약점을 유입하는 코드도 포함됩니다. 해결 방법은 다음과 같습니다.

    • 소스 코드 변경사항에 대한 사람의 검토 필요
    • IDE 및 소스 제어 시스템과 통합되는 코드 스캔 및 린트 작업 도구 사용

  • B:소스 제어 시스템 손상. 빌드 파이프라인의 소스 제어 시스템 및 기타 시스템에 대한 액세스를 제한하고 다중 인증(MFA)을 사용하면 이 위험을 완화하는 데 도움이 됩니다.

또한 소스 무결성을 평가할 때 소프트웨어 빌드 및 배포를 위해 사용하는 지원 스크립트 및 구성을 검사합니다. 이 파일의 취약점을 완화하도록 소스 제어 시스템 및 코드 검토 프로세스에 포함하세요.

소스 보호에 대한 자세한 내용은 소스 보호를 참조하세요.

빌드 위협

이러한 위협은 소프트웨어 빌드 또는 패키징 시 소프트웨어를 손상시키거나 소비자를 속여 잘못된 버전의 소프트웨어를 사용하도록 합니다.

  • C: 신뢰할 수 있는 소스 제어 시스템에서 오지 않은 소스로 빌드. 이 위험을 줄이는 데 도움이 되는 해결 방법은 다음과 같습니다.
    • 빌드에서 신뢰할 수 있는 소스를 사용하는지 확인할 수 있도록 출처 정보를 생성하는 Cloud Build와 같은 빌드 서비스를 사용합니다.
    • CI/CD 인프라를 네트워크 경계에 배치하여 빌드에서 데이터가 유출되는 것을 방지하세요. Google Cloud 서비스의 경우 VPC 서비스 제어를 사용합니다.
    • 필요한 오픈소스 종속 항목의 신뢰할 수 있는 사본을 Artifact Registry와 같은 비공개 아티팩트 저장소에 저장하고 사용합니다.
  • D: 빌드 시스템 손상. 이 위험을 줄이는 데 도움이 되는 해결 방법은 다음과 같습니다.
    • 빌드 시스템에 대한 직접 액세스를 필요한 사용자로 제한하여 최소 권한의 원칙을 따르세요. Google Cloud에서는 적절한 사전 정의된 역할을 부여하거나 커스텀 역할을 만들 수 있습니다.
    • Cloud Build와 같은 관리형 빌드 서비스를 사용합니다. Cloud Build는 각 빌드에 VM 환경을 설정하고 빌드 후 폐기하여 임시 빌드를 실행합니다.
    • CI/CD 인프라를 네트워크 경계에 배치하여 빌드에서 데이터가 유출되는 것을 방지하세요. Google Cloud 서비스의 경우 VPC 서비스 제어를 사용합니다.
  • F: 공식 프로세스 외부에서 빌드된 소프트웨어 패키징 및 게시. 빌드 출처를 생성 및 서명하는 빌드 시스템을 사용하면 소프트웨어가 신뢰할 수 있는 빌드 시스템에서 빌드되었는지 검증할 수 있습니다.
  • G: 내부 또는 외부 사용자에 대해 소프트웨어를 저장하는 저장소 손상. 이 위험을 줄이는 데 도움이 되는 해결 방법은 다음과 같습니다.
    • 필요한 오픈소스 종속 항목의 신뢰할 수 있는 사본을 Artifact Registry와 같은 비공개 아티팩트 저장소에 저장하고 사용합니다.
    • 빌드 및 소스 출처를 검증합니다.
    • 사람이 아닌 전용 계정 및 저장소 관리자로 업로드 권한을 제한합니다. Google Cloud에서 서비스 계정은 서비스 및 애플리케이션을 대신하여 작동합니다.

배포 및 런타임 위협

  • H: 특정 빌드 버전에 영구적으로 연결되지 않은 버전 범위 또는 태그를 지정하여 종속 항목을 확인하면 다음과 같은 문제가 발생할 수 있습니다.

    • 빌드에 처음 사용되는 종속 항목이 도일 빌드의 이후 실행을 위해 빌드에 사용되는 종속 항목과 다를 수 있기 때문에 빌드가 재현 가능하지 않습니다.
    • 종속 항목이 손상된 버전으로 확인되거나 소프트웨어를 손상시키는 변경사항이 포함된 버전으로 확인될 수 있습니다. 악의적인 행위자는 이러한 불확실성을 이용해 빌드가 의도한 버전 대신 악의적인 행위자의 패키지 버전을 선택하도록 할 수 있습니다. 종속 항목 혼란 위험을 해결하는 데에는 많은 종속 항목 권장사항이 도움이 될 수 있습니다.

  • 2: 배포 프로세스 손상. 지속적 배포 프로세스를 사용하는 경우 프로세스 손상으로 인해 사용자에게 제공하는 소프트웨어에 원치 않는 변경사항이 적용될 수 있습니다. 배포 서비스에 대한 액세스를 제한하고 사전 프로덕션 환경에서 변경사항을 테스트하여 위험을 완화할 수 있습니다. Cloud Deploy를 사용하면 환경 간 지속적 배포 프로세스와 승격을 관리할 수 있습니다.

  • 3: 손상되었거나 호환되지 않는 소프트웨어 배포. 배포 정책을 적용하면 이 위험을 해결하는 데 도움이 됩니다. Binary Authorization을 사용해서 컨테이너 이미지가 정책 기준과 호환되는지 확인하고 신뢰할 수 없는 소스로부터의 컨테이너 이미지 배포를 차단할 수 있습니다.

  • 4: 소프트웨어 실행 시 취약점 및 잘못된 구성.

    • 새로운 취약점이 정기적으로 발견된다는 것은 새로운 발견 항목이 프로덕션 단계의 애플리케이션에 대한 보안 위험 수준을 변경할 수 있다는 것을 의미합니다.
    • 루트 사용자로 실행하거나 컨테이너 실행 시 권한 에스컬레이션을 허용하는 등 일부 구성은 승인되지 않은 액세스 위험을 증가시킵니다.

    GKE 보안 상황 대시보드는 실행 중인 워크로드에서 OS 취약점 및 구성 문제와 관련된 정보를 표시합니다.

    Cloud Run에서는 또한 배포한 컨테이너 이미지의 알려진 취약점을 포함하여 배포된 버전에 대한 보안 통계를 볼 수 있습니다.

소스 보호에 대한 자세한 내용은 빌드 보호를 참조하고 배포 보호에 대한 자세한 내용은 배포 보호를 참조하세요.

종속 항목 위협

종속 항목에는 빌드의 직접 종속 항목과 직접 종속 항목에서 다운스트림된 종속 항목의 재귀 트리인 임시 종속 항목이 포함됩니다.

다이어그램에서 E는 빌드에서 잘못된 종속 항목을 사용하고 있음을 나타냅니다. 잘못된 종속 항목에는 다음이 포함됩니다.

  • 내부적으로 개발한 구성요소, 상업용 서드 파티 소프트웨어, 오픈소스 소프트웨어 등 애플리케이션이 사용하는 모든 소프트웨어.
  • 다른 공격 벡터에서 발생한 취약점. 예를 들면 다음과 같습니다.
    • 공격자가 소스 제어 시스템에 대해 액세스 권한을 획득하여 프로젝트에 사용되는 종속 항목 버전을 수정합니다.
    • 빌드에는 조직의 다른 팀에서 개발한 구성요소가 포함됩니다. 로컬 개발 환경에서 직접 구성요소를 빌드하고 게시하고 실수로 테스트 및 디버깅에만 로컬로 사용하는 라이브러리에 취약점이 발생합니다.
  • 공개 저장소에서 오픈소스 종속 항목을 의도적으로 삭제. 공개 저장소에서 직접 종속 항목을 검색할 경우 이러한 삭제로 인해 소비 파이프라인 손상이 발생할 수 있습니다.

이러한 위험을 해결하는 방법은 종속 항목 권장사항을 참조하세요.

위협 해결

공급망의 전반적인 무결성은 가장 취약한 부분에 의해 결정됩니다. 공격 벡터를 무시하면 해당 공급망 부분에서 공격 위험이 증가합니다.

이와 동시에 모든 것을 한 번에 변경할 필요는 없습니다. 소프트웨어 공급망 보안에는 스위스 치즈 모델로도 잘 알려진 누적 행동 효과가 적용됩니다. 구현하는 각 완화 방법은 위험을 줄이고, 공급망 전반에서 완화를 결합하면 다양한 유형의 공격에 대한 보호를 높입니다.

  • 조직의 위협 감지, 대응 및 해결 능력을 평가할 수 있게 해주는 프레임워크 및 도구를 사용해서 보안 상황을 평가합니다.
  • 소프트웨어 공급망을 보호하기 위한 권장사항 및 이러한 권장사항을 지원하도록 설계된 Google Cloud 제품에 대해 알아보세요.
  • Software Delivery Shield를 사용하여 Google Cloud의 소프트웨어 공급망에서 소프트웨어를 보호하세요. 우선순위 및 기존 인프라에 따라 점진적으로 서비스를 구현할 수 있습니다.

다음 단계