TuxCare와 JFrog, 오픈소스 보안 취약점 해결을 위해 파트너십 체결

주요 내용

SecureChain 수정 사항은 JFrog Zero-Touch Remediation 내에서 제공되며, 버전 번호 변경 없이 적용됩니다.
문제 탐지는 결코 어려운 부분이 아니었습니다. 오류가 재발하지 않는 수정본을 만들어 배포하는 것이 항상 어려운 일이었죠.
패키지에 대한 보안 수정 사항 제공이 상류 유지보수자 측에서 중단된 후에도 지원은 계속됩니다.
적용된 모든 수정 사항은 JFrog AppTrust를 통해 검증되므로, 감사 증거가 파이프라인에서 자동으로 생성됩니다.

의존성 트리에서 세 단계 아래에 위치한 패키지에 심각한 CVE가 발견됩니다. 스캐너가 당일에 이를 포착하는데, 이 부분은 비교적 수월합니다. 하지만 수정 사항은 메이저 릴리스에서만 제공되는 것으로 드러나고, 해당 릴리스는 팀이 사용하는 두 서비스에서 호출하는 API를 변경하며, 이 패키지를 가져온 것은 팀 내 누구도 통제할 수 없는 벤더 SDK에 의해 고정되어 있습니다. 2주가 지나도 티켓은 여전히 열려 있고, 해당 발견 사항은 보고서에 그대로 남아 있습니다.

취약점이 있는 오픈소스 패키지를 찾는 것은 거의 어려운 일이 아닙니다. 그 과정에서 또 다른 문제를 일으키지 않으면서 올바른 수정 사항을 올바른 빌드에 반영하는 것이야말로 문제 해결을 복잡하게 만드는 부분입니다.

이것이 바로 새로운 파트너십이 해결하고자 하는 격차입니다. TuxCare는 JFrog의 ‘자가 치유형 소프트웨어 공급망 보안 생태계(Self-Healing Software Supply Chain Security Ecosystem)’에 창립 파트너로 합류했으며, SecureChain은 취약한 오픈소스 패키지에 대한 수정 사항의 공급원으로 JFrog Zero-Touch Remediation과 연동될 예정입니다.

오픈소스 문제 해결이 실제로 주춤하는 지점

스캐너의 탐지 범위가 이제 충분히 넓어져서, 대부분의 팀은 취약한 종속성에 대한 대응 방안이 마련되기도 훨씬 전에 이미 그 사실을 파악하고 있습니다. 그 결과, 처리해야 할 작업 목록이 쌓이게 됩니다.

취약점이 있는 타사 패키지가 있으면 세 가지 실질적인 선택지가 남습니다. 수정된 버전으로 업그레이드하거나, 직접 수정 사항을 백포트하거나, 아니면 위험을 감수하고 직접 코드를 작성하는 것입니다. 첫 번째 방법은 모든 도구가 권장하는 방식이지만, 대개 가장 비실용적입니다. 전이적 의존 관계에서 발생하는 버전 상승은 매니페스트만으로는 누구도 예측할 수 없는 방식으로 연쇄적으로 파급되기 때문입니다. 때로는 영향을 받는 버전이 이미 지원 종료된 상태라 더 이상 업그레이드할 수 없는 경우도 있습니다. 두 번째 방법은 자신이 작성하지 않은 코드의 포크를, 제대로 테스트할 수 없는 코드베이스에서 유지 관리해야 한다는 것을 의미합니다. 세 번째 방법이 보통 실제로 일어나는 일입니다.

30명으로 구성된 플랫폼 팀이 12개의 자바 서비스를 운영하고 있다고 상상해 보세요. 그중 절반은 자체 소유가 아닌 라이선스를 통해 사용하는 SDK 때문에 구버전의 잭슨(Jackson) 라인에 묶여 있습니다. 업그레이드는 별도의 기능 추가가 없는, 여러 스프린트에 걸친 프로젝트입니다. 개발자들은 안전하게 배포할 수 있는 방법을 찾기 위해 며칠씩이나 해결 방안을 비교하는 데 시간을 허비합니다. 어떤 방법을 선택하든 주간 보고서에는 똑같은 내용이 기록되고, 감사 일정은 변하지 않습니다.

SecureChain이 기여하는 점

SecureChain 패키지는 소스 코드부터 다시 빌드되며, 공개되기 전에 악성코드 검사를 거치고, 매니페스트에 명시된 버전을 변경하지 않은 채 알려진 취약점에 대한 패치가 적용됩니다.

이 통합에는 두 가지 중요한 특성이 있습니다. 수정 패치는 동일한 버전 번호를 유지하므로, 의존성 그래프 내의 어떤 요소도 이동할 필요가 없습니다. 또한, 업스트림 유지보수가 종료되어도 지원이 중단되지 않습니다. 유지보수 담당자가 작업을 중단한 후에도 ‘무한 수명주기 지원(Endless Lifecycle Support)’을 통해 해당 버전 계열에 대한 수정 패치가 계속 제공되기 때문입니다.

바로 그 두 번째 특성에는 오래 지속되는 발견 사항들이 많이 포함되어 있습니다. 3년 동안 커밋이 한 번도 없었던 패키지라면, 아무리 많은 티켓이 이를 참조하고 있다 해도 해당 패키지 관리자로부터 CVE 수정 패치를 받을 수 없을 것입니다.

현재 SecureChain의 지원 범위는 npm, PyPI, Maven에 이르고 있으며, 향후 Go, Rust, PHP도 지원될 예정입니다.

파이프라인 내부에서 일어나는 일

Artifactory는 빌드가 소스를 가져오는 곳이기 때문에, 개발자에게 별도의 변경을 요청하지 않고도 수정된 버전을 적용할 수 있는 유일한 장소입니다.

제로 터치 수정(Zero-Touch Remediation) 기능은 취약점이 있는 구성 요소를 정책에 따라 이용 가능한 최적의 파트너 수정 사항과 매칭하고, 사용자가 이미 실행 중인 파이프라인을 통해 이를 적용하며, JFrog AppTrust를 통해 해당 조치에 대한 서명된 증명서를 기록합니다. 정책에서 소스 재빌드 및 지속적인 패치 적용이 적용된 패키지를 선호하는 경우, SecureChain 버전이 제공됩니다. 빌드 프로세스는 전날 요청했던 것과 동일한 패키지를 요청하면 패치된 패키지를 받게 됩니다.

티켓도 필요 없고, 호환되는 버전을 찾아 헤매지도 않으며, 서비스를 운영하는 팀과 협상할 필요도 없습니다.

인증 부분은 겉으로 보이는 것보다 더 큰 가치가 있습니다. 대부분의 팀은 결국 해당 패키지에 패치가 적용되었다는 사실을 입증할 수 있습니다. 하지만 언제 패치가 적용되었는지, 어떤 CVE에 대응한 것인지, 그리고 어떤 절차를 통해 적용되었는지를 감사관이 추가 질의 없이 받아들일 수 있는 형태로 입증할 수 있는 팀은 훨씬 적습니다.

이것이 가장 먼저 효과를 발휘하는 곳은

가장 확실한 성과는 업스트림 지원이 종료된 패키지, 팀이 직접 선택하지도 않았고 쉽게 대체할 수도 없는 전이적 의존성, 그리고 문제 해결에 대한 SLA가 단순한 목표가 아닌 계약상 의무로 명시된 모든 환경입니다.

이미 Xray 또는 Advanced Security와 함께 Artifactory를 운영 중이라면, SecureChain을 수정 소스로 추가하는 것은 마이그레이션이라기보다는 정책상의 결정에 해당합니다. 빌드 소스가 JFrog 이외의 곳에서 가져오는 경우에도 SecureChain은 독립형 심사 레지스트리로 정상적으로 작동하며, 필요할 때 언제든지 통합 기능을 활용할 수 있습니다.

어느 쪽이든, 주목할 만한 변화는 수정 사항이 존재한다는 사실이 아닙니다. 수정 사항은 예전에도 존재했으니까요. 중요한 점은 사람이 직접 전달하지 않아도 수정 사항이 실행 중인 빌드에 적용될 수 있다는 사실이며, 바로 이 점이 문제 해결을 단순한 프로젝트 차원의 작업에서 소프트웨어를 출시하는 과정의 일상적인 부분으로 전환시키는 것입니다.

JFrog 제로 터치 수정 기능에 대한 자세한 내용: jfrog.com/zero-touch-remediation

TuxCare SecureChain에 대한 자세한 정보: tuxcare.com/securechain-for-oss

요약