공급망 보안에 관한 간단한 이야기## Intro 우리는 매일 무언가를 설치하고, 빌드하고, 배포합니다. npm/pip install, go get, cargo add와 같은 명령은 너무 익숙하며, 필요한 패키지를 찾고, 설치하고, 사용하는 것은 숨 쉬듯 자연스럽습니다. 그런데 2026년 3월 말, JavaScript 생태계에서 널리 쓰이는 HTTP 클라이언트 axios의 npm 패키지가 악성 버전으로 게시됐다는 다소 충격적인 소식이 나왔습니다. Microsoft Threat Intelligence는 2026년 3월 31일 `axios@1.14.1`과 `axios@0.30.4`가 악성 의존성을 포함한 버전으로 식별됐고, 해당 의존성이 C2에서 OS별 2단계 RAT payload를 내려받는 구조였다고 분석했습니다. GitLab Advisory도 두 버전이 침해된 maintainer 계정으로 게시됐고 `plain-crypto-js@4.2.1`을 통해 cross-platform RAT를 배포했다고 정리했습니다. 제게 충격을 주었던 이유는 "axios 코드 어딘가에 평범한 취약점이 있었다"는 익숙한 이야기가 아니었기 때문입니다. Datadog Security Labs 분석에 따르면 악성 `axios@1.14.1`의 핵심 변화는 axios 소스 로직이 아니라 `package.json`에 추가된 `plain-crypto-js` 의존성이었습니다. 정상적인 패키지 이름, 정상처럼 보이는 patch release, 평소처럼 실행한 설치 명령 사이에서 신뢰가 무너진 것입니다. 그래서 이 사건이 던지는 질문은 "axios를 어느 버전으로 내려야 하는가"에서 끝나지 않습니다. 더 중요한 질문은 이것입니다. > 우리가 매일 설치하고, 빌드하고, 배포하는 소프트웨어는 정말 우리가 생각하는 그 소프트웨어가 맞을까? ## What We Trust \-패키지 이름이 올바르다. \-레지스트리가 올바른 파일을 내려준다. \-lockfile이 있으면 의존성 트리가 재현될 것이다. \-GitHub Actions가 만든 산출물이 소스 코드와 일치한다. \-릴리스 태그가 있으면 정상 절차를 거쳤다고 믿고, 서명된 업데이트라면 안전하다. 겉보기에는 너무나 당연한 이야기들이지만, 공급망 공격은 이 믿음 사이를 파고듭니다. 공격자는 최종 애플리케이션의 취약점을 직접 찾아낼 필요 없이, '최종 애플리케이션이 신뢰하는 것'을 오염시키면 됩니다. 의존성 패키지, maintainer 계정, 빌드 파이프라인, 패키지 레지스트리, 업데이트 채널, 설치 스크립트, 배포 artifact가 모두 공격 표면이 될 수 있습니다. NIST SP 800-161 Rev. 1은 공급망 위험을 조직이 획득하는 제품과 서비스가 악성 기능을 포함하거나, 위조됐거나, 개발·제조 관행의 문제로 취약해질 수 있는 위험으로 다룹니다. NIST SP 800-204D도 소프트웨어 공급망을 단순한 라이브러리 목록이 아니라 source code가 build, test, package, deploy 단계를 거쳐 새 버전의 소프트웨어가 되는 CI/CD 활동 전체로 설명합니다. 결국 공급망 공격의 핵심은 "악성 코드가 어디에 숨어 있었는가"만이 아닙니다. 더 근본적인 질문은 “악성 코드가 어떻게 정상적인 것으로 받아들여졌는가”입니다. ## Attack Surface 소프트웨어 공급망 공격은 최종 시스템을 직접 공격하기보다, 그 **시스템이 굳게 믿고 있는 신뢰 경로**를 파고듭니다. | 공격 표면 | 대표 예시 | 핵심 리스크 | | --- | --- | --- | | 의존성 패키지 | npm, PyPI, Maven, Go module | 악성 패키지가 정상 의존성처럼 위장해 설치됨 | | maintainer 계정 | npm owner, PyPI maintainer, GitHub 권한 | 정상 권한으로 악성 버전이 publish됨 | | CI/CD 파이프라인 | GitHub Actions, GitLab CI, Jenkins | secret 유출, artifact 오염, 릴리스 권한 탈취 | | 패키지 레지스트리 | npm registry, PyPI, container registry, 내부 mirror | Git 저장소의 소스와 다른 산출물이 배포됨 | | 업데이트 채널·설치 스크립트 | signed installer, auto updater, post install, [setup.py](http://setup.py) | 설치 또는 업데이트 순간 임의 코드가 실행됨 | | 런타임 환경 | egress, shell execution, credential access | C2 통신, secret 유출, lateral movement로 이어짐 | 이 공격들의 무서운 공통점은 모든 것이 너무나 정상적인 절차처럼 보인다는 점입니다. 개발자는 평소처럼 설치하고, CI는 평소처럼 빌드하고, 배포 시스템은 평소처럼 artifact를 배포합니다. 그런데 그 평범한 경로 중 하나만 오염되어 있어도 악성 코드는 자연스럽게 흘러갑니다. ## Case Study 공급망 공격은 새로운 개념은 아니지만, 최근 사건들은 공격자가 어디를 노리는지 더 선명하게 보여줍니다. 먼저 전체 흐름을 표로 잡고, 그다음 각 사건의 의미를 짧게 보겠습니다. | 연도 | 사건 | 공격자가 노린 신뢰 경로 | 핵심 교훈 | | --- | --- | --- | --- | | 2021 | Kaseya VSA | 원격 관리·배포 도구 | 관리 도구는 대규모 배포 권한이므로 침해 시 고객사로 피해가 확산됨 | | 2022 | PyTorch nightly `torchtriton` | 패키지 이름과 registry 우선순위 | namespace와 dependency resolution 정책도 보안 경계임 | | 2023 | 3CX DesktopApp | 서명된 업데이트 채널 | 서명된 업데이트도 생성 환경과 배포 경로 검증이 필요함 | | 2024 | XZ Utils | release tarball·배포 산출물 | Git 저장소와 실제 설치 artifact는 다를 수 있음 | | 2025 | `tj-actions/changed-files` | third-party GitHub Action | 작은 CI 도구도 secret과 token을 볼 수 있음 | | 2026 | axios npm compromise | npm registry와 publish 계정 | GitHub 저장소가 멀쩡해도 registry 패키지는 오염될 수 있음 | ### #1. Kaseya VSA — Management Tools as Attack Path (2021) Kaseya VSA 랜섬웨어 사건은 원격 관리·배포 도구가 얼마나 위험한 신뢰 경계가 될 수 있는지 보여줬습니다. CISA는 2021년 7월 Kaseya VSA를 사용하는 여러 MSP를 대상으로 한 supply-chain ransomware attack을 공지했습니다. 관리 도구가 침해되면 단일 서버를 넘어, MSP를 통해 연결된 고객사로 피해가 연쇄 확산될 수 있습니다. ### #2. PyTorch Nightly — Name and Index Priority (2022) 이 사건은 **dependency confusion**, 즉 의존성 혼동의 전형적인 사례입니다. PyTorch Foundation은 2022년 12월 25일부터 30일 사이 Linux에서 pip로 PyTorch-nightly를 설치한 경우 `torchtriton` 의존성이 PyPI의 악성 패키지로 대체될 수 있었다고 공지했습니다. 내부 nightly index에서 가져와야 할 이름이 공개 PyPI에도 존재했고, 공개 인덱스가 우선 적용된 것이 핵심이었습니다. 패키지 이름, namespace, registry 우선순위는 단순한 설정값이 아닙니다. 이 경계가 흔들리면 정상 설치 절차가 그대로 공격 경로가 됩니다. ### #3. 3CX — Signed Updates Need Verification (2023) 3CX DesktopApp 사건은 서명된 데스크톱 애플리케이션 업데이트가 오염된 사례입니다. Mandiant는 이 침해가 이전의 또 다른 소프트웨어 공급망 침해에서 시작됐다고 분석했습니다. 3CX 내부 환경이 먼저 오염된 소프트웨어를 통해 감염되고, 그 결과 3CX의 고객에게 다시 오염된 앱이 전달된 구조였습니다. **서명된 업데이트**라는 사실은 중요하지만 충분하지 않습니다. 그 업데이트가 어떤 환경에서 만들어졌고, 어떤 workflow를 거쳐 나왔고, 실행 후 어떤 동작을 하는지까지 함께 봐야 합니다. ### #4. XZ Utils — Clean Repo, Different Artifact (2024) XZ Utils backdoor 사건은 소스 저장소를 눈으로 확인하는 것과 실제 배포되는 패키지를 검증하는 것이 완전히 다를 수 있음을 강하게 드러냈습니다. OpenSSF는 CVE-2024-3094가 xz package의 backdoor를 다루며, 문제 버전은 5.6.0과 5.6.1이라고 정리했습니다. 우리가 최종적으로 설치하는 것은 웹페이지의 코드가 아니라 빌드 절차를 거친 **release artifact**입니다. 따라서 재현 가능한 빌드, provenance, tarball 검증, 배포 산출물 비교의 중요성이 더 커졌습니다. ### #5. tj-actions/changed-files — Small CI Tools See Secrets (2025) 2025년 3월에는 GitHub Actions 생태계에서도 중요한 공급망 공격이 발생했습니다. NVD의 CVE-2025-30066 설명에 따르면 `tj-actions/changed-files`의 v1부터 v45.0.7까지 태그가 2025년 3월 14일부터 15일 사이 악성 commit `0e58ed8`을 가리키도록 변경되었고, 이로 인해 Actions 로그를 통해 secret이 노출될 수 있었습니다. StepSecurity도 이 Action이 CI/CD secret을 public build log에 노출할 수 있는 위험을 만들었다고 분석했습니다. 핵심은 `uses: owner/repo@v1` 같은 표현이 생각보다 약한 신뢰 경계라는 점입니다. 태그는 이동할 수 있고, third-party Action은 runner 안에서 코드로 실행되며, job에 주어진 secret과 `GITHUB_TOKEN` 권한을 함께 볼 수 있습니다. GitHub 문서가 third-party action을 full-length commit SHA로 pinning하라고 권고하는 이유입니다. 다만 SHA pinning만으로 끝나는 문제는 아닙니다. workflow 권한을 최소화하고, 외부 PR 검증 job과 release/publish job을 분리하고, secret이 필요한 job에서 실행되는 Action을 엄격히 관리해야 합니다. ### #6. axios — Registry Compromise Alone (2026) 다시 axios로 돌아오면, 이 사건은 “GitHub 저장소가 멀쩡해도 npm 패키지는 오염될 수 있는가”라는 질문에 대한 실제 사례입니다. Microsoft는 2026년 3월 31일 악성 axios 버전 `1.14.1`과 `0.30.4`가 확인됐고, 두 버전이 `plain-crypto-js@4.2.1`을 통해 install-time code execution과 C2 기반 2단계 RAT 배포를 수행했다고 분석했습니다. Datadog은 `axios@1.14.0`이 GitHub Actions OIDC trusted publishing으로 게시된 반면, 악성 `1.14.1`은 compromised account에서 직접 게시되어 trusted publisher metadata가 없었다고 설명했습니다. GitLab Advisory도 영향을 받은 버전과 안전한 downgrade 대상 버전(`1.14.0`, `0.30.3`)을 정리했습니다. 이 사건에서 중요한 것은 특정 버전이 악성이었다는 사실만이 아니라, 다음과 같습니다: \-소스 저장소와 패키지 레지스트리는 같은 것이 아닙니다. \-정상 계정으로 게시된 악성 버전은 단순한 “공식 패키지” 신뢰로 막기 어렵습니다. \-patch release에 갑자기 신규 runtime dependency가 추가되는 것은 강한 이상 신호입니다. \-publish 주체, provenance, Git tag, trusted publishing 여부 같은 metadata가 중요한 보안 신호가 됩니다. ## Vulnerable Code, Vulnerable Trust 전통적인 보안 사고방식에서는 취약점이 코드 안에 있다고 생각하기 쉽습니다. 입력 검증 실패, 인증 우회, SSRF, XSS, 메모리 오류 같은 것들입니다. 물론 여전히 중요합니다. 하지만 공급망 공격에서는 취약점이 코드 한 줄이 아니라 절차와 신뢰 구조 안에 있을 수 있습니다. \-패키지 이름이 비슷해서 잘못된 패키지를 설치합니다. \-내부 패키지와 같은 이름의 공개 패키지가 더 높은 우선순위로 resolve됩니다. \-maintainer 계정이 탈취되어 정상 권한으로 악성 버전이 게시됩니다. \-CI secret이 노출되어 공격자가 release workflow를 실행합니다. \-Git tag는 정상인데 registry에 올라간 artifact는 다릅니다. \-install script가 설치 시점에 외부 payload를 내려받습니다. \-빌드 runner가 외부로 secret을 전송합니다. 이 경우 문제는 "우리 애플리케이션 코드에 버그가 있느냐"만으로 설명되지 않습니다. 더 근본적인 문제는 우리가 너무 많은 것을 한 번에, 오래, 암묵적으로 신뢰하고 있다는 점입니다. 현대 공급망 보안의 핵심은 신뢰를 없애는 것이 아닙니다. 이는 현실적으로 불가능합니다. 대신 신뢰를 짧게 만들고, 단계마다 증거를 요구하고, 검증을 자동화해야 합니다. ## Beyond SCA and SBOM 공급망 보안을 이야기하면 Software Composition Analysis, 즉 SCA가 먼저 떠오릅니다. SCA는 프로젝트가 사용하는 오픈소스 구성요소와 알려진 취약점을 분석하는 데 유용합니다. 알려진 CVE, 라이선스 리스크, 취약 버전 업데이트를 관리하는 데 꼭 필요합니다. 하지만 SCA가 주로 묻는 질문은 이것입니다. > 이 버전에 알려진 취약점이 있는가? 공급망 공격에서는 다른 질문도 필요합니다. \-이 버전은 정상 절차로 게시되었는가? \-이 artifact는 우리가 신뢰하는 workflow에서 만들어졌는가? \-이 패키지에 갑자기 새로운 runtime dependency가 추가되지는 않았는가? \-이 패키지는 설치 중 어떤 코드를 실행하는가? \-실행 후 예상하지 못한 외부 통신을 하지는 않는가? SBOM도 마찬가지입니다. SBOM은 무엇이 들어 있는지 보여주는 inventory입니다. CISA와 NTIA 계열 자료에서 SBOM은 구성요소 가시성을 높이는 핵심 수단으로 다뤄지지만, SBOM 자체가 안전성을 판정해주지는 않습니다. | 항목 | 답하는 질문 | 한계 | | --- | --- | --- | | SCA | 이 구성요소에 알려진 취약점이 있는가? | 새로 게시된 악성 정상 버전이나 계정 탈취는 놓칠 수 있음 | | SBOM | 무엇이 들어 있는가? | 목록일 뿐, 안전성을 판정하지는 않음 | | VEX | 해당 취약점이 실제 제품에 영향을 주는가? | 정확한 제품 맥락과 운영 프로세스가 필요함 | | provenance | 누가, 어떤 절차로 만들었는가? | 검증 정책과 배포 단계의 enforcement가 필요함 | | attestation | 그 주장을 검증 가능한 형태로 남겼는가? | 서명·정책 검증 없이 보관만 하면 효과가 제한됨 | | runtime monitoring | 실행 후 실제로 무엇을 했는가? | 사전 차단보다 탐지·대응에 가까움 | 공급망 보안은 이 질문들을 함께 묶어야 합니다. 하나의 도구가 모든 신뢰 문제를 해결해주지는 않습니다. ## A Zero Trust Lens 제로트러스트는 단순히 “내부 네트워크도 믿지 말자”는 구호가 아닙니다. NIST SP 800-207은 zero trust를 정적 네트워크 경계가 아니라 사용자, 자산, 리소스 중심으로 방어를 옮기는 보안 패러다임으로 설명합니다. 또한 네트워크 위치나 자산 소유 여부만으로 암묵적 신뢰를 부여하지 않는다고 설명합니다. 이를 소프트웨어 공급망에 적용하면 다음과 같습니다. | 제로트러스트 원칙 | 공급망 보안에서의 적용 | | --- | --- | | 명시적 검증 | 의존성, artifact, publish 주체, provenance, attestation을 단계마다 확인합니다. | | 최소 권한 | CI token, registry token, cloud role, runner 권한을 필요한 만큼만 부여하고 job 단위로 통제합니다. | | 침해 가정 | maintainer 계정, build runner, registry, update channel이 언제든 침해될 수 있다고 보고 방어 로직을 설계합니다. | | 지속적 모니터링 | publish metadata 변화, 갑작스러운 dependency 추가, install-time behavior, runtime egress를 계속 관찰합니다. | 이 관점에서 “사내 CI니까 괜찮다”, “공식 npm 패키지니까 괜찮다”, “GitHub release가 있으니까 괜찮다”는 암묵적 믿음은 더 이상 충분하지 않습니다. CI도 검증해야 합니다. 레지스트리도 검증해야 합니다. 릴리스 artifact도 검증해야 합니다. 설치 후 동작도 검증해야 합니다. 공급망 보안에서 제로트러스트는 이렇게 요약할 수 있습니다. "신뢰를 짧게 만들고, 증거를 붙이고, 검증을 자동화한다." ## Where to Start 공급망 보안은 범위가 넓습니다. 모든 통제를 한 번에 도입하기는 어렵습니다. 대신 우선순위를 나누어 적용하는 것이 현실적입니다. ### P0 — Basic Controls Now \-lockfile과 재현 가능한 설치를 강제합니다. 의존성 트리 drift를 줄이고 CI 설치 결과를 예측 가능하게 만들어야 합니다. \-PR 단계에서 dependency diff를 검토합니다. 신규 직접·전이 의존성, 알려진 취약점, 라이선스, runtime dependency 변화를 merge 전에 확인해야 합니다. \-신규 릴리스 쿨다운을 적용합니다. 방금 게시된 버전이 탐지·철회되기 전 자동으로 설치되는 위험을 줄이기 위한 장치입니다. npm의 `min-release-age`, Dependabot의 `cooldown`, Renovate의 `minimumReleaseAge`처럼 release-age gate를 CI와 업데이트 봇 정책에 맞추는 방식입니다. \-장기 publish token을 줄이고 OIDC를 사용합니다. long-lived token 탈취 위험을 줄이고, 특정 workflow와 환경에서만 권한을 부여해야 합니다. \-GitHub Actions 권한을 최소화하고 SHA pinning을 적용합니다. 움직일 수 있는 tag와 과도한 `GITHUB_TOKEN` 권한에 의존하지 않도록 해야 합니다. \-artifact provenance와 attestation을 남깁니다. “CI가 성공했다”가 아니라 “기대한 빌드 경로에서 나온 artifact다”를 검증할 수 있어야 합니다. ### P1 — Operational Maturity \-SBOM과 VEX를 함께 운영합니다. SBOM은 구성요소 목록을 제공하고, VEX는 특정 취약점이 실제 제품에 영향을 주는지 판단하는 데 도움을 줍니다. \-self-hosted runner를 격리합니다. untrusted PR을 실행하는 runner와 secret을 가진 release/publish runner는 분리해야 합니다. \-registry와 publish metadata를 모니터링합니다. 평소와 다른 publish 주체, trusted publishing 부재, Git tag 없는 registry-only 버전, patch release의 신규 runtime dependency는 모두 이상 신호가 될 수 있습니다. \-설치와 런타임의 외부 통신을 관찰합니다. 가능하면 deny-by-default egress allowlist를 적용하고, 최소한 비정상 도메인 접근, shell 실행, downloader 실행 같은 행위는 탐지해야 합니다. ### P2 — Long-Term Maturity \-SLSA 기반으로 빌드 성숙도를 높입니다. 핵심은 build provenance, tamper resistance, build integrity를 단계적으로 높이는 것입니다. \-공급자 보안 평가를 조달 기준에 포함합니다. SBOM 제공 여부, 취약점 공지 절차, secure development practice, release provenance, 로그 제공 범위, incident response 협력 수준을 함께 확인해야 합니다. \-metadata 기반 이상 탐지를 자동화합니다. 패키지 publish 이벤트, maintainer 변경, 신규 의존성, provenance 부재, Git tag 불일치 같은 metadata를 SIEM 또는 내부 모니터링에 연결하면 더 빨리 발견할 수 있습니다. ## Team Checklist ### Dependency Management \-lockfile을 저장소에 커밋하고 있는가? \-CI에서 `npm ci`, `pip --require-hashes`, `go mod verify` 등 재현 가능한 설치 방식을 사용하는가? \-PR에서 dependency diff를 검토하는가? \-patch/minor release에서 신규 runtime dependency가 추가될 때 별도 승인을 요구하는가? \-신규 릴리스가 즉시 설치되지 않도록 패키지 매니저와 업데이트 봇에 쿨다운을 적용하는가? \-내부 패키지 namespace가 공개 registry와 충돌하지 않도록 관리되는가? ### CI/CD \-workflow별 token 권한이 최소화되어 있는가? \-third-party GitHub Actions를 full-length commit SHA로 pinning하고 있는가? \-release/publish job과 PR validation job이 분리되어 있는가? \-self-hosted runner가 untrusted PR을 실행하지 않도록 격리되어 있는가? \-cloud deploy에 장기 secret 대신 OIDC를 사용하는가? ### Package Publishing and Registries \-npm trusted publishing 등 OIDC 기반 publish를 사용하는가? \-장기 publish token을 제거했거나 만료·범위를 제한했는가? \-`private: true`, `publishConfig.registry`, scope registry 정책을 사용하는가? \-registry signature 또는 provenance 검증을 수행하는가? \-publish 주체와 metadata drift를 모니터링하는가? ### Artifacts and Deployment \-build artifact에 provenance 또는 attestation이 있는가? \-배포 전에 artifact attestation을 검증하는가? \-SBOM을 생성하고 artifact와 함께 보관하는가? \-VEX 또는 유사한 영향 판정 체계를 운영하는가? ### Runtime \-빌드 runner와 애플리케이션의 outbound traffic을 관찰하는가? \-egress deny-by-default 또는 allowlist 정책을 적용할 수 있는가? \-설치 중 shell, curl, wget, PowerShell 실행 같은 이상 행동을 탐지하는가? \-공급망 incident 발생 시 secret rotation과 runner 포렌식 절차가 준비되어 있는가? ## Closing "axios compromised on npm"이라는 문장은 한 라이브러리의 사고 소식으로만 읽히지 않았습니다. 그것은 우리가 매일 당연하게 신뢰하던 개발 과정 전체를 다시 보게 만드는 문장이었습니다. 공급망 공격의 위험은 정상 경로를 이용한다는 점에 있습니다. 공격자는 악성 코드를 몰래 심어도 그것이 정상 업데이트, 정상 패키지, 정상 릴리스처럼 보이게 만들 수 있습니다. 그래서 공급망 공격은 탐지와 대응이 어렵고, 한 번 성공하면 사용자와 고객에게 넓게 확산될 수 있습니다. 이제 공급망 보안은 “어떤 패키지가 취약한가”만 묻는 문제를 넘어섭니다. 이 패키지가 어디서 왔는지, 누가 게시했는지, 어떤 workflow에서 만들어졌는지, 릴리스 metadata가 평소와 일치하는지, 설치와 실행 중 어떤 동작을 하는지까지 함께 봐야 합니다. 현대적인 공급망 보안은 SCA, SBOM, provenance, CI/CD hardening, runtime monitoring의 결합으로 가야 합니다. 그리고 그 방향은 제로트러스트 원칙과 맞닿아 있습니다. 신뢰를 없애는 것이 아니라, 신뢰를 짧게 만들고, 증거를 붙이고, 자동으로 검증하는 것. 이것이 현대 소프트웨어 공급망 보안의 현실적인 출발점입니다. ## References NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations: NIST SP 800-204D, Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines: NIST SP 800-207, Zero Trust Architecture: CISA, Kaseya VSA Supply-Chain Ransomware Attack: PyTorch Foundation, Compromised PyTorch-nightly dependency chain between December 25th and December 30th, 2022: Mandiant / Google Cloud, 3CX Software Supply Chain Compromise Initiated by a Prior Software Supply Chain Compromise: OpenSSF, xz Backdoor CVE-2024-3094: NVD, CVE-2025-30066: StepSecurity, tj-actions/changed-files action is compromised: GitHub Docs, Security hardening for GitHub Actions: GitHub Docs, Artifact attestations: npm Docs, Trusted publishing for npm packages: npm Docs, About ECDSA registry signatures: npm Docs, npm ci: npm Docs, min-release-age config: GitHub Docs, Dependabot cooldown options: Renovate Docs, Minimum Release Age: CISA, Software Bill of Materials (SBOM): NTIA, The Minimum Elements For a Software Bill of Materials (SBOM): OpenSSF, SLSA: Microsoft Security Blog, Mitigating the Axios npm supply chain compromise: GitLab Advisory Database, GHSA-fw8c-xr5c-95f9: Datadog Security Labs, Compromised axios npm package delivers cross-platform RAT: