이 글은 Sonatype 공식 블로그의 What Are the New Rules for Secure Open Source Consumption?을 에스코어가 공식 파트너로서 한국어로 번역한 콘텐츠입니다.
에스코어 인사이트
원문에 앞서 오픈소스 사용 통제를 운영하는 조직이 함께 점검할 만한 사항을 정리했습니다.
•
오픈소스 유입 경로를 관리형 리포지토리로 표준화합니다: 개발자 PC와 CI/CD가 서로 다른 경로로 공개 레지스트리에 직접 연결되면 통제 기준과 추적성이 흔들립니다. 승인된 소스를 하나의 일관된 경로로 제공해야 합니다.
•
다운로드 시점에 위험 유형별 정책과 다음 행동을 함께 제공합니다: 악성 패키지, 알려진 취약점, 라이선스 충돌은 필요한 대응이 다릅니다. 차단 여부만 알리는 대신 안전한 버전, 대체 컴포넌트, 예외 요청 절차까지 연결해야 합니다.
•
승인 이후에도 전이 의존성을 포함해 지속적으로 추적합니다: 처음 선택했을 때 안전했던 컴포넌트도 이후 취약점이나 악성코드가 발견되거나 유지보수가 중단될 수 있습니다. 현재 사용 중인 버전을 파악하고 조치 가능한 업그레이드 경로를 유지해야 합니다.
Sonatype 원문 번역
안전한 오픈소스 사용에는 승인된 패키지 레지스트리나 릴리스 전 스캔만으로는 부족합니다. 팀은 컴포넌트의 출처를 통제하고, 선택하는 시점에 평가하고, 적합한 버전을 고르며, 새로운 위험이 나타난 뒤에도 계속 추적해야 합니다.
Sonatype 연구에 따르면 평균 애플리케이션에는 약 180개의 의존성이 있습니다. 이 정도 규모에서는 개발자가 의존성을 결정할 때마다 일관된 통제를 적용할 수 있어야 오픈소스를 안전하게 사용할 수 있습니다.
새 기능을 구현하기 위해 개발자가 라이브러리 하나를 추가하는 상황을 생각해 보겠습니다. 단 한 번의 선택도 여러 시점에서 위험을 만들 수 있습니다.
•
선택 시점: 패키지 관리자가 해당 라이브러리와 함께 수십 개의 전이 의존성을 가져올 수 있습니다.
•
설치 시점: 악성 패키지는 애플리케이션이 빌드되기 전에 코드를 실행할 수 있습니다.
•
도입 이후: 새로운 취약점이 공개되면 영향을 받는 애플리케이션을 모두 찾아 적용 가능한 업데이트를 확인해야 할 수 있습니다.
따라서 안전한 오픈소스 사용 규칙은 선택부터 문제 해결까지 전 과정을 다뤄야 합니다.
1. 승인된 소스를 정한다
승인된 소스는 개발자, 빌드 시스템, AI 코딩 어시스턴트가 오픈소스 컴포넌트를 어디에서 가져올 수 있는지를 정합니다. 공개 레지스트리는 유용한 배포 채널이지만, 레지스트리에 올라와 있다는 사실만으로 조직이 그 안의 모든 패키지를 승인한 것은 아닙니다.
팀은 생태계별로 승인된 업스트림 소스를 정하고, 승인된 소스에 접근하는 통합 경로를 마련해야 합니다. 관리형 리포지토리를 거치지 않고 공개 레지스트리에서 직접 패키지를 가져오면 유입 코드에 대한 가시성과 통제 수준이 환경마다 달라집니다.
승인된 경로는 의존성이 자동으로 해석되는 로컬 개발 환경과 CI/CD까지 이어져야 합니다. 그렇다고 개발자가 사전에 승인된 일부 라이브러리만 사용하도록 제한할 필요는 없습니다. 필요한 패키지에 안정적으로 접근할 수 있는 경로를 제공하고, 평소 승인된 소스에서 제공하지 않는 패키지가 필요할 때 따라야 할 명확한 절차를 마련한다는 뜻입니다.
소스 승인은 출발점일 뿐입니다. 정상적인 레지스트리에도 악성 패키지가 게시될 수 있고, 정상 패키지가 나중에 침해될 수도 있습니다. 따라서 컴포넌트 자체도 별도로 평가해야 합니다.
2. 다운로드 전에 컴포넌트를 평가한다
컴포넌트는 개발 환경이나 빌드에 들어오기 전에 요청 시점에 평가해야 합니다. 특히 일부 악성 패키지는 설치 단계에서 동작할 수 있기 때문에, 빌드가 끝난 뒤 발견하면 이미 최초 노출을 막기에는 늦을 수 있습니다.
2026년 2분기 말까지 Sonatype Research가 지난 10년 동안 여러 생태계에서 기록한 악성 패키지는 180만 개를 넘었습니다. 악성 패키지가 이처럼 대규모로 확인되고 있는 만큼, 익숙한 레지스트리와 워크플로를 거치는 패키지라도 조직이 실제로 사용하는 컴포넌트를 평가해야 합니다.
평가 단계에서는 대응 방식이 서로 다른 위험을 구분해야 합니다.
•
악성 또는 의심스러운 패키지: 설치 전에 차단하거나 격리해야 할 수 있습니다.
•
알려진 취약점: 더 안전한 버전을 선택하거나 해당 컴포넌트가 애플리케이션에서 어떻게 사용되는지 평가해야 할 수 있습니다.
•
라이선스 충돌: 다른 컴포넌트를 선택하거나 조직 정책에 따라 추가 검토해야 할 수 있습니다.
각 위험에 어떻게 대응할지는 조직이 정한 위험 허용 기준에 따라 판단해야 합니다. 요청이 차단되면 개발자는 차단 이유와 이후 취할 수 있는 조치를 알아야 합니다. 다른 버전 선택, 대체 컴포넌트 선택, 예외 승인 요청 등 가능한 방법을 명확히 알 수 있어야 합니다.
3. 신뢰할 수 있는 패키지만이 아니라 신뢰할 수 있는 버전을 고른다
패키지를 신뢰할 수 있는지는 프로젝트가 실제로 사용할 버전에 따라 달라집니다. 버전마다 취약점, 동작 방식, 유지보수 상태, 의존성, 애플리케이션과의 호환성이 다릅니다. 최신 릴리스라고 해서 항상 최선은 아니며, 다른 팀이 이미 쓰는 버전이 현재 프로젝트에도 맞는다는 보장도 없습니다.
신뢰할 수 있는 버전을 선택할 때는 다음 사항을 확인해야 합니다.
•
해당 버전이 예상한 출처에서 게시됐는지, 악성 행위의 징후가 있는지
•
알려진 취약점과 애플리케이션의 실제 노출 정도
•
라이선스 요구사항과 조직 정책
•
애플리케이션 및 기존 의존성 트리와의 호환성
•
프로젝트의 유지보수 이력과 앞으로 실제 적용할 수 있는 업데이트 경로
신뢰할 버전을 고를 때 확인하는 기준은 전이 의존성에도 똑같이 적용됩니다. 개발자가 직접 의존성 하나를 선택하더라도 실제 빌드에서는 그 아래에서 해석된 여러 버전을 함께 사용합니다. Lockfile과 일관된 의존성 해석 방식을 사용하면 실제로 선택된 버전 구성을 고정하고 파악하는 데 도움이 되지만, 선택된 컴포넌트를 평가하는 일을 대신하지는 못합니다.
실무에서는 아무런 대안 없이 경고만 보여주는 것보다 팀이 실제로 사용할 수 있는 버전을 안내하는 편이 낫습니다. 코딩 어시스턴트가 일상적인 개발 과정에서 의존성이나 업그레이드를 제안하는 일이 늘어날수록, 경고만 제시하지 않고 실제 사용할 수 있는 버전을 안내하는 일이 더 중요해집니다.
4. 리포지토리를 일관된 유입 경로로 만든다
중앙에서 관리하는 리포지토리가 없으면 개발 환경과 파이프라인마다 컴포넌트 점검, 버전 관리 기준 통일, 승인된 소스 보호를 따로 운영해야 해 관리가 파편화됩니다. 관리형 리포지토리를 사용하면 오픈소스 컴포넌트를 가져오는 안전한 단일 경로를 만들고, 유입되는 모든 아티팩트의 감사 기록을 남길 수 있습니다.
접근 경로를 중앙화하면 승인된 업스트림 소스를 일관되게 설정하고, 실제로 사용하는 컴포넌트를 추적하며, 로컬 개발과 자동화 빌드에 동일한 통제를 적용하기 쉬워집니다. 프로젝트마다 별도의 레지스트리 연결과 다운로드 규칙을 관리할 필요도 줄어듭니다.
리포지토리는 단순한 파일 저장소가 아니라 소프트웨어 전달 워크플로의 일부로 다뤄야 합니다. 어떤 프로젝트와 파이프라인이 리포지토리를 사용하는지, 직접 다운로드가 남아 있는 곳은 어디인지, 개발자가 지연 없이 승인된 패키지를 받을 수 있는지 파악해야 합니다. 신뢰할 수 있는 경로가 일상적인 개발에서 충분히 안정적으로 동작해야 팀도 실제로 그 경로를 사용합니다.
5. 승인 후에도 계속 살핀다
승인된 컴포넌트도 다운로드 이후 위험이 달라질 수 있으므로 지속적으로 모니터링해야 합니다. 연구자가 새로운 취약점을 공개할 수도 있고, 조사 과정에서 이전에 알려지지 않은 악성코드가 발견될 수도 있으며, 애플리케이션이 의존하는 버전의 프로젝트가 유지보수를 중단할 수도 있습니다. 따라서 안전한 오픈소스 사용은 최초 다운로드로 끝나지 않습니다.
팀은 애플리케이션에 들어 있는 컴포넌트와 버전을 전이 의존성까지 포함해 최신 상태로 파악해야 합니다. 새로운 위협 정보가 나오면 영향을 받는 프로젝트를 찾아내고, 실제 사용 중인 컴포넌트와 단순히 다운로드하거나 저장만 한 패키지를 구분할 수 있어야 합니다. 컴포넌트의 실제 사용 현황을 알아야 대응이 필요한 곳에 작업을 집중할 수 있습니다.
지속적인 의존성 분석은 다운로드 시점의 통제를 보완합니다. 초기 평가는 개발 환경에 들어오는 컴포넌트를 제한하고, 지속적인 모니터링은 컴포넌트를 받아들인 뒤 위험이 바뀌는 상황을 찾아냅니다. 컴포넌트의 위험 상태는 한 번 판단했다고 해서 그 결과가 영구히 유효한 것이 아닙니다.
6. 모든 발견 항목에 대응 절차를 마련한다
문제를 발견한 뒤 실제 조치로 이어지도록 명확한 대응 절차를 마련해야 합니다. 새로 확인된 위험마다 영향을 받는 애플리케이션과 책임자, 해야 할 조치를 연결해 두어야 합니다.
•
악성 패키지: 추가 사용을 중단하고 패키지가 실행됐는지, 자격 증명이 노출됐는지 조사합니다.
•
취약한 컴포넌트: 영향을 받는 애플리케이션을 식별하고 더 안전한 버전을 선택한 뒤 호환성을 시험합니다.
•
즉시 적용할 수정 방법이 없는 경우: 예외를 문서화하고 책임자를 지정한 뒤 다시 검토할 날짜를 정합니다.
우선순위는 심각도 점수만이 아니라 위협의 성격과 컴포넌트가 실제로 어떻게 사용되는지를 함께 반영해야 합니다. 변경 사항을 시험할 시간도 필요합니다. 중요한 애플리케이션을 망가뜨리는 업그레이드는 완전한 문제 해결 계획이 아닙니다.
팀이 영향을 받는 애플리케이션을 얼마나 빨리 찾아내고 적용 가능한 업그레이드를 얼마나 신속하게 완료하는지 추적하면 오픈소스 사용 프로세스가 제대로 작동하는지 판단할 수 있습니다. 우선순위 지정과 문제 해결은 이미 소프트웨어 안에서 발견된 위험을 다룹니다. 더 안전하게 운영하려면 보안 통제를 개발 초기 단계로 앞당겨야 합니다. 조직은 악성 항목이 리포지토리나 빌드에 들어오기 전에 차단할 수 있도록 악성코드 보호 체계를 갖춰야 합니다.
신뢰할 수 있는 선택을 가장 쉬운 선택으로 만든다
여섯 가지 원칙은 하나의 과정으로 이어집니다. 승인된 소스를 정하고 컴포넌트를 일찍 평가한 뒤 적합한 버전을 고릅니다. 관리형 리포지토리로 유입 경로를 통일하고, 이후에도 위험을 모니터링하며 명확한 조치 절차를 마련합니다.
이 과정을 일관되게 운영하면 보안을 강화하면서 더 빠른 소프트웨어 전달도 지원할 수 있습니다. 개발자는 모호한 경고를 해석하거나 잘못 선택한 의존성이 널리 퍼진 뒤 되돌리는 데 쓰는 시간을 줄일 수 있습니다. 엔지니어링 리더는 팀이 어떤 컴포넌트를 사용하는지 더 명확히 파악하고, 위험 상태가 달라졌을 때 일관된 방식으로 대응할 수 있습니다.
먼저 조직 안에서 의존성이 실제로 어떤 경로를 거쳐 들어오는지 점검해 보세요. 관리되지 않는 직접 다운로드를 찾아내고 안전한 리포지토리를 신뢰할 수 있는 기본 경로로 만들면 나머지 원칙을 적용할 기반이 생깁니다. 중앙화된 아티팩트 관리가 안전한 오픈소스 유입 체계를 어떻게 지원하는지 Sonatype Nexus Repository에서 확인할 수 있습니다.
에스코어는 Sonatype 공식 파트너로서 소프트웨어 공급망 보안 및 오픈소스 거버넌스 구축을 지원합니다.
도입이나 구축이 필요하시면 언제든 문의해 주세요.
지원 솔루션: Nexus Repository · Repository Firewall · Lifecycle · Sonatype Guide