CVE-2024-YIKES 사고 보고서 — 작은 실수가 만든 큰 보안 사고

무슨 일이 있었나

한 개발자가 자기가 운영하던 서비스에서 발견한 보안 취약점에 대한 사고 보고서(incident report)를 공개했어요. 이름하야 "CVE-2024-YIKES". 'YIKES'는 "앗, 이런!" 같은 감탄사라서, 농담 섞인 작명이긴 한데 내용은 전혀 농담이 아니에요. 자기가 만든 서비스에서 인증(auth) 관련 코드의 작은 실수 하나가 어떻게 심각한 보안 사고로 번졌는지를 솔직하게 풀어낸 글이거든요.

이런 글이 귀한 이유는, 보통 회사들이 보안 사고가 나면 "고객 데이터에 영향 없음" 같은 한 줄 공지로 끝내거나, 아예 묻어버리는 경우가 많기 때문이에요. 어떻게 사고가 일어났고, 무엇을 잘못했고, 무엇을 배웠는지를 이렇게 자세히 공유해주는 포스트모템(postmortem)은 보안을 공부하는 사람한테 진짜 좋은 교재예요.

사고의 본질 — '작은 가정'이 만든 구멍

이런 종류의 사고는 거의 패턴이 정해져 있어요. 코드 자체는 멀쩡해 보여요. 컴파일도 잘 되고, 테스트도 통과하고, 정상 사용자가 쓰면 아무 문제가 없죠. 그런데 개발자가 "이 값은 항상 이런 형태일 거야", "이 함수는 항상 이렇게 호출될 거야" 하고 무의식적으로 깔아둔 가정 하나가 깨지면, 그게 보안 취약점이 되는 거예요.

예를 들어볼게요. 사용자 ID를 받아서 그 사람의 데이터를 보여주는 API가 있다고 쳐봐요. 개발자는 "로그인한 사용자만 자기 ID를 보낼 거야"라고 생각하고 코드를 짰어요. 그런데 누군가가 다른 사람의 ID를 일부러 넣어서 요청을 보내면? 권한 검사를 안 해놨다면 남의 데이터가 그대로 노출돼요. 이게 그 유명한 IDOR(Insecure Direct Object Reference) 취약점이에요. OWASP Top 10에 항상 올라오는 단골 메뉴죠.

인증 토큰 검증에서도 비슷한 일이 자주 생겨요. JWT(JSON Web Token, 사용자 인증에 흔히 쓰는 토큰)를 검증할 때 서명(signature)을 확인 안 하거나, 만료 시간을 체크 안 하거나, 알고리즘 필드를 'none'으로 보내면 그냥 통과시키는 라이브러리 버그를 만나거나요. 이런 것들이 다 "설마 누가 그렇게까지 하겠어?"라는 가정에서 출발한 사고들이에요.

포스트모템 문화가 왜 중요한가

이번 보고서가 의미 있는 또 하나의 이유는 "비난 없는 포스트모템(blameless postmortem)" 의 좋은 사례라는 거예요. Google SRE 책에서 강조한 개념인데요, 사고가 났을 때 "누가 잘못했지?"가 아니라 "왜 이런 사고가 일어날 수 있는 환경이었지?"를 묻는 문화예요.

개인이 실수를 하지 않게 만드는 건 거의 불가능해요. 사람은 누구나 실수하니까요. 대신 실수가 사고로 이어지지 않는 시스템을 만드는 게 중요해요. 코드 리뷰, 자동화된 보안 스캔(Snyk, Semgrep, GitHub의 CodeQL 같은 도구들), 권한 기본값을 "거부"로 두기, 모든 API에 인증 미들웨어를 강제로 적용하기, 의심스러운 행동을 모니터링하는 시스템 같은 거죠.

이번 사고에서도 결국 "한 사람의 실수"가 시스템적인 안전망을 뚫고 나가버린 거예요. 그래서 보고서에서는 코드 자체의 패치보다도, 앞으로 비슷한 종류의 실수를 자동으로 잡아낼 수 있는 도구나 프로세스를 어떻게 추가할지에 더 많은 분량을 할애하고 있어요.

업계의 사고 공개 흐름

최근 몇 년 사이 보안 사고를 투명하게 공개하는 회사들이 늘고 있어요. Cloudflare는 자기네 장애나 사고를 굉장히 자세하게 블로그로 공개하는 걸로 유명하고, GitLab, Stripe, Heroku도 마찬가지예요. 한국에서도 토스, 당근, 카카오 등이 기술 블로그에서 장애 회고를 공유하기 시작했어요. 이게 단순히 "투명한 회사" 이미지를 위한 게 아니라, 공유된 사고는 업계 전체의 면역력을 키워준다는 점에서 중요한 거예요. 다른 팀이 같은 실수를 안 하게 도와주는 거죠.

한국 개발자에게 주는 시사점

첫째, 본인 코드의 "숨은 가정"을 의심해보세요. 입력값이 늘 정상일 거라는 가정, 호출 순서가 항상 같을 거라는 가정, 인증된 사용자는 항상 권한이 있을 거라는 가정 같은 거요. "공격자가 이걸 어떻게 악용할 수 있을까?"라는 관점으로 한 번씩 자기 코드를 다시 봐주는 시간이 필요해요.

둘째, 사내에 포스트모템 문화를 만드는 데 한 몫 해보세요. 작은 사고라도 "왜 일어났고, 다음에 어떻게 막을지"를 문서화하는 습관이요. 처음에는 어색해도 한두 번 해보면 팀의 학습 속도가 확연히 빨라져요.

셋째, CodeQL, Semgrep, Snyk 같은 정적 분석 도구를 CI에 붙여두세요. 사람의 눈이 놓치는 실수를 기계가 잘 잡아주거든요.

마무리

보안 사고는 "잘 만든 사람과 못 만든 사람"의 문제가 아니라 "시스템적인 안전망이 있느냐 없느냐" 의 문제예요. 여러분 회사에는 사고가 났을 때 비난 없이 회고할 수 있는 분위기가 있나요? 그리고 가장 최근에 발견한 "내가 깔아둔 무의식적 가정"은 무엇이었나요?