취약점 점검과 pen test 대응은 왜 상시 체계여야 하나

보안 취약점 점검과 침투 테스트(penetration test)는 많은 조직에서 연 1회 수행하는 ‘이벤트’로 취급된다. 하지만 새로운 CVE(Common Vulnerabilities and Exposures)는 매일 발표되고, 코드는 매주 변경되며, 인프라는 지속적으로 업데이트된다. 연 1회 점검으로는 나머지 364일의 취약점을 알 수 없다.

이 글은 Breeze 플랫폼에서의 취약점 점검과 pen test 경험을 통해, 왜 상시(continuous) 체계가 필요한지를 주장한다. 연례 pen test에서 발견된 문제를 수정하고, 다음 해 pen test에서 새로운 문제가 발견되는 패턴은 근본적으로 비효율적이다.

취약점 스캐닝(scanning)과 침투 테스트(pen test)는 목적과 방법이 다르다. 이 차이를 이해하고 각각을 적절히 활용하는 것이 중요하며, 그 구체적 경험을 기록한다.

Breeze 플랫폼은 Nike의 커머스 백엔드로, 고객의 개인정보와 결제 정보를 처리하는 시스템이었다. 이런 시스템에서 보안 취약점은 곧 사업 리스크다. 취약점을 통해 고객 데이터가 유출되면 법적 제재, 과징금, 브랜드 손상이 발생한다.

한국의 규제 환경에서는 ISMS 인증의 일환으로 정기적인 취약점 점검이 요구되며, 연 1회 이상의 모의해킹(pen test)도 수행해야 한다. 이 규제 요구사항을 충족하는 것은 최소한의 기준이었고, 실제 보안 수준을 높이기 위해서는 이를 넘어서는 상시 체계가 필요했다.

OWASP Top 10은 웹 애플리케이션의 가장 흔한 보안 위험 10가지를 정리한 목록이다. Injection, Broken Authentication, Sensitive Data Exposure, XSS, CSRF 등이 포함된다. 이 목록은 pen test에서 자주 검사되는 항목이기도 하며, 개발 단계에서부터 이 항목들을 방어적으로 코딩하는 것이 중요했다.

취약점 스캐닝 vs 침투 테스트: 목적의 차이

취약점 스캐닝(vulnerability scanning)은 자동화 도구를 사용하여 알려진 취약점(CVE)이 시스템에 존재하는지를 검사하는 것이다. 사용 중인 라이브러리의 버전과 알려진 CVE 데이터베이스를 대조하여 취약한 버전을 식별한다. ScanAtSource 같은 도구가 이 역할을 한다. 빠르고 자동화가 가능하지만, 비즈니스 로직의 취약점은 발견하지 못한다.

침투 테스트(pen test)는 실제 공격자의 관점에서 시스템을 공격하여 취약점을 발견하는 것이다. 자동화 도구로는 발견하기 어려운 비즈니스 로직 취약점(예: 가격 조작, 권한 우회, 레이스 컨디션을 이용한 중복 주문 등)을 발견할 수 있다. 수동 테스트이므로 비용과 시간이 많이 들지만, 스캐닝으로는 발견할 수 없는 문제를 찾아낸다.

상시 보안 운영 루프

Pen Test 결과가 코드 변경으로 이어지는 과정

pen test에서 취약점이 발견되면 보고서가 작성되고, 각 취약점에 심각도(Critical, High, Medium, Low)가 부여된다. 개발팀은 이 보고서를 받아 각 취약점에 대한 수정 계획을 수립해야 한다. Critical/High는 즉시 수정, Medium은 다음 릴리즈까지, Low는 백로그에 추가하는 식으로 우선순위를 정했다.

pen test 결과를 실제 코드 수정으로 연결하는 과정은 간단하지 않다. 보고서에 ‘인증 우회 가능’이라고 적혀 있어도, 어떤 코드에서 어떻게 수정해야 하는지는 개발자가 분석해야 한다. pen test 수행 업체와 내부 개발팀 간의 커뮤니케이션이 중요한 이유가 여기에 있다. 단순히 보고서를 받아보는 것이 아니라, 발견된 취약점의 재현 방법과 공격 경로를 이해해야 적절한 수정이 가능하다.

상시 스캐닝 체계의 필요성

새로운 CVE는 매일 발표된다. 어제까지 안전하던 라이브러리가 오늘 발표된 CVE로 인해 취약해질 수 있다. Log4j(CVE-2021-44228)가 대표적 사례다. 연 1회 스캐닝으로는 이런 제로데이 또는 신규 CVE에 대응할 수 없다.

상시 스캐닝 체계란, CI/CD 파이프라인에 취약점 스캔을 통합하여 코드가 변경될 때마다 자동으로 의존성의 취약점을 검사하는 것이다. ScanAtSource 등의 도구를 빌드 과정에 포함시키면, 취약한 라이브러리가 포함된 코드는 빌드 자체가 실패하도록 설정할 수 있다. Critical/High 취약점이 있으면 빌드를 차단(block)하는 정책이 이 체계의 핵심이다.

OWASP Top 10과 방어적 코딩

OWASP Top 10은 웹 애플리케이션 보안의 기본 지침서 역할을 한다. SQL Injection을 방지하기 위한 파라미터화된 쿼리(parameterized query), XSS를 방지하기 위한 출력 인코딩(output encoding), CSRF를 방지하기 위한 토큰 기반 검증 등 — 이런 방어적 코딩 패턴을 팀 전체가 숙지하고 적용하는 것이 pen test보다 앞선 단계의 보안이다.

pen test에서 OWASP Top 10에 해당하는 취약점이 발견된다면, 이는 개발 단계에서의 보안 인식이 부족했다는 신호다. 코드 리뷰 단계에서 보안 항목을 체크하는 습관, 보안 코딩 가이드라인의 팀 내 공유, 신규 멤버에 대한 보안 교육 등이 pen test 이전의 방어선이 되어야 한다.

연례 점검에서 상시 체계로의 전환 경험

Breeze 팀의 경험에서, 연례 pen test는 그 자체로 가치가 있었지만, 근본적 한계가 있었다. pen test 직후에는 보안 의식이 높아지지만, 시간이 지나면 다시 일상 업무에 밀려 보안 의식이 낮아지는 패턴이 반복되었다. 상시 스캐닝과 CI/CD 통합을 도입한 후에는, 보안이 특별한 이벤트가 아니라 일상적인 개발 프로세스의 일부가 되었다.

상시 체계의 도입이 개발 속도를 늦추지는 않았다. 처음에는 빌드 실패가 빈번하여 적응 기간이 필요했지만, 팀이 보안 요구사항을 사전에 고려하는 습관이 생긴 후에는 빌드 차단 건수가 크게 줄었다. 보안을 나중에 고치는 것보다 처음부터 고려하는 것이 결과적으로 빠르다.

운영 안정성과 보안은 개별 도구의 문제가 아니라 개발 흐름과 운영 기준을 바꾸는 구조적 작업이었다. 다음 글에서는 2021 - 장애 감지와 알림 체계는 어떤 신호부터 잡아야 실무에 도움이 되나를 통해 이 흐름을 계속 좁혀 본다.

점검 방식 비교 요약

상시 보안 체계의 트레이드오프

상시 스캔의 장점은 신규 취약점을 짧은 주기로 발견하고 대응할 수 있다는 점이다. 연간 점검 중심 체계보다 위험 노출 기간이 짧아지고, 릴리스 품질 기준도 일관되게 유지할 수 있다.

단점은 초기에는 빌드 차단과 대응 티켓이 늘어나 개발 부담이 커진다는 점이다. 그러나 기준이 정착되면 팀이 선제적으로 취약점 패턴을 피하게 되고, 결과적으로 긴급 대응 비용이 줄어든다.

상시 보안 운영 체크포인트

• SCA/SAST/DAST 결과를 배포 파이프라인과 연동해 기준 미달 시 차단한다.
• 취약점 등급별 대응 SLA를 정의하고 예외 승인 경로를 분리한다.
• pen test 결과는 재발 방지 패턴(코드/설정/운영)으로 환원해 재사용한다.