CISA PHP KEV 업데이트, 악용된 두 취약점 패치 압박 높여
CISA는 10월 26일 두 개의 PHP 취약점을 악용 카탈로그에 추가한 것으로 알려졌으며, 이에 따라 영향을 받는 웹 서비스를 여전히 운영 중인 조직의 대응 압박이 커지고 있다. CISA PHP KEV 업데이트는 통칭 PHP2Shell로 불리는 CVE-2026-109618 및 CVE-2026-109619와 관련된다. 서버에서 웹사이트 로직을 실행하는 프로그래밍 언어인 PHP는 10월 21일 수정 패치를 배포했다. 당면한 긴장은 운영 측면에 있다. 패치는 존재하지만, 조직은 영향을 받는 서비스에 실제로 패치가 적용됐다는 증거를 여전히 확보해야 한다.
Known Exploited Vulnerabilities 카탈로그, 즉 KEV는 CISA가 실제 공격에서 악용되고 있다고 판단한 보안 결함을 식별한다. 제공된 경보는 두 항목의 추가 내용을 설명하지만, 원문 페이지는 이 보고서를 위해 직접 가져올 수 없었다. PHP 릴리스 공지, 정부 지침 및 공급업체 권고문은 근본 취약점과 이용 가능한 수정 조치를 각각 독립적으로 뒷받침한다.
이 구분은 서로 다른 주장이 서로 다른 증거를 요구하기 때문에 중요하다. 작동하는 익스플로잇은 기술적 실행 가능성을 입증하며, 악성 트래픽은 악용 시도를 보여주고, 확인된 무단 실행은 침해의 성공을 입증한다. 보고된 카탈로그 추가는 얼마나 많은 조직이 침해를 입었는지를 입증하지는 않으면서도 수정 조치의 필요성을 강화한다. 방어자에게 핵심 갈등은 이용 가능한 소프트웨어 수정과, 노출된 모든 배포 환경이 이제 이를 실행한다는 확신 사이에 있다.
CISA PHP KEV 업데이트가 바꾸는 점
보고된 카탈로그 추가는 대응 우선순위를 바꾸지만, 근본적인 소프트웨어 수정 조치는 이미 이용 가능했다.
제공된 KEV 업데이트에 따르면, CISA는 10월 26일 메모리 손상 및 오래된 내부 요청 상태 취약점을 추가했다. 두 취약점 모두 PHP의 웹 요청 처리 방식에 영향을 미친다. 이 발표는 CISA가 기존 PHP 경고도 업데이트했다고 밝힌다.
원 경보를 가져오지 못해 해당 문구와 연관된 카탈로그 필드를 직접 검증하는 데 한계가 있다. 따라서 이 보고서는 어느 항목에도 특정 수정 기한을 부여하지 않는다. 조직은 이 발표를 준수 기한으로 전환하기 전에 최신 카탈로그 기록을 확보해야 한다.
별도의 패치 기록은 더 명확하다. PHP의 보안 릴리스는 두 취약점의 수정 사항을 식별한다. 발표된 수정 릴리스에는 PHP 8.2.35, 8.3.36, 8.4.27 및 8.5.12가 포함된다. 이 버전 번호는 PHP 프로젝트가 직접 배포하는 업스트림 릴리스를 의미한다.
운영체제 패키지를 사용하는 조직에서는 관련 증거가 다르게 보일 수 있다. 공급업체는 최신 업스트림 버전 번호를 채택하지 않고도 보안 수정 사항을 반영할 수 있다. 따라서 팀은 배포 환경이 여전히 취약한지 판단하기 전에 해당 공급업체 권고문과 패키지 상태를 확인해야 한다.
이 구분은 상반된 실수를 방지한다. 팀은 표시된 버전이 오래돼 보인다는 이유로 수정된 패키지를 기각할 수 있다. 반대로 최근 애플리케이션 업데이트가 기반 PHP 런타임까지 교체했다고 가정할 수도 있다. 어느 결론도 애플리케이션 대시보드나 버전 문자열만으로 자동으로 도출되지는 않는다.
이 변화는 취약점 심각도와 수정 긴급성의 차이도 더욱 부각한다. 심각도는 특정 조건에서 발생할 수 있는 결과를 설명한다. 악용 증거는 공격자 행동에 관한 정보를 추가한다. 조직은 여전히 두 신호를 자체적으로 접근 가능한 시스템과 연결해야 한다.
따라서 CISA PHP KEV 업데이트는 운영 의사결정 과정에 포함돼야 한다. 이는 영향을 받는 자산, 책임자, 노출도 및 수정 상태에 대한 검토를 촉발해야 한다. 단순히 발표를 전달하는 것만으로는 조직이 관련 공격 경로를 차단했는지 확인할 수 없다.
이 사안을 지켜보는 독자에게 핵심 사실은 이것이 더 이상 단순한 패치 릴리스 발표만은 아니라는 점이다. 보고된 카탈로그 조치는 기존의 소프트웨어 긴급 상황에 정부의 우선순위 신호를 더한다. 이 신호는 수정 조치가 존재한다는 사실을 단순히 인지하는 것보다, 실제 대응을 입증하는 일의 중요성을 높인다.
연방 기관, 노출도 기반 수정 조치 검증에 직면
연방 차원의 수정 압박은 헤드라인상의 심각도 점수만이 아니라 영향받는 자산과 적용 가능한 요구사항에 따라 달라진다.
제공된 경보는 이 추가 항목들을 위험에 따라 보안 업데이트의 우선순위를 정하는 CISA의 체계인 Binding Operational Directive 26-04 안에 위치시킨다. 구속력 있는 운영 지침은 적용 대상 연방 기관에 의무 요건을 설정한다. 그렇다고 모든 권고가 민간 부문 전체에 보편적인 법적 의무가 되는 것은 아니다.
FedRAMP의 위험 기반 수정 조치 공지는 CISA가 2026년 6월 10일 BOD 26-04를 발행했다는 점을 독립적으로 확인한다. FedRAMP는 연방 기관이 사용하는 클라우드 서비스의 보안 평가 및 인가 절차를 감독한다. 그 설명은 노출도, 악용 상태, 자동화 및 기술적 영향을 관련 우선순위 요소로 식별한다.
이 요소들은 자산 맥락을 중요하게 만든다. 공용 인터넷에서 접근 가능한 취약 서비스는 제한된 배포 환경과는 다른 운영 상황을 제시한다. 소프트웨어 결함은 동일할 수 있지만, 공격자가 활용할 수 있는 실질적인 경로는 다르다.
그에 따른 압박은 여러 팀에 걸쳐 작용한다. 보안 담당자는 권고문을 해석하고 영향 범위를 파악해야 한다. 인프라 팀은 실행 중인 소프트웨어를 식별해야 한다. 애플리케이션 책임자는 변경 사항을 평가해야 한다. 서비스 제공업체는 배포 환경 중 자신들이 통제하는 부분을 설명해야 한다.
따라서 연방 고객은 제공업체가 보안 공지를 따른다는 보장 이상의 것을 요구할 수 있다. 유용한 증거는 특정 서비스를 영향을 받는 구성 요소, 수정 조치 및 검증된 배포 상태와 연결한다. 이 연결이 일반적인 정책 문구와 평가 가능한 대응의 차이다.
지침이 해당 조직에 적용되지 않는 정부 외부에서도 동일한 운영 문제가 발생한다. 기업은 여전히 자사의 고객 포털, 게시 시스템 또는 관리 서비스가 영향을 받는 런타임을 사용하는지 파악해야 한다. 대응은 노출도와 의무에 따라 이뤄져야 한다.
공용 웹사이트와 별도로 호스팅된 고객 지원 애플리케이션을 가진 가상의 조직을 생각해 보자. 웹사이트 팀은 PHP를 직접 업데이트할 수 있다. 고객 지원 애플리케이션은 소프트웨어 공급업체의 조치가 필요할 수 있다. 하나의 내부 티켓만으로는 이 두 책임 경계 전반의 완료를 입증할 수 없다.
이 때문에 보고된 카탈로그 추가는 패키지를 설치하는 관리자 이상의 사람들에게 압박을 만든다. 조달, 서비스 관리 및 보안 리더십은 공급업체 증거를 요구할 수 있다. 핵심 질문은 영향을 받는 모든 서비스의 책임자가 식별됐는가로 바뀐다.
그렇다고 보편적인 기한을 임의로 만들어도 되는 것은 아니다. 적용 가능한 일정에는 실제 지침, 최신 카탈로그 정보 및 조직의 상황이 필요하다. 방어 가능한 대응은 이러한 기록에서 시작해 각 자산의 우선순위에 대한 근거를 문서화한다.
더 넓은 정책적 함의는 명확하다. 위험 기반 요구사항은 정확한 자산 목록과 노출 증거에 가치를 둔다. 조직은 어떤 서비스가 취약한 구성 요소를 실행하는지 식별할 수 없으면 영향을 받는 자산의 우선순위를 신뢰성 있게 정할 수 없다.
이용 가능한 패치는 여전히 실행 중인 서비스까지 도달해야 한다
출시된 수정 조치는 문제를 바로잡지만, 배포 증거만이 특정 서비스가 그 혜택을 받는지 입증한다.
PHP2Shell 대응은 소프트웨어 유지관리에서 반복되는 약점을 드러낸다. 서로 다른 팀은 “패치됨”이라는 표현을 서로 다른 상태로 사용할 수 있다. 패키지는 승인, 다운로드, 설치 또는 배포될 수 있다. 이러한 이정표가 반드시 같은 상태를 뜻하지는 않는다.
예를 들어 수정된 컨테이너 이미지가 레지스트리에 존재하더라도, 오래된 이미지가 계속 요청을 처리할 수 있다. 컨테이너 이미지는 애플리케이션 인스턴스를 시작하는 데 사용되는 소프트웨어를 묶는다. 관련 보안 질문은 가장 최근 아티팩트가 아니라 실행 중인 인스턴스에 관한 것이다.
마찬가지로 호스트 수준 패키지 업데이트는 별도로 번들된 소프트웨어를 그대로 둘 수 있다. 어플라이언스나 상용 애플리케이션은 자체 런타임을 포함할 수 있다. 기반 운영체제가 정기 업데이트가 완료됐다고 보고하더라도, 관리자는 제품별 업데이트가 필요할 수 있다.
이러한 사례는 이번 사건에서 문서화된 침해가 아니라 배포 위험을 보여준다. 이는 취약점 대응에 서비스 수준의 증거가 필요한 이유를 설명한다. 업스트림 릴리스의 존재만으로는 모든 다운스트림 배포에 관한 질문에 답할 수 없다.
Oracle의 영향받는 제품 권고문은 다운스트림 책임의 구체적인 예를 제공한다. 10월 25일자 공지는 나열된 통신 제품과 Oracle Solaris 전반에서 두 취약점을 다룬다. Oracle은 이용 가능한 패치를 신속히 적용할 것을 권고하며, 추가 패치가 제공됨에 따라 권고문이 변경될 것이라고 밝힌다.
이러한 제품별 접근 방식은 PHP 릴리스 발표를 읽고 하나의 설치 명령으로 모든 환경을 다룰 수 있다고 가정하는 것과 다르다. 공급업체는 자사 제품이 구성 요소를 어떻게 통합하는지 통제한다. 고객에게는 적용성 평가와 지원되는 수정 경로가 필요하다.
Red Hat은 또 다른 차원을 보여준다. 배포 아키텍처는 악용 평가를 바꾼다. 해당 지침은 Apache와 통합된 PHP와 PHP 요청을 처리하는 프로세스 관리자인 PHP-FPM의 차이를 논의한다. 이러한 차이는 영향을 받는 소프트웨어를 해결할 필요성을 없애지 않으면서도 실질적인 노출도에 영향을 준다.
따라서 Oracle과 Red Hat은 서로 다른 운영 질문에 답하기 때문에 유용한 비교 대상이다. 하나는 이 사안을 지원 제품 및 패치와 연결한다. 다른 하나는 설정이 악용 난이도에 어떤 영향을 미치는지 설명한다. 어느 쪽도 실제 배포 상태를 검증해야 할 필요성을 대체하지는 않는다.
구매자에게 이는 권고문 품질이 실질적인 서비스 기준이 된다는 의미다. 유용한 공급업체 대응은 영향을 받는 제품, 적용 가능한 수정 조치 및 미해결 제한 사항을 식별한다. 보안이 여전히 우선순위라는 광범위한 문구만으로는 고객이 자체 서비스를 평가할 근거를 거의 얻을 수 없다.
엔지니어링 팀에 주는 교훈은 증거의 연속성에 관한 것이다. 취약점 기록, 패키지 권고문, 배포 변경 및 실행 중인 서비스 검증은 동일한 자산을 설명해야 한다. 이러한 기록이 서로 다른 환경을 가리킬 때, 완료된 변경은 원래의 노출을 해결하지 못한 채 확신만 만들 수 있다.
CISA PHP KEV 업데이트는 이 격차를 해소하는 일의 중요성을 높인다. 이는 배포 검증의 긴급성을 더하지만, 근본적인 엔지니어링 책임은 바꾸지 않는다. 실제 요청을 처리하는 수정된 소프트웨어가 무엇인지 확인해야 한다.
임시 방어책에는 한계가 있다
트래픽 필터링은 수정 조치가 진행되는 동안 노출을 줄일 수 있지만, PHP 내부의 메모리 처리 결함을 고치지는 못한다.
두 취약점 모두 요청 처리 중 메모리 상태와 관련된다. 메모리 상태는 프로그램이 작업을 처리하는 동안 유지하는 정보를 뜻한다. 그 정보가 유효하지 않게 되면 이후 작업이 이를 잘못 해석할 수 있다. 악용 가능성은 특정 결함과 주변 실행 조건에 달려 있다.
영국 국가사이버보안센터(National Cyber Security Centre)는 첫 번째 문제를 메모리 부족 상태에서 초기화가 중단되는 현상으로 설명합니다. 초기화는 사용 전에 내부 데이터를 준비하는 과정입니다. 두 번째 문제에 대한 설명은 관련 메모리가 해제된 뒤에도 상태가 남아 있는 경우와 관련됩니다.
이 기관의 PHP 보안 가이드는 영향을 받는 조건에서 원격 코드 실행이 가능해질 수 있다고 경고합니다. 원격 코드 실행은 공격자가 다른 시스템에서 서버가 명령어나 코드를 실행하도록 만들 수 있음을 뜻합니다. 이러한 잠재적 결과가 수정 조치가 시급한 이유를 설명합니다.
그럼에도 조직은 노출 여부를 확인한 시점부터 배포를 완료하기까지 현실적인 공백 기간에 직면합니다. 그 기간 동안 팀은 접근을 제한하거나 트래픽 제어를 적용할 수 있습니다. 문제는 그러한 제어가 관련 경로를 다루고 실제 구성에서도 계속 효과를 발휘하는지입니다.
웹 애플리케이션 방화벽(WAF)은 웹 트래픽을 검사하고 필터링 규칙을 적용합니다. 이는 PHP 런타임과는 다른 계층에서 동작합니다. 요청 검사는 특정 악성 패턴을 식별할 수 있지만, 그 자체로 기반 프로그램이 이제 메모리를 안전하게 처리한다는 사실을 입증하지는 않습니다.
AWS의 임시 완화 가이드는 패치를 명시적으로 우선시하며 방화벽 제어를 보조 방어 수단으로 설명합니다. 해당 논의는 검사와 가시성의 한계도 지적합니다. 조직이 보호 주장에 대해 평가할 때 이 단서는 중요합니다.
이 일반적 함의는 특정 방화벽 공급업체를 넘어 적용됩니다. 제어 수단은 인식하는 트래픽을 차단할 수 있지만, 다른 경로는 해결되지 않은 채 남길 수 있습니다. 보안팀은 적용 범위, 예외, 구성, 그리고 요청이 PHP에 도달하는 서비스 경로를 이해해야 합니다.
가상의 애플리케이션은 일반 고객 트래픽에는 필터링 서비스 뒤에 위치하면서도 직접 접근 가능한 오리진 서버를 유지할 수 있습니다. 이런 상황에서 팀은 두 경로를 모두 평가해야 합니다. 선호 경로에서 규칙을 활성화했다고 해서 다른 경로까지 보호된다는 의미는 아닙니다.
이 사례는 특정 피해자에 관한 주장이 아니라 아키텍처상 고려 사항입니다. 완화 조치에 관한 진술에 범위가 필요한 이유를 보여 줍니다. 어떤 서비스, 트래픽 경로, 규칙 동작을 포괄하는지 밝히지 않은 “필터링 활성화”라는 표현만으로는 충분한 정보를 제공하지 못합니다.
가용성과의 절충도 존재합니다. 요청을 제한하거나 기능을 비활성화하면 정상적인 업무 흐름이 중단될 수 있습니다. 긴급 제어가 필수 운영을 조용히 망가뜨리지 않으면서 노출을 다루도록 하려면 애플리케이션 소유자가 참여해야 합니다. 이러한 조율은 명확히 정의된 수정 경로를 뒷받침해야 합니다.
이번 사건에서 임시 방어 조치는 한계가 문서화된 구체적 조치로 평가되어야 합니다. 그 가치는 대응 기간 동안 노출을 줄이는 데 있습니다. 그 존재만으로 영향을 받는 PHP 설치 환경에 수정 조치가 적용되었음을 입증하지는 않습니다.
악용 증거가 피해자 수를 입증하지는 않는다
긴급한 개선 조치를 뒷받침하는 증거는 광범위한 조직 침해 성공을 주장하는 증거보다 더 강력합니다.
이러한 구분은 보도의 정확성을 보호합니다. 공격 시도는 광범위할 수 있지만 모든 시도가 성공하는 것은 아닙니다. 모니터링 환경에서의 성공적인 실행은 기술적 가능성을 입증할 수 있으나, 침해된 기업을 식별하지는 못합니다. 카탈로그에 포함되었다고 해서 공개적인 피해자 수가 제공되는 것도 아닙니다.
Amazon의 악용 타임라인은 모니터링되는 디코이 인프라인 MadPot에서 10월 17일자 시도가 있었다고 보고합니다. 이러한 인프라는 관찰을 위해 악성 활동을 유인합니다. Amazon은 그 시도가 10월 21일 공개 이전에 발생했다고 설명합니다.
Amazon은 공개 전후의 추가 시도도 설명하면서, 실제 환경에서의 성공 여부에 대한 불확실성을 명시적으로 유지합니다. 이 단서는 해당 관찰과 함께 보존되어야 합니다. 그 시점은 초기 공격자 활동에 대한 우려를 뒷받침하지만, 익스플로잇 정보가 어떻게 이용 가능해졌는지는 식별하지 못합니다.
따라서 그 타임라인만으로 특정 유출 출처, 책임 주체 또는 성공적인 침입을 추론하는 것은 근거가 부족합니다. 귀속에는 추가 증거가 필요합니다. 시도가 공개에 앞섰다는 사실만으로 그 기원에 관한 모든 질문에 답할 수는 없습니다.
배포 환경별 분석은 주의가 필요한 또 다른 이유를 제공합니다. Red Hat은 지원 환경에서 CVE-2026-109618의 실제 악용 제약을 설명합니다. 그 평가는 일반적인 PHP-FPM 동작이 Apache 내부에 PHP를 포함하는 모듈인 mod_php를 사용하는 Apache 구성과 다르다고 설명합니다.
이러한 뉘앙스가 더 폭넓은 패치 우선순위를 무효화하는 것은 아닙니다. 다만 손쉬운 악용에 관한 보편적 진술은 오해를 불러일으킬 수 있음을 보여 줍니다. 정확한 설명은 심각한 잠재적 결과를 인식하면서도 아키텍처 간 차이를 보존할 수 있습니다.
따라서 가장 강력한 회의적 질문은 범위에 관한 것입니다. 어떤 구성이 신뢰할 수 있는 악용을 뒷받침하며, 그에 대한 성공적인 실행을 입증하는 증거는 무엇인가요? 이 질문은 모든 웹 서버를 동일하게 취급하거나 일부 경로가 더 까다롭다는 이유로 문제를 일축하는 것보다 더 유용합니다.
독자는 개선 조치와 사고 평가도 구분해야 합니다. 수정된 소프트웨어를 설치하면 향후 식별된 취약점을 해결할 수 있습니다. 하지만 공격자가 이전 버전을 이용했는지 여부를 자동으로 입증하지는 않습니다. 이는 증거 요건이 서로 다른 별개의 질문입니다.
관련 의심 활동을 발견한 조직에서는 조사가 보안 대응 프로세스에 따라 이루어져야 합니다. 충돌, 비정상 요청 또는 차단된 페이로드는 침해를 입증하지 않아도 조사를 정당화할 수 있습니다. 반대로 대시보드가 조용하다고 해서 관련된 모든 과거 활동이 포착되었다고 단정할 수는 없습니다.
따라서 CISA PHP KEV 업데이트는 과장된 결론을 부추기지 않으면서 대응 우선순위를 높여야 합니다. 영향을 받는 서비스를 식별하고 해당 수정 조치를 적용할 충분한 검증 정보가 있습니다. 피해자 수, 보편적 노출 또는 공격자 신원에 관한 공개적 주장은 발표 내용 이상의 증거를 필요로 합니다.
이러한 신중한 프레이밍은 방어 담당자에게 도움이 됩니다. 기록이 뒷받침하는 조치에 주의를 집중하는 동시에, 기록이 불완전한 부분에서는 불확실성을 유지합니다. 보고서가 각 출처가 정확히 무엇을 입증하는지 밝히면 긴급성과 정확성은 공존할 수 있습니다.
개선 조치가 따라잡고 있는지 보여 줄 세 가지 신호
다음으로 유용한 전개는 권위 있는 기록, 완료된 배포, 그리고 더 강력한 악용 증거와 관련됩니다.
첫 번째 신호는 최신 권위 있는 카탈로그와 경보 기록입니다. 독자는 포함 날짜, 요구 조치 및 적용 가능한 개선 정보를 명시하는 직접 접근 가능한 항목을 찾아야 합니다. 이러한 필드는 보고된 10월 26일 추가 조치의 운영상 해석을 강화할 것입니다.
기록에 단서나 이후 수정 사항이 포함되어 있다면, 조직은 이를 대응에 반영해야 합니다. 자동화된 주제 브리핑은 보도 과정의 한 시점을 포착합니다. 세부 사항이 바뀔 때는 유지 관리되는 기록이 의사결정을 이끌어야 합니다.
두 번째 신호는 하위 단계의 배포 완료입니다. 추가 공급업체 권고는 영향을 받는 제품과 수정 조치의 가용성을 명확히 할 수 있습니다. 더욱 의미 있는 것은 고객이 요청을 처리하는 서비스에 이러한 수정 조치를 배포했다는 증거입니다. 가용성과 도입은 서로 다른 질문에 답합니다.
확대되는 패치 목록은 수정 조치 제공의 진전을 보여 줄 것입니다. 노출된 자산 전반에 걸친 검증된 배포는 방어 담당자가 실제 위험을 줄이고 있다는 결론을 강화할 것입니다. 번들 런타임에 대한 지속적인 불확실성은 구성 요소 가시성이 여전히 장애물임을 보여 줄 것입니다.
세 번째 신호는 성공적인 악용에 관한 더 나은 증거입니다. 유용한 보고서는 영향을 받은 구성, 관찰된 실행, 조사 방법 및 한계를 식별할 것입니다. 모니터링된 테스트 시스템과 확인된 조직 피해자를 구분하고, 시도된 전달과 성공적인 침해를 분리할 것입니다.
이러한 증거는 개선 조치 우선순위와 조사 지침을 더욱 명확히 할 수 있습니다. 또한 공격자가 어떤 구성을 신뢰성 있게 악용할 수 있는지에 관한 초기 가정을 좁힐 수 있습니다. 어느 결과든 광범위한 우려를 더 정확한 지식으로 대체하여 대응을 개선할 것입니다.
이 신호들이 이 순서에 속하는 이유는 점진적으로 서로 다른 질문에 답하기 때문입니다. 공식 기록은 정부 조치를 확립합니다. 배포 증거는 수정 조치가 서비스에 도달했는지 입증합니다. 악용 증거는 남아 있는 위협과 입증된 결과를 명확히 합니다.
개발자와 엔터프라이즈 구매자에게 실질적 의미는 PHP를 넘어섭니다. 현대 애플리케이션은 여러 당사자가 관리하는 구성 요소에 의존합니다. 제품팀은 고객 경험을 소유하면서도 노출을 만드는 런타임을 직접 통제하지 못할 수 있습니다.
따라서 유용한 후속 조치는 공급업체에 각자의 역할에 적합한 증거를 요구하는 것입니다. 제품 공급업체는 적용 가능성과 지원되는 수정 조치를 식별해야 합니다. 호스팅 공급업체는 배포 책임을 설명해야 합니다. 내부 팀은 이러한 답변을 실제로 운영하는 서비스와 연결해야 합니다.
CISA PHP KEV 업데이트를 활용해 PHP 소유권과 수정 상태에 관한 미해결 질문을 다시 검토하세요. 각 배포 환경의 권위 있는 권고를 식별하고 해당 수정 조치가 실행 중인 서비스에 적용되었는지 확인하세요. 공급업체에는 완료된 개선 조치와 임시 제어 또는 아직 진행 중인 작업을 구분해 달라고 요청하세요. 다른 검토자가 결론을 이해할 수 있도록 관련 변경 기록과 함께 이러한 답변을 보존하세요. 의심 활동이 있는 경우에는 사고 평가를 업데이트 결정과 분리하세요. 노출 여부가 불확실한 경우에는 이를 해결할 담당자를 지정하세요. 유용한 결과는 영향을 받는 모든 서비스에 관한 문서화된 답변입니다. 즉, 누가 소유하는지, 어떤 수정 조치가 적용되는지, 그리고 남은 위험이 해결되었음을 보여 주는 증거가 무엇인지입니다.
