공급망이 곧 공격 표면이다

title: “공급망이 공격 표면이다” slug: the-supply-chain-is-the-attack-surface date: 2026-03-25 description: “Trivy가 침해되었습니다. 그다음 LiteLLM. 그리고 46분 만에 47,000건의 설치. AI 공급망은 설계된 대로 작동했습니다.” tags: [ai, security, supply-chain, agents, engineering, trust, infrastructure] author: Blake Crosley category: AI & Technology series: “AI Engineering”

2026년 3월 19일, TeamPCP라는 위협 그룹이 Aqua Security의 trivy-action GitHub 저장소에서 77개 버전 태그 중 76개를 강제 푸시했습니다. Trivy는 업계에서 가장 넓리 배포된 오픈소스 취약점 스캐너입니다. 새로운 태그는 자격 증명 탈취 맬웨어를 포함한 악성 커밋을 가리켰습니다. 대부분의 CI/CD 파이프라인이 고정된 커밋 SHA 대신 변경 가능한 버전 태그로 GitHub Actions를 참조하기 때문에, 빌드 파이프라인에서 Trivy를 실행하는 모든 조직이 침해된 코드를 즉시 실행하기 시작했습니다. 스캔은 계속 성공하는 것처럼 보였습니다. 스캐너는 계속 취약점을 보고했습니다. 동시에 러너 환경의 모든 비밀 정보를 조용히 수집하고 있었습니다.¹

5일 후인 3월 24일, TeamPCP는 해당 CI 환경 중 하나에서 탈취한 PyPI 발행 토큰을 사용하여, 클라우드 환경의 36%에 존재하는 인기 AI 프록시 라이브러리인 LiteLLM의 백도어 버전 2개를 발행했습니다.² 버전 1.82.8에는 모든 Python 시작 시 자동으로 실행되는 .pth 파일이 포함되어 있었습니다—모든 import 전에, 모든 애플리케이션 레벨 샌드박스 전에 실행됩니다. 페이로드는 SSH 키, 클라우드 자격 증명, 데이터베이스 비밀번호, 암호화폐 지갑, CI/CD 시크릿을 수집하고, 하드코딩된 RSA 공개키로 암호화한 후, 전날 등록된 공격자 제어 도메인으로 아카이브를 유출시켰습니다.³

PyPI는 46분 후 두 버전을 격리했습니다. 그 사이에 46,996건의 설치가 발생했습니다.⁴ LiteLLM 메인테이너는 GitHub 계정을 삭제하고, 모든 키를 로테이션하고, Mandiant를 고용했습니다.⁵

보안 스캐너는 스캔했습니다. 빌드 파이프라인은 빌드했습니다. 패키지 매니저는 설치했습니다. 모든 컴포넌트가 신뢰받은 대로 정확히 동작했습니다.

TL;DR

• 체인: Trivy(보안 스캐너)가 3월 19일 GitHub Actions 태그 하이재킹으로 침해. LiteLLM(AI 프록시)이 3월 24일 Trivy에 감염된 CI 환경에서 탈취한 PyPI 토큰으로 침해. 46분 만에 46,996건 다운로드.⁴
• 기법: 버전 1.82.8은 Python의 .pth 메커니즘을 악용하여 감염된 시스템에서 모든 python3 호출 시 LiteLLM을 import하지 않고 자격 증명 탈취 맬웨어를 실행.³
• 폭발 반경: PyPI의 2,337개 패키지가 LiteLLM에 의존. 88%가 침해 버전 설치를 허용하는 버전 사양. Google ADK, Stanford DSPy, MLflow, Guardrails AI, Cisco AI Defense SDK에 대한 하류 영향 확인.⁴
• 캔페인: TeamPCP가 1주일 만에 5개 생태계 공격: GitHub Actions, Docker Hub, npm(CanisterWorm, 28개 이상 패키지), Open VSX(Checkmarx KICS), PyPI(LiteLLM).⁶
• 구조적 교훈: 체인의 각 링크는 허가된 범위 내에서 작동했습니다. 허가된 작업들의 조합이 허가되지 않은 동작을 만들어냈습니다. 이것은 에이전트 레벨에서의 사일런트 이그레스와 CI/CD 레벨에서의 Clinejection을 가능하게 하는 것과 동일한 컴포지션 걭입니다. 공급망 공격은 컴포지션 공격입니다.
• 대응 방안: 의존성을 불변 참조에 고정합니다. 발행 자격 증명을 CI 러너에서 분리합니다. 아웃바운드 네트워크 요청을 OS 레벨에서 모니터링합니다. pip install을 코드 실행으로 취급합니다—실제로 코드 실행이기 때문입니다.

보안 스캐너가 빌드 파이프라인에 진입하다

공격은 2026년 2월 말 Trivy의 GitHub Actions 환경 설정 오류에서 시작되었습니다. 공격자는 취약한 pull_request_target 워크플로를 악용하여 Aqua Security의 aqua-bot 개인 액세스 토큰을 유출시켰습니다. Aqua는 3월 1일에 일부 자격 증명을 로테이션했지만, 로테이션이 불완전했습니다. TeamPCP는 유효한 토큰을 유지했습니다.¹

3월 19일, 그들은 해당 토큰을 사용하여 trivy-action 저장소의 77개 버전 태그 중 76개와 setup-trivy의 7개 태그 전부를 강제 푸시하여 모든 변경 가능한 태그 참조를 악성 커밋으로 리디렉션했습니다. 또한 릴리스 자동화를 트리거하여 악성 Trivy 바이너리를 v0.69.4로 발행했습니다.¹

페이로드는 Runner.Worker 프로세스 메모리를 덤프하고, SSH 키, 클라우드 자격 증명, Kubernetes 시크릿, Docker 설정, Git 자격 증명, .env 파일을 수집하는 자격 증명 탈취 맬웨어였습니다. 데이터는 AES-256과 4096비트 RSA 키로 암호화된 후 공격자가 제어하는 서버로 유출되었습니다. 악성 코드는 정상적인 Trivy 기능과 병행하여 실행되었습니다. 스캔은 성공했습니다. 취약점이 보고되었습니다. 탈취 맬웨어는 백그라운드에서 실행되고 있었습니다.⁷

3월 19일부터 23일 사이에 Docker Hub의 trivy:0.69.4, trivy:0.69.5, trivy:0.69.6, trivy:latest 태그 이미지가 침해되었습니다. CrowdStrike, Microsoft, Wiz, Palo Alto가 며칠 내에 기술 분석을 발표했습니다.⁷⁸⁹

아이러니는 구조적입니다. 보안 의식이 가장 높은 조직이 가장 크게 노출되었습니다. 취약점 스캔을 중요시하여 CI에서 Trivy를 실행했다면, 귀하의 빌드 파이프라인이 자격 증명을 수집하고 있었던 것입니다.

스캐너에서 탈취 맬웨어로, 그리고 AI 프록시로

LiteLLM의 CI 파이프라인은 Trivy를 실행했습니다. 구체적으로 ci_cd/security_scans.sh가 Aqua의 저장소에서 버전 고정 없이 apt를 통해 Trivy를 설치했습니다.¹⁰ 침해 창기간 동안 CI 실행이 오염된 Trivy 바이너리를 설치했고, GitHub Actions 환경에서 PYPI_PUBLISH_PASSWORD를 수집했습니다.

3월 23일, 공격자는 litellm.cloud를 등록했습니다. 3월 24일 10:39 UTC에 탈취한 자격 증명을 사용하여 PyPI에 litellm==1.82.7을 발행했습니다. 버전 1.82.8이 10:52 UTC에 이어졌습니다.⁴

두 버전은 서로 다른 공격 기법을 사용했습니다. 버전 1.82.7은 proxy_server.py에 페이로드를 내장하여 import litellm.proxy 시 트리거됩니다. 버전 1.82.8은 site-packages/에 .pth 파일을 추가하여 Python 인터프리터 시작 시 트리거됩니다. .pth 메커니즘은 경로 설정을 위한 정상적인 Python 기능입니다. site-packages/에 위치한 .pth로 끝나는 모든 파일은 인터프리터 초기화 시 Python의 site.py에 의해 자동으로 실행됩니다. 대부분의 Python 개발자는 이 기능의 존재를 모릅니다.³

두 버전의 페이로드는 환경 변수, SSH 키, AWS/GCP/Azure 자격 증명, Kubernetes 설정, 데이터베이스 비밀번호, 암호화폐 지갑, CI/CD 시크릿을 수집했습니다. 랜덤 세션 키를 사용하여 AES-256-CBC로 컨렉션을 암호화하고, 하드코딩된 4096비트 RSA 공개키로 세션 키를 래핑한 후 HTTPS POST를 통해 아카이브를 유출시켰습니다. 탈취된 데이터를 복호화할 수 있는 것은 공격자만입니다.³

1.82.8 맬웨어의 버그로 인해 발견되었습니다. .pth 파일이 자식 Python 프로세스를 생성하고, 이것이 .pth 파일을 다시 트리거하여 지수적 fork bomb을 만들었습니다. Andrej Karpathy가 X에서 이 버그를 지적했습니다. fork bomb이 없었다면 탈취 맬웨어는 감염된 모든 시스템의 모든 Python 호출에서 발간되기 전 몇 주 동안 조용히 실행되었을 것입니다.⁴

PyPI는 11:25 UTC에 두 버전을 격리했습니다. 총 노출 시간: 46분. 총 다운로드: 46,996건.⁴

폭발 반경

LiteLLM은 하루에 약 340만 회 다운로드됩니다. Wiz에 따르면 클라우드 환경의 36%에 존재합니다.² 46분의 노출 창으로 충분했습니다.

FutureSearch는 PyPI의 BigQuery 다운로드 로그를 분석한 결과, 공격 창 동안 버전 1.82.8이 안전한 버전보다 6배 더 많이 다운로드되었음을 발견했습니다. 다운로드는 uv(락 파일 사용)에 비해 pip(최신 버전으로 해석)에 크게 편향되었습니다. 46,996건의 다운로드 중 23,142건이 v1.82.8의 pip 설치였으며, .pth 파일이 pip 자체의 Python 프로세스 내에서 발화하기 때문에 설치 자체 중에 페이로드가 실행되었습니다.⁴

PyPI에서 2,337개 패키지가 LiteLLM에 의존합니다. 88%(2,054개 패키지)가 침해 버전의 설치를 허용하는 버전 사양을 가지고 있었습니다. 하류 노출은 다음과 같습니다:⁴

LiteLLM Cloud 및 Docker 프록시 사용자는 영향을 받지 않았습니다. 의존성이 requirements.txt에 고정되어 있었기 때문입니다. “고정”과 “미고정”의 차이가 침해와 안전의 차이였습니다.⁵

1주일에 5개 생태계

TeamPCP는 PyPI에서 멈추지 않았습니다. 캔페인은 5개 패키지 생태계를 연속으로 공격했습니다:⁶

GitHub Actions (3월 19일): trivy-action의 76개 태그와 setup-trivy의 7개 태그 전부 하이재킹. 악성 Trivy 바이너리 v0.69.4부터 v0.69.6 발행.

Docker Hub (3월 19-22일): 침해된 Trivy 이미지가 aquasec/trivy:latest 및 버전별 태그로 발행. mirror.gcr.io로 전파.

Open VSX (3월 23일): Checkmarx KICS GitHub Action 침해. 12:58부터 16:50 UTC 사이에 35개 태그 하이재킹.²

npm (3월 23-24일): CanisterWorm, 자기 복제 웜이 28개 이상의 npm 패키지에 배포.

PyPI (3월 24일): LiteLLM 버전 1.82.7과 1.82.8이 자격 증명 탈취 페이로드와 함께 발행.

각 생태계 침해는 이전 생태계에서 수집한 자격 증명을 사용했습니다. 캔페인은 신뢰 악용의 방향 그래프였으며, 각 침해된 노드가 다음 노드의 키를 제공했습니다.

공급망 공격은 컴포지션 공격이다

TeamPCP 캔페인의 구조적 패턴은 에이전트 보안과 사일런트 이그레스의 맥락에서 제가 설명한 것과 동일한 패턴입니다: 개별적으로 허가된 컴포넌트가 조합되어 허가되지 않은 동작을 만들어내는 것입니다.

Trivy는 CI에서 실행할 권한이 있었습니다. CI는 발행 자격 증명을 보유할 권한이 있었습니다. 패키지 매니저는 패키지를 설치할 권한이 있었습니다. 각 .pth 파일은 Python 경로를 설정할 권한이 있었습니다. 체인의 각 링크는 정의된 범위 내에서 작동했습니다. 이러한 허가된 작업들의 조합이 대규모 자격 증명 유출을 만들어냈습니다.

Clinejection 공격은 CI/CD 레벨에서 동일한 패턴을 실증했습니다: issue 제목이 Cline의 자동화 파이프라인에 적대적 텍스트를 주입하고, npm preinstall 스크립트를 실행하고, 빌드 캐시를 오염시키고, 크로스 워크플로 아티팩트를 오염시켰습니다. 각 단계는 개별적으로 허가되었습니다.¹¹

MCPTox 벤치마크는 에이전트 레벨에서 실증했습니다: 도구 설명에 포함된 악의적인 지시가 서버에 이미 있는 정상적인 도구를 사용하여 자격 증명을 유출하도록 에이전트를 리디렉션했습니다. 에이전트는 오염된 도구 자체를 실행한 적이 없습니다. 오염된 설명을 읽고 자신의 허가된 도구를 사용하여 공격을 수행했습니다.¹²

사일런트 이그레스는 런타임 레벨에서 실증합니다: 웹 페이지 메타데이터의 적대적 지시가 에이전트가 실행 권한이 있는 아웃바운드 HTTP 요청을 통해 런타임 컨텍스트를 유출시킵니다.¹³

공격 표면은 단일 취약 컴포넌트가 아닙니다. 공격 표면은 신뢰된 컴포넌트의 컴포지션입니다. 개별 링크를 보호해도 체인은 보호되지 않습니다. Trivy는 취약점이 아니었습니다. LiteLLM은 취약점이 아니었습니다. 취약점은 변경 가능한 버전 태그와 미고정 의존성으로 중재된 그들 사이의 신뢰 관계였습니다.

실제로 효과적인 대응책

이 공격의 각 단계를 방지했을 방어책은 지루합니다. 그리고 대부분의 조직이 건너뛰는 방어책이기도 합니다.

불변 참조에 고정합니다. LiteLLM은 버전 고정 없이 apt를 통해 Trivy를 설치했습니다. security_scans.sh가 특정 버전이나 커밋 SHA에 고정했다면 오염된 v0.69.4 바이너리는 실행되지 않았을 것입니다. GitHub Actions는 변경 가능한 태그가 아닌 커밋 SHA를 참조해야 합니다. uses: aquasecurity/[email protected](침해)과 uses: aquasecurity/trivy-action@57a97c7(안전)의 차이가 발행 자격 증명을 잃느냐 마느냐의 차이입니다.¹

발행 자격 증명을 CI 러너에서 분리합니다. PYPI_PUBLISH_PASSWORD는 Trivy가 실행된 GitHub Actions 러너에서 환경 변수로 접근 가능했습니다. 발행 자격 증명이 서드파티 액션 의존성이 없는 별도 워크플로에 분리되었다면, Trivy 침해는 PyPI 접근을 제공하지 않았을 것입니다. PyPI의 Trusted Publishers(OIDC)는 저장된 토큰을 완전히 제거합니다.⁵

아웃바운드 네트워크 요청을 모니터링합니다. 자격 증명 탈취 맬웨어는 HTTPS POST로 models.litellm.cloud(공격 24시간 전에 등록된 도메인)에 데이터를 유출시켰습니다. 신규 등록 도메인에 대한 요청을 플래그하는 이그레스 모니터링이 있었다면 이를 탐지할 수 있었습니다. 제 훅 시스템은 허용 목록에 없는 도메인으로의 아웃바운드 요청을 차단합니다—이 유출을 차단했을 동일한 패턴입니다.¹⁴

저는 프로덕션 환경에서 같은 교훈을 힘들게 배웠습니다. 신뢰할 수 있는 Cloudflare 캐시 퍼지 경로가 허가된 API 호출을 발행했지만, 주변 가드레일이 너무 느슨하여 잘못된 결과를 만들었습니다. 그 실패로 인해 도메인 허용 목록만이 아니라 고영향 작업에 대한 파괴적 작업 승인과 프리플라이트 훅을 추가하게 되었습니다.

pip install을 코드 실행으로 취급합니다. site-packages/의 .pth 파일은 모든 Python 시작 시 실행됩니다. 옵트아웃이 없습니다. 샌드박스가 없습니다. 자격 증명에 접근할 수 있는 CI 환경에서 pip install을 실행하면, 패키지의 모든 전이적 의존성에 임의 코드 실행을 허용하는 것입니다. 대응책은 자격 증명에 접근할 수 없는 환경에서 pip install을 실행한 후 설치된 패키지를 필요한 환경으로 복사하는 것입니다.

락 파일을 사용합니다. FutureSearch의 분석에 따르면, uv(락 파일 사용)를 통한 다운로드는 pip(최신 버전으로 해석)를 통한 다운로드보다 침해 버전을 설치할 가능성이 훨씬 낮았습니다. 락 파일은 완전한 방어는 아니지만, 가장 일반적인 노출을 방지합니다: 미고정 >= 버전 제약이 침해 릴리스로 조용히 업그레이드되는 것을 방지합니다.⁴

불편한 시사점

TeamPCP 캔페인은 공급망 보안이 애플리케이션 보안, 네트워크 보안, 엔드포인트 보호 뒤에 위치하는 부차적인 관심사가 아님을 보여줍니다. 도구 접근 권한을 가진 AI 에이전트를 운영하는 조직에게 공급망이 주요 공격 표면입니다.

CI 환경에서 pip install을 호출하고, URL을 가져오고, MCP 서버를 설치하는 AI 에이전트는 런타임에 신뢰 관계를 구성하고 있습니다. 각 작업은 허가되어 있습니다. 컴포지션은 허가되지 않을 수 있습니다. 배포-및-방어 패러독스가 이를 가속화합니다: 조직은 에이전트가 구성하는 신뢰 체인을 감사하는 것보다 더 빨리 에이전트를 배포합니다.

LiteLLM 1.82.8의 fork bomb 버그가 이 공격이 빠르게 발견된 유일한 이유였습니다. 이 구현 오류가 없었다면, 자격 증명 탈취 맬웨어는 감염된 모든 시스템의 모든 Python 호출에서 조용히 실행되었을 것입니다. 46분 만에 46,996건의 설치. 클라우드 환경의 36%. 2,337개의 하류 패키지. 공격자는 실수했습니다. 다음에는 그렇지 않을 수도 있습니다.

업데이트 — 2026년 3월 31일: 다른 벡터, 같은 결과

이 글이 공개된 지 6일 후, npm에 또 다른 사고가 발생했습니다. 3월 31일, axios 메인테이너인 Jason Saayman은 자신의 개인 컴퓨터가 표적형 소셜 엔지니어링 캠페인과 이어진 원격 액세스 트로이 목마 악성코드를 통해 침해당했다고 공개했습니다. 공격자들은 그의 npm 자격 증명을 사용해 axios 1.14.1과 0.30.4를 게시했으며, 두 버전 모두 [email protected]이라는 새로운 종속성을 주입해 macOS, Windows, Linux에 크로스 플랫폼 RAT를 설치했습니다. 악성 버전은 약 3시간 동안 유지되다가 커뮤니티 기여자들이 사고를 분류하고 npm이 해당 버전을 제거했습니다.¹⁶

axios 벡터는 TeamPCP와는 달랐습니다. 침해된 CI 러너도 없었고, 서드파티 보안 스캐너에서 수집된 자격 증명도 없었으며, 다중 생태계 웜도 없었습니다. Saayman을 겨냥한 캠페인은 게시 이전에 약 2주간 진행되었으며, 침해는 메인테이너의 개인 장치를 통해 곧바로 npm 게시 파이프라인까지 이어졌습니다. 복구를 위해서는 그의 모든 장치를 완전히 초기화하고, 개인용이든 아니든 그가 사용했던 모든 플랫폼의 모든 자격 증명을 교체해야 했습니다. C2 인프라는 142.11.206.73:8000에서 운영되는 sfrclak[.]com이었습니다.¹⁶

구조적 교훈은 동일합니다. 이제 신뢰 체인에는 메인테이너의 주의력과 경계심이 하나의 연결 고리로 포함됩니다 — 개별적으로는 허가된 작업들이 체인 내 사람이 조작당했을 때 허가되지 않은 동작으로 결합됩니다. axios 팀이 채택 중인 완화 조치(OIDC 게시, 불변 릴리스, 장치 격리)¹⁶는 Trivy에서 LiteLLM으로 이어진 사고가 드러낸 것과 동일한 결합 공백을 다룹니다. 즉, 이미 인접한 무언가를 침해한 공격자가 접근할 수 있는 위치에 게시 자격 증명이 저장되어 있다는 문제입니다.

3시간. 46분. 이것이 오늘날 현대적 공급망 공격이 작동하는 시간 창입니다. 핀 고정과 lockfile은 여전히 주요 방어 수단입니다 — 3월 31일 00:21-03:15 UTC 시간대 외에 새로 설치한 axios 사용자들은 영향을 받지 않았습니다.¹⁶

FAQ

영향을 받았는지 어떻게 확인합니까?

CI 로그와 로컬 환경에서 2026년 3월 24일 10:39부터 11:25 UTC 사이에 설치된 LiteLLM 버전 1.82.7 또는 1.82.8을 검색하십시오. 두 버전 중 하나라도 설치된 경우, 해당 시스템에서 환경 변수, SSH 키 또는 설정 파일로 접근 가능했던 모든 자격 증명을 로테이션하십시오. LiteLLM의 공식 가이드는 침해 버전을 실행한 모든 시스템을 완전히 침해된 것으로 취급할 것을 권장합니다.⁵

어떤 자문 식별자를 추적해야 합니까?

OSV와 PyPA 자문 데이터베이스에서 PYSEC-2026-2를 추적하십시오. OSV는 이 인시던트를 MAL-2026-2144 별칭으로도 나열합니다. 2026년 3월 25일 기준으로 OSV 공개 자문 페이지에는 악성 LiteLLM 릴리스에 대한 CVE 별칭이 나열되어 있지 않으므로, 인시던트 대응 팀은 영향받는 버전, 설치 창, PYSEC-2026-2를 기준으로 해야 합니다.¹⁵

LiteLLM Cloud 또는 Docker 프록시 사용자는 영향을 받았습니까?

아니요. LiteLLM Cloud와 공식 Docker 프록시 이미지는 requirements.txt에서 의존성을 고정하여 침해 버전으로의 자동 해석을 방지합니다. 46분 창 동안 pip install litellm(미고정)으로 LiteLLM을 설치한 사용자만 영향을 받았습니다.⁵

.pth 파일이란 무엇이며 왜 위험합니까?

.pth 파일은 모듈 검색 경로를 설정하기 위한 Python 기능입니다. site-packages/ 디렉토리에 위치한 .pth로 끝나는 모든 파일은 인터프리터 초기화 시 Python의 site.py 모듈에 의해 읽히고 실행됩니다. 이는 모든 import 문 전, 모든 애플리케이션 코드 전, 모든 Python 레벨 샌드박스 전에 발생합니다. 이 메커니즘은 Python 표준 라이브러리에 문서화되어 있지만 애플리케이션 개발자에게는 널리 알려져 있지 않습니다. 공격 벡터로 사용되는 정상적인 기능입니다.³

이것은 Trivy 공급망 공격과 관련이 있습니까?

네. LiteLLM 침해는 Trivy 침해의 직접적인 결과였습니다. TeamPCP는 3월 19일에 Trivy의 GitHub Actions를 침해하여 빌드 파이프라인에서 Trivy를 실행하는 조직의 CI/CD 자격 증명을 수집했습니다. 그 자격 증명 중 하나가 LiteLLM의 PyPI 발행 토큰이었습니다. 공격자는 그 토큰을 사용하여 5일 후 악성 LiteLLM 버전을 발행했습니다.¹⁰

TeamPCP란 무엇입니까?

TeamPCP(DeadCatx3, PCPcat, ShellForce, CipherForce로도 추적)는 2026년 3월에 다중 생태계 공급망 캔페인을 수행하여 GitHub Actions, Docker Hub, npm, Open VSX, PyPI의 패키지를 침해한 위협 그룹입니다. 이 그룹은 자격 증명 수집, 태그 하이재킹, 자기 복제 웜 기법을 사용하여 약 1주일 만에 5개 패키지 생태계를 공격했습니다.⁶

AI 에이전트 보안과의 관련성은?

패키지를 설치하고, URL을 가져오고, MCP 서버에 연결하는 AI 에이전트는 런타임에 신뢰 관계를 구성합니다. 각 작업은 개별적으로 허가됩니다. 이러한 작업들의 컴포지션은 사일런트 이그레스(에이전트 레벨), Clinejection(CI/CD 레벨), 그리고 이 공격(공급망 레벨)이 보여주듯이 허가되지 않은 동작을 만들어낼 수 있습니다. 런타임 행동 모니터링, 도메인 허용 목록, 자격 증명 분리가 스택의 다양한 계층에서 컴포지션 걭을 해결합니다.¹⁴

출처