Schneier의 AI 취약점 발견 주장, 소프트웨어 수정 역량에 압박
Bruce Schneier가 11월 2일 공개한 기사 요약은 놀라운 주목을 끄는 주장을 부각한다. 역사적으로 기록된 심각한 소프트웨어 취약점의 3%가 한 달 안에 발견됐다는 것이다. 그가 올린 AI Vulnerability Finding 게시물에서 제공된 발췌문은 매년 약 10만 건의 추가 발견이 이뤄질 것으로도 전망한다. 이 수치는 여기서 검증되지 않았지만, 문서화된 발견 사례만으로도 소프트웨어 수정 책임을 맡은 팀에는 이미 압박이 가해지고 있다.
핵심 갈등은 발견 속도와 수정 역량 사이에 있다. 보안 결함을 찾아내면 사용자를 보호할 기회가 생긴다. 동시에 해야 할 일도 생긴다. 누군가는 제보를 검증하고, 노출 범위를 평가하며, 수정안을 검토하고, 업데이트를 배포해야 한다. 발견 과정을 자동화한다고 해서 그 이후의 모든 의사결정까지 자동으로 빨라지는 것은 아니다.
Anthropic, Google, Mozilla는 유용한 참고 사례를 제공하지만, 각 수치는 서로 다른 대상을 측정한다. 이들의 발표는 보다 좁지만 중요한 결론을 뒷받침한다. 자동화된 보안 연구가 실제 발견 성과를 내고 있는 반면, 집계 방식과 후속 결과는 면밀한 검토가 필요하다는 것이다. 개발자와 기업 구매자에게 중요한 질문은 더 빠른 발견이 실제 노출 감소로 이어지는지다.
AI Vulnerability Finding 주장이 실제로 입증하는 것
헤드라인 수치는 연구 단서일 뿐, 전 세계 심각한 소프트웨어 결함을 독립적으로 확립한 측정치는 아니다.
Schneier의 취약점 발견 게시물과 연관된 제공 발췌문은 해당 수치를 댓글로 제시한다. 이 검토에서는 원문 페이지를 가져오지 못했다. 따라서 이 발췌문만으로는 누가 해당 비율을 계산했는지, 어떤 기록을 집계했는지, 보고 기간을 어떻게 정의했는지 알 수 없다.
이 구분은 이 주장으로부터 책임 있게 도출할 수 있는 내용의 범위를 제한한다. 눈에 띄는 비율은 특정 데이터베이스를 정확히 설명할 수 있지만, 지금까지 발견된 모든 보안 취약점을 설명하지는 않을 수 있다. 독자가 원래의 분모 대신 더 넓은 모집단을 암묵적으로 대입하면 오해를 낳을 수도 있다.
발견, 공개, 데이터베이스 등록은 서로 다른 사건이다. 연구자는 공급업체가 확인하기 전에 결함을 비공개로 식별할 수 있다. 공개 문서는 소프트웨어 업데이트와 함께 나중에 나올 수 있다. 따라서 월간 등록 급증이 그 달에 모든 기저 결함이 발견됐음을 입증하지는 않는다.
“기록된 모든 역사”라는 표현은 또 다른 미해결 경계를 더한다. 감사 가능한 계산에는 명시된 데이터베이스, 날짜가 명확한 스냅샷, 일관된 포함 규칙이 필요하다. 중복 기록, 거부된 제출, 공개 후 심각도 등급이 바뀐 취약점을 어떻게 처리했는지에 대한 설명도 필요하다.
연간 전망에는 별도의 가정이 들어간다. 최근 속도가 계속될 것이라는 가정이다. 원래의 월간 건수가 정확한 것으로 입증되더라도 이 가정은 검토할 가치가 있다. 집중적인 연구 캠페인, 공개 적체, 조율된 릴리스는 안정적인 연간 비율을 입증하지 못한 채 일시적인 급증을 만들 수 있다.
범주상의 문제도 있다. 발췌문은 심각한 취약점으로 시작하지만 이후에는 버그와 역사적 취약점 총수를 더 폭넓게 언급한다. 기초 계산을 확인하지 않은 채 이 범주들을 서로 바꿔 쓸 수는 없다. 소프트웨어 결함, 확인된 보안 취약점, 심각한 취약점은 서로 다른 모집단을 뜻한다.
이러한 한계가 더 큰 흐름의 중요성을 약화시키는 것은 아니다. 다만 신뢰가 어디에서 멈춰야 하는지를 보여 준다. 방어 가능한 서사는 정밀하게 측정된 역사적 전환점에 관한 뒷받침되지 않은 주장보다, 문서화된 발견 활동과 그 운영상 결과에 관한 것이다.
소셜 게시물을 통해 AI Vulnerability Finding을 접하는 독자에게 이 구분은 유용한 통찰을 보호해 준다. 보안팀은 지금 자신의 역량을 점검할 이유가 있다. 자체 발견 및 수정 과정의 균형이 무너지고 있는지 살피기 전에 검증되지 않은 비율을 받아들일 필요는 없다.
Anthropic의 보고된 결과는 중요한 경계와 함께 규모를 보여 준다
Anthropic이 공개한 수치는 상당한 발견 성과 주장을 뒷받침하지만, 댓글의 역사적 비율이나 월간 추정을 검증하지는 않는다.
Anthropic은 10월 6일 사이버 검증 프로그램 발표에서 4월부터 7월까지 파트너 전반에서 최소 129,000건의 검증된 소프트웨어 취약점을 보고했다고 밝혔다. 또한 4월부터 10월까지 진행한 오픈소스 스캐닝에서 5,500건의 검증된 발견을 별도로 보고했다.
회사는 33,000건이 넘는 검증된 취약점이 심각 또는 높음 등급을 받았다고 밝혔다. 이는 독립적으로 재현된 전수조사가 아니라 회사가 보고한 결과다. 기간과 범주 역시 한 달 안에 발견된 심각한 취약점에 관한 제공 댓글의 주장과 다르다.
Anthropic은 중요한 한계도 공개했다. 영향 보고는 33개 파트너의 부분적인 정보를 바탕으로 했으며, 조직마다 서로 다른 트리아지 방식을 사용했다. 절반 미만만 패치 건수를 제공했다. 이에 따라 회사는 보고된 패치율이 상당히 불완전하다고 설명했다.
이러한 경계가 중요한 이유는 서로 다른 측정치가 서로 다른 질문에 답하기 때문이다. 발견 건수는 보고된 발견 산출량을 측정한다. 확인 건수는 검증 단계를 추가한다. 패치 건수는 이후 결과를 설명하며, 배포 증거는 영향을 받은 사용자가 실제 보호를 받았는지를 다룬다.
따라서 경쟁적 함의도 좁게 유지해야 한다. Anthropic은 자사 모델을 사용한 참여 조직의 결과를 보고하고 있다. Google의 위협 연구자들은 더 넓은 공개 및 악용 패턴을 검토한다. 이 발표들은 상호 보완적인 관점을 제공하지만, 어느 공급업체가 더 나은 보안 결과를 내는지 입증하는 통제된 비교를 제공하지는 않는다.
구매자에게 이는 발견 총계가 논의를 시작하는 지점이어야지 결론을 내리는 근거가 되어서는 안 된다는 뜻이다. 더 많은 발견을 생성하는 공급업체는 간과된 문제를 찾아낼 수 있다. 하지만 특히 보고서에 명확한 재현 증거나 영향을 받는 버전 정보가 없으면 고객의 검토 시간도 더 많이 요구할 수 있다.
유용한 평가는 새로운 수용 취약점과 이전에 알려진 문제, 중복 보고를 구분할 것이다. 제안된 수정과 검토된 수정도 분리해야 한다. 이러한 구분은 비교를 어렵게 하지만, 기술적 산출물을 고객이 수행해야 하는 작업과 연결한다.
특히 전담 보안 인력이 많지 않은 상태에서 중요한 소프트웨어를 소유한 조직에 압박이 크게 가해진다. 발견 역량은 구매하거나 빌릴 수 있다. 하지만 제보를 수용하고 제품을 바꾸는 책임은 원래의 분석이 자동으로 도착하더라도 여전히 누군가가 맡아야 한다.
이는 보고된 규모에서 도출되는 분석적 함의이지, 업계 전체의 인력 결과를 측정한 것은 아니다. 들어오는 검증된 보고가 늘어나는데 검토 역량이 고정돼 있다면 미해결 대기열은 커진다. 정확한 비율은 각 조직의 소프트웨어, 도구, 안전한 변경 수행 능력에 따라 달라진다.
그래서 Anthropic 발표 이후 가장 유용한 후속 질문은 완료에 관한 것이다. 수용된 발견 중 몇 건이 지원되는 릴리스에 도달했는가? 얼마나 오래 미해결 상태로 남아 있었는가? 비교 가능한 답변이 없다면 큰 발견 수치는 노출 감소보다 활동량을 더 명확히 보여 준다.
소프트웨어 유지관리자는 발견 이후의 작업을 떠안는다
취약한 소프트웨어를 유지관리하는 조직은 보고서를 보호 조치로 전환하는 운영 부담을 짊어진다.
NIST의 4월 15일 취약점 데이터베이스 변경 사항은 보안 업무를 둘러싼 정보 인프라에 가해지는 압박을 보여 준다. 이 기관은 취약점 제출 건수가 2020년부터 2025년 사이 263% 증가했다고 보고했다. 더 높은 처리량에도 불구하고 속도를 따라잡을 수 없었다고 밝혔다.
NIST는 공개 취약점 정보 저장소인 National Vulnerability Database에서 항목을 보강하는 방식을 바꿨다. 보강은 심각도 점수와 영향을 받는 제품 같은 세부 정보를 추가한다. 개정된 방식에 따라 선정된 범주가 우선순위를 받으며, 다른 항목은 즉각적인 보강 없이 계속 등재된다.
이 기관은 알려진 악용 취약점, 연방정부 내에서 사용되는 소프트웨어, 정의된 핵심 소프트웨어를 우선시했다. 또한 이러한 기준이 잠재적으로 중대한 모든 문제를 포착하지는 못할 것이라고 인정했다. 이 변경은 역량 제약을 문서화하지만, AI가 근본적인 제출 증가를 유발했다고 입증하지는 않는다.
더 넓은 함의는 증가하는 발견 흐름에 추가 데이터베이스 행만으로는 충분하지 않다는 것이다. 유지관리자와 고객은 무엇에 주목할 가치가 있는지 판단할 신뢰할 수 있는 맥락이 필요하다. 누락되거나 지연된 맥락은 해석 업무를 이미 자체 시스템 평가 책임을 지고 있는 팀으로 옮길 수 있다.
소프트웨어 유지관리자에게 신뢰할 수 있는 제보를 받는 일은 그 결론을 읽는 것만으로 축소할 수 없는 여러 의무를 만든다. 영향을 받는 동작을 이해해야 한다. 제안된 수정은 주변 설계에 맞아야 한다. 지원되는 버전과 종속 구성요소에는 별도의 결정이 필요할 수 있다.
기업 사용자는 또 다른 해석 층위에 직면한다. 취약한 구성요소는 직접 유지관리하는 것이 아니라 구매한 제품 안에 포함돼 있을 수 있다. 어떤 설치 버전이 영향을 받는지, 취약한 동작에 접근할 수 있는지, 공급업체가 어떤 조치를 지원하는지 알아야 한다.
이는 모든 조직이 동일한 적체를 겪고 있다는 발견이 아니라, 운영상 의존성을 설명하는 사례다. 그 중요성은 발견과 완화, 즉 취약점을 수정하거나 줄이는 과정의 구분에서 나온다. 누군가 이에 관해 정보에 기반한 결정을 내릴 수 있을 때만 보고서는 가치를 갖는다.
인센티브 불일치에도 주목할 필요가 있다. 발견 플랫폼은 즉시 발견 사례를 공개할 수 있지만, 유지관리자는 신중한 검토와 별문제 없는 업데이트로는 눈에 덜 띄는 공로를 얻는다. 구매자는 보고량과 유지관리 품질이 보안에 대한 서로 다른 기여를 나타낸다는 점을 인식해야 한다.
결정이 팀을 넘나들 때는 공동 문서화가 유용해진다. 검색 가능한 지식 베이스는 기술 기록, 책임 결정, 뒷받침 증거를 연결하는 데 도움이 될 수 있다. 이는 조정을 지원하지만, 검증과 릴리스 승인은 여전히 적절한 엔지니어링 프로세스를 필요로 한다.
실질적인 압박은 기술적인 만큼 조직적이다. 더 빠른 발견은 보고서, 수정, 배포 결정의 책임 소재를 더 명확히 하도록 강제한다. 이러한 책임이 모호하게 남아 있으면, 정당한 발견이 더 많이 유입될수록 제품을 개선하기 전에 대응 프로세스의 약점이 드러날 수 있다.
Mozilla는 발견에 완전한 수정 프로세스가 필요한 이유를 보여 준다
Mozilla의 설명은 AI 지원 발견이 배포된 소프트웨어 변경과 연결된 구체적인 사례를 제공한다.
Mozilla의 Firefox 강화 파이프라인 보고서는 모델을 테스트 인프라 및 보안 버그 수명주기와 통합한 과정을 설명한다. 팀은 유의미한 규모를 위해 재현 가능한 테스트, 중복 탐지, 트리아지, 추적, 릴리스 작업이 필요했다고 말한다. Firefox 150에서 Mythos Preview 발견 사항 271건을 수정했다고 보고했다.
해당 계정은 데이터베이스 총계를 신중하게 다뤄야 하는 이유도 설명한다. Mozilla는 내부적으로 보고된 여러 버그를 하나의 공통 취약점 식별자 아래에 묶는다. 따라서 보고된 버그 수는 공개 식별자 수와 직접적으로 일치하지 않는다. 이 관계를 설명하지 않은 채 어느 한 집단을 집계하면 독자를 오도할 수 있다.
Mozilla는 심각한 버그와 실제 침해 가능성도 구분한다. 계층형 브라우저 설계상 공격자가 보호 경계를 넘으려면 여러 취약점이 필요할 수 있다. 높은 심각도 분류는 해결할 가치가 있는 문제를 가리키지만, 완전한 공격이 이미 구축됐다는 뜻은 아니다.
보고된 이러한 세부 사항은 발견 건수만으로는 얻을 수 없는 더 유용한 사례 연구를 이룬다. 자동화된 탐지와 릴리스 사이에서 어떤 일이 벌어지는지를 유지보수자가 논의하는 모습을 보여 준다. 또한 사용자가 수정 사항을 받기 전에 모델의 출력이 거쳐야 하는 제도적 지식도 드러낸다.
분석적 교훈은 모델 역량과 조직 역량이 서로 곱해진다는 점이다. 실제 문제를 찾아내는 시스템도 누군가 이를 재현하거나 평가하지 못하면 제공하는 보호는 제한적이다. 성숙한 대응 절차는 엔지니어가 활용할 수 있는 형태로 도착한 증거에서 더 큰 가치를 얻는다.
이 관계는 조달 비교도 까다롭게 만든다. 신중하게 준비된 프로젝트 환경 안에서 평가된 모델은 빌드 도구, 테스트 인프라, 코드에 정통한 유지보수자의 도움을 받는다. 고객은 동일한 모델을 익숙하지 않은 애플리케이션에 적용한다고 해서 동등한 결과를 기대할 수 없다.
널리 재사용되는 라이브러리와 관련된 가상의 보고서를 생각해 보자. 초기 증거는 테스트 환경에서 충돌이 발생함을 입증할 수 있다. 유지보수자는 여전히 원인을 이해하고, 영향을 받는 버전을 확인하며, 제안된 수정이 근본 원인을 해결하는지 판단해야 한다.
알려진 결함의 재유입을 막는 검증인 회귀 테스트는 수정 사항을 유지하는 데 도움이 된다. 릴리스 커뮤니케이션은 영향을 받는 동작을 정확하게 설명해야 한다. 이후 해당 라이브러리를 통합한 제품의 하위 사용자에게는 적합한 업데이트 경로가 필요하다.
이 가상 사례는 추가적인 실제 사건을 주장하는 것이 아니라 워크플로를 설명한다. 같은 발견 사항이 연구자, 라이브러리 유지보수자, 제품 공급업체, 기업 운영자에게 왜 작업을 발생시킬 수 있는지 보여 준다. 각 참여자는 보호에 이르는 경로의 서로 다른 부분을 통제한다.
여기에는 긍정적인 순환이 형성될 가능성이 있다. 더 나은 증거는 보고서를 해석하는 데 드는 시간을 줄여 실제 수정 작업에 더 많은 주의를 기울이게 할 수 있다. 검토된 수정과 유용한 테스트는 이후 자동화 분석에 활용 가능한 환경을 개선할 수 있다. 이 순환이 현실화될지는 구현과 측정된 결과에 달려 있다.
반대의 경우도 가능하다. 제대로 정리되지 않은 발견 사항은 더 강력한 보고서를 해결하는 데 필요한 주의를 소모할 수 있다. 핵심 구분은 단순히 사람의 연구와 자동화된 연구의 차이가 아니다. 유지보수자가 행동할 수 있도록 돕는 증거와, 해결되지 않은 조사 작업을 수신자에게 떠넘기는 출력의 차이다.
심각도 레이블만으로는 검증 격차를 해소할 수 없다
치명적 레이블, 공개 식별자, 관찰된 악용은 보안 문제의 서로 다른 차원을 설명한다.
Common Vulnerability Scoring System(CVSS)은 정의된 기술적 특성을 통해 취약점 심각도를 설명하는 프레임워크다. FIRST의 심각도 점수 산정 명세는 9.0에서 10.0 사이의 점수를 치명적으로 분류한다. 그러나 이 분류만으로 특정 조직에서 공격자가 결함을 악용하고 있는지는 확인할 수 없다.
마찬가지로 Common Vulnerabilities and Exposures 식별자인 CVE는 공개된 취약점에 공통 참조값을 부여한다. 이는 동일한 기술적 범위를 보편적으로 측정하는 단위가 아니다. 집계 수는 부분적으로 문제가 할당되고 표현되는 방식에 따라 달라진다.
따라서 원래의 백분율을 엄밀하게 평가하려면 시간 전반에 걸쳐 일관된 규칙이 필요하다. 분자와 분모는 호환 가능한 모집단과 심각도 정의를 사용해야 한다. 그렇지 않으면 계산은 정밀해 보이면서도 서로 다른 기록을 결합할 수 있다.
그에 못지않게 중요한 시점 문제도 있다. 분자가 최근 공개된 기록을 집계한다면, 이는 공개 활동을 측정하는 것이다. 이를 발견 활동이라고 부르려면 근본 문제가 언제 발견됐는지에 관한 추가 증거가 필요하다. 보고 지연은 이 사건들을 분리할 수 있다.
Google의 9월 30일 공개 및 악용 분석은 더 폭넓은 맥락을 제공한다. 연구진은 2026년 1월 5,045건, 8월 10,740건의 공개가 있었다고 보고했다. 또한 할당 정책과 공급업체 공개 주기가 원시 총계의 해석을 복잡하게 만든다고 경고했다.
연구진은 악용을 별도로 추적했으며 CVSS 범주가 아닌 자체 위험 등급을 사용했다. 이 방법론적 차이는 중요하다. 분석에서 나온 위험 범주를 아무 설명 없이 치명적 심각도 점수로 바꿔 부르면 안 된다. 비슷한 표현이 서로 다른 분류 체계를 상호 교환 가능하게 만들지는 않는다.
이러한 발견은 인과관계 주장에 신중해야 한다는 점을 뒷받침한다. 공개 증가가 AI 사용 확대와 동시에 발생할 수는 있지만, AI가 그 증가 전체를 설명한다고 입증하지는 않는다. 보고 방식, 적용 범위, 공개 관행의 변화도 검토해야 한다.
관찰된 악용에도 한계가 있다. 모니터링 데이터세트에 없는 취약점이 반드시 안전하거나 손대지 않은 상태라는 뜻은 아니다. 반대로 공개 총계가 크다고 해서 성공적인 침해가 그만큼 크게 늘었다는 사실이 입증되는 것도 아니다. 가시성과 표본 추출은 연구자가 관찰할 수 있는 것에 영향을 미친다.
따라서 가장 강력한 회의적 입장은 실제 기술적 진전을 인정하면서도 엄격한 측정을 요구한다. 이는 모든 기업 보고서를 일축하라는 뜻이 아니다. 특히 그 결론이 과거 총계나 향후 연간 산출량으로 확장될 때, 제시된 증거가 구체적인 결론을 뒷받침하는지 묻는 것이다.
AI Vulnerability Finding에서 해결되지 않은 질문은 자동화 시스템이 실제 결함을 식별할 수 있는지 여부가 아니다. 인용된 프로젝트 설명은 이미 그보다 좁은 주장을 뒷받침한다. 불확실성은 비교 가능한 모집단 전반의 규모, 증가에 대한 책임, 그리고 발견이 지속적인 보호로 전환되는 비율에 관한 것이다.
이 구분은 공개 논의를 이끌어야 한다. 모든 결함을 즉각적인 재앙으로 취급하면 우선순위 설정이 무너질 수 있다. 불확실한 집계 통계를 근거로 문서화된 발견을 무시하는 것도 반대 방향의 실수다. 증거가 주장 범위와 대응의 긴급성을 결정해야 한다.
확인된 수정, 릴리스 시점, 독립적 재현을 지켜보라
다음으로 유용한 증거는 발견 산출물을 승인된 발견 사항, 제공된 수정, 재현 가능한 결과와 연결할 것이다.
향후 몇 달간은 먼저 Anthropic과 참여 조직에서 더 완전한 보고가 나오는지 살펴봐야 한다. 유용한 진전은 어떤 발견 사항이 승인되고, 수정되고, 지원되는 릴리스에 포함됐는지를 보여 주는 대응 집계다. 비교 가능한 보고는 기존 발견 주장을 더 쉽게 평가하게 해 줄 것이다.
더 강력한 설명은 중복 보고와 관련 결함을 어떻게 처리했는지 밝힐 것이다. 또한 비공개로 유지되는 소프트웨어와 문서를 검토할 수 있는 공개 프로젝트를 구분할 것이다. 아울러 중첩되거나 크기가 다른 기간 간 비교를 피하도록 보고 기간을 명확히 제시할 것이다.
이 정보가 완료된 수정과 함께 발견 증가를 보여 준다면, 방어 역량이 향상됐다는 근거는 더 강해질 것이다. 확인된 발견 사항이 이에 상응하는 릴리스 증거 없이 누적된다면, 발견이 대응을 앞지르고 있다는 우려를 강화할 것이다. 불완전한 보고만으로는 결과가 불확실하게 남는다.
둘째, 승인된 보고와 이용 가능한 업데이트 사이의 시점을 지켜봐야 한다. 결함을 수정하기 위한 소프트웨어 변경인 패치는 중간 이정표다. 지원되는 릴리스는 그 수정을 사용자에게 제공하며, 배포 여부가 영향을 받는 환경이 이를 받는지를 결정한다.
개별 문제가 여전히 너무 오래 대기하더라도 처리량은 개선될 수 있기에 이 간격은 중요하다. 팀은 전체적으로 더 많은 보고를 마감하면서도 어려운 사례의 대기열은 계속 늘어날 수 있다. 완료된 수정만 보고하면 해결되지 않은 항목은 숨겨진다.
더 짧고 지속 가능한 수정 주기의 증거는 자동화된 발견이 운영 보안을 개선할 수 있다는 주장을 강화할 것이다. 미해결 대기열이 늘어나거나 이전 수정에 대한 반복적인 재수정이 발생한다면 그 주장은 약화될 것이다. 두 결과 모두 주목할 만하며, 헤드라인의 발견 총계와 함께 살펴봐야 한다.
셋째, 유지보수 자원이 서로 다른 프로젝트 전반에서 독립적인 재현이 이뤄지는지 살펴봐야 한다. 광범위한 테스트를 거친 브라우저의 결과는 유익하지만, 모든 애플리케이션이나 라이브러리에서 동등한 결과를 입증하지는 않는다. 더 폭넓은 증거에는 문서화된 환경, 승인된 발견 사항, 필요한 작업에 관한 명확한 설명이 필요하다.
유지보수자가 단순히 공급업체의 총계를 지지하는 대신 자체 평가를 공개할 때 재현은 특히 유용하다. 발견의 타당성과 수정에 대한 합의는 설득력 있는 출력을 만들어 내는 시연보다 더 많은 정보를 제공한다. 이견은 집계 통계가 가리는 한계를 드러낼 수 있다.
이 신호들은 궁극적으로 누가 가장 큰 이익을 얻는지에 대한 예측에 의존하지 않고 진전을 평가할 방법을 제공한다. 공격자와 방어자는 관련 역량을 활용할 수 있지만, 목표와 운영 제약은 다르다. 결과는 접근성, 구현, 그리고 보호 조치가 영향을 받는 시스템에 얼마나 빠르게 도달하는지에 달려 있다.
원래의 의견은 AI Vulnerability Finding을 둘러싼 놀라움을 포착하지만, 놀라움은 면밀한 검토의 출발점이다. 백분율의 근거가 된 데이터세트를 요구하라. 어떤 심각도 규칙이 적용되는지, 날짜가 발견을 설명하는지 공개를 설명하는지 물어라. 그런 다음 확인, 수정, 릴리스를 거쳐 발견 사항을 추적하라. 보안 도구를 평가한다면 자체 팀이 재현할 수 있는 증거와 유지보수자가 인정하는 결과를 요청하라. 소프트웨어 공급업체에 의존한다면 영향을 받는 버전과 완료된 수정을 어떻게 전달하는지 물어라. 연간 전망을 되풀이하기 전에 근본 프로젝트 설명을 읽어라. 유용한 질문은 구체적이다. 발견이 가속화될 때, 소프트웨어를 책임지는 조직은 그 증거를 보호로 전환할 수 있는가?
