종속성 검토 작업 구성 사용자 지정

소개

종속성 검토 작업은 종속성 변경에 대한 pull request를 검색하고 새로운 종속성에 알려진 약점이 있는 경우 오류를 발생시킵니다. 설치되면 워크플로 실행이 필수로 표시되면 알려진 취약한 패키지를 도입하는 끌어오기 요청이 병합되지 않도록 차단됩니다.

이 가이드에서는 취약성 심각도 수준, 종속성 라이선스 및 범위를 기준으로 빌드 실패라는 세 가지 매우 일반적인 사용자 지정을 추가하는 방법을 보여 줍니다.

필수 조건

이 가이드는 다음을 전제로 합니다.

• 리포지토리에 대해 종속성 그래프를 사용할 수 있습니다. 자세한 내용은 "종속성 그래프 구성"을 참조하세요.
• 리포지토리에서 GitHub Actions이(가) 사용하도록 설정되었습니다. 자세한 내용은 "리포지토리에 대한 GitHub Actions 설정 관리" 항목을 참조하세요.

1단계: 종속성 검토 작업 추가

이 단계에서는 리포지토리에 종속성 검토 워크플로를 추가합니다.

1. GitHub에서 리포지토리의 기본 페이지로 이동합니다.

2. 리포지토리 이름 아래에서 작업을 클릭합니다.

   

3. "GitHub Actions으로 시작"에서 "보안" 범주를 찾은 다음 모두 보기를 클릭합니다.

4. "종속성 검토"를 찾은 다음 구성을 클릭합니다. 또는 검색 창을 사용하여 "종속성 검토"를 검색합니다.

5. 그러면 종속성 검토의 GitHub Actions 워크플로 파일인 dependency-review.yml가 열립니다. 여기에는 다음이 포함되어야 합니다.

   YAML

   name: 'Dependency review'
   on:
     pull_request:
       branches: [ "main" ]
   
   permissions:
     contents: read
   
   jobs:
     dependency-review:
       runs-on: ubuntu-latest
       steps:
         - name: 'Checkout repository'
           uses: actions/checkout@v4
         - name: 'Dependency Review'
           uses: actions/dependency-review-action@v4
   

2단계: 심각도 변경

종속성 검토 작업을(를) 필수로 설정하여 취약한 종속성이 포함된 코드가 병합되지 않도록 차단할 수 있습니다. 그러나 일부 상황에서는 위험이 낮은 취약점을 차단하는 것이 너무 제한적일 수 있다는 점에 유의하세요. 이 단계에서는 fail-on-severity 옵션을 사용하여 빌드가 실패하는 취약성의 심각도를 변경합니다.

1. dependency-review.yml 파일의 끝에 fail-on-severity 옵션을 추가합니다.

   YAML

         - name: 'Dependency Review'
           uses: actions/dependency-review-action@v4
           with:
             fail-on-severity: moderate
   

3단계: 차단할 라이선스 추가

취약성이 종속성을 차단할 수 있는 유일한 이유는 아닙니다. 조직에서 사용할 수 있는 라이선스 종류에 제한이 있는 경우 종속성 검토를 사용하여 deny-licenses 옵션으로 해당 정책을 적용할 수 있습니다. 이 단계에서는 끌어오기 요청이 LGPL-2.0 또는 BSD-2-Clause 라이선스를 포함하는 종속성을 도입하는 경우 빌드를 중단하는 사용자 지정을 추가합니다.

1. dependency-review.yml 파일의 끝에 deny-licenses 옵션을 추가합니다.

   YAML

         - name: 'Dependency Review'
           uses: actions/dependency-review-action@v4
           with:
             fail-on-severity: moderate
             deny-licenses: LGPL-2.0, BSD-2-Clause
   

4단계: 범위 추가

마지막으로, fail-on-scopes 옵션을 사용하여 취약한 종속성이 특정 배포 환경(이 경우 개발 환경)에 병합되지 않도록 합니다.

1. dependency-review.yml 파일의 끝에 fail-on-scopes 옵션을 추가합니다.

   YAML

         - name: 'Dependency Review'
           uses: actions/dependency-review-action@v4
           with:
             fail-on-severity: moderate
             deny-licenses: LGPL-2.0, BSD-2-Clause
             fail-on-scopes: development
   

5단계: 구성 확인

이제 dependency-review.yml 파일은 다음과 같아야 합니다.

name: 'Dependency Review'
on: [pull_request]


permissions:
  contents: read


jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - name: 'Checkout Repository'
        uses: actions/checkout@v4
      - name: Dependency Review
        uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: moderate
          deny-licenses: LGPL-2.0, BSD-2-Clause
          fail-on-scopes: development

name: 'Dependency Review'
on: [pull_request]


permissions:
  contents: read


jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - name: 'Checkout Repository'
        uses: actions/checkout@v4
      - name: Dependency Review
        uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: moderate
          deny-licenses: LGPL-2.0, BSD-2-Clause
          fail-on-scopes: development

사용자 지정 구성에 대한 템플릿으로 이 구성을 사용할 수 있습니다.

가능한 모든 사용자 지정 옵션에 대한 자세한 내용은 종속성 검토 작업 설명서의 추가 정보를 참조하세요.

모범 사례

종속성 검토 구성을 사용자 지정할 때 수행할 수 있는 몇 가지 모범 사례가 있습니다.

• 허용 목록 대신 차단 목록을 선택합니다. 허용하려는 모든 라이브러리의 포괄적인 목록을 만드는 것보다 차단하려는 "정말 나쁜" 종속성 목록을 컴파일하는 것이 더 실용적입니다.

• 허용할 라이선스를 지정하는 대신 라이선스를 차단하도록 선택합니다. 다양한 라이선스가 있으므로 호환되는 라이선스의 전체 목록을 컴파일하는 것보다 현재 라이선스와 호환되지 않는 라이선스를 제외하는 것이 일반적으로 더 실용적입니다.

• fail-on-severity을 선택합니다. 취약성의 심각도에 따라 실패하는 것은 보안에 대한 필요성과 개발자를 위한 마찰이 적은 환경을 만들어야 하는 필요성 간의 균형을 맞추는 좋은 방법입니다.

추가 참고 자료

• "종속성 검토 구성"
• "조직 전체에서 종속성 검토 적용"