운영 현대화로의 전환은 소프트웨어 공급망 보안에 대한 필요성을 증가시킬 것입니다.

요즘 소프트웨어 공급망의 보안 측면이 위협받는다는 것은 놀라운 일이 아닙니다. 처음으로 log4j가 뉴스에 보도되자 모든 사람이 소프트웨어 공급망의 널리 퍼져 있는 문제가 되는 취약성을 완화하기 위해 급히 나섰습니다.

최근 Spring4Shell이 우리의 관심을 끌었습니다. 이는 프레임워크에서 발생하는 또 다른 취약성으로, 위협을 해결해야 하는 기업들에게 혼란을 야기하고 있습니다.

그래서 GitHub이 소프트웨어 공급망의 보안을 목표로 하는 새로운 기능을 도입하는 것을 보는 것은 어느 정도 즐거웠습니다. 특히 Sonatype의 최신 소프트웨어 공급망 현황 보고서를 읽고 난 후에는 더욱 즐거웠습니다. 이 보고서에는 역할에 상관없이 보안을 중시하는 모든 기술자가 두려워할 만한 통계가 나와 있었습니다. 주목할 점:

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

이러한 결과는 보고서에서 "평균적인 현대 애플리케이션에는 128개의 오픈 소스 종속성이 포함되어 있다"고 결정했기 때문에 특히 문제가 됩니다.

글쎄요, 제가 수학을 좋아하지 않는다는 건 알겠지만, 한 번 해보겠습니다.

2022년 응용 전략 현황 에서 우리는 주목할 만한 여러 통계를 발견했습니다.

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

따라서 200의 33%는 일반적인 기업이 포트폴리오에 평균 66개의 최신 애플리케이션을 보유하고 있다는 것을 의미합니다. Sonatype의 오픈소스 종속성 평균을 사용하면 평균적인 기업이 8448개의 다양한 오픈소스 종속성을 확보해야 하는 부담을 지고 있을 수 있다는 것을 의미합니다. 이제, 애플리케이션 간에 중복이 거의 확실히 있을 것입니다. 컨테이너 기반 앱은 거의 항상 동일한 컨테이너 오케스트레이션 환경을 공유합니다(현재 COE의 왕은 쿠버네티스입니다). 따라서 특정 종속성 측면에서 부담은 실제로 낮지만 취약성이 발생할 경우 모든 인스턴스를 업데이트해야 한다는 의미는 아닙니다.

더 많은 수학을 하지 않고도 오늘날 소프트웨어 공급망을 보호하는 것이 앱 포트폴리오의 규모와 오픈 소스 종속성을 고려할 때 상당한 작업이라는 데 모두 동의합시다.

GitHub의 새로운 기능은 "현재 풀 리퀘스트의 리치 디프에만 표시되는 취약성을 찾아 차단"함으로써 이 문제를 해결하는 데 도움이 됩니다. 즉, 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 운영은 조직에 새로운 관행이 될 것이라는 것입니다. 새로운 관행을 수립한다는 것은 새로운 운영 방식을 수립한다는 것을 의미합니다. 여기에는 처음부터 보안을 구축하는 것도 포함됩니다.