공급망 코드 보안의 모범 사례

이 가이드의 내용

이 가이드에서는 코드의 보안을 개선하기 위해 수행할 수 있는 가장 큰 변경 사항을 설명합니다. 각 섹션에서는 보안을 개선하기 위해 프로세스를 변경할 수 있는 사항을 간략하게 설명합니다. 가장 큰 변경 내용이 먼저 나열됩니다.

어떤 위험이 있나요?

개발 프로세스의 주요 위험은 다음과 같습니다.

공격자가 악용할 수 있는 보안 취약성이 있는 종속성 사용
공격자가 리소스에 액세스하는 데 사용할 수 있는 인증 자격 증명 또는 토큰
공격자가 악용할 수 있는 사용자 고유의 코드에 취약성을 도입

위험은 리소스 및 프로젝트를 공격에 노출시키고 해당 위험은 사용자가 만든 패키지를 사용하는 모든 사람에게 직접 공유됩니다. 다음 섹션에서는 위험으로부터 자신과 사용자를 보호하는 방법을 설명합니다.

종속성에 대한 취약성 관리 프로그램 만들기

종속성에 대한 취약성 관리 프로그램을 만들어 종속된 코드를 보호할 수 있습니다. 높은 수준에서 다음을 보장하는 프로세스를 포함해야 합니다.

종속성의 인벤토리를 만듭니다.
종속성에 보안 취약성이 있는 경우를 알 수 있습니다.
끌어오기 요청에 대한 종속성 검토를 적용합니다.
해당 취약성이 코드에 미치는 영향을 평가하고 수행할 작업을 결정합니다.

첫 번째 단계로 종속성의 전체 인벤토리를 만들려고 합니다. 리포지토리의 종속성 그래프는 지원되는 에코시스템에 대한 종속성을 보여 줍니다. 종속성을 체크 인하거나 다른 에코시스템을 사용하는 경우 이를 타사 도구의 데이터로 보완하거나 종속성을 수동으로 나열해야 합니다. 리포지토리에 대한 최소한의 읽기 권한이 있는 경우 GitHub UI 또는 GitHub REST API를 통해 리포지토리에 대한 종속성 그래프를 SPDX 호환 SBOM(Software Bill of Materials)으로 내보낼 수 있습니다. 자세한 내용은 "리포지토리에 대한 소프트웨어 자료 청구서 내보내기"을(를) 참조하세요.

종속성에서 취약성 자동 검색

Dependabot은 종속성을 모니터링하고 알려진 취약성이 있는 경우 이를 알림으로써 도움이 될 수 있습니다. Dependabot을(를) 사용 설정하여 종속성을 보안 버전으로 업데이트하는 끌어오기 요청을 자동으로 제기하게 할 수도 있습니다. 자세한 내용은 "Dependabot 경고 정보" 및 "Dependabot 보안 업데이트 정보"을(를) 참조하세요.

끌어오기 요청에서 취약성 자동 검색

종속성 검토 작업은(는) 끌어오기 요청에 대한 종속성 검토를 적용하므로 끌어오기 요청이 리포지토리에 취약한 버전의 종속성을 도입하는지 쉽게 확인할 수 있습니다. 취약성이 감지되면 종속성 검토 작업에서 끌어오기 요청의 병합을 차단할 수 있습니다. 자세한 내용은 "종속성 검토 정보"을(를) 참조하세요.

취약한 종속성으로 인한 위험에 대한 노출 평가

취약한 종속성(예: 라이브러리 또는 프레임워크)을 사용하고 있는 경우 프로젝트의 노출 수준을 평가하고 수행할 작업을 결정해야 합니다. 취약성은 일반적으로 심각도 점수로 보고되어 그 영향이 얼마나 심각한지 보여 줍니다. 심각도 점수는 유용한 가이드이지만 취약성이 코드에 미치는 전체 영향을 알려주지는 못합니다.

코드에 대한 취약성의 영향을 평가하려면 라이브러리를 사용하는 방법도 고려하고 실제로 시스템에 미치는 위험을 결정해야 합니다. 이 취약성은 사용하지 않는 기능의 일부일 수 있으며 영향을 받는 라이브러리를 업데이트하고 일반적인 릴리스 주기를 계속할 수 있습니다. 또는 코드가 위험에 심하게 노출되어 영향을 받는 라이브러리를 업데이트하고 업데이트된 빌드를 즉시 제공해야 할 수도 있습니다. 이 결정은 시스템에서 라이브러리를 사용하는 방법에 따라 달라지며, 사용자만 내릴 수 있는 결정입니다.

통신 토큰 보호

코드는 종종 네트워크를 통해 다른 시스템과 통신해야 하며 인증하려면 비밀(예: 암호 또는 API 키)이 필요합니다. 시스템에서 실행하려면 해당 비밀에 액세스해야 하지만 소스 코드에 포함하지 않는 것이 가장 좋습니다. 이는 많은 사람들이 액세스할 수 있는 리포지토리에 특히 중요하고 퍼블릭 리포지토리에도 중요합니다.

리포지토리에 커밋된 비밀 자동 검색

참고:

참고: 사이트 관리자가 먼저 인스턴스에 대해 secret scanning을(를) 사용하도록 설정해야 이 기능을 사용할 수 있습니다. 자세한 내용은 "어플라이언스에 대한 비밀 검사 구성"을(를) 참조하세요.

엔터프라이즈 소유자가 엔터프라이즈 수준에서 정책을 설정한 경우 secret scanning을(를) 사용하거나 사용하지 않도록 설정하지 못할 수 있습니다. 자세한 내용은 "엔터프라이즈에 대한 코드 보안 및 분석을 위한 정책 적용"을(를) 참조하세요.

secret scanning을 구성하여 많은 서비스 공급자가 발급한 비밀을 확인하고 비밀이 검색된 경우 이를 알릴 수 있습니다. 사용자 지정 패턴을 정의하여 리포지토리, 조직 또는 엔터프라이즈 수준에서 추가 비밀을 검색할 수도 있습니다. 자세한 내용은 "비밀 검사 정보" 및 "지원되는 비밀 검사 패턴"을(를) 참조하세요.

GitHub Enterprise Server에서 사용하는 비밀의 보안 스토리지

코드 외에도 다른 위치에서 비밀을 사용해야 할 수 있습니다. 예를 들어 GitHub Actions 워크플로 또는 Dependabot이 다른 시스템과 통신할 수 있도록 허용합니다. 비밀을 안전하게 저장하고 사용하는 방법에 대한 자세한 내용은 "GitHub Actions에서 비밀 사용" 및 "Dependabot에 대한 개인 레지스트리 액세스 구성"을(를) 참조하세요.

리포지토리에서 취약한 코딩 패턴 제외

참고: GitHub Advanced Security을(를) 사용하도록 설정된 조직 소유 리포지토리

참고: 사이트 관리자가 먼저 code scanning를 사용하도록 설정해야 이 기능을 사용할 수 있습니다. 자세한 내용은 "어플라이언스에 대한 코드 검사 구성"을(를) 참조하세요.

엔터프라이즈 소유자가 엔터프라이즈 수준에서 GitHub Advanced Security 정책을 설정한 경우 code scanning을(를) 사용하거나 사용하지 않도록 설정할 수 없습니다. 자세한 내용은 "엔터프라이즈에 대한 코드 보안 및 분석을 위한 정책 적용"을(를) 참조하세요.

이 문서의 내용