AI 시대 오픈소스 보안, 사후관리에서 실시간 예방으로

 

AI 시대 오픈소스 보안, 사후 관리에서 실시간 예방으로

 

안녕하세요,

그로메트릭 입니다. 🐸

 

오픈소스 컴포넌트를 활용해 빠르게 개발하고 배포하는 것은 이제 당연한 일이 되었지만, 그만큼 보안팀이 감당해야 할 취약점의 양도 폭발적으로 늘고 있습니다. 많은 기업이 '가장 위험한 취약점부터 먼저 처리한다'는 우선순위 지정(Vulnerability Prioritization) 전략으로 이 문제에 대응해왔지만, 최근 발생한 일련의 오픈소스 공급망 공격 사례는 이 방식만으로는 더 이상 충분하지 않다는 사실을 보여주고 있습니다. 

 

특히 npm 생태계에서 발생한 Mastra AI 프레임워크 침해 사고는, 악성 코드가 설치 시점에 곧바로 실행될 수 있다는 점에서 '이미 들어온 위협을 정리하는 것'보다 '애초에 위험한 컴포넌트가 들어오지 못하게 막는 것'이 훨씬 중요하다는 교훈을 남겼습니다. 실제로 소나타입의 2026 소프트웨어 공급망 리포트에 따르면, 이미 수정본이 나와 있는 취약 컴포넌트 버전 단 4개가 2025년 한 해에만 약 18억 건에 달하는, 충분히 피할 수 있었던 악성 다운로드를 만들어냈습니다.

이번 아티클에서는 취약점 우선순위 지정만으로 AI 시대의 보안 리스크를 감당할 수 없는 이유와, AI 코딩 어시스턴트가 존재하지도 않는 패키지 버전을 추천하거나 오히려 보안성이 낮은 업그레이드를 제안한다는 실제 연구 결과, 그리고 소프트웨어 공급망을 근본적으로 안전하게 만들기 위한 구체적인 전략을 함께 소개합니다.

 

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

---

오픈소스 취약점 관리, 우선순위 지정만으로 충분할까

현대 소프트웨어 개발은 서드파티 오픈소스 컴포넌트에 크게 의존하고 있으며, 그 활용 규모는 이제 상상을 초월하는 수준입니다. 이 덕분에 개발팀은 오픈소스 기여자들의 성과 위에서 배포와 출시에만 집중할 수 있게 되었고, 전 세계적으로 실질적인 혁신이 이루어졌습니다. 하지만 그만큼 애플리케이션 보안(AppSec) 팀은 끊임없이 밀려드는 위협에 시달리고 있으며, 아무리 경험 많은 조직이라도 이를 효과적으로 관리하기 쉽지 않습니다. 할 일 목록과 백로그가 계속 쌓이는 상황에서, 효율적인 팀들은 시간이 검증된 방법인 '우선순위 지정'을 택해 가장 중요한 작업부터 처리해왔습니다.

 

최근의 소프트웨어 공급망 공격 사례들은 우선순위 지정이 여전히 중요하다는 사실과 동시에, 그것만으로는 더 이상 충분하지 않다는 사실을 함께 보여주고 있습니다. 2026년 6월, 공격자들은 Mastra AI 프레임워크의 npm 배포 워크플로우 일부를 침해하고, 악성 패키지인 easy-day-js를 영향을 받은 패키지들의 의존성으로 추가했습니다. 이 위협이 설치 과정에서 곧바로 실행될 수 있었다는 점은 중요한 시사점을 남깁니다. 팀은 이제 위험한 컴포넌트를 사후에 우선순위로 정리하는 것이 아니라, 애초에 빌드에 들어오지 못하도록 막아야 한다는 것입니다.

 

물론 취약점 패치 우선순위 지정은 여전히 중요하지만, 그것만으로 리스크와 기술 부채를 관리하기에는 부족합니다. 팀은 여전히 어떤 이슈가 실제로 악용 가능하고(exploitable), 도달 가능하며(reachable), 수정 가능하고(fixable), 비즈니스와 가장 밀접한 관련이 있는지 파악해야 합니다. 하지만 우선순위 지정은 보통 위험한 컴포넌트가 이미 환경 안에 들어온 뒤에야 시작됩니다. 그 시점이 되면 개발자는 기존 업무에서 벗어나 다시 불려오고, 보안팀은 해당 컴포넌트가 어디까지 퍼졌는지 추적해야 하며, 조직은 애초에 막을 수 있었던 노출을 관리하게 됩니다.

 

목표는 우선순위 지정을 대체하는 것이 아니라, 무엇이 소프트웨어 공급망에 들어올 수 있는지를 통제하는 장치와 이를 결합하는 것입니다.

 

알고 있다면, 이제는 실행할 때

오늘날의 소프트웨어 환경은 믿기 힘들 정도로 빠르게 움직이고 있으며, 취약점은 필연적으로 발생할 수밖에 없습니다. 소나타입의 '2024 제10회 연간 소프트웨어 공급망 현황' 리포트에 따르면, 취약한 컴포넌트 다운로드 건 중 약 95%는 이미 수정본이 존재했고, 업스트림에서 해결할 방법이 전혀 없는 진짜 예외 케이스는 약 0.5%에 불과했습니다. '2026 소프트웨어 공급망 현황' 리포트는 이 패턴을 더 확장해서 보여주는데, 이미 수정본이 배포된 취약 컴포넌트 버전 4개가 2025년 한 해 동안 약 18억 건에 달하는, 충분히 피할 수 있었던 취약 다운로드를 만들어냈다는 사실을 확인했습니다.

 

npm, PyPI, Maven Central, NuGet, Hugging Face 등 여러 생태계에서 악성 오픈소스 활동의 양은 계속 증가하고 있습니다.

하지만 모든 패키지나 취약점이 동일한 수준의 위험을 가지는 것은 아닙니다. 더 스마트한 접근법은 각 조직이 정의한 비즈니스 영향을 기준으로, 정책을 통해 대규모로 취약점 우선순위를 정하는 리스크 기반 프레임워크를 채택하는 것입니다. 이를 위해서는 시의적절하고 신뢰할 수 있는 인텔리전스가 필요합니다. 만약 근간이 되는 취약점, 악성코드, 컴포넌트 데이터가 누락되었거나 늦었거나 잘못되었다면, 전체 대응 프로세스는 처음부터 잘못된 전제 위에서 시작하는 셈입니다.

 

개발자의 소비 습관부터 바꿔야 한다

한 번 고정된 버전은 몇 년 동안 여러 서비스에 그대로 복사되어 사용됩니다. 전이 의존성(transitive dependency)은 세 단계쯤 아래 어딘가에 자리 잡고 있으며, 아무도 그것에 책임감을 느끼지 않습니다. 스캐너는 긴 이슈 목록을 뽑아내지만, 개발자를 호환 가능한 가장 안전한 업그레이드로 안내해주지는 않습니다. 팀은 "아직 문제가 터지지 않았다"는 이유로 업데이트를 미룹니다. 그리고 동일한 결정이 수백 개의 애플리케이션에서 반복됩니다.

팀이 충분한 가시성, 가이드, 안전장치 없이 오픈소스 컴포넌트를 소비하고 재사용하면, 같은 위험한 선택이 제품, 서비스, 파이프라인, 환경 전반에 걸쳐 그대로 퍼져나갈 수 있습니다. 그 이슈가 대응 백로그에 등장할 때쯤이면, 보안팀은 단순히 개발자에게 취약점 하나를 고쳐 달라고 요청하는 것이 아니라, 이미 대규모로 확산된 소비 패턴 자체를 되돌려 달라고 요청하는 셈이 됩니다.

개발자들이 보안을 소홀히 하는 것은 관심이 없어서가 아닙니다. 그들은 보안 이슈를 기능 개발, 고객과의 약속, 안정성 문제, 출시 마감, 기술 부채와 함께 저울질하고 있습니다. 애플리케이션 보안 경고는 훨씬 더 큰 업무 흐름 속의 하나의 입력값일 뿐이며, 무엇을 고칠 수 있고 무엇을 출시해야 하는지 사이에는 언제나 긴장이 존재합니다.

그렇기 때문에 우선순위 지정은 여전히 중요합니다. 팀은 어떤 이슈가 실질적으로 가장 큰 위험을 가지는지 알아야, 개발자가 정말 중요한 작업에 집중할 수 있습니다. 하지만 우선순위 지정만으로는 근본적인 행동을 바꾸지 못합니다. 대규모로 리스크를 줄이려면, 조직은 취약한 버전이 선택되고, 복사되고, 승인되고, 소프트웨어 공급망 전반에 반복되기 이전 단계부터 개발자가 더 안전한 선택을 하도록 도와야 합니다.

 

AI는 느슨한 프로세스를 더 빠르게 무너뜨린다

개발자들이 이미 오래된 소프트웨어 의존성 패턴을 그대로 복사해왔다면, AI는 그것을 더 빠르게 복사할 것입니다. 공개된 데이터가 오래되었다면, AI는 그 오래된 데이터를 근거로 더 빠르게 추론할 것입니다. 학습 데이터에 안전하지 않은 버전이 안전한 버전보다 더 많이 등장한다면, AI는 안전한 선택 대신 익숙한 선택을 자신 있게 추천할 수 있습니다.

 

올해 초 소나타입은 실제 의존성 업그레이드 추천 36,870건을 분석했는데, 이 중 27.76%가 존재하지 않는 버전을 참조하고 있었으며, 여기에는 1만 건이 넘는 '환각(hallucinated)' 패키지 릴리스가 포함되어 있었습니다. 반면 실시간 패키지 레지스트리, 취약점 인텔리전스, 악성코드 데이터, 호환성 파괴 변경(breaking-change) 분석에 근거해 추천을 생성하도록 하자, 동일한 컴포넌트 집합에서 이 환각 비율은 0%로 떨어졌습니다.

 

보안 측면의 영향도 중요합니다. 같은 연구에서 LLM이 생성한 업그레이드 전략은 분석된 전략들 중 보안 개선 효과가 가장 낮았고, 345개 컴포넌트는 모델이 추천한 최신 버전이 오히려 기존보다 더 많은 오픈소스 취약점을 발생시키면서 보안성이 더 낮아졌습니다. 해당 모델은 심지어 프로테스트웨어(protestware)와 대규모 공급망 공격에 연루된 패키지까지 추천했습니다.

 

바로 이것이 우리가 대비해야 할 미래입니다. 문제는 실수를 저지르는 개별 개발자가 아니라, 실시간 인텔리전스 없이도 그럴듯한 결정을 내리는 자동화된 시스템입니다.

 

취약점 우선순위를 넘어서

AI 네이티브 소프트웨어 개발 생명주기(PDLC, Product Development Lifecycle)가 조직 전반으로 확산됨에 따라, 보안 프로그램은 취약점 우선순위 대응을 넘어 '통제된 소비'와 '지속적인 현대화'까지 아우르는 방향으로 나아가야 합니다.

즉, 보안팀은 여전히 무엇이 가장 중요한지 결정해야 하지만, 티켓 큐(queue)를 유일한 통제 지점으로 취급하는 것을 멈춰야 합니다. 가장 좋은 취약점은 애초에 빌드에 들어오지 않는 취약점입니다. 그 다음으로 좋은 것은, 문제가 긴급 상황으로 번지기 전에 안전하고 호환 가능한 경로를 통해 자동으로 패치되는 취약점입니다.

• 진입 단계부터 통제하기: 알려진 악성 패키지, 알려진 취약 버전, 더 이상 지원되지 않는 컴포넌트, 승인되지 않은 소스는 아티팩트 레포지토리와 파이프라인 단계에서 차단되거나 엄격하게 통제되어야 합니다. 개발자가 모든 잘못된 선택을 일일이 직접 발견하게 해서는 안 됩니다.
• 안전한 경로를 가장 쉬운 경로로 만들기: 개발자에게 정책을 준수하는 안전한 오픈소스 컴포넌트 버전, 컨테이너, 기타 소프트웨어 공급망 입력값을 제공하고, 호환성을 고려한 업그레이드 추천과 함께 대응 작업을 대신 처리해주는 신뢰할 수 있는 자동 풀 리퀘스트(Pull Request)를 제공해야 합니다. 다음 단계는 단순한 의존성 업데이트를 넘어, 업그레이드에 필요한 1st-party 코드, 설정, 빌드 로직 관련 변경까지 자동화하는 것입니다. 소나타입은 이를 '골든 풀 리퀘스트(Golden Pull Request)'라고 부르는데, 이는 정책을 준수하는 업그레이드 경로를 기반으로 알려진 위반 사항을 해결하면서도 빌드가 깨지지 않도록 하는 풀 리퀘스트를 의미합니다. 보안팀은 이제 "그건 쓰지 마세요"라고만 말할 것이 아니라, "대신 이걸 쓰세요"라고 말할 수 있어야 합니다.
• 피할 수 있었던 노출을 측정하기: 더 나은 지표는 "백로그에 CVE가 몇 개나 있는가?"가 아니라 "더 안전한 버전이 존재하는데도 우리 빌드가 여전히 취약한 버전을 사용하고 있는 빈도는 얼마나 되는가?"입니다. 이는 논의의 초점을 경고 건수에서 실제 행동 변화로 옮겨줍니다.
• '수명 종료(End of Life)' 컴포넌트는 현대화 과제로 다루기: 더 이상 지원되지 않는 컴포넌트를 일반적인 패치 업데이트와 같은 큐에 두어서는 안 됩니다. 이런 컴포넌트에는 담당자, 마이그레이션 계획, 비즈니스 차원의 가시성, 명확한 일정이 필요합니다. 어떤 것은 대규모 업그레이드가 필요하고, 어떤 것은 교체가 필요하며, 어떤 것은 완전히 폐기해야 합니다. 이를 평범한 취약점 대응 티켓처럼 취급하는 것은 실제로 필요한 작업을 가려버릴 뿐입니다.

 

효과적인 취약점 대응을 위한 도구와 전략

탄탄한 취약점 우선순위 프레임워크를 갖추려면 스프레드시트, 대시보드, 수작업 분류만으로는 부족합니다. 현대적인 개발 환경에는 알려진 위험이 소프트웨어 공급망에 진입하는 것을 막고, 개발자가 더 안전한 선택을 하도록 안내하는 통합된 통제 장치가 필요합니다.

이는 소비 시점부터 시작되어야 합니다. Sonatype Firewall은 악성 패키지, 취약한 컴포넌트, 기타 리스크를 다운로드 시점에 차단함으로써, 컴포넌트가 개발자 환경, 레포지토리, CI/CD 파이프라인에 도달하기 전에 정책을 강제하도록 도와줍니다. 이를 통해 애초에 대응 작업으로 이어질 이슈의 수 자체를 줄일 수 있습니다.

하지만 팀에는 실제로 조치가 필요할 때 신뢰할 수 있는 가이드도 필요합니다. Sonatype Guide는 실시간 취약점, 버전, 라이선스, 컴포넌트 인텔리전스를 활용해 개발자와 AI 코딩 어시스턴트가 더 건강한 오픈소스를 선택하도록 돕습니다. 개발자에게 긴 이슈 목록을 그냥 넘겨주는 대신, 이미 익숙한 워크플로우에 자연스럽게 녹아드는 명확하고 정책에 부합하는 추천을 제공하는 것이 목표입니다.

이 두 가지 역량이 함께 작동하면, 취약점 대응은 소프트웨어가 선택되고 빌드되고 유지되는 지점에 훨씬 더 가까워집니다. 보안팀은 여전히 가장 중요한 이슈의 우선순위를 정해야 하지만, 동시에 예방 가능한 위험을 조기에 차단하고, 안전한 대안을 추천하며, 대응 작업을 별도의 백로그 정리 업무가 아니라 개발자 워크플로우의 일부로 만들어주는 도구도 함께 갖춰야 합니다.

 

백로그 정리만으로는 미래를 대비할 수 없다

본질적으로 취약점 우선순위 지정은 혼돈 속에서 질서를 만들려는 시도입니다. 팀이 집중할 수 있도록 돕고, 경고 피로도를 줄여주며, 보안팀과 엔지니어링 팀이 더 실질적인 대화를 나눌 수 있게 해줍니다. 하지만 새로운 데이터는 오늘날의 리스크 환경이 약한 신호들, 안전하지 않은 기본 소비 패턴, 방치된 소프트웨어, 그리고 실수를 기계적인 속도로 증폭시킬 수 있는 자동화로 이루어져 있음을 보여줍니다.

 

이제 우리는 소비 시점에서 소프트웨어 공급망을 통제해야 합니다. 안전한 컴포넌트를 안전하지 않은 컴포넌트보다 더 쓰기 쉽게 만들어야 합니다. 더 이상 패치할 수 없는 소프트웨어의 사용을 멈추고 빌드를 현대화해야 합니다. 그리고 고정된 기억과 자신감 넘치는 추측이 아니라, 실시간의 신뢰할 수 있는 인텔리전스에 기반한 AI 에이전트가 필요합니다.

 

이것이 바로 소나타입이 조직들을 돕고자 하는 방향입니다. 계속 늘어나는 취약점 목록을 팀이 일일이 분류하게 하는 대신, 소나타입 넥서스 원(Nexus One) 플랫폼은 위험한 컴포넌트가 개발 단계에 진입하는 것을 막고, 새롭게 등장하는 위협을 지속적으로 모니터링하며, 방치되고 더 이상 관리되지 않는 의존성을 식별하고, 취약점을 자동으로 해결하며, AI 시스템에 신뢰할 수 있는 소프트웨어 인텔리전스를 제공하도록 돕습니다. 보안에 대한 의사결정을 소프트웨어가 선택되고 빌드되고 소비되는 지점에 더 가깝게 배치함으로써, 조직은 혁신 속도를 늦추지 않으면서도 리스크를 줄일 수 있습니다.

 

소프트웨어 공급망 보안의 미래는 백로그를 더 잘 관리하는 방법을 찾는 것으로 승리할 수 없습니다. 설계 단계부터 탄력적인 소프트웨어 공급망을 구축하는 데 달려 있습니다 .

 

---

출처

소나타입 블로그 : Focusing on Vulnerability Prioritization Is Missing the AI-Era Point