요약
OpenCode가 보안 침해로 OpenCode Console 사용자 1.4%가 피해를 입었다고 밝혔습니다.
AI 코딩 도구를 만드는 OpenCode가 X(옛 트위터) 공식 계정에 올린 공지입니다. 전날 밤 대규모 증류 공격(다른 회사 AI 모델의 답변을 대량으로 뽑아 자기 모델 학습에 쓰는 행위)과 관련된 침해가 있었다고 알렸습니다.
왜 중요한가
- 피해 서비스는 여러 AI 모델을 대신 연결해 주는 곳이라, 유출된 키로 남의 돈이 쓰일 수 있습니다.
- 앤트로픽, 오픈AI, 구글이 함께 수습에 나선 것은 여러 모델 업체가 얽힌 사고라는 뜻입니다.
- 일괄 폐기 없이 이메일 안내만 나가서, 피해 사용자가 각자 키를 바꾸는 등 직접 대응해야 합니다.
핵심 내용
- 피해자는 OpenCode Console 사용자의 1.4%라고 밝혔습니다.
- 침해는 공지 전날 밤 일어났고, 대규모 증류 공격과 관련이 있다고 했습니다.
- 피해 사용자 모두에게 당일 아침 이메일로 알렸다고 했습니다.
- 사고가 아직 진행 중이라 자세한 내용은 밝힐 수 없다고 했습니다.
- 앤트로픽, 오픈AI, 구글과 함께 피해를 수습하고 있다고 덧붙였습니다.
HN 반응
- 여러 이용자는 피해 서비스가 코딩 에이전트와 별개인 OpenRouter 비슷한 중개 서비스라며, 이를 흐린 공지와 제목을 비판했습니다.
- 유출된 키를 누구나 폐기할 수 있는 창구를 두자는 제안에는, 그러면 유출이 서비스 거부 공격으로 번진다는 반론이 맞섰습니다.
오픈코드 팀이 제대로 설명하지 않은 부분을 짚고 넘어가겠습니다.
유출된 건 'OpenCode Console'이라는 서비스입니다. OpenCode 코딩 에이전트와는 별개의 서비스예요. 코딩 에이전트만 쓰신다면 영향이 없습니다. 'OpenCode Console'은 OpenRouter와 비슷한 서비스인데, 사용자는 훨씬 적습니다.
'OpenCode Console'이라는 이름은 정말 헷갈립니다. CLI 코딩 에이전트를 가리키는 말로 오해하기 쉬운데, 그렇지 않습니다. 'OpenCode Console'은 CLI/TUI 코딩 에이전트나 데스크톱 앱과는 아무 관련이 없습니다.
게다가 'OpenCode Console'은 온라인에 문서가 거의 없고, 공식 유출 공지도 이 구분을 전혀 분명히 하지 않습니다. OpenCode 팀이 소통을 끔찍하게 못 했고, 그건 팀의 책임입니다.
'OpenCode Console'을 쓰는 사람들에게는 오늘이 나쁜 날입니다. 하지만 이 글을 읽는 OpenCode 사용자 대다수는 아마 'OpenCode Console'을 쓰지 않을 겁니다.
여러 제공사 모델을 종량제로 쓰는 OpenCode 상품은 Zen인 줄 알았는데요. 그리고 OpenCode Go는 여기서 어디에 해당하나요?
아니요, Console은 Zen이나 Go와 다릅니다. 그래도 헷갈리시는 게 당연합니다. opencode 팀이 지금 무슨 일이 벌어지고 있는지 설명을 정말 형편없이 했거든요. 그 때문에 브랜드에 실질적인 타격을 입었는데, 자초한 일입니다.
NNN... 신뢰는 이미 깨졌어요
이 글을 올린 사람입니다. OpenCode 팬이나 팀이 이 글이 HN 첫 페이지에 올라온 걸 달가워하지 않는 것 같네요. 이미 여러 명이 신고(flag)했고요. 저는 추천을 부탁하는 사람이 아닌데, 추천해 주시면 정말 고맙겠습니다. 감사합니다!
어, 얘네 YC 회사였네요: https://www.ycombinator.com/companies/opencode
제목은 "OpenCode"가 아니라 "OpenCode Console"이어야 합니다.
맞아요, 그건 큰 차이죠.
"여러 명이 신고했다"는 건 어떻게 알아내셨나요?
흥미롭네요. 원래 순위는 1위였는데 10위 안팎을 넘어선 적이 없네요. 이런 건 처음 봅니다: https://news.social-protocols.org/stats?id=50133401
자세한 지표를 알려 주셔서 감사합니다. 제 말이 맞다는 게 증명됐네요...
로그인했을 때는 글이 보였습니다. 그런데 시크릿 창에서 /newest 페이지를 열어 보니 이 글이 없었어요.
로그인하지 않아도 메인 페이지 14위입니다. 로그인했을 때와 똑같아요.
지금은 그렇네요.
비추천을 엄청 받은 게 분명합니다. 올라온 시각, 받은 점수, 현재 순위를 비교해 보세요.
HN에서는 글에 비추천을 못 합니다(댓글에는 할 수 있지만요).
추천을 그만큼 받은 글이 그 짧은 시간에 보통 차지하는 순위보다 밀려났다는 뜻이었을 거예요. 몇 시간 만에 추천이 수백 개면 보통 5위 안에 드는 글이거든요.
제가 알기로는 신고(flagging)가 알고리즘에서는 슈퍼 비추천처럼 작동합니다.
네, 신고는 슈퍼 비추천이 맞습니다.
증류 공격(distillation attack)이 뭔지 누가 좀 설명해 주실 수 있나요?
API 키를 쓰는 모든 시스템에는 "invalidate_api_key" 엔드포인트가 있어야 한다고 생각합니다. 그러면 키가 유출됐을 때 화이트햇 해커나 키를 보관하던 쪽이 키를 전부 무효화할 수 있으니까요. 지금은 시간과의 싸움인 데다, 다들 이메일을 받고 각자 알아서 조치해야 합니다.
사실 간접적이고 편법이긴 해도 그런 방법이 있습니다! GitHub 시크릿 스캐닝 파트너사의 키를 공개 저장소나 gist에 올리면 해당 파트너사로 전달되고, (대개) 즉시 폐기해 줍니다. 그러니 누군가를 도우려면 키를 넣은 공개 gist를 만들었다가 15초쯤 뒤에 지우면 충분합니다.
https://docs.github.com/en/code-security/reference/secret-security/supported-secret-scanning-patterns 에 활성 파트너사 표가 있습니다.
이번 경우에 책임 있는 행동은 OpenCode 쪽이 모든 키를 무효화하는 것뿐이었을 겁니다. 하지만 Anthropic/OpenAI 같은 곳에 그런 엔드포인트가 없다면 그렇게 간단하진 않겠죠.
직접 쓸 수 있는 엔드포인트는 없지만, OpenCode가 유출된 키를 추론 제공사에 넘기고 폐기를 요청할 수는 있습니다. 제공사들은 그걸 처리할 수 있거든요. 아직 조치가 진행 중이라고 하니 그렇게 될 수도 있습니다.
그러면 자격 증명 유출이 서비스 거부로 바뀔 뿐이에요. 그것도 어디서든 일으킬 수 있는 서비스 거부로요.
이 경우라면 남들 토큰값으로 큰돈을 쓰느니 차라리 내 키가 막히는 쪽이 낫지 않을까요.
끝까지 생각해 보세요. 키를 훔친 사람이, 가상의 그 시스템에서 키를 쓸지 폐기할지 결정할 수 있습니다.
악의가 있다면 당신에게 가장 큰 피해를 주거나 자기에게 가장 이득이 되는 쪽을 고르겠죠.
키가 자기한테 쓸모없는데 폐기하면 당신이 피해를 본다면, 폐기할 겁니다.
키가 쓸모없지 않다면... 그냥 쓰고 폐기하지 않겠죠?
보호되지 않은 키를 발견한 화이트햇 제3자를 위한 겁니다. 일부러 키를 훔치는 사람이 폐기하지 않을 거라는 건 당연하고요.
그럼 키를 발견한 화이트햇 해커는 정확히 뭘 해야 하죠?
소유자에게 연락도 안 하고 일방적으로 폐기해야 한다고 결정하라는 건가요?
그게 악의적인 행동이 아니라고요?
다른 공개 엔드포인트 서비스가 노출하는 위험 이상은 아닙니다. 이 폐기 엔드포인트도 인증으로 보호할 수 있어요. 폐기하려는 API 키로 인증하면 됩니다.