오픈소스 공급망 보안, 안전한 오픈소스 사용을 위한 6가지 규칙

 

오픈소스 공급망 보안, 안전한 오픈소스 사용을 위한 6가지 규칙

 

안녕하세요,

그로메트릭 입니다. 🐸

 

애플리케이션 하나가 평균 약 180개의 의존성(dependency)을 품고 있는 시대입니다. 개발자가 라이브러리 하나를 추가하는 순간, 패키지 매니저는 수십 개의 전이적 의존성(transitive dependency)까지 함께 가져옵니다. 그중 하나라도 악성 패키지라면 빌드가 시작되기도 전, 설치 단계에서 코드가 실행될 수 있습니다. 도입 이후 새로운 취약점이 공개되면 영향을 받는 애플리케이션을 모두 찾아내고, 적용 가능한 업데이트를 마련해야 합니다. 소나타입 리서치팀이 2026년 2분기 말까지 지난 10년간 기록한 악성 패키지는 180만 개를 넘습니다. 익숙한 레지스트리를 쓴다고 안전이 보장되지는 않는다는 뜻입니다.

게다가 이제는 AI 코딩 어시스턴트까지 의존성과 업그레이드를 제안하고 있습니다. 승인된 레지스트리를 정해 두거나 릴리스 직전에 한 번 스캔하는 것만으로는 부족한 이유입니다. 이번 글에서는 소나타입이 제시하는 안전한 오픈소스 사용(Secure Open Source Consumption)의 6가지 규칙을 살펴봅니다. 승인된 소스 지정, 다운로드 전 컴포넌트 평가, 신뢰할 수 있는 버전 선택, 관리형 리포지토리 일원화, 승인 이후 지속 모니터링, 모든 발견 사항에 대한 조치 경로 마련까지, 컴포넌트 선택부터 조치까지 전 과정을 아우르는 원칙입니다. 신뢰할 수 있는 선택을 '가장 쉬운 선택'으로 만드는 방법을 지금 확인해 보세요.

 

*아래 글은 소나타입(Sonatype)의 공식 블로그 글을 번역하여 작성되었습니다.

---

오픈소스를 안전하게 사용하기 위한 새로운 규칙?!

안전한 오픈소스 사용은 승인된 패키지 레지스트리를 지정하거나 릴리스 전에 스캔 한 번 돌리는 것만으로 끝나지 않습니다. 팀은 컴포넌트가 어디서 오는지 통제하고, 선택하는 시점에 평가하고, 적절한 버전을 고르고, 새로운 위험이 등장할 때마다 이를 계속 추적해야 합니다.

 

소나타입 리서치에 따르면 애플리케이션 하나에는 평균 약 180개의 의존성이 포함되어 있습니다. 이 정도 규모라면, 안전한 사용을 위해서는 개발자의 의존성 결정 하나하나를 뒷받침하는 일관된 통제가 필요합니다.

목표는 개발자와 AI 지원 워크플로우가 신뢰할 수 있는 의존성을 '쉽게' 선택하도록 만들고, 그 선택을 바꿔야 할 때 팀이 현실적으로 대응할 수 있는 방법을 마련하는 것입니다.

 

새 기능을 위해 라이브러리 하나를 추가하는 개발자를 떠올려 보세요. 이 단 하나의 선택이 여러 시점에서 위험을 불러올 수 있습니다.

• 선택 시점: 패키지 매니저가 해당 라이브러리와 함께 수십 개의 전이적 의존성을 가져올 수 있습니다.
• 설치 시점: 애플리케이션이 빌드되기도 전에 악성 패키지가 실행될 기회를 얻을 수 있습니다.
• 도입 이후: 새로운 취약점이 공개되면, 팀은 영향을 받는 애플리케이션을 모두 찾아내고 적용 가능한 업데이트를 확보해야 합니다.

그래서 안전한 사용을 위한 규칙은 선택부터 조치(remediation)까지 전체 경로를 다뤄야 합니다.

 

1. 승인된 소스(Approved Sources) 정의하기 ✅

승인된 소스란 개발자, 빌드 시스템, AI 코딩 어시스턴트가 오픈소스 컴포넌트를 가져올 수 있는 곳을 정한 것입니다. 퍼블릭 레지스트리는 유용한 배포 채널이지만, 그곳에서 받을 수 있다고 해서 그 안의 모든 패키지를 조직이 승인했다는 의미는 아닙니다.

팀은 생태계(ecosystem)별로 승인된 업스트림 소스를 정의하고, 이에 접근하는 단일 경로를 마련해야 합니다. 어떤 곳은 관리형 리포지토리를 거치고 어떤 곳은 퍼블릭 레지스트리에서 직접 받는다면, 유입되는 코드에 대한 가시성과 통제가 들쭉날쭉해집니다.

 

승인된 경로는 의존성이 자동으로 해석(resolve)되는 경우가 많은 로컬 개발 환경과 CI/CD까지 확장되어야 합니다.

그렇다고 개발자를 짧은 사전 승인 라이브러리 목록에 묶어 두라는 뜻은 아닙니다. 필요한 패키지를 얻을 수 있는 신뢰할 만한 경로를 제공하고, 평소 소스 밖의 무언가가 필요할 때 따를 명확한 절차를 마련하라는 의미입니다.

 

소스 승인은 출발점일 뿐입니다. 정상적인 레지스트리에도 유해한 패키지가 게시될 수 있고, 정상 패키지가 나중에 침해될 수도 있습니다. 따라서 컴포넌트 자체에 대한 평가도 여전히 필요합니다.

 

2. 다운로드 전에 컴포넌트 평가하기 📋

컴포넌트는 요청되는 시점, 즉 개발 환경이나 빌드에 들어가기 전에 평가해야 합니다. 이는 특히 악성 패키지에 중요합니다. 일부 악성 패키지는 설치 과정에서 코드를 실행할 수 있기 때문에, 빌드 이후에 발견하면 초기 노출을 피하기에 이미 늦었을 수 있습니다.

 

2026년 2분기 말 기준, 소나타입 리서치는 지난 10년간 여러 생태계에서 180만 개가 넘는 악성 패키지를 기록했습니다. 이 규모는 익숙한 레지스트리와 워크플로우를 통해 들어오는 패키지라 하더라도, 팀이 사용하는 것을 반드시 평가해야 한다는 점을 보여 줍니다.

평가는 서로 다른 대응이 필요한 위험을 구분해야 합니다.

• 악성 또는 의심 패키지: 설치 전에 차단하거나 격리(quarantine)해야 할 수 있습니다.
• 알려진 취약점: 더 안전한 버전을 찾거나, 해당 컴포넌트가 어떻게 사용될지 평가해야 할 수 있습니다.
• 라이선스 충돌: 대체 컴포넌트를 찾거나 조직 정책에 따른 검토가 필요할 수 있습니다.

이러한 결정은 조직의 위험 임계값(risk threshold)을 따라야 합니다. 요청이 차단되었을 때 개발자는 그 이유와 다음에 무엇을 할 수 있는지 알아야 합니다. 다른 버전을 고를지, 다른 컴포넌트를 선택할지, 예외를 요청할지 말이죠.

스캐닝은 개발 전 과정에서 여전히 가치가 있습니다. 하지만 다운로드 전에 컴포넌트를 평가하면, 설치되는 순간 코드를 실행할 수 있는 패키지에 대해 더 이른 결정 지점을 추가할 수 있습니다.

 

3. 신뢰할 수 있는 '패키지'가 아니라 신뢰할 수 있는 '버전' 선택하기 🔗

어떤 패키지를 신뢰할 수 있는지는 프로젝트가 사용할 구체적인 버전에 달려 있습니다. 버전마다 취약점, 동작, 유지보수 상태, 의존성, 애플리케이션과의 호환성이 다릅니다. 최신 릴리스가 자동으로 최선의 선택이 되는 것도 아니고, 다른 팀이 이미 쓰고 있는 버전이 이 프로젝트에 맞는다는 보장도 없습니다.

신뢰할 수 있는 버전을 결정할 때는 다음을 고려해야 합니다.

• 해당 버전이 예상한 소스에서 게시되었는지, 그리고 악성 활동의 징후가 있는지
• 알려진 취약점과, 그 취약점에 대한 애플리케이션의 노출 정도
• 라이선스 요건과 조직 정책
• 애플리케이션 및 기존 의존성 트리(dependency tree)와의 호환성
• 프로젝트의 유지보수 이력과 향후 업데이트를 위한 현실적인 경로

이 질문들은 전이적 의존성에도 똑같이 적용됩니다. 개발자는 직접 의존성 하나를 선택하지만, 빌드는 그 아래에서 해석된 버전들을 사용합니다. 락파일(lockfile)과 일관된 의존성 해석은 팀이 그 결과를 유지하고 이해하는 데 도움이 되지만, 무엇이 선택되었는지에 대한 평가를 대신하지는 못합니다.

 

실질적인 결과물은 다음 단계가 없는 경고가 아니라, 팀이 실제로 사용할 수 있는 버전으로의 안내여야 합니다. 이는 코딩 어시스턴트가 일상적인 개발 과정에서 의존성이나 업그레이드를 제안하는 경우가 늘어날수록 더욱 중요해집니다.

 

4. 리포지토리를 일관된 단일 경로로 만들기 📥

중앙화된 관리형 리포지토리가 없다면 파이프라인과 개발 환경 전반에서 컴포넌트 검사를 시행하고, 버전 거버넌스를 표준화하고, 승인된 소스를 보호하는 일이 심하게 파편화됩니다. 관리형 리포지토리는 오픈소스 컴포넌트를 가져오는 안전한 단일 경로를 만들고, 유입되는 모든 아티팩트에 대한 감사 로그(audit log)를 남깁니다.

접근을 중앙화하면 팀은 승인된 업스트림 소스를 구성하고, 사용하는 컴포넌트를 추적하고, 로컬 개발과 자동화된 빌드 전반에 일관된 통제를 적용할 수 있습니다. 또한 프로젝트마다 레지스트리 연결과 다운로드 규칙을 따로 관리해야 하는 부담도 줄어듭니다.

 

리포지토리는 단순히 파일을 저장하는 곳이 아니라 딜리버리 워크플로우의 일부로 다뤄야 합니다. 팀은 어떤 프로젝트와 파이프라인이 리포지토리를 사용하는지, 어디서 여전히 직접 다운로드가 일어나는지, 개발자가 승인된 패키지를 지연 없이 받을 수 있는지 파악해야 합니다. 신뢰할 수 있는 경로는 팀이 매일 사용할 수 있을 만큼 신뢰할 수 있어야 합니다.

 

5. 승인 이후에도 계속 모니터링하기 🖥️

승인된 컴포넌트라도 다운로드 이후 위험이 달라질 수 있으므로 지속적인 모니터링이 필요합니다. 연구자가 새로운 취약점을 공개하거나, 조사 과정에서 이전에 알려지지 않은 악성코드가 밝혀지거나, 애플리케이션이 의존하는 버전의 유지보수가 중단될 수도 있습니다. 따라서 안전한 사용은 첫 다운로드 이후에도 계속됩니다.

 

팀은 전이적 의존성을 포함해 애플리케이션에 들어 있는 컴포넌트와 버전을 최신 상태로 파악하고 있어야 합니다. 새로운 인텔리전스가 들어오면 영향을 받는 프로젝트를 식별하고, 실제로 사용 중인 컴포넌트와 단순히 다운로드되거나 저장만 된 패키지를 구분할 수 있어야 합니다. 이런 맥락이 있어야 대응 작업을 정말 중요한 곳에 집중할 수 있습니다.

 

바로 이 지점에서 지속적인 의존성 분석이 다운로드 시점의 통제를 보완합니다. 초기 평가는 개발 환경에 들어오는 것을 제한하고, 지속적인 모니터링은 컴포넌트가 승인된 이후의 위험 변화를 잡아냅니다. 어느 쪽의 결정도 한 번 내렸다고 영원히 유효하다고 가정할 수는 없습니다.

 

6. 모든 발견 사항에 조치 경로(Remediation Path) 마련하기 🚥

모든 발견 사항에는 식별부터 조치까지 이어지는 명확한 경로가 필요합니다. 대응 프로세스는 새로 식별된 위험을 영향받는 애플리케이션, 그 애플리케이션의 담당자, 그리고 적절한 다음 단계와 연결해야 합니다.

• 악성 패키지인 경우: 추가 사용을 중단하고, 해당 패키지가 실행되었거나 자격증명(credential)을 노출했는지 조사합니다.
• 취약한 컴포넌트인 경우: 영향받는 애플리케이션을 식별하고, 더 안전한 버전을 선택하고, 변경 사항의 호환성을 테스트합니다.
• 즉각적인 수정이 불가능한 경우: 예외를 문서화하고, 담당자를 지정하고, 재검토 날짜를 정합니다.

우선순위는 심각도 점수에만 의존하기보다 위협의 성격과 컴포넌트가 사용되는 방식을 반영해야 합니다. 또한 팀에는 변경 사항을 테스트할 여유가 필요합니다. 핵심 애플리케이션을 망가뜨리는 업그레이드는 완전한 조치 계획이라고 할 수 없습니다.

영향받는 애플리케이션을 얼마나 빨리 식별하고, 실제로 적용 가능한 업그레이드를 얼마나 빨리 완료하는지 추적하면 사용 프로세스가 제대로 작동하는지 알 수 있습니다. 우선순위 지정과 조치가 이미 소프트웨어에서 발견된 위험을 다룬다면, 더 안전한 접근 방식은 보호를 왼쪽으로 옮기는 것(Shift Left)입니다. 조직은 악성 요소가 리포지토리나 빌드에 도달하기 전에 차단할 수 있도록 악성코드 방어(malware protection) 체계를 갖춰야 합니다.

 

신뢰할 수 있는 선택을 '가장 쉬운 선택'으로 😌

새로운 규칙들은 하나의 연속된 경로를 만듭니다. 승인된 소스를 선택하고, 컴포넌트를 일찍 평가하고, 적절한 버전을 고르고, 관리형 리포지토리를 사용하고, 지속적으로 위험을 모니터링하고, 명확한 조치 단계를 마련하는 것입니다.

이 경로는 더 강력한 보안뿐 아니라 더 빠른 딜리버리도 뒷받침합니다. 개발자는 애매한 경고를 해석하거나, 이미 퍼져 버린 잘못된 의존성을 되돌리는 데 쓰는 시간을 줄일 수 있습니다. 엔지니어링 리더는 팀이 무엇을 사용하고 있는지 더 명확하게 파악하고, 컴포넌트의 위험이 바뀔 때 더 믿을 만한 방식으로 대응할 수 있습니다.

 

먼저 조직 전반에서 의존성이 현재 어떤 경로로 들어오고 있는지 점검하는 것부터 시작해 보세요. 관리되지 않는 다운로드를 찾아내고 안전한 리포지토리를 믿을 수 있는 경로로 만들면, 나머지 규칙들이 작동할 기반이 마련됩니다. 중앙화된 아티팩트 관리가 어떻게 그 기반을 뒷받침하는지 Sonatype Nexus Repository에서 확인해 보세요.

---

출처

소나타입 블로그 : What Are the New Rules for Secure Open Source Consumption?