전체메뉴

[애플경제 김향자 기자] 오픈소스 소프트웨어가 하나의 추세로 자리잡으면서, 취약성이 자주 노출되고, 오픈소스 도입 과정에서 유사한 리소스로 위장한 요소나 악성코드에 감염되는 등 보안 문제도 날로 심각해지고 있다.

이에 국내․외 보안업체들도 최근엔 SW시큐어의 일환으로 오픈소스 SW 보안의 중요성을 강조하고 있다. 특히 글로벌 보안업체 엔도르 랩스와 어도비, 해쉬 코(Hashi Corp), 디소드(Disord), 팔로 알토 네트워크(Palo Alto Networks) 등의 보안 책임자 20명이 최근 SW 보안위협 사항을 조목조목 발췌, 소개하며 주의를 당부해 주목을 끌고 있다.

엔도르 랩스, 어도비, 해쉬 코, PAN 등 보안업체 공동 조사

엔도르 랩스 등이 펴낸 연구보고서는 현재 국내․외를 망라한 오픈소스 SW 보안 위협요인들을 일목요연하게 정리한 내용이란 점에서 의미가 크다.

이에 따르면 우선 개발자들이 도입, 적용하는 오픈소스의 구성 요소 중에 취약한 코드가 포함되어있는 경우가 많다. 이 취약성은 오픈소스가 적용된 소프트웨어 내에서 악용되어 해당 시스템과 데이터의 기밀성, 무결성, 가용성을 크게 손상시킨다는 지적이다.

또 사이버 공격자는 기존 프로젝트나, 배포된 오픈소스의 합법적인 리소스를 악용하는 경우가 많다. 즉, 해당 리소스에 악성 코드를 주입하여 공격하는 방식이다. 예를 들어 합법적인 프로젝트 관리자의 계정을 가로채거나, 패키지 저장소의 취약성을 이용하는 수법이 그런 경우다. “이러한 유형의 공격은 악의적인 코드가 합법적인 패키지의 일부로 배포되므로, 탐지하기 어렵기 때문에 특히 그 위험성과 피해가 클 수 밖에 없다”는 엔도르 랩스, 어도비 등의 경고다.

합법적 구성요소 악용, 고의적인 철자 오류

또 합법적인 오픈 소스나, 시스템 구성 요소와 유사한 이름으로 위장된 구성 요소를 주입시키는 수법도 경계해야 한다. 엔도르 랩스 등이 특히 주의를 환기하는 것으론 △타이포 스쿼트가 있다. 이는 원래 구성 요소 이름의 철자를 잘못 쓴 듯한 명칭으로 배포한다. 신뢰할 수 있는 명망가나 작가 등을 사칭하는 △브랜드 잭킹 수법도 경계해야 한다.

이른바 △콤보 스쿼트도 흔히 범죄자들이 쓰는 수법이다. 이는 서로 다른 언어나, 생태계 간의 공통된 이름을 도용하는 것이다. “사용자가 합법적이라고 생각하고, 악의적인 구성 요소를 다운로드하도록 속이는 방법”이란 설명이다.

출시된 후 오랫동안 유지, 관리되지 않는 오픈소스일수록 보안 문제도 크다는 지적이다. 즉, 구성 요소나 버전이 더 이상 적극적으로 개발되지 않는다. 이로 인해 기능적 혹은 기능 외적인 버그에 대한 패치가 적절하게 제공되지 않거나 전혀 제공되지 않을 수 있다. 노출된 취약성을 대상으로 하는 공격에 쉽게 당할 수 밖에 없는 이유다.

일부 개발자들의 부주의도 문제가 된다. 대표적으로 편의상 업데이트된 오픈소스 버전을 적용할 때도 구식 버전의 코드 베이스를 사용하는 사례가 그것이다. 이로 인해 프로젝트 보안을 위해 중요한 버그 수정이나, 보안 패치가 누락되어 외부 공격에 무방비상태가 되어버리는 것이다.

구식 버전 코드베이스, AS없는 SW도 위험

SW시큐어 코딩의 경우와 마찬가지로 추적되지 않은 종속성도 문제다. 종속성에 대해 아주대 윤대균 교수는 “모든 소프트웨어가 끊임없이 진화하기 때문에, 일부 모듈의 변경은 수시로 발생하므로, 바로 이런 부분이 악성 해커들이 노리는 공격 포인트”라면서 “수많은 오픈소스 기반의 SW나 모듈이 복잡하게 얽혀 또 다른 SW를 구성하는 ‘종속성 트리’를 파악함으로써 문제가 생긴 원인을 짚어낼 수 있다”고 제시했다.

이에 프로젝트 개발자들은 이같은 오픈소스 SW 구성요소의 종속성을 필히 인식해야 한다는 주문이다.

우선 △업스트림 구성 요소가 소프트웨어 BOM(구성요소 관리목록, Bill of Materials)에 포함되지 않거나, △소프트웨어 구성 도구가 실행되지 않거나 탐지되지 않는 경우를 주의해야 한다. 또한 △패키지 관리자를 사용하여 종속성을 설정하지 않을 경우, 자칫 추적되지 않은 종속성의 취약성이 노출되면서 보안 문제가 발생할 수 있다는 충고다.

엔도어 보고서는 또 구성요소 또는 프로젝트가 라이센스가 없거나, 의도했던 용도와 호환되지 않거나, 요구사항이 충족되지 않는 라이센스를 가질 경우 역시 주의를 당부한다.

즉 “라이센스 조건에 따라 구성 요소를 사용하는 것은 매우 중요한 문제”라면서 “라이선스 없이 구성요소를 사용하거나, 그 약관을 준수하지 않을 경우 저작권 또는 라이선스 침해를 초래할 수 있고, 저작권자로부터 법적 조치를 당할 위험성이 크다”고 했다.

또한 “법적 의무나 규제 요건을 위반하면, 특정 산업 또는 시장에 참여할 기회를 박탈당하거나, 제한을 받을 수도 있다”고 주의를 당부했다.

오픈 소스 프로젝트는 흔히 개발 원칙을 따르지 않는 경우가 빈번하게 발생한다. 즉, 표준 버전 관리 체계를 사용하지 않고, 회귀 테스트 세트나, 검토 지침 또는 문서도 갖고 있지 않는 경우가 많다. 이로 인해 오픈소스 구성 요소가 안정적으로 안전하게 작동하지 않아 공격에 노출되는 사례가 잇따르고 있다.

라이센스 규정, 개발원칙 무시도 금물

이를 두고 엔도어 등은 “미숙한 구성요소나, 프로젝트에 의존하면 운영상의 심각한 위험을 초래할 수 있다”면서 “예를 들어, 오픈소스 소프트웨어에 의존한 소프트웨어가 의도한 대로 작동하지 않아 크게 신뢰가 훼손될 수도 있다”고 밝혔다.

각기 다른 시간에 오픈소스를 다운로드할 경우, 그때마다 구성요소들이 동일하다고 보장할 수만은 없다. 그럼에도 불구하고, 이를 무시한채 구성 요소를 사용할 경우 보안 위험이 매우 크다는 지적이다. 실제로 소프트웨어 테스트 업체인 코드코브(Codecov) 다운로드된 스크립트가 무결성을 사전에 확인하지 않아 공격에 노출되었던 ‘배쉬 업로더’(Bash Uploader) 사건도 그런 사례다. 그래서 “가변적인 구성요소임을 무시한채 같은 오픈소스를 반복해서 다운로드 할 경우 소프트웨어 빌드의 안정성과 재현성에 큰 위협이 된다”는 경고다.

‘오픈 소스 리스크 완화’ 매뉴얼

이같은 오픈소스 리스크를 최소화하기 위해선 우선 코드를 정기적으로 검색하여 손상된 패키지를 찾아내는 것이 중요하다. 또 보안 요구사항과 위험 허용도를 기준으로 삼아, 이에 가장 적합한 안전장치를 선택하고 우선 순위를 정할 수도 있다.

앞서 엔도르 등 보안업체들에 따르면 프로젝트의 품질을 평가하는 과정에서 해당 문서와 릴리스 노트에서 완전성과 적시성을 반드시 확인해야 한다. 또 CI/CD 파이프라인의 존재나, 테스트 적용 범위를 나타내는 배지를 찾도록 한다.

특히 종속성을 최신 상태로 유지하고, 사용하기 전에 코드 특성을 확인하는 것이 중요하다. 즉, “코드 보안을 위해 코드와 프로젝트 특성을 모두 확인하고, 소스 코드 저장소, 유지 관리자 계정, 릴리스 빈도, 다운스트림 사용자 수 등 프로젝트 특성을 고려할 필요가 있다”는 설명이다.

이 밖에 △소프트웨어를 구성하는 분석 도구를 평가, 비교해야 하고, △오픈 소스 라이센스 조항을 준수하는 구성 요소를 사용하며, △구성 요소의 연결 방식, 배치 모델, 의도된 분포 방식 등도 꼼꼼히 살펴야 한다.