Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
개발자 / 보안 / 오픈소스

"개발자에 좋은 것은 해커에게도 좋다" 오픈소스 SW 공급망 보안 문제의 해법

Dan Lorenc | InfoWorld 2022.07.22
소프트웨어 공급망 보안에 대한 권한은 누가 가져야 할까? 개발자 혹은 개발자를 지원하는 플랫폼과 보안 엔지니어링 팀? 과거에는 기업의 지원 계약 및 보안 서비스수준협약(SLA)을 어느 리눅스 배포판과 운영체제, 인프라 플랫폼으로부터 확보할지를 CIO, CISO, 또는 CTO와 담당 보안팀이 결정하곤 했다. 하지만 이후 개발자가 이 모든 일을 도커 파일(Docker Files)과 깃허브 액션(GitHub Actions)에서 처리하게 됐다. 개발자에게 상황이 ‘시프트 레프트(shift left)’했고 이전과 같은 기업 차원의 감독은 사라졌다.
 
ⓒ Getty Images Bank

오늘날에는 규정 준수 및 보안 팀이 이런 정책과 요건을 규정한다. 개발자는 이 요건을 준수하는 범주 내에서 원하는 도구를 선택할 유연성을 갖는다. 이처럼 업무가 구분되면 개발자 생산성에 가속도가 크게 붙는다.

그러나 Log4j 사태는 기업의 시스템 보안 문제에 대한 경종을 울렸다. 시프트 레프트 개발자 자율성과 생산성의 장점에도 불구하고 소프트웨어 공급망을 이루는 오픈소스 구성요소는 악성 행위자가 노리는 새로운 표적이 되고 말았다.
 

오픈소스는 개발자와 공격자 모두에게 좋다

네트워크 보안은 공격자 입장에서 예전보다 훨씬 더 어려운 공격 벡터가 됐다. 반면 오픈소스라면? 오픈소스 의존성 또는 라이브러리를 찾아 개입한 후 다른 모든 의존성으로 방향을 전환하면 그만이다. 공급망은 기업과 기업의 소프트웨어 산출물 사이의 연결 고리가 중요하다. 오늘날 공격자는 바로 이 부분을 집중적으로 공략하고 있다. 기본적으로 개발자 입장에서 오픈소스 소프트웨어의 장점은 공격자 입장에서도 장점이다.

개방성 : 개발자는 ‘누구나 코드를 볼 수 있고 누구나 코드에 기여할 수 있다’는 점을 좋아한다. 리누스 토발스의 말처럼 “지켜보는 눈이 많으면 모든 버그는 잡아내기 쉬워지고” 이는 오픈소스의 큰 장점이다.

반면 공격자는 ‘깃허브 계정이 있는 사람이라면 누구나 필수 라이브러리에 코드에 기여할 수 있다’는 점을 대단히 좋아한다. 악성 코드 커밋은 자주 발생한다. 만인의 이익은 안중에도 없는 소유자에게 라이브러리가 접수돼 넘어간다. 유명한 사례가 '위대한 중지자(The Great Suspender)'라는 크롬 플러그인이었다. 관리자가 이 플러그인을 다른 사람에게 넘겼고 그는 즉시 악성코드에 플러그인하기 시작했다. 이처럼 호의적인 기여자가 악의적인 기여자로 변한 사례는 많다.

투명성 : 개발자는 ‘문제가 있을 때 직접 소스를 살펴 코드 감사를 할 수 있다’는 점을 좋아한다. 반면 공격자는 ‘오픈소스는 분량이 방대해서 코드 감사가 현실적으로 불가능하다’는 점을 대단히 좋아한다. 게다가, 코드의 많은 부분이 실제 사용되는 방식과는 다른 소스로 배포된다. 예를 들어, 파이썬(Python)이나 노드.js(Node.js) 패키지에 대한 소스 코드를 보면, pip install 또는 npm install을 실행했을 때 컴파일된 것에서 온 패키지를 잡게 되는데, 이 패키지가 실제로 사용자가 감사한 소스 코드에서 왔다는 보장이 없다.

소스 코드 활용 방식에 따라 다르지만 실제로 소스 코드를 매번 처음부터 컴파일하는 것이 아니라면 투명성 중 많은 부분은 착각일 수 있다. 유명한 사례는 코드코브(Codecov) 침해다. 인스톨러였던 배시(bash) 스크립트가 해킹돼 정보를 빼내는 악성코드가 주입된 상태였다. 이는 조작 가능한 다른 빌드에 대한 취약점으로도 악용됐다.

무료 : 개발자가 오픈소스를 대단히 좋아하는 것은 다른 사람이 작성한 코드를 자유롭게 사용하도록 보장하는 라이선스와 함께 제공되기 때문이다. 이는 매우 훌륭한 방식이다. 기업이 내부적으로 개선된 소프트웨어를 얻기 위해 조달 과정을 거처야 하는 것보다 훨씬 쉽다. 반면 공격자에게 이는 무료에 이끌려 오픈소스를 사용하는 수없이 많은 표적이 있다는 의미다. 실제로 2014년에 발생한 하트블리드(Heartbleed) 공격은 인터넷의 필수 인프라 중 얼마나 많은 부분이 무료인 오픈소스를 바탕으로 운영되는지 보여주며 경종을 울린 첫 번째 사례였다.

Jwt-go라는 고랭(Golang) 라이브러리도 있었다. 전체 고랭 생태계(쿠버네티스 포함)에 걸쳐 사용된 인기 높은 라이브러리였지만, 내부에 취약점이 발견되었을 때 해결책을 제공할 관리자가 이미 떠나고 없어 혼란이 발생했다. 사람들은 버그 해결을 위해 다양한 패치를 내놓았고 한때는 똑같은 버그에 대여섯 가지 패치 버전이 경쟁하기도 했다. 마침내 하나의 패치가 등장해 취약점을 종결시켰다.
 

오픈소스는 소프트웨어 공급망 보안에도 대단히 좋다

이 모든 연결 고리를 강화할 유일한 방법은 협력이다. 커뮤니티야말로 우리가 가진 최대의 강점이다. 업계 전체와 만인의 공급망 내 곳곳에 오픈소스가 스며든 것은 어쨌든 오픈소스 커뮤니티(시간과 노력을 들이고 코드를 공유한 모든 프로젝트 관리자) 덕분이다. 우리는 바로 그 커뮤니티를 활용해 그 공급망의 안전을 확보할 수 있다.

개발자든 플랫폼 또는 보안 엔지니어링팀의 일원이든 이러한 소프트웨어 공급망 보안 분야의 발전 상황에 관심이 있는 사람이 주목해야 할 오픈소스 프로젝트를 소개한다.
 
  • SLSA : SLSA(소프트웨어 산출물을 위한 공급망 수준(Supply chain Levels for Software Artifacts)의 줄인 말로 “살사”라고 읽음)는 규범적이고 진보적인 빌드 시스템 보안 요건이다. 1단계는 빌드 시스템을 사용하는 것이다(노트북에서 손으로 하면 안 된다). 2단계는 로그와 메타데이터를 내보내는 것이고(그래야 나중에 검색과 사건 대응을 할 수 있다), 3단계는 일련의 모범 사례를 따르는 것이다. 4단계는 실제로 안전한 빌드 시스템을 사용하는 것이다.
  • 테크톤(Tekton) : 테크톤은 보안을 염두에 두고 설계된 오픈소스 빌드 시스템이다. 많은 빌드 시스템을 안전한 방식으로 실행할 수 있다. 테크톤은 SLSA가 내장된 준수한 기본 제품의 대표적인 사례다. 
  • 인토토(In-Toto) : 인토토와 다음에 소개하는 TUF는 모두 소프트웨어 공급망 보안이 거론되기 시작하기 한참 전에 뉴욕대학교(NYU) 연구실에서 탄생했다. 공급망 도중에 발생하는 이슈를 기록하고 정책에 따라 검증할 수 있는 암호화 체인을 적용한다. 인토토는 빌드 쪽에 집중하고 TUF는 배포 쪽에 집중한다.
  • TUF : TUF(업데이트 프레임워크)는 자동 업데이트 시스템, 패키지 관리자, 배포, 정족수를 통해 승인되는 관리자 집합을 처리한다. TUF도 안 좋은 일이 발생할 때 암호화 키 복구를 전문으로 한다.
  • 시그스토어(Sigstore) : 시그스토어는 오픈소스 소프트웨어 산출물을 위한 무료이자 손쉬운 코드 승인 프레임워크다. 승인은 암호학적으로 검증 가능한 관리 연속성, 즉, 조작되지 않은 소프트웨어 출처 기록을 확립하는 수단이다. 
 

소프트웨어 공급망을 위한 더 개선된 보호장치

지난 10년 동안 도구와 보안의 선택이 모두 개발자에게 ‘시프트 레프트’됐다. 앞으로도 개발자가 사용할 최고의 도구를 선택하는 데 계속 자율성을 유지할 가능성이 크다. 단, 보안 태세와 관련 정책을 관리할 책임은 원상 복귀(‘시프트 라이트’)할 필요가 있다.

흔히 오해하는 것처럼 보안팀이 보안 버그를 찾아내고 취약점을 없애기 위해 온종일 코드를 한줄 한줄 검토한다는 것은 실제와 전혀 다르다. 보안팀은 개발팀에 비해 규모가 훨씬 작다. 보안팀의 존재 이유는 프로세스를 수립하고, 개발자가 마땅히 해야 할 일을 하도록 돕고, 한 번에 보안 버그 하나씩이 아니라 취약점 부류 전체를 제거하는 것이다. 이 방법으로만 보안팀이 엔지니어 수백 명으로 구성된 개발팀을 따라잡을 수 있다.

보안팀은 소프트웨어 산출물에 대한 신뢰의 근원을 확보할 표준 프로세스가 필요하고, 개발자는 명확히 규정된 보안 정책을 대상으로 오픈소스 선택의 균형을 맞출 확실한 경로가 필요하다. 오픈소스는 종종 문제를 일으켰지만 결국은 그 해답을 찾는 데 도움을 줄 것이다. 언젠가는 개발자가 알려진 취약점을 예방하기 위해 점검을 거친 이미지만 배포하게 될 것이다. 
editor@itworld.co.kr
 Tags 오픈소스 보안
Sponsored

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

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

Copyright © 2022 International Data Group. All rights reserved.