pnpm minimumReleaseAge 7일 설정, 글로벌 config에 넣었더니 조용히 무시된 이야기

npm 패키지 하나가 털리면 무슨 일이 생길까요. 프론트라면 브라우저 안에서 끝날 수도 있지만, 백엔드 서버는 사정이 달라요. DB 접속 정보, 인증 토큰, 웹훅 시크릿까지 환경변수에 전부 들고 있거든요. postinstall 스크립트 한 번이면 충분해요.

그래서 새로 나온 패키지 버전을 일정 기간 설치하지 않는 지연 설정을 걸기로 했어요. 악성 버전은 보통 공개 후 며칠 안에 발각되고 내려가서, 숙성 기간만 둬도 상당수를 피할 수 있어요.

7일 지연, 설정은 한 줄이에요

pnpm에는 minimumReleaseAge라는 옵션이 있어요. 값의 단위가 분이라서 7일이면 10080이에요. 60분 × 24시간 × 7일을 계산한 숫자예요.

# pnpm-workspace.yaml
minimumReleaseAge: 10080

이 한 줄이면 공개된 지 7일이 안 된 버전은 설치 대상에서 빠지고, 그보다 오래된 버전으로 잡혀요.

글로벌 config에 넣었더니 조용히 무시됐어요

처음엔 레포마다 넣기 귀찮아서 글로벌 설정에 걸었어요. 에러도 경고도 없었고 install도 잘 돌았죠. 그런데 테스트해 보니 어제 공개된 버전이 그대로 설치되더라고요. 지연이 전혀 안 걸린 거예요.

제가 쓰는 pnpm 기준으로 이 옵션은 프로젝트의 pnpm-workspace.yaml에서만 읽혀요. 글로벌 경로에 넣으면 틀렸다고 알려주는 대신 그냥 넘어가요. 보안 설정이 적용됐다고 믿는 상태로 남는 게 제일 무서운 부분이에요. 서버 방화벽을 켰다고 생각했는데 실제로는 꺼져 있는 상황과 같으니까요.

옮기고 나서, 설치 결과로 확인했어요

운영 중인 레포 세 곳의 pnpm-workspace.yaml에 한 줄씩 넣고 다시 돌려 봤어요. 이번엔 며칠 전에 나온 최신 버전 대신 더 오래된 버전이 잡혔어요. 설정이 진짜 동작하는지는 문서가 아니라 이렇게 설치 결과로 눈으로 확인하는 편이 확실해요. 레포당 10분이 안 걸렸어요.

급하게 받아야 하는 보안 패치가 있다면 minimumReleaseAgeExclude에 해당 패키지를 예외로 등록하면 돼요. 지연은 기본값으로 깔고, 예외를 좁게 여는 구조가 관리하기 편했어요.

보안 설정은 검증까지가 한 세트예요

라이프케어로그의 플랜엘(plan-l)처럼 법령 데이터 API와 인증 키를 다루는 백엔드는 의존성 하나가 곧 보안 경계예요. 직접 겪어 보니 배운 건 단순해요. 보안 설정은 넣는 것보다 정말 적용됐는지 확인하는 데까지가 한 세트라는 것. 조용히 무시되는 설정이 제일 위험해요.