Red Hat Blog를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://www.redhat.com/en/blog/2024-red-hat-product-security-risk-report-cves-xz-backdoor-sscas-aioh-my
따뜻한 차나 커피 한 잔을 마시며 Red Hat Product Security 에서 발간한 2024 제품 보안 위험 보고서를 읽어보세요 . 오픈소스 생태계와 그 보안 과제에 대해 최신 정보를 얻고자 노력하는 사람으로서, 올해 보고서는 눈에 띄게 길었지만, 깊이와 세부적인 내용은 실망스럽지 않았습니다. 특히 올해 보고서에 추가된 주목할 만한 내용 중 하나는 AI에 대한 내용입니다.
숫자 게임: 위로, 위로, 그리고… 잠깐, 뭐라고요?
먼저, 원자료를 분석해 보겠습니다. Red Hat Security Advisories (RHSA)는 2024년에 2,975건으로 새로운 정점을 찍었습니다. 지난 몇 년간 꾸준히 증가해 왔습니다. 흥미롭게도, 중요 및 보통 권고는 크게 증가한 반면, 심각 권고는 소폭 감소하여 더욱 적극적인 보안 관행과 빠른 탐지 속도에 집중되었습니다.
일반 취약점 및 노출(CVE) 수는 4,272개로 급증했는데, 이는 비교적 안정적이었던 전년 대비 크게 증가한 수치입니다. 이러한 현상의 원인은 무엇일까요? 보고서는 Linux Kernel Organization가 2024년 2월 CVE 번호 부여 기관(CNA)으로 지정되었다는 점을 강조합니다. CVE 번호 부여 기관은 이전에는 지정되지 않았던 여러 커널 문제에 CVE를 할당하기 시작했습니다. kernel.org에 새롭게 추가된 CVE를 제외하면, 추세선이 다소 증가한 것으로 보이며, 이는 레드햇의 포트폴리오 확장을 반영하는 것으로 보이지만, 우려스러운 수준은 아닙니다.
더 자세히 살펴보면, 대부분의 새로운 커널 CVE는 보통 및 낮음 등급을 받았으며, kernel.org에서 2024년에 할당한 CVE 중 45%만이 현재 Red Hat Enterprise Linux (RHEL) 커널에 영향을 미쳤습니다. 더 나아가, 실제 악용 시도가 발견된 곳과 일치하는 ‘중요’ 및 ‘중요’ 취약점 에 집중해야 합니다 . 이러한 접근 방식은 Red Hat이 ‘중요‘ CVE 의 절반 이상을 신속하게 처리하여 7일 이내에 첫 번째 수정 사항을 제공하고, 0일차에 3개의 수정 사항을 제공하는 것을 통해 입증되었습니다.
이러한 지표를 살펴볼 때 위의 맥락을 고려하지 않는다면, “Red Hat은 도대체 뭘 하고 있는 걸까?”라고 생각할 수 있습니다. CVE(핵심 보안 취약점) 수는 크게 증가했지만, Red Hat 제품의 근본적인 위험 프로필은 실제로 이와 같은 방식으로 변화하지 않았습니다. 이러한 수치는 CVE 수에만 의존하는 것은 불충분함을 보여줍니다. 심각도, 악용 가능성, 그리고 관련성도 고려해야 합니다. Red Hat이 Critical(중요) 및 Important(중요) 문제에 대한 패치 적용 에 집중하는 것은 데이터를 통해 입증되었으며, 실제 악용 사례가 가장 많이 발생하는 부분을 보여줍니다. 따라서 위험 기반 접근 방식이 가장 타당함을 입증합니다.
XZ Backdoor: 방 안의 코끼리
2024년 보안에 대해 이야기할 때 XZ Backdoor 사건을 빼놓을 수 있을까요? 이 사건은 치밀하게 계획된 공급망 공격으로, 오픈소스 커뮤니티의 꿈에도 여전히 남아 있습니다. 2년 넘게 커뮤니티와 신뢰를 쌓아온 한 신뢰받는 관리자가 XZ 라이브러리에 정교한 백도어를 설치했습니다. Andres Freund가 백도어 때문에 발생한 성능 저하를 알아차리지 못했다면, 수많은 시스템의 보안 셸(SSH) 접근이 침해되었을 수도 있습니다.
이 보고서에서 Red Hat은 오픈소스 대응을 되돌아보며, 내재된 위험을 강조하고 오픈소스 모델의 강점을 소개합니다. 소스 코드와 상호작용이 공개되었기 때문에 신속하고 협력적인 분석과 정보 공유가 가능했습니다. 또한 Fedora 테스트 및 RHEL 품질 엔지니어링과 같이 Red Hat의 자체 파이프라인 내에서 발생할 수 있었던 장벽에 대해서도 논의하지만 , 확실히 말할 수는 없습니다.
XZ 백도어 사건은 경종을 울렸습니다. 이 사건은 오픈 소스의 신뢰와 기여 프로세스에 장기적인 영향을 미칠 것입니다. 공급망 공격은 그 횟수와 정교함이 증가하고 있습니다. 공격자들은 개발자들이 매일 사용하는 공통 도구와 공유 코드를 표적으로 삼아 광범위한 문제를 일으키고자 합니다. 이러한 유형의 공격은 소프트웨어 공급업체가 다층적인 보호 체계를 갖춰야 함을 보여줍니다. 즉, 미리 빌드된 코드의 안전성을 자동으로 확인하고, 소프트웨어 빌드를 위한 안전한 조립 라인을 구축하며, 새로운 부분을 추가하기 전에 면밀히 검사해야 합니다. Red Hat이 최근 XZ 보안 문제를 포착할 수 있었고, 실제로도 포착할 수 있었던 여러 가지 점검 조치를 마련했다는 사실은 이러한 보안 체계가 실제로 도움이 된다는 것을 보여줍니다. 보안은 결코 한 번에 끝나지 않습니다.
공급망 문제
Software Supply Chain Attacks(SSCA)의 급증과 오픈소스 구성 요소 의존도는 믿기 어려울 정도이지만, 통계적으로는 사실입니다. Black Duck의 분석은 심각한 상황을 보여줍니다. 상용 코드베이스의 무려 97%가 오픈소스 구성 요소에 의존하고 있다는 것입니다. 이는 혁신과 개발 속도를 높이는 반면, 악의적인 공격자들에게는 매우 매력적인 공격 대상이 될 수 있습니다. 데이터에 따르면 이들은 어떤 기회도 놓치지 않습니다. Red Hat이 공개적으로 보고된 SSCA를 추적한 결과, 2024년에 발생한 사고는 89건으로 전년 대비 무려 68% 증가했습니다. Sonatype의 보고서도 이러한 불안한 추세를 반영합니다. 소프트웨어 공급망은 점점 더 공격받고 있습니다.
XZ Util 침해와 정교한 고용 사기 계획을 사용하여 내부자 접근 권한을 얻은 북한 위협 행위자는 악의적인 행위자가 사용하는 진화하는 전술의 두 가지 예일 뿐입니다.이것의 문제점은 이러한 공격의 대부분에 대한 동기가 거의 알려지지 않았고 엄청난 양의 공격이 청구되지 않은 채로 남아 있다는 것입니다.누가 공격하는지 또는 왜 공격하는지 완전히 이해하지 못하면 효과적으로 방어하기 어렵습니다.일부 공격자가 돈을 원하거나 간첩을 시도한다는 것을 알고 있지만 많은 공격의 목표를 알지 못합니다.이는 사이버 위협과 관련된 전체 상황을 복잡하게 만들고 예측하거나 모델링하기 어렵습니다.공격자의 관점에서 개발자와 그들의 액세스 포인트를 표적으로 삼는 것은 왕국의 열쇠를 쥐고 있기 때문에 완벽하게 합리적이지만 디지털 세계를 구축하는 바로 그 인간적인 요소가 주요 표적이 된다는 것을 의미합니다.
이러한 SSCA는 숙련되고 익명화된 공격자에 의한 중요한 오픈 소스 종속성 악용이 증가하고 있음을 보여줍니다. 오픈 소스가 현대 소프트웨어의 기반이라는 이유만으로 오픈 소스 사용을 중단할 수는 없습니다. 따라서 앞으로 근본적인 변화가 필요합니다. 침해 사고 대응 시뿐만 아니라 개발 라이프사이클 전반에 걸쳐 더욱 선제적인 보안 프로토콜을 구축해야 합니다. 여기에는 종속성 검증 강화, 개발자를 위한 강력한 보안 관행, 그리고 XZ 대응 사례에서 강조된 바와 같이 공급업체, 커뮤니티, 사용자가 생태계 보안에 투자하는 공동 책임 모델이 포함됩니다. 오픈 소스 의존도의 엄청난 규모는 보안에 대한 비례적인 투자를 요구합니다. 우리는 여전히 몇 발 앞서 있는 적들을 따라잡기 위해 노력하고 있습니다.
AI에 대한 찬가
혹시 놓치셨을지도 모르지만, 지난 한 해 동안 생성형 AI(Generative AI)는 챗봇부터 코딩 도우미, 그리고 창작 도구에 이르기까지 폭발적으로 성장했습니다. 이러한 성장세는 계속되고 있으며, Gen AI는 2030년까지 매년 37%씩 성장할 것으로 예측됩니다 . 믿기 어려울 정도로 놀라운 성장세입니다.
하지만 모든 반짝이는 신기술이 그렇듯, 이 기술에도 모두가 그 기술이 무엇을 할 수 있는지에 집중하는 허니문 단계가 있습니다. 얼마나 빨리 작동할 수 있을까? 얼마나 많은 것을 만들어낼 수 있을까? 우리가 하는 모든 일을 어떻게 바꿀 수 있을까?
하지만 이제 의료, 금융, 정부처럼 규제가 엄격한 산업에서 특히 실수가 중대한 결과를 초래할 수 있는 분야에서 진정한 가치를 깨닫게 되었으니, 우리는 심각한 문제들을 생각해야 합니다. AI 사용을 어떻게 안전하고, 보안적이며, 신뢰할 수 있게 유지할 수 있을까요? AI가 문제를 일으키거나 개인 정보를 유출하지 않을 것이라고 믿을 수 있을까요? 의사 결정권자들은 데이터 보안이 이미 올해 AI에 대한 사람들의 가장 큰 우려 사항이라고 말합니다. 충분히 공감되는 이야기입니다. 안전하게 구축되지 않았다는 이유로 개인 정보가 유출되거나 AI가 잘못된 결정을 내리는 것을 원치 않으니까요. 위에서 읽으셨듯이, 오픈 소스 분야에서는 이미 몇 가지 가시성 높은 목표가 있습니다.
제가 감사하게 생각하는 점은 우리가 단순히 AI 열풍에 편승하는 것이 아니라, AI를 안전하고 안전하게 만드는 방법을 실제로 연구하고 있다는 것입니다. 하지만 쉬운 일은 아닙니다.
Red Hat이 Building Trust: Foundations of Security, Safety and Transparency in AI 에서 지적한 첫 번째 사항 중 하나는 AI 보안 취약점과 AI 안전 문제를 분리해야 한다는 것입니다.
- 보안 취약점: 해커가 AI 시스템에 침입하는 방법을 찾아냄.
- 안전 문제: AI 자체가 “해킹”하지 않았더라도 부정확하거나 편향적이거나 심지어 해로운 내용을 말할 수 있습니다.
이러한 문제는 다르게 해결해야 합니다. 버그를 수정하는 것과 AI에게 악의적인 행동을 하지 않도록 가르치거나 허위 정보를 조작하는 것은 다르기 때문입니다. 서로 다른 규칙이 필요합니다.
Red Hat과 같은 기업, EU와 미국 같은 정부, 그리고 다양한 산업 단체들이 이 문제를 해결하기 위해 열심히 노력하고 있다는 점은 안심이 됩니다. 이들은 다양한 AI 위험을 추적하기 위한 지침, 표준, 그리고 방법을 개발하고 있습니다. 엔지니어들을 교육하고 안전한 설계를 구축하는 등, 이 기술을 처음부터 책임감 있게 구축하고자 합니다. 중요한 것은 Red Hat이 단순히 말하는 것이 아니라 실제로 구축하고 있다는 것입니다.
그렇다면 이 모든 것이 무엇을 의미할까요? AI 붐은 흥미롭고 많은 것을 바꿀 수 있습니다. 하지만 결국은 신뢰입니다. 모든 좋은 관계가 그렇듯, 신뢰는 기본입니다. AI와의 관계는 신뢰를 바탕으로 구축되어야 AI의 모든 이점을 누릴 수 있으며, 이는 화려한 데모 이상의 의미를 지닙니다. AI 기술의 안전성과 보안성을 확보하고 예상대로 작동하도록 뒷받침하기 위해 보이지 않는 곳에서 끊임없이 노력하는 것에서 비롯됩니다. 적임자들이 이 부분에 집중하고 있는 것 같아 다행입니다. 나중에 큰 문제를 해결하려고 애쓰기보다는 지금 신중하게 보호책을 마련해야 합니다. AI를 믿고 AI를 믿고 AI를 믿고 AI를 사용할 수 있는 사람들이 필요합니다!
SDLC의 숨은 노력
2024년, Red Hat은 모든 신뢰할 수 있는 제품 뒤에는 어떤 것도 놓치지 않기 위한 엄청난 노력이 숨어 있음을 증명했습니다. Red Hat의 접근 방식은 단순히 NIST 보안 표준을 따르는 데 그치지 않습니다. Red Hat은 AI 기술을 포함하여 모든 개발 제품의 신뢰성과 신뢰성을 처음부터 검증하기 위한 고유한 방법을 개발하고 있습니다.
보안 중심 소프트웨어 구축 계획을 제공하는 Red Hat Secure Software Development Lifecycle(RHSDLC)은 이제 더욱 스마트해지고 오늘날의 실제 보안 과제에 더욱 부합합니다. 하지만 단순히 기준을 충족하는 데 그치지 않습니다. RHSDLC와 같은 자체 표준을 개발하여 Security Operating Approvals(SOA) 절차를 개선함으로써 소프트웨어 공급망의 보안을 처음부터 끝까지 강화하고 있습니다. 여기에는 타사 도구 검증, 검사 자동화, 문제 발생 전 위험 표시가 포함됩니다. 마치 홍수가 날 때까지 기다리지 않고, 아직 물이 새기 전에 잡는 것과 같습니다. Red Hat은 보안 세부 사항을 철저히 조사하고 신뢰, 투명성, 복원력을 최우선으로 고려하여 제품에 대한 고객의 신뢰를 강화하기 위해 최선을 다하고 있습니다.
Security Architecture Reviews(SAR)가 RHSDLC에 표준화된 것을 보고 정말 기뻤습니다. 이 검토는 “절대적으로 필요한 부분에만 접근 권한 부여”, “방어 체계 강화” 와 같은 전통적이고 검증된 보안 원칙을 뒷받침하며 , 제품 설계 단계부터 보안을 구현하도록 보장합니다.
마지막으로 RapiDAST가 있습니다. 오픈소스나 애플리케이션 개발에 관심이 있다면 이 도구는 숨겨진 보석과도 같습니다. Red Hat의 동적 애플리케이션 보안 테스트 도구인 RapiDAST는 2024년에 대대적인 업그레이드를 거쳤습니다. RapiDASTS는 단순히 성능이 향상된 것이 아니라 사용하기도 더 쉬워졌습니다. 예를 들어, 쿠버네티스 운영자 테스트 지원, 향상된 자동화, 그리고 훨씬 간소화된 인터페이스를 제공합니다. 이제 결과를 Google Cloud Storage로 바로 내보낼 수 있어 협업 효율성이 더욱 높아졌습니다.
Red Hat은 이 모든 것을 개발자들이 제품을 빌드하고 출시하는 데 매일 사용하는 시스템인 CI/CD 파이프라인에 직접 구축하고 있습니다. 도구에 의존하는 개발자, IT 전문가, 시스템 보안을 유지하려는 최종 사용자 등 모두에게 보안 중심 개발에 대한 의지는 매우 중요합니다. 끊임없는 사이버 위협이 존재하는 세상에서, 소프트웨어 공급업체가 설계 단계부터 테스트 및 구성 요소 추적에 이르기까지 보안에 집중하고 있다는 사실은 안심이 됩니다. Red Hat은 보안을 단순한 부차적인 요소가 아닌 품질의 핵심 요소로 간주합니다.
2025년에 다시 만날 때까지
올해 보고서는 보안이 끊임없이 변화하고 있음을 다시 한번 일깨워줍니다. CVE 보고 방식의 변화, 지속적인 공급망 위험, AI의 영향력 증가, 그리고 취약점 우선순위 지정 등 사용자가 고려해야 할 사항이 많습니다.
이처럼 투명한 보고서는 매우 중요합니다. 개발자부터 IT 팀, 저처럼 호기심 많은 독자까지 우리 모두가 상황을 파악하고, 어려움을 이해하며, 더욱 현명한 선택을 할 수 있도록 도와줍니다. 제 생각에는 단순히 문제를 예방하는 것만이 아니라, 문제에 어떻게 대응하는지도 마찬가지로 중요합니다. XZ 백도어와 같은 사고 발생 시 오픈소스 커뮤니티가 어떻게 힘을 모았을까요? 바로 이것이 바로 협업의 힘입니다!
Red Hat 제품 보안 위험 보고서 2024 전문을 읽어보세요 .
