Offcanvas

CSO / 보안 / 비즈니스|경제 / 애플리케이션

CIO의 새로운 보안 미션, ‘소프트웨어 공급망’을 지켜라

2022.11.07 Mary Branscombe  |  CIO
오픈소스가 기업에서 인기 있는 이유 중 하나는 정교한 애플리케이션 및 서비스의 개발 속도를 높이는 검증된 구성 요소를 제공하기 때문이다. 하지만 서드파티 소프트웨어 구성 요소, 패키지, 컨테이너의 편리함은 위험도 수반한다. 구축하는 애플리케이션의 보안이 이러한 종속성에 달려 있어서다. 

소프트웨어 공급망 공격은 가트너가 이를 2022년에 두 번째로 큰 위협이라고 꼽을 만큼 광범위해지고 있다. 가트너에 따르면 2025년까지 전 세계 기업의 45%가 소프트웨어 공급망 공격을 한 번 이상 겪게 되리라 예측됐으며, CIO의 82%는 (소속 기업이) 이러한 공격에 취약할 것이라고 말했다. 여기에는 널리 사용되고 있는 소프트웨어 구성 요소의 취약점(예: 로그4j 등)을 통한 공격, 빌드 파이프라인 공격(예: 솔라윈즈(SolarWinds), 카세야(Kaseya), 코드코브(Codecov) 해킹 등), 패키지 저장소 해킹 등이 포함된다.

사이코드(Cycode)의 CEO 라이어 레비는 “공격자의 우선순위가 프로덕션 환경에서 소프트웨어 공급망으로 바뀌었다. 소프트웨어 공급망이 가장 취약한 고리이기 때문”이라며, “소프트웨어 공급망이 비교적 쉬운 표적으로 남아 있는 한 소프트웨어 공급망 공격은 증가할 것”이라고 전했다.
 
ⓒGetty Images Bank

아쿠아 시큐리티(Aqua Security)의 전략 부문 수석 부사장 라니 오스냇은 “최근 세간의 이목을 끈 사건들이 소프트웨어 개발 업계에 경종을 울렸다. (업계는) 수십 년의 불투명성과 투명성의 부재를 발견했다”라고 언급했다. 

오픈소스 코드를 사용하는 코드베이스를 조사한 결과 취약점 그리고 구식 또는 방치된 구성 요소가 흔했다. 코드베이스의 81%는 1개 이상의 취약점이, 50%는 1개 이상의 고위험 취약점이 있었고, 88%는 최신 버전이 아니거나 2년 동안 새로 개발되지 않은 구성 요소를 사용했다.

하지만 이러한 문제 때문에 오픈소스의 인기에 흠집이 날 가능성은 작으며, (무엇보다) 상용 소프트웨어와 서비스도 취약하긴 마찬가지다. 지난 8월 (암호 관리 서비스) 라스트패스(LastPass)가 해킹을 당했다. 회사에 따르면 고객 데이터는 손실되지 않았지만 공격자는 소스 코드 일부를 가져갔다. 이를 통해 향후 라스트패스의 사용자를 더 쉽게 공격할 수 있다. 아울러 트윌리오(Twilio) 해킹으로 공격자는 다운스트림 조직에 공급망 공격을 개시할 수도 있을 것이다.

‘섀도우 코드(Shadow Code)’ 위협
보안팀이 네트워크 해킹을 가정하고 방어하는 것처럼 CIO도 내부 또는 외부의 모든 코드, 심지어는 개발자가 쓰는 개발 환경 및 도구가 이미 해킹됐다고 가정한 채 소프트웨어 공급망 공격을 방어하고 피해를 최소화하기 위한 정책을 마련해야 한다.

오스냇은 CIO가 섀도우 IT(Shadow IT; 직원들이 IT 부서에서 승인하지 않은 하드웨어 및 소프트웨어를 구매하고, 이를 IT 부서에서 파악하지 못하는 현상)와 마찬가지로 ‘섀도우 코드’를 고려해야 한다고 권고했다. 그는 “단순한 보안 문제가 아니다. 오픈소스이든 상용이든 소프트웨어를 확보하는 방식, 즉 이를 환경에 적용하는 방식, 업데이트하는 방식, 구축하고 싶은 제어 종류, 공급업체에 요구하려는 제어 종류를 심층적으로 다루는 것”이라고 설명했다.

투명성: SBOM(Software Bill Of Material)을 향해
물리적 공급망은 이미 라벨, 성분 목록, 안전 데이터 시트, 자재 명세서(BOM)를 사용하기 때문에 규제기관과 소비자는 최종 제품이 무엇인지 알 수 있다. 새로운 이니셔티브의 목표는 소프트웨어에 유사한 접근 방식을 적용하여 기업들이 소프트웨어 개발 프로세스의 종속성 웹과 공격 표면을 이해하도록 하는 것이다.

소프트웨어 공급망 보안에 관한 美 백악관의 행정 명령(14028)에 따르면 연방정부에 (제품을) 공급하는 소프트웨어 업체는 ‘SBOM’을 제공하고, 아울러 ‘SLSA(Supply chain Levels for Software Artifacts)’ 보안 체크리스트를 사용하여 변조를 방지해야 한다. 

포레스터의 수석 애널리스트 자넷 워싱턴은 “이 때문에 많은 기업이 소프트웨어 공급망을 훨씬 더 진지하게 살펴보고 있다. 오늘날 모든 기업이 소프트웨어를 생산하고 소비한다. 이에 많은 생산업체가 ‘SBOM으로 증명할 수 있는 안전한 소프트웨어를 어떻게 생산할 수 있을까?’를 이야기하고 있다”라고 말했다.

이와 관련해 다양한 산업 간 프로젝트가 존재하며, 이를테면 NIST의 NIICS(National Initiative for Improving Cybersecurity in Supply Chains), 마이크로소프트 및 IETF 회원의 SCITT(Supply Chain Integrity, Transparency) 이니셔티브, 오픈SSF 공급망 무결성 워킹 그룹(OpenSSF Supply Chain Integrity Working Group) 등이 있다. 워싱턴은 “모두가 총체적인 접근 방식을 취하고 있으며, ‘소프트웨어를 개발하는 공급망에 무엇을 가져와야 하는지 파악해야 한다’라고 말하고 있다”라고 덧붙였다. 

최근 리눅스 재단(Linux Foundation)의 설문조사 결과 SBOM에 관한 인식이 높은 것으로 나타났다. IT 공급업체, 서비스 제공업체, 규제가 엄격한 산업의 47%가 현재 SBOM을 사용하고 있으며, 88%는 2023년에 사용할 예정이라고 밝혔다. 

SBOM은 이미 소프트웨어 구성 요소 및 API 자산을 관리하고 있는 기업에 가장 유용하다. 워싱턴은 “현재 탄탄한 소프트웨어 개발 프로세스가 있는 곳은 SBOM을 생성할 수 있는 도구를 더 쉽게 마련할 수 있다”라고 전했다.

SBOM은 빌드 시스템에서 생성하거나 또는 사후에 소프트웨어 구성 분석 도구로 생성할 수 있다. 많은 도구가 CI/CD 파이프라인에 통합돼 빌드의 일환으로 실행되거나 또는 라이브러리를 풀다운(Pull Down)할 때 실행할 수 있다는 게 그의 설명이다. 워싱턴은 “이렇게 하면 ‘해당 구성 요소가 파이프라인에 있는데 심각한 문제가 있다. 계속하겠는가?’라는 경고를 받을 수 있다”라고 덧붙였다. 

체인가드(Chainguard)의 CEO 댄 로랑은 이것이 유용하려면 개발자 팀이 오픈소스 소프트웨어를 확보하는 방식에 명확한 정책이 필요하다고 말했다. “개발자가 기업의 정책상 ‘안전’하다고 간주되는 사항을 어떻게 알 수 있을까? 또 오늘날 개발자가 쓰는 모든 소프트웨어의 대부분을 차지하는 오픈소스가 실제로 변조되지 않았는지 어떻게 알 수 있을까?”라고 전했다. 

그는 자바스크립트, 자바, 쿠버네티스, 파이썬이 소프트웨어 패키지 출처를 설정하는 데 쓰는 오픈소스 시그스토어(Sigstore) 프로젝트를 언급했다. “시그스토어는 웹사이트 인증서처럼 소프트웨어 무결성을 위한 것이다. 기본적으로 일련의 관리 및 신뢰 검증 시스템을 구축한다”라고 설명했다.

“CIO는 먼저 개발팀을 대상으로 새로운 산업 표준 접근법을 사용하여 빌드 시스템을 잠그는 기본 단계를 주입하는 것부터 시작해야 한다. 그다음 소프트웨어 구성 요소를 환경으로 가져오기 전에 신뢰성을 검증하는 반복 가능한 방법을 만들어야 한다”라고 로랑은 말했다. 

기여하기
구성 요소, API, 서버리스 기능과 관계없이 대부분의 기업은 일상적인 인벤토리를 실행하지 않는 한 현재 사용하고 있는 것을 과소평가한다고 워싱턴은 지적했다. 그는 “이러한 API 중 일부가 적절한 인증 방법을 사용하지 않거나 예상한 방식대로 작성되지 않았으며, 또 일부는 더 이상 사용되지 않는다”라고 말했다.

취약점 외에 커뮤니티의 패키지 지원을 평가하는 것은 코드의 기능을 이해하는 것만큼 중요하다. 모든 유지관리자가 코드를 중요한 리소스로 취급해야 하는 부담을 원치 않기 때문이다. 그는 “물론 모든 오픈소스가 동일하게 만들어지는 건 아니다”라고 언급했다.

“오픈소스는 무료로 다운로드할 수 있지만 이를 사용하는 것은 확실히 무료가 아니다. 이를 사용하면 (오픈소스가) 자신의 공급망 내에 위치한다는 점에서 그 이면의 보안 태세를 이해해야 한다는 것을 의미한다. 따라서 (오픈소스에) 다시 기여할 필요가 있다. 개발자는 취약점 해결에 참여해야 한다”라면서, “오픈소스 프로젝트에 직접 또는 (이를) 리소스와 자금으로 지원하는 이니셔티브에 금전적으로 기여할 준비도 해야 한다. 오픈소스 전략을 수립할 때, 그중 일부는 예산과 의미를 파악하는 것이다”라고 워싱턴은 권고했다. 

다시 말해, 이를 단순히 비용으로 여기지 말고 의존하는 구성 요소를 더욱더 제대로 파악할 기회로 여겨야 한다. “심지어는 개발자가 커뮤니티에 참여하면서 (이를 통해) 개발자를 유지하는 데 도움이 될 수 있다. 개발자는 자신의 스킬을 강화할 수 있고, 이를 이력서에 사용할 수 있다”라고 그는 덧붙였다.

취약점은 기술 스택의 어디에서나 발견할 수 있다. 여기에는 워크로드의 일부로 리눅스와 오픈소스를 점점 더 많이 실행하지만 다른 환경에서 흔히 찾아볼 수 있는 보안 프로세스와 프레임워크가 부족한 메인프레임도 포함된다. 

파이프라인 보호하기
소프트웨어 딜리버리 파이프라인을 보호하는 것도 중요하다. NIST의 SSDF(Secure Software Development Framework)와 SLSA는 좋은 출발점이다. 여기에는 간단한 빌드 시스템부터 시작하여 감사 및 인시던트 대응을 위해 로그와 메타데이터를 사용하는 안전한 빌드 파이프라인까지 다양한 성숙도 수준의 모범 사례가 포함된다. CNCF의 소프트웨어 공급망 보안 모범 사례(Software Supply Chain Best Practices) 백서, 가트너의 소프트웨어 공급망 보안 위험 완화 지침, 마이크로소프트의 OSS 보안 공급망 프레임워크(OSS Secure Supply Chain Framework) 등도 살펴볼 만하다.

하지만 악성 코드를 찾기 위해 자동화된 스캔 도구를 켜는 것만으로는 너무 많은 오탐이 생성될 수도 있다. 그리고 비트버켓(BitBucket), 깃허브(GitHub), 깃랩(GitLab) 등의 버전 관리 시스템에는 보안 및 액세스 보호 기능(예: 점차 세분화되는 액세스 정책 관리, 브랜치 보호, 코드 서명, 모든 기여자를 대상으로 한 MFA 요구, 비밀번호 및 자격 증명 스캔 등)이 포함돼 있지만 명시적으로 활성화해야 하는 경우가 많다.

또 단일 스택에서 SLSA를 구축하여 빌드 파이프라인을 보호하는 FRSCA(Factory for Repeatable Secure Creation of Artifacts) 등의 프로젝트는 아직 프로덕션 준비가 되지 않았다. 하지만 CIO는 빌드 시스템에 앞으로 이러한 사례가 더 많이 포함되리라 예상해야 한다.

실제로 SBOM은 해답의 일부에 불과하며 이를 생성하고 사용하기 위한 도구도, 아울러 (이를) 요청하고 소비하기 위한 프로세스도 아직 성숙 단계에 있다. 워싱턴은 계약에는 SBOM을 원한다는 것뿐만 아니라 예상하는 업데이트 주기 그리고 취약점 보고서 및 알림 포함 여부를 명시해야 한다고 조언했다. 그는 “로그4j와 같은 중요한 취약점이 발견되면 공급업체가 알려주는가, 아니면 기업이 직접 SBOM에서 검색하여 영향을 받는지 파악해야 하는가?”라고 말했다. 

또한 기업들은 SBOM을 읽는 도구 그리고 이러한 도구가 찾은 항목에 관해 조치를 취하는 프로세스를 마련해야 한다. 워싱턴은 “[SBOM에서] 알려진 취약점이 무엇인지, 라이선스에 어떤 영향을 미치는지, 계속해서 발생하는지 알려줄 수 있는 도구가 필요하다”라고 전했다.

오스냇은 “CIO가 명심해야 할 사항이 있다. SBOM은 조력자이지만 실제로 공급망 보안 측면에서 어떤 문제도 해결하지 못한다는 점을 염두에 둬야 한다. 일어날 수 있는 사건에 대처하는 데 도움이 된다”라며, “업계의 대응 속도 그리고 SBOM 및 코드 증명 표준을 중심으로 하는 광범위한 협업 모두 도구의 상호운용성을 지원한다. 이는 SOC 2가 제공했던 산업 전반의 투명성 및 보고 기준의 동일한 개선으로 이어질 수 있다”라고 전했다. 

그렇지만 CIO는 품질만큼 보안을 개발자 역할의 일부로 만드는 새로운 표준이나 도구를 기다릴 필요가 없다고 오스냇은 언급했다. 그는 “먼저 CISO와 수석 엔지니어를 소집해 기업에 적합한 모델이 무엇인지 그리고 이러한 변화가 어떻게 일어날지 파악하라”라고 조언했다. ciokr@idg.co.kr
 
추천 테크라이브러리

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.