릴리스에 포함되는 항목 검증하기

의존성이 필요한지 확인하세요

에이전트는 문제를 해결할 듯한 패키지를 제안할 수 있습니다. 제안은 패키지가 실제로 존재하거나 적합하다는 증거가 아닙니다. 설치 전에 정확한 레지스트리, 게시자, 패키지 이름, 버전을 검증하세요.

가상의 CSV 내보내기에서는 런타임이 필요한 동작을 이미 제공할 수 있습니다. 새 패키지가 적합할 수도 있지만 유지보수와 실행 경로가 추가됩니다. 구현에 드는 노력과 의존성으로 인해 계속 맡아야 할 책임을 비교하세요.

라이선스와 지원 런타임을 검토하세요. 유지보수 활동과 관련 보안 권고를 살펴보세요. 익숙한 이름이 다른 레지스트리에서는 다른 패키지를 가리킬 수 있습니다. 설치 성공은 설치가 완료되었다는 것만 보여 줍니다.

설치와 빌드 동작을 살펴보세요

의존성은 설치나 빌드 중에 코드를 실행할 수 있습니다. 이런 환경에서는 자격 증명과 네트워크 접근을 제한하세요. 신뢰할 수 없는 풀 리퀘스트를 처리하는 작업에 프로덕션 비밀 정보를 노출하지 마세요.

생태계가 지원한다면 커밋된 잠금 파일을 사용하세요. 빌드가 해당 파일을 따르도록 요구하세요. 예상하지 못한 전이 의존성을 포함해 잠금 파일 변경을 소스 변경과 함께 검토하세요. 버전 고정은 재현성을 높이지만 취약한 버전을 안전하게 만들지는 않습니다.

NIST의 SSDF는 수명주기 전반에 걸친 소프트웨어 보호와 개발 관행을 다룹니다. 빌드 환경을 설계할 때 이 넓은 관점을 적용하세요. 프레임워크 읽기.

구성 요소 목록과 생성 이력을 구분하세요

소프트웨어 자재 명세서인 SBOM은 소프트웨어의 구성 요소를 기록합니다. 구성 요소에 문제가 생겼을 때 영향받는 릴리스를 찾는 데 도움이 됩니다. 구성 요소가 안전하다는 사실을 독립적으로 입증하지는 않습니다.

생성 이력인 provenance는 아티팩트가 어떻게 만들어졌는지 다룹니다. SLSA는 빌드와 입력 정보를 담는 생성 이력 형식을 정의합니다. 검증할 때 이 정보를 신뢰할 수 있는 생성 주체 및 사용하려는 아티팩트와 연결해야 합니다. 이름이 ‘provenance’인 파일만으로는 충분하지 않습니다. SLSA 생성 이력.

내보내기 서비스에서는 살펴볼 수 있는 다음 연결 관계를 기록하세요.

1. 검토한 커밋이 수락된 소스를 식별합니다.
2. 빌드가 입력과 실행 환경을 식별합니다.
3. 아티팩트에 변하지 않는 다이제스트가 있습니다.
4. 검사가 확인한 아티팩트나 소스를 식별합니다.
5. 배포 기록에 대상 환경에 배치된 아티팩트를 남깁니다.

승인 후에 정해진 검증 프로세스 없이 다른 방식으로 다시 빌드하지 마세요. latest처럼 변경 가능한 태그는 나중에 다른 이미지를 가리킬 수 있습니다.

발견된 문제의 의미를 판단하세요

취약점 발견 사항에는 맥락이 필요합니다. 영향받는 버전, 실행 경로에서 도달 가능한 동작, 노출, 사용 가능한 수정, 결과를 확인하세요. 임시 예외가 있다면 이를 뒷받침하는 증거를 기록하세요. 담당자, 만료 시점, 검토 계기를 정하세요.

한 발견 사항이 해당되지 않는다는 이유로 검사 도구 전체를 비활성화하지 마세요. 검사가 완료되지 않았는데 이상이 없다고 보고하지 마세요. 시간 초과, 지원하지 않는 패키지, 이용할 수 없는 보안 권고 피드는 증거가 없다는 뜻입니다.

마지막으로 릴리스 이후의 업데이트를 계획하세요. 새로운 보안 권고는 어제 수락한 아티팩트에도 영향을 줄 수 있습니다. 서비스 담당자에게는 구성 요소 목록, 대응 프로세스, 수정된 릴리스를 만들 역량이 필요합니다.

지속적인 취약점 관리에서 반복 검사와 검증된 프로덕션 수정을 연결하는 방법을 이어서 학습하세요.