KOSMO에서 보안 쪽도 같이 맡으면서 Dependabot이나 Codex 클라우드에 뜨는 취약점 경고를 보게 됐다.
처음에는 심각도가 높고 우리 pnpm-lock.yaml에도 해당 버전이 있으면 바로 수정해야 하는 거 아닌가 생각했다. 경고에 영향받는 버전까지 적혀 있으니까 일단 패키지를 올리면 해결될 것 같았다.
근데 실제로 하나를 살펴보면서, 패키지가 설치되어 있다는 것과 누군가 우리 서비스를 공격할 수 있다는 건 다른 이야기라는 걸 알게 됐다.
이미지 처리 패키지에 경고가 떴다
한 번은 이미지 처리 패키지에서 서비스가 멈출 수 있다는 경고가 떴다. pnpm-lock.yaml을 확인하니 영향받는 버전이 정말 있었다. 여기까지만 보면 경고 자체는 맞았다.
그래서 처음에는 이미지 업로드 기능부터 떠올렸다. 사용자가 이미지를 올릴 수 있는데, 혹시 그 파일이 문제의 코드로 들어가는 건 아닐까?
의존성 경로와 실제 호출부를 따라가 보니, 해당 패키지는 제품 코드에서 직접 쓰는 것이 아니라 다른 도구가 가져온 것이었다. 확인한 사용처도 앱에 포함할 로컬 에셋을 준비하는 과정에 있었다. 사용자가 올린 이미지가 그곳으로 전달되는지까지 봤지만, 당시 확인한 제품 흐름에서는 이어지는 경로를 찾지 못했다.
그래서 결론도 조금 조심스럽게 적었다. 패키지 취약점은 유효하지만, 현재 KOSMO 서비스에서 외부 입력으로 그 코드를 호출하는 경로는 확인되지 않았다. 처음에는 경고가 맞는지 아닌지만 판단하면 될 줄 알았는데, 실제로는 우리 코드에서 어디에 놓여 있는지를 봐야 했다.
물론 이걸로 모든 위험이 사라졌다고 말할 수는 없다. 이번에는 정적으로 코드를 살펴본 것이고, 공격을 재현하거나 모든 배포 환경을 확인한 건 아니었다. 개발·빌드 과정에 들어오는 파일은 또 다른 범위다. 나중에 이미지 처리 방식이나 빌드 입력이 바뀐다면 같은 경고도 다시 검토해야 한다.
이제 경고가 뜨면 뭘 볼까
이번 일을 겪고 나서는 Dependabot 경고든 Codex 클라우드 경고든 심각도 숫자만 보고 바로 결론을 내리지 않으려고 한다.
먼저 원문에서 어떤 버전과 기능이 영향을 받는지 본다. 그다음 우리 코드에서 패키지를 직접 쓰는지, 다른 도구를 통해 들어온 건지 확인한다. 여기서 끝내지 않고 실제 호출부와 입력 경로를 따라간다. 외부 사용자가 제어할 수 있는 데이터가 그 코드까지 도달하는지, 도달한다면 서비스 서버에서 실행되는지 아니면 개발·빌드 과정에서 실행되는지도 따로 봐야 한다.
처음에는 pnpm-lock.yaml에 이름이 있으면 충분한 근거라고 생각했는데, 그것만으로는 실제 공격 경로를 설명할 수 없었다. 반대로 지금 경로를 찾지 못했다고 앞으로도 안전하다고 할 수는 없어서, 어느 버전과 환경을 확인했는지, 무엇은 확인하지 못했는지도 같이 남겨야 했다.
경로가 확인되면 영향에 맞게 수정하고 다시 검증한다. 경로가 확인되지 않더라도 업데이트가 어렵지 않다면 올리는 쪽을 검토할 수 있다. 경고를 종료할 때는 왜 현재 사용 경로에 해당하지 않는지와 어떤 변화가 생기면 다시 봐야 하는지를 적어 둔다.
정리
- 취약한 버전이 설치되어 있는지와 우리 서비스에서 공격 경로가 있는지는 따로 확인하기.
- 패키지 이름에서 멈추지 않고 실제 호출부와 외부 입력이 닿는 곳까지 보기.
- 확인하지 못한 범위와 다시 검토해야 할 조건도 같이 남기기.
아직 보안 경고를 볼 때마다 바로 판단할 수 있는 건 아니다. 그래도 이번에는 경고를 단순히 닫거나 업데이트하기 전에, 우리 제품에서 실제로 어떤 일이 일어날 수 있는지 먼저 확인해야겠다고 생각했다.