운영 현대화로의 전환은 소프트웨어 공급망 보안의 필요성을 높일 것입니다

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

요즘 소프트웨어 공급망의 보안이 위협받는 것은 놀라운 일이 아닙니다. 먼저 log4j가 뉴스에 보도되면서 모두가 소프트웨어 공급망 전반에 광범위하게 퍼진 심각한 취약점을 완화하기 위해 분주히 움직였습니다.

최근에는 Spring4Shell이 새롭게 주목받았습니다. 프레임워크로 인해 발생한 또 하나의 취약점으로, 위협에 대응해야 하는 기업들에 큰 혼란을 초래하고 있습니다.

따라서 GitHub이 새로운 기능을 도입해 소프트웨어 공급망 보안을 강화하는 모습을 보니 다소 반가웠습니다. 특히 Sonatype의 최신 소프트웨어 공급망 현황 보고서를 읽은 뒤라 더욱 반가웠습니다. 이 보고서에는 역할을 불문하고 보안을 중시하는 기술 전문가라면 누구나 경각심을 가져야 할 통계가 담겨 있었습니다. 특히 주목할 내용은 다음과 같습니다.

• 현재 사용 가능한 OSS 구성 요소 버전은 3,700만 개에 달합니다
• 인기 프로젝트의 29%에는 알려진 보안 취약점이 하나 이상 포함되어 있습니다
• 오픈 소스 공급업체를 겨냥한 사이버 공격이 전년 대비 650% 증가

이러한 조사 결과가 특히 우려스러운 이유는 보고서에서 “현대 애플리케이션에는 평균적으로 128개의 오픈 소스 종속성이 포함되어 있다”고 밝혔기 때문입니다.

자, 제가 계산하는 걸 별로 좋아하지 않는다는 건 아시겠지만, 그래도 한번 계산해 봅시다.

In the 2022년 애플리케이션 전략 현황에서는 주목할 만한 몇 가지 통계를 확인할 수 있습니다:

• 최신 애플리케이션(컨테이너 네이티브 및 모바일)은 기업 애플리케이션 포트폴리오의 평균 33%를 차지합니다.
• 모든 산업 분야의 기업은 평균적으로 약 200개의 애플리케이션으로 구성된 앱 포트폴리오를 유지합니다

따라서 200개의 33%를 계산하면 일반적인 기업은 포트폴리오에 평균 66개의 최신 애플리케이션을 보유하고 있다는 뜻입니다. Sonatype의 평균 오픈 소스 종속성 수를 적용하면, 일반적인 기업은 서로 다른 8,448개의 오픈 소스 종속성을 보호해야 하는 부담을 안고 있을 수 있습니다. 물론 애플리케이션 간에 종속성이 중복될 가능성은 매우 높습니다. 컨테이너 네이티브 앱은 거의 항상 동일한 컨테이너 오케스트레이션 환경을 공유하므로(현재 COE의 최강자는 Kubernetes입니다), 개별 종속성 수 측면에서 실제 부담은 더 적습니다. 하지만 취약점이 발생하면 해당 종속성의 모든 인스턴스를 업데이트해야 한다는 점에서는 부담이 줄어들지 않습니다.

더 이상 계산하지 않더라도, 오늘날 애플리케이션 포트폴리오의 규모와 오픈 소스 종속성의 포함을 고려하면 소프트웨어 공급망을 보호하는 일이 상당한 과제라는 데 모두 동의할 수 있을 것입니다.

GitHub의 새로운 기능은 “현재 풀 리퀘스트의 리치 diff에만 표시되는 취약점을 찾아 차단”함으로써 이 문제를 해결하는 데 도움이 됩니다. 즉, CI/CD 파이프라인에 통합되어 알려진 취약점을 실시간으로 검사합니다.

좋습니다. 그리 특별한 기능은 아닙니다. DevSecOps는 수년간 이러한 유형의 보안 ‘시프트 레프트’를 주도해 왔습니다. 사용하는 도구와 관계없이 대부분의 CI/CD 파이프라인은 코드에 대한 보안 검사를 수행할 수 있습니다. 하지만 종속성 깊숙이 숨어 있거나 쉽게 탐지하기 어려운 논리 오류로 인해 발생한 알려진 취약점까지 검사하는 기능을 통합한 파이프라인은 많지 않습니다.

물론 나중에 뒤통수를 칠 수 있는 취약점과 오류를 근절하려면 CI/CD 파이프라인에 가능한 한 많은 보안 기능을 포함해야 합니다. 하지만 우리가 이 과정을 거친 이유는 그것이 아닙니다.

SRE, 소프트웨어 및 공급망 보안

제가 기존 소프트웨어 공급망의 문제를 지적하는 이유는 조직이 SRE 접근 방식으로 운영을 현대화할수록 이 문제가 더욱 악화될 수밖에 없기 때문입니다. SRE 관행은 본질적으로 자동화에 의존하며, 잘 아시다시피 자동화는 소프트웨어와 스크립트에 의존합니다. 그런데 그중 상당수가—놀랍게도—오픈 소스입니다.

실제로 DevOps에서 사용하는 수많은 오픈 소스 도구를 SRE도 사용한다는 사실은 그리 놀라운 일이 아닙니다. 역할과 관계를 단순화해 설명하자면, SRE는 프로덕션 환경을 위한 DevOps라고 할 수 있습니다. DevOps 실무자는 일반적으로 소프트웨어 빌드 및 릴리스 파이프라인에 집중하는 반면, SRE는 소프트웨어 운영 파이프라인에 집중합니다. 여기에는 애플리케이션뿐만 아니라 애플리케이션 보안 및 전송 서비스, 그리고 플랫폼과 환경(코어, 클라우드, 엣지 등)도 포함됩니다. SRE 담당자의 업무 범위는 IT 스택 전반에 걸쳐 있으므로 소프트웨어 공급망을 보호하는 일이 훨씬 더 어려워집니다.

요컨대 소프트웨어 공급망 보안은 개발, 빌드, 릴리스, 배포, 운영에 이르는 전체 애플리케이션 수명 주기에 영향을 미치므로 모든 조직이 중요하게 고려해야 합니다.

또한 디지털 트랜스포메이션 여정에서 살아남고자 하는 조직이라면 이 문제에 주목해야 합니다. 전 세계 기업에 중대한 변화가 다가오고 있으며, 이는 조직의 핵심인 엔터프라이즈 아키텍처에 영향을 미칩니다.

대부분의 엔터프라이즈 아키텍처는 수십 년 전에 구축되었으며, 리소스는 고정되어 유연하게 변경할 수 없고 데이터 센터가 비즈니스 세계의 중심이라는 전제하에 개발된 프레임워크를 기반으로 합니다.

이제는 그 어느 것도 사실이 아니며, 설령 그렇다 하더라도 비즈니스 역시 달라졌습니다. 오늘날 비즈니스는 점점 더 디지털화되고 있으며, 데이터 기반 프로세스를 갖춘 디지털 비즈니스를 사람 중심 프로세스를 갖춘 물리적 비즈니스를 표현하도록 설계된 아키텍처로는 제대로 나타낼 수 없습니다. 엔터프라이즈 아키텍처를 현대화해야 합니다. 이를 위해 SRE 운영과 같은 새로운 도메인을 통합해야 합니다.

실제로 그렇게 하고 있습니다. 올해 실시한 조사에 따르면, 조직의 37%가 애플리케이션과 운영을 현대화하기 위해 이미 SRE 운영을 도입했으며, 또 다른 40%는 향후 12개월 이내에 도입할 계획입니다. 이는 조직 내에서 이 새로운 역할을 지원할 도구와 스크립트, 소프트웨어와 데이터, 그리고 전체 기술 스택이 필요하다는 의미입니다.

그리고 소프트웨어와 스크립트, 기술 스택에는 공급망과 보안이 뒤따릅니다. 운영을 현대화할 때 반드시 유념해야 할 한 가지는 DevOps를 통해 얻은 교훈입니다. 즉, SRE 관행 역시 상당 부분 동일한 기술 부채와 보안 문제를 초래한다는 것입니다.

다행인 점은 DevOps 및 빌드 프로세스와 달리 SRE 운영이 조직에 새로운 관행으로 자리 잡게 된다는 것입니다. 새로운 관행을 확립한다는 것은 처음부터 보안을 내재화하는 것을 포함해 새로운 운영 방식을 정립한다는 의미입니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물