소프트웨어 공급망 보안 도구들은 공격을 막는 것이 아니라, 공격이 발생하는 것을 지켜보고 있을 뿐이다

주요 내용

• 대부분의 소프트웨어 공급망 보안 도구는 빌드에 이미 포함된 요소가 무엇인지 알려줄 뿐이며, 애초에 해당 요소가 빌드에 포함되는 것을 막아주는 도구는 훨씬 적습니다.
• 이 라벨은 실제로는 서로 전혀 다른 다섯 가지 기능을 포괄하고 있지만, 구매자들은 마치 이 제품들이 똑같은 역할을 하는 것처럼 흔히 비교하곤 합니다.
• 이 둘을 구분 짓는 핵심은 설치 과정에서 어떤 일이 일어나는지가 아니라, 설치 후 대시보드에 어떤 표시가 나타나는지가 아닙니다.
• 샌드박스 테스트에서 나온 두 가지 수치만으로도, 공급업체가 제시하는 그 어떤 기능 매트릭스보다 더 빠르게 최종 후보 목록을 추릴 수 있습니다.

올해 소프트웨어 공급망 보안은 보안 팀의 우선순위 목록에서 급속히 상위로 올라섰으며, 검토 대상 목록은 계속해서 늘어나고 있습니다. 일주일 동안 세 번의 벤더 설명회에 참석하다 보면 데모 내용이 모두 뒤섞여 버리기 일쑤입니다. 여러 벤더, 여러 대시보드에서 모두 똑같이 깔끔하게 정리된 샘플 저장소의 취약한 종속성을 표시해 주지만, 올해 발생한 공격 캠페인 중 어느 것을 막을 수 있었을지 판단할 실질적인 방법은 없습니다.

이는 구매자의 이해 부족 문제가 아닙니다. 카테고리 자체의 문제입니다. 이 도구들은 근본적으로 서로 다른 역할을 수행하면서도 거의 똑같은 마케팅 용어를 사용하고 있으며, 그 차이는 누군가가 시기에 대해 매우 구체적인 질문을 던졌을 때 비로소 드러납니다.

왜 이 카테고리가 갑자기 모든 사람의 관심을 끌고 있는가

애널리스트들의 관심은 지출 추이를 따르며, 지출은 이러한 사건들을 뒤따릅니다. 2026년 3월 말, 일주일 간격으로 널리 사용되는 npm 패키지가 해킹당해 3시간 동안 새로 빌드된 모든 버전에 원격 접속 트로이목마를 은밀히 설치했으며, 또 다른 널리 사용되는 PyPI 패키지는 파이썬이 다음에 시작되는 순간 자격 증명을 탈취하도록 악용되었습니다. 두 경우 모두 사용자의 별도 조작이 필요하지 않았습니다. 두 공격 모두 문제 해결 후 수행되는 스캔이 실질적인 효과를 발휘하기 전에 실행되도록 설계되었습니다. 하나는 설치 중에, 다른 하나는 인터프리터가 다음에 실행될 때 발생했습니다.

이것이 바로 대부분의 소프트웨어 공급망 보안 도구가 메우지 못하는 사각지대이며, 이 분야 제품을 선택하기가 그토록 어려운 이유이기도 합니다. 공급업체들은 기능 설명에는 거의 똑같은 표현을 사용하면서도, 사후 스캔을 수행하는 제품부터 설치 전에 차단하는 제품에 이르기까지 극히 상이한 제어 지점을 기반으로 제품을 판매하고 있습니다.

현실 점검: 이 범주에 속한다고 주장하는 공급업체라고 해서, 그 제품이 바로 옆에 있는 공급업체의 제품과 동일한 문제를 해결한다는 의미는 아닙니다. 중복된다고 가정하기 전에, 해당 제품이 정확히 어떤 제어 지점을 다루는지 물어보십시오.

소프트웨어 공급망 보안 도구는 실제로 어떤 역할을 하는가

이 브랜드명 아래에서는 다섯 가지 서로 다른 기능이 판매되고 있습니다. 이 다섯 가지를 모두 아우르는 제품은 거의 없으며, 대부분의 팀은 결국 여러 가지를 조합하여 사용하게 됩니다.

구성 분석, SBOM, 출처 추적은 비교적 성숙하고 잘 알려진 기능이며, 많은 조직이 이미 이들 중 적어도 일부를 다루는 도구를 보유하고 있습니다. 설치 시점 스크리닝은 2026년 공격이 실제로 발생한 영역이지만, 대부분의 후보 목록에서는 이 기능을 직접 평가하는 데 신경을 쓰지 않는 경우가 많습니다.

지원 종료(EOL) 후 유지보수 이는 2021년에 이미 유지보수를 중단한 의존성이 감사 과정에서 발견되기 전까지는 아무도 신경 쓰지 않는 문제입니다.

탐지와 예방의 차이

거의 모든 팀이 이미 보유하고 있는 기능부터 시작하세요. 이 기능은 탐지가 끝나고 예방이 시작되는 지점을 가장 명확하게 파악할 수 있는 부분이기도 하기 때문입니다. 소프트웨어 구성 분석은 해결된 종속성 목록을 권고 사항 데이터베이스와 대조하여 확인합니다. 이 기능은 해당 업무에 정말 탁월하며, 다른 어떤 제품을 구매하든 간에 반드시 갖추어야 할 가치가 있습니다.

문제는 권고 기반 취약점 탐지가 악성 구성 요소가 식별되고 그 결과가 해당 도구에 반영된 후에야 비로소 작동한다는 점입니다. 그리고 해당 결과가 도구에 반영되려면 누군가가 악성 패키지를 발견하고, 이를 신고하며, 피드에 게시되어야만 합니다. 올해 진행된 공격 캠페인들의 경우, 탐지 속도가 대체로 빨랐으나 권고 처리 과정은 여전히 그 속도를 따라가지 못했습니다. TanStack npm 침해 사건 사건에서 Socket의 스캐너는 는 게시 후 6분 이내에 악성 패키지가 레지스트리에 게시된 지 6분 만에 악성 아티팩트를 탐지했으며, 이 침해 사건은 첫 번째 악성 게시 후 20~26분이 지나서야 공개적으로 보고되었습니다. 이 보고는 영향을 받은 프로젝트의 자체 도구가 아닌 외부 연구원에 의해 이루어졌습니다. 6분은 탐지 속도로는 빠른 편입니다. 하지만 이는 악성 패키지가 레지스트리에 활성 상태로 남아 있어 누구의 빌드에서도 호출될 수 있었던 6분이며, 대부분의 도구가 이를 대조할 수 있는 정보를 확보하기까지는 훨씬 더 오랜 시간이 걸렸습니다.

이제 악성 코드가 실제로 어디에서 실행되는지 생각해 봅시다. npm install 과정에서 npm postinstall 스크립트가 실행되는데, 이는 단순한 이론이 아닙니다. 2026년 3월 31일, 널리 사용되는 Axios 패키지가 해킹당했습니다. . 공격자들은 해킹당한 유지보수자 계정을 이용해 두 개의 악성 버전을 배포했는데, 각 버전에는 ‘plain-crypto-js’라는 악성 종속성이 은밀하게 포함되어 있었습니다. 이 종속성의 postinstall 스크립트는 크로스 플랫폼 원격 액세스 트로이목마(RAT) 드로퍼 역할을 하여, 가동 중인 명령 및 제어(C&C) 서버에서 플랫폼별 페이로드를 가져왔습니다. 해당 기간 동안 새로 설치한 사용자는 import 문이 필요 없이 빌드에 RAT를 바로 포함하게 되었습니다.

.pth 시작 후크를 악용하는 PyPI 패키지는 인터프리터가 다음에 시작될 때 실행되며, LiteLLM 침해 사건이 가장 대표적인 사례입니다. 2026년 3월 24일, PyPI에 등록된 litellm 파이썬 패키지의 두 버전에서 악성 코드가 발견되었는데,. 이는 이미 LiteLLM의 CI/CD 파이프라인에서 사용 중이던 Trivy 보안 스캐너의 해킹된 릴리스로 인해 프로젝트의 PyPI 게시 자격 증명이 노출된 데 따른 결과였습니다. 두 버전 모두 페이로드를 포함하고 있었으며, 특히 두 번째 버전은 한 걸음 더 나아가 Python 인터프리터가 시작될 때마다 자동으로 실행되는 .pth 파일을 설치하여, 명시적인 임포트 없이도 자격 증명 탈취 페이로드를 실행하도록 했습니다.

컴파일 중에 악의적인 build.rs를 포함하는 Rust 크레이트가 실행되는 경우 – 동일한 설계상의 결함이지만, 단지 다른 생태계에서 발생하는 것일 뿐입니다. 두 경우 모두, 악성 코드는 어떤 애플리케이션 로직보다도 먼저 실행됩니다. 즉, 설치 중, 컴파일 중, 또는 런타임이 다음에 자동으로 시작될 때 실행됩니다.

해상도나 설치 상태만 확인하는 스캐너의 경우, 종속성이 도착하는 시점과 실행되는 시점 사이에 유용한 간격이 없습니다. 스캔 자체는 느리지 않습니다. 단지 이벤트의 잘못된 측면에 위치해 있을 뿐입니다.

주의: 벤더의 데모에서 악성 패키지가 탐지 결과 목록에 표시된다면, 방금 보신 것은 탐지 과정이지 예방 과정이 아닙니다. 네트워크 아웃바운드 트래픽을 모니터링한 상태에서 동일한 테스트를 다시 실행해 달라고 요청하고, 해당 탐지 결과가 표시되기 전에 페이로드가 서버로 데이터를 전송했는지 여부를 확인해 달라고 요청하십시오.

해상도 결정 단계에서의 검사는 설치 시점의 실행보다 더 앞선 단계에서 이루어지는 몇 안 되는 제어 수단 중 하나이며, 이것이 바로 SecureChain for OSS의 설계 전제입니다. 패키지는 SLSA 레벨 3 출처 정보를 갖춘 검증된 소스에서 재빌드되고, 서명된 후 사용자가 기존 패키지 관리자나 리포지토리 관리자를 지정하는 단일 레지스트리에 게시되므로, 빌드 에이전트가 패키지를 요청할 때쯤이면 검증 절차는 이미 완료된 상태입니다.

출처 정보만으로는 이러한 격차를 해소할 수 없습니다. 악성 TanStack 버전은 프로젝트 자체의 릴리스 파이프라인을 통해 신뢰할 수 있는 신원 하에 배포되었으며, 이는 유효한 SLSA 출처 정보를 지닌 악성 npm 패키지의 첫 번째 기록된 사례입니다. 출처 정보는 아티팩트가 어디에서 빌드되었는지를 증명할 뿐입니다. 해당 빌드에 사용된 구성 요소가 검증되었는지 여부에 대해서는 아무런 정보를 제공하지 않으므로, 검증된 소스 코드로부터 재빌드하는 것은 동일한 통제 수단이 아니라 별도의 통제 수단으로 간주됩니다.

Snyk, Socket 및 레지스트리 수준 스크리닝 비교

현재 공급망 보안 업체들의 최종 후보 목록에서는 네 가지 주요 아키텍처 접근 방식이 주를 이루고 있습니다. 개별 제품마다 차이가 상당히 크므로, 이를 기능별 검토가 아닌 카테고리 차원의 개요로 이해하시기 바랍니다. 실제 차이점은 기능 체크리스트가 아니라 통제 지점에 있기 때문에, SCA 도구 비교만으로는 그 차이를 파악하기 어렵습니다.

Snyk은 주로 SCA 스캐너 방식에 속합니다. Socket은 행동 기반 패키지 분석과 Socket Firewall을 통한 설치 시점 차단 기능을 결합하는데, Socket Firewall은 패키지 관리자의 트래픽을 프록시하여 악성으로 확인된 패키지가 다운로드되기 전에 차단합니다. Nexus Firewall과 JFrog Curation은 리포지토리 방화벽 방식을 채택하고 있습니다. 선별 및 재빌드된 레지스트리는 상대적으로 작은 분야인데, 이는 레지스트리 규모에서 소스 코드를 기반으로 패키지를 재빌드하는 데는 정책 기반 스크리닝과는 근본적으로 다른 엔지니어링 모델이 필요하기 때문입니다. 바로 이 접근 방식입니다 SecureChain for OSS 는 소스에서 재빌드된 패키지를 기반으로 하며, 업스트림 개발이 중단된 후에도 패치를 적용하고, JavaScript, Python, Java, Go, Rust, PHP 등 6가지 생태계를 단일 레지스트리에서 포괄합니다.

이 네 가지 접근법 중 어느 것도 패키지의 담당자가 사라진 후 어떤 일이 벌어지는지에 대해서는 별다른 언급이 없습니다. 이는 어떤 접근법을 선택하든 그 위에 더해지는 별도의 분야입니다(이에 대해서는 아래에서 더 자세히 다루겠습니다).

그리고 이 네 가지 접근 방식 중 어느 것도 본질적으로 잘못된 답은 아닙니다. 실패의 원인은 같은 접근 방식에 속하는 제품 두 가지를 구매한 뒤, 그 카테고리를 모두 다뤘다고 가정하는 데 있습니다.

전문가 팁: 각 공급업체에 자사가 어떤 접근 방식을 취하고 있다고 생각하는지 물어보세요. 즉시 답변하며 자사의 부족한 점을 스스로 지적하는 업체야말로 두 번째 미팅을 가질 가치가 있는 곳입니다. ‘엔드투엔드(end-to-end)’ 지원이라는 주장을 그대로 믿기보다는, 네 가지 접근 방식 모두에 비추어 검증해 보세요.

2주 만에 실행할 수 있는 평가 프레임워크

공급업체의 데모는 보안 조치가 완료된 샘플 저장소에서 실행되므로, 사실상 아무런 정보도 얻을 수 없습니다. 대신 이 방법을 사용해 보세요.

1주차: 테스트 세트 구축. 실제로 사용하는 생태계를 대상으로 한 2026년 실제 캠페인 세 가지를 선택하세요. 이 세 가지는 네 가지 생태계와 세 가지 서로 다른 메커니즘을 아우릅니다.

• npm 관련 Axios 보안 침해 사건: 2026년 3월 31일, 해킹당한 관리자 계정을 통해 설치 후 실행되는 RAT 드로퍼가 배포됨.
• PyPI에서 발견된 LiteLLM 보안 취약점: 2026년 3월 24일, 인터프리터 시작 시 실행되는 악성 .pth 파일.
• PolinRider npm, Go, Packagist 및 Chrome 확장 프로그램을 가로지르는: 패키지 파일에 숨겨진 악성코드 로더를 이용해 명령 및 제어(C&C) 연결을 구축하고, 인증 정보를 탈취하는 페이로드를 배포하는, 북한과 연계된 활발한 공격 캠페인.

2주차: 두 개의 숫자를 측정해 보세요. 악성으로 확인된 버전은 대개 공개 직후 제거되거나 격리되므로, 현재 테스트 세트에 포함된 정확한 Axios 또는 LiteLLM 페이로드를 설치할 수는 없을 것입니다. 각 벤더에게 안전하게 재현할 수 있는 아티팩트를 제공할 수 있는지 문의하거나, 직접 ‘카나리아(canary)’를 구축해 보세요. 카나리아란, 설치 후 스크립트를 통해 사용자가 제어하는 서버로 신호를 보내는 무해한 패키지를 말합니다. 샌드박스 환경에서 이를 설치하고, 차단까지 걸린 시간과 경고가 발생하기까지 걸린 시간을 기록하세요. 이 두 가지 수치는 벤더가 제공하는 어떤 기능 매트릭스보다 더 빠르게 앞서 언급한 네 가지 접근 방식을 구분해 줍니다.

그 시점부터는 보통 결론이 꽤 명확하게 나옵니다.

• 차단 기능이 전혀 없고, 경보 발령까지 걸리는 시간이 1분 미만이라고요? 이건 탐지 도구입니다. 계속 사용하되, 설치 시점의 제어 수단으로 오해하지는 마세요.
• 패키지가 가져오거나 실행되기 전에 차단되었는데, 활용 가능한 경고 메시지가 없나요? 이는 예방 통제 조치이며, 사고 대응을 위해 가시성 기능을 추가로 구축해야 합니다.
• 두 수치 모두 괜찮아 보이나요? 차단이 어드바이저리 피드에 의존하는지 확인해 보세요. 만약 그렇다면, 보호 창은 해당 피드의 지연 시간만큼만 효과적입니다.
• 공급업체가 샌드박스 테스트를 거부하나요? 그 거절 자체가 바로 답입니다.

범위에 관한 실질적인 참고 사항 하나. 4개 이상의 패키지 생태계를 운영하는 팀의 경우, 특정 생태계의 깊이만큼이나 커버리지의 공백도 중요할 수 있으며, PolinRider 캠페인은 이를 직접적으로 입증해 주는 사례입니다. Socket의 2026년 7월 1일 분석에 따르면, ‘Contagious Interview’ 클러스터와 연계된 북한 해커들은 npm, Go 모듈, Packagist, Chrome 웹 스토어에 걸쳐 108개의 패키지와 브라우저 확장 프로그램에 총 162개의 악성 배포 아티팩트를 게시했으며, 80개의 Go 모듈에서 침해 흔적이 발견되었습니다에서 침해 흔적이 발견되었습니다. 이 캠페인은 여전히 진행 중이며, 그 이후로 총 건수는 더욱 증가했습니다. 침해된 패키지에는 Packagist의 sevenspan 네임스페이스 하에 게시된 PHP 패키지도 포함되었습니다. npm은 포함하되 Go는 포함하지 않는 패키지 수준 통제 수단에 의존하는 팀이라면, 해당 80개의 Go 모듈에 대해서는 이에 상응하는 보호 조치를 취할 수 없었을 것입니다.

최종 후보에 오른 모든 공급업체에게 물어봐야 할 질문들

여섯 가지 질문으로, 대략 정보를 얼마나 많이 드러내는지에 따라 순서를 정했습니다.

1. npm install이나 pip install을 실행할 때, 특히 스캔이 실행되기 전에는 어떤 일이 일어납니까?
2. 해결하기 전에 패키지를 검토하시나요, 아니면 해결한 후에 분석하시나요?
3. 현재 기본적으로 지원하는 생태계는 무엇이며, 향후 계획에 포함된 생태계는 무엇입니까?
4. 패키지를 소스 코드에서 직접 빌드하시나요, 아니면 업스트림에서 공개된 아티팩트를 스캔하시나요?
5. 업스트림에 악성 패키지가 등장한 시점부터 귀사의 제품이 이를 실제로 차단하기까지의 지연 시간 중앙값은 얼마입니까?
6. 우리가 의존하고 있는 패키지를 상류 유지보수자가 더 이상 관리하지 않게 되면, 귀사의 제품은 어떻게 대응하나요?

네 번째 질문은 목록에서 차지하는 순위보다 훨씬 더 중요합니다. 공개된 아티팩트를 스캔하면 그 안에 포함된 악성 코드를 발견할 수는 있지만, 스캐너는 오직 아티팩트 자체만 확인할 수 있기 때문에 해당 아티팩트가 주장하는 소스 코드와 일치하는지 여부를 확인할 수는 없습니다. 신뢰할 수 있는 출처를 가진 검증된 소스 코드를 바탕으로 재컴파일하는 것이야말로 이러한 구체적인 취약점을 해소하는 방법이며, 이는 단순히 체크리스트를 채우는 것이 아니라 실질적인 엔지니어링적 노력이 필요한 작업입니다.

여섯 번째 질문은 평가 당시에는 아무도 묻지 않다가 18개월이 지나면 모두가 묻게 되는 질문입니다. 업스트림에서 더 이상 지원하지 않는 패키지에 대한 패치를 계속하는 일은 새로운 설치물을 선별하는 일과는 별개의 영역이며, 이 두 가지를 동일한 문제로 취급하는 제품은 훨씬 적습니다.

일반적인 프로젝트에서 대부분의 의존성은 직접적인 것이 아니라 전이적인이며, 실제로 선택한 패키지를 통해 간접적으로 도입됩니다. 이것이 의존성 그래프의 대부분을 차지하므로, 평가 시에는 매니페스트의 최상위 수준뿐만 아니라 여러 계층 아래에 있는 각 도구의 동작까지 테스트해야 합니다.

결과는 스택 구성에 따라 크게 달라질 것입니다. CI가 철저히 관리되는 단일 언어 환경의 개발 팀과, 중앙 플랫폼 팀 없이 40개의 리포지토리를 운영하는 다중 언어 조직은 완전히 다른 상황이며, 두 경우 모두에 동일한 권장 사항을 제시하는 벤더는 귀사에 대해 충분히 파악하지 못한 것입니다.

이 상황이 여러분에게 어떤 영향을 미치는지

이 모든 것은 Snyk, Socket, 그리고 레지스트리 방화벽을 사용하는 진영 중에서 어느 쪽이 더 낫다고 가리는 것이 아닙니다. 중요한 것은 자신이 어떤 접근 방식을 채택하고 있는지 파악하고, 어떤 부분이 부족한지에 대해 스스로에게 솔직해지는 것입니다.

많은 조직에서는 이미 성숙한 기능들에 대해 어느 정도 대응 체계를 갖추고 있습니다. 구성 분석, SBOM 도구, 그리고 출처 추적은 이제 충분히 이해되고 있으며, 해당 분야에서 이미 보유하고 있는 자원은 결코 낭비되지 않습니다. 명시적으로 점검할 가치가 있는 통제 수단은 설치 시점 스크리닝으로, 즉 스택 내의 어떤 요소가 위험한 패키지의 코드가 실행되기 전에 이를 차단할 수 있는지 여부를 의미합니다. 이것이 바로 2026년 공격 캠페인이 뚫고 지나간 취약점이며, 아무리 훌륭한 분석 결과로 가득 찬 대시보드라 할지라도 이 간극을 메울 수는 없습니다.

2주간의 테스트를 진행해 보세요. 설치 과정에서 실제 취약점이 발견된다면, 그것이 바로 다음 단계로 자금을 지원해야 할 핵심 지표입니다. OSS용 SecureChain 는 JavaScript, Python, Java, Go, Rust, PHP 등 다양한 언어에서 패키지가 해결되기 전에 이를 검사하며, 업스트림 지원이 종료된 후에도 보안 유지 관리를 지속합니다. 이 중 전반부는 대부분의 후보 목록에서 간과하는 설치 시점의 보안 점검입니다.

SecureChain에 대해 자세히 알아보기 → 

자주 묻는 질문

소프트웨어 공급망 보안 도구란 무엇인가요?

개발, 빌드, 배포 및 운영 단계 전반에 걸쳐 타사 코드를 통해 유입되는 위험을 줄여주는 제품들입니다. 이 범주에는 소프트웨어 구성 분석, SBOM 관리, 출처 검증, 설치 시 검사, EOL 이후 패키지 유지보수 등 일반적으로 하나의 명칭으로 묶여 판매되는 다섯 가지 서로 다른 업무가 포함됩니다.

SCA는 소프트웨어 공급망 보안과 같은 것입니까?

아닙니다(그리고 바로 이 점이 대부분의 SCA 도구 비교에서 간과되는 부분입니다). 소프트웨어 구성 분석은 해당 범주 내의 한 가지 기능에 불과합니다. 이 기능은 해결된 종속성 그래프에서 알려진 취약점이 있는 구성 요소를 표시해 주지만, 그 자체만으로는 새로 유입된 악성 패키지에 대한 설치 시점의 통제 수단이 될 수는 없습니다.

Snyk과 Socket 중 어느 쪽을 선택해야 할까요?

여기서 비교를 위해, Snyk Open Source는 권고 사항 중심의 구성 분석 접근 방식을 대표하는 반면, Socket은 풀 리퀘스트(pull request) 시점의 행동 기반 패키지 분석과 Socket Firewall을 통한 설치 시점 차단 기능을 결합합니다. 두 도구 중 하나를 평가하는 팀은 적용 범위를 가정하기 전에, 해당 도구가 자사의 스택에 정확히 어떤 계층(PR 검토, 설치 시점, 또는 둘 다)에 적용되는지 확인해야 합니다.

소프트웨어 공급망 보안 평가 체크리스트에는 어떤 항목이 포함되어야 할까요?

생태계 커버리지, 제어 지점의 타이밍, 패키지가 소스 코드에서 재빌드되는지 아니면 공개된 아티팩트로만 스캔되는지 여부, 피드 지연 시간, 전이적 의존성 깊이, 그리고 업스트림 유지보수자가 패키지 관리를 그만두면 어떤 일이 발생하는지 등입니다.

공급업체의 카테고리 순위가 어떤 도구를 구매해야 할지 알려주는 걸까요?

이는 애널리스트나 리뷰 사이트가 공급업체들을 공통된 평가 기준에 따라 비교할 수 있을 만큼 표면적인 유사점을 충분히 발견했는지를 알려줄 뿐입니다. 하지만 여러분의 아키텍처에 어떤 제어 지점이 누락되어 있는지는 알려주지 않는데, 사실 여러분이 정말로 답을 찾고자 하는 것은 바로 그 부분입니다.

요약

기사 이름

소프트웨어 공급망 보안 도구와 그 도구들이 놓치고 있는 부분

설명

대부분의 소프트웨어 공급망 보안 도구는 설치 후 공격을 탐지합니다. 네 가지 접근 방식을 비교해 보고, 최종 후보 목록에 오른 도구들을 2주 이내에 테스트해 보십시오.

작성자

아르템 카라세프

게시자 이름

TuxCare

게시자 로고