저희 조직에서는 프로덕션 환경에 배포하기 전에 Docker 이미지에서 발견된 High/Critical 등급의 모든 취약점을 패치하도록 요구하고 있습니다. 현재 저희가 구축한 Discourse는 discourse/base:2.0.20251008-0017-web-only를 기반으로 하며, 이 중 일부 취약점을 가능한 한 패치하려고 노력하고 있습니다. 아래는 패치가 필요한 취약점 목록입니다.
그냥 한번 시도해보고 결과를 지켜보시는 게 좋겠습니다. 보안과 라이브러리 버전 관리를 전문으로 하는 사람이 꽤 많으니까요.
하지만 잠깐. 만약 기본 Docker 이미지를 보고 계신다면(아, 아니면 직접 빌드한 이미지를 말씀하시는 건가요? 정확히 파악이 잘 안 되네요), 그렇다면 당신의 일은 불가능할 것 같습니다. 그 중 많은 부분이 Discourse 소스에서 관리되니까요. 예를 들어, 이 커밋에서는 Rack를 2.2.20으로 업그레이드합니다. 기본 Docker 이미지의 버전은 중요하지 않습니다. 아마도 launcher를 사용하여 이미지를 빌드한 후 어떤 버전의 구성 요소들이 있는지 확인하시는 것이 좋을 것입니다. 그런 다음 go와 python을 제거하기 위해 일부 yaml을 추가할 수 있습니다.
또한, 시스템에 다른 사용자가 있을 때만 문제가 되는 보안 이슈들이 꽤 있습니다. 따라서 Docker 컨테이너에 그런 것들이 있다는 것은 실제로는 중요하지 않으며, Discourse 팀이 우선순위로 다루지 않을 가능성이 높습니다.
현재 빌드 프로세스는 이전 메시지에서 언급된 discourse 기본 이미지로 시작하며, 그 다음에 스크립트를 실행합니다. 이 스크립트는 지원되는 설치 프로세스의 부트스트랩 단계(런처 스크립트)일 뿐이며, 활성 redis/db 연결이 필요한 단계는 실행하지 않습니다.
따라서 부트스트랩 단계에서는 discourse의 모든 ruby 의존성과 npm 의존성이 설치된다고 가정합니다. 취약성 목록에 표시되는 버전들은 대부분 discourse 애플리케이션 자체의 의존성입니다.
또한 조사해 본 결과, 태그가 지정되는 golang 의존성은 golang으로 빌드된 esbuild라는 npm 의존성에서 비롯된다는 것을 알게 되었습니다. 사용하는 go 버전에는 표준 라이브러리 취약성이 있어 태그가 지정되고 있습니다. 따라서 이 문제를 해결하려면 해당 라이브러리를 다시 컴파일해야 할 것 같아, 노력할 가치가 있는지 확실하지 않습니다.
하지만 다른 취약성들은 discourse의 직접적인 ruby/npm 의존성 또는 전이적 의존성입니다. 제 질문은 주로 설치 직전에 해당 의존성들의 버전을 업데이트하는 것에 관한 것이었습니다. discourse 개발자들이 이를 수정하는 작업이 어려울 것임을 이해합니다. 다만, 일부 의존성은 특정 코드 경로에서만 문제를 일으킬 수 있을 것 같다는 추측에서, "업그레이드"가 문제를 일으키는지 여부를 확인할 수 있는 방법이 있는지 이해하려고 했을 뿐입니다.