JFrog Shadow AI Detection, 리포지토리 통제를 넘어 개발자 워크스테이션으로 확장
JFrog는 10월 21일 AI 보안 적용 범위를 확대하며, 에이전트 구성 요소가 리포지토리 통제 밖에서 유입될 수 있는 개발자 워크스테이션을 겨냥했다. JFrog shadow AI detection 업데이트는 보안팀이 반드시 검토했다고 볼 수 없는 로컬 설치 AI 자산을 다룬다. 이 업데이트의 의미는 검사가 이뤄지는 위치, 즉 개발자의 에이전트가 작동하는 장비에 있다.
바르셀로나에서 열린 swampUP Europe에서 발표된 이번 확장은 고객이 제어하는 모델 스캐닝에 워크스테이션 탐색 기능을 더한다. JFrog는 AI security expansion에서 인벤토리, 검사, 시행을 위한 별도의 기능을 설명한다. 이러한 구분은 자산을 발견했다고 해서 조직이 이를 승인했거나 실행을 차단했다는 의미는 아니기 때문에 중요하다.
Snyk와 Palo Alto Networks 역시 에이전트 보안을 겨냥하며, 구매자에게 검토할 수 있는 경쟁 접근 방식을 제공한다. 그러나 핵심적인 긴장은 기업 개발 환경 내부에 있다. 리포지토리 통제는 관리형 배포 시스템으로 유입되는 자산을 관리하지만, 로컬 에이전트 확장은 개발자의 작업 환경으로 들어오는 또 다른 경로를 만든다. JFrog는 이 경로까지 가시성을 확장하고 있으며, 구매자는 가시성이 어떻게 조치로 이어지는지 판단해야 한다.
JFrog Shadow AI Detection, 검사를 워크스테이션으로 옮기다
JFrog에 따르면 워크스테이션 플러그인은 로컬 에이전트 구성 요소를 탐색하고, 결정론적 스캔을 실행하며, 결과를 플랫폼에 보고한다. 결정론적 스캔은 규칙을 일관되게 적용해 동일한 입력에 대해 동일한 결과를 낸다. 회사는 자산 식별 정보, 워크스테이션 존재 여부, 출처 정보, 위험 발견 사항을 담은 중앙 집중식 인벤토리를 설명한다.
이 변화는 로컬 에이전트 자산을 관리형 리포지토리에 들어가기 전에 보안 인벤토리에 포함시킨다.
소프트웨어 리포지토리는 팀이 중앙에서 관리하는 코드나 패키지를 저장한다. 워크스테이션에는 개발자의 AI 어시스턴트 작동 방식에 영향을 미치는 추가 구성 요소가 있을 수 있다. 이러한 구성 요소의 운영상 영향은 개발 중인 애플리케이션에 포함되는지 여부에 달려 있지 않으므로 별도의 주의가 필요하다.
애플리케이션과 이를 만드는 데 쓰이는 도구 사이의 경계를 생각해 보자. 팀은 애플리케이션과 함께 배포되는 모든 종속성을 검사하면서도 어시스턴트의 로컬 지침은 간과할 수 있다. 이러한 지침이 파일 접근 또는 명령 실행에 영향을 준다면, 애플리케이션 스캐닝은 작업 환경의 일부만 포괄한다.
이 구분은 보안팀이 인벤토리화해야 할 대상도 바꾼다. 개발자가 어떤 모델을 사용하는지 묻는 것만으로는 불완전하다. 구매자는 해당 모델의 동작을 형성하는 구성 요소와 그 동작이 발생할 때 이용 가능한 권한도 이해해야 한다.
JFrog의 접근 방식은 이 로컬 정보를 기존 자산 관리 프로세스와 연결할 기회를 만든다. 이미 이 플랫폼을 사용하는 조직에는 연속성이 매력으로 작용한다. 보안팀은 중앙에서 관리되는 구성 요소에 대해 이미 유지하고 있는 정보와 함께 워크스테이션 발견 사항을 평가할 수 있다.
이러한 이점은 탐색 적용 범위에 달려 있다. 인벤토리는 배포된 스캐너가 관찰할 수 있는 대상을 나타낸다. 따라서 구매자는 채워진 대시보드를 배포 기록, 지원되는 구성, 보고가 최신 상태로 유지된다는 증거와 함께 해석해야 한다.
누락된 워크스테이션과 발견 사항이 없다고 보고하는 워크스테이션은 서로 다른 상태다. 이를 혼동하면 인벤토리가 실제 배포 기반이 뒷받침하는 것보다 더 완전해 보일 수 있다. 실질적 가치는 가시성이 시작되고 끝나는 지점을 아는 데서 나온다.
이는 관리되지 않는 자산의 의미도 바꾼다. 익숙하지 않은 로컬 구성 요소는 조사가 필요하지만, 익숙하지 않다는 사실만으로 악의적 의도가 입증되지는 않는다. 유용한 인벤토리는 검토자가 관리 누락과 위험한 행동의 증거를 구분하도록 도와야 한다.
개발자에게 이 구분은 시스템이 유용한 피드백 채널이 되는지에 영향을 준다. 구성 요소를 식별하고, 그 기능을 설명하며, 책임 검토자를 명시하는 발견 사항은 해결을 뒷받침한다. 설명 없는 경고는 어떤 작업을 계속할 수 있는지에 대한 불확실성을 만든다.
따라서 이번 발표는 검사 경계를 확장한다. 운영상 의미는 고객이 발견된 각 구성 요소를 명확한 결정에 연결할 수 있는지에 달려 있다.
보안 및 플랫폼 팀이 승인 문제를 떠안다
워크스테이션 탐색은 어떤 에이전트 기능이 개발 환경에 적합한지 결정하는 사람들에게 부담을 준다.
보안팀은 발견 사항을 평가할 만큼 충분한 정보가 필요하다. 플랫폼 팀에는 개발자가 실제로 이용할 수 있는 승인 경로가 필요하다. 엔지니어링 관리자는 제한이 필수 워크플로를 중단시키는지, 아니면 불필요한 접근을 제거하는지 이해해야 한다.
이러한 책임은 겹치지만 자동으로 같은 담당자에게 귀속되지는 않는다. 구성 요소는 정당한 엔지니어링 작업을 지원하면서도 해당 작업에 필요한 범위보다 넓은 권한을 요청할 수 있다. 이 불일치를 해결하려면 워크플로와 이용 가능한 통제 수단 모두에 대한 지식이 필요하다.
에이전트 스킬은 때로 스크립트를 동반하는 지침 묶음으로, 어시스턴트가 작업을 수행하도록 안내한다. 스킬의 유용성만으로 그 접근 권한이 적절한지는 결정되지 않는다. 중요한 질문은 요청된 작업, 구성 요소의 동작, 개발자 권한 간의 관계에 관한 것이다.
개발자가 동료에게서 유용한 자동화 번들을 받는 상황을 상상해 보자. 이는 문서화된 고객 사고가 아니라 예시를 위한 시나리오다. 이 번들은 프로젝트 변경 사항을 요약하는 데 도움이 되지만, 프로젝트 밖의 파일을 검사할 수 있는 스크립트도 포함한다.
검토자는 여러 판단을 분리해야 한다. 요약 작업은 허용될 수 있고, 스크립트는 수정이 필요할 수 있으며, 공유 프로세스는 등록을 요구할 수 있다. 번들 전체를 단순히 승인 또는 금지로 처리하면 이러한 선택지를 가리게 된다.
이 사례는 JFrog 워크스테이션 보안이 기술적 가시성과 함께 조직적 업무를 만드는 이유를 보여 준다. 탐색은 검토의 출발점을 제공한다. 누군가는 여전히 더 제한적인 버전을 승인하고, 제한 사항을 설명하거나, 기존 대안을 식별할 권한을 가져야 한다.
소규모 기업은 특히 책임 소재를 결정해야 한다. 전담 플랫폼 그룹이 없는 회사도 발견 사항에 대응할 책임자를 지정해야 한다. 스캐너를 구매한다고 해서 익숙하지 않은 구성 요소를 조사하거나 개발자의 요청에 답할 사람이 저절로 정해지지는 않는다.
대규모 조직은 조정 문제에 직면한다. 서로 다른 엔지니어링 그룹은 서로 다른 도구를 사용할 정당한 이유를 가질 수 있다. 중앙 정책은 설명하거나 유지하기 불가능해지지 않으면서 이러한 차이를 고려해야 한다.
개발자 신뢰는 이러한 결정이 얼마나 일관되게 이뤄지는지에도 일부 좌우된다. 유사한 작업을 수행하는 유사한 구성 요소는 이해할 수 있는 방식으로 처리돼야 한다. 특히 통상적인 프로젝트 경계를 넘어선 접근을 허용할 때 예외에는 담당자와 이유가 필요하다.
팀에는 의사결정의 공통 기록도 필요하다. 검색 가능한 지식 기반은 승인 근거, 책임자, 검토 이력을 보존하는 데 도움이 될 수 있다. 이러한 문서는 유사한 질문이 다시 제기될 때 이전 결정을 활용할 수 있게 해 보안 프로세스를 보완한다.
따라서 워크스테이션 가시성이 만드는 부담은 구체적이다. 조직은 일상적인 개발이 불분명한 승인 대기열에 좌우되지 않도록 하면서, 이전에는 비공식적이었던 도구 선택을 검토 가능한 결정으로 전환해야 한다.
로컬 탐색과 모델 기반 검사는 서로 다른 목적을 지닌다
JFrog의 발표는 Bring Your Own LLM Key, 즉 BYOK를 활용한 AI Asset Scanning도 도입한다. 이를 통해 고객은 자체 대규모 언어 모델 계정을 검사에 사용할 수 있다. 회사에 따르면 프롬프트와 스킬은 JFrog 호스팅 게이트웨이 없이 JFrog Platform에서 고객의 모델 엔드포인트로 전달된다.
로컬 탐색과 모델 기반 검사는 서로 다른 질문에 답하므로, 구매자는 그 결과를 별도로 평가해야 한다.
탐색은 존재 여부에 관한 문제다. 스캐너가 지원하는 관점 안에 어떤 구성 요소가 존재하는가? 검사는 해석에 관한 문제다. 구성 요소가 어떤 위험을 초래하는 것으로 보이는가? 대응 프로세스는 또 다른 질문을 더한다. 이 평가 뒤에 무엇을 해야 하는가?
이 단계를 분리하면 제품 주장을 평가하기가 더 쉬워진다. 성공적인 탐색 시연은 테스트된 조건에서 구성 요소가 발견됐음을 입증한다. 그것이 해당 구성 요소의 동작을 완전히 이해했거나 실행이 차단됐음을 입증하지는 않는다.
모델 기반 검토에는 자체적인 평가 필요성이 따른다. 시맨틱 스캐닝은 일반적인 프로그램 코드와 닮지 않은 지침을 포함해 의미를 해석하기 위해 모델을 사용한다. 구매자는 이러한 해석이 실제 업무와 유사한 사례에서 어떻게 작동하는지에 대한 증거가 필요하다.
어시스턴트에게 임시 파일을 제거하도록 정당하게 요청하는 내부 유지보수 지침을 생각해 보자. 문맥에서 분리되면 그 표현은 파괴적인 요청처럼 보일 수 있다. 효과적인 검토는 의도한 디렉터리, 이용 가능한 권한, 주변 워크플로를 고려해야 한다.
반대의 문제도 주목할 필요가 있다. 유해한 지침은 평범한 작업을 완료하는 데 필요한 단계처럼 자신을 포장할 수 있다. 의심스러운 언어를 인식하는 것은 유용하지만, 구매자는 평가가 해당 행동의 실질적 결과를 포착하는지 살펴봐야 한다.
고객 제어형 모델 라우팅은 검사 경로 일부를 누가 관리하는지 바꾼다. 이는 공급자 접근 권한, 보존 설정, 자격 증명, 운영 책임에 관한 질문을 만든다. 고객이 이미 모델 공급자와 관계를 맺고 있더라도 이러한 질문에는 답이 필요하다.
이 방식은 모델 선택을 보안 평가와 관련된 문제로도 만든다. 구매자는 검사 모델을 바꾸면 발견 사항, 설명 또는 검토 결과가 달라지는지 물어야 한다. 보안팀이 시간에 걸쳐 평가를 비교해야 할 때 일관성은 중요하다.
따라서 JFrog 에이전트 스캐닝은 단일 점수가 아니라 일련의 결정으로 평가할 가치가 있다. 팀은 무엇이 발견됐는지, 무엇이 평가됐는지, 그리고 어떤 증거가 발견 사항을 뒷받침하는지 알아야 한다.
이 과정은 결과를 받는 개발자에게도 이해하기 쉬워야 한다. 특정 권한이나 지침과 연결된 설명은 수정의 경로를 제공한다. 근거 세부 정보가 없는 광범위한 경고는 개발자가 필요한 변경 사항을 추측하게 만든다.
아키텍처적 매력은 분명하다. 로컬 증거를 수집하고 이를 중앙 집중식 검토와 연결하는 것이다. 구매 결정은 이 연결이 일상적인 개발 조건에서 얼마나 잘 작동하는지에 달려야 한다.
Snyk와 Palo Alto Networks는 서로 다른 통제 지점을 드러낸다
JFrog는 다른 공급업체들도 AI 에이전트를 둘러싼 구성 요소와 권한을 검사하는 시장에 진입한다. 이러한 경쟁은 구매자에게 유용한 비교 기준을 제공한다. 동시에 개별 통제 지점을 검토하지 않고 포괄적인 에이전트 보안을 광범위하게 주장하는 일은 비교하기 어렵게 만든다.
Snyk의 agent component scanning 문서는 스킬과 Model Context Protocol 서버 같은 구성 요소의 로컬 탐색 및 평가를 설명합니다. MCP는 AI 애플리케이션을 외부 도구 및 데이터와 연결하는 표준 인터페이스입니다. Snyk는 엔터프라이즈 배포를 위한 백그라운드 보고 기능도 문서화하고 있습니다.
이 문서는 주목할 만한 운영 세부 사항을 덧붙입니다. MCP 구성을 검사할 때 서버에 연결하거나 구성된 명령을 실행할 수 있습니다. Snyk는 이러한 상호작용에 대한 동의 동작 및 제한 사항을 설명합니다. 구매자는 배포 요구 사항을 평가할 때 스캐너 결과뿐 아니라 스캐너 활동도 검토해야 합니다.
Palo Alto Networks는 더 폭넓은 에이전트 보안 제품을 제시합니다. 이 회사의 agent security controls는 ID, 권한, 아티팩트 검사 및 실행 중 보호를 강조합니다. 이는 벤더가 설명한 기능이며, 비교 우위의 효과를 입증하는 근거는 아닙니다.
유용한 비교는 각 제품이 에이전트 작업의 어느 지점을 관찰하거나 제어하는지에 관한 것입니다.
로컬 스캐너는 워크스테이션 환경 내의 구성 요소를 검사합니다. ID 제어는 어떤 주체가 액세스 권한을 받는지 다룹니다. 런타임 제어는 활동이 발생하는 동안 이를 검사하거나 제한합니다. 이러한 기능은 서로 다른 근거와 배포 경계를 활용하면서도 동일한 보안 목표를 지원할 수 있습니다.
구매자에게 중요한 것은 중복 기능보다 해결되지 않은 커버리지입니다. 여러 제품이 동일한 구성 요소를 식별하면서도 책임 주체를 불분명하게 남길 수 있습니다. 반대로 제어 지점이 다른 제품은 동일한 워크플로에 대해 상호 보완적인 근거를 제공할 수 있습니다.
적절한 평가는 대표적인 작업에서 시작됩니다. 개발자가 구성 요소를 설치하고, 도구를 연결하며, 구성을 변경한 뒤 에이전트에게 작업 수행을 요청합니다. 그러면 구매자는 어떤 제품이 각 변경 사항을 감지하는지, 그리고 어떤 대응이 가능한지 추적할 수 있습니다.
이 접근 방식은 긴 기능 목록을 운영상 근거의 대체물로 취급하지 않게 합니다. 제품은 탐색, 스캔, 시행을 설명할 수 있지만 각각에 별도의 통합이 필요할 수 있습니다. 구매자는 보안 결과에 대한 책임을 배정하기 전에 이러한 종속성을 이해해야 합니다.
JFrog의 입지는 고객이 로컬 발견 사항과 중앙에서 관리되는 소프트웨어 자산 간의 연결을 중시하는 경우 가장 강합니다. 이는 자사의 탐지 기능이 경쟁사보다 뛰어나다는 주장이 아니라 아키텍처 적합성에 대한 논거입니다.
Snyk는 로컬 구성 요소 평가를 위한 관련 비교 대상입니다. Palo Alto Networks는 ID 및 실행 제어를 위한 참고 사례를 제공합니다. 어느 비교도 모든 환경에서 한 벤더가 다른 벤더를 대체한다는 점을 입증하지는 않습니다.
따라서 JFrog 워크스테이션 보안은 고객의 기존 스택과 구체적인 공백을 기준으로 평가해야 합니다. 핵심 질문은 추가된 워크스테이션 관점이 조직이 이전에는 내릴 수 없었던 의사결정을 가능하게 하는지입니다.
경쟁은 이러한 경계에 관한 더 명확한 근거를 제시한다면 유용할 것입니다. 벤더가 지원 경로, 배포 요구 사항, 대응 동작을 직접 테스트할 수 있을 만큼 정밀하게 설명할 때 구매자는 이점을 얻습니다.
인벤토리가 승인이나 차단을 입증하지는 않는다
JFrog의 제품 블로그에는 구매자가 유지해야 할 한 가지 단서가 담겨 있습니다. 이 글은 조직 정책에 따라 로컬 자산이 허용되는지 확인하는 기능이 향후 릴리스에 계획되어 있다고 설명합니다. 더 광범위한 발표에서는 별도의 플랫폼 기능을 통한 시행을 논의합니다.
따라서 회사의 local detection workflow는 발견된 모든 로컬 자산이 이미 승인 게이트의 적용을 받는다는 주장보다 더 제한적으로 해석할 필요가 있습니다. 고객은 자신들의 특정 배포 환경에서 어떤 검사가 작동하는지 확인해야 합니다.
탐색, 조직 승인, 차단에는 각각 별도의 근거가 필요합니다.
인벤토리 항목은 시스템이 특정 ID 아래에서 무언가를 기록했다는 사실을 보여 줍니다. 승인 결정은 정의된 조건 내에서 누군가가 그 사용을 승인했다는 사실을 보여 줍니다. 차단은 조건이 충족되지 않았을 때 제어 기능이 작업을 중단시켰다는 사실을 뜻합니다.
제품 평가는 한 단계의 근거를 다른 단계의 근거로 대체하지 않아야 합니다. 대시보드에서 구성 요소를 보는 것만으로는 탐색 이전에 무슨 일이 있었는지 알 수 없습니다. 정책 할당을 확인하는 것만으로는 모든 관련 실행 경로가 이를 준수하는지 알 수 없습니다.
위험을 식별하는 것과 공격 성공을 입증하는 것 사이에도 차이가 있습니다. 광범위한 파일 액세스 권한을 가진 구성 요소는 면밀한 검토가 필요합니다. 그러나 그 기능만으로 민감한 자료에 접근했거나 정보를 외부로 전송했다는 사실이 입증되지는 않습니다.
마찬가지로 익숙한 출처는 맥락을 제공하지만 모든 행동 관련 의문을 해소하지는 않습니다. 중앙에서 관리되는 구성 요소도 권한, 구성 또는 의도된 사용 방식이 바뀌면 검토가 필요할 수 있습니다. 출처는 조사를 끝내기보다 의사결정에 정보를 제공해야 합니다.
독립 연구는 지침 자체를 검토할 필요성을 뒷받침합니다. tool poisoning benchmark인 MCPTox는 도구를 설명하는 정보인 도구 메타데이터에 삽입된 악성 지침을 연구합니다. 이 연구는 지침 기반 행동에 대한 우려의 연구적 근거를 제시하지만, JFrog 제품을 평가하지는 않습니다.
위협이 증가한다는 헤드라인 주장에는 이러한 구분이 중요합니다. 구성 요소와 공격 기법의 범위가 확대된다고 해서 성공적인 워크스테이션 침해의 증가가 자동으로 정량화되지는 않습니다. 이 발표는 시장 전반의 사고율을 산정할 근거를 제공하지 않습니다.
커버리지 역시 운영상의 문제로 남습니다. 구매자는 시스템이 변경된 구성 요소, 연결이 끊긴 장비, 지원되지 않는 구성, 누락된 보고서를 어떻게 처리하는지 물어야 합니다. 이러한 질문은 특정 실패를 가정하지 않으면서도 주장된 관점의 한계를 정의합니다.
시점 역시 동등한 주의가 필요합니다. 자산이 사용된 후의 탐색은 조사와 개선 조치를 지원할 수 있습니다. 사용 전에 작동하는 제어 기능은 다른 목적을 수행합니다. 제품 데모는 이 시점을 명확히 보여야 합니다.
개인정보 보호 검토도 같은 평가에 포함되어야 합니다. 로컬 스캔과 메타데이터 보고는 구성 요소 내용 이동에 관한 일부 의문을 줄이지만, 메타데이터는 여전히 내부 활동을 설명할 수 있습니다. 구매자에게는 전송되는 필드와 액세스 제어에 관한 명확한 설명이 필요합니다.
이러한 단서는 워크스테이션 탐색의 가치를 낮추지 않습니다. 대신 조직이 구매하려는 보안 결과와 이를 연결하는 데 필요한 근거를 규정합니다.
배포 커버리지, 정책 제공, 대응 근거를 주시하라
향후 몇 달간 가장 유용한 신호는 운영 제공과 관련된 내용일 것입니다. 더 많은 발견 자산은 활동을 입증하겠지만, 구매자는 탐색이 더 나은 의사결정을 지원하는지 알아야 합니다. 이 발표는 그 관계를 시험할 구체적인 기회를 만듭니다.
배포 커버리지, 문서화된 정책 동작, 대응 근거는 워크스테이션 가시성이 제어 기능으로 얼마나 전환되는지 보여 줄 것입니다.
첫 번째 신호는 실제 개발 환경 전반에서 신뢰할 수 있는 배포가 이루어진다는 근거입니다. 관련 공개 자료는 지원되는 구성, 보고 최신성, 데이터 제공을 중단한 장비를 관리자가 식별하는 방법을 설명해야 합니다. 고객 사례는 그러한 맥락과 함께 제시될 때 더 유용합니다.
배포 사례는 성공 사례만큼이나 경계를 명확하게 설명할 때 설득력을 얻습니다. 구매자는 어떤 워크플로가 포함되었고, 어떤 워크플로에 조정이 필요했으며, 무엇이 배포 범위 밖에 남았는지 이해해야 합니다. 이러한 세부 사항은 실질적인 커버리지에 대한 신뢰를 높일 것입니다.
상당한 수동 조정이 필요하다는 근거는 추가 운영 작업을 시사할 수 있습니다. 이는 탐색의 이점을 없애지는 않지만 인력 배치와 롤아웃에 대한 기대를 바꿀 것입니다. 조직은 이 작업을 제품의 구현 요구 사항 일부로 평가해야 합니다.
두 번째 신호는 명확하게 문서화된 로컬 정책 동작의 제공입니다. JFrog가 계획한 승인 검사는 구매자가 추적할 수 있는 구체적인 기능을 제공합니다. 유용한 문서는 출처 일치, 조직 승인, 구성 요소가 검사를 통과하지 못했을 때 수행되는 조치를 구분해야 합니다.
지원되는 워크플로 전반에서 이러한 단계를 보여 주는 릴리스는 인벤토리와 거버넌스 간의 연결을 강화할 것입니다. 지속적인 모호성은 고객이 별도의 검토 또는 시행 절차에 의존하게 할 것입니다. 어느 결과든 구매 기대에 영향을 주어야 합니다.
세 번째 신호는 현실적인 테스트와 고객 배포에서 나온 대응 근거입니다. 구매자는 위험한 구성 요소가 발견된 뒤 어떤 일이 발생했는지 보여 주는 사례를 찾아야 합니다. 유용한 결과에는 발견 사항, 책임 소유자, 결정, 그리고 의도한 대응이 발생했다는 확인이 포함됩니다.
동일한 작업과 환경을 사용한다면 비교 평가는 도움이 될 것입니다. 통제된 실습은 로컬 구성 요소를 찾는 것, 그 지침을 해석하는 것, 승인되지 않은 작업을 중단하는 것 사이의 차이를 드러낼 수 있습니다. 이러한 결과는 관련 없는 벤더 데모보다 더 많은 정보를 제공합니다.
JFrog 에이전트 스캔은 일상적이고 정당한 작업에 대한 근거도 필요합니다. 보안 워크플로는 검토자가 이미 해결된 문제를 반복해서 다시 열지 않고도 발견 사항을 해결할 수 있게 해야 합니다. 설명되지 않은 결과는 일관되게 조치하기 어렵기 때문에 설명과 검토 기록이 중요합니다.
엔지니어링 리더에게 즉시 필요한 다음 단계는 자사 개발 경로를 중심으로 구성된 데모를 요청하는 것입니다. 승인된 구성 요소, 익숙하지 않은 구성 요소, 변경된 구성 요소, 보고가 불완전한 장비를 포함하십시오. 벤더에게 탐색 시점, 전송되는 정보, 책임 소유권, 가능한 대응을 보여 달라고 요청하십시오. 실습 전반에 걸쳐 위험 발견 사항과 차단된 작업의 차이를 명확히 유지하십시오. JFrog shadow AI detection은 엔터프라이즈 검사의 경계를 개발자의 워크스테이션까지 확장합니다. 그 확장은 이를 통해 가능해지는 의사결정을 기준으로 평가하십시오. 즉, 어떤 구성 요소에 검토가 필요하고, 누가 이를 승인할 수 있으며, 그 행동이 해당 승인을 초과할 때 무슨 일이 발생하는지입니다. 더 완전한 인벤토리를 완결된 보안 결과로 간주하기 전에 데모가 이러한 질문에 답하도록 요구하십시오.
