취약점 해결을 위한 Snyk 패치
패치 소개
가끔은 취약점을 해결할 수 있는 직접 업그레이드가 없거나 기능적인 이유로 업그레이드가 불가능할 수도 있습니다. 예를 들어, 업그레이드가 주요한 변경 요소일 때입니다.
이러한 경우, Snyk이 패치를 사용하여 코드를 보호할 수 있습니다. 이 옵션은 취약점을 해결하기 위해 로컬로 설치된 node_modules 파일에 최소한의 수정을 가하게 됩니다. @snyk/protect를 사용하면 이 문제에 대한 패치를 업데이트합니다.
다음 시나리오에서 패치가 적용됩니다:
직접 의존성에 대한 업그레이드 옵션이 없을 때.
간접 의존성의 취약점이 있는 버전에 도달할 수 있는 직접 의존성을 업그레이드할 방법이 없을 때.
업그레이드가 패키지가 현재 코드베이스와 호환되지 않게 만들 때.
패치는 소스 코드 통합 및 @snyk/protect를 통해 이용할 수 있습니다.
패치 생성 프로세스
패치는 Snyk에서 생성하고 유지보수합니다. 패키지 소유자가 코드 변경을 통해 문제를 해결한 경우, 우리의 패치는 이 공식 수정을 기반으로 만들어지며, 미적이거나 관련 없는 변경 사항은 삭제합니다. 패키지 소유자가 취약성에 대해 아직 조치하지 않은 경우 우리는 새로운 패치를 작성합니다.
발표 전에 패치를 확인하고 오래된 버전으로 다시 적용하며, 패치가 기능을 손상시키지 않았는지 테스트합니다.
패치는 Snyk 취약점 데이터베이스의 일부이므로 적용 전에 확인할 수 있습니다.
Snyk 패치가 생성되는 방법과 시점
Snyk은 고영향 취약성에 대해 패치를 생성합니다. 취약성이 많은 사용자에게 영향을 미치는 인기 있는 패키지의 중대 취약성인 경우 고영향으로 판단됩니다.
Snyk 보안 팀은 패치를 생성하는데, 일반적으로 종속성에 추가된 수정 사항을 다시 적용하는(backporting) 방식으로 진행합니다. Backporting은 소프트웨어의 특정 버전에 대한 수정 사항을 가져와 해당 소프트웨어의 이전 버전에 적용하는 작업입니다. 이 작업은 소프트웨어를 기능적으로 동일하게 업데이트하면서 취약점 수정이 적용되게 합니다. 자세한 내용은 레드햇의 보안 패치 백포팅(Backporting Security Fixes) 참조하세요.
Snyk 보안 엔지니어에 의해 패치가 생성되고, 팀의 다른 두 멤버가 리뷰를 합니다. 또한 패치는 다음과 같은 방법으로 테스트됩니다:
패키지를 빌드하고 해당 패키지의 자동화된 테스트를 사용하여 테스트
해당 패키지를 사용하는 패키지나 응용 프로그램을 자동화된 테스트를 사용하여 테스트
Snyk 보안 팀이 작성 및 실행한 사용자 정의 테스트
모든 패치는 커뮤니티에서 다운로드 및 검토할 수 있으며, Snyk은 모든 피드백을 환영합니다.
유지되지 않는 패키지의 경우, Snyk은 패치를 생성하고 해당 패치가 병합되기 위해 프로젝트에 대한 풀 리퀘스트를 오픈합니다.
Snyk CLI를 사용할 때 패치가 작동하는 방법
CLI를 사용하여 패치를 적용하는 방법에 대한 자세한 정보는 Snyk CLI를 사용하여 취약점 수정을 참조하십시오.
소스 코드 통합을 사용할 때 패치가 작동하는 방법
취약점을 해결하기 위해 패치를 사용하려면 snyk이 종속성으로 추가되며, 패치를 적용해야 할 목록이 포함된 .snyk 파일이 생성됩니다.
.snyk 파일에는 node_modules에서 여러 위치에 나타날 수 있기 때문에 각각의 경로에 대한 패치 세부 정보가 포함되어 있습니다.
'npm:negotiator:20160616':
- errorhandler > accepts > negotiator:
patched: '2017-05-05T12:39:16.961Z'
- negotiator:
patched: '2017-05-05T12:39:16.961Z'Last updated