360 CyberGym 결과: Tulongfeng, 취약점 재현 99.4% 주장

360은 자사의 Tulongfeng 보안 시스템이 과거 소프트웨어 버그를 기반으로 구성된 평가인 CyberGym에서 약 99.4%의 취약점 재현 성공률을 달성했다고 밝혔다. 360 CyberGym 결과는 2026년 10월 30일자 보도에서 공개됐다. 이는 알려지지 않은 취약점을 찾는 일반적 성공률이 아니라, 정의된 과제에서 거의 최고 수준에 가까운 점수를 기록했다는 의미다.

이 구분은 OpenAI, Anthropic, Google의 모델을 중심으로 구축된 에이전트와 전문 시스템을 비교하는 보안팀에 중요하다. 식별된 버그를 재현하려면 상당한 엔지니어링 작업이 필요하다. 반면 익숙하지 않은 애플리케이션에서 특정되지 않은 결함을 찾는 일은 다른 문제다. 전자에서의 강력한 결과는 주목할 만하지만, 후자에 관한 모든 주장을 뒷받침하는 증거가 되지는 않는다.

핵심 쟁점은 거의 완벽한 재현 점수가 얼마나 큰 운영상 가치를 입증하느냐에 있다. 구매자는 벤치마크 실행의 성공과 자사 환경에서 신뢰할 수 있는 조사 결과를 연결하는 증거가 필요하다. 360에겐 투명한 평가 세부 정보와 검증 가능한 보안 성과를 통해 그 연결성을 보여줄 기회가 있다.

360 CyberGym 결과가 실제로 입증하는 것

보고된 결과는 알려진 취약점 재현에 관한 것이며, 정확한 평가 날짜는 여전히 불분명하다.

China.org.cn에 귀속돼 Xinhuanet이 발행한 10월 30일자 취약점 재현 보고서는 Tulongfeng의 성능을 설명했다. 이 보고서는 세 번의 평가에서 각각 99.27%, 99.47%, 99.40%의 성공률을 기록했다고 전했다. 1,507개 전체 과제를 대상으로 한 명시된 평균은 99.38%였다.

이는 보도의 발행일을 확인해 준다. 그러나 테스트가 언제 종료됐는지, 리더보드 항목이 언제 변경됐는지는 확인하지 못한다. 보고서는 결과를 최근의 것으로 표현했지만 해당 날짜를 제공하지 않았다. 따라서 독자는 10월 30일을 확정된 평가 이정표가 아닌 보도 날짜로 받아들여야 한다.

해당 보도는 Tulongfeng을 리더보드 선두로도 지칭했다. 이 순위 주장은 보고된 수치 결과와 별도로 다뤄야 한다. 공개적으로 확인된 벤치마크 페이지에는 Tulongfeng의 순위와 구성을 독립적으로 점검하기에 충분한 항목이 표시되지 않았다. 따라서 이 분석은 점수와 선두 주장 모두를 해당 보도에 귀속한다.

벤치마크 결과에는 여러 증거 층위가 있다. 공개된 발표는 누군가가 무엇을 보고했는지 보여준다. 상세 제출 자료는 평가가 어떻게 운영됐는지 설명한다. 독립 재현은 다른 팀이 비슷한 결과를 얻는지 검증한다. 이 층위들은 서로 다른 질문에 답하며, 같은 발표가 여러 웹사이트에 게시됐다고 해서 이를 대체할 수는 없다.

용어도 신중히 다뤄야 한다. 취약점 재현은 특정 소프트웨어 결함을 입증하는 입력을 생성하는 것을 의미한다. 발견은 존재 여부나 위치가 미리 제공되지 않은 결함을 식별하는 일이다. 재현 점수를 발견률로 설명하는 것은 평가가 직접 측정한 범위를 넘어서는 주장이다.

뉴스 피드에서 이 제목을 접한 독자에게 이것이 핵심적인 정정이다. 이 발표는 정의된 출발점을 갖춘 자동화된 보안 조사 과제에 관한 것이다. Tulongfeng이 임의의 소프트웨어에서 거의 모든 취약점을 찾아낸다는 것, 또는 배포된 고객이 동등한 결과를 받는다는 것을 입증하지는 않는다.

이러한 더 좁은 해석에도 중요한 발전 가능성은 남는다. 보고된 성능이 문서화된 조건에서 유지된다면, Tulongfeng은 알려진 버그 설명을 실행 가능한 증거로 전환하는 데 매우 뛰어난 시스템이 될 수 있다. 이 작업은 보고서를 받은 뒤 어떤 엔지니어링 조치가 필요한지 결정하는 과정 사이에서 실질적인 역할을 한다.

중요성은 바로 그 연결에 있다. 보안 시스템은 출력물이 누군가가 문제를 검증하고, 범위를 이해하며, 방어 가능한 결정을 내리는 데 도움이 될 때 유용해진다. 점수는 그 유용성을 평가하는 출발점이지, 완전한 설명은 아니다.

알려진 버그는 보안 에이전트에 정의된 출발점을 제공한다

CyberGym은 까다로운 조사 과제를 측정하지만, 개방형 발견에서는 먼저 찾아내야 할 정보를 제공한다.

공식 CyberGym 평가에 따르면, 주요 Level 1 설정은 취약점 설명과 패치되지 않은 코드베이스를 제공한다. 개념 증명, 즉 PoC는 특정 결함을 입증하는 실행 가능한 테스트다. 성공하려면 이 테스트가 취약한 버전에서는 결함을 유발하고 패치된 버전에서는 문제가 없어야 한다.

이는 의미 있는 엔지니어링 과제를 만든다. 소프트웨어 도구를 통해 행동하는 모델 기반 시스템인 에이전트는 서면 설명을 실제 프로그램 동작과 연결해야 한다. 그 출력은 실행 기반 검증을 통과해야 한다. 그럴듯한 설명만으로는 과제를 충족할 수 없다.

그러나 제공된 설명은 탐색 문제를 바꾼다. 시스템은 관련 취약점이 존재한다는 증거를 가지고 시작한다. 이 전제를 중심으로 조사를 구성할 수 있다. 개방형 검토에서는 어디를 탐색할지, 어떤 의심스러운 동작이 중요한지, 추가 조사가 더 많은 자원을 투입할 가치가 있는지도 판단해야 한다.

개발자 관점에서 차이를 생각해 보자. 구체적인 버그 보고서는 특정 동작을 살펴볼 이유를 제공한다. 대규모 애플리케이션을 평가해 달라는 광범위한 요청은 제약이 더 적다. 둘 다 판단을 요구하지만, 조사의 서로 다른 지점에 그 판단을 요구한다.

이 구분은 보고된 결과가 보안 공급업체에 압력을 가하면서도 시장 전체를 결론짓지는 못하는 이유를 설명한다. 자동화된 조사를 판매하는 공급업체는 구체적인 질문에 직면한다. 자사 시스템이 유사한 조건에서 그만큼 설득력 있는 증거를 낼 수 있는가? 광범위한 발견을 약속하는 공급업체는 유용한 출발점을 찾는다는 더 넓은 질문에 답해야 한다.

어느 쪽도 유창한 설명만으로 이 질문에 답할 수 없다. 취약점을 정확히 설명하는 시스템도 관련 동작을 보여줘야 한다. 반대로 설명되지 않은 실패를 만들어내는 시스템은 엔지니어에게 추가 해석 작업을 남긴다. 유용한 자동화는 가설, 테스트, 관찰된 동작, 결론을 연결한다.

벤치마크의 제한된 과제는 구매자가 역량과 적용 범위를 구분하는 데도 도움이 된다. 역량은 시스템이 특정 조사를 완료할 수 있는지 묻는다. 적용 범위는 어떤 애플리케이션, 환경, 취약점 유형을 평가할 수 있는지 묻는다. 높은 점수는 평가 범위 안에서 역량 주장을 뒷받침하지만, 적용 범위에는 추가 증거가 필요하다.

이러한 분리는 조달 논의에 영향을 미쳐야 한다. 구매자는 공급업체에 자사 시스템이 안정적으로 완료하는 작업을 설명해 달라고 요청해야 한다. “보고된 소프트웨어 취약점을 재현한다”는 표현은 자율 보안에 대한 광범위한 주장보다 더 명확한 약속을 전달한다. 또한 엔지니어가 직접 평가할 수 있는 과제를 파일럿 프로젝트에 부여한다.

따라서 운영상 영향은 구체적이다. 자동화가 재현 작업을 안정적으로 완료할 수 있다면, 분석가는 보고서가 관찰 가능한 문제를 설명하는지 확인하는 데 드는 노력을 줄일 수 있다. 남은 작업에는 영향 평가, 담당자 조율, 제안된 대응 검토가 포함된다. 초기 기술 조사가 개선되더라도 이러한 책임은 여전히 중요하다.

360은 점수 뒤에 전문화된 조율 체계를 둔다

Tulongfeng의 보고된 설계는 조율된 보안 작업을 강조하며, 시스템 아키텍처 자체를 주장의 일부로 만든다.

10월 보도는 전문 에이전트와 함께 작동하는 보안 특화 언어 모델을 설명한다. 해당 설명에 따르면, 서로 다른 역할이 가설 수립부터 검증까지 조사를 단계별로 분담한다. 제시된 장점은 보안 지식, 도구, 조율을 결합하는 데서 나온다.

이는 시스템 수준의 제안이다. 모델의 코드 추론 능력도 중요하지만, 그 주변의 프로세스도 중요하다. 주변 소프트웨어는 모델이 어떤 증거를 받는지, 어떤 행동을 취할 수 있는지, 실패한 시도를 어떻게 처리하는지를 결정한다. 이러한 선택은 최종 결과에 영향을 준다.

전문화에는 그럴듯한 근거가 있다. 관련 코드를 찾는 데 집중하는 역할은 다른 역할이 가설을 테스트할 증거를 생성할 수 있다. 검증 역할은 관찰된 동작이 원래 주장을 뒷받침하는지 평가할 수 있다. 원칙적으로 책임을 나누면 복잡한 조사를 더 쉽게 관리할 수 있다.

이 설명은 Tulongfeng이 보고된 점수를 얻은 이유에 대한 검증된 설명이 아니라 근거에 머문다. 해당 보도는 각 구성 요소의 기여도를 분리할 만큼 충분한 통제 비교를 제공하지 않는다. 조율, 모델 학습, 도구, 자원 배분 중 무엇이 가장 큰 개선을 가져왔는지도 입증할 수 없다.

유용한 비교 사례는 칭화대학교의 RedbudAI 연구다. 공개된 단일 모델 평가는 GLM-5.2를 사용해 86.2%의 성공률을 보고했으며, 별도의 반복 시도 분석에서는 93.6%에 도달했다. 저자들은 이 측정값들을 서로 바꿔 쓸 수 있는 결과로 제시하지 않고 구분한다.

RedbudAI는 각 과제에 대한 로컬 실행, 제한된 네트워킹, 지정된 최종 테스트도 설명한다. 이런 세부 정보는 결과를 더 해석 가능하게 만든다. Tulongfeng과의 통제된 비교를 입증하지는 못하지만, 수치 뒤의 운영 조건을 드러낸다.

이 비교는 더 광범위한 분석 문제를 보여준다. 단일 모델 시스템도 도구와 조사 단계를 구성하는 소프트웨어인 상당한 오케스트레이션을 포함할 수 있다. 멀티에이전트 시스템은 역할이 얼마나 독립적으로 작동하는지에 따라 크게 달라질 수 있다. 명칭만으로는 구매자에게 실제 수행 작업을 거의 알려주지 못한다.

따라서 Tulongfeng의 보고된 선두는 전문 에이전트 팀이 다른 설계보다 보편적으로 우수하다는 사실을 입증할 수 없다. 이를 입증하려면 다른 조건들을 비교 가능한 수준으로 맞춰야 한다. 그런 통제가 없다면, 결과는 완전한 구성의 성능을 설명할 뿐이다.

OpenAI, Anthropic, Google과 관련된 비교에도 같은 절제가 적용된다. 전문 보안 시스템과 에이전트 프레임워크에 연결된 범용 모델은 서로 다른 평가 대상이다. 어떠한 비교든 기반 모델에 관한 결론을 내리기 전에 전체 구성을 식별해야 한다.

개발자에게 이는 단계 간 전달되는 증거에 주목하게 한다. 조사자는 원래 가설을 보존하는가? 검증자는 관련 실행 결과를 점검하는가? 다른 엔지니어가 추론 과정을 재구성할 수 있는가? 이런 질문은 에이전트 수보다 아키텍처와 실질적 신뢰를 더 직접적으로 연결한다.

바로 이 지점에서 360의 기술적 이야기가 흥미로워진다. 이 주장은 보안 전문성이 워크플로에 어떻게 들어가고 연속된 의사결정 속에서 어떻게 유지되는지 살펴보게 한다. 상세한 공개 자료는 반복 가능한 엔지니어링 이점과 매력적인 아키텍처 설명을 구분하는 데 도움이 될 것이다.

최고점에 가까운 점수일수록 평가 세부 정보가 더 중요해진다

최대치에 가까운 결과는 채점 규칙, 자원 제한, 재현 가능한 증거의 중요성을 높인다.

CyberGym 유지관리자는 팀이 자체적으로 결과를 평가하고 제출한다고 주의를 당부한다. 또한 강력한 시스템 간의 작은 차이가 의미 있는 역량 격차를 나타내지 않을 수 있다고 경고한다. 이러한 단서는 독자가 1위라는 제목을 어떻게 해석해야 하는지에 직접적인 영향을 미친다.

높은 성능 수준에서는 순위만으로는 설명할 수 있는 범위가 제한적입니다. 구매자는 시스템 간에 과업 성공률, 자원 사용량, 신뢰성, 평가 조건에서 어떤 차이가 있는지 파악해야 합니다. 작은 수치상 우위가 중요한 운영상 단점과 공존할 수 있습니다. 반대로 더 면밀히 검토할 가치가 있는 실질적인 개선을 반영할 수도 있습니다.

공식 제출 요건은 이 문제를 인식하고 있습니다. 성공률과 함께 비용 보고를 요구하고, 모델 사용량, 과업 소요 시간, 예시 로그, 최종 결과를 요청합니다. 이러한 공개 정보는 실제로 작업을 완료하는 데 무엇이 필요했는지를 보여주는 데 도움이 됩니다.

기업 구매자에게 소요 시간은 보안 조사가 엔지니어링 일정과 경쟁하기 때문에 중요합니다. 구성은 사용 가능한 인프라에 맞아야 하므로 자원 사용량도 중요합니다. 간헐적으로 장시간 실행되는 과업은 일정 관리에 복잡성을 더할 수 있으므로 변동성 역시 중요합니다. 이러한 요소들이 높은 성공률의 가치를 부정하는 것은 아닙니다. 다만 그 실질적 가치를 결정합니다.

채점 규칙도 그만큼 주의 깊게 살펴봐야 합니다. CyberGym의 최종 제출 규칙은 시스템이 최종 답변을 지정하도록 요구합니다. 대신 성공한 후보를 모두 인정한다면 이는 다른 질문에 답하는 셈입니다. 시스템이 조사 과정에서 여러 후보를 생성할 때 이 차이는 중요해집니다.

올바른 출력을 선택하는 일 자체가 유용한 역량입니다. 엔지니어는 설명되지 않은 여러 시도를 뒤질 필요 없이 바로 활용할 수 있는 결과를 필요로 합니다. 시스템이 결국 유효한 증거를 생성하더라도, 그 증거를 인식하고 제시할 신뢰할 수 있는 방식이 여전히 필요합니다.

보고된 세 차례의 평가도 방법론적 의문을 남깁니다. 평가를 반복하면 일관성을 측정할 수 있지만, 하나의 과업 안에서 반복 기회를 제공하면 성공 지표가 달라질 수 있습니다. 공개된 내용은 Tulongfeng에 대해 이 관계를 충분히 설명하지 않습니다. 상세 문서가 있다면 실행 간에 무엇이 동일하게 유지됐는지 명확해질 것입니다.

여기서 “독립적”이라는 표현은 신중하게 써야 합니다. 별도의 실행이 반드시 별도의 외부 평가자를 뜻하는 것은 아닙니다. 검토한 보도는 외부 연구소가 전체 결과를 재현했다는 점을 확인하지 않습니다. 독자는 반복 평가에 관한 설명만으로 독립 감사를 추론해서는 안 됩니다.

네트워크 접근은 또 다른 비교 문제를 만듭니다. 과거 취약점에 이미 공개된 수정책이나 설명이 있을 경우, 공개 정보 접근은 지름길을 제공할 수 있습니다. 이는 360의 부정행위 증거가 아니라 벤치마크 전반의 우려 사항입니다. 투명한 접근 정책은 검토자가 결과가 의도된 과업을 반영하는지 평가하는 데 도움이 됩니다.

다른 구성 선택도 해석을 좌우합니다. 실행 가능한 취약 애플리케이션은 소스 코드 검사만으로는 얻을 수 없는 다른 피드백을 제공합니다. 여러 과업에 걸쳐 축적된 메모리는 이후 조사에서 시스템이 무엇을 갖고 시작하는지를 바꿉니다. 문서는 이러한 선택을 드러내어 독자가 동등한 조건끼리 비교할 수 있도록 해야 합니다.

이러한 미해결 세부 사항은 신중한 결론을 뒷받침합니다. 360 CyberGym 결과는 기술적 주목을 받을 만하지만, 확정적인 우위 주장을 하려면 더 많은 증거가 필요합니다. 방법론에 대한 불확실성은 근거 없는 비난으로 번지거나 헤드라인 아래 사라지는 대신, 후속 보도의 방향을 이끌어야 합니다.

기업 가치는 재현 이후에 무엇이 일어나는지에 달려 있다

상업적 관점에서 중요한 질문은 성공적인 조사가 보안 결정을 내리고 실행하는 데 필요한 작업을 줄여 주는지 여부입니다.

재현된 취약점은 엔지니어링 팀에 검토할 수 있는 구체적인 대상을 제공합니다. 이는 연구자, 유지보수 담당자, 애플리케이션 소유자 간의 소통을 지원할 수 있습니다. 그러나 조직은 여전히 영향을 받은 코드가 자사 환경에 존재하는지, 어떤 대응이 타당한지를 판단해야 합니다.

소프트웨어 의존성에 관한 보고서를 평가하는 가상의 팀을 생각해 보겠습니다. 시스템은 준비된 환경에서 해당 동작을 재현할 수 있습니다. 그러면 팀은 배포된 버전과 사용 방식이 같은 문제에 노출되는지 확인해야 합니다. 이 평가는 기술적 결과와 운영상 관련성을 연결합니다.

다음 결정은 보안 문제를 제거하거나 줄이기 위한 작업인 완화 조치에 관한 것입니다. 제안된 수정안은 검토와 테스트가 필요합니다. 팀은 배포 제약과 의도하지 않은 동작도 고려해야 합니다. 재현은 그 과정에서 가치 있는 증거이지만, 모든 단계를 완료해 주지는 않습니다.

이것이 벤치마크 범주가 중요한 이유입니다. CyberGym-E2E라는 별도의 엔드투엔드 벤치마크는 취약점 발견, 개념 증명 생성, 패치 생성을 다룹니다. 더 넓은 범위는 완전한 방어 수명 주기를 평가하는 데 수반되는 추가 작업을 부각합니다.

그렇다고 더 넓은 평가가 재현의 중요성을 떨어뜨리는 것은 아닙니다. 오히려 과업 간의 경계를 보여 줍니다. 조직은 발견이나 패치를 시스템에 위임하지 않으면서도 뛰어난 재현 보조 도구의 혜택을 받을 수 있습니다. 명확한 경계는 팀이 적절한 검토를 유지하면서 유용한 역량을 도입하게 합니다.

10월 보도는 Tulongfeng의 배포 사례와 취약점 발견에 대해서도 더 폭넓은 주장을 제기합니다. 이 주장들은 각각 별도의 뒷받침 증거가 필요합니다. 고객 참여, 확인된 발견, 완료된 완화 조치는 서로 다른 종류의 결과입니다. 이들을 하나의 효과성 인상으로 합쳐서는 안 됩니다.

구매자에게 가장 유익한 증거는 발견 사항과 해결 결과를 연결하는 것입니다. 해당 문제는 책임 있는 유지보수 담당자에 의해 확인됐는가? 조사가 수정에 충분한 맥락을 제공했는가? 결과를 전달받은 팀이 재현할 수 있었는가? 이러한 질문은 자동화가 조직 경계를 넘어 유용한 작업을 전달하는지 검증합니다.

또한 숨겨진 인적 노력을 드러내는 데도 도움이 됩니다. 시스템은 광범위한 환경 준비나 전문가 개입 이후에 좋은 성과를 낼 수 있습니다. 그러한 지원은 완전히 정당할 수 있습니다. 구매자는 단지 어떤 책임이 여전히 자사 직원에게 남아 있는지 이해해야 합니다.

이 인계 과정에서는 지식 관리가 중요해집니다. 엔지니어는 원본 보고서, 환경 세부 정보, 재현 기록, 검토 결정이 계속 연결되어 있어야 합니다. 검색 가능한 엔지니어링 지식 베이스는 보안 시스템의 기술적 역량과 별개로 이러한 문서화 요구를 해결합니다.

조사 담당자가 바뀔 때 이 연결은 중요합니다. 원래 운영자만 이해할 수 있는 결과는 추가 작업을 만듭니다. 문서화된 결과라면 다른 엔지니어도 가정을 검토하고 대응을 이어갈 수 있습니다. 따라서 추적 가능성은 자동화된 성공과 함께 운영 가치에 관한 논의에 포함돼야 합니다.

기업 차원의 함의는 구체적입니다. 보안 공급업체는 완전하고 검토 가능한 작업 단위를 입증해야 한다는 압박을 받고 있습니다. 360에 있어 강력한 재현 성능은 신뢰할 수 있는 출발점이 될 수 있습니다. 신뢰할 수 있는 인계와 해결된 발견에 관한 증거는 이 역량이 일상적인 보안 운영으로 어디까지 확장되는지를 보여 줄 것입니다.

세 가지 신호가 결과를 명확히 할 것이다

다음으로 유용한 증거는 제출된 구성, 그 효율성, 그리고 과거 사례 재현을 넘어선 결과에 관한 것입니다.

첫째, 보고된 점수를 구체적인 벤치마크 구성과 연결하는 상세한 Tulongfeng 평가 공개를 지켜봐야 합니다. 여기에는 모델, 도구 접근 권한, 채점 규칙, 대표적인 조사 기록이 포함돼야 합니다. 이를 통해 독자는 보고된 결과가 정확히 무엇을 설명하는지 이해할 수 있습니다.

명확한 공개는 이 주장의 범위에 대한 신뢰를 높일 것입니다. 외부 검토도 더 현실적으로 만들 것입니다. 문서가 헤드라인의 백분율에만 머문다면, 신뢰의 범위도 그에 상응해 제한돼야 합니다. 설명 자료가 없다고 해서 보고된 결과가 거짓이라는 뜻은 아니지만, 의문은 해소되지 않은 채 남습니다.

둘째, 360과 다른 보안 에이전트 개발사의 비교 가능한 효율성 공개를 지켜봐야 합니다. 과업 소요 시간, 모델 사용량, 자원 요구 사항은 서로 다른 시스템이 어떻게 결과를 얻는지 보여 줄 것입니다. 이러한 측정치는 구매자가 과업 완료와 함께 운영 적합성을 평가하는 데 도움이 됩니다.

검토 가능한 증거를 일관되게 생성하는 효율적인 시스템은 더 강력한 도입 근거가 될 것입니다. 광범위한 자원을 요구하는 구성도 전문 조사를 위한 용도에는 적합할 수 있습니다. 핵심은 높은 점수를 받은 모든 시스템이 같은 배포 범주에 속한다고 가정하는 것이 아니라, 어떤 작업량을 담당하는지 파악하는 데 있습니다.

셋째, 과거 평가 범위를 벗어난 소프트웨어에서 문서화된 발견과 완화 결과를 지켜봐야 합니다. 유지보수 담당자의 확인, 재현 가능한 증거, 완료된 수정은 더 폭넓은 발견 주장에 구체적인 근거를 제공할 것입니다. 명확한 보고는 새로 확인된 문제와 알려진 문제의 재현 또는 변형을 구분해야 합니다.

이러한 신호는 앞으로 몇 달간의 보도를 이끌어야 합니다. 이는 누가 보안 자동화를 주도할지 예측할 필요 없이 Tulongfeng의 보고된 성능에 대한 해석을 강화하거나 좁힐 것입니다. 현재의 핵심 뉴스는 주장 그 자체와 이를 뒷받침하는 엔지니어링 접근 방식입니다.

개발자와 보안 구매자는 워크플로를 바꾸기 전에 증거를 살펴보라는 계기로 360 CyberGym 결과를 활용해야 합니다. 시스템이 어떤 과업을 완료했는지, 어떤 정보를 받았는지, 검토자가 최종 출력을 어떻게 확인했는지 물어보십시오. 그런 다음 그 답을 팀이 실제로 마쳐야 하는 조사와 연결하십시오. 보고된 점수를 구성, 한계, 뒷받침 기록과 함께 검토하십시오. 상세 자료나 확인된 발견이 나올 때 이 평가를 다시 살펴보십시오. 공급업체를 비교하고 있다면 각 업체에 동일한 공개 정보를 요청하십시오. 어떤 시스템이 엔지니어에게 독립적으로 이해하고, 재현하고, 보안 문제 해결에 활용할 수 있는 결과를 남겨 줍니까?