보안 코드 리뷰 해설: 리뷰어가 diff에서 무엇을 찾는지, 그리고 그 이유

보안 코드 리뷰는 소스 코드를 의도적으로 읽어, 작성자가 의도하지 않은 동작을 하도록 만들 수 있는 방법을 찾는 것을 특정 목적으로 합니다. 그 정의는 대부분의 팀이 실제로 수행하는 것, 즉 보안 체크리스트를 곁에 두고 하는 기능 리뷰와 비교해 보기 전까지는 당연하게 들립니다. OWASP Secure Code Review Cheat Sheet는 그 경계를 정확히 긋습니다. 보안 리뷰는 정확성이 아니라 입력 검증, 인증, 권한 부여, 암호 구현 및 공격 벡터를 대상으로 한다는 점에서 기능 리뷰와 다릅니다. 완벽하게 작동하는 diff도 공격자에게 시스템으로 들어가는 경로를 제공할 수 있으며, 두 리뷰 중 오직 하나만이 그것을 찾고 있습니다.

이 주제가 2020년이 아니라 지금 글 한 편으로 다룰 가치가 있는 이유는, 언어 모델이 diff를 유능하게, 저렴하게, 그리고 지속적으로 읽을 수 있게 되었기 때문이다. 이는 검토 대상이 되는 차원 중 단 하나도 바꾸지 않으면서 검토의 경제성을 바꾼다. 체크리스트는 모델보다 오래되었고, 움직이지 않았다. 움직인 것은 그것을 얼마나 자주 돌릴 여유가 있는가이다.

리뷰어가 실제로 읽으며 찾는 것

OWASP 치트 시트는 작업을 여섯 영역으로 구성하는데, 이 목록의 유용한 점은 각 영역이 범주가 아니라 질문이라는 것입니다. 범주는 형식적인 체크에 그치게 하지만, 질문은 발견으로 이어집니다.

입력과 인젝션. 문제는 코드에 새니타이저가 있느냐가 아니라, 셸, SQL, 템플릿 엔진, 표현식 평가기 같은 인터프리터에 무언가가 도달하느냐, 그리고 그 요구 사항이 어느 계층에서 강제되어야 하느냐입니다. 매개변수화된 쿼리를 추가하는 diff는 좋습니다. 그러나 다른 호출자들이 원시 문자열을 전달하는 함수에 매개변수화된 쿼리를 추가하는 diff는 문제를 옮겨 놓은 diff일 뿐입니다.

인증 및 세션. 호출자는 누구이며, 코드는 그 사실을 어떻게 입증했는가? 반복되는 버그는 망가진 비밀번호 검사가 아니라 권한 변경 후에도 살아남는 세션이다. 권한 상승이 일어나도 토큰은 예전 클레임을 그대로 유지하고, 한 시간이 지나도 그 권한은 여전히 남아 있다.

인가. 객체 수준 검사는 모든 라우트에서 매번 수행해야 합니다. diff에서 특별히 찾아야 할 것은 형제 라우트가 가진 가드를 상속하지 않는 새 라우트입니다. 미들웨어는 라우터별로 등록되므로, 다른 라우터 아래에 추가된 라우트에는 그 가드가 적용되지 않기 때문입니다.

암호화. 프리미티브, 모드, 키 길이, 그리고 키가 저장되는 위치. 두 가지 질문이 대부분의 실제 발견 사항을 잡아냅니다. 이 코드베이스를 읽을 수 있는 사람이 키까지 읽을 수 있는가, 그리고 이 비교가 타이밍을 누설해서는 안 되는 비교인가.

비즈니스 로직. 시퀀스의 순서를 바꾸거나 재생할 수 있는지, 또는 클라이언트가 선택한 값에 의해 구동될 수 있는지 여부. 클라이언트로부터 도착한 가격, 수량, 역할 또는 상태 전이가 서버 측에서 다시 도출되지 않는다면, 그것이 어떻게 검증되든 관계없이 취약점으로 간주합니다.

구성과 시크릿. diff가 배포하는 것 중 저장소에 절대 있어서는 안 될 것들, 그리고 코드가 실제로 실행되는 환경에서 기본값이 안전한지 여부. 디버그 플래그의 기본값이 true라는 것은 그 플래그에 관한 발견이 아니라 프로덕션에 관한 발견이다.

베이스라인 리뷰 대 디프 리뷰

OWASP는 두 가지 모드를 구분하는데, 이 둘을 혼동하는 것은 헛된 노력과 잘못된 확신 모두의 흔한 원인입니다. 베이스라인 리뷰는 코드베이스를 포괄적으로 검토하며, 새 애플리케이션이나 주요 릴리스, 레거시 시스템 온보딩, 규정 준수 요구 사항 충족, 또는 이미 문제가 발생한 후의 사후 분석에 적합한 도구입니다. 차이 기반 리뷰는 변경된 내용만 살펴보며, 풀 리퀘스트, 커밋, 기능 완료 및 지속적 검증에 적합한 도구입니다.

이 구분이 중요한 이유는 두 방식이 만들어내는 작업이 서로 다르기 때문입니다. 베이스라인 리뷰는 백로그로 끝나고, diff 리뷰는 병합 결정으로 끝납니다. 첫 번째를 지속적으로 돌리는 것은 비용상 감당이 되지 않으며, 첫 번째를 한 번도 수행한 적 없는 코드베이스에서 두 번째를 돌리는 것이 바로 팀이 잘못된 커버리지 감각을 쌓아가는 방식입니다. 모든 변경은 리뷰를 통과하지만, 기존에 있던 SQL 문자열 연결은 그대로 방치됩니다.

기법, 그리고 각 기법이 잡아내는 것

OWASP는 네 가지 검토 기법을 제시하는데, 이들은 얼마나 철저한지가 아니라 검토자가 어떤 증거를 따라가는지로 구별된다. 코드 패턴 분석은 익숙한 형태를 따라간다: 위험한 함수 호출, 신뢰할 수 없는 입력의 역직렬화, 누락된 길이 검사. 이는 빠르며 결정론적 도구가 잘하는 바로 그 일이다. 데이터 흐름 분석은 값이 들어오는 곳에서 사용되는 곳까지 따라가는데, 이는 세 함수 전에 적용된 새니타이저가 여기서도 여전히 유효한지 답할 수 있는 유일한 방법이다. 위협 기반 검토는 공격자의 역량에서 시작해 앞으로 나아가며, 이것이 개별적으로는 올바른 두 컴포넌트 사이의 간극을 잡아내는 방법이다. 비즈니스 로직 검토는 코드 줄이 아니라 워크플로를 읽으며, 어떤 일련의 정당한 작업이 부당한 상태를 만들어내는지 묻는다.

그 네 가지 중 첫 번째만 스캐너가 잘 처리할 수 있고, 첫 번째와 두 번째만 안내 없는 모델 패스가 잘 처리할 수 있다. 그것은 모델에 반대하는 논거가 아니라, 리뷰어에게 어떤 기법을 원하는지 알려주자는 논거다. 왜냐하면 "보안 문제"를 요청하는 프롬프트는 패턴 분석을 안정적으로 산출하고 거기서 멈출 것이기 때문이다.

AI가 바꾼 것과 바꾸지 않은 것

AI가 작성한 코드에 관한 연구는 리뷰 병목을 새로 만든 것이 아니라 더 날카롭게 만들었다. 2022년 IEEE S&P에 발표된 GitHub Copilot 제안에 대한 NYU 연구는 생성된 스니펫의 약 40%가 18개 CWE 범주에 걸쳐 악용 가능한 패턴을 포함하고 있음을 발견했다. 2023년 ACM CCS에 발표된 개발자 행동에 관한 스탠퍼드 연구는 더 중대한 효과를 발견했다. 어시스턴트를 사용하는 개발자들은 자신의 코드가 안전하다고 더 확신했지만, 측정 가능하게 더 안전하지 않은 코드를 생산했다. 더 많은 산출물과 더 큰 자신감은 리뷰 문제다.

리뷰어로서의 언어 모델은 그 방정식에서 한 가지 변수인 처리량을 바꾼다. 좌석당이 아니라 토큰당 비용으로 모든 풀 리퀘스트를 읽을 수 있고, 위의 여섯 가지 질문을 명시적으로 던질 수 있다. 하지만 질문 자체를 바꾸지 않으며, 리뷰를 신뢰할 수 있게 만드는 두 가지 속성인 결정성과 코드 실행 능력도 얻지 못한다. 동일한 diff를 두 번 리뷰하면 서로 다른 발견 사항이 나올 수 있고, 심각도는 실행할 때마다 달라지며, 리뷰어는 표시된 경로가 도달 가능하다는 것을 증명할 수 없다.

OrcaCode Review는 그 아이디어를 제품화한 형태이며, 설계 선택이 실패 모드를 드러내므로 자세히 볼 가치가 있다. 실패 사례를 구체적이고 재현 가능한 코멘트로 분리하는 리뷰 — 이 키는 여전히 시간에 따라 달라지므로, 재시도된 청구는 새 키를 발급해 이중 청구할 수 있습니다, 여기 한 줄짜리 변경이 있습니다 — 는 리뷰어가 하는 일을 하는 것이다. 재현 없이 "잠재적 보안 문제"를 보고하는 리뷰는 패턴 매처보다 정밀도가 떨어지는 패턴 분석을 하는 것이다. 그리고 오픈 라이선스로 공개된 규칙 및 게이트 엔진은 점검해 볼 가치가 있는 암묵적 주장을 하고 있다: 리뷰어의 판단도 검토 가능해야 한다는 것이다.

효과적으로 작동하는 2층 구성

결정론적 스캐너와 확률적 리뷰어가 주어졌을 때, 실무에서 살아남는 배치는 각자 실제로 잘하는 일을 맡기는 것이다. 스캐너는 모든 푸시에서 실행된다: 몇 초가 걸리고, 모델도, 편차도 없으며, 비밀 정보, 위험한 API 호출, 안전하지 않은 역직렬화, 환각된 임포트를 잡아낸다. 리뷰어는 모든 풀 리퀘스트에서 실행된다: 몇 분이 걸리고, 모델 기반이며, 줄 사이에 숨은 로직 — 인가 검사가 fetch 전에 실행되는지, 멱등성 키가 안정적인 값에 바인딩되는지, 새 라우트가 가드를 상속했는지 — 를 잡아낸다.

그다음으로 사람들이 건너뛰는 층: 게이트. 병합을 막지 않는 발견 사항은 알림일 뿐이고, 알림은 금요일에나 읽힌다. 게이트는 좁아야 하고 절대적이어야 한다 — 치명적인 발견 사항은 막고, 나머지는 코멘트로만 남긴다 — 그리고 예외 허용은 문서로 남겨야 한다. 게이트의 가치는 첫 번째 발견 사항을 막는 데 있는 것이 아니라 모든 우회를 가시화하는 데 있기 때문이다.

코드베이스가 아니라 변경 사항을 검토 중입니다

diff 검토를 위한 실용적인 훈련법은 짧은 절차로 이루어져 있으며, 그 가치는 한나절이면 가르칠 수 있다는 데 있다. diff를 읽을 때는 그것이 추가하는지를, 무엇이 바뀌는지가 아니라 공격 표면 관점에서 읽어라. 각각의 새로운 진입점마다 입력을 diff가 끝나는 지점에서 한 단계 더 따라가라 — 취약점은 보통 그 진입점이 호출하는 함수에 있으며, 작성자는 그 함수를 읽지 않았다. 각각의 새로운 경로마다 가드 등록을 확인하라. 각각의 새로운 의존성마다 그것이 존재하는지, 그리고 다른 누군가가 그 이름으로 이미 배포했는지 확인하라. 각각의 새로운 구성 값마다 실제로 배포될 환경에서 그 값이 무엇으로 기본 설정되는지 물어라.

그것들 중 어느 것도 언어를 잘 알 필요는 없으며, 그래서 보안 전문가가 아닌 리뷰어에게까지 확장할 수 있습니다. 다만 리뷰어가 파일이 아니라 diff를 보아야 한다는 점은 요구합니다. 이 방법 전체가 무엇이 새로운지 아는 데 달려 있기 때문입니다.

그리고 솔직한 한계: diff 리뷰는 diff 이전에 이미 존재하던 결함을 찾을 수 없습니다. 애플리케이션이 한 번도 기준선 리뷰를 받은 적이 없다면, 지금 할 수 있는 가장 가치 높은 보안 작업은 더 나은 리뷰어가 아니라, 돈·신원·파일 접근과 관련된 영역에서 위의 여섯 가지 질문을 가지고 코드베이스를 한 번 의도적으로 훑는 것입니다. 그 이후에는 모든 후속 diff 리뷰가 한 번은 살펴본 것을 보호하는 것이 됩니다. 그 이전에는 모든 diff 리뷰가 알려지지 않은 무언가를 보호하는 것입니다.