Keone Hon의 Ultrafuzz 추진, Monad의 OpSec 우려를 부각하다
Monad 공동 창업자 Keone Hon은 개발자들에게 Ultrafuzz를 도입할 것을 촉구하는 한편, 보안은 계약 코드의 버그를 찾는 데 그치지 않는다고 경고하고 있다. Keone Hon의 Ultrafuzz 추진은 AI 지원 테스트와 운영 보안(Operational Security), 즉 소프트웨어를 둘러싼 계정, 기기, 프로세스를 보호하는 OpSec를 결합한다. 안전한 계약도 이를 관리할 권한을 가진 사람에게 의존한다는 점에서 이 조합은 중요하다.
crypto.news에 따르면 Hon은 10월 30일 보안 자료를 공유하고, 별도로 개발자들에게 Ultrafuzz로 계약을 테스트하라고 권했다. 그의 호소는 기존 오픈소스 프로젝트에 다시 주목하게 한다. 이는 신규 제품 출시를 뜻하거나 도구의 효과를 독립적으로 검증하는 것은 아니다.
핵심 긴장은 자동화된 조사와 개발자에게 남아 있는 운영 책임 사이에 있다. Trail of Bits의 Echidna 같은 기존 도구도 이미 계약의 동작을 테스트한다. Ultrafuzz는 이 작업에 AI 조율 기능을 더하지만, 자체 문서에서는 가치 있는 자격 증명 주변에서 제한 없는 에이전트를 실행하지 말라고 경고한다. 도입을 고려하는 팀은 도구가 산출하는 결과와 이를 안전하게 산출하기 위해 필요한 환경을 모두 평가해야 한다.
Keone Hon의 Ultrafuzz 추진은 기존 보안 노력을 다시 부각한다
당장의 소식은 새로 출시된 보안 제품이 아니라, Hon이 도입을 다시 촉구했다는 점이다.
Crypto.news는 10월 31일 Hon이 직원 기기, 자격 증명, 관리 권한, 제3자 계정을 다루는 지침과 함께 계약 테스트를 홍보했다고 보도했다. 해당 보도는 그의 10월 30일 게시물을 재현하고, 개발자들에게 Ultrafuzz를 실행해 보라고 별도로 권유한 내용을 설명한다. 이러한 보안 권고 사항은 소프트웨어 검토를 더 폭넓은 운영 규율 안에 위치시킨다.
이 구분은 독자가 이 발표를 해석하는 방식에 영향을 준다. 새 릴리스라면 새로 추가된 기능, 마이그레이션 요건, 이전 버전과의 차이에 관한 질문이 뒤따를 것이다. 반면 재차 권유하는 경우에는 도입, 실질적 유용성, 기존 자료가 필요한 팀에 도달하는지에 관한 질문이 제기된다.
Hon의 메시지는 조직이 때때로 서로 다른 사람에게 맡기는 책임도 함께 묶는다. 개발자는 계약의 동작을 조사하는 반면, 다른 직원은 계정을 관리하고 컴퓨터를 운영하며 민감한 작업을 승인한다. 특히 관리 작업이 소프트웨어의 동작을 바꿀 수 있을 때, 보안 결과는 이러한 책임이 어떻게 연결되는지에 달려 있다.
스마트 계약은 블록체인에 배포되어 프로그래밍된 규칙에 따라 실행되는 소프트웨어다. 일부 계약에는 업그레이드나 기타 관리 작업을 위한 특권 기능도 포함된다. 규칙을 검토하는 일과 이를 변경할 권한을 보호하는 일은 서로 다른 실패 경로를 다룬다. 어느 한 영역에서 성공했다고 해서 다른 영역에서도 성공한 것은 아니다.
이 때문에 OpSec 자료는 이 이야기에서 테스트 도구와 함께 다뤄져야 한다. 보도된 Hon의 권고는 특수한 AI 방어 체계만이 아니라 일상적인 업무 관행을 포괄한다. 이는 코드 검토 후에도 프로토콜을 뒷받침하는 사람과 시스템에 관심을 돌리게 한다.
보도상 명확한 경계도 있다. 이번 검토에서는 Hon의 원래 X 게시물을 직접 확인할 수 없었으므로, 그의 최근 발언은 이를 재현한 보도에 근거해 계속 귀속된다. 도구의 공개 문서는 그 존재와 운영 모델에 관한 별도의 근거를 제공한다.
이 호소만으로는 얼마나 많은 팀이 이 지침을 도입했는지 측정할 수 없다. 사용자가 서명 관행을 바꾸었거나 이전에 알려지지 않은 취약점을 수정했다는 점도 입증하지 않는다. 공개, 홍보, 사용, 입증된 효과는 여전히 별개의 단계다.
독자에게 의미 있는 변화는 결합된 요청이다. Monad는 빌더들에게 소프트웨어를 더 폭넓게 조사하는 동시에 그 소프트웨어를 둘러싼 권한을 점검하라고 요구하고 있다. 이러한 요청이 행동 변화로 이어질지는 자료 목록을 공유하는 것 이상의 작업에 달려 있다.
압박은 감사를 일상 운영과 분리하는 팀에 가해진다
Hon의 호소는 계정과 관리 접근 권한을 통제하는 사람을 포함해 프로토콜을 운영하는 조직에 책임을 부여한다.
계약 검토는 정의된 소프트웨어 대상을 조사한다. 그러나 조직은 인력 교체, 새로운 의존성, 권한 변경, 업무 방식의 수정 등을 통해 그 대상 주변에서 계속 변한다. 완료된 검토를 영구적인 보안 상태로 취급하면 이러한 지속적인 결정을 간과하게 된다.
검토를 거친 코드와 업그레이드를 승인할 권한이 있는 계정을 가진 프로토콜을 생각해 보자. 권한이 없는 사람이 그 계정을 장악한다면, 검토는 조직의 승인 절차를 강제할 수 없다. 이 가정은 올바른 소프트웨어 동작과 특권 권한의 정당한 사용 사이의 경계를 보여 준다.
같은 논리는 직원의 컴퓨터에도 적용된다. 개발자는 하나의 기기에서 계약 로직을 신중하게 다루면서 관련 없는 소프트웨어와 커뮤니케이션도 처리할 수 있다. 그 결과 발생하는 노출은 계약 자체가 의도대로 정확히 동작하더라도 업무 환경에 속한다.
보도에서 설명한 가이드는 기기 분리, 자격 증명 관행, 거래 서명 전 점검을 통해 이러한 주변 환경을 다룬다. 그 권고는 새로운 AI 기능에 의존하지 않는다. 대신 팀이 일상적 책임을 명확히 하고 매일의 업무 중에도 유지할 것을 요구한다.
이는 개별 개발자만큼이나 창업자와 엔지니어링 리더에게도 압박을 준다. 누군가는 누가 민감한 작업을 승인할 수 있는지, 어떤 기기가 그러한 작업을 지원하는지, 의심스러운 활동이 어떻게 보고되는지를 결정해야 한다. 이러한 결정에는 또 다른 자동화 스캔이 아니라 책임 주체가 필요하다.
Hon은 더 유능한 공격자를 방어 강화의 이유로 제시하며 AI가 논의의 변화를 이끈다고 본다. 이는 그의 명시된 근거이지, AI가 특정 사고를 일으켰다는 증거는 아니다. 공격에서 AI가 개입했음을 입증하려면 공격 자체에 관한 증거가 필요하다.
더 강한 귀속이 없어도 운영상 시사점은 유용하다. 팀이 수행하는 보안 작업의 양을 늘리기 위해 자동화를 도입한다면, 접근 권한에 관한 명확한 규칙도 여전히 필요하다. 조사를 더 많이 한다고 해서 계정, 기기, 서명 절차를 통해 노출되는 권한이 자동으로 줄어드는 것은 아니다.
이 압박은 프로토콜을 평가하는 구매자와 파트너에게도 미친다. 소프트웨어가 자동화 테스트를 받았다는 진술은 조직이 이를 안전하게 운영할 수 있는지보다 더 좁은 질문에 답한다. 검토자는 무엇이 검사되었고 어떤 책임이 그 검사 범위 밖에 남았는지를 이해해야 한다.
예를 들어 계약 동작에 관한 보고서는 직원의 복구 절차가 보호된다는 점을 입증하지 않는다. 보호된 계정에 관한 진술도 회계 로직이 이례적인 거래 순서를 올바르게 처리한다는 점을 입증하지 않는다. 두 진술 모두 범위가 분명할 때 유용할 수 있다.
이는 Hon의 결합된 메시지가 단순히 도구를 사용해 보라는 요청보다 더 까다롭다는 뜻이다. 그는 팀에 기술적 조사와 운영 책임성을 조율하라고 요구한다. 특히 각 전문가가 다른 사람이 이를 담당한다고 여길 때, 실질적인 질문은 이러한 활동 사이의 위험을 누군가 책임지는지 여부가 된다.
Ultrafuzz는 기존 테스트 방법을 중심으로 조사를 조율한다
Ultrafuzz의 제안은 에이전트가 조사할 질문과 단계 사이에서 전달할 증거를 포함해 보안 작업을 조직하는 데 있다.
Monad의 9월 10일 오픈소스 릴리스는 스마트 계약 작성에 사용되는 프로그래밍 언어인 Solidity와 Vyper 지원을 설명한다. 이 릴리스에는 20회가 넘는 생태계 실행 경험이 반영됐다고 밝힌다. 이는 독립적인 보호 수준 측정이 아니라 재단 측의 개발 주장이다.
예상치 못한 동작을 찾기 위해 다양한 입력을 생성하는 테스트 기법인 퍼징은 워크플로의 일부를 이룬다. 불변 조건은 시스템이 도달하는 여러 상태에서도 참으로 유지되어야 하는 조건이다. 이러한 조건을 정의하면 조사에 테스트할 구체적인 질문이 생긴다.
중요한 설계 선택은 입력 생성 이전에 이뤄진다. 시스템에는 의도된 동작, 관련 사용자, 의미 있는 실패 조건에 대한 유용한 설명이 필요하다. 그 설명이 불완전하다면, 광범위한 테스트는 잘못된 질문을 철저히 조사할 수 있다.
Antonio Viggiano의 9월 21일 기술적 해설은 이 프로젝트가 팀의 외부 보안 검토 준비를 돕는 데서 출발했다고 설명한다. 그는 퍼징 테스트의 공백과 작업 일부를 자동화하려는 노력을 다룬다. 그의 설명은 Ultrafuzz를 보안 참여를 지원하는 도구로 제시한다.
이 워크플로는 속성을 조사하기 전에 참여자와 작업을 매핑한다. 예를 들어 대출 애플리케이션에서는 차입자, 대출자, 청산자가 서로 다른 작업을 통해 상호작용한다. 이러한 관계를 이해하면 조사자는 고립된 작업이 아니라 순서와 관련된 실패를 추론하는 데 도움이 된다.
이 순서가 중요한 이유는 개별 작업 후에는 조건이 유지되더라도 여러 상호작용 뒤에는 실패할 수 있기 때문이다. 유용한 조사는 시스템의 변화하는 상태를 고려해야 한다. 실패에 관한 설득력 있는 설명을 생성하는 일은 그 실패가 실제로 발생한다는 증거를 내놓는 일과 다르다.
기존 테스트 도구도 이미 이 문제의 일부를 다룬다. Trail of Bits는 Echidna를 속성 기반 퍼저로, Medusa를 병렬 스마트 계약 퍼저로 설명한다. 계약 테스트 도구에는 전체 애플리케이션을 실행하지 않고 코드를 검사하는 Slither도 포함된다.
따라서 비교 대상은 단순한 대체 경쟁이 아니라 워크플로 범위다. Echidna는 제공된 속성을 테스트하는 데 집중한다. Ultrafuzz는 준비와 해석을 포함해 대상 주변의 더 폭넓은 조사를 조율하려 한다. 조직은 여전히 속성과 결과 증거의 품질을 평가해야 한다.
Viggiano의 설명은 에이전트가 이전 에이전트의 출력에 의존할 때의 어려움도 논의한다. 이는 조율된 워크플로가 유용한 정보뿐 아니라 오류도 물려받기 때문에 중요하다. 초기 단계의 잘못된 가정은 다른 단계에서 이를 검증하지 않는 한 이후 작업에 영향을 줄 수 있다.
도입자에게 핵심 질문은 이러한 조율이 더 적은 전문 인력으로 검토 가능한 결과를 산출하는지 여부다. 답을 얻으려면 실제 캠페인을 검토해야 한다. 긴 보고서나 정교한 워크플로 다이어그램만으로는 조사가 프로토콜에서 가장 중요한 실패 경로를 포괄했다는 점을 입증할 수 없다.
자동화된 발견 사항에도 재현 가능한 증거가 필요하다
보안 발견 사항을 신뢰하는 데 필요한 증거는 그럴듯한 경고를 생성하는 데 필요한 증거보다 더 구체적이다.
AI가 생성한 보고서는 현실적인 실패를 설명할 수 있지만, 대상이 이를 허용한다는 사실까지 입증하지는 못한다. 반대로 조사는 가정이 관련 동작을 제외하기 때문에 실패를 놓칠 수 있다. 도구를 평가하려면 근거 없는 발견 사항과 간과된 취약점 모두에 주의를 기울여야 한다.
재현기는 명시된 조건에서 보고된 실패를 신뢰성 있게 보여 주는 테스트 또는 절차다. 검토자에게 이는 설명을 관찰 가능한 동작과 연결한다. 이러한 연결이 없다면 팀은 경고가 적용되는지 판단하는 데 추가 노력을 들여야 한다.
대상 리비전도 중요합니다. 소프트웨어는 개발 과정에서 변경되며, 이전 버전에 관한 발견은 배포 예정 버전을 더 이상 정확히 설명하지 못할 수 있습니다. 보고서에는 다른 검토자가 어떤 코드와 가정이 해당 결과를 낳았는지 식별할 수 있을 만큼의 맥락이 필요합니다.
이러한 요구 사항은 AI 시스템뿐 아니라 사람의 검토에도 적용됩니다. 자동화는 팀이 즉시 조사할 수 있는 양보다 더 많은 잠재적 발견 사항을 만들어낼 수 있기 때문에 압박을 가합니다. 그 결과물의 가치는 확립된 실패와 아직 해결되지 않은 의심을 얼마나 명확히 구분하는지에 따라 달라집니다.
따라서 유용한 평가는 발견 사항이 제기된 뒤 무엇이 일어났는지를 묻습니다. 개발자가 이를 재현했는가? 팀이 근본적인 문제를 인정했는가? 수정 조치는 입증된 동작을 해결했는가? 이러한 질문은 자동화된 발견을 엔지니어링 결과와 연결합니다.
도구 간 비교에도 이와 유사하게 신중한 경계 설정이 필요합니다. 대상, 모델 선택, 프롬프트, 가용 리소스가 달라지면 결과도 달라질 수 있습니다. 한 번에 여러 조건을 바꾸는 비교는 어떤 설계 선택이 겉으로 보이는 개선을 만들어냈는지 분리해 내지 못합니다.
독립 연구는 도입 문제에 대한 맥락을 제공합니다. 연구 Human Side of Fuzzing은 스마트 계약 개발 툴킷인 Echidna와 Foundry와 관련된 GitHub 이슈 381건을 조사했습니다. 이 연구는 실무자들이 이러한 시스템을 사용하는 과정에서 겪는 어려움을 살펴봤습니다. 이 연구는 Ultrafuzz를 평가하지는 않습니다.
여기서 중요한 점은 이용 가능한 기술과 실제로 사용할 수 있는 워크플로의 구분입니다. 도구는 실질적인 기술적 요구를 해결할 수 있지만, 동시에 설정, 해석, 유지보수 작업을 요구할 수도 있습니다. AI 조정은 발견 결과뿐 아니라 이러한 부담을 기준으로도 평가해야 합니다.
이는 Ultrafuzz에 공정한 기준을 제시합니다. 개발자는 완전한 커버리지나 보편적 우위를 주장하지 않으면서도 유용한 증거를 제시할 수 있습니다. 범위가 명확한 사례, 재현 가능한 실패, 성공하지 못한 실행에 대한 솔직한 설명은 외부인이 이 워크플로가 어디에서 기여하는지 판단하는 데 도움이 됩니다.
이에 상응하는 회의적 관점은 AI 보조 조사를 일축할 것을 요구하지 않습니다. 이는 “이 시스템이 문제를 발견했다”는 주장과 “이 시스템이 보안을 입증한다”는 주장 사이의 비약을 경계하라는 뜻입니다. 두 주장은 서로 다른 증거 요건을 가지며, 후자는 단일 캠페인의 범위를 넘어섭니다.
Keone Hon의 Ultrafuzz 추진을 평가하는 팀에 실질적인 결론은 명확합니다. 도입은 다른 사람이 검토하고 이의를 제기할 수 있는 산출물을 만들어야 합니다. 신뢰는 참여한 에이전트 수가 아니라 그러한 산출물과 그 해결 과정에서 쌓여야 합니다.
제한 없는 에이전트는 운영 환경 자체를 평가의 일부로 만든다
Ultrafuzz 자체 경고는 격리를 테스트가 시작된 뒤 고려할 세부 사항이 아니라, 책임 있는 평가의 조건으로 만듭니다.
프로젝트의 agent security warning은 일반 워크스테이션과 분리된 소프트웨어 기반 컴퓨터인 일회용 격리 가상 머신을 권장합니다. 에이전트가 제한 없는 권한으로 작동한다고 명시합니다. 또한 가치 있는 데이터나 자격 증명이 포함된 환경은 피하라고 경고합니다.
이 경고는 도구를 시도하는 행위의 의미를 바꿉니다. 개발자는 붙여 넣은 코드에 대한 논평을 단순히 요청하는 것이 아니라, 소프트웨어가 환경 안에서 작업을 수행하도록 허용하는 것입니다. 해당 환경에서 이용 가능한 권한은 평가의 일부가 됩니다.
격리는 의도하지 않은 작업이 초래할 결과를 줄입니다. 하지만 생성된 모든 발견이 정확하다거나 관련된 모든 계약 동작이 검토된다는 것을 보장하지는 않습니다. 운영상 격리와 분석 정확성은 둘 다 캠페인의 유용성에 영향을 미치더라도 여전히 별개의 요건입니다.
이 구분은 기밀 코드에도 적용됩니다. 격리된 머신은 분석에 필요한 민감한 프로젝트 자료를 보관하면서도 관련 없는 파일에 대한 접근을 제한할 수 있습니다. 팀은 선택한 구성 전반에서 그러한 자료가 어떻게 처리되는지 이해해야 합니다.
이는 조직에 이미 외부 소프트웨어 검토 규정이 있는 경우 특히 중요합니다. 보안 도구 역시 저장소에 접근할 수 있는 다른 소프트웨어와 동일한 의사결정 절차를 거쳐야 합니다. 방어 목적이라고 해서 그 권한을 이해할 필요가 사라지는 것은 아닙니다.
여기에는 Ultrafuzz가 사용자의 워크스테이션을 침해했다고 주장할 근거가 없습니다. 문서화된 경고는 명시된 위험과 배포 경계를 설정합니다. 이를 특정 유해 사건이 발생했다는 주장으로 바꿔서는 안 됩니다.
더 유용한 해석은 책임성에 관한 것입니다. 누군가는 환경을 준비하고, 무엇을 그 안에 넣을지 결정하며, 결과 산출물을 검토해야 합니다. 캠페인의 자동화 단계는 이러한 책임을 없애지 않습니다. 오히려 머신 활동과 사람의 판단 사이의 인계를 더 중요하게 만듭니다.
여기에서 도구와 OpSec에 대한 요구가 가장 직접적으로 만납니다. 계약을 조사하기 위해 AI를 도입하는 팀은 그 조사에도 운영 규율을 적용해야 합니다. 그렇지 않으면 다른 곳에서는 기대하는 관행의 예외로 보안 워크플로를 취급할 위험이 있습니다.
유사한 제품을 평가하는 조직에는 조달 측면의 함의도 있습니다. 배포 요건은 지원 언어 및 보고 기능과 함께 비교 항목에 포함되어야 합니다. 도구의 유용성은 조직이 접근 및 기밀 유지 요건 안에서 이를 운영할 수 있는지에 부분적으로 달려 있습니다.
그에 따른 상충 관계는 구체적입니다. 더 큰 자율성은 에이전트가 지속적인 개입 없이 더 많은 작업을 수행하게 해 주지만, 환경은 그 자율성의 결과를 제한해야 합니다. 올바른 평가는 준비, 실행, 검토, 폐기를 포함한 전체 캠페인을 고려합니다.
따라서 Keone Hon의 Ultrafuzz 추진은 개발자가 캠페인을 시작하는지 여부만으로 평가할 수 없습니다. 더 강력한 도입 신호는 팀이 문서화된 경계를 준수하고 결과에 대한 분명한 책임을 유지하는 모습을 보여줄 것입니다. 소프트웨어를 실행하는 것은 이를 잘 활용하는 일의 일부일 뿐입니다.
검증된 발견, 지속적인 사용, 운영 변화에 주목하라
다음 증거는 자동화된 조사를 수정 조치, 반복 사용, 그리고 민감한 운영에 대한 더 강력한 통제와 연결해야 합니다.
가장 먼저 주목할 신호는 독립적으로 재현 가능한 발견입니다. 향후 수개월 동안의 상세 공개는 어떤 대상을 조사했는지, 어떤 동작이 실패했는지, 다른 검토자가 이를 어떻게 확인했는지를 보여줄 수 있습니다. 그러한 증거는 이 워크플로가 잠재적 경고를 생성하는 수준을 넘어 기여한다는 근거를 강화할 것입니다.
수용된 수정도 또 다른 유용한 연결 고리를 더합니다. 공개된 발견은 배포된 시스템에 영향을 주지 않더라도 흥미로울 수 있습니다. 개발자가 문제를 이해하고 수정했다는 증거는 발견이 어떻게 엔지니어링 작업으로 이어졌는지를 보여줄 것입니다.
공개된 사례가 없다고 해서 실패가 입증되는 것은 아닙니다. 팀은 문제를 수정하는 동안 발견 사항을 기밀로 유지할 수 있고, 공개 시점도 달라질 수 있습니다. 하지만 외부 관찰자가 효과를 독립적으로 판단할 수 있는 증거는 줄어들게 됩니다.
두 번째 신호는 초기 시험을 넘어선 지속적인 사용입니다. 코드 변경 후에도 팀이 도구를 다시 사용한다면, 일회성 시연과는 다른 도입 신호를 제공합니다. 반복 사용은 이 워크플로가 지속적인 개발 프로세스에 맞는다는 점을 시사합니다.
사용자가 필요한 노력을 설명할 때 이 신호는 더 강해집니다. 설정의 어려움, 실패한 캠페인, 검토 시간, 유용한 결과물에 대한 설명은 다른 팀이 적합성을 평가하는 데 도움이 됩니다. 근거 없는 칭찬은 워크플로가 어디에서 도움이 됐는지 명확히 설명하는 것보다 실용적인 정보를 덜 제공합니다.
저장소에 대한 관심만으로는 이러한 질문에 답할 수 없습니다. 공개적 관심은 실제 운영 사용보다 호기심, 홍보, 연구를 반영할 수 있습니다. 도입 주장은 완료된 작업과 결과 검토를 책임진 사람을 설명할 때 더 많은 정보를 제공합니다.
세 번째 신호는 기술적 테스트와 함께 나타나는 운영 변화입니다. Hon의 더 폭넓은 요구를 따르는 팀은 특권 접근, 서명 방식, 민감한 업무의 분리를 검토할 것입니다. 이러한 조치는 메시지가 계약 분석을 넘어 전달됐다는 주장을 뒷받침할 것입니다.
캠페인 보고서만으로는 그러한 변화가 실제로 일어났음을 입증할 수 없습니다. 증거는 민감한 세부 사항에 적절히 주의하면서 프로토콜을 운영하는 조직에서 나와야 합니다. 명확한 책임 소재와 문서화된 프로세스는 보안을 진지하게 다룬다는 포괄적 주장보다 더 의미 있습니다.
이러한 신호들은 같은 명제의 서로 다른 부분을 검증합니다. 검증된 발견은 분석적 유용성을 평가합니다. 지속적인 사용은 실무 적합성을 평가합니다. 운영 변화는 더 강력한 테스트가 소프트웨어를 관리하는 시스템에 대한 더 강력한 통제와 함께 이뤄지는지 평가합니다.
개발자가 즉시 취할 조치는 캠페인을 시작하기 전에 어떤 증거가 워크플로 도입을 정당화하는지 정의하는 것입니다. 누가 발견 사항을 검토할지, 실패를 어떻게 재현할지, 어떤 환경이 프로젝트의 운영 요건을 충족하는지 식별하십시오. 구매자와 파트너는 결과 보고서가 실제로 무엇을 다루며 어떤 책임이 여전히 그 범위 밖에 남는지 물어야 합니다. Keone Hon의 Ultrafuzz 추진은 이러한 질문을 다시 검토할 유용한 이유를 제공합니다. 문서화된 경계를 읽고, 조직의 관행과 비교한 뒤, 다음 보안 훈련이 더 나은 증거와 그 증거가 해결할 수 없는 위험에 대한 더 명확한 책임 소재를 모두 만들어낼지 물어보십시오.
