요약
한 주 사이 대형 보안 사고가 잇따랐고, LLM이 버그 발견부터 공격까지의 시간을 몇 시간으로 줄였습니다.
영국 정부 관련 일을 하는 개발자 드루 실콕이 10월 셋째 주에 몰려 터진 보안 사고를 정리했습니다. 그는 스스로 보안 전문가가 아니라고 밝히면서, 이런 한 주가 앞으로 일상이 되는지 물었습니다.
왜 중요한가
- 버그가 있다는 소식만 퍼져도 몇 시간 안에 자동화된 공격이 시작되는 환경이 됐다는 진단입니다.
- 다만 이번 사고 상당수는 사람이 찾은 평범한 버그였습니다. 그래서 모든 것을 AI 탓으로 돌리는 논의는 지나치다고 봤습니다.
핵심 내용
- PHP2Shell로 불린 PHP 원격 코드 실행(공격자가 서버에서 코드를 돌리는 공격) 취약점은 인터넷의 약 70%에 영향을 준다는 추정이 나왔습니다.
- 이 취약점은 LLM으로 찾았고, 엠바고(약속한 시각까지 공개를 미루는 합의) 전에 정보가 새면서 패치 전부터 공격이 벌어졌습니다.
- 같은 주에 클라우드 업체 레일웨이의 환경 변수 유출과 LiteLLM 악성 버전 배포 사고도 겹쳤습니다.
- 해법으로 코드 전면 비공개, AI 적극 도입, 대응 절차 표준화를 따져 봤지만 모두 비용이나 한계가 크다고 봤습니다.
- 당장 할 일로는 패치 전에 세부 사항을 알리지 않기, 고객 소통 개선, 공격받는다는 전제로 대비하기를 꼽았습니다.
HN 반응
- 미리 통보받는 대형 업체 말고는 정보 없이 대응해야 한다는 불만과, 조율된 공개 관행이 곧 무너질 것이라는 전망이 나왔습니다.
- AI가 만든 코드가 보안에 취약하다는 주장과, 오히려 방어적으로 짜서 평균 품질이 올랐다는 반론이 맞섰습니다.
여기엔 두 가지 측면이 있습니다. 하나는 치명적인 취약점과 익스플로잇이 발견되는 속도가 지금 훨씬 빨라졌다는 점이고, 다른 하나는 발견부터 대규모 악용까지 걸리는 시간이 훨씬 짧아졌다는 점입니다.
LLM이 버그를 전부 찾아서 고치고 나면 발견 속도는 잦아들 거라고들 합니다. 뭐, 그렇게 믿고 싶으시면 그러시든가요. 하지만 그래도 시간 간격이 훨씬 짧아졌다는 문제는 그대로 남고, 그건 당분간 사라지지 않습니다.
업계에서 뭔가를 부수는 게 직업이나 취미인 쪽에 서 계시다면 이 모든 게 아주 흥미진진할 겁니다. 하지만 부서지지 않게 막는 게 일인 쪽에 서 계시다면 정말 최악입니다.
저는 어제 하루를 통째로 날렸습니다. 큰 업체 몇 곳이 뭔가를 발견해서 다른 큰 업체들에게 알렸고, 공개 정보를 "실수로" 충분히 흘려서 다른 모두가 알아차리게 해 놓고는, 나머지 사람들은 대응할 정보도 거의 없는 채로 알아서 하라며 내버려 뒀기 때문입니다.
올해만 벌써 몇 번째 반복되는 패턴입니다. 대형 호스팅 업체 명단에 들어 있으면 무슨 일이 터질지 미리 통보받고 먼저 패치도 받습니다. 거기 못 들면 안됐지만 어쩔 수 없고, 오늘 다른 계획이 없었길 바라야죠.
저 같은 사람들에게 이건 LLM이 제 삶을 실질적으로 더 나쁘게 만드는 또 하나의 방식일 뿐입니다.
협조적 공개(coordinated disclosure)는 조만간 끝날 수밖에 없습니다. 이상적으로는 방어하는 쪽에서 취약점을 발견하면 "선한 편"에게만 알리고 악당에게는 알리지 않는 게 맞죠. 하지만 세상은 그렇게 돌아가지 않으니, 유출할 가능성이 낮은 소수의 중요한 대형 주체에게만 알려서 모두가 알게 되기 전에 최대한 많은 대응을 하자는 식으로 타협했던 겁니다.
이제는 어떤 소프트웨어에 악용 가능한 메모리 문제가 있을지도 모른다는 사실만 알아도, 악의적인 쪽이 LLM을 거기에 들이대서 몇 시간 안에 문제를 찾아낼 수 있습니다. 이건 갈수록 심해질 겁니다.
결국 속도 싸움이 될 겁니다. 취약점을 찾았다면 차라리 곧바로 모두에게 공개하는 게 낫습니다. 인터넷에 노출된 소프트웨어를 운영하는 사람은 누구나 공개되는 취약점을 24시간 지켜보고 자동으로 분류하는 에이전트가 필요해질 겁니다. 업그레이드하든, 보호용 껍데기로 필터링을 강화하든, 사람이 도와줄 수 있을 때까지 서비스 전체를 내리든 말이죠. 그래야 24시간 지켜보다가 자동으로 공격하는 공격 에이전트를 따라갈 수 있습니다.
저는 다음과 같은 식의 첫 익스플로잇이 나오기까지 얼마나 걸릴지 궁금합니다.
악의적인 쪽이 유명 소프트웨어에서 이론상 심각하지만 실제로 악용하기는 쉽지 않은 진짜 취약점을 찾습니다. 예를 들어 RCE로 100% 털릴 수 있지만, 플랫폼 Y에서 커널 버전 Z로 구성 X를 쓰고, 그것도 화요일이어야 하는 식의 익스플로잇입니다.
그 취약점은 막으면서 자기들만 아는 더 위험한 취약점을 슬쩍 여는 패치를 설계합니다. 그 패치를 LLM 리뷰어들에게 몰래 테스트해 보면서, 새로 심은 취약점이 자동 리뷰에서 대체로 걸리지 않을 때까지 방식을 다듬습니다.
그러고는 원래 익스플로잇을 "책임 있게 공개"하면서 친절하게 패치도 공유합니다. 원래 익스플로잇을 급히 고치느라 패치 자체는 건성으로만(클로디하게, 코덱시하게) 리뷰됩니다. 이쯤 되면 이런 일이 하도 많이 반복돼서, 클로드센(ClodSed)이 내놓은 코드 변경을 그냥 적용하고 보는 게 기본이 되어 있습니다.
새 취약점이 결국 발견되더라도 "아, 제 에이전트가 그건 못 잡았네요"라고 그럴듯하게 말할 수 있고, 실제로 그건 사실입니다. 그동안 그들은 자기들만 아는 새 익스플로잇을 씁니다.
제출된 수정안을 격리해 두고, 그걸 읽지 않은 채로 직접 수정안을 만들어서 방어할 수 있습니다. 그런 다음에야 둘을 비교하는 겁니다.
어쨌든 악의가 없어도 이런 일은 벌어집니다. 선의의 제보자가 해당 분야 전문성이 부족한 데다 모델이 실수까지 하는 바람에, 바이브 코딩으로 만든 수정안이 우연히 취약점을 끼워 넣을 수 있거든요. 그런데 확증 편향에 사로잡혀 있으면 그 수정안의 결함을 알아채지 못하고 그대로 반영하게 됩니다. 제보자도 아마 자기 LLM으로 테스트했을 테니 그 테스트도 통과할 거고요.
최근 어떤 암호화폐 프로젝트에서 실제로 이런 일이 있었고, 그게 큰 익스플로잇의 한 원인이 됐습니다.
이건 AI 이전에도 있던 일이고, "변종 분석(variant analysis)"이라고 부릅니다. 다만 LLM 때문에 위력이 엄청나게 세졌고, 100% 크게 우려할 만한 일입니다.
참고로 Claude는 기존 버그의 변종을 찾는 데 실제로 꽤 뛰어납니다.
이것도 통하지 않습니다. 공격자들은 훨씬 더 동기가 강하고 그런 것들을 주시할 여력도 되니까요.
목표가 취약점을 찾는 것이든 돈을 훔치는 것이든 뭐든, 새 익스플로잇을 찾는 데 모든 에너지를 쏟게 됩니다.
나머지 세상 사람들은 해야 할 다른 일이 있고(사용자 의견 듣기, 서비스 운영하기 등등), 공지가 올라올지도 모른다고 세상 모든 소셜 미디어를 지켜보는 데 공격자만큼 시간을 쓸 수는 없습니다. 정의상 불가능하죠.
그래서 데이터 유출로 잃을 게 많은 곳이라면 시스템의 껍데기를 단단히 강화해서 아예 취약하지 않게 만들든가(제대로 하기가 아주 어렵습니다), 취약점 소식을 듣고 대응하는 과정을 자동화하는 게 좋을 겁니다.
이것도 제대로 하기가 아주 어렵습니다.
적용할 패치가 아직 없는데 자동으로 어떤 조치를 취하실 건가요?
공급망 공격에 더 취약해질 가능성도 있습니다.
Chrome, Firefox, Node.js, 리눅스 커널, Nginx 같은 데에도 악용 가능한 메모리 문제가 있는 건 거의 확실하잖아요.
몇 시간 안에 CVE가 쏟아질 거라고 봐야 할까요? 다들 주말을 망쳐서 죄송합니다.
농담처럼 들리겠지만, 제 지인 중에 Kimi에게 "마음껏 날뛰면서 리눅스 커널의 파일시스템을 퍼징해 봐"라고 시킨 사람이 있습니다. 다음 날 아침에 일어나 보니 "버그 26개 발견, 수정안 준비 완료"가 떠 있었다고 해요.
그 뒤로 몇 개는 받아들여졌고, 제출해야 할 목록이 감당이 안 될 만큼 쌓여서 퍼저는 멈췄다고 합니다.
네, 저도 안 믿습니다. 지금 GitHub만 봐도 자기가 뭘 하는지 기초도 모르는 사람들이 바이브 코딩으로 만든 프로젝트로 완전히 쓰레기장이 됐잖아요. LLM을 많이 쓰면 새로운 익스플로잇투성이 코드가 나올 겁니다. 그래도 상황이 정리되고 나면, 이런 익스플로잇이 발견되는 빈도를 LLM 친화적인 기여 정책과 비친화적인 정책에 따라 비교해 보면 확실히 알 수 있을 테니 흥미로울 것 같습니다.
저는 정반대로 봅니다. 이런 바이브 코딩 프로젝트가 최고 실력의 사람이 만든 것보다도 보안 수준이 훨씬 높습니다.
요즘 최상위 에이전트에게 할 일 관리 앱을 만들어 보라고 시켜 보세요. 안티 CSRF, XSS, CSP, 보안 쿠키, HMAC, 로그인 속도 제한, 들어본 적도 없는 온갖 것까지 엔터프라이즈급 보안을 구축하는 걸 보게 될 겁니다.
간단한 OAuth를 구현하라고 시켰더니 들어오는 IP를 사설/공인 서브넷으로 분류하고, 아주 이론적인 DNS 리바인딩 공격에 대한 우회책까지 넣는 걸 봤습니다.
LLM이 뭐든 과하게 설계하길 좋아한다는 건 다들 알잖아요. 정적인 3페이지짜리 블로그를 암호화폐 거래소급 보안으로 바꿔 놓으면서 아주 신나게 놉니다.
코딩할 줄 아는 사람이 만든 소규모 프로젝트라면 맞는 말입니다. 하지만 그렇지 않을 수 있는 범주가 두 가지 더 있습니다.
브이로거나 영업 담당자가 일상 업무를 자동화하려고 만든 간단한 유틸리티입니다. 이런 유틸리티는 급하게 만들어지고, 에이전트에게 개인 키를 그대로 넘겨준 채 배포되는 식입니다. 보안에는 전혀 신경을 쓰지 않은 거죠.
상당히 큰 규모의 인력이 만들어내는 새로운 세대의 엔터프라이즈급 쓰레기 코드입니다. 말도 안 되게 짧은 출시 기한과 방대한 코드량 때문에 자기들이 만든 결과물을 제대로 리뷰하지 않습니다.
물론 그런 코드도 단순한 기법 면에서는 안전할 수 있습니다(에이전트가 큰 도움이 되니까요). 하지만 그런 코드베이스에서는 무엇을 고쳐야 하는지 알아내기도, 다른 걸 망가뜨리지 않고 고치기도, 비슷한 일이 다시 생기지 않게 막기도 극도로 어렵습니다.
그 말이 맞을 수도 있지만, 지금 얘기하는 건 주요 프로젝트들이 쓰는 핵심 라이브러리의 취약점이지, 아무도 신경 안 쓰는 일회성 프로젝트가 아닙니다.
그런가요? 저는 이걸 기회로 삼아 데브옵스 파이프라인이나 소프트웨어 공급망 같은 걸 개선하고 있습니다. 제가 별난 건지, 이상한 걸 즐기는 건지도 모르겠네요. 게다가 이런 보안 사고가 터지면 수습할 사람이 많이 필요하니, 앞으로 우리 인간들이 할 유급 일거리도 늘어나는 셈이고요.
이제 모든 걸 인터넷에 올려놓는 짓을 그만둘 때가 된 건 아닐까요?
이번 연쇄 사태 이전부터도 우리가 보안을 다뤄 온 방식은 취약해 보였습니다. 우리는 뭔가가 안전하다고 가정하고 만든 다음, 필요할 때마다 패치하는 경향이 있습니다.
오늘날 컴퓨팅 관련 장치의 상당 부분은 보안과 관련된 것입니다. 모든 빌어먹을 기기를 인터넷에 연결하지 않는다면 그 장치들이 필요한 정도도 크게 줄어들 겁니다. 오프라인을 우선으로 설계하던 때로 돌아가야 하고, 그다음으로는 외부에서 들어오는 모든 코드에 대한 신뢰 수준을 대폭 낮춰야 합니다. 증명(attestation), 공증(notarization), 서명이 상황을 개선하긴 했지만 여전히 큰 구멍이 남아 있습니다. 웹사이트를 보려고 제3자의 원격 코드를 JavaScript 형태로 실행하는 걸 당연하게 만든 것도 썩 좋은 생각은 아니었을지 모릅니다.
우리는 보안의 3요소에서 "A"가 "가용성(availability)"을 뜻한다는 사실도 잊은 듯합니다. 그런데도 온라인 위협을 막겠다고 온라인으로 배포되는 보안 업데이트와 패치 때문에 한 달에도 몇 번씩 기기와 시스템을 쓰지 못하게 되는 일을 더더욱 당연하게 받아들였습니다. 애초에 존재해서는 안 됐을 취약점 때문에 보안 업데이트가 끊긴 기기들이 쓸모없어지는 것도 당연하게 받아들이게 됐고요.
제가 읽은 모든 자료가 그렇다고, 이게 새로운 일상이라고 말합니다.
Mythos가 처음 발표됐을 때, 제가 이야기를 나눈 보안 전문가는 거의 전부 그냥 기겁을 했습니다. 지금 제 업무의 상당 부분은 AI가 만든 익스플로잇의 영향을 완화하는 일입니다.
AI가 만들어내는 코드의 양도 이 상황을 더 악화시킬 겁니다. AI가 생성한 코드는 보안에 악명 높게 형편없으니까요.
AI가 생성한 코드가 정말 보안에 악명 높게 형편없습니까?
제 경험상 AI 코드는 아주 방어적이고 '뻔한' 실수를 최소화하는 데 능합니다.
지금 비교 대상이 옛날 모델이 생성한 코드입니까, 아니면 Mythos급 모델입니까?
프롬프트와 테스트 스위트부터 시작해서 어떻게 생성하느냐에 크게 달려 있고, 무엇보다 여러분의 태도가 중요합니다. 보안을 더 챙기려면 시간과 돈이 듭니다.
출시 속도가 전부고 그 밖의 건 무시해도 된다고 생각하는 사람들이 여전히 많습니다. "컴파일되네? 출시해!"는 1990년대 말인데, LLM은 이런 접근을 훨씬 쉽게 만들어 줄 뿐입니다. 산탄총을 맞은 체처럼 보안이 구멍투성이인 기계 생성 소프트웨어가 넘쳐나게 될 겁니다.
프롬프트만의 문제는 아니고, 무엇으로 학습했느냐의 문제이기도 합니다.
요즘은 최전선 모델들이 전반적으로 꽤 괜찮지만, 예전에는 생성된 php/javascript는 미심쩍었고, ts는 조금 나았고, Rust는 일관되게 괜찮았습니다.
README의 최대 너비를 80자로 제한하느냐, 풀 마크다운을 쓰느냐만으로도 나오는 C 코드가 크게 달라질 수 있습니다.
제 생각에는 훨씬 더 안전한 코드를 쓰는 건 꽤 쉽습니다. 의존성을 줄이고, 쓰는 의존성도 필요한 일만 하도록 하고 불필요한 코드가 컴파일돼 들어가지 않게 하면 됩니다. 그렇게 구성하는 건 예전엔 너무 번거로웠지만, 이제는 프롬프트 한 번이면 됩니다.
대부분의 소프트웨어는 보안을 전혀 생각하지 않고 만들어집니다. 보안은 비용이 드니까요. LLM 이전에도 그랬고, LLM이 나왔다고 달라질 것 같지 않습니다.
그런데 이런 생각이 듭니다. LLM은 소유한 회사가 조종하는 것이니, 그 회사들이 어떻게든 보안을 더 낫게 만들 수 있다는 뜻 아닐까요? 물론 양날의 검입니다. 한 회사가 세상 코드의 상당 부분을 읽고 생성할 수 있다는 것 자체가 위험이니까요.
오픈소스 메인테이너로서 확실히 말씀드릴 수 있는 건, 평균적인 PR의 품질은 이제 더 좋아졌다는 겁니다. 제가 겪는 문제는 오히려 일부 사람들이 AI를 여러 방식으로 "쏟아붓고" 오용하는 쪽입니다. 그래도 그 사람들의 AI가 그 사람들보다 코드를 더 잘 씁니다.
저는 AI가 잘 관리되는 라이브러리를 쓰지 않고 그냥 직접 만들어 버리는 쪽을 택할 수도 있다는 게 더 나쁘다고 생각합니다.
아니면 오래된 라이브러리를 쓰기도 합니다.
저희는 "개발자가 어느 정도 거드는" AI 개발을 하고 있는데, AI가 어떤 라이브러리를 쓰겠다고 계획했습니다. 그 라이브러리를 찾아봤더니 GitHub 페이지에 "더 이상 유지보수되지 않음, 다른 라이브러리 Z를 사용할 것"이라고 되어 있었습니다. 그걸 알려 주자 AI가 수긍하고 원래 라이브러리와 새 라이브러리를 비교해 줬는데(도움은 됐습니다), 활발한 개발 여부보다 GitHub 스타 수에 훨씬 큰 비중을 두는 것 같았습니다.
SCA나 SBOM 같은 도구는 여러분이 쓰는 것들이 오래되지 않았는지 확인하려면 여전히 필요합니다. LLM이 해결해 주는 문제가 아닙니다.
프로젝트가 스타 수를 자랑하면 저는 곧바로 불신합니다.
보통 다운로드 수나 스타 수는 VC에게 보여 주는 신호인데, 그래서 간접적으로는 저한테도 부정적인 신호가 됩니다.
바로 이런 부분을 안목 있고 해당 분야 지식이 넓은 사람이 리뷰하면서 알아채야 합니다. 아니면 최소한 에이전트에게 그걸 확인하라고 지시하든가요. 물론 그런 사람이 아직도 그 역할로 고용돼 있다면 말이죠.
많은 프로젝트가 쓰는 의존성 자체가 공격 대상이 되는 걸 생각하면, 그게 가끔은 장점이 될 수도 있습니다.
의사야, 네 병이나 고쳐라?
LLM에게 피드백 루프 안에서, 처음 만들 때의 맥락은 전혀 없는 상태로 자기 시스템을 뚫어 보라고 시키면 어떨까요? 반복하다 보면 '안전한' 상태에 도달해야 하지 않나요(쓰고 싶은 토큰 한도 안에서요)?
제 경험상 적대적 리뷰를 항상 따라 주지는 않습니다.
우리 같은 무지렁이들은 특별한 "보안" 전용 모델을 쓰는 축복을 못 받았기 때문이겠죠.
우리가 나쁜 이유로 익스플로잇을 찾고 있을지도 모르니까요, 아마도요.
LLM이 어디에 사각지대가 있느냐에 달렸습니다.