← 목록으로

리눅스 커널 개발자 Greg Kroah-Hartman, LLM 시대의 보안 [영상]

• LLM이 찾아낸 취약점의 숫자보다 실제 버그를 검증하고 고치는 일이 중요함. 리눅스 커널 개발자 Greg Kroah-Hartman이 AI 보안 도구의 성과와 한계, 유지보수자의 대응을 다룬 발표
• Mythos가 발견했다는 리눅스 취약점 79개에는 오탐·중복·이미 수정된 문제가 섞여 있었으며, 검토 결과는 ‘실제 버그 수정 10개’로 압축됨
• 그렇다고 LLM을 버릴 필요는 없음. 과거 수정 패턴을 찾아 비슷한 버그를 발견하고, 작은 문제들을 연결해 공격할 수도 있으므로 사소한 수정까지 꾸준히 적용해야 함
• 그럴듯한 설명을 믿기보다 코드·재현 절차·테스트 결과를 확인하고, 보고자에게 수정 패치를 요구해 검증 부담을 떠넘기는 보고를 걸러야 함
• 로컬 모델로 비공개 정보를 보호하며 실제 문제를 해결하면 됨. 퍼징 도구가 등장했을 때처럼 버그를 하나씩 고쳐 나가면 코드베이스는 더 나아질 수 있음

취약점 79개라는 숫자 뒤에 남은 것

• Greg Kroah-Hartman이 Kernel Recipes 2026에서 리눅스 커널 개발자와 오픈소스 유지보수자를 대상으로 진행한 발표임
• 커널의 CVE 처리량은 지난해 주당 약 50건에서 현재 하루 33건으로 늘었지만, 기존 처리 도구는 이 규모를 감당하고 있음
  • CVE의 숫자가 곧 같은 수의 심각한 공격 가능성을 뜻하는 것은 아니며, 실제 문제와 공격 조건을 구분해야 함
• Anthropic의 Mythos가 발견했다는 리눅스 취약점 79개의 원자료를 검토한 결과, 상당수는 새로운 보안 취약점으로 보기 어려웠음
  • 24개는 충돌했다는 내용만 있고 구체적인 정보가 없었음
  • 14개는 버그가 아니었고, 3개는 지어낸 데이터였음
  • 15개는 최신 버전에서 이미 수정됐으며, 이 중 11개는 다른 개발자가 먼저 수정한 문제였음
  • 나머지 실제 버그로 분류된 보고에도 중복이 있었고, 수정이 필요한 20개 중에는 커널의 보안 위협 모델에 포함되지 않는 조건을 가정한 문제가 섞여 있었음
• 최종적으로 이를 ‘실제 버그 수정 10개’ 로 정리함
  • 커널 전체의 시간당 패치 반영량과 비교해 ‘커널 개발 한 시간 분량’이라고 표현함
  • 이는 자신이 모든 문제를 한 시간 만에 찾아 고쳤다는 뜻은 아님

과장 홍보와 별개로, 도구는 활용할 수 있음

• Mythos가 사용한 접근은 과거에 수정한 버그와 같은 패턴이 다른 코드에도 남아 있는지 찾는 방식임
  • 커널 개발자들이 Coccinelle 등의 도구로 오래전부터 수행해 온 접근이며, 완전히 새로운 발상은 아님
• LLM 기반 도구도 실제 버그를 찾고 재현 환경과 수정안을 만드는 데 도움이 될 수 있음
  • NOMMU 환경의 문제에서는 가상 머신과 테스트 코드를 만들어 문제를 재현하고 수정 방법을 제시했음
  • 퍼징이 입력을 전달할 수 있는 경로에 제약을 받는 것과 달리, 코드 분석으로 다른 경로의 문제도 탐색할 수 있음
• 작은 버그 여러 개를 연결한 공격도 가능하므로, 심각해 보이는 취약점만 골라 고치는 것으로는 부족함
  • 수정된 버그를 실제 운영 시스템에 적용하지 않는 관행이 중요한 문제임
  • 오랫동안 미뤄 온 유지보수와 보안 투자의 대가를 치르고 있는 상황임
• 퍼징과 정적 분석 도구가 등장했을 때도 비슷한 부담을 겪었음
  • 실제 문제를 확인하고 수정하는 작업을 반복하면 발견되는 버그를 줄이고 소프트웨어를 개선할 수 있음

그럴듯한 보고서보다 코드와 테스트 확인

• 대학원생 6명과 함께 생성된 패치를 검토한 경험에서는 그럴듯해 보이는 패치의 약 절반이 잘못됐음
  • 적용되지 않거나 문제를 해결하지 못하는 패치, 존재하지 않는 문제를 고치는 패치, 실제로 실행될 수 없는 경로를 전제로 한 패치 등이 있었음
  • 발표자 자신도 처음에는 맞는 수정이라고 판단했다가 더 깊은 검토에서 오류가 드러난 사례가 있었음
• 장황한 설명이 수정의 타당성을 보장하지 않음
  • 변경 설명을 걷어내고 코드부터 확인하는 편이 판단에 도움이 됐음
  • mutex_unlock을 mutex_destroy로 바꾸는 등, 이름은 그럴듯하지만 새로운 버그를 만드는 수정도 반복적으로 나타남
• 학습에 포함된 오래된 코드는 현재 프로젝트의 개발 관행과 다를 수 있음
  • 최신 코드 스타일과 안전한 구현 방식 대신 과거의 잘못된 패턴을 재생산할 수 있음
• 유지보수자는 재현 절차, 테스트 방법, 정보의 출처를 요구하고 잘못된 보고를 반려할 수 있음
  • 패치가 많고 설명이 길다는 이유로 받아들일 의무는 없음
  • 제출자가 질문에 답하고 실제 검증에 참여하는지도 중요함

유지보수 부담을 줄이는 대응

• 리눅스 커널 보안팀은 어떤 조건을 보안 문제로 보는지 위협 모델을 문서화함
  • 악성 파일시스템 이미지를 관리자가 직접 마운트하는 상황처럼, 범위 밖의 문제를 구분하는 기준이 됨
• 보고할 때 해당 하위 시스템의 유지보수자를 함께 포함하고, 초기 수정 패치도 제출하도록 요구함
  • 수정안을 만드는 과정에서 애초에 버그가 아니라는 사실이 드러나기도 함
  • 긴 보고서만 받아 유지보수자가 처음부터 원인을 분석하고 패치를 만드는 부담을 줄이려는 조치임
• OpenSSF와 Alpha-Omega의 지원으로 보안 보고 검토를 돕는 전담 개발자도 확보함
• 비공개 보안 정보는 외부 서비스에 올리지 않고, 로컬 모델과 에이전트 도구를 활용하는 방향을 권함
  • 프로젝트별 검토 지침과 위협 모델을 제공하고, 결과는 사람이 확인해야 함
• 더 이상 쓰이지 않는 드라이버나 프로토콜은 수정 대신 삭제하는 것도 해결책임
  • 사용되지 않는 드라이버를 제거해 약 3,000줄의 코드를 없앤 사례도 있음
• 당분간 작업량은 많겠지만, 실제 버그를 고치고 불필요한 코드를 줄여 나가면 커널은 이전보다 나아질 수 있음