언제 정보가 "너무 많은 정보"인가요?

조아오 코레이아

2023년 4월 14일 - 기술 에반젤리스트

조금만 주의를 기울여 보셨다면 이러한 추세를 눈치채셨을 겁니다. 특히 지난 1년여 동안 변경 로그가 점점 더 간결해지고 있습니다. 버전 간에 정확히 어떤 일이 있었는지 설명하는 데는 단순한 '버그 수정' 또는 '성능 개선'이 전부인 경우도 있습니다. 이러한 변화에 대한 몇 가지 설득력 있는 이유와 그에 못지않게 흥미로운 반론도 있습니다.

코드 변경에 대한 코드 줄 수보다 코드 변경을 설명하는 텍스트 단락이 더 많던 시대는 지났습니다. 변경 로그는 문학 작가가 자신의 직업 선택을 재고하게 만들 정도로 뛰어난 필치로 작성된 흥미로운 텍스트였습니다. 행복한 날들입니다.

하지만 이제 그런 시대는 지났습니다. Windows 업데이트 변경 로그를 살펴보면 정확히 무엇이 잘못되어 수정이 필요한지, 문제를 해결하기 위해 어떤 조치가 취해졌는지 자세히 살펴볼 수 있습니다. 몇 년 전 이 정책이 시행되었을 때 상당한 (매우 시끄러운) 반발이 있었지만 Microsoft는 꿈쩍도 하지 않았고, 이 정책은 오늘날까지 시행되고 있으며 소비자용 제품과 전문가용 제품 모두에 영향을 미치고 있습니다.

마이크로소프트가 마이크로소프트답기 때문에 이런 일이 벌어지는 것이라고 생각할 수도 있겠지만, 이는 '대기업' 플레이북에서 흔히 볼 수 있는 일입니다. 하지만 통로 건너편에 있는 Linux Kernel을 살펴보면 그곳에서도 같은 일이 벌어지고 있습니다. 물론 Kernel의 버그, 취약성 및 새로운 기능에 대한 여러 포럼의 모든 토론, 의견 및 스레드를 따라갈 수는 있지만 변경 로그 자체를 살펴보면 특정 버전에서 해결된 특정 보안 수정을 식별하는 데 어려움을 겪을 것입니다.

모호성을 통한 보안은 오래 지속되지 않는 경향이 있지만, 개발자들이 이 문제를 해결하기 위해 노력하고 있습니다.

보안 문제

변경 로그의 정보량을 줄여야 한다고 주장하는 사람들은 종종 다음과 같이 주장합니다(특별한 순서 없이):

악의적인 공격자가 이미 배포된 오래된 버전에 존재하는 새로운 취약점(따라서 취약한)을 식별하기 위해 필요한 정보를 줄입니다;
취약점이 공개되고 익스플로잇이 '야생에서' 나타나는 시간이 단 몇 분으로 단축되고 있기 때문에 해커가 시스템 침해를 시도하기 전에 '선량한 사용자'가 시스템을 패치할 수 있는 시간을 조금이라도 제공해야 합니다;
사용자는 가능한 한 빨리 최신 버전을 사용해야 하므로 모든 사소한 세부 사항을 알 필요가 없다고 주장하지만, 항상 패치를 적용하는 것은 사이버 보안의 기본입니다.

하지만 반대편에서도 그에 못지않게 설득력 있는 주장이 있습니다:

악의적인 공격자는 버전 간의 실제 코드 차이를 비교할 수 있는 리소스, 노하우, 인센티브를 가지고 있기 때문에 변경 로그가 필요하지 않습니다. 이제 AI 봇이 이 작업을 지원할 수 있게 되어 필요한 지식 수준이 사소해졌기 때문에 이러한 문제는 더욱 복잡해졌습니다.
이러한 세부 정보를 숨기면 평가할 수 있는 비교 가능한 위험 측정이 없기 때문에 패치할 항목의 우선순위를 정하기가 더 어려워지거나 불가능해집니다.
패치로 인해 의도치 않은 결과가 발생한 적이 없기 때문에 매번 최신 버전을 사용하는 것이 항상 완전히 안전한 것은 아니죠?

이에 대한 논쟁은 매우 빠르게 과열될 수 있으며, 요점을 놓치고 궁극적으로 비생산적인 "내가 가장 잘 안다"는 식의 논쟁으로 변질되기 쉽습니다. 그러나 이러한 논쟁은 보안에 실질적인 영향을 미치는 문제를 효과적으로 부각시킵니다. 시스템에 설치된 모든 소프트웨어를 항상 최신 버전으로 유지해야 한다는 것은 부인할 수 없는 사실입니다. 그러나 하드웨어 지원이 중단되거나 범위, 요구 사항 또는 가용성이 변경되는 등의 일반적인 이벤트는 이를 달성하는 것을 불가능하게 만들 수 있습니다. 이 경우, 심각한 문제가 발생하기 전까지는 현재 노출되어 있는 새로운 취약점을 식별할 방법이 없기 때문에 정보 부족은 도움보다 훨씬 더 큰 장애가 될 수 있습니다.

보안 문제를 명시적으로 식별하지 않는다는 것은 해당 문제에 대한 CVE를 요청하지 않거나 요청을 지연한다는 의미이기도 합니다. 사이버 보안과 같이 거의 전적으로 CVE 추적, 관리, 스캔 및 패치에 초점을 맞추는 분야에서는 모든 도구와 모니터링을 회피하는 보안 문제가 발생한다는 것은 아무리 생각해도 논란의 여지가 있습니다.

우리가 나아갈 방향

변경 로그가 사실상 쓸모없어지는 시기가 올 수도 있습니다.

Windows Server 인사이더 빌드에는 이 기능조차 없으며, 아이러니한 점은 무료로 테스트 작업을 수행하는 베타 버전을 실행하고 있지만 무엇을 테스트해야 하는지 알 방법이 없다는 것입니다. 이는 예외가 아닌 표준이 될 수 있습니다. 소비자 OS 버전에서는 더 이상 패치 설명에 쉽게 액세스할 수 없으며, 이제 일반적인 "버그 수정"이라는 언급만 포함되어 있습니다. 더 자세한 정보를 찾으려면 더 깊이 파고들어야 하며, 그마저도 점차 더 적은 수의 사용자에게만 제공되고 있습니다.

다시 한 번 강조하지만, 이러한 접근 방식이 클로즈드 소스 소프트웨어에만 국한된 것이 아니라는 점을 강조하고 싶습니다. 오픈소스 세계에서도 이러한 접근 방식이 유효한 것으로 채택되고 있습니다. 사실 오픈소스 프로젝트에서는 이러한 접근 방식이 특이한 상황을 만들어냅니다. 한편으로는 자유롭게 사용할 수 있는 소스 코드와 버그 보고서가 있고, 개발자가 버그를 수정하고 기능을 추가하도록 인센티브를 제공하고자 하는 욕구가 있습니다. 하지만 다른 한편으로는 이러한 작업에 도움이 될 수 있는 정보를 의도적으로 숨기고 있습니다. 뭔가 앞뒤가 맞지 않습니다.

이 논쟁에 대한 매우 긴 논쟁 목록은 이 문서에서 찾을 수 있습니다. 스레드에서 일부 Kernel 리더들이 이 문제에 대해 그들이 선택한 접근 방식의 장점과 그에 따른 광범위한 비판에 대해 논의하고 있습니다.

AI의 영향

AI는 빠르게 진화하고 있으며, 새로운 기능을 모두 따라잡기는 어렵습니다. 하지만 현재 AI 봇의 확고한 기능 중 하나는 코드에서 문제를 이해하고 찾는 데 도움을 주는 기능입니다. AI 봇 채팅 인터페이스에 코드 블록 전후를 붙여넣고 "해당 코드 변경으로 해결된 버그 찾기" 및 "해당 버그가 어떻게 악용될 수 있는지"를 묻는 메시지를 표시하는 것은 매우 간단합니다.

오픈 소스 소프트웨어는 접근성이 폐쇄 소스 소프트웨어보다 훨씬 더 빠르게 이러한 영향을 받게 됩니다. 보안 취약점을 식별하기 위해 서로 다른 버전의 소프트웨어 간의 차이를 확인하는 것은 이미 위협 행위자들이 하는 일이며, 이제 그 기준이 상당히 낮아졌습니다. 하지만 선의의 공격자들이 직접 이러한 작업을 수행할 수 있는 가용성과 리소스를 확보하는 것만으로는 여전히 충분하지 않으며, 버그를 찾아서 악용하는 데에만 집중하는 것이 아니라 다른 우려 사항도 가지고 있습니다.

'모호함을 통한 보안'의 '모호함'이 곧 조명을 받게 될 것입니다.

마법 총알 또는 부족

이 문제에 대한 마법의 총알은 없습니다. 지금까지 이 문제는 해결하기 어려운 것으로 입증되었으며, 놀랍게도 모든 사람이 자신의 접근 방식이 최고라고 믿기 때문에 그렇게 하고 있습니다. 이는 마치 한 시스템에 서로 다른 접근 방식을 가진 세 가지 소프트웨어 애플리케이션(OS, 웹 서버, 데이터베이스)을 사용하는 것과 같은 극단적인 상황일 수 있습니다. 결국 누군가는 정보 공유(또는 은폐)에 대한 이러한 서로 다른 접근 방식의 대가를 지불하고 있으며, 이는 IT 전문가가 효과적으로 업무를 수행하기 위해 극복해야 하는 또 다른 장애물이 됩니다.

궁극적으로 변경 로그와 그 안에서 공유되는 정보의 양을 둘러싼 논쟁은 복잡하고 다면적입니다. 기술과 AI가 계속 발전함에 따라 업계는 투명성과 보호 사이의 균형을 맞추기 위해 보안 및 정보 공유에 대한 접근 방식을 재평가해야 할 수도 있습니다.