English
신뢰와 정확성

방법론

PatchScope의 PHP 보안 권고 데이터 수집, 버전 매칭과 상태 판정, 웹사이트 수동 점검 방식과 그 한계를 설명합니다.

업데이트 2026년 10월 25일

요약

PatchScope는 두 가지 좁은 질문에 답합니다. 특정 PHP 버전의 보안 상태에 대해 공개적으로 알려진 내용은 무엇인지, 그리고 공개 웹사이트를 외부에서 볼 때 그 사이트가 자신의 설정에 대해 무엇을 드러내는지입니다. 이 페이지에서는 데이터를 구성하는 방법, 버전을 매칭하는 방법, 각 상태를 판정하는 기준, 웹사이트 점검 항목, 그리고 결과를 신뢰할 수 없게 되는 지점을 설명합니다.

아래의 모든 규칙은 세 가지 원칙에 따릅니다.

  • 경고보다 정확성. 근거 없는 단정적인 답보다 “정보 부족” 또는 “영향 가능성 있음”을 우선합니다.
  • “안전함”이라고 말하지 않습니다. PatchScope의 어떤 결과도 버전이나 웹사이트가 안전하다고 단정하거나 암시하지 않습니다. 점검은 관찰한 내용만 보고할 수 있습니다.
  • 출처를 공개합니다. 모든 보안 권고에는 출처, 검토일, 검증 수준이 표시됩니다.

데이터 출처

PHP 버전 검사기와 CVE 조회는 큐레이션된, 버전 관리되는 JSON 스냅샷을 사용합니다. 스냅샷은 다음 자료를 바탕으로 구성됩니다.

출처 용도
php.net 지원 버전 및 지원 종료(EOL) 페이지 브랜치 출시일, 활성 지원 및 보안 지원 종료일
PHP ChangeLog 수정 버전과 각 릴리스가 해결한 버그 또는 CVE
php-src GitHub 보안 권고 권고 설명, 영향 버전 및 패치 버전
CVE 레코드(CVE.org) 및 NVD CVE 식별자, 설명, CVSS 점수, 참고 자료
신뢰할 수 있는 벤더 및 배포판 트래커 1차 출처를 확인할 수 없을 때의 보조 정보

이 데이터셋은 PHP 엔진과 번들 확장(php-src)의 취약점을 다룹니다. WordPress, 프레임워크, Composer 패키지, PECL 확장, PHP로 작성된 애플리케이션은 다루지 않습니다.

검증 수준

모든 보안 권고 레코드에는 다음 정보가 포함됩니다.

  • 각 사실에 대한 출처 URL
  • 레코드를 출처와 마지막으로 대조한 날짜인 검토일
  • 검증 수준: primary(공식 PHP 출처로 확인됨) 또는 secondary – pending primary verification(공식 PHP 확인 전까지 CVE/NVD 또는 벤더 트래커에 근거함)

화면에는 각 권고 옆에 검증 수준이 표시됩니다. 특히 2026년 레코드는 검증이 완료될 때까지 2차 출처에 의존할 수 있습니다.

CVSS 점수

출처에 따라 CVSS 점수가 서로 다를 수 있습니다. PHP 프로젝트, NVD, 배포판 벤더는 서로 다른 배포 환경을 가정하기 때문에 같은 문제에 다른 점수를 매기기도 합니다. PatchScope는 임의로 하나를 고르지 않고 각 점수의 출처를 함께 표시합니다. 점수는 우선순위를 정하는 하나의 참고 자료로 보시고, 실제 노출 여부에 대한 판정으로 보지 않으시기 바랍니다.

업데이트 절차와 최신성

스냅샷은 스크립트 기반의 검토 절차를 거쳐 업데이트됩니다. 변경 사항은 게시 전에 저장소의 검증 스크립트를 통과해야 하며, 이 스크립트는 스키마, 버전 범위, 날짜 일관성, 출처 필드를 확인합니다. 정기 자동 업데이트 작업은 계획 중입니다.

스냅샷에는 커버리지 기준일이 있습니다. 보고 계신 데이터가 현재 날짜보다 45일 넘게 오래된 경우, 새로운 릴리스나 권고가 누락되었을 수 있으므로 검사기에 경고가 표시됩니다.

데이터 모델

브랜치 수명 주기

각 PHP 브랜치(예: 8.3)에는 최초 출시일, 활성 지원 종료일, 보안 지원 종료일이 기록됩니다. 브랜치 상태는 이 날짜들과 현재 날짜를 기준으로 계산됩니다.

상태 의미
활성 지원(Active) 버그 수정과 보안 수정을 모두 받습니다
보안 수정만 제공 필요에 따라 보안 수정만 받습니다
지원 종료(End of life) PHP 프로젝트로부터 더 이상 수정을 받지 않습니다
출시 전(Pre-release) 아직 정식 출시되지 않았습니다(alpha, beta, RC)
알 수 없음(Unknown) 데이터셋에 해당 브랜치의 수명 주기 기록이 없습니다

보안 권고 레코드

각 권고에는 브랜치별로 다음 정보가 기록됩니다.

  • 영향 범위: 해당 브랜치에서 권고가 취약하다고 명시한 버전
  • 수정 버전: 각 브랜치에서 수정이 포함된 첫 릴리스

권고에 나열되지 않은 브랜치에 대해서는 이전 브랜치 처리 방식을 정책 필드로 기록합니다.

  • affected-no-fix: 이전 브랜치도 영향을 받는 것으로 보지만, 이미 지원이 종료되어 수정이 배포되지 않았습니다.
  • not-assessed: 권고가 이전 브랜치의 영향 여부를 밝히지 않았습니다.
  • not-affected: 이전 브랜치에는 취약한 코드가 없는 것으로 알려져 있습니다.

권고 발표일 당일 또는 이후에 출시된 브랜치는 수정이 포함된 것으로 간주합니다.

버전 파싱

검사기는 다음 형식을 받습니다.

  • 전체 버전: 8.3.10
  • 접두어가 붙은 버전: PHP 8.3.10
  • 출시 전 버전: 8.4.0RC1, 8.4.0beta2
  • 배포판 빌드 문자열: 8.1.2-1ubuntu2.20, 7.4.33-1+deb11u5
  • 브랜치만 입력: 8.3

앞뒤 텍스트는 정리됩니다. 배포판 접미사는 결과 해석 방식을 바꾸므로 그대로 유지하고 표시합니다(아래 참고). PHP 버전으로 해석할 수 없는 입력은 추측하지 않고 이유와 함께 거부합니다.

매칭 규칙과 상태

검사기는 각 권고에 대해 네 가지 상태 중 하나를 지정합니다.

영향 있음(Affected)

입력한 버전이 권고에 영향 범위로 명시된 범위 안에 있습니다.

영향 가능성 있음(Potentially affected)

영향을 받을 수 있지만 데이터로 확인할 수 없습니다. 대표적인 경우는 다음과 같습니다.

  • 지원이 종료된 브랜치이며 권고가 해당 브랜치를 평가하지 않은 경우(not-assessed 정책)
  • 8.1.2-1ubuntu2.20과 같은 배포판 빌드 문자열을 입력한 경우. 배포판 패키지는 업스트림 버전 번호를 바꾸지 않고 보안 수정을 백포트하는 경우가 많기 때문에, 업스트림 버전만으로는 수정 포함 여부를 알 수 없습니다.

영향 없음 / 수정됨(Not affected / fixed)

버전이 해당 브랜치의 수정 버전 이상이거나, 권고에 따르면 해당 브랜치가 영향 범위 밖에 있습니다.

정보 부족(Insufficient information)

검사기가 근거 있는 답을 낼 수 없습니다. 대표적인 경우는 다음과 같습니다.

  • 8.3처럼 브랜치만 입력하여 패치 수준에 따라 결과가 달라지는 경우
  • 데이터셋 커버리지보다 새로운 버전인 경우
  • 아직 출시되지 않은 브랜치인 경우
  • 해당 브랜치에 대한 권고 데이터에 공백이 있는 경우

종합 판정

종합 판정은 권고별 상태와 브랜치 지원 상태를 함께 고려합니다.

  • 하나라도 영향 있음이면 종합 판정은 영향 있음입니다.
  • 그렇지 않고 영향 가능성 있음 또는 정보 부족이 있으면 그 불확실성을 판정에 반영합니다.
  • 지원 종료 브랜치는 절대 깨끗한 결과를 받지 않습니다. 일치하는 권고가 없더라도, 해당 브랜치는 더 이상 보안 수정을 받지 않으며 향후 취약점도 업스트림에서 패치되지 않는다는 점을 판정에 명시합니다.
  • 지원 중인 브랜치의 깨끗한 결과는 현재 데이터셋에서 입력한 버전과 일치하는 권고가 없다는 뜻일 뿐, 해당 버전이 안전하다는 의미가 아닙니다.

업그레이드 권장 사항

권장 사항은 정해진 순서를 따릅니다.

  1. 사용 중인 브랜치의 최신 패치. 브랜치가 아직 지원 중이라면 첫 단계는 해당 브랜치의 최신 패치 릴리스입니다. 일반적으로 가장 위험이 낮은 변경입니다.
  2. 최신 안정 브랜치. 장기 목표로 최신 안정 브랜치도 함께 안내합니다.
  3. 지원 종료 브랜치의 경우, 보안 지원 기간이 최소 12개월 이상 남은 지원 브랜치 중 가장 오래된 브랜치를 권장합니다. 호환성(작은 폭의 업그레이드)과 곧 다시 업그레이드해야 하는 부담 사이의 균형을 고려한 것입니다.

권장 사항은 수명 주기 데이터만을 기준으로 합니다. 애플리케이션 호환성은 반영하지 않으므로 별도로 테스트하셔야 합니다.

웹사이트 보안 점검

웹사이트 보안 검사기는 Cloudflare Pages Function에서 서버 측으로 실행됩니다. 사용자가 소유하거나 테스트 권한을 가진 공개 웹사이트를 대상으로 수동(passive) 점검을 수행합니다.

점검 항목과 기준

점검 항목 확인 내용 분류 기준
HTTPS 사용 가능 여부 유효한 연결로 HTTPS 응답을 하는지 HTTPS 미지원은 문제
HTTP→HTTPS 리디렉션 일반 HTTP가 HTTPS로 리디렉션되는지 리디렉션 없음은 문제
Strict-Transport-Security HTTPS 응답의 HSTS 존재 여부와 max-age HTTPS에서 누락 시 문제, max-age 180일 미만은 잠재적 문제
Content-Security-Policy CSP 헤더 존재 여부 누락 시 잠재적 문제
X-Content-Type-Options nosniff 값 누락 또는 잘못된 값은 잠재적 문제
X-Frame-Options / frame-ancestors 헤더 또는 CSP 지시어를 통한 클릭재킹 방지 둘 다 없으면 잠재적 문제
Referrer-Policy 존재 여부와 값 누락 시 잠재적 문제
Permissions-Policy 존재 여부 누락 시 잠재적 문제
PHP 버전 노출 X-Powered-By 또는 Server의 버전 노출 사실을 보고하고, 노출된 버전을 수명 주기 데이터와 대조하며, 지원 종료 버전이면 문제
서버 소프트웨어 노출 Server 등 헤더의 버전 번호 버전 노출은 잠재적 문제
쿠키 플래그 응답이 설정한 쿠키의 Secure, HttpOnly, SameSite 쿠키 이름별로 누락된 플래그 보고
security.txt /.well-known/security.txt 존재 여부 누락 시 잠재적 문제
민감 경로 고정된 잘 알려진 경로 목록(아래 참고) 노출이 확인되면 문제

쿠키 점검은 쿠키 이름과 속성만 기록하며, 쿠키 값은 절대 기록하지 않습니다.

민감 경로 점검

스캐너는 다음 각 경로에 GET 요청을 한 번씩만 보냅니다.

/.git/HEAD, /.env, /phpinfo.php, /info.php, /wp-config.php.bak, /wp-config.php~, /wp-content/debug.log, /server-status, /.DS_Store

200 OK 응답만으로는 노출로 판단하지 않습니다. 많은 사이트가 존재하지 않는 경로에도 일반 페이지를 반환합니다(“소프트 404”). 응답 본문이 해당 파일 유형의 콘텐츠 시그니처(예: Git HEAD 파일의 ref: 줄, phpinfo 페이지의 구조)와 일치할 때만 노출로 보고합니다. 응답 본문은 최대 64KB까지 메모리에서만 검사하며, 저장하거나 반환하지 않습니다. 결과에는 상태 코드와 헤더 값만 표시됩니다.

워드프레스 점검

홈페이지에서 워드프레스 신호가 두 가지 이상 확인되면(예: /wp-content/ 경로, generator 메타 태그, REST API Link 헤더) 아래 점검을 추가로 실행합니다. 그렇지 않으면 건너뛰고, 보고서에 워드프레스가 감지되지 않았다고 표시합니다.

점검 확인 대상 분류 기준
워드프레스 버전 홈페이지의 generator 메타 태그 버전이 노출되면 잠재적 문제, 표시되지 않으면 통과
플러그인과 테마 홈페이지가 이미 참조하는 플러그인·테마 파일 경로(경로 추측 없음) 목록은 홈페이지에서 가져오고, 상태는 아래에 설명한 데이터베이스 조회로 확인하며, 조회에 실패하면 “확인 불가”로 표시합니다
REST API 사용자 목록 /wp-json/wp/v2/users에 GET 1회 계정 목록이 공개되면 잠재적 문제. 계정 수만 기록하며 사용자 이름은 기록하지 않습니다
작성자 아카이브 사용자 이름 /?author=1에 GET 1회(리디렉션은 따라가지 않음) /author/<이름>/으로 리디렉션되면 잠재적 문제. 이름은 기록하지 않습니다
XML-RPC /xmlrpc.php에 GET 1회(XML-RPC 호출은 보내지 않음) 표준 “POST 요청만 허용” 응답이 오면 잠재적 문제
업로드 폴더 목록 /wp-content/uploads/에 GET 1회 “Index of” 페이지가 보이면 문제
기본 readme /readme.html에 GET 1회 공개되어 있으면 영향이 작은 잠재적 문제

취약점 데이터베이스 조회. 스캔이 끝나면 감지된 워드프레스 버전과 최대 15개의 플러그인·테마를 키 없이 쓸 수 있는 무료 공개 출처 두 곳에서 조회합니다. 알려진 취약점은 WPVulnerability에서, 코어 버전 상태(최신 / 오래됨 / 안전하지 않음)와 플러그인 최신 버전·중단 여부는 WordPress.org API에서 가져옵니다. 버전 범위는 워드프레스가 쓰는 version_compare() 규칙과 같은 방식으로 비교합니다. 플러그인 버전은 파일 주소(?ver=)에서 읽은 추정값이므로 일치해도 확정이 아닌 영향 가능성 높음으로 표시합니다. 워드프레스가 기본으로 붙이는 코어 버전과 같은 값은 무시합니다. 조회에 실패하면 확인 불가로 표시하며, 실패를 “알려진 취약점 없음”으로 표시하지 않습니다.

워드프레스 여부와 관계없이 모든 홈페이지에서 display_errors가 출력한 PHP 오류 메시지도 확인합니다(발견 시 문제). 오류 종류만 보고하며 메시지 내용이나 파일 경로는 기록하지 않습니다.

결과 분류

  • 문제 발견(Issue detected): 점검에서 명확한 문제를 발견했습니다.
  • 잠재적 문제(Potential issue): 검토할 가치가 있으며, 환경에 따라 허용될 수도 있습니다.
  • 이 점검에서 문제 미발견(No issue detected by this check): 해당 점검에서는 발견된 것이 없습니다. 사이트가 안전하다는 의미가 아닙니다.
  • 판단 불가(Unable to determine): 시간 초과, 차단, 예상치 못한 응답 등으로 점검을 완료하지 못했습니다.

스캐너가 하지 않는 일

취약점을 악용하지 않으며, 자격 증명을 무차별 대입하거나 추측하지 않고, 사이트를 크롤링하거나 매개변수를 퍼징하지 않습니다. 포트 스캔, 폼 테스트, 대상에 대한 POST 요청도 하지 않습니다.

SSRF 보호 조치

스캐너는 사용자가 입력한 URL을 PatchScope 인프라에서 요청하므로 엄격한 요청 통제를 적용합니다.

  • 기본 포트의 http, https만 허용합니다.
  • URL에 자격 증명을 포함할 수 없습니다.
  • IP 주소 리터럴은 거부합니다.
  • 내부용 및 특수 용도 호스트 이름은 거부합니다(예: localhost, .local, .internal).
  • DNS는 DNS-over-HTTPS로 조회하며, 조회된 모든 주소가 공인 주소여야 합니다.
  • 리디렉션은 최대 5회까지, 각 단계마다 같은 규칙으로 다시 검증합니다.
  • 요청당 6초 제한 시간, 스캔당 총 약 25초의 시간 예산이 있습니다.
  • 스캔당 요청 수 상한과 클라이언트별 속도 제한이 적용됩니다.

사용자 에이전트

요청은 다음 사용자 에이전트로 전송됩니다.

PatchScopeBot/1.0 (+https://patchscope.evoa.one/methodology)

사이트 점검을 원하지 않는 사이트 소유자는 이 사용자 에이전트를 차단하시면 됩니다.

알려진 한계

  • 백포트된 수정. PHP 버전 번호만으로는 호스팅 업체나 Debian, Ubuntu, RHEL 같은 Linux 배포판이 보안 수정을 백포트했는지 증명할 수 없습니다. 8.1.2로 표시되는 배포판 패키지에 훨씬 이후 업스트림 릴리스의 수정이 포함되어 있을 수 있습니다. 확실한 답은 배포판의 보안 트래커나 패키지 변경 기록에서 확인하시기 바랍니다.
  • 헤더 기반 점검은 사이트가 노출하는 정보만 봅니다. X-Powered-By를 숨긴다고 PHP가 업그레이드되는 것은 아니며, 헤더가 없다고 해서 실행 중인 버전을 알 수 있는 것도 아닙니다.
  • CDN과 WAF는 헤더를 추가, 제거 또는 재작성할 수 있으므로, 결과가 원본 서버가 아닌 엣지를 설명할 수 있습니다.
  • 소프트 404 처리는 시그니처에 의존합니다. 일반적이지 않은 서버 응답은 “판단 불가” 결과가 나올 수 있습니다.
  • 외부 관점만 제공합니다. 외부 스캔으로는 서버 설정, 설치된 플러그인, 파일 권한, 애플리케이션 코드를 볼 수 없습니다.
  • 부분적인 권고 커버리지. 데이터셋은 큐레이션된 것이며 모든 권고를 포함하지는 않습니다. 데이터셋에 CVE가 없다는 것이 해당 CVE가 존재하지 않는다는 증거는 아닙니다. CVE 조회에서 결과가 없으면 CVE.org와 NVD로 연결해 드립니다.
  • 최근 레코드. 2026년 권고는 1차 검증이 끝날 때까지 2차 출처에 의존할 수 있으며, 검증 수준이 함께 표시됩니다.

오류 신고

잘못된 버전 범위, 누락된 권고, 틀린 날짜, 잘못 분류된 웹사이트 점검 결과를 발견하시면 알려 주시기 바랍니다. GitHub 저장소에 이슈를 등록하시거나 문의 페이지의 연락처를 이용하실 수 있습니다. 권고 또는 CVE ID, 테스트한 버전이나 URL, PatchScope가 표시한 내용, 예상한 결과, 수정 근거가 되는 출처 링크를 함께 보내 주십시오.

PatchScope 자체의 보안 취약점은 공개적으로 신고하지 마십시오. 보안 정책을 참고하시기 바랍니다.