슬롭스쿼팅이란 무엇인가? AI 패키지의 허상이 어떻게 공급망 공격으로 이어지는가

주요 내용

• 슬롭스쿼팅이란, 공격자가 AI 도구가 생성한 패키지 이름을 등록해 두고 누군가가 이를 설치하기를 기다리는 행위를 말합니다.
• 이 방법이 효과가 있는 이유는 환각이 반복되기 때문이며, USENIX 연구에서 43%의 환각이 총 10회의 재현 실험 모두에서 다시 나타났기 때문이다.
• 승인된 카탈로그에 포함되지 않은 항목을 모두 거부하는 저장소는, 임의로 지어진 이름이 전혀 해결되지 못하게 합니다.
• 의존성을 스스로 설치하는 코딩 에이전트는 사람이 수행하는 마지막 검증 단계를 없애버립니다.

팀원 중 한 명이 AI 어시스턴트에서 가져온 파이썬 코드 조각을 붙여넣고, pip install 명령어를 실행했는데, 터미널 화면이 아무런 오류 메시지 없이 지나갑니다. 임포트도 정상적으로 작동합니다. ‘슬롭스쿼팅(slopsquatting)’이란, 공격자가 해당 패키지 이름을 선점하기 전까지 그 이름이 아무것도 가리키지 않았던 상황을 말합니다. 모델이 그 이름을 만들어냈고, 누군가가 먼저 등록했으며, 설치 과정이 그들에게 침투의 발판을 제공한 것입니다.

이 가이드에서는 ‘슬롭스쿼팅(slopsquatting)’이 무엇을 의미하는지, 공격 체인이 어떻게 진행되는지, 실제 연구 결과에 따르면 이러한 공격이 얼마나 자주 발생하는지, 그리고 실제 파이프라인에 도달하기 전에 어떤 방어 수단이 효과적인지에 대해 자세히 설명합니다.

슬롭스쿼팅이란 무엇인가요?

슬롭스쿼팅은 소프트웨어 공급망 공격 로, 공격자가 대규모 언어 모델이 환각을 일으키기 쉬운 패키지 이름을 등록한 뒤, 그 이름 아래에 악성 코드를 게시하는 방식입니다. 개발자는 AI 어시스턴트가 해당 패키지가 존재한다고 알려주었기 때문에 이를 설치하게 됩니다. 이것이 바로 ‘패키지 환각’입니다. 즉, 모델이 방금 안내해 준 레지스트리에는 존재하지 않는 종속성을 추천하는 현상입니다.

이 용어는 파이썬 소프트웨어 재단(Python Software Foundation)의 상주 보안 개발자인 세스 라슨(Seth Larson)이 처음 만들었으며, 오픈소스 데이터 플랫폼 Ecosyste.ms를 운영하는 앤드류 네스빗(Andrew Nesbitt)에 의해 더 널리 알려지게 되었습니다. 이 용어는 “AI 슬롭(AI slop)”을 타이포스쿼팅에 “AI 슬롭”을 결합한 것입니다. 

여기서 누구도 오타를 낸 것은 아닙니다. 설치 명령어는 정확했고, 이름은 모델이 기재한 대로 정확히 표기되었으며, 그 명령어를 신뢰한 근거는 추천한 레지스트리와 이름을 대조해 확인한 적이 없는 시스템에서 비롯된 것이었습니다.

슬롭스쿼팅 대 타이포스쿼팅

타이포스쿼팅은 인간의 실수를 악용합니다. reqeusts instead of requests로 오타가 나게 만듭니다. 또는 python3-dateutil는 2019년에 PyPI에 업로드되어 python-dateutil 을 모방하기 위해 PyPI에 업로드되었으나, SSH 및 GPG 키를 수집하는 또 다른 패키지를 함께 설치한다는 사실이 누군가에 의해 발견되자 며칠 뒤 삭제되었습니다. 슬롭스쿼팅은 시스템 오류를 악용하지만, 시스템 오류는 사실 훨씬 더 조직적으로 이루어지고 있는 것으로 드러났습니다.

	오타 스쿼팅	슬롭스쿼팅
설치를 유발하는 요인은 무엇인가요?	사람의 오타인가, 아니면 이름을 잘못 기억한 것인가	AI가 의도한 이름 목록에 없는 이름을 추천합니다.
한 연구에서 나타난 규모	소수의 고가치 표적 주변에 밀집해 있다	205,474개의 고유한 환각 이름이 관찰됨
예측 가능성	공격자는 자주 틀리는 철자를 추측한다	공격자는 모델에 프롬프트를 입력하여 이름을 수집한다
실명과 유사성	대개 실제와 비교하면 사소한 수정만 필요할 정도입니다	가장 가까운 실제 패키지와 편집 거리 1~2 이내인 파이썬 패키지의 13.4%; 편집 거리 6 이상인 패키지의 48.6%
누가 위험에 노출되어 있는가	잘못된 이름을 수정하는 개발자 및 자동화된 워크플로우	AI가 생성한 종속성 목록을 수용하는 모든 사람(에이전트 포함)

많은 허구적인 이름들은 실제 패키지와는 거리가 멉니다. 허구적인 파이썬 이름 중 가장 가까운 기존 이름과 1~2자 차이 이내인 경우는 13.4%에 불과한 반면, 6자 이상 차이가 나는 경우는 48.6%에 달했습니다. 이들은 아슬아슬하게 빗나간 사례가 아니라 그럴듯하게 들리는 지어낸 이름들이기 때문에, 편집 거리 및 이름 유사도 검사만으로는 이러한 이름들을 상당수 놓치게 됩니다.

이름들도 반복해서 등장한다. USENIX 연구진은 는 환각 현상을 일으킨 프롬프트 500개를 선정하여 각각을 10회씩 재실행했습니다. 환각으로 생성된 이름 중 43%는 10회 실행 모두에서 나타났으며, 58%는 한 번 이상 나타났습니다. 공격자는 추측할 필요가 없습니다. 이러한 반복성은 공격자가 모델이 신뢰할 수 있게 만들어낸 결과를 측정하기보다는 인간이 어떻게 오타를 내는지 예측하는 기존의 타이포스쿼팅과 근본적으로 구별되는 점입니다.

슬롭스쿼팅 공격의 작동 원리

총 네 단계로 이루어져 있으며, 기술적으로 까다로운 과정은 하나도 없습니다. 이것이 바로 AI가 생성한 패키지가 그토록 효율적인 전달 수단이 되는 이유 중 하나입니다. 성공적인 시도는 다음 항목에 해당합니다. MITRE ATT&CK T1195.001, ‘소프트웨어 종속성 및 개발 도구 침해’에 해당하므로, 이 공격은 생소한 개념으로 따로 분류되기보다는 이미 보유하고 있는 위협 모델의 범주 내에 포함됩니다.

1. 환각을 거두다

공격자는 코드 생성 프롬프트를 대량으로 실행하고, 출력된 모든 패키지 이름을 수집한 뒤, 각각을 PyPI나 npm에서 조회합니다. 조회되지 않는 이름은 목록에 추가됩니다. 동일한 모델을 반복해서 실행해도 계속 조회되지 않는 이름은 목록 상단에 배치됩니다.

한 가지 연구 결과는 깊이 생각해 볼 가치가 있습니다. USENIX 연구에 따르면, 환각으로 생성된 이름은 여러 모델에 걸쳐 공통적으로 나타나는 경우보다 특정 모델에만 국한되는 경우가 훨씬 더 많았습니다. 고유한 이름의 81%는 테스트 대상이었던 16개 모델 중 정확히 하나에서만 나왔습니다. 재발 빈도와 중복 정도는 모델마다 다르기 때문에, 공통 블랙리스트만으로도 충분하다고 가정하기보다는 자체 팀이 실제로 사용하는 어시스턴트를 직접 측정하는 것이 현명한 방법입니다.

연구 규모로 측정을 수행하는 데는 비용이 적지 않지만, 꼭 비싸야만 하는 것은 아닙니다. USENIX 팀은 16개 모델에 걸쳐 576,000개의 코드 샘플을 생성했으며 두 가지 언어와 광범위한 프롬프트 세트를 포괄했습니다. 하나의 프레임워크, 하나의 클라우드 SDK, 또는 내부적인 성격의 사용 사례 하나를 조사하는 데 필요한 양은 별개의 문제이며, 그 규모도 훨씬 작습니다.

2024년 초 이 연구에서 검증한 모델들에서 모델 선택은 매우 중요한 요인으로 작용했는데, 오픈소스 모델의 환각 발생률은 평균 21.7%였던 반면 상용 모델은 5.2%에 그쳤다. A 2026년에 발표된 프리프린트에서는 동일한 방법론을 5개의 최신 최첨단 모델에 적용하여 전체 오류율이 4.62%에서 6.10% 사이로 집계되었다. 이 논문은 아직 동료 심사를 거치지 않았으므로, 확립된 추세라기보다는 초기 신호로 받아들여야 한다. 임의로 지어진 모델 이름들은 어느 쪽으로도 사라지지 않았다.

알아두면 좋은 팁: 다음과 같은 타당한 접미사: -utils, -helpers, -client, 그리고 -sdk 와 같은 접미사는 지어낸 이름도 언뜻 보기에는 신뢰할 수 있는 것처럼 보이게 할 수 있습니다. 합리적으로 보이는 명명 규칙은 확인해야 할 단서로만 삼고, 결코 해당 패키지가 실제 존재한다는 증거로 삼아서는 안 됩니다.

2. 이름을 등록하고 생동감 있게 보이게 하세요

공격자는 가장 그럴듯한 이름을 등록한 뒤, 제대로 작동하는 무언가를 공개합니다. 이름에서 암시하는 바와 대략적으로 일치하는 기능을 수행하는 코드, README 파일, 그리고 겉보기에는 정상적으로 보이는 라이선스 등이죠.

페이로드는 설치 경로 내에 있거나, 아무도 자주 호출하지 않는 임포트 함수 안에 숨겨져 있습니다. 실행될 때 외부로 요청을 보내는 설치 후크나, 일반 노트북에서는 한 가지 방식으로 동작하다가, 중요한 인증 정보와 네트워크 접근 권한이 있는 환경에서는 다른 방식으로 동작하는 코드 등이 그 예입니다. 겉보기에는 무해해 보이는 이러한 기능들은, 예상되는 임포트 함수가 정상적으로 작동하는 것처럼 보이기 때문에 시간을 벌어주는 것입니다.

다운로드 수치는 어떤 가설보다도 이 점을 더 잘 보여줍니다. Lasso Security는 ‘huggingface-cli’라는 허구적인 이름의 빈 패키지를 등록했고 로 등록한 빈 패키지가 3개월 동안 3만 건 이상의 다운로드를 기록했는데, 여기에는 README 파일에 이를 설치하라고 안내한 알리바바 연구 저장소도 포함되어 있었습니다. 페이로드가 전혀 포함되지 않은 무해한 개념 증명(PoC)임에도 불구하고, 결국 실제 개발 아티팩트에 참조되기도 했습니다.

3. 개발자가 AI의 지시에 따라 이를 설치한다

설치 과정 자체는 별다른 특징이 없습니다. 누군가가 조수에게 어떻게 해야 하는지 물어보고, 제대로 작동할 것 같은 코드를 받아서, 함께 제공된 명령어를 실행하면 됩니다.

pip install PACKAGE_NAME

레지스트리 제어 기능이나 엔드포인트 경고 기능이 없으면 어떤 경고도 발생하지 않습니다. 패키지는 해결되고, 설치되며, 가져오기됩니다. 개발자가 무언가를 확인한다면, 가져오기가 제대로 작동하는지 확인할 뿐이며, 실제로도 잘 작동합니다.

이 모델의 신뢰성이 이곳에서도 그대로 적용됩니다. 그 외에는 문제가 없는 코드 내에 포함된 패키지 이름은 해당 코드의 신뢰도를 빌려오게 되며, 업무 진행 속도가 빠른 팀에서는 일상적인 변경 과정에서 도입된 새로운 종속성이, 검토 과정에서 종속성 추가 사항이 명시적으로 드러나지 않는 한, 주변의 로직에 비해 덜 주목받게 됩니다. 여전히 누군가가 제안 내용을 읽고 실행 여부를 결정해야 합니다. 에이전트가 종속성을 설치할 수 있도록 허용되고 승인 절차가 전혀 없는 경우, 아무도 그 내용을 읽지 않게 됩니다.

4. 빌드 및 CI 과정을 거치더라도 유지됩니다.

이름이 requirements.txt 또는 package.json에 등록되면, 이는 더 이상 선택의 문제가 아니라 인프라가 됩니다. 해당 매니페스트를 통해 설치하는 빌드에서는 이를 가져옵니다. 새로운 컨테이너 이미지는 이를 내장합니다. 노트북부터 CI 러너, 배포 토큰과 레지스트리 자격 증명을 보유한 빌드 시스템에 이르기까지, 이 종속성을 해결하는 모든 환경이 이를 상속받습니다.

전파 현상은 상황을 더욱 악화시킵니다. 침해된 패키지가 내부 라이브러리의 의존성으로 포함되면, 원래의 제안을 전혀 보지 못한 관리자가 담당하는 서비스까지 이 패키지가 전달될 수 있습니다. 이 시점이 되면 감사 시 핵심 질문은 더 이상 ‘누가 이것을 설치했는가’가 아니라, ‘이것이 어디까지 퍼졌는가’가 됩니다.

그 결과로 발생하는 문제는 보안이 침해된 의존성에서 흔히 볼 수 있는 전형적인 사례들입니다. 즉, 인증 정보 도용, 암호화폐 채굴, 예기치 않은 외부 트래픽, 또는 빌드 환경이 접근할 수 있는 모든 대상에 대한 광범위한 침해 등이 있으며, 리눅스 호스트도 포함됩니다.

주의: 락파일(lockfile)은 악성 패키지를 정상적인 패키지인 것처럼 완벽하게 고정시킵니다. 락파일은 재현성을 보장할 뿐, 무엇이 고정되었는지에 대해서는 아무런 정보를 제공하지 않습니다. 해당 의존성과 그 락파일 항목이 의도적으로 제거되기 전까지는, 이 파일을 통해 설치하는 모든 호스트에서 보안 침해 현상이 재현될 것입니다.

연구 결과가 보여주는 바

이 수치는 다음에서 가져온 것입니다. USENIX Security 2025에서 발표된 『We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs』에서 비롯된 것으로, USENIX Security 2025에서 발표된 논문입니다. 이 논문은 이 분야의 모든 연구자들이 결국 인용하게 되는 대규모 연구이며, 아래 표의 모든 수치는 간접적인 요약이 아닌 이 논문을 직접 인용한 것입니다.

발견	그림
환각에 빠진 듯한 상품 추천	223만 명 중 440,445명 (19.7%)
관찰된 독특한 환각적 이름들	205,474
오픈 소스 모델의 환각 발생률	21.7%
상업용 모델의 환각 발생률	5.2%
10회 재방송 모두에서 환각 장면이 반복되어 나왔다	43%
다시는 나타나지 않은 환각	39%
npm 패키지로 인정되는 파이썬 환각	8.7%

여기서 헤드라인에 나온 백분율보다 더 중요한 세 가지가 있습니다.

반복성은 공격의 원동력입니다. 환각으로 나타난 이름 중 43%는 10번의 재실행 모두에서 다시 나타났고, 58%는 한 번 이상 재출현했는데, 이는 이들 대부분이 일회성 잡음의 범위를 벗어난다는 것을 의미합니다. 반복 가능성 덕분에 공격자가 시간을 들여 정보를 수집할 가치가 있는 것입니다.

여러 생태계를 아우르는 수치가 사람들을 혼란스럽게 만듭니다. ảo로 생성된 파이썬 이름 중 8.7%가 유효한 npm 패키지였기 때문에, 이름이 어딘가에 존재하는지 확인하는 개발자는 아무런 의미가 없는 ‘통과’ 신호를 받게 됩니다. 다른 레지스트리에 존재한다고 해서 그것이 요청한 의존성이라는 증거는 아닙니다.

언어별 차이는 변화하고 있습니다. USENIX 연구에 포함된 2024년형 모델들을 살펴보면, 자바스크립트의 환각 발생률은 21.3%였던 반면 파이썬은 15.8%였습니다. 2026년 프리프린트에서는 5개의 최신 모델을 대상으로 한 분석 결과, 이러한 관계가 역전되었다고 보고되었습니다. 이를 특정 언어의 특성이 아니라, 현재 다루고 있는 모델의 특성으로 간주해야 합니다.

AI 에이전트가 왜 위험을 높이는가

 

위의 3단계는 누군가가 AI가 제안한 코드를 실행하기 전에 이를 읽어본다는 전제를 바탕으로 합니다. 에이전트 기반 툴링은 이러한 전제를 없앨 수 있습니다. 오류를 확인하고, 누락된 종속성이 있음을 판단한 뒤 이를 설치하는 에이전트는 이 과정을 완전히 마무리하며, 미리보기나 정책 점검, 승인 절차 없이도 아무도 확인하기 전에 패키지 이름이 디스크에 저장됩니다.

공급업체의 테스트 결과에 따르면, 이 문제는 해결되지 않은 채 공구 성능만 개선되고 있는 것으로 보입니다. 트렌드마이크로의 슬롭스쿼팅 연구에 따르면 에 따르면, 논리적 추론과 실시간 웹 검색 기능을 갖춘 코딩 에이전트가 평가 과정에서 환각 발생률을 약 절반으로 줄였으며, 실시간 검증을 수행하는 설정에서 가장 적은 수의 유령 의존성이 발생했습니다. 하지만 이름 오류는 여전히 발생했습니다. 트렌드마이크로는 잔여 오류의 원인을 문맥 간극 메우기, 표면적 형태 모방, 그리고 생태계 간 이름 차용에서 기인한다고 분석합니다. 즉, 에이전트가 실제 패키지의 규칙을 따르지만 특정 패키지와 일치하지 않는 요소를 조합하는 경우입니다.

50% 감축은 의미 있는 성과입니다. 이는 감사관에게 넘겨줄 수 있는 통제 수단이 아닙니다.

또 다른 예로 ‘바이브 코딩(vibe coding)’이 있는데, 여기서는 AI가 생성한 코드를 의존성이나 설치 시 어떤 동작을 하는지 독립적으로 검토하지 않고 무작정 받아들이는 것을 의미합니다. 더 안전한 기본 설정은 그 반대입니다. AI가 제안한 모든 타사 의존성은 모델 이외의 다른 수단을 통해 해당 패키지와 버전이 확인될 때까지 검증되지 않은 상태로 유지되어야 합니다. 이러한 검증 공백에 자체적으로 설치되는 에이전트까지 더해지면, 검토 단계는 사실상 사라지게 됩니다.

슬롭스쿼팅에 대처하는 방법

이 문제를 단일 제어 수단만으로는 잡아낼 수 없습니다. 검증은 명백한 사례를 포착하고, 고정(pinning)은 영향 범위를 제한하며, 강제 허용 목록(allowlist)은 해결 경로를 차단하고, 스캔 및 검토 정책은 앞서 언급한 세 가지가 제대로 작동하도록 보장합니다. 이 모든 조치를 함께 실행하십시오.

빌드가 공개 레지스트리에서 직접 해결되는 경우, 방어 전략 3의 허용 목록이 문제의 양상을 바꾸는 핵심 요소입니다. 이미 내부 미러를 운영 중이라면, 해당 미러가 허용 목록을 적용하는지, 아니면 전달받은 내용을 무조건 캐시하는지 먼저 확인해야 합니다. 제한 없이 내용을 그대로 가져오는 캐시를 사용할 경우, 이 취약점은 이전과 거의 동일한 수준으로 남아 있기 때문입니다.

1. 패키지가 존재하고 이력이 있는지 확인합니다.

AI가 추천한 패키지를 매니페스트에 포함하기 전에, 해당 패키지가 처음 공개된 시점, 유지보수 담당자, 관련 저장소가 실제 존재하며 활발히 운영되고 있는지, 그리고 레지스트리에 등록된 아티팩트가 해당 소스와 일치하는지 여부를 확인해야 합니다. 공개 및 유지보수 담당자 정보는 별도의 설치나 패키지 코드 실행 없이 레지스트리 메타데이터에서 직접 가져옵니다.

curl -s https://pypi.org/pypi/PACKAGE_NAME/json

npm view PACKAGE_NAME time.created maintainers

채택 여부는 별도로 확인해야 합니다. PyPI의 JSON 엔드포인트는 다운로드 필드에서 -1을 반환하므로, 다운로드량이 분석 지표에 포함된다면 pypistats나 BigQuery 데이터셋에서 해당 데이터를 가져와야 합니다. 리포지토리의 진위 여부와 소스-아티팩트 간 일치 여부도 별도로 검증해야 합니다. 레지스트리 링크만으로는 해당 링크가 가리키는 대상의 소유자가 누구인지에 대해 아무것도 증명할 수 없습니다.

본능이 아닌 정책 차원에서 기준을 설정하십시오. 버전, 채택 여부, 유지보수자 신원, 소스-아티팩트 일치 여부 확인 등이 그것입니다. 이 네 가지 기준은 종속성이 그래프에 포함되기 전에 명백한 불일치를 드러내 주지만, 정교하게 제작된 악성 패키지는 이 모든 기준을 통과할 수도 있습니다. 이는 검토를 위한 신호일 뿐, 안전성을 입증하는 것은 아닙니다.

2. 락파일과 해시를 사용하여 종속성을 고정하기

락파일은 재현성을 보장합니다. 해시는 무결성을 보장합니다. 신뢰할 수 있는 절차를 통해 해시가 생성되고 보호되었다고 가정할 때, 해시는 설치한 아티팩트가 승인한 아티팩트와 동일함을 확인해 줍니다.

pip install –require-hashes -r requirements.txt

해시 확인 모드는 전 아니면 무의 원칙을 따릅니다. 모든 요구 사항과 모든 전이적 종속성은 반드시 == 로 고정하고 해시를 포함해야 하며, 그렇지 않으면 설치가 완전히 실패하므로, 첫 번째 단계가 번거로울 것임을 염두에 두어야 합니다. 고정이 해줄 수 없는 것은 고정된 항목이 과거에 안전했는지 여부를 알려주는 것입니다. npm의 레지스트리 데이터는 불변이므로, 특정 이름과 버전은 게시 취소 후에도 다시 게시될 수 없습니다. 현실적으로 발생할 수 있는 실패는 첫날부터 잘못된 패키지를 승인하고 고정해 버리는 것이므로, 고정은 검증 대신에 검증 후에 이루어져야 합니다.

설치 시 스크립트 실행은 별개의 문제이며, npm은 이미 이에 대한 조치를 취했습니다. 현재 npm은 기본적으로 종속성 설치 스크립트를 차단하며, allowScripts 에 일치하는 항목이 없는 라이프사이클 스크립트는 건너뛰며, 설치가 끝날 때 건너뛴 항목을 나열합니다. npm install-scripts 승인 및 npm install-scripts deny 해당 목록을 관리하며, 승인 내역은 실제로 검토한 버전에 고정되도록 하세요.

npm ci –ignore-scripts

구버전 npm에서 해당 플래그는 허용 목록을 제외한, 동일한 개념의 단순화된 버전입니다. 어느 쪽이든 설치 시점에만 적용됩니다. 임포트 시, 빌드 시 또는 실행 시에 실행되는 코드는 영향을 받지 않습니다.

3. 엄선된 출처에서만 정보를 가져오세요

가장 강력한 구조적 조치는 이름이 어떤 대상으로 해결될 수 있는지를 변경하는 것입니다. 승인된 카탈로그 외부의 모든 것을 거부하는 저장소는 임의로 지정한 이름의 해결에 실패하게 되는데, 이는 전체 체인에서 실패가 발생하는 데 가장 비용이 적게 드는 단계입니다.

해당 속성은 큐레이션 중인 저장소가 아니라 허용 목록에서 비롯된 것입니다. 많은 비공개 레지스트리는 해당 레지스트리가 다루는 패키지에 대해서는 검증된 빌드를 제공하지만, 그 외의 모든 항목은 업스트림에서 프록시 방식으로 전달하므로, 해당 범위에 포함되지 않은 모든 이름에 대해서는 원래의 노출 상태가 그대로 유지됩니다. 미러가 접근을 차단했다고 단정 짓기 전에 이 점을 확인해 볼 가치가 있습니다.

TuxCare의 SecureChain 는 지원 대상 세트를 위해 구축되었습니다. 이 서비스는 자바스크립트, 파이썬, 자바, Go, Rust, PHP 등 6가지 생태계를 아우르며, 모두 동일한 선별된 카탈로그를 통해 제공됩니다. 출시 시기는 생태계마다 약간씩 다를 수 있으며, 일부 생태계는 아직 출시 전 단계에 있을 수 있으므로 특정 스택의 최신 상태를 확인하시려면 [email protected]으로 이메일을 보내주십시오.

패키지는 보안이 강화되고 격리된 환경에서 소스 코드부터 재빌드되며, 알려진 악성코드 및 의심스러운 코드 패턴에 대한 검사를 거치고, CVE가 공개될 때마다 SLA에 따라 패치가 적용됩니다. 또한 SLSA 레벨 3 출처 정보와 SBOM 및 VEX 데이터도 제공됩니다. 패키지 또는 리포지토리 관리자를 TuxCare 레지스트리로 지정하면, 재생성된 락파일(lockfile)은 공개 타르볼 대신 TuxCare URL과 체크섬을 기록합니다. TuxCare의 공식 문서에 따르면, 해당 레지스트리는 SecureChain 빌드가 존재하는 경우 이를 제공하고, 그 외의 경우에는 동일한 엔드포인트를 통해 공개 업스트림 패키지를 제공합니다. 따라서 슬롭스쿼팅 방지 보장은 레지스트리 교체 자체에서 비롯되는 것이 아니라, 그 위에 적용하는 허용 목록(allowlist)에서 비롯됩니다.

4. 새로운 종속성에 대한 동작을 분석하고 관찰하기

서명 및 평판 기반 탐지는 이미 누군가에 의해 식별된 위협에 대해 가장 효과적입니다. 새로 등록된 악성 패키지는 아직 해당 데이터베이스에 등록되지 않았기 때문에, 바로 이 틈을 노려 슬롭스쿼팅이 활동하는 것입니다.

행동 기반 검사가 이러한 공백을 메워줍니다. 설치 중 예상치 못한 네트워크 접속, 평문이어야 할 패키지 내의 난독화되거나 축소된 소스 코드, 자격 증명 및 환경 변수 읽기, 패키지 디렉터리 외부의 쓰기 등이 그 예입니다. 특히 네이티브 모듈 빌드의 경우, 합법적인 패키지 중에서도 이러한 행위 중 한두 가지를 수행하는 경우가 많기 때문에, 이를 자동으로 차단하기보다는 검토를 위해 표면화하는 것이 중요합니다.

병합 전에 CI에서 종속성 변경 사항을 스캔하고, 정기적인 재스캔도 계속 실행하도록 하세요. 첫 번째 스캔은 새로 추가된 내용을 포착하고, 두 번째 스캔은 처음에는 문제가 없었지만 3주 후에 문제가 생긴 패키지를 포착합니다.

전문가 팁: 모든 풀 리퀘스트에서 종속성 매니페스트를 비교 분석하고, 코드 검토와는 별도로 추가 항목에 대한 명시적인 승인을 요구하십시오. 종속성 변경 사항을 일반적인 코드 변경 사항과 분리해야만 공급망 검토가 충분히 가시화되어 이를 철저히 요구할 수 있습니다.

5. AI가 생성한 코드에 대한 검토 지침을 작성하십시오.

도구만으로는 프로세스상의 문제점을 해결할 수 없습니다. AI 도구가 종속성을 제안할 경우 어떻게 대응할지 서면으로 결정하십시오.

실행 가능한 정책은 사람이 ‘방어 조치 1’의 검증을 거칠 때까지 AI가 제안한 모든 패키지를 신뢰할 수 없는 것으로 간주하며, 빌드 성공 여부만으로는 판단하지 않고 이름과 버전을 명시하여 새로운 종속성을 승인합니다. 에이전트는 검토되지 않은 상태로 종속성 매니페스트에 대한 쓰기 권한을 얻지 못하며, 추가 및 버전 변경은 승인 절차를 거쳐야 합니다. 승인된 소스 목록은 패키지 관리자나 저장소 정책 계층에서 강제 적용되므로, 정책 위반은 신뢰 여부의 문제가 아닌 빌드 실패로 나타납니다.

TuxCare SecureChain이 설치 과정에서 어떤 점을 변경하는가

슬롭스쿼팅이 통하는 이유는, 설치 명령어가 아무도 검증하지 않은 이름을 아무렇지 않게 해결해 주기 때문입니다. SecureChain은 이름을 해결할 때 얻어지는 결과를 바꿔 놓습니다. 카탈로그에 포함된 패키지는 검증된 소스 코드로부터 재컴파일되며, 설치 가능해지기 전에 알려진 악성코드와 의심스러운 패턴에 대한 검사를 거칩니다. 또한 업스트림 유지보수자가 작업을 중단한 후에도 지속적으로 패치가 적용되므로, ‘환각 이름’ 문제와 바로 인접해 있는 ‘손상된 종속성’ 문제까지 해결해 줍니다.

가장 상단에 허용 목록을 적용하여 빌드가 해당 카탈로그를 넘어갈 수 없도록 하고, 공격자가 먼저 그곳에 도달했는지 여부와 관계없이 임의로 지어진 이름으로는 설치할 대상이 전혀 없도록 해야 합니다.

다음 페이지에서 이 솔루션이 귀하의 기술 스택에 어떻게 적용되는지 확인해 보세요. SecureChain for OSS 페이지에서에서 확인해 보시거나, 저희에게 문의해 주시면 문의해 주십시오.

자주 묻는 질문