취약점 수정과 배포 운영

컨테이너 기본 이미지와 오픈 소스 의존성의 취약점은 소프트웨어를 빌드한 뒤에도 발견됩니다. Apollo는 영향을 받는 배포 환경(Environment)을 찾고 수정 릴리스의 배포를 조정하지만, 수정 속도는 의존성 구성과 릴리스 절차에도 좌우됩니다.

필요한 의존성만 유지

사용하지 않는 패키지를 제거하면 새 CVE가 제품에 영향을 줄 가능성과 지속적으로 처리할 발견 사항을 줄일 수 있습니다. 직접 의존성뿐 아니라 함께 설치되는 전이 의존성도 검토합니다.

• 기본 이미지는 필요한 패키지만 가진 최소 이미지나 scratch 이미지를 검토합니다. 범용 이미지의 사전 설치 패키지가 애플리케이션에는 필요하지 않을 수 있습니다.
• 필수 패키지가 추가하는 전이 의존성을 확인하고, 불필요한 항목은 컨테이너 빌드 과정에서 제거합니다.
• 디버깅 도구를 운영 컨테이너에 항상 포함하는 대신, 필요한 경우 Kubernetes의 임시 디버그 컨테이너를 사용합니다.

반복적으로 문제가 생기는 의존성은 업그레이드만 반복하기보다 제거하거나 다른 구성 요소로 대체할 수 있는지 검토합니다.

구성 요소별 독립 릴리스

여러 구성 요소를 하나의 릴리스로 묶으면 그중 하나의 취약점이 전체 업그레이드를 막을 수 있습니다. 특히 여러 팀이 같은 제품에 기여할 때는 개별 구성 요소를 독립적으로 수정하고 배포할 수 있도록 분리하는 편이 유리합니다.

Apollo의 제품 릴리스 의존 관계는 함께 동작해야 하는 제품 간 버전 조건을 표현합니다. 여러 Helm 차트로 큰 애플리케이션을 구성하면서 각 구성 요소를 독립적으로 릴리스할 수 있습니다. 분리한 뒤에도 호환 버전 조건은 유지해야 합니다.

의존성 갱신과 릴리스 자동화

제품 수가 늘어나면 수동 갱신으로 최신 의존성을 유지하기 어렵습니다. Dependabot 같은 도구나 조직의 스크립트로 의존성 갱신을 자동화하고 제품을 자주 릴리스합니다. 릴리스마다 최신 패키지 버전으로 이미지를 다시 빌드하면 기본 이미지에 남은 오래된 패키지를 줄일 수 있습니다.

의존성 갱신을 안전하게 배포하려면 테스트, blue/green 업그레이드, 상태 점검과 롤백 수단을 함께 마련합니다. 호환성을 깨는 변경은 뒤로 미루지 말고 일찍 처리해야 이후 갱신이 막히는 기간을 줄일 수 있습니다.

수정본을 실제 환경까지 전달

보안 SLA에는 수정 코드를 만드는 기한뿐 아니라 배포된 버전을 교체하는 기한도 포함해야 합니다. CI 검사에서 수정본이 통과해도 환경이 이전 버전을 계속 실행하면 취약점은 남습니다.

온프레미스, 망분리 또는 간헐적으로 연결되는 환경에는 수정본을 전달하고 적용할 경로가 필요합니다. 가능한 단계는 자동화하되 환경의 승인 정책과 유지보수 시간대를 함께 고려합니다.

Apollo는 취약점 자동 회수와 회수된 버전에서 전환을 지원합니다. 완전히 안전한 후보가 없고 중간 릴리스를 거쳐야 한다면, 별도 설정과 자격 조건 아래 CVE로 회수된 릴리스로 업그레이드하여 위험을 낮추거나 유지하는 경로를 사용할 수 있습니다.

배포 위치와 영향 범위 확인

제품 관점에서는 어떤 버전이 어디에 설치되었는지, 환경 관점에서는 어떤 제품과 버전이 실행 중인지 확인합니다. 회수 안내와 집계 상태는 문제가 있는 릴리스를 표시합니다.

Risk Management와 리소스별 Security 탭은 CVE를 기준으로 영향을 받는 릴리스와 배포 개체를 연결합니다. 위험도가 높거나 배포 범위가 넓은 취약점을 우선 처리하고, 안전한 대체 릴리스가 없는 사례는 별도로 검토합니다. 즉시 수정할 수 없는 발견 사항에는 근거와 만료일을 갖춘 억제 요청을 제출할 수 있습니다.