Wiz Black October 보고서, AI 플랫폼 보안 사고 9건 추적

Wiz는 10월에 공개된 최소 9건의 보안 공지를 AI 개발자 플랫폼과 고객이 이들에 맡긴 자격 증명에 관한 경고로 묶었다. 10월 30일 공개된 Wiz Black October 보고서는 Fireworks AI, Lightning AI, Railway, Warp, OpenCode 및 기타 서비스와 관련된 사고를 연결한다. 실질적인 긴장은 분명하다. 개발을 단순화하는 플랫폼은 공격자가 침해된 공급업체 너머의 서비스에 접근할 수 있는 경로를 찾는 장소가 되기도 한다.

공개된 내용은 서로 다른 진입점과 영향을 받은 각기 다른 시스템을 설명한다. 모든 사고가 하나의 조직적인 캠페인에 속한다는 점을 입증하지는 않는다. 이 플랫폼들이 개발자, 애플리케이션, 상류 AI 제공업체 사이에서 차지하는 위치가 이들을 공통으로 중요하게 만든다.

고객이 받는 압박은 코딩 어시스턴트나 배포 서비스를 선택하는 데 그치지 않는다. 플랫폼은 팀이 제공업체 자격 증명을 모든 팀원에게 노출하지 않고 사용할 수 있도록 도울 수 있다. 그러나 그러한 편의성은 중요한 질문을 남긴다. 누군가 자격 증명을 보관하는 시스템을 침해하면 어떻게 되는가?

Wiz Black October 보고서가 실제로 입증하는 것

가장 명확한 발견은 단일 공격자나 공통 취약점의 증명이 아니라, 공지의 집중이다.

Wiz 연구원 Benjamin Read와 Rami McCarthy는 Fireworks AI, Andromeda, Zeabur, Lightning AI, OpenCode, Railway, Warp, CommandCode, Northflank를 열거한다. 이들의 AI 플랫폼 사고 정리는 애플리케이션이 구성 정보와 비밀값을 받는 데 사용하는 설정인 자격 증명과 환경 변수에 반복적인 관심이 있음을 지적한다.

이 구분은 공지 일정이 공격 타임라인은 아니라는 점에서 중요하다. 기업은 업데이트를 공개하기 전에 무단 활동을 발견할 수 있다. 추가 기록을 검토한 뒤 영향을 받은 범위를 수정할 수도 있다. 나열된 모든 날짜를 침해가 발생한 시점으로 간주하면 잘못된 순서가 만들어진다.

Fireworks는 구체적인 사례를 제공한다. 공지에 따르면 이 회사는 10월 6일 내부 자격 증명의 무단 사용을 파악했으며, 이후 영향을 받은 고객에게 알렸다. 초기 활동은 제한된 계정 그룹의 평가 작업과 연결된 환경 변수를 포함했다.

자격 증명 노출 공지에 따르면, Fireworks는 고객 모델, 데이터세트, 학습 데이터, 개인정보 또는 추론 트래픽에 대한 무단 접근을 탐지하지 못했다. 이 진술은 명시된 범위와 통제 내에서 당시 조사 결과를 설명한다.

회사는 영향을 받은 고객에게 발급 제공업체를 통해 타사 자격 증명을 교체하라고도 안내했다. 이는 공지에서 중요한 경계다. Fireworks 자격 증명과 Fireworks 내부에 저장된 자격 증명은 서로 다른 시스템에 대한 접근을 승인할 수 있다.

따라서 사고들을 함께 해석하려면 각 공급업체가 실제로 무엇을 보유하는지에 주의를 기울여야 한다. 배포 플랫폼, 호스팅된 코딩 콘솔, 개발 작업공간은 동일한 자산을 노출하지 않는다. 고객의 사용 방식도 다르다.

“AI 개발자 플랫폼”이라는 범주는 활동의 집중을 이해하는 데 유용하다. 그러나 제품, 저장 방식, 고객 책임의 차이를 지워버리면 유용성이 떨어진다.

따라서 이 보고서는 연결된 접근 권한을 점검해야 할 이유로 읽어야 한다. 명시된 모든 공급업체의 모든 고객이 동등한 피해를 입었다고 가정할 신뢰할 만한 근거는 아니다.

그러한 좁은 해석도 여전히 중요하다. 개발자는 영향을 받은 서비스에 저장된 자격 증명을 걱정하기 위해 조직적인 캠페인의 증거가 필요하지 않다. 즉각적인 노출은 해당 자격 증명의 권한과 계속된 유효성에 달려 있다.

핵심 변화는 개발자가 업무를 연결하는 데 사용하는 시스템 주변에서 구체적인 공지가 누적된 점이다. 해결되지 않은 질문은 그러한 연결이 각 사고의 영향을 어디까지 확장했는지다.

침해된 플랫폼 너머에서 고객에게 가해지는 압박

공급업체가 자체 사고를 수습하더라도 고객은 다른 곳의 접근 권한을 닫아야 할 수 있다.

Lightning AI는 이 문제의 운영 측면을 보여준다. 회사는 10월 15일 무단 자격 증명 접근을 확인했고, 10월 16일 이른 시점에 사용자 플랫폼 접근을 취소했다고 밝혔다.

플랫폼 사고 업데이트는 영향을 받은 Studio Platform 서비스와 GPU 클러스터 대여 인프라 및 관리형 서비스를 구분한다. 10월 28일 업데이트에서는 읽기 전용 Drive 접근이 복구됐으며, 다른 서비스도 뒤따를 것이라고 보고했다.

Lightning은 저장된 비밀값을 교체하고 연결된 타사 서비스를 검토할 것을 권고했다. 이러한 안내는 사고 복구를 공급업체의 로그인 페이지가 다시 작동하는지 여부만으로 측정할 수 없는 이유를 보여준다.

가용성과 자격 증명 유효성은 별개의 문제다. 작업공간을 복구하면 고객이 업무를 재개하는 데 도움이 된다. 노출된 자격 증명을 취소하는 일은 복사본을 가진 사람이 해당 자격 증명이 승인하는 서비스를 계속 이용할 수 있는지를 결정한다.

Railway도 유사한 경계를 설명했다. 10월 21일 공지에서는 무단 당사자가 암호화된 환경 변수에 접근하고 일부 복호화된 내용을 획득했을 가능성이 있다고 밝혔다. 회사는 비정상적인 활동을 검토하는 한편 저장된 변수와 자격 증명을 교체할 것을 권고했다.

환경 변수 공지는 조사 기간 배포를 일시 중단한다고도 알렸다. 이는 가능한 노출에 대응하는 동안 변경 사항을 릴리스할 수 있는지라는 또 다른 고객 우려를 낳았다.

이러한 설명은 엔지니어링 리더, 보안 팀, 애플리케이션 소유자에게 서로 다른 이유로 압박을 가한다. 엔지니어링에는 작동하는 배포가 필요하다. 보안 팀에는 영향을 받은 접근 권한에 관한 방어 가능한 설명이 필요하다. 애플리케이션 소유자에게는 추가 장애를 만들지 않는 대체 자격 증명이 필요하다.

이 책임들은 겹치지만 상호 대체할 수는 없다. 누군가는 원래 발급처에서 기존 자격 증명을 취소하지 않은 채 애플리케이션 설정을 업데이트할 수 있다. 다른 누군가는 이에 의존하는 모든 애플리케이션을 식별하기 전에 자격 증명을 취소할 수 있다.

엔터프라이즈 구매자에게 이는 공급업체 복구의 의미를 바꾼다. 유용한 업데이트는 공급업체의 차단 조치와 여전히 필요한 고객 조치를 모두 설명해야 한다.

조직은 서비스별 영향과 자체 노출도 구분해야 한다. 플랫폼 전반의 장애가 없었다고 해서 연결된 자격 증명이 비공개로 유지됐다는 뜻은 아니다. 반대로 장애가 있었다고 해서 모든 고객 비밀값에 접근이 있었다는 뜻도 아니다.

이로 인해 기술 대응과 함께 문서화 부담도 생긴다. 팀은 공지를 보관하고, 자격 증명 소유자를 식별하며, 어떤 발급 서비스가 취소를 확인했는지 기록해야 한다. 그렇지 않으면 “해결됨”은 참여자마다 다른 의미가 될 수 있다.

검색 가능한 지식 기반은 기술 문서와 대응 결정을 정리하는 데 도움이 될 수 있다. 그러나 자격 증명을 발급하고 수락한 시스템의 증거를 대체할 수는 없다.

따라서 실질적인 압박은 공급업체 선택보다 더 광범위하다. 고객은 개발 워크플로가 어떤 외부 계정과 연결되는지, 그리고 누가 그 접근을 종료할 수 있는지 이해해야 한다.

조사관이 공격자를 식별하지 못한 경우에도 이 요구 사항은 여전히 유효하다. 신원 귀속은 증거가 확보될 때까지 기다릴 수 있다. 고객의 접근 검토는 공격자의 공개 이름이 아니라 영향을 받은 자격 증명에 달려 있다.

공동의 편의성이 만드는 공동 자격 증명 노출

상충 관계는 더 쉬운 협업과 협업을 가능하게 하는 접근 권한의 집중 사이에 있다.

OpenCode 공지는 그 상충 관계를 유난히 선명하게 보여준다. The Hacker News에 따르면 이 사고는 작업공간이 외부 AI 제공업체 키를 저장할 수 있는 선택형 호스팅 서비스인 Console과 관련됐다.

제공업체 키는 보유 자체로 권한 범위 내의 요청을 승인할 수 있는 베어러 자격 증명이다. 이를 개별 팀원에게서 분리해 두면 관리가 단순해질 수 있다. 하지만 호스팅 서비스는 여전히 이를 사용할 방법이 필요하다.

보도된 OpenCode Console 침해는 회사에 따르면 Console 사용자 중 1.4%에 영향을 미쳤을 가능성이 있다. OpenCode는 이러한 호스팅 자격 증명을 명령줄 및 데스크톱 애플리케이션이 로컬에 저장한 키와 구분했다.

이 구분은 제품 전체에 대한 과도하게 광범위한 결론을 막는다. 보도된 노출은 특정 서비스와 자격 증명 구성에 관한 것이었다. 모든 설치 환경이 같은 경로로 키를 처리했다는 점을 입증하지는 않는다.

또한 고객에게 보이는 통제를 신중하게 해석해야 하는 이유도 드러낸다. 호스팅 콘솔 내부에서 적용되는 제한은 콘솔이 관찰할 수 있는 활동에 적용된다. 복사된 제공업체 키를 직접 사용하는 것은 다른 경로를 따른다.

이는 특정 고객 제한이 이 사고 중 실패했다는 증거가 아니라 아키텍처적 결과다. 그 중요성은 통제가 어디에서 이뤄지는지에 있다.

구현 방식은 다르지만, 같은 논리는 개발 서비스 전반에 적용된다. 플랫폼은 일반 협업자로부터 비밀값을 보호하면서도 워크로드 실행에 필요한 권한 있는 내부 접근 권한은 유지할 수 있다.

따라서 고객에게는 비밀값이 인터페이스에서 숨겨진다는 말만으로는 충분하지 않다. 어떤 시스템이 어떤 권한으로 그러한 비밀값을 검색하거나 사용할 수 있는지 이해해야 한다.

암호화에도 맥락이 필요하다. 저장 시 암호화는 특정 조건에서 저장된 데이터를 보호한다. 그 자체로는 권한을 부여받은 애플리케이션이나 침해된 권한 구성요소가 복호화된 내용을 요청할 때 어떤 일이 발생하는지 설명하지 않는다.

Railway의 표현은 암호화가 보편적으로 실패했다는 점을 입증하지 않으면서도 이 구분을 중요하게 만든다. 해당 공지는 암호화된 변수와 일부 복호화된 내용에 접근했을 가능성을 설명했다. 추가 기술적 결론에는 더 많은 증거가 필요하다.

이 상충 관계의 반대편에는 정당한 이점도 있다. 중앙화된 자격 증명 관리는 비공식적인 공유를 줄이고 팀 접근을 더 쉽게 관리할 수 있게 한다.

모든 자격 증명을 개별 장비로 옮기면 또 다른 관리 문제가 발생한다. 10월의 공지들은 보편적으로 더 나은 저장 위치를 입증하지 않는다. 대신 배치 위치가 고객이 평가해야 할 신뢰 경계를 바꾼다는 점을 보여준다.

OpenCode의 호스팅과 로컬 간 구분은 바로 그 경계를 구체적으로 드러내기 때문에 유용하다. Fireworks의 평가 작업 범위와 Lightning의 서비스 제외도 유사한 역할을 한다.

따라서 Wiz Black October 패턴은 플랫폼이 “비밀값을 지원하는지”보다 더 날카로운 조달 질문을 제기한다. 구매자는 서비스가 권한 있는 접근을 어떻게 제한하고 그 접근이 실패했을 때 노출을 어떻게 억제하는지 알아야 한다.

가장 강력한 제품 답변은 협업을 편리하게 하면서도 노출된 자격 증명 하나에 부여되는 권한을 줄이는 방식일 것이다. 개별 공급업체가 이 기준을 충족하는지는 제품별 증거가 필요하다.

자격 증명 수명 주기 실패는 초기 수정 이후에도 지속될 수 있다

비밀값 교체는 이전 접근 권한이 종료되고 대체 자격 증명이 공격자의 손이 닿지 않는 곳에 있을 때에만 도움이 된다.

Zeabur의 예비 보고서는 자격 증명 관리 실패를 상세히 설명한다. 회사는 공개 인터넷에서 사용할 수 있는 평문으로 저장된 장기 관리자 자격 증명이 이번 사고의 원인이었다고 밝혔다.

자사의 자격 증명 유출 분석에서는 이전 순환 작업의 공백도 설명했다. 10월 사고에서 사용된 자격 증명 전체가 8월 사고 대응 범위에 포함된 것은 아니었다.

또 다른 흐름은 백업과 관련된다. Zeabur는 교체용 자격 증명이 백업에 포함됐고, 이후 무단으로 사용됐다고 밝혔다. 회사는 확인된 사건과 공격자가 백업을 어떻게 확보했는지에 대한 평가를 구분했다.

이러한 세부 사항은 복구가 의존 관계의 연속이라는 점에서 중요하다. 새 자격 증명을 만드는 것은 하나의 조치다. 공격자가 이를 가져올 수 없음을 확인하는 것은 별개의 결과다.

더 넓은 교훈은 모든 10월 사고에 관한 주장이 아니라 분석적 관점이다. 대응은 애플리케이션 계층에서는 완료된 것처럼 보일 수 있지만, 다른 곳에서 오래된 자격 증명이 여전히 유효할 수 있다.

마찬가지로 새 시크릿은 여전히 노출된 위치에 기록될 수 있다. 이런 경우 순환은 값을 바꾸지만 접근 관계까지 반드시 바꾸는 것은 아니다.

이 때문에 사고 업데이트는 교체와 함께 격리 조치도 설명해야 한다. 고객은 새 값이 문제를 해결한다고 가정하기 전에 시크릿을 획득하던 경로가 차단됐다는 확신이 필요하다.

백업은 과거 상태를 보존하기 때문에 이러한 평가를 복잡하게 만든다. 백업의 복구 가치는 프로덕션 시스템이 나중에 삭제하거나 교체할 수 있는 정보를 유지하는 데 달려 있다.

그렇다고 백업이 본질적으로 안전하지 않다는 뜻은 아니다. 실행 중인 서비스에 대한 접근과 마찬가지로 백업 접근도 동일한 자격 증명 분석에 포함돼야 한다는 의미다.

Zeabur의 보고서는 확실성의 수준을 구분한다는 점에서 특히 유용하다. 기록된 읽기, 추정된 다운로드, 확인되지 않은 가능성은 서로 다른 발견 사항이다.

독자는 영향을 평가할 때 이러한 구분을 유지해야 한다. 컨테이너 접근을 보여주는 기록이 반환된 모든 결과의 내용을 자동으로 입증하는 것은 아니다. 로그가 없다고 해서 접근이 전혀 발생하지 않았다는 증거도 아니다.

이러한 증거 원칙은 상업적 결과로 이어진다. 민감한 워크로드를 재개할지 결정하는 고객에게는 조사관이 관찰한 내용과 여전히 알 수 없는 내용을 명확히 설명해야 한다.

자격 증명이 순환됐다는 설명은 적용 범위에 대한 정보 없이는 제한적인 확신만 제공한다. 접근이 차단됐다는 설명 역시 어떤 접근 경로를 조사했는지 밝히지 않으면 제한적인 확신만 제공한다.

여기에는 새로운 AI 특화 취약점이 필요하지 않다. 일반적인 관리자 권한도 다른 서비스의 자격 증명에 닿게 되면 특히 중대한 결과를 초래한다.

따라서 플랫폼에 가해지는 경쟁 압력은 구체적이다. 공급업체는 복구 절차가 고객이 실제로 맡긴 연결된 접근 권한을 포괄한다는 점을 입증해야 한다.

설득력 있는 대응은 사고의 경계, 개선 조치의 경계, 그리고 둘을 연결하는 증거를 설명할 것이다.

에이전트 스웜과 증류는 여전히 별개의 주장이다

증거는 공격자 신원, 자동화 또는 동기에 대한 통합된 설명보다 자격 증명 노출 우려를 더 강하게 뒷받침한다.

Wiz는 Fireworks, OpenCode, Warp가 조정된 AI 에이전트가 관여하는 공격을 의미하는 에이전트 스웜 공격의 징후를 설명했다고 보고했다. 또한 OpenCode와 CommandCode는 자신들의 사고를 증류와 연관 지었다고 언급했다.

증류는 한 모델의 출력을 다른 모델 학습에 사용하는 방식이다. 이 가능한 동기는 일반 워크로드를 위한 자격 증명 재판매나 무단 사용과는 다르다.

이러한 설명은 겹칠 수 있지만, 겹침이 증거는 아니다. 공격자는 접근 권한을 훔쳐 다른 사람에게 넘길 수 있다. 최종 사용자의 목적이 최초 침입자의 목적을 자동으로 입증하지는 않는다.

같은 이유로 OpenCode의 공개적 규정에는 출처 표기가 필요하다. 사고를 증류와 관련 있다고 부르는 것만으로는 누가 출력을 요청했는지, 조사관이 어떻게 그런 결론에 도달했는지를 입증하지 못한다.

The Hacker News는 중요한 기술 세부 사항이 공개되지 않은 채 남아 있다고 보도했다. 따라서 독자는 회사의 설명을 전체 사고에 대해 독립적으로 확립된 해석으로 받아들여서는 안 된다.

마찬가지로 자동화된 활동이 반드시 자율적인 의사결정을 보여주는 것은 아니다. 빠른 실행, 반복된 요청, 병렬 활동은 기존 스크립트에서도 발생할 수 있다.

신뢰할 수 있는 에이전트 스웜 귀속에는 이러한 가능성을 구분하는 증거가 필요하다. 공개 설명은 독자에게 더 넓은 명칭을 받아들이라고 요구하기 전에 관찰된 행동을 설명해야 한다.

이는 공급업체의 설명을 일축해야 한다는 이유가 아니다. 자체 시스템을 조사하는 기업은 대중에게 공개되지 않은 증거를 보유할 수 있다.

이는 해당 기업들이 말하는 내용과 외부 독자가 검증할 수 있는 내용을 구분해야 하는 이유다. 이러한 구분은 분석이 공개 내용보다 더 확실해지는 일을 막는다.

Wiz는 또한 일반적으로 LLMJacking이라 불리는, 다른 주체의 언어 모델 접근 권한을 무단으로 사용하는 탈취된 자격 증명의 후속 악용을 설명한다. 그 분석은 일부 자격 증명 확인을 재판매 인프라와 연관 짓는 한편, 최초 침해에 관한 결론은 제한한다.

이 단서는 핵심적이다. 탈취된 키에 대한 접근은 어떤 행위자를 후속 활동과 연결할 수 있지만, 그것이 키를 노출한 침해의 책임을 입증하지는 않는다.

동일한 신중함은 9건의 공개 내용을 모두 하나로 묶는 데에도 적용된다. AI 자격 증명에 대한 공통 관심은 의미 있는 패턴이다. 하지만 공통 운영자, 공유 도구 또는 동일한 목표를 입증하지는 않는다.

방어자에게 이러한 구분은 우선순위의 순서를 바꾼다. 자격 증명의 유효성과 관찰된 사용은 즉각적인 판단을 뒷받침할 수 있다. 자동화와 동기에 관한 주장은 별도의 증거가 필요하다.

공급업체에는 유익한 업데이트의 기준을 바꾼다. 공격자를 정교하다고 묘사하는 것보다 접근이 어떻게 발생했는지와 어떤 통제가 실패했는지를 설명하는 편이 운영상 더 가치 있다.

독자에게 적절한 회의적 태도는 구체적이다. 문서화된 범위 안에서 확인된 노출은 받아들여야 한다. 증거가 이를 연결하기 전까지 더 넓은 캠페인 주장은 잠정적으로 유지해야 한다.

Wiz Black October 보고서는 이러한 원칙에 따라 읽을 때 가장 강력하다. 그 가치는 미해결 설명 하나하나를 사실로 만들지 않으면서도 조사가 필요한 패턴을 식별하는 데 있다.

플랫폼이 바뀌었음을 보여줄 요소

다음으로 의미 있는 증거는 더 완전한 공개, 더 제한된 자격 증명 권한, 그리고 독립적으로 평가 가능한 복구 조치에서 나올 것이다.

첫 번째 신호는 더 나은 기술 보고다. 앞으로 몇 달 동안 공급업체가 최종 타임라인, 영향을 받은 시스템의 경계, 공격자가 접근 권한을 얻은 방법에 대한 설명을 공개하는지 지켜봐야 한다.

이러한 공개는 저장된 자격 증명을 둘러싼 반복적 약점을 확인한다면 분석을 강화할 것이다. 반대로 서로 관련 없는 진입 지점과 목표를 확립한다면 통합된 캠페인 해석은 약화될 수 있다.

두 결과 모두 이해를 높일 것이다. 후속 보도의 목적은 새로운 증거와 무관하게 극적인 명칭을 유지하는 것이 아니라, 원래의 패턴을 정교화하는 데 있다.

유용한 최종 보고서는 초기 설명과 이후 발견 사항도 조정해야 한다. 범위가 확대되거나 축소됐다면, 고객은 조사관이 왜 평가를 바꿨는지 이해할 필요가 있다.

이는 사후 분석 보고서의 길이보다 더 중요하다. 상세한 서술도 고객의 노출을 결정하는 접근 관계를 빠뜨릴 수 있다.

두 번째 신호는 자격 증명 권한의 변화다. 호스팅 서비스가 접근할 수 있는 범위나 해당 권한이 지속되는 기간을 줄이는 문서화된 제품 변경이 있는지 지켜봐야 한다.

단기 권한 부여는 정해진 기간이 지나면 자동으로 만료된다. 제한된 권한은 자격 증명이 허용하는 행동을 제한한다. 이는 복제된 접근이 초래하는 결과를 제약하는 서로 다른 방식이다.

이러한 조치의 존재만으로 플랫폼이 안전하다는 사실이 입증되지는 않는다. 어디에 적용되는지, 어떤 워크플로가 여전히 예외인지, 고객이 무엇을 구성해야 하는지를 증거로 보여줘야 한다.

이런 변화는 공급업체가 근본적인 절충 관계를 해결하고 있다는 근거를 강화할 것이다. 노출된 값을 교체하는 데만 한정된 대응은 구조적 개선의 더 약한 증거가 될 것이다.

구매자는 발표된 작업과 실제 배포된 동작도 구분해야 한다. 로드맵은 의도를 설명한다. 업데이트된 문서와 관찰 가능한 적용은 서비스를 평가하는 더 확실한 근거를 제공한다.

세 번째 신호는 복구와 후속 오용에 관한 더 명확한 증거다. 공급업체와 영향을 받은 고객이 폐기된 자격 증명이 무단 활동을 중단시켰는지, 교체 자격 증명이 계속 보호됐는지를 설명하는지 지켜봐야 한다.

정리 작업이 완료됐다는 주장 이후에도 오용이 계속된다면 설명이 필요하다. 불완전한 폐기, 또 다른 노출된 자격 증명, 또는 조사관이 아직 파악하지 못한 접근 경로가 관련됐을 수 있다.

대중은 어떤 설명이 적용되는지 추정해서는 안 된다. 중요한 점은 이후 보도가 증거를 통해 불일치를 해소하는지 여부다.

반대로 무단 활동이 종료됐다는 문서화된 사실은 격리 조치의 효과를 뒷받침할 것이다. 그렇더라도 공급업체가 유사한 노출을 어떻게 방지할 것인지라는 별도의 질문은 남는다.

개발자에게 이러한 신호는 공급업체 평가를 더 구체적으로 만든다. 서비스는 팀이 실제로 사용하는 애플리케이션과 계정에 대응하는 방식으로 접근 경계를 설명해야 한다.

엔터프라이즈 구매자는 복구된 서비스를 대응 완료로 간주하기 전에 이러한 명확성을 기대해야 한다. 연결된 AI 워크플로를 사용하는 지식 근로자 역시 자신이 사용하는 도구가 어떤 계정에 접근할 수 있는지 이해해야 한다.

공급업체가 업데이트를 공개할 때 Wiz Black October 공개 내용을 다시 검토하고, 각각의 새 주장과 이를 뒷받침하는 증거를 비교해야 한다. 어떤 자격 증명이 노출됐는지, 어디에서 폐기가 이뤄졌는지, 교체 접근 권한이 제공되기 전에 무엇이 바뀌었는지 물어야 한다. 플랫폼 복구와 연결된 서비스 검토는 서로 다른 기록에 의존하므로 분리해 유지해야 한다. 개발팀에 유용한 결과는 누가 접근 권한을 보유하며 그 접근이 어떻게 종료되는지에 대한 더 명확한 설명이다. 구매자에게는 협업이 더 이상 같은 수준의 권한 집중을 요구하지 않는다는 증거다. 다음 질문은 구체적이다. 어떤 공급업체가 고객이 검증할 수 있을 만큼 명확하게 그 변화를 문서화할 것인가?