웹사이트 보안 스캔 보고서 읽는 법

첫 보안 스캔은 진단 덤프를 여는 느낌일 수 있습니다. 눈에 띄는 점수, 색으로 구분된 발견 항목의 벽, 그리고 수많은 약어. 점수는 *지금 어디에 있는지*를, 발견 항목은 *다음에 무엇을 할지*를 알려줍니다. 이 글은 보안 엔지니어가 하듯이 보고서를 읽는 법을, 맨 위의 숫자부터 이번 주 가장 먼저 고칠 한 가지까지 짚어 갑니다.

점수부터 보되, 거기서 멈추지 마세요

IsSafeSite는 세 가지 차원을 하나의 숫자로 합칩니다. 보안(60%), SEO(20%), 트래픽 보호(20%). 전체 점수가 좋아도 치명적인 문제 하나가 숨어 있을 수 있으니, 점수는 합격/불합격 판정이 아니라 시간에 따라 지켜보는 추세선으로 다루세요. 스캔의 핵심은 그 아래의 발견 항목입니다.

심각도로 먼저, 다음은 노력으로 정렬하세요

모든 발견 항목에는 심각도가 있습니다. 위험이 가장 큰 곳에 시간을 쓰도록 이 순서로 처리하세요:

1. 1치명적(Critical) — 지금 악용 가능하거나 데이터를 직접 노출함. 오늘 수정.
2. 2높음(High) — 현실적인 공격 경로, 또는 전체를 약화시키는 통제의 부재.
3. 3중간(Medium) — 다른 문제와 결합될 때 의미가 커지는 강화 공백.
4. 4낮음/정보(Low/Info) — 모범 사례 제안. 한 번의 정리 작업으로 묶어 처리.

같은 심각도 안에서는 비용이 낮은 수정부터 하세요. Strict-Transport-Security 헤더 누락은 한 줄 변경으로 영향이 큰 반면, 세션 처리를 재설계하는 일은 그렇지 않습니다. '저비용/고심각도' 항목부터 처리하는 것이 점수를 올리고 목록을 줄이는 가장 빠른 길입니다.

발견 항목 하나를 끝까지 읽으세요

각 발견 항목은 단독으로도 이해되도록 작성됩니다. 좋은 항목은 네 가지 질문에 답합니다:

• 무엇이 관찰되었는가 — 그것을 유발한 정확한 헤더, 경로, 인증서 필드 또는 응답.
• 왜 중요한가 — 일반적인 경고가 아니라 구체적인 위험.
• 어떻게 고치는가 — 구체적인 지시문, 설정 블록 또는 코드 변경.
• 어떻게 확인하는가 — 깨끗한 재스캔이 어떻게 보여야 하는지.

검색 결과의 수정을 한꺼번에 적용하려는 충동을 참으세요. 관련 없는 사이트에서 복사한 헤더 값은 앱을 망가뜨릴 수 있습니다(지나치게 엄격한 Content-Security-Policy가 전형적인 예). '어떻게'를 적용하기 전에 '왜'를 먼저 읽으세요.

오탐과 실제 공백을 구분하세요

자동 스캔은 대규모 패턴 매칭이므로 가끔 오탐이 나옵니다. CDN에서 설정되어 스캐너가 보지 못한 헤더나, 의도적으로 공개한 '노출' 경로 등입니다. 분석은 바로 당신이 판단할 수 있도록 심각도, 신뢰도, 증거를 제공합니다. 무언가를 제외하기 전에 자신의 설정과 대조해 확인하고, 제외한다면 그 이유를 적어 두세요.

보고서를 짧은 계획으로 바꾸세요

40개 할 일 목록이 아니라 계획으로 보고서를 마무리하세요. 실행 가능한 주간 리듬은 다음과 같습니다:

1. 1이번 주에 모든 치명적 항목과 한 줄로 끝나는 높음 항목을 고치세요.
2. 2남은 높음과 중간 항목에 담당자와 날짜를 지정하세요.
3. 3배치마다 재스캔하여 점수 변화와 회귀를 확인하세요.
4. 4의식적으로 수용하는 항목에는 예외 메모를 남기세요.

가장 자주 마주치는 헤더와 TLS 발견 항목에는 각각 자세한 글이 있습니다. 가장 흔한 10가지 보안 헤더 실수와 사이트를 위험에 빠뜨리는 SSL/TLS 설정 오류를 참고하세요. 재스캔 단계를 자동화할 준비가 되면 기능 페이지와 API 문서에서 CI에 연결하는 방법을 확인할 수 있습니다.