공지사항

의존성관리 10

CVE 대응만으론 부족하다: AI 시대 오픈소스 의존성 관리

안녕하세요,그로메트릭 입니다. 🐸 소프트웨어 취약점(CVE)이 공개될 때마다 보안·개발팀은 같은 순서로 움직입니다. 영향받는 컴포넌트를 쓰고 있는지 확인하고, 취약한 코드에 도달하는지 따지고, 수정 버전을 찾아 테스트한 뒤 프로덕션에 반영합니다. 그리고 곧 다음 권고문이 도착합니다. 문제는 CVE를 하나씩 쫓는 방식이 의존성이 이미 소프트웨어 안에 들어온 뒤에야 위험에 대응하게 만들 수 있다는 점입니다. 소나타입이 분석한 오픈소스 CVE 1,552건 중 64%에는 CVSS 점수가 없었고, 출처 간 심각도 분류가 일치한 비율은 19%에 그쳤으며, 점수 부여까지는 평균 6주가 걸렸습니다. AI가 컴포넌트를 찾고 도입하는 속도를 높이면서, AI 코딩 어시스턴트가 제안한 라이브러리가 검증되기 전에 프로젝트에 ..

[Npm 공급망 공격] 탈취된 패키지 12개 릴리스, PolinRider 로더 재등장

안녕하세요,그로메트릭 입니다. 🐸 탈취된 npm 패키지에서 PolinRider 로더가 다시 발견되었습니다. 소나타입 리서치 랩스는 2026년 11월 4일, 탈취된 npm 패키지 10개의 릴리스 12건에서 숨겨진 런타임 로더를 확인했습니다. 영향받은 패키지는 Redux 연동, health API, 브라우저 활동 추적, 유틸리티 등 서로 무관한 기능을 제공합니다. 이 로더는 기존 PolinRider 활동에서 보고된 것과 동일한 하드코딩 이더리움 지갑이 보낸 트랜잭션을 조회해 페이로드 서버의 IP 주소를 알아낸 뒤, XOR로 인코딩된 JavaScript를 내려받아 실행하도록 설계되어 있습니다. 패키지 매니페스트에는 install·postinstall 훅이 없어, install 스크립트를 비활성화하는 것만으..

Maven Central 신뢰 구조: 의존성 전달 경로에서 레지스트리가 보장하는 것

안녕하세요,그로메트릭 입니다. 🐸 Maven Central에서 Java 의존성을 가져오는 개발팀이라면, 빌드가 성공하는 이면의 구조를 한 번쯤 짚어볼 필요가 있습니다. 개발팀이 의존성을 추가할 때 신뢰하는 대상은 파일 하나가 아닙니다.좌표와 일치하는 컴포넌트, 올바른 버전 해석을 돕는 메타데이터, 빌드 시점에 항상 가능한 다운로드까지 함께 신뢰하게 됩니다.이 과정은 대부분 자동으로 수행되기 때문에, 신뢰가 전제되어 있다는 사실은 평소에 잘 드러나지 않습니다. 소나타입의 OSPO Global Director인 Paul Horton은 퍼블리싱, 메타데이터, 가용성, 문제 대응, 장기 보존이라는 운영 요소가 이 신뢰를 만든다고 설명합니다. 의존성의 출처와 위험을 설명해야 하는 조직에게는 공급망 보안 관점에서..

AI 코딩 시대의 개발 생산성, 릴리즈 뒤 의존성 정리 작업의 효율성

안녕하세요,그로메트릭 입니다. 🐸 AI 덕분에 아이디어에서 풀 리퀘스트(PR)까지 걸리는 시간은 분 단위로 줄었습니다. 그런데 소프트웨어를 배포하는 일까지 쉬워졌다고 할 수 있을까요? 코드는 빨리 도착했지만, 실패한 빌드와 의존성 충돌, 뒤늦게 발견된 이슈, 가치 없는 업그레이드 때문에 릴리스는 늦어질 수 있습니다. 코드 생성량은 도구가 만들어 낸 활동량일 뿐, 사용자에게 전달된 프로덕션 수준의 소프트웨어가 얼마나 되는지, 그 과정에서 계획에 없던 작업이 얼마나 생겼는지는 보여주지 않습니다. 의존성 문제가 빌드나 릴리스까지 번지면 구성요소의 사용 위치 파악, 교체, 자격 증명 노출 가능성 평가로 작업이 이어집니다. 결국 핵심은 AI가 만든 속도 이점이 PR에서 프로덕션까지 얼마나 살아남느냐입니다. 소나..

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

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

Partners/Sonatype 2026.10.08

AI 코딩 에이전트가 바꾸는 SDLC: 오픈소스 의존성 거버넌스 전략

안녕하세요,그로메트릭 입니다. 🐸 AI 코딩 어시스턴트와 에이전트가 며칠 걸리던 구현 작업을 몇 시간으로 줄여주고 있습니다. 하지만 코드를 '쓰는' 시간이 줄었다고 해서 소프트웨어를 '출시하는' 속도까지 빨라지는 것은 아닙니다. 생성된 코드는 여전히 계획, 리뷰, 테스트, 보안 검증, 배포, 유지보수 단계를 거쳐야 하기 때문입니다. 생성된 코드의 양이 곧 생산성을 의미하지 않는 이유입니다.오히려 병목은 구현에서 검증으로 이동하고 있습니다. 리뷰와 승인이 변경 1건마다 같은 수작업을 요구한다면 풀 리퀘스트는 쌓이고, AI로 얻은 생산성은 다운스트림에서 사라집니다. 특히 AI는 프롬프트 한 번으로 웹 프레임워크, 데이터베이스 클라이언트, 로깅 유틸리티 등 수십 개의 컴포넌트와 그에 딸린 전이(transit..

CI/CD 자격증명 탈취: 악성 오픈소스 패키지가 설치 시점에 노리는 권한

안녕하세요,그로메트릭 입니다. 🐸 오픈소스 패키지를 설치하는 개발팀과 CI/CD 파이프라인을 운영하는 조직이라면 눈여겨봐야 할 분석입니다.소나타입(Sonatype)이 공식 블로그에서 악성 오픈소스 패키지가 왜 유독 CI/CD 자격증명을 노리는지 짚었습니다.자격증명 하나만 손에 넣어도 소스 코드, 빌드 시스템, 패키지 레지스트리, 클라우드 인프라, 운영 배포 환경까지 닿을 수 있기 때문입니다. 2025년 소나타입이 분석한 악성 패키지 가운데 53%는 설치 단계에서 개발 환경을 노리도록 만들어져 있었습니다.의존성 하나를 설치했을 뿐인데 악성 릴리스 배포와 빌드 오염으로 번질 수 있다는 점에서, 공급망 보안 관점의 실질적인 비즈니스 리스크로 이어질 수 있는 사안입니다. *아래 글은 소나타입(Sonatype)..

AI 토큰 비용 최적화, 초기 의존성 결정이 좌우한다

안녕하세요,그로메트릭 입니다. 🐸 AI 코딩 어시스턴트를 실제 업무에 붙여 쓰고 있는 개발팀이라면, 토큰 비용이 예상보다 빠르게 늘어나는 경험을 한 번쯤 해봤을 것입니다.AI 코딩 어시스턴트는 작업을 해석하고, 코드베이스를 검사하고, 의존성을 선택하고, 코드를 수정하고, 테스트를 실행하고, PR을 준비하는 일까지 수행합니다. 이 과정에서 모델과의 상호작용, 코드 검색, 툴 호출, 재시도, 검증 단계 하나하나가 리소스를 소모합니다. 에이전틱 워크플로우는 한 번의 프롬프트와 응답으로 끝나지 않습니다. 컨텍스트를 쌓고, 툴을 호출하고, 실패를 복구하고, 처음부터 제대로 됐다면 필요 없었을 작업을 반복합니다.문제는 에이전트가 결정을 잘못 내렸을 때 비용이 빠르게 불어난다는 점입니다. 존재하지 않는 의존성 버전..

Flooding Dropper 캠페인 npm 악성 패키지 846개 확산

안녕하세요,그로메트릭 입니다. 🐸 npm 패키지 매니저를 사용하는 개발팀이라면 절대 가볍게 넘겨서는 안 될 소식입니다. 소나타입(Sonatype) 리서치랩이 'Flooding Dropper'라는 이름의 대규모 악성 패키지 캠페인을 포착했습니다. 지금까지 확인된 것만 846개에 달하는 npm 패키지가 이 캠페인에 연루돼 있으며, 조사가 진행될수록 그 규모는 계속 늘어나고 있습니다.이번 공격의 특징은 '자동화'입니다. 공격자는 하나의 계정에서 다량의 악성 패키지를 배포하는 대신, 수많은 npm 계정을 자동으로 생성해 소량의 패키지씩 분산 배포하는 전략을 택했습니다. bigops, bnpl 같은 특정 키워드를 조합한 패키지명과 35.x.y 버전대라는 공통점 외에는 단서가 많지 않아, 탐지와 차단이 유독 까다..

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

안녕하세요,그로메트릭 입니다. 🐸 오픈소스 컴포넌트를 활용해 빠르게 개발하고 배포하는 것은 이제 당연한 일이 되었지만, 그만큼 보안팀이 감당해야 할 취약점의 양도 폭발적으로 늘고 있습니다. 많은 기업이 '가장 위험한 취약점부터 먼저 처리한다'는 우선순위 지정(Vulnerability Prioritization) 전략으로 이 문제에 대응해왔지만, 최근 발생한 일련의 오픈소스 공급망 공격 사례는 이 방식만으로는 더 이상 충분하지 않다는 사실을 보여주고 있습니다. 특히 npm 생태계에서 발생한 Mastra AI 프레임워크 침해 사고는, 악성 코드가 설치 시점에 곧바로 실행될 수 있다는 점에서 '이미 들어온 위협을 정리하는 것'보다 '애초에 위험한 컴포넌트가 들어오지 못하게 막는 것'이 훨씬 중요하다는 교훈..

Partners/Sonatype 2026.07.08