PHP 보안 대응에서 드러난 AI와 사람의 역할
2026년 10월 21일 PHP는 CVE-2026-109618·CVE-2026-109619를 수정한 보안 릴리스를 발표했습니다. PHP Foundation에 따르면 첫 문제의 징후는 2024년 사람이 수행한 보안 감사의 후속 작업에서 발견됐습니다. 2026년 여러 연구팀의 보고로 영향이 구체화됐고, AI는 보고서 검증과 같은 원인의 묶음을 찾는 데 활용됐습니다. 재단은 판단과 각 패치 작업은 사람이 맡았다고 설명합니다. 'AI가 혼자 발견해 자동으로 해결했다'고 줄이면 실제 과정을 놓칩니다. 아래는 10월 21일 두 취약점에 대해 발표된 업스트림 릴리스입니다. 모든 환경의 최신 버전 목록이나 안전 판정표가 아닙니다. Linux 배포판·LTS 업체가 기존 버전에 수정을 반영하는 백포트를 제공할 수 있으므로, 버전 숫자만 비교하지 말고 공급자의 보안 공지와 적용 패키지를 대조해야 합니다. 업데이트 뒤의 후속 공지도 중요합니다. PHP는 10월 23일 세션 업로드 진행 기능에 관한 추가 안내를 냈습니다. 세션 직렬화 방식이 설정상 php_binary 또는 php_serialize인데 애플리케이션이 session_start() 전에 ini_set()으로 php로 바꾸고, 업로드 진행 기능도 켜져 있는 특이한 조합을 설명합니다. 해당 여부와 session.upload_progress.enabled=0 권고는 담당자가 원문에 따라 확인해야 합니다. 런타임에 직렬화 방식을 바꾸지 않는 애플리케이션은 기능을 유지할 수 있다는 구분도 있습니다. 즉, 21일 릴리스 번호를 확인했다고 23일 안내까지 검토한 것은 아닙니다. 실제 서비스의 PHP 실행 환경·공급자 패키지·추가 공지 적용 조건을 함께 기록해야 패치 여부를 판단할 수 있습니다.
| PHP 계열 | 발표된 수정 릴리스 |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
탐지·버전 변경·AI 코드 수정은 다른 단계
여기서 오픈소스 보안 AI는 오픈소스가 포함된 소프트웨어의 보안 문제를 분석하거나 수정안을 제안하는 AI 활용을 뜻합니다. 도구 자체가 오픈소스라는 의미나, 자동 업데이트 도구가 모두 생성형 AI라는 의미는 아닙니다. GitHub의 Copilot Autofix는 CodeQL 경고와 코드 문맥을 바탕으로 변경안을 제안하는 사례입니다. 의존성은 프로그램이 사용하는 외부 패키지입니다. 직접 추가한 패키지가 다시 불러오는 패키지도 있어, 최상위 목록만 바꾸면 필요한 수정이 모두 끝난다고 단정할 수 없습니다. 아래 표는 기능을 구분하기 위한 편집 요약이며 제품의 성능 순위가 아닙니다.
| 받은 결과 | 뜻하는 것 | 다음 검토 |
|---|---|---|
| 취약점 경고 | 해당 조건을 조사할 근거가 생김 | 실제 사용 버전과 영향 조건 일치 여부 |
| 의존성 변경안 | 패키지 구성·버전 변경이 제안됨 | 직접·간접 변경 범위와 호환성 |
| AI 코드 수정안 | 경고 해결을 위한 코드 후보가 생김 | 수정의 타당성·기능 유지·새 문제 여부 |
파일에 적힌 버전과 실행 중인 버전
OSV-Scanner는 소스 의존성을 점검할 때 버전이 결정된 잠금 파일을 우선하도록 안내합니다. manifest는 필요한 패키지와 버전 범위를 선언하는 파일이고, lockfile은 해석된 패키지 버전을 기록하는 잠금 파일입니다. manifest에 적힌 범위를 실제 설치 버전으로 읽으면 안 됩니다. 컨테이너 검사에서는 실제 설치된 구성 요소가 핵심이라는 구분도 있습니다. 수정 요청에는 검사한 커밋, 대상 파일, 패키지 이름, 기존·변경 버전을 남기세요. 예를 들어 package.json 한 줄만 바뀌었더라도 package-lock.json에서 여러 간접 의존성이 함께 바뀔 수 있습니다. 변경 요청은 코드와 의존성을 합친 전체 차이로 검토하고, 배포 후에는 실행 중인 이미지나 설치 패키지가 승인한 변경과 일치하는지 대조합니다.
자동 수정안에 새 패키지가 들어왔다면
GitHub는 Copilot Autofix가 문법상 올바른 코드라도 동작을 바꾸거나, 문제를 일부만 해결하거나, 새 취약점을 만들 수 있다고 설명합니다. 존재하지 않는 패키지를 제안할 가능성도 명시합니다. 낯선 의존성이 추가됐다면 이름만 보고 설치하지 말고 실제 배포처·유지보수 상태·해당 버전과 필요한 이유를 확인하세요. 검토자는 경고가 지적한 코드 경로를 수정했는지, 검사를 삭제하거나 경고만 억제한 것은 아닌지 살펴야 합니다. 이후 해당 보안 검사와 프로젝트의 기존 테스트를 실행하고, 변경된 기능을 다루는 회귀 테스트를 더합니다. 로그인이나 파일 업로드처럼 영향을 받는 흐름은 정상 입력뿐 아니라 거부돼야 할 입력도 승인된 테스트 환경에서 검증하세요. 테스트 통과는 실행한 범위의 결과이지 모든 취약점이 없다는 증명이 아닙니다.
자동 적용 전에 남길 변경 요청 예시
OSV-Scanner의 Guided Remediation은 확인 시점에 실험적 기능이며, 의존성 변경 파일과 지원 전략에 제한이 있습니다. 검사 가능한 모든 생태계를 자동 수정한다는 뜻은 아닙니다. 공식 안내는 신뢰하지 않는 프로젝트에서 패키지 관리자가 스크립트를 실행하거나 외부 저장소에 접근할 수 있음을 경고합니다. 의존성 구성을 다시 계산하면 변경 폭과 호환성 위험도 커질 수 있습니다. npm 잠금 파일을 고친 것만으로 node_modules 설치가 갱신되지는 않습니다. 운영 서버에서 시험 삼아 실행하기보다, 백업된 변경 전 상태와 승인된 격리 환경을 준비해야 합니다. 다음은 실제 패키지나 사고 사례가 아닌 검토 기록 예시입니다. 대상: 서비스 A / 승인된 시험 브랜치 / 검사한 커밋 근거: 취약점 원문과 영향 버전 / 사용 중 버전 변경: 직접·간접 의존성 목록 / 코드 차이 / 새 패키지 유무 검증: 보안 재검사 / 기존 테스트 / 영향 기능 테스트 / 미검증 범위 승인: 검토자 / 배포 담당자 / 배포 후 적용 상태 확인 방법 복구: 되돌릴 변경·산출물 / 복구 시 남는 보안 위험 / 재검토 일정 수정 후보가 생성됐다는 이유로 병합·배포 권한까지 넓힐 필요는 없습니다. 경고에서 수정 완료까지 걸린 시간과 검토·재작업 시간을 따로 기록하면, 제안 건수만 셀 때보다 자동화의 실제 효과를 판단하기 좋습니다. 이 글에는 그 효과를 측정한 수치가 없습니다.