정부 공급망 파이프라인의 사이버 취약점 실태를 밝히다

이 기사는 TechCrunch에 게재되었던 내용을 바탕으로 업데이트하여 재구성했습니다.

‍

이름조차 언급하기 싫은 한 해 동안 이미 충분한 혼란을 겪었음에도, 2021년은 미국 정부에 기록상 최악의 데이터 유출 사고 중 하나라는 충격적인 소식과 함께 시작되었습니다. 솔라윈즈(SolarWinds) 사건은 국가 차원의 정교하고 파괴적인 공격으로, 여러 정부 부처와 대기업을 공포에 몰아넣으며 엔드포인트 보안을 강화하기 위해 허둥대게 만들었습니다. 사실상 솔라윈즈 소프트웨어의 모든 최종 사용자가 피해를 입었으며, 이 사건은 소프트웨어 공급망에서의 사이버 보안과 방어가 얼마나 중요한지를 여실히 보여주었습니다.

사이버 보안이 중요하다는 것은 누구나 알지만, 공급망이라는 맥락에서 그것이 실제로 무엇을 의미할까요?

일반적인 개발 팀의 사이버 보안 현주소

매일 엄청난 양의 소프트웨어가 생산되고 있으며, 매년 수십억 줄의 코드가 쏟아져 나옵니다. 디지털 중심의 생활 방식에 대한 수요가 커짐에 따라 이 수치는 더욱 증가할 것입니다. 전 세계 개발자 수는 2024년까지 거의 2,900만 명에 이를 것으로 예상되지만, 현재 그들의 안전한 코딩 능력을 평가하고 인증할 공식적인 자격 제도는 존재하지 않습니다. 모든 개발자가 보안에 취약한 코드를 작성하거나 재사용한다는 의미는 아니지만, 우리가 데이터 보안을 신뢰하는 소프트웨어에 기본적인 보안 취약점이 포함될 위험은 분명히 지속되고 있습니다.

개발자들은 기능을 구현하고 코드를 최대한 빠르게 배포하는 능력으로 평가받습니다. 대부분의 조직에서 보안은 성공의 척도가 아니었지만, 소프트웨어 개발 초기 단계에서 흔한 보안 버그를 예방하는 것이 얼마나 중요한지 깨닫는 기업이 늘어나면서 이러한 인식도 변화하고 있습니다. 그러나 인식과 실천은 별개의 문제입니다. 대부분의 대학 개발 교육 과정에서 안전한 코딩 관행에 대한 맥락을 다루지 않기 때문에, 부족한 부분을 채우는 것은 종종 개발자의 직장 몫이 됩니다. 만약 기술 향상과 지식 공유가 드물거나 실무와 동떨어져 있다면 효과는 거의 없을 것입니다. 결국 기술 개발 부족으로 인한 취약점의 악순환은 끊이지 않고 있습니다.

물론 전 세계의 사이버 보안 문제를 해결하는 것이 일반 소프트웨어 개발자의 책임은 아닙니다. 애초에 조직이 비싼 비용을 들여 보안 전문가를 고용하는 이유가 바로 그것이니까요. 하지만 보안 전문가가 부족한 상황에서 개발자들도 보안 부담을 줄이는 데 분명히 기여할 수 있습니다.

그렇다면 파괴적인 사이버 공격을 예방하기 위해 우리와 핵심 인프라 및 민감한 조직을 위한 소프트웨어를 만드는 공급업체는 어떤 위치에 서야 할까요? 최소한 소프트웨어 조달 방식의 현상 유지부터 변화시켜야 할 것입니다.

안전한 소프트웨어 공급망을 가로막는 함정들

사슬은 가장 약한 고리만큼만 강하다는 진부한 격언은 안타깝게도 소프트웨어 공급망에도 그대로 적용됩니다. 귀사가 보안 모범 사례를 강화하고, 개발자 역량 강화에 투자하며, 기능적인 DevSecOps 환경(즉, 소프트웨어를 최대한 안전하게 만드는 책임을 모두가 공유하는 것)으로 나아가고 있더라도, 보안 문제가 있는 공급업체의 소프트웨어를 사용한다면 그 위험을 그대로 떠안고 결과를 감당해야 합니다.

물론 보안 팀이 기술 스택에 추가되는 타사 소프트웨어의 안전성을 평가해야 하지만, 비즈니스 요구 사항에 따라 선택의 여지 없이 결정이 내려질 때도 있습니다. 이 시점부터는 신뢰의 문제가 됩니다. 공급업체가 귀사만큼 보안을 중요하게 생각할까요? 그리고 공급업체가 귀사가 보호해야 할 자산과 위험을 귀사만큼 제대로 이해하고 평가할 수 있을까요?

투명성은 공급업체 소프트웨어의 보안 적합성을 평가하는 데 가장 중요한 요소입니다. 그들은 자사의 보안 관행을 투명하게 공개하고 있나요? 그들은 데이터를 안전하게 보호하는 방식에 자부심을 느껴야 하며, 이를 최우선 순위로 삼아야 합니다. 보안 관행이 어디에도 게시되어 있지 않거나 정보를 얻을 수 없다면, 보안을 최우선으로 생각하지 않을 가능성이 큽니다. 공급업체는 기술적인 질문에 답변할 수 있어야 하며, ISO27001이나 SOC2와 같은 독립적인 인증을 보유하고 있다면 더욱 좋습니다. 또한, 내부 실사 및 보안 관행의 일환으로 직접 코드를 들여다보고 취약점을 스캔할 수 없다면 그 소프트웨어는 고려하지 않는 것이 좋습니다.

소프트웨어 수요가 급증하고, 특히 공급업체의 코드가 새로운 환경에서 작동하도록 기존 시스템에 통합되는 상황에서 공급업체와 구매자 모두 최고의 역량을 발휘해야 합니다. 양측 모두 개발자가 현장에서 일반적인 보안 버그와 결함을 배포 전에 찾아낼 수 있도록 해야 합니다. 기존의 복잡한 기술 솔루션 네트워크에 새로운 요소가 추가될 때 수백, 수천 개의 종속 항목이 위험에 노출될 수 있으며, 작은 실패 하나가 치명적인 결과로 이어질 수 있습니다.

그렇다면 해결책은 무엇일까요? 모든 것을 처음부터 직접 코딩하는 것일까요? 1998년이라면 말이 되었을지도 모릅니다. 하지만 이제는 더 이상 가장 가까운 세차장을 찾기 위해 검색 엔진에 묻지 않는 것처럼, 오늘날의 환경에 맞는 현실적인 안전장치를 구현해야 합니다.

만병통치약은 없지만, 해결책은 있습니다

구매자의 경우, 공급업체 소프트웨어와 개발 관행에 대한 보안 평가는 전체 보안 프로그램 및 위험 완화 계획의 우선순위가 되어야 합니다. 그들의 인증, 관행, 그리고 개발자들의 보안 평판에 대해 질문하십시오.

공급업체(소프트웨어를 만드는 모든 기업 포함)는 보안을 최우선으로 생각하고 있음을 증명할 준비가 되어 있어야 하며, 역량 강화에 집중해야 합니다. 보안 기술을 갖춘 개발자는 수요가 매우 높으며, 적절한 도구와 지원이 있다면 기존 팀원들을 교육하여 일반적인 취약점으로 인한 공격을 방어할 수 있는 인재로 성장시킬 수 있습니다. 하지만 아무 교육이나 제공하지 마십시오. 기존 워크플로우를 보완하는 보안 도구를 사용하여 그들이 성장할 시간을 주십시오. 최대한 쉽게 만들고, 비즈니스를 구동하는 코드 속에서 성가신 버그들이 줄어드는 것을 확인하십시오.

결론적으로, 소프트웨어의 모든 위험은 공급망의 일부가 되는 순간 즉시 증폭되어 모든 사용자와 취약한 구성 요소가 사용된 모든 시스템에 영향을 미칩니다. 공급업체가 소프트웨어를 구현하는 기업만큼 보안에 진지하지 않거나, 양측 모두 보안 프로그램이 부족하다면 솔라윈즈와 같은 파괴적이고 광범위한 공급망 공격은 필연적으로 일상이 될 것이며, 이는 모두에게 치명적인 문제입니다.