종속 항목 관리

이 문서에서는 취약점 모니터링, 아티팩트 확인, 종속 항목 사용 공간 축소, 재현 가능한 빌드 지원 등 애플리케이션 종속 항목과 이를 관리하기 위한 권장사항을 설명합니다.

소프트웨어 종속 항목은 소프트웨어 라이브러리 또는 플러그인과 같이 애플리케이션 작동에 필요한 소프트웨어의 일부입니다. 종속 항목 확인은 코드를 컴파일하거나, 소프트웨어를 빌드, 실행, 다운로드, 설치할 때 발생할 수 있습니다.

종속 항목에는 사용자가 만드는 두 가지 구성요소인 고유 서드 파티 소프트웨어와 오픈소스 소프트웨어가 모두 포함될 수 있습니다. 종속 항목 관리를 위해 선택하는 방식은 애플리케이션의 보안 및 신뢰성에 영향을 줄 수 있습니다.

구체적인 권장사항 구현은 아티팩트 형식 및 사용하는 도구에 따라 다를 수 있지만 일반 원칙은 여전히 적용됩니다.

직접 및 임시 종속 항목

애플리케이션에는 직접 종속 항목과 임시 종속 항목이 모두 포함될 수 있습니다.

직접 종속 항목
애플리케이션이 직접 참조하는 소프트웨어 구성요소입니다.
임시 종속 항목
애플리케이션의 직접 종속 항목에 기능적으로 필요한 소프트웨어 구성요소입니다. 각 종속 항목에는 자체적으로 직접 및 간접 종속 항목이 있을 수 있으며 모두 애플리케이션에 영향을 미치는 임시 종속 항목의 재귀 트리를 만듭니다.

각 프로그래밍 언어에 따라 종속 항목 및 해당 관계에 대해 서로 다른 수준의 가시성을 제공합니다. 또한 일부 언어는 패키지를 설치하거나 배포할 때 패키지 관리자를 사용해서 종속 항목 트리를 확인합니다.

Node.js 생태계에서 npm 및 Yarn 패키지 관리자는 잠금 파일을 사용하여 모듈 빌드를 위한 종속 항목 버전과 패키지 관리자가 특정 모듈 설치를 위해 다운로드하는 종속 항목 버전을 식별합니다. Java와 같은 다른 언어 에코시스템은 종속 항목 검사에 대한 지원이 보다 제한적입니다. 또한 빌드 시스템은 특정 종속 항목 관리자를 사용하여 종속 항목을 체계적으로 관리해야 합니다.

예를 들어 npm 모듈 glob 버전 8.0.2가 있다고 가정해 보세요. package.json 파일에서 npm 모듈에 대해 직접 종속 항목을 선언합니다. glob용 package.json 파일에서 dependencies 섹션에는 게시된 패키지에 대한 직접 종속 항목이 나열됩니다. devDepdencies 섹션에는 유지관리 담당자 및 glob 참여자에 의한 로컬 개발 및 테스트 종속 항목이 나열됩니다.

  • npm 웹 사이트에서 glob 페이지에는 직접 종속 항목과 개발 종속 항목이 나열되지만 이러한 목록에 자체 종속 항목도 포함되었는지는 표시되지 않습니다.

  • Open Source Insights 사이트에서 glob에 대한 추가 종속 항목 정보를 확인할 수 있습니다. glob의 종속 항목 목록에는 직접 종속 항목과 간접(임시) 종속 항목이 모두 포함됩니다.

    임시 종속 항목은 종속 항목 트리의 심층적인 계층이 될 수 있습니다. 예를 들면 다음과 같습니다.

    1. glob 8.0.2는 minimatch 5.0.1에 대한 직접 종속 항목을 갖습니다.
    2. minimatch 5.0.1은 brace-expression 2.0.1에 대한 직접 종속 항목을 갖습니다.
    3. brace-expression 2.0.1은 balanced-match 1.0.2에 대한 직접 종속 항목을 갖습니다.

간접 종속 항목에 대한 가시성이 없으면 코드가 직접 참조하지 않는 구성요소에서 발생하는 취약점 및 기타 문제를 식별하고 대응하기가 매우 어렵습니다.

glob 패키지를 설치하면 npm은 전체 종속 항목 트리를 확인하고 package.lock.json 파일에 다운로드한 버전의 목록을 저장하여 모든 종속 항목의 레코드를 확보합니다. 동일한 환경에서 이후 설치는 동일한 버전을 검색합니다.

종속 항목 통계 도구

다음 도구를 사용해서 오픈소스 종속 항목을 파악하고 프로젝트의 보안 상황을 평가할 수 있습니다. 이러한 도구는 패키지 형식 전반의 정보를 제공합니다.

Software Delivery Shield
취약점, 종속 항목 정보, 소프트웨어 재료명세서(SBOM), 빌드 출처 등 Cloud Build, Cloud Run, GKE의 아티팩트에 대한 보안 통계를 볼 수 있는 Google Cloud의 완전 관리형 소프트웨어 공급망 보안 솔루션입니다. Software Delivery Shield는 소프트웨어 개발 수명 주기 전반에서 보안 상태를 개선하기 위한 다른 서비스와 기능도 제공합니다.
오픈소스 도구

다음과 같은 많은 오픈소스 도구가 제공됩니다.

  • Open Source Insights: 오픈소스 소프트웨어의 알려진 직간접 종속 항목, 알려진 취약점, 라이선스 정보에 대한 정보를 제공하는 웹사이트입니다. 또한 Open Source Insights 프로젝트는 이 데이터를 Google Cloud 데이터 세트로 제공합니다. BigQuery를 사용하면 데이터를 살펴보고 분석할 수 있습니다.

  • Open Source Vulnerabilities 데이터베이스: 다른 데이터베이스의 취약점을 한 위치에 집계하는 검색 가능한 취약점 데이터베이스입니다.

  • 스코어카드: GitHub 프로젝트에서 위험한 소프트웨어 공급망 관행을 식별하는 데 사용할 수 있는 자동화된 도구입니다. 이 도구는 저장소에 대한 검사를 수행하고 각 검사에 0~10의 점수를 부여합니다. 그런 후 점수를 사용해서 프로젝트의 보안 상황을 평가할 수 있습니다.

  • Allstar: GitHub 조직 또는 저장소가 구성된 정책을 준수하는지 지속적으로 모니터링하는 GitHub 앱입니다. 예를 들어 관리자 또는 푸시 액세스 권한이 있는 조직 외부의 공동작업자를 확인하는 정책을 GitHub 조직에 적용할 수 있습니다.

종속 항목 포함 접근 방식

애플리케이션에 종속 항목을 포함하는 데에는 몇 가지 일반적인 방법이 있습니다.

공개 소스에서 직접 설치
Docker Hub, npm, PyPI, Maven Central과 같은 공개 저장소에서 직접 오픈소스 종속 항목을 설치합니다. 이 방법은 외부 종속 항목을 유지보수할 필요가 없기 때문에 편리합니다. 그러나 이러한 외부 종속 항목을 제어할 수 없으므로 소프트웨어 공급망은 오픈소스 공급망 공격에 더 취약합니다.
소스 저장소에 종속 항목 복사본 저장
이 방법은 벤더링으로도 알려져 있습니다. 빌드 중 공개 저장소로부터 외부 종속 항목을 설치하는 대신 종속 항목을 다운로드하고 프로젝트 소스 트리에 복사합니다. 사용하는 벤더링된 종속 항목을 더 세밀하게 제어할 수 있지만 몇 가지 단점이 있습니다.
  • 벤더링된 종속 항목을 사용하면 소스 저장소 크기가 늘어나고 잦은 변경이 필요합니다.
  • 개별 애플리케이션에 동일한 종속 항목을 벤더링해야 합니다. 소스 저장소 또는 빌드 프로세스가 재사용 가능한 소스 모듈을 지원하지 않는 경우 종속 항목 복사본을 여러 개 유지보수해야 할 수 있습니다.
  • 벤더링된 종속 항목은 업그레이드가 더 어려울 수 있습니다.
비공개 저장소에 종속 항목 저장
Artifact Registry와 같은 비공개 레지스트리는 공개 저장소에서 설치의 편의성과 종속 항목에 대한 제어 기능을 제공합니다. Artifact Registry를 사용하면 다음을 수행할 수 있습니다.
  • 모든 애플리케이션에 대해 빌드 아티팩트 및 종속 항목을 중앙 집중화합니다.
  • 공개 저장소와 같은 방법으로 Artifact Registry에서 비공개 저장소와 상호 작용하도록 Docker 및 언어 패키지 클라이언트를 구성합니다.
  • 비공개 저장소에서 종속 항목을 더 세밀하게 제어합니다.
  • Identity and Access Management를 사용하여 각 저장소에 대한 액세스를 제한합니다.
  • 원격 저장소를 사용하여 업스트림 공개 소스의 종속 항목을 캐시하고 취약점을 검사합니다(비공개 미리보기).
  • 가상 저장소를 사용해서 단일 엔드포인트 뒤에서 원격 및 비공개 저장소를 그룹화합니다. 각 저장소에서 우선순위를 설정하여 아티팩트를 다운로드하거나 설치할 때 검색 순서를 제어합니다(비공개 미리보기).
  • Cloud Build, Cloud Run, Google Kubernetes Engine을 포함하여 Software Delivery Shield에서 다른 Google Cloud 서비스와 함께 Artifact Registry를 쉽게 사용합니다. 소프트웨어 개발 수명 주기 전반에서 자동 취약점 스캔을 사용하고, 빌드 출처를 생성하고, 배포를 제어하고, 보안 상황 통계를 확인합니다.

가능하면 종속 항목에 대해 비공개 레지스트리를 사용합니다. 비공개 레지스트리를 사용할 수 없는 상황에서는 소프트웨어 공급망에서 콘텐츠를 제어할 수 있도록 종속 항목 벤더링을 고려하세요.

버전 고정

버전 고정은 애플리케이션 종속 항목을 특정 버전 또는 버전 범위로 제한하는 것을 의미합니다. 이상적으로 종속 항목의 단일 버전을 고정합니다.

종속 항목의 버전을 고정하면 애플리케이션 빌드의 재현 가능성을 보장하는 데 도움이 됩니다. 하지만 빌드에 보안 수정, 버그 수정, 개선사항을 비롯하여 종속 항목에 대한 업데이트도 빌드에 포함되지 않습니다.

소스 저장소에서 종속 항목에 대해 새 출시 버전을 모니터링하는 자동화된 종속 항목 관리 도구를 사용하여 이러한 문제를 해결할 수 있습니다. 이러한 도구는 필요에 따라 요구사항 파일을 업데이트하여 종속 항목을 업그레이드하며, 흔히 변경 로그 정보 또는 추가 세부정보를 포함합니다.

버전 고정은 임시 종속 항목이 아닌 직접 종속 항목에만 적용됩니다. 예를 들어 my-library 패키지의 버전을 고정하면 my-library의 버전을 제한하지만 my-library의 종속 항목이 있는 소프트웨어의 버전은 제한되지 않습니다. 잠금 파일을 사용하여 일부 언어에서 패키지의 종속 항목 트리를 제한할 수 있습니다.

서명 및 해시 인증

종속 항목으로 사용 중인 아티팩트의 진위성을 확인하기 위해서는 여러 방법을 사용할 수 있습니다.

해시 확인

해시는 파일에 생성되는 값으로, 고유 식별자 역할을 합니다. 아티팩트 해시를 아티팩트 제공자가 계산한 해시 값과 비교하여 파일의 무결성을 확인할 수 있습니다. 해시 인증은 중간자 공격 또는 아티팩트 저장소 손상을 통해 종속 항목 교체, 조작 또는 손상을 식별하는 데 도움이 됩니다.

해시 인증을 사용하려면 아티팩트 저장소에서 수신하는 해시가 손상되지 않았음을 신뢰해야 합니다.

서명 확인

서명 확인은 확인 프로세스에 보안을 추가합니다. 아티팩트 저장소, 소프트웨어 유지관리 담당자 또는 둘 다 아티팩트를 서명할 수 있습니다.

sigstore와 같은 서비스는 유지관리 담당자가 소프트웨어 아티팩트를 서명하고 소비자가 이러한 서명을 확인할 수 있는 방법을 제공합니다.

Binary Authorization은 Google Cloud 런타임 환경에 배포된 컨테이너 이미지가 다양한 기준에 대한 증명으로 서명되었는지 확인할 수 있습니다.

잠금 파일 및 컴파일된 종속 항목

잠금 파일은 완전히 확인되는 요구사항 파일이며, 애플리케이션에 설치할 모든 종속 항목의 버전을 정확히 지정합니다. 일반적으로 설치 도구에서 자동으로 생성되는 잠금 파일은 버전 고정과 서명 또는 해시 인증을 애플리케이션의 전체 종속 항목 트리와 결합합니다.

설치 도구는 최상위 종속 항목의 모든 다운스트림 임시 종속 항목을 완전히 확인하여 종속 항목 트리를 만든 후 잠금 파일에 종속 항목 트리를 포함합니다. 따라서 이러한 종속 항목만 설치할 수 있으므로 빌드를 더 쉽게 재현하고 일관적으로 만들 수 있습니다.

비공개 및 공개 종속 항목 혼합

최신 클라우드 기반 애플리케이션은 오픈소스 타사 코드와 클로즈드 소스 내부 라이브러리에 의존하는 경우가 많습니다. Artifact Registry를 사용하면 여러 애플리케이션 간에 비즈니스 로직을 공유하고 동일한 도구를 재사용해서 외부 및 내부 라이브러리를 설치할 수 있습니다.

그러나 비공개 및 공개 종속 항목을 혼합하면 소프트웨어 공급망이 종속 항목 혼동 공격에 더 취약해집니다. 공격자는 내부 프로젝트와 동일한 이름으로 프로젝트를 오픈소스 저장소에 게시하여 잘못 구성된 설치 프로그램을 악용해서 내부 종속 항목 대신 악성 코드를 설치할 수 있습니다.

종속 항목 혼란 공격을 방지하기 위해서는 다음과 같은 여러 단계를 수행할 수 있습니다.

  • 종속 항목의 서명 또는 해시를 잠금 파일에 포함하여 확인합니다.
  • 타사 종속 항목 및 내부 종속 항목 설치를 2개의 고유 단계로 구분합니다.
  • 수동으로 또는 프록시 가져오기를 통해 필요한 타사 종속 항목을 비공개 저장소에 명시적으로 미러링합니다. Artifact Registry 원격 저장소는 업스트림 공개 저장소의 프록시 가져오기입니다.
  • 가상 저장소를 사용하여 단일 엔드포인트 뒤의 원격 및 표준 Artifact Registry 저장소를 통합합니다. 비공개 아티팩트 버전이 항상 이름이 동일한 공개 아티팩트보다 우선 적용되도록 업스트림 저장소의 우선순위를 구성할 수 있습니다.
  • 공개 패키지 및 기본 이미지에 신뢰할 수 있는 소스를 사용합니다.

사용되지 않는 종속 항목 삭제

니즈가 변화하고 애플리케이션이 발전함에 따라 일부 종속 항목 사용을 변경하거나 중지할 수 있습니다. 사용되지 않는 종속 항목을 애플리케이션에 계속 설치하면 종속 항목 공간이 늘어나고 이러한 종속 항목의 취약점으로 인한 손상 위험이 커집니다.

애플리케이션이 로컬에서 작동하면 개발 프로세스 중에 설치한 모든 종속 항목을 애플리케이션의 요구사항 파일에 복사하는 것이 일반적입니다. 그런 후 이러한 모든 종속 항목에 애플리케이션을 배포합니다. 이 방법은 배포된 애플리케이션의 작동을 보장하는 데 도움이 되지만 프로덕션에 필요하지 않은 종속 항목이 도입될 가능성도 있습니다.

애플리케이션에 새 종속 항목을 도입할 때는 주의가 필요합니다. 각 종속 항목마다 완전히 제어할 수 없는 코드를 더 많이 도입할 수 있습니다. 정기적인 린트 작업 및 테스트 파이프라인의 일부로 요구사항 파일을 감사하는 도구를 통합하여 종속 항목을 실제로 사용하거나 가져올지 결정합니다.

일부 언어에는 종속 항목 관리에 도움이 되는 도구가 있습니다. 예를 들어 Maven 종속 항목 플러그인을 사용해서 Java 종속 항목을 분석하고 관리할 수 있습니다.

취약점 스캔

종속 항목의 취약점에 빠르게 대응하면 소프트웨어 공급망을 보호하는 데 도움이 됩니다.

취약점 스캔을 통해 종속 항목이 애플리케이션에 취약점을 유입하는지 여부를 자동으로 일관적으로 평가할 수 있습니다. 취약점 스캔 도구는 잠금 파일을 사용하여 종속되는 아티팩트를 정확하게 확인하고 새로운 취약점이 발견되면 사용자에게 알립니다(경우에 따라 추천 업그레이드 경로도 포함).

예를 들어 Artifact Analysis는 컨테이너 이미지의 OS 패키지 취약점을 식별합니다. Artifact Registry에 업로드될 때 이미지를 스캔하고 이미지를 내보낸 후 최대 30일 동안 새로운 취약점을 찾기 위해 지속적으로 모니터링합니다.

On-Demand Scanning을 사용하여 OS, Go, 자바 취약점을 찾기 위해 컨테이너 이미지를 로컬로 스캔할 수 있습니다. 이렇게 하면 Artifact Registry에 저장하기 전에 취약점을 해결할 수 있도록 조기에 식별할 수 있습니다.

다음 단계