CISA, 업그레이드 창 공격 이후 WordPress 취약점을 KEV 카탈로그에 추가

CISA는 11월 3일 WordPress Core 취약점 한 건을 Known Exploited Vulnerabilities 카탈로그에 추가하며, 업그레이드 창 취약점을 실제 악용 범주로 분류했다. CISA WordPress KEV 등재는 특정 Core 업데이트 중 원격 코드 실행을 허용하는 취약점의 보안 식별자인 CVE-2026-119977에 관한 것이다. 패치는 이미 존재한다. 이제 조직은 해당 패치를 설치했는지, 이전 업데이트 과정에서 서버가 노출됐는지를 확인해야 한다는 즉각적인 압박을 받는다.

캐나다 사이버 보안 센터는 WordPress 보안 권고문에서 이 카탈로그 추가 사실을 확인했다. WordPress는 이미 수정 버전을 배포한 상태였으므로, 이번 변화는 새로운 소프트웨어 출시가 아니라 악용 상태의 변경이다. 이 구분은 해결되지 않은 보안 티켓 중 무엇에 즉시 대응해야 할지 결정하는 관리자에게 중요하다.

핵심적인 긴장은 제한적인 공격 기회와 공격자들이 실제로 이를 노리고 있다는 증거 사이에 있다. Wordfence는 인증 없이 가능한 코드 실행 취약점으로 설명하는 반면, Patchstack은 취약한 업데이트 창에 도달하기 어렵다는 점을 강조한다. 이제 조직은 이러한 평가와 카탈로그 추가 사실을 함께 검토해야 한다. 웹사이트 소유자, 호스팅 제공업체, 연방 보안팀에게 업데이트된 버전은 그에 따른 질문의 일부에만 답할 뿐이다.

CISA WordPress KEV 등재가 바꾸는 점

수정 소프트웨어는 이미 이용 가능했지만, 카탈로그 추가는 완화 조치 결정의 근거를 바꾼다.

Known Exploited Vulnerabilities, 즉 KEV 항목은 CISA가 실제 환경에서 악용되고 있다고 인식한 취약점을 뜻한다. 이번 사건에서 캐나다 권고문은 11월 3일 추가 사실을 독립적으로 뒷받침하며, 관리자에게 필요한 업데이트를 적용하라고 권고한다. 실질적인 결과는 영향을 받는 설치 환경을 일반 유지보수 대기열에서 더 신속히 제외해야 할 이유가 강해졌다는 것이다.

악용 지정 전에는 관리자가 흔히 기술적 심각도와 공격자 관심에 관한 불확실성을 저울질해야 한다. 하지만 이후에는 연기를 정당화하기가 더 어려워진다. 호환성 문제는 여전히 주의를 기울일 가치가 있지만, 이제는 실제 운영상 위협의 증거와 경쟁해야 한다. 이는 유지보수 승인을 책임지는 사람에게 제시되는 결정의 성격을 바꾼다.

이 구분은 발표를 오해하는 것을 막기도 한다. CISA는 11월 3일 WordPress 패치를 배포하지 않았다. 또한 카탈로그 추가가 모든 취약한 웹사이트가 침해를 겪었다는 사실을 입증하는 것도 아니다. 이는 기존 소프트웨어 취약점을 둘러싼 알려진 위협 맥락을 바꾼다.

여러 웹사이트를 관리하는 조직에서는 이 문제가 내부 보고에 나타나는 방식도 달라져야 한다. 사용 가능한 보안 업데이트를 설명하는 티켓은 통상적인 일정 조정의 여지를 남긴다. 실제 악용된 취약점을 식별하는 티켓에는 남아 있는 노출에 대한 명시적인 설명이 필요하다. 담당 팀은 어떤 사이트가 여전히 영향을 받는지, 그리고 누가 그 완화를 승인할 수 있는지 설명해야 한다.

외부 웹 에이전시에 의존하는 마케팅 사이트를 가진 가상의 회사를 생각해 보자. 회사는 게시 일정을 통제하고, 에이전시는 WordPress를 관리하며, 호스팅 제공업체는 서버 설정을 통제한다. 악용 통지가 보안팀에 도달하더라도, 이러한 책임이 자동으로 이전되지는 않는다. 그 결과 각자가 대응의 일부를 통제하는 사람들 사이에 책임 공백이 발생한다.

이 상황에서는 경보를 전달하는 것만으로 충분하지 않다. 회사는 에이전시가 영향을 받는 설치 환경을 식별했고, 호스팅 제공업체가 관련 서버 노출을 처리했다는 증거가 필요하다. 이는 별개의 운영 질문이다. 사이트가 자동 업데이트를 받는다는 일반적인 설명은 어느 쪽의 답도 입증하지 못한다.

따라서 CISA WordPress KEV 등재는 연방 규정 준수 이상의 의미를 갖는다. 민간 조직이 이전의 유지보수 결정을 재검토할 구체적인 이유를 제공한다. 유용한 질문은 기존 대응이 새롭게 확인된 위협 상태를 반영하는지 여부가 된다. 낮은 우선순위로 표시된 오래된 티켓은 새 평가를 받아야 한다.

이는 취약점 관리와 사고 평가도 구분한다. 수정된 소프트웨어를 설치하면 앞으로의 취약한 상태는 해결된다. 공격자가 이미 그 상태를 이용했는지 판단하려면 다른 증거가 필요하다. 두 결과를 동등한 것으로 취급하면 조직이 무슨 일이 있었는지 이해하기 전에 보안 이슈를 종료할 위험이 있다.

WordPress 업그레이드 취약점은 유지보수 작업 안에 존재한다

취약한 작업은 WordPress 유지보수의 일부이므로, 업데이트 과정 자체가 노출 평가와 관련이 있다.

TOCTOU(time-of-check time-of-use) 경쟁 조건은 리소스를 확인하는 시점과 사용하는 시점 사이에 보안 가정이 더는 성립하지 않는 결함이다. 여기서 문제는 WordPress Core 업그레이드에 사용되는 임시 파일과 관련된다. 원격 코드 실행은 공격자가 영향을 받는 서버에서 자신이 제어하는 코드를 실행하게 할 수 있음을 뜻한다.

Wordfence의 업그레이드 창 취약점 기록에 따르면, 예측 가능하고 웹에서 접근 가능한 스테이징 경로가 전체 패키지 Core 업그레이드 중 공격 기회를 만든다. 이 기록은 영향을 받는 릴리스 범위와 그에 대응하는 수정 버전을 식별한다. 또한 인증된 WordPress 계정이 필요 없는 공격자를 설명한다.

이 메커니즘은 일반적인 로그인 중심 평가가 왜 관련 질문을 놓칠 수 있는지 설명한다. 조직은 강력한 관리자 비밀번호와 제한된 게시 권한을 갖추고도 업데이트 환경을 검토해야 할 수 있다. 이러한 보호 조치는 서로 다른 접근 경로를 다룬다. 그 존재가 이 특정 취약점에 도달할 수 없다는 증거가 되어서는 안 된다.

WordPress 업그레이드 취약점은 유지보수 상태에 대한 단순한 해석에도 도전한다. 최근 업데이트를 보여주는 대시보드는 설치된 소프트웨어에 관한 유용한 사실을 확인해 준다. 그러나 업데이트가 실행되는 동안 존재했던 모든 조건을 설명하지는 않는다. 이전 노출을 검토할 때 이 차이를 이해하는 것이 필요하다.

예시적인 호스팅 환경으로, 자동화된 유지보수 서비스를 공유하는 여러 고객 웹사이트를 상상해 보자. 이 서비스는 각 고객에게 업데이트 완료를 보고한다. 고객은 그러한 보고를 유지보수가 수행됐다는 확인으로 합리적으로 해석한다. 그러나 보안 검토자는 업데이트 작업이 웹 서버를 통해 임시 파일을 노출했는지 여전히 파악해야 한다.

이는 업데이트에 반대하는 주장을 뒷받침하지 않는다. 수정 버전의 적용을 지연하면 취약한 소프트웨어 상태가 유지된다. 대신 유지보수 실행 자체를 보안 논의의 일부로 만든다. 조직은 제공업체가 최종 소프트웨어 버전과 업데이트 작업 주변의 관련 보호 조치를 모두 설명할 것으로 기대해야 한다.

이 메커니즘은 책임 있는 보도가 주장할 수 있는 범위도 좁힌다. 업그레이드 창과 연관된 취약점은 언제나 이용 가능한 무제한 공격 경로와 동일하지 않다. 타이밍과 배포 조건이 중요하다. 이러한 제약을 설명하면 모든 WordPress 사이트 요청이 이를 촉발할 수 있다는 인상을 주지 않고도 독자가 위협을 이해하도록 돕는다.

동시에 서버에서 코드가 실행되는 결과와 결합될 때 제한된 기회도 여전히 중요하다. 관리자는 악용에 유리한 타이밍이 필요하다는 이유만으로 문제를 일축할 수 없다. 올바른 평가는 기술적 전제조건과 공격자 활동의 증거를 함께 고려한다. 어느 한 요소도 다른 요소를 지워서는 안 된다.

더 넓은 교훈은 일시적인 운영 상태에 관한 것이다. 보안 검토는 고객이 평소 접하는 안정 상태의 애플리케이션을 흔히 강조한다. 배포, 업그레이드, 복구 작업도 주의를 기울일 만하다. 이번 사건은 다른 플랫폼이 같은 결함을 공유한다는 사실을 확립하지 않으면서도 그 원칙을 구체화한다.

연방 정책은 노출과 책임을 핵심으로 만든다

CISA 취약점 우선순위 지정은 취약점의 기술적 특성과 함께 영향을 받는 자산과 그 노출에 따라 결정된다.

CISA는 2026년 6월 10일 Binding Operational Directive 26-04를 발표했다. 구속력 있는 운영 지침은 적용 대상 연방 기관을 위한 의무적 사이버 보안 지시다. CISA의 위험 기반 완화 공지는 자산 노출, KEV 상태, 익스플로잇 자동화, 침해 이후의 기술적 영향을 우선순위 지정 요인으로 식별한다.

같은 공지는 이 지침이 이전의 취약점 완화 요구사항을 조화시킨다고 밝힌다. 또한 업데이트된 절차, 기관 관리 자산의 식별, 지정된 시나리오에서의 침해 점검을 요구한다. 이러한 요구사항은 악용 지정이 행정적 결과를 갖는 이유를 설명한다. 보안팀은 취약점을 실행 가능한 대응과 연결할 수 있도록 충분한 자산 정보를 확보해야 한다.

Federal Civilian Executive Branch 기관에는 이는 자산 목록의 품질과 내부 조정에 대한 압박을 만든다. 카탈로그 항목은 기관이 운영하는 모든 설치 환경을 식별할 수 없다. 누군가는 영향을 받는 제품을 실제 시스템에 매핑해야 한다. 또한 누군가는 어느 조직이 수정 조치를 통제하는지 확인해야 한다.

민간 기업은 이 연방 프레임워크와 자체 의무를 구분해야 한다. 이 지침은 모든 WordPress 운영자에게 동일한 규정 준수 요구사항을 자동으로 부과하지 않는다. 그럼에도 우선순위 지정 요인은 기업의 의사결정을 구성하는 유용한 방법을 제공한다. 공용 노출과 잠재적인 서버 통제는 지침의 공식 범위 밖에서도 관련 고려사항이다.

외부에서 관리되는 웹사이트는 이러한 요인을 평가하기 더 어렵게 만든다. 사업 소유자는 도메인과 그 목적은 알 수 있지만 호스팅 구성에 접근하지 못할 수 있다. 개발 에이전시는 애플리케이션 버전은 알 수 있지만 인프라에 대한 권한은 없을 수 있다. 제공업체는 고객의 사고 대응 결정을 소유하지 않으면서도 두 기술적 세부사항을 모두 통제할 수 있다.

정책적 함의는 보안 책임이 소프트웨어 경계에서 멈출 수 없다는 것이다. 조직에는 경보 수신에서 구현 증거 확보까지 이어지는 명확한 경로가 필요하다. 그 경로는 인력 변경과 공급업체 인계 이후에도 유지되어야 한다. 그렇지 않으면 발표가 널리 알려졌음에도 알려진 취약점이 해결되지 않은 채 남을 수 있다.

CISA 취약점 우선순위 지정은 팀이 완화 예외를 설명하는 방식도 바꾼다. 중단에 대한 모호한 우려는 지속되는 노출을 평가할 근거를 거의 제공하지 않는다. 유용한 예외는 영향을 받는 서비스, 지연 사유, 위험을 수용하는 사람을 식별한다. 또한 예외 종료를 뒷받침할 증거가 무엇인지 설명해야 한다.

이번 사건은 그러한 기록이 중요한 이유를 보여 준다. 이후 검토에서는 악용 통지가 나타났을 때 웹사이트가 취약했는지 물을 수 있다. 타임스탬프나 설치 식별 정보가 없는 업데이트 확인만으로는 그 질문에 답하기 어렵다. 명확한 기록은 완료된 대응과 추정을 구분하는 데 도움이 된다.

증거를 체계적으로 관리하는 팀이라면 검색 가능한 기술 지식 베이스를 통해 권고문, 제공업체 응답, 유지보수 결정을 연결해 둘 수 있습니다. 문서화는 책임성을 뒷받침하지만 기술적 검증을 대체하지는 않습니다. 결정적인 증거는 여전히 영향을 받은 환경과 그 환경을 책임지는 사람들에게서 나옵니다.

제한적인 공격 시간대가 운영상 위험을 판단해 주지는 않는다

가장 설득력 있는 회의적 주장은 악용의 난이도에 관한 것이지만, 카탈로그 등재만으로도 그 주장만으로는 충분하지 않음을 알 수 있다.

Patchstack의 코어 업데이트 경쟁 상태 평가는 공격 가능 시간이 극히 짧다고 설명합니다. 실질적인 악용은 어렵다고 평가하며, 업그레이드 디렉터리에 대한 웹 접근을 제한할 것을 권고합니다. 이 공격은 특정 운영 조건에 의존하므로 해당 평가는 주목할 가치가 있습니다.

Wordfence의 설명은 같은 문제의 다른 측면, 즉 노출된 스테이징 경로를 통한 인증되지 않은 실행을 강조합니다. 이러한 서로 다른 강조점은 본질적으로 모순되기보다 유용합니다. 한 평가는 공격 기회의 제약을 부각하고, 다른 평가는 그로 인해 가능한 능력을 부각합니다. 관리자는 어느 결론이든 특정 사이트에 적용하기 전에 두 관점을 모두 이해해야 합니다.

카탈로그 등재는 이론적 난이도가 공격자의 관심이나 악용을 없애지 못했다는 증거를 더합니다. 그러나 그것만으로 공격자가 얼마나 자주 성공하는지는 알 수 없습니다. 또한 어떤 호스팅 구성에서 실질적인 노출이 가장 큰지도 확정하지 못합니다. 이러한 질문에는 악용 지정만으로 제공되는 정보보다 더 상세한 증거가 필요합니다.

바로 이 지점에서 보안 요약은 오해를 불러일으킬 수 있습니다. 이 문제를 악용하기 쉽다고 표현하면 시간적 제약을 무시하게 됩니다. 무해하다고 표현하면 악용 증거를 무시하게 됩니다. 더 방어 가능한 설명은 배포 환경에 따라 달라지는 전제조건과 잠재적으로 심각한 결과를 가진, 현재 활발히 악용되는 취약점이라는 것입니다.

같은 주의는 보안 제품에도 적용됩니다. 일반 애플리케이션 내부에서 작동하는 보호 기능이 모든 임시 실행 환경을 포괄한다고 자동으로 가정할 수는 없습니다. 핵심 질문은 해당 보호 기능이 취약한 요청에 대해 어느 위치에서 실행되는가입니다. 제품이 존재한다는 사실만으로는 이 아키텍처적 질문에 답할 수 없습니다.

Patchstack은 특히 자사의 애플리케이션 수준 방화벽 방식이 이 임시 추출 환경을 보호할 수 없는 이유를 설명합니다. 이는 설명된 메커니즘에 관한 제한적인 진술입니다. 이를 모든 방화벽이 이 취약점에 대응하지 못한다는 보편적 주장으로 확대해서는 안 됩니다. 네트워크 제어, 서버 구성, 애플리케이션 보호는 서로 다른 지점에서 작동합니다.

관리형 WordPress 서비스를 구매하는 고객에게 이 차이는 구체적인 평가 질문을 만듭니다. 업그레이드 프로세스가 노출을 초래하는 경우, 제공업체의 보안 보호 포함 주장은 더 자세한 설명이 필요합니다. 구매자는 관련 제어 수단과 그 범위에 대한 설명을 기대해야 합니다. 마케팅 라벨은 실제로 영향을 받은 경로를 무엇이 차단하는지에 대한 설명보다 보장 수준이 낮습니다.

Wordfence와 Patchstack의 비교는 심각도 라벨이 운영상 판단을 대체할 수 없는 이유도 보여 줍니다. 서로 다른 평가는 타이밍, 접근성, 영향에 관한 서로 다른 가정을 반영할 수 있습니다. 조직은 이 문제를 내부적으로 요약할 때 그러한 가정을 보존해야 합니다. 이를 제거하면 조건부 기술 평가가 근거 없는 포괄적 결론으로 바뀝니다.

따라서 불확실성에 대한 가장 유용한 대응은 구체적이어야 합니다. 평가 대상 환경에 관련 조건이 존재했는지 확인해야 합니다. 조치 후 무엇이 달라졌는지 파악해야 합니다. 미해결 과거 노출과 확인된 현재 보호 상태를 분리해 유지해야 합니다.

패치된 웹사이트에도 과거에 대한 질문은 남는다

조치는 소프트웨어 취약점을 해소하지만, 이전 공격 활동이 아무런 결과를 남기지 않았다는 점을 독립적으로 입증하지는 않는다.

WordPress는 2026년 10월 28일 버전 7.1.4를 공개했습니다. 보안 릴리스 세부 정보에서는 코드 실행으로 이어질 수 있는 업그레이드 프로세스 취약점을 식별하고 즉각적인 업데이트를 권고합니다. 이 발표는 최신 WordPress 버전만 활성 지원을 받는다고 명시하면서 보안 백포트도 설명합니다.

이 릴리스 이력은 악용 발표가 이용 가능한 수정 사항 뒤에 나왔기 때문에 중요합니다. 조직은 패치가 제공된 날짜와 자체 사이트에 적용된 날짜를 구분해야 합니다. 어느 날짜도 단독으로 사이트가 공격을 받았는지 입증하지는 않습니다. 하지만 함께 보면 검토가 필요한 기간을 정의하는 데 도움이 됩니다.

유지보수가 자동으로 이루어지는 경우 과거에 대한 질문은 특히 중요합니다. 자동화는 릴리스와 설치 사이의 지연을 줄일 수 있습니다. 동시에 사업 소유자가 일반적인 성공 알림에 의존하게 만들 수도 있습니다. 유용한 보안 기록은 그 알림을 식별 가능한 웹사이트 및 검증된 소프트웨어 상태와 연결해야 합니다.

가령 한 가상의 조직이 자사 공개 사이트가 현재 수정된 소프트웨어를 실행하고 있음을 확인했다고 가정해 보겠습니다. 보안팀은 이 사이트가 이전에 다른 호스팅 구성에서 업그레이드를 거쳤다는 사실도 알게 됩니다. 이러한 사실은 이전 조건을 검토할 근거가 됩니다. 증거 없이 침해 사실을 발표할 근거가 되지는 않습니다.

마찬가지로 눈에 보이는 웹사이트 변경이 없다고 해서 조사가 끝나는 것은 아닙니다. 페이지가 정상적으로 로드된다는 사실은 서버 무결성에 관한 제한적인 정보만 제공합니다. 적절한 대응은 이용 가능한 기록과 평가된 노출 수준에 따라 달라집니다. 조직은 명백한 증상이 없다는 사실을 검증된 안전성 주장으로 바꾸지 않아야 합니다.

이 사건과 관련해 검토된 공개 출처는 피해자 수나 성공한 침입에 대한 포괄적인 설명을 확립하지 않습니다. 또한 모든 악용 시도를 담당한 특정 캠페인을 확립하지도 않습니다. 이러한 한계는 명시적으로 유지되어야 합니다. 대규모 침해에 관한 광범위한 주장은 여기서 이용 가능한 증거를 넘어섭니다.

안심시키는 주장에도 그에 상응하는 한계가 있습니다. 제공업체는 오늘 수정된 버전을 가리키는 것만으로 과거의 안전성을 입증할 수 없습니다. 관련 증거를 검토했다면 그 검토의 범위와 한계를 설명해야 합니다. 검토하지 않았다면 미해결 질문은 계속 드러나 있어야 합니다.

이러한 분리는 비기술 이해관계자와의 소통을 개선합니다. 비즈니스 리더는 노출 검토가 계속되는 동안 애플리케이션이 수정되었음을 이해할 수 있습니다. 이 진술들은 서로 다른 완료 기준을 가진 별개의 업무 흐름을 설명합니다. 이를 하나의 녹색 상태로 합치면 조직이 실제로 무엇을 알고 있는지 가려집니다.

따라서 WordPress 업그레이드 취약점은 “해결됨”의 의미를 재고하게 만듭니다. 일상적인 유지보수 티켓이라면 성공적인 설치만으로 충분할 수 있습니다. 악용된 취약점의 경우, 종결에는 과거 노출에 대한 추가적인 판단이 필요할 수 있습니다. 조직은 그 판단이 업데이트 보고서 안에서 사라지도록 두지 말고 문서화해야 합니다.

대응이 효과를 내고 있음을 보여 줄 요소

다음으로 유용한 신호는 검증된 조치, 더 명확한 악용 증거, 그리고 관리형 업데이트 운영에 대한 더 강한 보장입니다.

첫 번째 신호는 영향을 받은 조직이 수정된 소프트웨어 상태에 도달했다는 증거입니다. 유용한 보고는 평가한 설치 항목과 조치가 완료되었다고 판단한 근거를 식별해야 합니다. 이 단계에서 업데이트 이용 가능성에 관한 일반적 주장은 기여하는 바가 적습니다. 소프트웨어는 존재하며, 운영상 핵심 질문은 배포와 검증입니다.

더 명확한 조치 보고는 악용 지정이 의미 있는 대응을 이끌었다는 근거를 강화할 것입니다. 간과된 웹사이트가 반복적으로 발견된다면 자산 목록이나 소유권 문제를 시사합니다. 두 결과 모두 조직이 경보를 몇 번이나 전달했는지보다 중요합니다. 인식 제고는 노출된 시스템의 상태를 바꿀 때 가치가 생깁니다.

두 번째 신호는 악용에 관한 더 상세한 증거입니다. 시도된 요청과 성공한 코드 실행을 구분하는 연구는 위험 평가를 개선할 것입니다. 성공적인 공격과 연관된 호스팅 조건을 식별하는 조사 결과도 마찬가지입니다. 이러한 증거는 제한된 공격 시간대와 실제 결과 사이의 비교를 더 정교하게 만들 것입니다.

그 증거는 현재의 우려를 강화하거나 범위를 좁힐 수 있습니다. 다양한 환경에서 문서화된 침해가 발생했다면 노출 검토의 시급성에 대한 더 광범위한 근거가 됩니다. 특정 구성에 집중된 증거라면 관리자가 평가의 초점을 맞추는 데 도움이 됩니다. 어느 결과든 구분되지 않은 의심스러운 요청 수보다 더 유용할 것입니다.

세 번째 신호는 호스팅 및 유지보수 제공업체가 업데이트 보호를 어떻게 설명하는가입니다. 의미 있는 대응은 수정된 버전, 임시 디렉터리 접근, 고객 대상 검증을 연결해야 합니다. 제공업체는 서비스가 자동으로 수행하는 작업과 고객 조치가 필요한 작업을 구분할 수 있어야 합니다. 이러한 명확성은 이 사건이 드러낸 책임 공백을 줄일 것입니다.

한계에 관한 투명한 보고도 그에 못지않게 가치 있는 신호가 될 것입니다. 증거 범위를 설명하는 제공업체는 고객이 추가 검토가 필요한지 판단하기 쉽게 만듭니다. 근거 없는 보장은 기저 유지보수 작업이 완료된 경우에도 신뢰를 약화시킵니다. 보안 커뮤니케이션은 증거가 끝나는 지점에서 불확실성을 보존해야 합니다.

향후 몇 달 동안 이러한 신호는 이 사건이 고립된 조치 노력으로 남을지, 반복되는 유지보수 취약점을 드러낼지를 결정할 것입니다. 관련된 검증은 구체적입니다. 조직은 업데이트가 어떻게 실행되는지 설명하고 그 결과로 얻은 보호를 입증할 수 있는가? 이 질문은 모든 퍼블리싱 플랫폼이 이 취약점을 공유한다는 뜻 없이 운영 설계에 적용됩니다.

웹사이트를 책임지는 독자는 CISA WordPress KEV 목록을 활용해 조직의 대응에 대한 구체적인 설명을 요청해야 합니다. 어떤 설치 항목을 평가했는지, 어떤 수정 릴리스를 실행하는지, 누가 결과를 검증했는지 물어보십시오. 책임 팀이 과거 노출 문제를 다룰 때까지 그 질문을 계속 드러나 있게 유지하십시오. 에이전시나 호스팅 제공업체가 업무를 관리한다면 일반적인 서비스 보장만 받아들이지 말고 귀하의 사이트를 식별하는 증거를 확보하십시오. 권고문, 유지보수 확인, 평가 결정을 함께 보존하십시오. 목표는 현재 보호 상태와 남아 있는 불확실성에 대한 방어 가능한 설명입니다. 조직은 소유하거나 의존하는 모든 WordPress 설치에 대해 그러한 설명을 제시할 수 있습니까?