이 글은 인프런 강의 「백엔드 개발자를 위한 서버 보안 실무」 섹션 7을 입문자용으로 풀어 쓴 시리즈 마지막 글이에요.
금요일 오후 5시의 공지
금요일 오후, 보안 뉴스에 "널리 쓰이는 라이브러리에서 원격 코드 실행 취약점, 이미 악용 중"이라는 소식이 올라옵니다. 팀 채널이 술렁여요.
- 그 라이브러리, 우리도 쓰나요?
- 어느 서버, 어느 이미지에 들어 있죠?
- 지금 당장 패치해야 하나요, 월요일에 해도 되나요?
이 질문에 15분 안에 답할 수 있는 팀과 이틀 동안 찾아다니는 팀의 차이가, 이번 글의 주제예요.
다 읽을 수 없다, 거르는 기준이 필요하다
새로 공개되는 CVE는 하루에도 수백 건이에요. 누구도 이걸 다 읽을 수 없습니다. 그래서 깔때기가 필요해요.
맨 아래 칸이 가장 중요합니다. 내 자산 목록이 곧 필터예요. 우리가 무엇을, 어떤 버전으로, 어디에 쓰는지 모르면 아무리 좋은 정보원이 있어도 거를 수가 없어요. 그래서 이 시리즈 내내 자산 목록, 잠금 파일, 이미지 재료 목록(SBOM)을 강조한 거예요.
점수 세 개, 읽는 순서
취약점에는 보통 세 가지 신호가 붙어요.
- CVSS: 터지면 얼마나 심각한가. 우리에게 익숙한 0~10점 점수예요.
- EPSS: 앞으로 30일 안에 악용될 가능성이 얼마나 되는가.
- KEV: 미국 CISA가 관리하는, 이미 실제 공격에 쓰이고 있는 취약점 목록.
입문자가 가장 많이 하는 실수는 CVSS 점수 순서대로 고치는 거예요. 하지만 CVSS가 높아도 아무도 공격하지 않을 수 있고, 점수가 그리 높지 않아도 이미 공격받고 있을 수 있습니다. 그래서 판단 순서는 KEV → EPSS → CVSS예요. 단, KEV에 없다고 안전하다는 뜻은 아니에요. 아직 확인되지 않았을 뿐일 수 있으니까요.
국내라면 KISA 보호나라의 보안 공지도 함께 받아 두면 좋아요. 그리고 수정 버전은 배포판이나 벤더의 공지가 가장 정확합니다.
72시간이라는 운영 목표
이 강의는 "외부에 노출된 자산에서 악용 중인(KEV) 취약점이 나오면 72시간 안에 반영을 끝낸다" 를 운영 목표로 권해요. 법이 정한 기한이 아니라 팀이 스스로 정하는 약속입니다. (개인정보 유출 신고의 72시간과는 다른 이야기라 헷갈리지 마세요.)
큰 흐름은 다섯 단계예요.
- 받기: 공지가 오면 시계가 돌기 시작합니다.
- 해당 여부: 이 제품, 이 버전이 우리에게 있는가. 여기서 해당 자산 목록이 빨리 나와야 해요.
- 완화: 패치 전이라도 외부 노출 서버부터 급한 불을 끕니다.
- 패치: 한 번에 전체가 아니라 단계적으로 반영합니다.
- 검증·기록: 정말 수정 버전이 됐는지 다시 확인하고, 무엇을 언제 왜 했는지 남겨야 끝이에요. 공지 이전부터 노린 흔적이 없는지도 돌아봅니다.
핵심은 이 흐름을 사건이 터질 때마다 새로 발명하지 않는 것이에요. 매일 아침 자동으로 스캔하고 KEV와 대조해, 사람은 걸러진 결과만 보는 구조를 만들어 두면 하루 15~30분이면 충분합니다.
내 서비스는 지금 어느 단계일까
시리즈 전체를 네 단계로 묶어 보면 이렇습니다. 가장 중요한 건 초급이 출발선이라는 점이에요. 키 로그인, 자동 패치, 기본 차단 방화벽, 서버 밖으로 보내는 로그. 이 기본을 다 채우지 못했다면, 화려한 탐지 도구보다 여기부터 시작하세요.
정리
- 모든 CVE를 볼 수는 없다. 내 자산 목록이 곧 필터다.
- 판단 순서는 KEV → EPSS → CVSS. KEV에 없다고 안전한 건 아니다.
- 72시간은 법이 아니라 운영 목표. 흐름을 미리 만들어 두고, 기록해야 끝이다.
강의에서는 이걸 매일 굴러가게 만듭니다
섹션 7에서는 정보원을 한 채널로 모으고, 가상의 KEV 공지를 받아 72시간 안에 반영하는 과정을 시계를 옆에 두고 단계별로 따라갑니다.
- 배포판별로 해당 여부와 수정 버전을 확인하는 법, 컨테이너는 SBOM으로 찾기
- 매일 아침 스캔 결과를 KEV·EPSS와 대조해 등급을 매기고 알리는 자동화 스크립트
- 단계별로 쓰는 72시간 반영 기록 양식과, 내 서비스 레벨 진단 체크리스트
강의 보러 가기: https://inf.run/XvwyH
시리즈를 끝까지 읽어 주셔서 고마워요. 이 시리즈가 "보안은 보안팀의 일"에서 "내 서버, 내 코드의 일"로 생각이 바뀌는 계기가 됐다면 좋겠습니다. 직접 손으로 공격하고 고쳐 보고 싶다면 강의에서 만나요.
- 이전 글: 키 하나가 계정 전체가 될 때: 클라우드 보안과 사고 대응 입문
- 처음으로: 서버 보안, 왜 백엔드 개발자의 일일까
- 전체 목차: 시리즈 목차
