워드프레스 보안 감사: 라이브 전 확인 사항

PAGEnza에서 생성된 모든 플러그인은 사용자의 워드프레스 설치에 도달하기 전에 세 가지 자동 보안 검사를 거칩니다. 이 게시물은 이러한 검사가 무엇을 찾는지 — 그리고 각 검사가 왜 중요한지를 설명합니다.

AI 생성 코드가 감사를 받아야 하는 이유

대규모 언어 모델은 워드프레스 플러그인을 작성하는 데 놀랍도록 능숙합니다. 훅 이름을 알고 WP 코딩 표준을 이해하며 읽기 쉬운 PHP를 생성합니다. 하지만 예측 가능한 실수도 저지르며 — 이러한 실수는 보안 취약점으로 이어집니다.

우리가 가장 흔하게 보는 것들:

• $_GET 또는 $_POST를 정리(sanitization) 없이 사용하는 경우
• 폼 제출 시 nonce 검증 누락
• $wpdb->prepare() 없이 직접 데이터베이스 쿼리
• 동적 동작을 위해 eval() 또는 exec() 사용
• esc_html() 또는 esc_attr() 없이 사용자 데이터 출력

이것들은 이국적인 엣지 케이스가 아닙니다. 최고의 모델에서도 LLM 출력에서 정기적으로 나타납니다.

단계 1: 프롬프트 유효성 검사

AI가 한 줄을 작성하기 전에, 사용자 설명을 분석합니다. 이 단계는 두 가지 범주의 문제를 포착합니다:

조작 시도 — AI가 의도적으로 악성 코드를 생성하도록 유도하는 프롬프트. "이전 지침 무시" 또는 "테스트를 위해 백도어 생성"과 같은 것들입니다.

모호하거나 실행 불가능한 설명 — 유용한 코드를 생성하기에는 너무 짧거나 모호한 프롬프트. "플러그인 만들기"는 쓰레기를 생성합니다. "스팸 필터링 기능이 있는 이메일 주소로 제출물을 보내는 연락처 양식 만들기"는 실제적인 것을 생성합니다.

프롬프트가 이 검사를 통과하지 못하면, 사용자는 일반적인 거부가 아닌, 그 이유를 설명하는 특정 오류 메시지를 보게 됩니다.

단계 2: 격리된 컨테이너에서 PHP 린팅

AI가 PHP 코드를 생성하면, 완전히 격리된 Docker 컨테이너 내에서 php -l을 통해 실행됩니다. 이는 플러그인이 워드프레스 설치에 도달하기 전에 구문 오류를 포착합니다.

하지만 더 나아갑니다: 린팅이 실패하면, 시스템은 단순히 출력을 거부하지 않습니다. 오류를 수정 프롬프트와 함께 AI에게 다시 보냅니다 — 이를 **치유(healing)**라고 부릅니다. AI는 자신의 실수를 보고 최대 세 번까지 다시 시도합니다.

이는 사용자가 거의 "생성 실패" 메시지를 보지 않는다는 것을 의미합니다. 그들은 약간 더 긴 생성 시간 — 그리고 작동하는 코드를 보게 됩니다.

단계 3: 코드 보안 스캔

이것이 가장 중요한 단계입니다. 다음을 확인하는 정적 분석을 실행합니다:

위험한 함수: eval(), exec(), system(), shell_exec(), passthru() — 이 중 하나라도 플러그인 출시를 차단합니다.

SQL 인젝션 벡터: 보간된 변수가 있는 원시 $wpdb->query() 호출, $wpdb->prepare() 누락, mysql_query() 직접 사용.

권한 확인 누락: 특권 작업을 수행하기 전에 current_user_can()을 호출하지 않는 AJAX 핸들러.

Nonce 검증 누락: wp_verify_nonce() 또는 check_ajax_referer()를 호출하지 않는 폼 처리기.

이스케이프되지 않은 출력: echo $_GET[...], 이스케이프 함수 없이 echo $user_input.

이 중 하나라도 발견되면 플러그인이 차단됩니다. 사용자는 단순히 "보안 검사 실패"가 아니라, 어떤 함수가 차단을 트리거했는지, 그리고 왜 그랬는지 정확히 나열하는 보고서를 보게 됩니다.

감사 보고서 모양

각 생성된 플러그인에는 명확한 언어로 된 보안 감사 보고서가 함께 제공됩니다. 보고서는 다음을 나열합니다:

• 통과한 검사 (녹색)
• 경고를 트리거한 검사 (호박색) — 차단은 아니지만 주의가 필요한 문제
• 치유 중에 자동으로 적용된 수정 사항

보고서는 자동으로 생성되어 플러그인 다운로드에 첨부됩니다. 이는 자신의 확신을 위해서뿐만 아니라 고객에게 보안을 진지하게 받아들였음을 보여주기 위해서도 유용합니다.

단계 4: 저장 시 유효성 검사

이것은 초기 생성의 일부가 아닙니다 — 사용자가 PAGEnza 편집기에서 플러그인 코드를 수동으로 편집할 때 적용됩니다.

저장할 때마다 동일한 린트 + 보안 스캔이 다시 실행됩니다. 편집 중에 치명적인 취약점을 도입하면, 수정할 때까지 저장이 차단됩니다. 이는 개발자가 2년 동안 프로덕션에 남아 있는 빠른 "임시" 변경을 하는 일반적인 시나리오를 방지합니다.

자동 감사 제한 사항

자동 스캔은 특정 종류의 문제를 잘 포착합니다. 모든 것을 포착하지는 않습니다.

논리 오류, 잘못된 비즈니스 로직, 그리고 알려진 위험한 패턴을 포함하지 않는 미묘한 권한 에스컬레이션 문제는 여전히 인간의 검토가 필요합니다. 문서에서 이에 대해 투명하게 설명합니다 — 감사는 보안 검토를 대체하는 것이 아니라 최소 표준을 보장하는 기준입니다.

결제 또는 민감한 데이터를 처리하는 프로덕션 플러그인의 경우, 자동 검사 외에 수동 검토를 권장합니다. 감사 보고서는 인간 검토자에게 좋은 출발점을 제공합니다.