Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
복잡한 소프트웨어 스택의 취약점 대응에 대한 심도 있는 논의입니다. NixOS와 같은 시스템에서 의존성 폐쇄를 추적하는 도구의 중요성을 강조하며, 단순히 크기를 줄이는 것보다 '시스템의 정확성 증명'이 핵심임을 주장합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기저자가 vendored or hard-coded CA trust bundles를 패키지 목록이나 SBOM에서 찾을 수 있느냐며 NixOS 이슈를 연결한 점이 흥미로움. 그 링크를 따라가면 시스템의 Nix 의존성 폐쇄에 TLS 인증서를 포함한 패키지가 있는지 검사하는 nix-cacert-scan이 나옴.
이 도구로 인증서가 포함된 이유를 추적하고, 오버레이로 패키지를 수정하고, 파이프라인에 자동화를 넣어 시스템 전체에서 손상된 인증서를 탐지할 수도 있음. 이런 시스템 전체 추적 가능성은 NixOS의 강점임.
다만 nixpkgs의 서명된 커밋, 내장 커널 강화, musl 빌드 등 보안에 더 집중하지 않는 점은 아쉬움. nixpkgs는 너무 크고 복잡하게 얽혀 있으니, 상업 업체가 먼저 하기 전에 보안 중심 핵심 부분을 분리하면 좋겠음.
Nixpkgs 작업 대부분은 여전히 자원봉사자가 맡고 있으므로, 기존의 산더미 같은 작업과 별개인 일을 하려면 시간과 의지가 있는 누군가가 필요함. 자금과 동기가 있는 기업이 전담 인력을 고용한다면 원하는 보안 기능은 거의 무엇이든 구현할 수 있을 것임.
다만 자금이 풍부한 기업에서 NixOS를 많이 쓰는 것 같지는 않음. 이런 기업은 움직임이 느리고, Nix와 NixOS가 패러다임을 바꾼다고 외치는 소수 시스템 관리자에게 귀 기울이지 않을 가능성이 큼.
현재 지원되는 NixOS 안정 버전인 26.05의 최신 리비전을 쓰는데도, 연결한 도구로 검사하면 내 의존성 폐쇄에 eMudhra 인증서를 신뢰하는 패키지가 5개나 남아 있음.
모두 업스트림에서는 수정됐지만 nixpkgs 관리자가 아직 수정 사항을 백포트하지 않은 듯함. nixpkgs 팀을 존중하지만, 내 uv 설치가 손쉽게 중간자 공격을 당할 수 있는 상태는 아니었으면 함.
크고 복잡한 소프트웨어 스택에서 취약점을 자동으로 발견하는 상황에 대처하려면, 기능을 상당히 포기하더라도 더 작고 단순한 스택으로 교체하는 편이 맞아 보임.
원래 기능의 필수적인 최소 부분만 수행하면서도, 작고 단순해서 정확성을 증명할 수 있는 도구가 될 때까지 반복하면 됨. 솔직히 좋은 방향이라고 생각함.
프로그램이 얼마나 작아야 버그가 없다고 보장할 수 있을까? 여러 프로그램이 상호작용하고, 다른 시스템의 프로그램과 통신하며, 자체 버그가 있는 불완전한 하드웨어에서 작동한다면 어떨까?
단순성은 복원력에 도움이 되지만 그것만으로는 부족함. 안전 필수 소프트웨어를 접하며 배운 핵심은 프로그램이 아니라 시스템의 정확성을 증명해야 한다는 것임.
작은 크기 자체가 목표는 아님. 결과적으로 작아질 수는 있지만 부수적인 결과일 뿐임.
아주 작은 프로그램도 동작을 추론하기 어려울 수 있음. 6-state Turing Machine for which we don't know whether it halts도 존재함. 반면 훨씬 큰 seL4 같은 프로그램에서는 종료 여부뿐 아니라 더 유용한 성질도 형식적으로 증명할 수 있음. 크기는 추론 가능성을 가늠하기에 매우 불확실한 대리 지표임.
“얼마나 작아야 하는가?”에는 좋은 단일 답이 없지만, 형식 검증에서는 기계적으로 검사 가능한 증명이 통과하면 됨. 정확성을 계속 증명할 수 있다면 기능이나 최적화를 얼마든지 추가해도 됨. “어떤 성질을 검증할 것인가?”라는 논쟁이 “얼마나 작게 만들 것인가?”보다 생산적이라고 봄.
추론하기 쉬운 작은 단위로 분리하고, 검증된 안정성보다 최신 상태를 우선해 철저히 업데이트하는 방향을 생각했음.
초기에는 보안을 위해 안정성을 크게 희생하겠지만, 안정화와 대체 경로, 장애 시 단계적인 기능 축소를 반복해서 개선하면 저자가 가장 큰 부담으로 꼽은 보안 버그를 개별 애플리케이션 스택의 맥락에서 평가하는 작업을 줄일 수 있을 것임. 인프라를 개별 관리하는 반려동물보다 교체 가능한 가축처럼 다루는 접근과도 통함.
이런 전략이 현실적으로 의미 있다고 믿으려면, EU가 정부 기관의 DOCX 사용 사례 하나라도 금지하거나 정부·은행 웹사이트의 JavaScript 기능 하나라도 금지해야 할 것임. 솔직히 EU 말고 누가 하겠는가?
실제로 그렇게 한다면 매우 환영하겠음.
이 상황은 수십 년에 걸쳐 누적돼 왔고, AI와 소프트웨어에 대한 강화된 검증은 그 속도를 높였을 뿐이라고 봄.
C와 C++에는 수십 년 묵은 씁쓸함이 있음. 1988년 Morris 웜이 인터넷의 상당 부분을 장악했을 때 보안이 어렵다는 경고는 충분했어야 함. C가 얼마나 취약한지도 모두 알았어야 함.
당시에는 좋은 대안이 없었다는 점은 인정함. Java를 사용할 수 있는 프로젝트에는 Java가 큰 진전이었음. LLM이 일으키는 골칫거리의 70~80% 는 원래 있던 버그를 드러내는 일임. 대부분의 개발자에게 안전한 C 코드를 작성하는 일이 너무 어려웠기에 존재하던 버그들임.
내가 일한 조직에서는 보안뿐 아니라 전반적으로 더 적은 인력·자원·예산·시간으로 더 많이 하라는 압박이 수년간 커져 왔음. AI 이전부터 그랬는데, 이제는 경영진이 AI만 넣으면 모든 것이 해결될 거라고 여김. 실제로는 이미 타오르거나 곧 타오를 불에 기름을 붓는 셈임.
그렇다고 전부 자본주의 탓이라고 단정하기는 어려움. 완벽하지는 않아도 신중하게 계획하고 미래를 준비하며, 자본주의 환경에서 성공하면서도 일을 허술하게 하지 않는 회사에서도 일해 봤음. 그런 회사 한 곳을 떠난 건 지금도 후회함.
보안을 비롯해 지금 겪는 문제는 오랫동안 쌓여 드러난 만큼, 해결에도 시간이 걸릴 것임.
eMudhra 인증서가 어디 숨어 있는지 사실상 모든 곳을 뒤지는 일을 맡았지만, 저자보다는 덜 비관적임. 지금은 afl-fuzz와 Heartbleed가 등장했던 시기를 조금 떠올리게 함.
우리가 사용하는 소프트웨어에는 생존자 편향이 있고, 2014년처럼 그 건전성을 시험할 새로운 방법이 급증하고 있음. 당시에도 많은 소프트웨어가 타격을 받았지만 살아남았고, 이번에도 살아남은 소프트웨어는 더 튼튼해질 것임. 기본적인 대응 부담은 영구적으로 높아졌겠지만, 지금의 소란은 시간이 지나면 잦아들 것으로 예상함.
침해를 가정하고 악용을 탐지하며 노출·횡적 이동·권한 상승을 제한하라는 것은 그냥 정상적인 보안 절차의 정의 아닌가? 여기서 필요한 “예산”은 전문가의 급여를 뜻하는 것일까?
프로젝트 아키텍처를 세밀한 계층으로 설계하면 모든 공격을 막지는 못해도 피해 범위는 줄일 수 있음. 아니면 바로 도입해 쓸 수 있는 완성형 솔루션 개발에 필요한 예산을 뜻하는 것일까?
진짜 피해자는 소규모 자체 호스팅 운영자 같음. 지금도 할 일이 많아 모든 보안 공개를 따라가기 어렵지만, 개인 웹사이트와 Nextcloud, IRC 바운서 등을 돌리는 내 VPS도 대기업이나 정부 시스템 못지않게 취약함.
현실적으로는 운영체제 공급자의 패치를 최대한 빨리 적용하는 수밖에 없어 보이지만, 그것만으로 부족할 때도 있음. 이번 PHP 취약점이 실제로 얼마나 심각했는지는 아직 모르겠지만, “공개”부터 패키지가 나오고 내가 적용 성공 여부를 확인할 수 있을 때까지는 적어도 몇 시간이 걸렸음.
나도 몇 가지 서비스를 자체 호스팅하며, 이번 일을 비롯한 취약점에 대응해 공개 인터넷에는 정적 파일만 노출하는 방향으로 더 옮겨 갔음. 나머지는 사설 VPN이나 mTLS로만 접근하게 함.
nginx에 인증 없이 가능한 원격 코드 실행 취약점이 없다면, 항상 최신 상태를 따라잡는 데 시간과 주의를 쏟을 필요는 없음.
보안 종사자는 아니지만, 소프트웨어 보안 업계에도 비슷한 의구심이 있음. 직접 취약점을 찾지 않으면 악당들이 찾을 것이라는 이유로 공격 방법을 발견하는 데 엄청난 노력을 쏟는데, 범죄자 대부분은 그렇게 똑똑하지 않다는 점에서 늘 회의적이었음. 순진한 생각일 수도 있음.
범죄자 대부분이 똑똑할 필요는 없음. 연쇄 취약점 공격으로 얻을 돈이 충분하다면 한 명만 공격법을 찾아 배포해도 됨. 주요 국가도 취약점 탐색 인력을 고용하고 있으며, 일부는 이를 실제 공격에 활용한다는 의혹을 받음.
언젠가는 취약점의 홍수가 줄어들거나, 두더지 잡기식 대응으로는 보안을 달성할 수 없다고 받아들여야 함. AI 기반의 집중적인 취약점 탐색이 시작된 지 얼마 되지 않아 발견량이 줄지 않을 것이라고 단정하기는 이름. 다만 더 체계적이고 구조적인 접근을 시도하기까지 얼마나 기다릴지는 모두 생각해 봐야 함.
조직범죄가 소규모 범죄자에게 서비스를 판매하는 일이 더 많지 않다는 게 의외임. 예를 들어 소셜 미디어나 침해된 IoT 기기로 집주인이 부재중인 주택 목록을 알아낼 방법이 여럿 있음.
이런 정보를 다른 나라의 좀도둑에게 20달러에 파는 일은 여러 국가에서 비교적 위험이 낮은 범죄일 것 같음.
“제로 트러스트” 대신 ZINT(Zero Implicit Network Trust) 라는 약어를 계속 사용해 왔음. 네트워크를 암묵적으로 신뢰하지 않는다는 뜻이어서, 실무자가 요구사항을 바로 이해할 수 있을 만큼 구체적임.
무엇이 지속 불가능하다는 것일까? 글에서는 오히려 현재 상태가 지속될 것이라고 말하는 듯함. 모든 소프트웨어 취약점이 발견되고 수정되는 세상은 오지 않을 것이라면서, 마지막 선택지는 현 상태를 받아들이는 것이라고 함.
그 정도면 괜찮음. 현실 세계를 받아들이며 살고 싶음.