보안 가이드

Next.js를 안전하게 운영하기: 공개된 CVE에 뒤처지지 않기

Next.js에서 가장 무서운 것은 공개된 CVE를 패치 안 한 채 두는 것이다 — 몇 달 묵은 CVSS 10.0 RCE가 실제 침해를 일으켰다. 네 기둥: 가동 중인 버전으로 판단, 의존성 기계 모니터링, 빠른 업데이트, 최소 권한 — 본 사이트의 운영 관점으로.

게시 2026-06-07 업데이트 2026-06-07 3분 읽기

대상: Next.js(또는 유사 JS 프레임워크)로 앱을 출시하는 사람, 특히 "AI의 도움으로 만들어 감으로 운영" 중인 경우. 실제 사고에서 추려냈다(→ 방치된 CVSS 10.0).

본 사이트의 견해: 승부는 '속도'에서 갈리지 않는다

인디 개발자는 보통 보안에서 지식 부족이 아니라 운영의 연속성 부족 때문에 진다. CVE 뉴스를 남보다 빨리 읽는 것은 가치가 없다(속도는 벤더와 뉴스에 맡겨라). 통하는 것은 당신과 관련된 CVE를 놓치지 않는 시스템이다. 그래서 이 글은 "더 많이 알기"가 아니라 "시스템화"에 기댄다.

1. 가동 중인 버전으로 판단하라

"내가 위험한 버전에 있는가"를 매니페스트 하한이 아니라 실제로 가동 중인 것으로 측정하라 — 매니페스트 숫자와 가동 버전은 자주 어긋나기 때문이다.

✗ package.json 하한으로 셈

"next": "^16.0.0" → "16.0.0이 취약하니 우리도" — "8개 취약"으로 과대 계상.

✓ 가동 중인 버전으로 셈

npm ls next가 해석된 버전을 보임 → 자동으로 오른 것은 안전, 고정된 것만 뒤처짐. 실제로는 2개.

package.json 하한은 거짓말한다. 가동 중인 버전으로 판단하면 위험이 달라진다('취약' 8개가 2개로).

# 실제로 해석된 버전을 보라
npm ls next react react-dom
# 가동 중인 컨테이너 안에서
docker exec <container> npm ls next

캐럿 범위(^16.0.0)는 재빌드 시 자동으로 오르고, 고정된 의존성은 뒤처진다. 여기 나오는 숫자가 진실이다.

2. 의존성을 기계로 모니터링하라

CVE를 손으로 추적하는 것은 불가능하고, 그 놓침이 곧 사고가 된다. 기계가 감시하게 하라.

무료 의존성 모니터링

osv-scanner scan -L pnpm-lock.yaml

GitHub에서는 Dependabot을 켜라(Settings → Security). 당신의 의존성에 해당하는 CVE에 대해서만 PR을 받는다.

중요한 것은 우선순위 매기기다. 본 사이트의 입장: "악용되고 있는가(KEV)" 곱하기 "CVSS가 얼마나 높은가"로 순위를 매긴다. 쓰지 않는 높은 CVSS는 영향이 작고; 활발히 악용되는 중간 점수가 최우선이다 — 그 우선순위 매기기가 실제 작업이다.

3. 업데이트 규율: 증상이 아니라 근본을 고쳐라

취약점이 나타나면, 프레임워크를 패치 버전으로 업그레이드해 구멍 자체를 닫아라.

증상 가리기(불충분)

리버스 프록시에서 "수상해 보이는" 요청만 차단
과금/증상을 멈추고 "처리됨"으로 친다
RCE 자체는 그대로 둔다

근본 수정(올바름)

프레임워크를 업그레이드해 패치 버전으로
업그레이드 후 로그에서 시그니처가 사라졌는지 확인
응급 처치와 근본 수정을 별개 작업으로 보고, 둘 다 한다

흔한 실패

"과금/증상을 멈췄다" ≠ "처리했다." 응급 처치와 취약점을 닫는 것은 다른 작업이다. 둘 다 하라.

4. 피해 반경을 줄이는 최소 권한

뚫렸을 때 피해를 가둔다.

권한 없는 사용자로 실행

컨테이너 USER를 root로 돌리지 마라. 침해는 "그 권한"까지만 닿는다.

DB/Redis를 내부 네트워크에만 바인딩

절대 공개하지 마라. 직접 닿을 수 있는 표면을 줄여라.

서비스별로 분리

네트워크와 데이터를 서비스별로 나눠, 한 침해가 전부로 번지지 못하게 하라.

이것들이 침해가 "컨테이너 안 환경 탈취"에서 멈추느냐 "호스트 점령"에 닿느냐를 가른다.

본 사이트는 직접 이렇게 한다

본 사이트는 여기 쓴 그대로, 자신의 의존성을 CVE 모니터링한다 — 그래서 이 모든 것을 시작한 사고(방치된 공개 CVSS 10.0)를 다시는 사람이 놓치지 않게 한다. "우선순위(KEV + CVSS)로 순위를 매겨라"라고 말하는 이유는, 실제로 그렇게 운영하기 때문이다.

다음으로 읽기

FAQ

QNext.js 보안에서 가장 중요한 것은 무엇인가요?

버그를 안 만드는 것 이전에, 프레임워크나 그 의존성의 공개된 CVE를 패치 안 한 채 두지 않는 것입니다. 가장 심각한 침해 대부분은 새로운 공격이 아니라 방치된 알려진 구멍에서 옵니다.

Qpackage.json으로 취약 여부를 알 수 있나요?

아니요. package.json의 `^`(하한)은 현실을 반영하지 않습니다 — 캐럿 범위는 재빌드 시 자동으로 올라가고, 고정된 의존성은 뒤처집니다. 항상 실제로 가동 중인 버전으로 판단하세요.

Q혼자라면 가장 먼저 할 한 가지는 무엇인가요?

Dependabot(GitHub)이나 osv-scanner를 켜서 기계가 의존성의 CVE를 감시하게 하는 것입니다. 수동 순찰은 늘 놓칩니다. 계속되는 시스템이 더 많은 지식을 이깁니다.