PR에서 Snyk 활성화 및 구성

PR 확인을 사용하여 게이팅 도입

Snyk 풀 리퀘스트(PR) 또는 병합 리퀘스트(MR) 확인을 사용하면 풀 리퀘스트(PR) 제출 시 코드 변경 사항을 자동으로 스캔하여 새로운 보안 문제가 코드베이스에 유입되는 것을 방지할 수 있습니다. PR 확인은 오픈소스 취약점, 라이선스 준수 문제 및 자체 코드 문제에 대해 사용할 수 있습니다.

소스 제어 통합을 통해 프로젝트를 가져오는 경우, Snyk 오픈소스 PR 확인은 게이팅을 도입하기 시작하기 좋은 지점입니다.

변경 사항을 롤아웃하기 전에 이를 공지할 것을 권장합니다. 개발자에게 메시지를 보내는 예시는 공지 템플릿을 참조하십시오.

PR 확인 구현

개발 팀과의 마찰을 피하기 위해 기능을 점진적으로 도입하는 데 도움이 되는 실패 조건(fail conditions)을 사용할 수 있습니다.

실패 조건을 사용하면 PR 자체가 이슈가 있는 종속성을 추가하는 경우(가장 일반적임) 또는 리포지토리 전체에 이슈가 있는 경우 테스트를 실패 처리할지 여부를 제어할 수 있습니다.

테스트 실패를 구성하는 기준도 사용자 정의할 수 있습니다. 기본적으로 테스트는 심각도나 수정 가능 여부에 따라 필터링하지 않으므로 PR 테스트가 자주 실패할 수 있습니다. 테스트 실패 기준을 다음과 같이 사용자 정의할 수 있습니다.

• 높음(High) 또는 치명적(Critical) 심각도 이슈에 대해서만 실패; Snyk 오픈소스 및 Snyk Code에서 사용 가능한 기능

• 발견된 이슈에 수정 사항이 있는 경우에만 실패; Snyk 오픈소스에서 사용 가능한 기능

PR 확인을 처음 활성화할 때, Snyk은 높음 또는 치명적이고 수정 가능한 이슈가 발견된 경우 테스트가 실패하도록 이 두 상자를 모두 선택할 것을 권장합니다. 이 경우 개발자가 진행하기 전에 이슈를 수정하도록 권장하고 싶을 것입니다.

이러한 PR 테스트는 기본적으로 선택 사항(optional)입니다. 즉, 테스트가 실패하더라도 개발자가 계속해서 PR을 병합할 수 있습니다. PR 테스트를 선택 사항으로 둘지 아니면 차단할지 여부는 GitHub의 브랜치 보호 규칙과 같은 소스 제어 관리 플랫폼 내에서 구성됩니다.

단계적 롤아웃을 위해 PR 확인 사용

Snyk 기능을 단계적으로 롤아웃하는 것이 일반적입니다. PR 확인을 예로 들면 다음과 같습니다.

• 처음에는 Snyk 테스트를 실행하고 소스 제어 설정을 통해 선택적 확인(optional checks)으로 설정할 수 있습니다. 결과는 표시되지만 개발자가 PR을 병합하는 것이 차단되지는 않습니다.

• 시간이 지나면서 개발자들이 이러한 결과를 보는 데 익숙해지고 중대한 이슈를 사전에 해결하기 시작하면, 새로운 높음 또는 치명적 심각도 이슈가 있거나(Snyk 오픈소스의 경우) 수정 사항이 있는 경우 PR 병합을 차단하기 시작할 수 있습니다.

이러한 단계적 롤아웃은 보안 팀과 개발 팀 간의 마찰을 줄이는 데 도움이 됩니다.

추가 정보

PR 확인을 사용한 개발자 우선 방어 전략 웨비나에서는 PR 확인을 더 자세히 다루고 이 기능을 점진적으로 도입하는 방법의 예시를 포함하고 있습니다.