2023년 말, 우리 팀은 고객사 A사의 웹 서비스에 신규 기능을 배포하면서 동시에 오래된 XSS 취약점(CVE‑2022‑12345) 패치를 적용하려고 했습니다. 배포 전 사전 검증 단계에서 취약점 스캐너가 해당 취약점을 ‘미탐지’로 표시했기에, 저는 ‘이미 패치된 것 같다’는 생각에 별다른 조치를 취하지 않았습니다.
하지만 배포 직후, 보안 로그에 의심스러운 스크립트 삽입 시도가 포착되었습니다. 실제로는 패치가 적용되지 않은 상태였고, 공격자는 입력값을 통해 관리자 페이지에 자바스크립트를 삽입해 세션 쿠키를 탈취하려 했습니다.
재현해봤더니, 패치 스크립트가 조건부 로드되는 구조였음에도 CI 파이프라인에서 환경 변수 `PATCH_MODE=off`가 설정돼 있었고, 이 때문에 패치 파일이 빌드 단계에서 제외되었습니다. 성공 기준은 공격 URL에 접근했을 때 쿠키가 노출되지 않아야 했고, 실패 기준은 쿠키가 그대로 노출되는 것이었습니다.
문제를 해결하기 위해 먼저 CI 설정 파일(.gitlab-ci.yml)을 점검했고, `PATCH_MODE` 플래그를 강제 `on`으로 고정했습니다. 이후 로컬에서 `docker-compose up`으로 전체 스택을 재현해 패치가 정상 적용되는지 확인했으며, 스캐너도 다시 실행해 ‘취약점 발견’으로 결과가 바뀌는 것을 확인했습니다.
이번 경험을 통해 얻은 교훈은 ‘스캐너 결과만 믿지 말고, 배포 파이프라인의 환경 변수와 조건부 로직을 반드시 검증하라’는 점입니다. 특히 자동화된 빌드·배포 환경에서는 작은 설정 하나가 전체 보안 방어선을 무너뜨릴 수 있음을 절실히 느꼈습니다.
하지만 배포 직후, 보안 로그에 의심스러운 스크립트 삽입 시도가 포착되었습니다. 실제로는 패치가 적용되지 않은 상태였고, 공격자는 입력값을 통해 관리자 페이지에 자바스크립트를 삽입해 세션 쿠키를 탈취하려 했습니다.
재현해봤더니, 패치 스크립트가 조건부 로드되는 구조였음에도 CI 파이프라인에서 환경 변수 `PATCH_MODE=off`가 설정돼 있었고, 이 때문에 패치 파일이 빌드 단계에서 제외되었습니다. 성공 기준은 공격 URL에 접근했을 때 쿠키가 노출되지 않아야 했고, 실패 기준은 쿠키가 그대로 노출되는 것이었습니다.
문제를 해결하기 위해 먼저 CI 설정 파일(.gitlab-ci.yml)을 점검했고, `PATCH_MODE` 플래그를 강제 `on`으로 고정했습니다. 이후 로컬에서 `docker-compose up`으로 전체 스택을 재현해 패치가 정상 적용되는지 확인했으며, 스캐너도 다시 실행해 ‘취약점 발견’으로 결과가 바뀌는 것을 확인했습니다.
이번 경험을 통해 얻은 교훈은 ‘스캐너 결과만 믿지 말고, 배포 파이프라인의 환경 변수와 조건부 로직을 반드시 검증하라’는 점입니다. 특히 자동화된 빌드·배포 환경에서는 작은 설정 하나가 전체 보안 방어선을 무너뜨릴 수 있음을 절실히 느꼈습니다.
💬 댓글 2