▲

AI가 두 취약점 문화를 깨뜨리고 있다

 (jefftk.com)
8P by GN⁺ 2일전 | ★ favorite | 댓글 2개
  • Copy Fail 공개 뒤 Hyunwoo Kim은 기존 수정이 충분하지 않다고 보고 같은 날 패치를 공유했지만, Linux식 조용한 공개 수정 절차가 외부 발견으로 드러나며 엠바고 종료로 이어짐
  • Linux, 특히 네트워킹 영역에서는 보안 영향은 비공개 목록에 공유하고 버그 수정은 공개적으로 빠르게 진행해, 실제 취약점 존재를 며칠간 엠바고로 유지하려는 관행이 있음
  • 다른 사람이 공개 변경을 발견하고 보안 영향을 알아낸 뒤 공개하면서, 이후 전체 세부사항이 공개됨
  • AI가 커밋별 보안 의미를 평가하는 비용을 낮추면서, 조용히 공개된 수정에서 취약점을 찾아내는 일이 더 쉬워지고 신호 대 잡음비도 높아짐
  • 전통적인 90일 조율 공개도 약해지고 있으며, 이번 경우 Kim의 ESP 취약점 보고 후 9시간 만에 Kuan-Ting Chen도 독립적으로 보고해 매우 짧은 엠바고가 더 나은 방향일 수 있음

Copy Fail과 Linux 보안 수정 관행의 충돌

  • Copy Fail 취약점이 공개된 뒤 Hyunwoo Kim은 기존 수정이 충분하지 않다고 보고 같은 날 패치를 공유함
  • Kim은 Linux, 특히 네트워킹 영역에서 흔한 절차를 따랐음
    • 보안 영향은 Linux 보안 엔지니어의 비공개 목록에 공유함
    • 버그 수정은 공개적으로 조용하고 빠르게 진행함
    • 실제 수정만 공개된 상태에서 심각한 취약점의 존재는 며칠간 엠바고로 유지하려는 목적이었음
  • 다른 사람이 해당 변경을 발견하고 보안 영향을 알아낸 뒤, 이를 공개함
  • 취약점이 이미 공개된 것으로 간주되면서 엠바고가 종료됐고, 이후 전체 세부사항이 공개됨

AI가 두 취약점 문화에 만드는 압력

  • 조율된 공개 문화

    • 보안 버그를 발견하면 유지관리자에게 비공개로 알리고, 보통 90일 같은 기간을 주어 수정하게 하는 방식임
    • 목표는 취약점이 알려지기 전에 수정이 먼저 배포되도록 하는 데 있음

  • “버그는 버그” 문화

    • Linux에서 특히 흔한 접근으로, 커널이 해서는 안 되는 동작을 한다면 누군가가 이를 공격으로 바꿀 수 있다는 전제를 둠
    • 취약점이라는 사실에 주목을 끌지 않고 가능한 한 빨리 고침
    • 많은 변경이 지나가는 상황에서는 사람들이 눈치채지 못할 수 있고, 그 사이 시스템을 패치할 시간이 남는다는 기대가 있음

  • AI로 인해 공개 수정 방식의 위험이 커짐

    • 이 방식은 원래도 완벽하게 작동하지 않았지만, AI가 취약점 발견에 능숙해지면서 더 큰 문제가 됨
    • 보안 수정이 많이 나오면서 커밋을 검토하는 일이 더 매력적이 됐고, 신호 대 잡음비가 높아짐
    • AI가 각 커밋을 지나가는 시점에 평가하는 비용이 점점 낮아지고 효과도 커지고 있음

  • 긴 엠바고도 약해짐

    • 과거에는 탐지 속도가 느려서, 벤더에 보고하고 90일 공개 창을 두면 그동안 다른 사람이 발견하지 않을 가능성이 높았음
    • 이제는 AI 지원 그룹들이 소프트웨어 취약점을 대량으로 스캔하기 때문에 그 전제가 약해짐
    • 이번 경우 Kim이 ESP 취약점을 보고한 지 9시간 만에 Kuan-Ting Chen도 이를 독립적으로 보고함
    • 엠바고는 잘못된 비긴급성을 만들고, 결함을 고칠 수 있는 행위자를 제한해 위험을 키울 수 있음

  • 가능한 방향과 간단한 모델 테스트

    • 해결책은 명확하지 않지만, 매우 짧은 엠바고가 좋은 접근으로 보이며 시간이 갈수록 더 짧아져야 할 수 있음
    • AI는 공격자뿐 아니라 방어자도 빠르게 만들 수 있어, 과거에는 너무 짧아 쓸모없었을 엠바고도 가능하게 할 수 있음
    • Gemini 3.1 Pro, ChatGPT-Thinking 5.5, Claude Opus 4.7에 f4c50a403를 줬을 때 세 모델 모두 바로 보안 패치임을 맞힘
    • 커밋 맥락 없이 diff만 줬을 때 Gemini는 보안 수정이라고 확신했고, GPT는 그럴 가능성이 높다고 봤으며, Claude는 아닐 가능성이 높다고 봄
    • 이 테스트는 "Without searching, does this look like a security patch?"라는 프롬프트로 각 모델을 한 번씩 실행한 매우 빠른 예시이며, 모델 간 비교에 큰 의미를 두기는 어려움

함께 보면 좋은 글 β

▲
fastkoder 23시간전  [-]

매우 짧은 엠바고 vs 긴 엠바고 중에서 " 매우 짧은 엠바고"로 갈수 밖에 없으니, 보안담당 AI agent는 더 바빠지겠네요.

답변달기
▲
GN⁺ 2일전  [-]
Hacker News 의견들

  • 이 변화는 아주 오래전부터 예고됐고, LLM이 무엇인지 알기 전부터 지금 보이는 균열은 예측 가능했음
    촉매는 소프트웨어 투명성의 증가임. 오픈소스와 소스 공개형 소프트웨어 채택이 크게 늘었고, 역공학과 디컴파일 도구의 성능도 크게 좋아졌음. 일반적인 기성 폐쇄 소스 소프트웨어가 진지한 공격자에게 의미 있게 가려져 있던 시절은 이미 10년도 넘게 지났음
    BinDiff 이후로 이 문제는 천천히 진행돼 왔음. 소프트웨어를 패치하면 취약점도 함께 공개할 수밖에 없음. 그동안은 패치가 곧 취약점 공개라는 걸 알아보려면 어느 정도 전문성이 필요했기 때문에 다들 부정해 왔지만, AI가 그 핑계를 날려버렸음
    이제 mainline Linux에 무언가 병합될 때마다 여러 조직이 그 차이를 LLM 프롬프트에 넣고 취약점 수정인지 공격적으로 평가하며 익스플로잇 가이드를 생성하고 있음. nginx, OpenSSL, Postgres 같은 주요 오픈소스 프로젝트 대부분도 곧 그렇게 될 것임
    조율된 공개 관행은 이 환경에 맞춰져 있지 않고, 사실 지난 10년 동안도 맞지 않았다고 봄
    묘하게도 이 상황이 불편하지 않은데, 조율된 공개 관행은 늘 시스템 관리자 운영 편의를 위해 공개를 늦추는 게 좋다는 전제를 의심 없이 받아들여 왔다고 보기 때문임. 그 전제는 의심할 이유가 있음. 공개 지연은 단순히 패치를 적용하는 것 외의 선택지가 있는 시스템 운영자에게서도 정보를 빼앗음

    • “일반적인 기성 폐쇄 소스 소프트웨어가 진지한 공격자에게 의미 있게 가려져 있던 시절은 이미 10년도 넘게 지났다”는 말은 거의 당연하지만, 마지막 방어선은 소프트웨어를 공개 배포하지 않고 서버-클라이언트 구조에 의존하는 것임
      취약점이 더 쉽게 탐지되고 악용되면 이런 방식이 더 흔해질 수도 있음. 물론 항상 가능한 건 아님
      지난 11년 동안 ProGuard로 난독화한 게임 클라이언트 바이너리가 여러 번 디컴파일되어 GitHub에 올라온 건 꽤 짜증났음. 배포하지 않은 서버 코드만 비공개로 남아 있었음
      흥미롭게도 네트워크 프로토콜을 매주보다 덜 자주 바꾸기 전까지는 공격자들이 이를 역공학하는 문제가 없었음. 이제는 LLM 지원을 받는 공격자라면 그 속도도 따라올 수 있을 것 같음
    • 조율된 취약점 공개가 생긴 비즈니스적 이유는 늘 이해했고, 직장에서도 그 방침을 따를 수밖에 없었지만, 개인적으로는 항상 완전 공개 쪽이었음. 이 변화를 매우 기다려 왔음

  • 이건 AI 문제가 새로 생긴 것이라기보다 오래된 문제가 AI 문제로 재포장된 것에 가까워 보임
    사람들은 LLM이 나오기 훨씬 전부터 커널 커밋 차이를 비교하며 어떤 것이 보안 수정인지 찾아냈음. 패치가 공개적으로 올라오는 순간 경쟁은 사실상 이미 시작된 셈임
    공개 유예 기간을 줄이는 게 정말 도움이 되는지도 잘 모르겠음. 몇 시간 안에 패치할 수 있는 조직은 이미 괜찮고, 나머지는 여전히 며칠이나 몇 주가 걸림
    오히려 익스플로잇 생성 비용이 낮아질수록 조율된 공개는 덜 중요해지는 게 아니라 더 중요해질 가능성이 큼

    • “사람들은 이미 커널 커밋 차이를 비교하며 어떤 것이 보안 수정인지 찾아냈다”지만, 그건 숙련이 필요했고 보통 일관적·체계적으로 이뤄지지는 않았음. AI가 있으면 누구나 어떤 소프트웨어에도 이걸 할 수 있음
      “공개 유예 기간을 줄이는 게 도움이 되는지 모르겠다”에 대해서는, 왜 90일이고 왜 2년은 아닌가가 핵심임. 동시 발견 빈도가 높아지면서 그 균형을 정하던 요인이 바뀌었다는 게 글의 주장임. 어차피 유예 밖에 있는 여러 사람이 익스플로잇을 찾을 거라면, 유예 기간은 실제 창이 아니라 환상일 뿐임
      “저렴한 익스플로잇 생성이 조율된 공개를 더 중요하게 만든다”는 데는 동의함. 하지만 동시에 덜 실행 가능하게 만듦. 스크립트 키디도 제로데이를 찾고 악용할 수 있으면 조율할 수 있는 역량이 무너짐
      화이트햇 문화에는 늘 일종의 장인 길드 윤리가 있었음. 그 길드가 깨지면 그 윤리도 설 자리가 없어짐
    • Linux 개발 전체를 계속 지켜본 건 아니지만, 패치가 커널에 들어가기도 전에 메일링 리스트에서 동작하는 익스플로잇이 공개된 일이 예전에 있었는지 모르겠음
      이런 건 본 적이 없고, 과장 섞인 분위기를 감안하더라도 이제 LLM 덕분에 이런 일이 자주 벌어질 것 같은 인상을 받음
    • Torvalds는 주요 문제가 발견됐을 때 뒤따르는 소동까지 필요하지 않고, 버그 자체를 공개하는 것으로 충분하다고 했음 [1]
      그래서 Dirtyfrag가 Linux 커널 수정으로 공개된 건 놀랍지 않음 [2]
      [1] https://www.zdnet.com/article/torvalds-criticises-the-securi...
      [2] https://afflicted.sh/blog/posts/copy-fail-2.html
    • 오래된 문제가 AI로 더 악화되고 있다고 보는 게 맞겠음
    • 매주 같은 내용의 변형을 쓰는 것 같아서, 게으름을 허락한다면 예전에 쓴 버전을 공유하겠음
      https://news.ycombinator.com/item?id=47921829

  • 큰 문제가 생겼음
    미국은 전쟁 중이고, 지금 세계의 상당 부분도 사이버 공격 수준의 전쟁을 하고 있음. 미국, EU, 중동 대부분, 이스라엘, 러시아가 그렇음
    Ubuntu, GitHub, Let’s Encrypt, Stryker 같은 주요 서비스가 공격받아 며칠씩 내려갔고, 병원 시스템 전체가 부분적으로 중단되기도 했음
    이런 와중에 AI가 공격 생성 속도를 훨씬 빠르게 만들었음. 방어 측이 대응할 수 있는 속도보다 빠름. 예전에는 제로데이 공격이 드물었지만 이제는 보통 일이 됐음
    좋아지기 전까지 더 나빠질 것이고, 어쩌면 훨씬 더 나빠질 수 있음

    • 어떻게 좋아질 수 있는지 모르겠음

  • “이제 보안 수정이 너무 많이 나오기 때문에 커밋을 살펴보는 매력이 커졌다. 신호 대 잡음비가 더 높다”는 부분은 왜 그런지 의문임
    “AI가 각 커밋을 지나갈 때마다 평가하는 비용이 점점 싸고 효과적이 된다”는 부분이 핵심임. AI가 있으면 “변경이 너무 많으니 사람들이 눈치 못 챌 것”이라는 가정이 깨짐

  • 이 빠른 테스트는 많은 걸 보여주지 못함. “이게 보안 패치인가?”라고 직접 물으면 AI가 그 전제에 동의하는 출력을 내도록 암시하고 유도하게 됨
    혼동 행렬이 더 유용함. 물론 이 글이 자세한 AI 역량 테스트 글은 아니라는 점은 이해함

    • 추가 증거로는 크지 않다는 데 동의함. 누군가 그 목록의 N개 커밋에 대해 이 커밋을 포함해 같은 테스트를 돌려본다면 결과가 매우 궁금함
    • 이상적으로는 모든 커널 차이에 대해 LLM이 예/아니오로 분류한 결과의 혼동 행렬에서 계산할 수 있는 파이 계수, 즉 MCC가 필요함
      참양성, 참음성, 거짓양성, 거짓음성 수로 계산 가능함

  • 자동화된 패치와 릴리스 주기가 필요함
    지금까지는 보고를 받고, 조사하고, 검증하고, 패치하고, 릴리스를 준비하는 데 믿기 어려울 정도로 느린 수동 절차에 의존해 왔음. 수정판을 내는 데 몇 달이 걸리는 일이 흔함. 공격자가 몇 시간 만에 새 익스플로잇을 쏟아낼 수 있는 시대에는 너무 느림
    패치까지의 평균 시간을 줄이려면 가치 사슬의 병목을 반복적으로 개선해야 함
    버그 보고를 받은 뒤 1시간 안에 QA 테스트 가능한 패치된 제품으로 돌릴 수 있어야 함. 이를 표준화하거나 오픈소스로 만들고, Linux 커널 → 배포판 → 배포판을 쓰는 제품 → 사용자로 이어지는 전체 소프트웨어 공급망이 쓰게 해야 함. AI가 있으면 못 할 이유가 없고, 우리가 느릴 뿐임

  • AI는 업데이트 창을 극적으로 줄일 것임. 2026년에 의존성 쿨다운을 고민하는 건 최악이고, 이제는 의존성 워밍업을 고민해야 함
    곧 오픈소스 프로젝트에서 취약점을 안전하게 공개하는 방법 같은 건 사라질 것임. 중앙화된 SaaS가 여기서는 큰 보안상 이점을 갖게 됨

    • 폐쇄 소스 중앙화 SaaS가 큰 보안상 이점을 갖게 됨
      오픈소스 의존성의 원격 코드 실행 취약점은 보안 패치가 공개되는 순간 똑같이 취약하다는 뜻인데, 왜 논란인지 모르겠음
    • Linux를 쓰는 조직들이 각자 일정 비용을 들여 AI로 자기 의존성을 계속 스캔하고 패치하며, 서로 패치와 스캔 결과를 보내는 신뢰의 그물망을 만들 수도 있음

  • Tony Hoare의 “명백한 버그가 없는 것”과 “명백히 버그가 없는 것”에 대한 오래된 말은 LLM 시대에 그 어느 때보다 더 잘 들어맞음

  • 버그를 그냥 버그라고 다루는 설명은 개인적으로 꽤 말이 안 되게 읽히지만, Linux 세계에는 실용적 문제보다 원칙을 더 중시하는 사람이 많다는 건 알고 있음
    그래도 90일은 길어 보임
    결국 대형 AI 회사들이 핵심 인터넷 인프라 쪽 사람들을 도와야 할 것 같음. nginx 같은 것들에 최신·최고 AI를 돌리는 건 우리 모두에게 집단적으로 이득이라고 봄

  • “다행히 AI는 여기서 공격자만큼 방어자도 빠르게 해줄 수 있어, 이전에는 쓸모없을 만큼 짧았을 공개 유예도 가능하게 한다”는 대목이 이 문제 공간의 중요한 측면임
    보안 위험이 결국 누가 더 많은 토큰 비용을 쓸 것인가의 군비 경쟁으로 바뀔 수 있음

    • 흥미로운 점은 이 때문에 폐쇄 소스 코드가 방어자에게 더 큰 자산이 된다는 것임
      공격자는 거기에 토큰을 쓸 수 없지만, 방어자는 소스 코드를 기반으로 강화 작업에 토큰을 쓸 수 있음. 공격자는 블랙박스 테스트에 묶이게 됨
답변달기