PR에서 Snyk 활성화 및 구성하기
PR 체크를 사용하여 게이팅 도입
Snyk 풀 리퀘스트(PR)/머지 리퀘스트(MR) 체크를 사용하여 풀 리퀘스트(PR)를 제출할 때 코드 변경 사항을 자동으로 스캔함으로써 새로운 보안 문제가 코드베이스로 들어가지 않도록 할 수 있습니다. PR 체크는 오픈 소스 취약점, 라이선스 준수 문제 및 자체 코드 문제에 대해 사용할 수 있습니다.
만약 소스 제어 통합을 통해 프로젝트를 가져온다면, PR 체크는 게이팅을 도입하기에 좋은 장소가 될 것입니다.
PR 체크 구현
개발팀과의 마찰을 피하기 위해 이 기능을 점진적으로 도입할 수 있도록 도와줄 수 있는 여러 기능들이 있습니다.
실패 조건: PR 자체가 문제가 있는 종속성을 추가하는 경우 (가장 흔한 경우) 또는 전체 저장소에 문제가 있는 경우에 테스트가 "실패"할지 여부를 제어할 수 있습니다.
"실패 테스트"의 기준은 사용자 정의할 수도 있습니다. 기본적으로 테스트는 심각도나 수정 가능 여부에 따라 필터링되지 않기 때문에 PR 테스트가 정기적으로 실패할 수 있습니다. 테스트를 실패시키는 기준을 사용자 정의할 수 있습니다.
심각도가 높음 또는 심각인 문제에 대해서만 실패합니다.(Snyk Open Source and Snyk Code)
발견한 문제에 해결 방법이 있는 경우에만 실패합니다. (Snyk Open Source).
이 기능을 처음 활성화할 때, Snyk는 '높음 또는 심각한' 및 '수정 가능한' 문제가 발견되면 테스트가 실패하도록 두 상자를 모두 선택하기를 제안합니다. 이 경우, 개발자가 계속하기 전에 문제를 수정하도록 장려하고 싶을 것입니다.
이 PR 테스트는 기본적으로 선택 사항이며, 테스트가 실패하더라도 개발자는 계속해서 PR을 병합할 수 있습니다. PR 테스트가 선택 사항인지 또는 차단인지는 깃허브의 브랜치 보호 규칙과 같은 소스 제어 관리 플랫폼에서 구성됩니다.
단계별 롤아웃을 위한 PR 체크 사용
이러한 기능들을 단계적으로 롤아웃하는 것이 일반적입니다. PR 체크를 예로 들어 설명해보겠습니다:
Snyk 테스트를 초기에 실행하고 소스 제어 설정을 통해 선택 사항의 체크로 설정합니다. 결과는 표시되지만 개발자는 PR을 병합하는 데 차단되지 않습니다.
개발자들이 이러한 결과를 보고 비상 상황에 대해 적극적으로 대응하기 시작하자, 새로운 고 또는 심각한 심각도 문제가 있거나 의 경우에는 수정 가능한 문제가 있을 때 PR이 병합되는 것을 차단하기 시작할 수 있습니다.
이러한 단계별 롤아웃은 보안과 개발 팀 간의 마찰을 줄이는 데 도움이 됩니다.
또한 참조
더 자세한 PR 체크에 대한 웨비나와 이 기능을 점진적으로 도입하는 방법을 포함한 예제를 보려면 여기를 참조하세요: Dev-First Prevention Strategies Using PR Checks.
Last updated