Trigger.dev 고객 환경변수 노출 사고, 원인 미공개 상태로 상태 페이지는 'resolved' 표시

뚫린 취약점을 실제로 공개한 회사가 있나? 아무도 안 밝혔는데 그러면 자기들도 모른다는 뜻일 수도 있음. Northflank는 CVE-2026-98432 패치했다고 했는데 trigger.dev는 아직 확인을 안 해줬더라.

상태 페이지를 resolved로 돌린 건 좀 배짬 큰데? 익스플로잇 막았으면 뭘 더 하라는 거임.

포스트모템이나 재발 방지책도 없이 resolved부터 찍는 건 별로다. 시크릿 로테이션은 고객 몫으로 남았는데 이걸 해결됨이라고 부르는 게 이해가 안 감.

고객 환경변수 털렸다고 메일 한 통 보내고 resolved? 어떻게 뚫렸는지, 얼마나 털렸는지도 모르면서 그냥 다 좋다는 식임.

보안이 우선순위였던 적이 있냐? 소규모 팀은 누군가 좀 안다고 미루고, 사고가 터지면 보안 팀 뽑아서 몇 년 동안 조직 문화랑 싸운다.

이 속도면 자기 SaaS에 AI 쓴 거 숨기는 날이 올까? 아무도 신경 안 쓰는 것 같기도 하고. LLM이 인간이 짠 스파게티 코드의 허점은 훨씬 잘 찾더라.

직접 만든 소프트웨어가 답이라는 의견도 있는데, 남의 서비스 하나 터는 것보다 한 사람 터는 게 수익성이 낮아서 공격면이 줄긴 한다. 인터넷에 안 노출하고 Tailscale로만 돌리는 것도 방법임.

Tailscale도 최근에 털렸잖아. eMudhra 인증서 쪽 벡터였는데 그쪽 잘못이라기보다는 인증서 구조 문제였고, 요즘은 피할 곳이 없어 보임.

bespoke는 하드닝이 기존 업체보다 훨씬 약함. 취약점 스캔은 점점 싸지고 병렬화되니까 결국 누가 에이전트 떼거리로 인터넷을 훑는다.

Claude Code 원격 접근 도구 사건 이후로 몇 주는 새 소프트웨어나 패키지 매니저 안 쓰는 게 낫다. 그 혼란기에 조용히 백도어가 깔렸을 수 있음.

나는 크롬이랑 VSCode 확장 다 지웠다. 맥에서 tart VM 띄워서 작업할까 고민 중임.

Next.js 바이브 프로젝트가 유료 백그라운드 잡 서비스를 따로 붙여야 하는 게 안티패턴임. Elixir처럼 동시성을 기본으로 처리하는 스택 쓰면 이런 3자 서비스에 안 기대도 됨.

큐랑 유저 테이블 같은 핵심 기능을 아웃소싱한다는 게 이해가 안 간다. 보안이랑 비용 리스크만 커짐.

trigger.dev는 자체 인프라에서도 돌릴 수 있음. 웹앱 라이브러리 선택이랑은 별개 문제임.

trigger.dev 경쟁사인 Inngest도 몇 달 전에 같은 일 겪었다. 나는 익스플로잇 전에 패치했지만 그 뒤로 서비스 신뢰가 흔들렸음.

'Mitigated'로 두고 고객이 메일 확인하고 시크릿 돌릴 때까지 resolved는 아니라고 봐야 함.

통제 못 하는 SaaS에는 당분간 아무것도 배포 안 할 생각임. 개발자용 SaaS는 죽었다고 본다, 자체 호스팅 git만 씀.

인프라 스타트업은 하이퍼스케일러로 회귀할 것 같다. 나는 환경변수 암호화해서 복호화 키를 코드에 박아넣는 방법을 씀.

HSM 하나 못 두는 인프라 업체가 고객 민감 데이터를 들고 있으면 안 되지.

돈 많다고 보안을 잘하는 건 아님. 하이퍼스케일러가 항상 낫다는 건 아니고, 사람 잘못 만나면 큰 회사도 똑같이 털린다.