개요
소프트웨어 공급망 보안은 위험 관리와 사이버 보안 분야의 모범 사례를 결합하여 잠재적 취약점으로부터 소프트웨어 공급망을 보호하도록 지원합니다. 소프트웨어 공급망은 애플리케이션 개발부터 CI/CD 파이프라인 및 배포에 이르는 소프트웨어 개발 라이프사이클(SDLC)에서 코드를 다루는 모든 관련 요소와 관계자로 구성됩니다.
소프트웨어 공급망에는 구성 요소(예: 인프라, 하드웨어, 운영 체제(OS), 클라우드 서비스), 구성 요소 작성자, 구성 요소의 출처(예: 레지스트리, GitHub 리포지토리, 코드베이스, 기타 오픈소스 프로젝트)와 같은 소프트웨어에 관한 정보의 네트워크들이 포함됩니다. 아울러 소프트웨어 공급망에는 소프트웨어 보안에 부정적인 영향을 끼칠 수 있는 취약점도 포함되므로 소프트웨어 공급망 보안이 필요합니다.
소프트웨어 공급망 보안이 중요한 이유
오늘날 대부분의 소프트웨어는 완전히 처음부터 작성된 것이 없고, 주로 오픈소스 소프트웨어가 포함된 소프트웨어 아티팩트들이 결합되어 있습니다. 그런데 이러한 소프트웨어 아티팩트는 취약점의 영향을 받기가 쉽고, 개발자는 타사의 소스 코드나 시간의 경과에 따른 소프트웨어 아티팩트의 변경 사항에 대한 제어 권한이 부족합니다. 패치가 적용되지 않은 소프트웨어는 보안 문제에 더 취약하다는 점을 명심해야 합니다. 소프트웨어는 일상적인 비즈니스 운영을 실행하는 데 반드시 필요하므로 공급망 보안은 모든 조직과 보안 팀에게 있어 매우 중요한 책임입니다.
2020년 소프트웨어 기업 솔라윈즈(SolarWinds)는 해커가 대기업과 정부 기관에서 사용 중인 SolarWinds 플랫폼인 Orion IT 모니터링 및 관리 소프트웨어를 통해 악성 코드를 설치하는 보안 침해 사태를 겪었습니다. 해커는 공급망을 공격하여 SolarWinds뿐만 아니라 SolarWinds 고객까지 침투했습니다. Log4j는 흔히 사용되지만 광범위하게 익스플로잇될 수 있는 오픈소스 소프트웨어로, 수많은 사용자와 조직을 데이터 침해와 공격에 대해 무방비 상태에 빠트렸습니다. 2021년 미국 대통령은 공급망과 사이버 보안 등에 대한 2가지 백악관 행정명령을 내리며 소프트웨어 공급망과 보안의 중요성을 강조했습니다.
Red Hat 리소스
소프트웨어 공급망에 대한 보안 리스크
소프트웨어 공급망의 구성 요소에 리스크가 있다는 것은 그러한 공급망 구성 요소를 사용하는 모든 소프트웨어 아티팩트에도 잠재적 리스크가 있다는 것을 의미합니다. 이러한 보안 리스크는 해커에게 맬웨어, 백도어 또는 기타 악성 코드를 삽입해 구성 요소 및 그와 연결된 공급망을 손상시킬 수 있는 기회를 허용합니다. 주로 금전적 이익을 노리는 해커와 국가 배후의 해커가 저지르는 소프트웨어 공급망 공격이 증가하고 있으며 이는 디지털 환경과 물리적 환경 모두에 엄청난 영향을 미칠 수 있습니다. 이러한 공격은 일반적으로 다음 네 가지 리스크 유형 중 하나로 분류됩니다.
- 취약점: 소프트웨어 코드의 결함으로, 악용 시 보안 침해를 야기할 수 있습니다. 소프트웨어 아티팩트에 패치를 적용하고 업데이트를 수행하여 리스크를 최소화하세요.
- 라이센싱: 발생되는 소프트웨어 아티팩트를 오픈소스로 만들고 특허권을 무효화하도록 강요할 수 있는 법적 리스크입니다. 법률 전문가와 상담이 필요한 영역입니다.
- 타사 종속성: 소프트웨어 공급망에 속한 외부 조직에 대한 종속성으로, 파악이 어렵습니다. 모든 타사 코드를 분석하고 보안 방식과 관련해 공급업체와 상담하세요.
- 프로세스 및 정책: 미흡할 경우 문제가 됩니다. 개발자를 위한 정책과 취약점 대응을 위한 프로세스(또는 플레이북)를 수립하세요.
일반적인 공격 벡터로는 업데이트 하이재킹, 코드 서명 훼손, 오픈소스 코드 손상 등이 있습니다.
DevSecOps 및 소프트웨어 보안
DevSecOps는 전체 IT 라이프사이클에 걸쳐 보안을 공동의 책임으로 통합하는 문화, 자동화 및 소프트웨어 설계에 대한 접근 방식입니다. DevSecOps는 처음부터 애플리케이션과 인프라 보안을 고려해야 함을 의미합니다. 또한 DevOps 워크플로우가 느려지지 않도록 일부 보안 게이트를 자동화해야 한다는 의미이기도 합니다. 보안 기능을 갖춘 통합 개발 환경(Integrated Development Environment, IDE) 사용에 동의하는 등 지속적인 보안 통합을 위한 적합한 툴을 선택하면 이러한 목표 달성에 도움이 될 수 있습니다.
Red Hat Advanced Cluster Security for Kubernetes는 소프트웨어 공급망과 개발자 워크플로우에 보안 점검을 통합하여 고위험 보안 문제를 감지하고 해결하는 데 도움을 줍니다. 또한 개발자에게 기존 워크플로우에서 보안 컨텍스트를 제공하여 DevOps에서 보안을 자동화합니다.
소프트웨어 공급망 보안과 애플리케이션 보안 비교
소프트웨어 공급망은 코드를 다루는 모든 관련 요소와 관계자로 구성되어 있는 반면, 애플리케이션 보안은 코드 자체를 공격과 취약점으로부터 보호합니다. 소프트웨어 공급망 보안과 마찬가지로 애플리케이션 보안은 개발의 모든 단계에 적용되어야 합니다.
애플리케이션 보안은 소프트웨어 개발 라이프사이클에서 시작되어 시스템에 대한 무단 액세스를 차단하고 상용 데이터를 보호하기 위해 애플리케이션 라이프사이클 전반으로 확장됩니다. 공급망의 무결성을 강화하면 결과적으로 애플리케이션 보안을 향상할 수 있습니다. 구성을 강화하고, 공격 표면을 최소화하고, 권한을 제한하고, 소프트웨어에 서명하고, 시스템의 여러 부분으로 빌드를 배포하는 것은 모두 애플리케이션에 대한 공격을 방지하는 방법에 해당합니다.
소프트웨어 공급망 위협 완화
소프트웨어 공급망 보안은 조직, 조직의 고객, 그리고 오픈소스 기여에 의존하는 모든 조직에 중요합니다. 보안 침해를 당하고 싶어 하는 조직도 없지만 다른 조직이 유사한 이벤트에 노출되는 데 대한 책임을 지는 것을 원하는 조직도 없습니다. 따라서 소프트웨어 공급망을 보호하는 것이 중요합니다.
다음은 보안 팀이 고려해야 할 몇 가지 보안 모범 사례입니다.
- 공급망 전반에서 리소스(예: 개발자 툴, 소스 코드 리포지토리, 기타 소프트웨어 시스템)에 대한 최소한의 권한 액세스만 제공하고, 다단계 인증을 활성화하고, 강력한 비밀번호를 사용.
- 직원을 위한 보안 교육을 정기적으로 제공.
- 연결된 모든 기기와 중요 데이터의 보안 강화.
- 티어 1 공급업체부터 시작하여 공급업체와 비즈니스 협력업체 파악. 리스크 평가를 수행하여 각 공급업체의 사이버 보안 태세와 취약점에 대한 공공 정책 평가.
- 취약한 시스템에 대해 스캔과 패치 적용을 정기적으로 실시.
아울러 개발자는 lock 파일을 사용하는 보안 코딩 사례와 기타 보안 중심의 이니셔티브를 고려해야 합니다.
- 체크섬 검증
- 벤더 종속성을 소스 제어에 포함
- SBOM(Software Bill of Material) 게시 및 사용
- 다음을 포함하는 SLSA(Supply-chain Levels for Software Artifacts, 소프트웨어 아티팩트를 위한 공급망 수준) 채택
- 출처 인증을 위해 소프트웨어 아티팩트에 디지털 기술로 서명하는 기능
- 프로세스 및 정책에 자동화 활용
- 소프트웨어 구성 분석(Software Composition Analysis, SCA), 정적 애플리케이션 보안 테스트(Static Application Security Testing, SAST), 동적 애플리케이션 보안 테스트(Dynamic Application Security Testing, DAST) 등과 같은 자동화된 보안 테스트 툴로 소프트웨어 스캔
Red Hat을 선택해야 하는 이유
Red Hat은 소프트웨어 개발 라이프사이클 초기에 소프트웨어 구성 요소와 종속성을 보호해야 하는 필요성을 알고 DevSecOps 사례를 사용하여 모든 단계에서 보안 통합을 자동화합니다. Red Hat이 업스트림 공급망을 이해하고, 1년 365일 믿고 맡길 수 있는 제품을 제공해 드립니다. Red Hat과 파트너는 전문 지식, 통합 DevSecOps 에코시스템, 그리고 조직이 소프트웨어 개발 라이프사이클 전반에 소프트웨어 공급망 보안을 구현할 수 있도록 지원하는 역량을 제공합니다.
레드햇 공식 블로그
레드햇 공식 블로그에서 고객, 파트너, 커뮤니티 에코시스템 등 현재 화제가 되는 최신 정보를 살펴 보세요.
