"위험의 선행 지표를 살펴라" 오픈소스 소프트웨어의 10가지 위험과 완화 대책

최근 XZ 파일 압축/압축 해제에 사용되는 XZ 유틸즈(XZ Utils)에서 백도어가 발견되면서 OSS의 보안 및 사용 방식을 점검해야 할 필요성이 커지고 있다. 오픈소스 소프트웨어(Open Source Software, OSS)는 최신 소프트웨어 개발의 기반이 되지만, 공급망의 취약한 고리가 될 수 있다.
 

XZ 유틸즈의 백도어가 제때 발견되지 않았다면 오늘날 파급력이 가장 큰 소프트웨어 공급망 침해 사고가 됐을 수 있다. XZ 유틸즈 백도어는 Log4j처럼 광범위하게 악용되지는 않았지만, 현대의 디지털 생태계가 매우 취약하며 OSS를 소비하고 보호하는 방식을 성숙시켜야 한다는 경각심을 일깨운다. 

OWASP(Open Web Application Security Project)의 OSS 상위 10가지 위험(Top 10 Risks for Open Source Software)과 같은 사이버보안 실무자를 위한 리소스와 지침은 이런 사건에 대응하며 조금씩 발전하고 있다. OWASP가 선정한 상위 10가지 위험은 원래 소프트웨어 공급망 및 애플리케이션 보안 업체인 엔돌 랩스(Endor Labs)에서 OSS 및 CI/CD 파이프라인의 안전한 소비와 취약점 관리에 중점을 두고 만들었다. 해당 프로젝트에는 팔로알토, 해시코프, 씨티뱅크와 같은 업계 리더의 지원이 포함됐다. 

전통적인 취약점 관리 방법은 흔히 CVE(Common Vulerabliity and Exposures) 데이터베이스에 포함된 알려진 취약점을 살펴보는 것이다. 하지만 알려진 취약점은 위험의 후행 지표라는 인식이 점점 확산하고 있다. 

성숙한 오픈소스 사용 문화를 위해서는 특정 OSS 라이브러리, 구성 요소 및 프로젝트와 관련된 위험이 있음을 알려줄 수 있는 위험의 선행 지표를 살펴보는 패러다임의 전환이 필요하다. 이는 전반적으로 OSS를 보다 안전하게 사용하고 익스플로잇 및 취약점으로 이어지는 잠재적 위험을 완화하는 데 도움이 된다.

다음은 OWASP가 꼽은 상위 10가지 OSS 위험과 완화 대책이다. 

 

1. 알려진 취약점

OSS 구성 요소에는 알려진 취약점이 포함될 수 있다. 이런 취약점은 소프트웨어 개발자와 유지보수 관리자가 실수로 도입했다가 이후 커뮤니티의 보안 연구자가 발견하고 공개하는 경우가 많다. 이런 취약점은 기업 및 애플리케이션에서 사용되는 컨텍스트에 따라 악용될 수 있다. 사소해 보일지라도 개발자에게 컨텍스트를 제공하지 않으면 상당한 수고와 시간 낭비, 좌절을 초래할 수 있다. 

문제 해결을 위해 CISA의 KEV(Known Exploited Vulnerability) 목록이나 EPSS(Exploit Prediction Scoring System)를 살펴보는 것이 도움이 된다. 기업은 사용하는 모든 OSS 구성 요소에서 알려진 취약점을 스캔하고, 발견 우선순위를 정하는 등의 완화 조치를 취할 수 있다. 우선순위는 알려진 악용 사례, 악용될 확률, 도달 가능성 분석(노이즈 발견을 최대 80%까지 줄일 수 있다) 등의 방법을 기반으로 정할 수 있다. 

2. 합법적인 패키지의 손상

악의적인 공격자는 합법적인 패키지를 손상시켜 조직적으로 혹은 개인적으로 다운스트림 소비자에게 영향을 줄 수 있다는 점을 잘 인지하고 있다. 따라서 프로젝트 관리자 계정을 탈취하거나 패키지 리포지토리의 취약점을 악용하는 등 다양한 방법으로 이런 공격 벡터를 악용한다. 혹은 악의적인 의도를 품고 프로젝트 관리자에 자원하는 경우도 있다. 최근 발생한 XZ 유틸즈 사건이 바로 그런 경우다. 이 사건에서는 누군가가 오랜 시간 동안 합법적인 기여자로 위장해 코드에 백도어를 삽입했다. 

이런 위험을 완화하는 방법은 마이크로소프트가 개발해 현재 오픈SSF에 기부한 '보안 공급망 소비 프레임워크(Secure Supply Chain Consumption Framework, S2C2F)'와 같은 새로운 리소스 및 지침을 사용하는 것이다. 

3. 이름 혼동 공격

잠재적인 피해자가 실수로 다운로드하도록 유도하기 위해 합법적인 OSS 패키지 또는 구성 요소와 유사한 이름의 악성 구성 요소를 만드는 경우다. CNCF 소프트웨어 공급망 공격(CNCF Software Supply Chain Attack) 목록에도 나와 있는 공격으로, 타이포스쿼팅과 브랜드 재킹이 포함된다. 이렇게 손상된 패키지가 기업의 IT 환경으로 유입되면, 시스템과 데이터의 무결성·가용성·기밀성에 영향을 미칠 수 있다. 

이름 혼동 공격에 대처하기 위해서는 개발자가 다운로드하려는 OSS 패키지나 구성 요소가 합법적인이 확인하는 것부터 시작해야 한다. 이를 위한 개발자 교육은 필수다. 

4. 유지관리되지 않는 소프트웨어

독점 소프트웨어와 달리 '공급업체'가 없는 OSS의 가혹한 현실을 반영한다. OSS 유지관리자는 소프트웨어는 '있는 그대로' 제공하므로 소프트웨어가 유지관리, 업데이트, 지속될 것이라는 보장이 없다. 시놉시스(Synopsys)의 OSS 보고서에 따르면, 평가 대상 코드베이스의 85%가 4년 이상 된 OSS 구성 요소를 포함하고 있는 데다가 지난 2년 동안 새로운 개발이 이뤄지지 않은 구성 요소도 있는 것으로 나타났다. 

오늘날 소프트웨어가 노후화되는 속도는 매우 빨라졌다. 새로운 취약점도 더욱 빠르게 등장하고 있다. 연간 NVD 지표에 따라 적극적으로 업데이트되지 않는 OSS 구성 요소를 사용하는 최신 애플리케이션의 보안과 위생에 좋은 징조는 아니다. 

OSS를 유지 보수하는 인력은 대부분 무보수 자원 봉사자다. 따라서 구성 요소가 적극적으로 개발되거나 유지관리되지 않을 수 있으며, 결함에 대한 수정 역시 이뤄지지 않을 수 있다. 수정이 이루어지더라도 해당 구성 요소를 사용하는 소프트웨어 소비자가 원하는 일정에 맞지 않거나, 다운스트림 고객과의 SLA에 명시된 기간과 일치하지 않을 수 있다. OSS 세계에서 '사용한다는 것은 곧 소유하는 것'이다. 

OSS가 유지관리되지 않는 또 다른 이유는 인력 부족이다. 10명 이하의 개발자가 관리하는 프로젝트는 94%에 달하며, 특히 25%가량은 코드에 기여하는 개발자가 단 한 명뿐이다. 이런 문제를 포괄적으로 이해하고자 하는 사람은 포드햄 로스쿨 교수 친마이 샤르마의 논문 '공유지의 비극(A Tragedy of the Digital Commons)'을 읽어보기를 바란다. 

소프트웨어의 유지관리는 매우 중요하기 때문에 업계에는 "누군가가 버스에 치여도 프로젝트에 영향을 미치지 않는 최소 필수 인원"을 의미하는 '버스 팩터(Bus Factor)'라는 용어가 있다. 프로젝트에 관리자가 한 명뿐이라는 사실은 분명 위험하다. 최신 코드 베이스의 60~80%가 OSS로 구성됐다는 점을 고려하면, 오늘날 디지털 생태계의 상당 부분, 심지어 가장 중요한 시스템조차 최소한의 지원과 유지보수를 받는 소프트웨어에 기반한다는 현실이 우려스럽다. 

이런 위험에 대처하기 위해서는 유지관리자와 기여자의 수, 릴리스 빈도, MTTR(meantime to repair) 등 프로젝트의 활성화 정도와 건전성을 확인하는 것이 필수다. 

5. 오래된 소프트웨어

최신 버전과 업데이트가 존재함에도 불구하고 오래된 버전의 컴포넌트를 사용하는 경우가 있다. 시놉시스 보고서에 인용된 것처럼 이런 상황은 실제로 압도적으로 많은 코드 베이스와 리포지토리에서 발생하는 일반적인 현상이다. 

물론 많은 최신 소프트웨어 애플리케이션과 프로젝트가 복잡하고 어지러울 정도로 많은 종속성을 가지고 있기 때문에 문제는 더욱 복잡하다. 소나타입(Sonatype) 및 엔돌 랩스(Endor Labs)와 같은 그룹의 보고서에서도 이런 문제를 지적했다. 엔돌 랩스가 발표한 '종속성 관리 현황(The State of Dependency Management)'에 따르면, 취약점 95%가 전이적 종속성과 관련이 있다. 

6. 추적되지 않는 종속성

개발자와 기업이 특정 종속성이나 구성 요소의 사용 여부를 항상 인지하는 것은 아니다. 이는 기업이 OSS 소비를 이해하기 위해 SCA(Software composition analysis)와 같은 도구를 사용하지 않거나 기업이 소비하거나 배포하는 소프트웨어의 구성 요소에 대한 가시성을 제공하는 SBOM(software bills of matrials)과 같은 새로운 툴을 채택하기 않은 결과일 수 있다. 

사실 SBOM은 소프트웨어 공급망 보안을 보장하고자 하는 광범위한 움직임의 일환이다. 솔라윈즈 및 Log4j와 같은 사건을 통해 업계는 소프트웨어 자산 인벤토리가 수년 동안 SANS/CIS에서 제안하는 중요한 관리 사항임에도 불구하고 대부분 기업이 구성 요소/라이브러리 수준까지 포괄한 소프트웨어 인벤토리를 작성하지 않는다는 사실을 깨달았다. SBOM은 기업이 기업 차원에서 구성 요소 인벤토리를 파악할 수 있도록 함으로써 이런 문제를 해결하고자 한다. 

7. 라이선스 및 규제 위험

컴포넌트 또는 프로젝트에 라이선스가 없거나 다운스트림 소비자의 의도된 사용을 방해하는 라이선스가 있을 수 있다. OWASP는 기업이 OSS 구성 요소를 사용할 때 해당 구성 요소의 라이선스 조건을 준수해야 한다고 명시한다. 그렇게 하지 않으면 라이선스 또는 저작권 침해, 심지어 법적 조치로 이어질 수 있다. 이는 기업이 독점 제품, 서비스 및 오퍼링에서 OSS 구성 요소를 광범위하게 사용함에 따라 기업의 비즈니스 목표, M&A 활동 등에 영향을 미칠 수 있다. 

소프트웨어에 사용 중인 구성 요소의 라이선스와 용도를 파악하면 이런 위험을 완화할 수 있다. 또한 라이선스가 없는 구성 요소의 사용을 완전히 피하고 여러 라이선스 또는 상충하는 라이선스가 적용되는 구성 요소를 식별하는 것도 권장된다. 

8. 미성숙한 소프트웨어

모든 소프트웨어가 동일한 과정을 거쳐 개발되는 것은 아니다. 유지관리자의 참여 수준이 다르기 때문에 성숙도 측면에서 다양한 스펙트럼에 존재한다. 일부 OSS 프로젝트는 NIST 보안 소프트웨어 개발 프레임워크(SSDF)에 인용된 것과 같은 보안 관행을 적용하지 않을 수 있다. 예를 들어 문서화 작업이나 회귀 테스트, 검토 가이드라인, 기타 여러 베스트 프랙티스 적용이 미흡할 수 있다. 

또한 많은 개발자가 보안에 관심이 없다는 불편한 현실도 있다. 무료 오픈소스 소프트웨어 개발자가 코드의 보안을 개선하는 데 전체 시간의 2.3%만 투자한다는 리눅스 재단과 하버드 대학교 LISH(Laboratory for Innovation Science at Harvard University)의 연구 결과가 이를 뒷받침한다. 

브랜치 보호 여부, 기여자 및 조직 수, CI 테스트, 퍼징, 유지관리, 라이선싱 등 깃허브의 OSS 프로젝트에 대한 강력한 점검을 제공하는 오픈SSF의 스코어카드(OpenSSF's Scorecard)와 같은 툴도 광범위하게 사용할 수 있다. CISA와 오픈SSF가 개발한 '패키지 리포지토리 보안을 위한 원칙(Principles for Package Repository Security)'이라고 불리는 원칙을 참고하는 것도 도움이 된다.  

9. 승인되지 않은 변경(혹은 변경 가능성)

OWASP는 개발자가 변경을 인지, 검토 또는 승인하지 않은 상태에서 구성 요소가 변경될 수 있는 상황이 있음을 경고했다. 이는 다운로드 링크가 변경되거나, 버전이 지정되지 않은 리소스를 가리키거나, 변조되어 안전하지 않은 데이터 전송을 가리킬 때 발생할 수 있다. 

권장되는 조치 및 완화 방법에는 리소스 식별자를 사용해 보증하고 동일한 변경 불가능한 아티팩트를 가리키는 것이 포함된다. 또한 구성 요소를 실제로 설치 및 사용하기 전에 서명과 다이제스트를 확인할 수 있다. 또한 전송 중 구성 요소가 손상될 위험을 완화하기 위해 기업은 네트워크 트래픽의 전송 및 통신에 보안 프로토콜을 사용해야 한다. 

10. 과도하거나 너무 적은 종속성

마지막으로 컴포넌트가 제공하는 기능이 매우 적거나 많지만, 실제로는 일부만 사용되는 상황이다. 이를 흔히 '소프트웨어 블로트(software bloat)'라고 한다. 크기가 작은 종속성 사례에서는 코드 줄이 제한되어 있기 때문에 컴포넌트가 보안을 위해 업스트림 프로젝트에 종속된다. 반대로 코드가 비대해지거나 기하급수적으로 많은 코드 줄이 있는 경우, 의도한 목적에 실제로 필요하거나 사용되지 않음에도 불구하고 공격 표면이 증가하고 잠재적으로 악용될 수 있는 코드/종속성을 가져오는 결과를 초래한다. 

이런 경우 내부적으로 필요한 기능을 재개발해 종속성 부족 또는 과다에 따른 위험을 완화할 것을 권장한다. 체인카드(Chainguard)처럼 클라우드 네이티브 컨테이너 환경에서 취약점이 거의 없는 최소한의 강화된 기본 이미지인 ‘보안 기본 이미지’를 활용하려는 움직임도 확산하고 있다. 
editor@itworld.co.kr