PHP 패키지에 지속적으로 패치를 적용하는 Packagist 대체 솔루션

이 블로그 글의 AI 요약으로 바로 가기

주요 내용

포기된 패키지는 CVE가 공개된 상태라도 Packagist를 통해 계속 설치할 수 있는데, 이는 패키지 수정 작업이 애초에 Packagist의 업무가 아니었기 때문이다.
SecureChain은 PHP 패키지를 설치 전에 재컴파일하고 검토한 다음, 업스트림 유지보수가 느려지거나 중단될 경우 지속적으로 패치를 적용합니다.
Composer 설정 전체를 SecureChain을 통해 처리하거나, 필요한 패키지만 전송할 수 있습니다.
Private Packagist는 사용자의 패키지를 호스팅하고 미러링하는 반면, SecureChain은 더 이상 유지보수되지 않는 패키지에 패치를 적용합니다.

CVE가 공개된 채 방치된 Composer 패키지는 사용자를 곤란한 처지에 빠뜨립니다. 업스트림에서 수정 사항이 나올 가능성은 거의 없으므로, 직접 포크하거나 다른 패키지로 교체하거나, 보완 조치를 문서화하여 감사관이 이를 수용해 주기를 바라는 것 외에는 별다른 선택지가 없습니다. 이 문제를 해결하기 위해 개발된 Packagist 대안인 SecureChain은 패치 변경 사항을 기반으로 구축되었습니다. SecureChain은 PHP 패키지가 사용자의 빌드 단계에 도달하기 전에 재컴파일하고 검수하며, 원본 유지보수자가 활동을 중단한 후에도 오랫동안 SLA에 따라 수정 사항을 지속적으로 제공하므로, Packagist 대신 또는 Packagist와 병행하여 사용할 수 있습니다.

다음은 해당 기능이 실제로 무엇을 포함하는지, 그리고 여러분이 이미 사용하고 있는 Composer 워크플로우와 어떻게 조화를 이루는지에 대한 설명입니다.

팀들이 Packagist의 대안을 찾는 이유

Packagist는 본래의 목적대로 작동합니다. 패키지 저장소를 색인화하고 Composer에 코드를 어디서 가져와야 할지 알려주며, 그 역할을 훌륭하게 수행합니다. 하지만 Packagist가 결코 의도하지 않았던 것은 어떤 문제도 해결하는 것이 아닙니다. 유지보수자가 릴리스를 중단하더라도, Composer는 Packagist 메타데이터와 CVE 정보를 바탕으로 기존에 존재하는 취약점이 있는 버전을 아무 문제 없이 계속 해결해 줍니다.

올해는 상황이 달라졌습니다. 5월 말에 출시된 Composer 2.10은 해결 단계와 기존 잠금 파일(lockfile)을 통한 설치 단계에서 악성코드로 표시된 버전을 차단하며, 보안 권고 사항, 유지보수가 중단된 패키지, 악성코드를 단일 종속성 정책으로 통합합니다. 이에 이어 7월, Packagist는 게시된 안정 버전을 불변(immutable)으로 만들었기 때문에, 태그가 변경된 릴리스가 사용자가 이미 잠근 버전을 몰래 대체하는 일이 더 이상 발생하지 않습니다. 두 변경 사항 모두 실질적인 개선이며, 어느 쪽도 패치를 작성하지는 않습니다. 악성 릴리스를 차단한다고 해도, CVE가 공개된 채로 방치된 패키지를 계속 사용해야 하며, 이를 수정해 줄 업스트림 개발자는 없는 상황이 남게 됩니다.

보통 이때가 되면 팀은 일회성 해결책 대신 Packagist의 대안을 찾기 시작합니다. 이 차이는 중요합니다. 해결책은 단 한 건의 감사 지적 사항을 처리할 뿐입니다. 반면 패치를 기반으로 구축된 대안은 현재 처리해야 할 버려진 패키지 한 가지뿐만 아니라, 이러한 문제가 앞으로도 계속 발생할 것이라고 가정합니다. Composer 의존성이 PHP와 달리 지원 종료일을 갖지 않는 이유에 대한 자세한 내용은 “PHP가 지원 종료되었다고 해서 Composer 의존성도 사라지는 것은 아닙니다( Your Composer Dependencies Don’t Retire Just Because PHP Did)” 기사를 참고하세요. 이 기사는 앱에서 여전히 실행 중인 패키지들에 이것이 어떤 의미를 지니는지 심도 있게 다루고 있습니다.

이 점에서 PHP만이 예외는 아닙니다. 2026년에 여러 오픈소스 생태계에서 발생한 공급망 사고로 인해 개발 팀들은 레지스트리에 대한 신뢰도를 재고해야 할 이유가 생겼으며, 이러한 현상은 특정 언어에만 국한되지 않았습니다.

업스트림 개발이 중단된 후에도 SecureChain이 어떻게 패치 작업을 지속하는지

유지보수자가 활동을 중단하면 업스트림 지원도 중단되지만, SecureChain의 지원 범위는 ‘무한 수명 주기 지원’을 통해 계속 이어집니다.

SecureChain은 이를 일회성 해결책이 아닌 라이프사이클 전반에 걸친 문제로 간주합니다. SecureChain이 제공하는 모든 PHP 패키지는 설치 가능해지기 전에 격리된 환경에서 소스 코드부터 다시 빌드되므로, 사용자의 빌드에 포함되는 내용은 아무도 재빌드하거나 확인하지 않은 업스트림 아티팩트에서 그대로 가져온 것이 아니라 처음부터 끝까지 철저히 검증된 것입니다. 또한 패키지는 알려진 악성코드 및 의심스러운 코드 패턴에 대해 선별 검사를 거치며, 검사에서 불합격된 항목은 사후에 표시되는 것이 아니라 사용자에게 전달되기 전에 차단됩니다.

패키지가 첫 번째 검사를 통과했다고 해서 작업이 끝나는 것은 아닙니다. 업스트림에서 여전히 릴리스를 배포하는 동안, 새로운 CVE가 발견될 때마다 SLA에 따라 활성 구성 요소가 모니터링되고 패치됩니다. 이는 여전히 관심을 기울이고 있는 유지보수자가 보여줄 법한 모습입니다. 업스트림의 활동이 중단되면 TuxCare가 직접 패키지 유지 관리를 이어가며, 마지막 업스트림 릴리스 이후 약 6개월이 지나면 ‘Endless Lifecycle Support’가 이를 인수하여, 원래 관리자가 복귀하든 그렇지 않든 상관없이 사용자가 해당 패키지에 의존하는 한 계속해서 수정 사항을 제공합니다.

문제를 발견한 시점과 실제로 해결하는 시점 사이의 그 간극이야말로, 많은 공급망 관리 도구가 미흡한 부분입니다. 업무 성과를 입증해야 하는 팀을 위해 SecureChain은 SLSA 레벨 3 출처 정보, SBOM 및 VEX 데이터도 생성하므로, 단순히 “이 문제가 패치되었다”는 주장을 맹신해야 하는 것이 아니라, 이를 뒷받침하는 기록을 확인할 수 있습니다.

SecureChain이 Packagist와 어떻게 조화를 이루는지

이 모든 과정을 진행한다고 해서 팀이 기존에 Composer를 사용해 온 방식을 완전히 바꿔야 하는 것은 아닙니다. SecureChain은 공개 Packagist 대신 또는 이와 병행하여 사용할 수 있는 Composer 호환 저장소이며, 트래픽의 어느 정도를 SecureChain을 통해 처리할지는 귀사에서 결정하시면 됩니다.

일부 팀은 전체 Composer 설정을 SecureChain을 통해 처리하므로, 더 이상 사용되지 않는 패키지뿐만 아니라 가져오는 모든 패키지가 설치 전에 재빌드되고 검토됩니다. 다른 팀들은 보다 제한적인 접근 방식을 취하여, 더 이상 사용되지 않거나 고위험으로 확인된 패키지만 전송하고, 그 외의 모든 패키지는 현재와 똑같이 Packagist에서 직접 가져옵니다. 카탈로그에 아직 등록되지 않은 항목은 요청 시 추가할 수 있습니다. 어느 쪽이든 개발자들은 계속해서 동일한 composer install 그리고 composer update 이미 알고 있는 명령어들을 사용하며, 저장소가 설정되면 일상적인 업무 흐름은 그대로 유지됩니다.

SecureChain을 통해 라우팅되는 모든 경우, 이러한 명령어 뒤에서 일어나는 과정이 달라집니다. Composer는 Packagist 메타데이터가 가리키는 곳( 소스 저장소나 배포 아카이브 )에서 패키지를 다운로드하는 대신, 해당 패키지가 이미 재빌드되고, 검증을 거치며, 패치가 적용된 저장소에서 패키지를 가져옵니다. lockfile에는 여전히 Composer가 해결한 버전과 참조 정보가 기록됩니다. 다른 점은 패키지의 출처입니다. 일반적인 업스트림 경로를 통해 제공되었을 패키지 대신, TuxCare 리포지토리에서 제공되는 재빌드되고 유지 관리된 패키지가 사용됩니다.

Composer 스택에 SecureChain 적용하기

지난번 감사 결과, 공개된 보안 권고가 있는 버려진 패키지가 두세 개 발견되었다면, 이는 범위가 좁고 명확하게 정의된 시작점일 뿐, 전체 의존성 구성을 재설계해야 할 이유는 아닙니다. 버려진 패키지 목록이 그보다 더 길다면, 가장 먼저 고려해야 할 질문은 그 중 어떤 패키지에 대해 현실적으로 패치를 적용할 수 있는지입니다. 이는 Composer 설정 중 어느 정도를 처음부터 SecureChain을 통해 처리하는 것이 합리적인지를 결정하는 기준이 되기 때문입니다.

SecureChain은 Private Packagist를 대체하는 서비스가 아니므로, 이 둘을 명확히 구분하는 것이 좋습니다. Composer와 Packagist.org를 운영하는 Packagist Conductors의 Private Packagist는 비공개 패키지 호스팅, 미러링 및 배포 제어를 담당하며, 지난 1년 동안 자체적으로 상당한 규모의 공급망 보안 도구를 추가해 왔습니다. 하지만 Private Packagist가 하지 못하는 일은, 수년 전부터 유지보수자가 응답을 중단한 종속성에 대한 수정 사항을 역포트하는 것입니다. 비공개 호스팅이 주된 목적인 팀에게는 Private Packagist가 더 적합하며, 두 서비스가 서로의 역할을 수행하지 않기 때문에 두 서비스를 모두 운영하는 것도 지극히 합리적인 선택입니다.

PHP 패키지가 보안 범위가 미흡한 영역이라면, SecureChain for PHP를 살펴보시고 이 솔루션이 어떻게 작동하는지 더 자세히 확인해 보시거나, 귀사의 특정 스택에서 어떤 부분을 커버할 수 있는지 안내를 받아보시려면 견적을 요청해 주십시오.

자주 묻는 질문

Packagist의 대안은 무엇인가요?

Packagist의 대안은 공개 Packagist 대신 또는 이와 병행하여 사용되는 Composer 호환 저장소입니다. 팀들은 비공개 호스팅, 통제된 배포, 더 엄격한 보안 심사, 또는 더 이상 유지보수되지 않는 패키지에 대한 지속적인 패치 제공 등 공개 Packagist에서 제공하지 않는 기능이 필요할 때 이러한 대안을 선택합니다.

SecureChain은 실제로 어떤 부분을 수정하나요?

SecureChain은 PHP 패키지의 전체 수명 주기 동안 취약점을 패치합니다. 사용 중인 패키지는 SLA에 따라 패치되며, 업스트림 개발이 중단되면 TuxCare가 직접 유지 관리를 이어가고, 그 이후에도 Endless Lifecycle Support를 통해 해당 패키지를 실행하는 동안 장기적인 지원을 제공합니다.