전체메뉴

[애플경제 전윤미 기자] IT산업과 SW업계는 이젠 오픈소스 시대라고 해도 과언이 아니다. 그러나 오픈소스는 태생적으로 제3자의 생성물이므로, 늘 위험을 안고 있다. 그 때문에 개발자나 SW종사자는 물론, 일반인들도 오픈소스 소프트웨어에 대한 이해를 높여야 한다는 목소리가 높다.

특히 소스코드를 기반으로 아예 별개의 개발을 시도하는 ‘오픈소스 포킹(forking)’과 같은 대안이 필요하다는 조언이다. 개발자 등 사용자들은 또한 평소에소 오픈소스에 대한 나름의 ‘큐레이션’을 통해 오픈소스 커뮤니티나 공급자에 대한 종속성을 최소화할 필요가 있다.

수많은 이점 불구, 위험과 ‘기회비용’ 많아

또한 소프트웨어 자재 청구서(SBOM)와 같은 장치도 도움이 된다. 이를 통해 오픈소스를 계속 추적하고, 가시성을 높일 수 있다. 기왕이면 CNCF(Cloud Native Computing Foundation) 또는 아파치(Apache)와 같은 오픈 소스 재단의 소프트웨어를 사용하는게 안전하다는 조언도 따른다.

본래 오픈소스 기술은 기업과 SW개발자들에게 수많은 이점을 제공하지만, 반드시 코드의 출처를 알아내고 유지 관리를 해야만 위험을 예방할 수 있다. 오픈소스 시스템은 이제 안드로이드 기기에서부터 다양한 산업 시스템, AI에 이르기까지 기술 스택 전반에 깊이 스며들고 있다.

그러나 문제는 여전히 가시지않은 오픈 소스의 신뢰도다. 아직도 오픈소스 소프트웨어(OSS)가 어떻게, 어디에서 비롯되었는지에 대한 이해나 탐지가 미흡한 경우가 많다. 특히 기업의 경우 오픈소스 구성 요소에 자체 인프라 등이 얼마나 종속될 것인지를 알 수 없는 상황도 많다.

심지어는 OSS가 있다는 사실조차 모를 수도 있다. 이는 오픈 소스를 사용한 소프트웨어 완제품을 구매했기 때문이다. 해당 소프트웨어가 오픈소스로 만들어진 사실조차 알 수 없는 것이다. 실제로 시중에 나도는 소프트웨어 코드의 절대 다수가 오픈소스로 만들어진 것이 오늘의 현실이다.

오픈소스 취약성 드러낸 Log4j 사건

지난해 또 다시 전세계적으로 문제를 일으킨 ‘Log4J’ 취약성도 그런 사례 중 하나다. 기업들은 이처럼 널리 사용되는 오픈 소스 라이브러리의 취약성에 대한 노출을 평가하느라 애를 먹곤 한다. 문제는 보안에만 그치지 않는다. 오픈소스에 대한 라이선싱이나 AS 지원 등도 문제다. OSS가 애초 어디에서 어떻게 만들어지고, 어떤 용도가 가장 적절한지를 알 수 없어 문제가 되기도 한다.

Log4 사건 이후 기업체 CIO들이나 소프트웨어 개발 팀들 간엔 새삼 이에 대한 경각심이 고취되었다. 보안전문가들도 오픈 소스 소프트웨어 관리에 한층 더 신경을 쓰고 있다. 특히 수많은 오픈 소스 커뮤니티들도 이런 위험의 재발을 막기 위해 노력하는 분위기다.

오픈소스 위험 방지를 위한 다양한 대책

또 오픈소스 ‘포킹’도 하나의 대책이 될 수 있다. 보안매체 ‘사이버시큐리티 인사이더’는 오픈 소스 산업 그룹 ‘오픈UK(OpenUK)’ 관계자의 말을 빌려 “오픈 소스 프로젝트를 ‘포킹’하면 라이선스 변경을 포함, OSS 주변의 위험 요소가 상당수 제거된다”면서 “물론 ‘포킹’은 힘든 작업이지만 코드의 개방적 특성을 유지한다”고 했다.

‘포킹’은 개발 커뮤니티의 일부(혹은 프로젝트와 무관한 서드파티 혹은 사용자)가 프로젝트의 소스 코드 기반을 토대로 완전히 별도의 개발을 시작하는 것이다. 프로젝트가 ‘포크’로 인정받으려면, 새로운 프로젝트명과 소프트웨어 브랜치, 웹사이트, 버저닝 시스템, 메일링 목록, 새롭게 분리된 개발자 커뮤니티 등이 필요하다. 물론 그럼에도 불구하고 사용자로선 완전히 안심해선 안되고, 끊임없이 오픈소스 안전성을 주시해야 한다는 조언이다.

앞서 ‘사이버시큐리티 인사이더’는 “‘"포크’에도 불구하고, 현명한 사용자들은 프로젝트에 기여하는 커뮤니티를 확인한다”면서 “이를 통해 해당 프로젝트가 종속되기 전에 프로젝트의 상태를 파악한다”고 밝혔다. 또 “이런 식으로 사용자들이 오픈 소스를 ‘큐레이션’하는 사례가 늘어나고 있다”고 덧붙였다.

특ㅎ 기업이 시스템을 견고하고 안전하게 유지하려면 오픈 소스를 프로젝트에 통합하는 과정에서 각별한 주의와 노력이 필요하다는 지적이다. 소프트웨어 자재 청구서(SBOM)와 같은 장치도 도움이 된다. 오픈소스를 계속 추적하고, 가시성을 높일 수 있기 때문이다. 그럼에도 “개발자 팀은 코드도 계속 모니터링해야 한다”는 주문이다.

또한 CNCF(Cloud Native Computing Foundation) 또는 아파치(Apache)와 같은 오픈 소스 재단의 소프트웨어를 사용하면 한층 안전하다.

‘헤드리드’는 이에 대해 “오픈 소스 소프트웨어를 채택하는 것은 독점 코드를 채택하는 것만큼 심각하게 생각해야 한다”면서 “오픈소스 코드가 ‘무료’라는 이유만으로 안심해선 안 된다”고 했다. 즉 “‘코드 뒤’에 있는 제작자 내지 개발한 사람들의 동기가 무엇인지, 그들을 신뢰할 수 있는지를 파악해야 한다”는 조언이다.

또한 오픈소스는 기대한 만큼의 ‘기회비용’, 즉 ‘신뢰’와 ‘책임’의 문제가 따른다는 지적이다. 독일증권거래소의 기업 IT 및 사이버보안 전무이사인 토미슬라브 류바스는 “문제가 생겼을 때 누구에게 전화해야 할까?”라고 반문했다. 그는 “독점 소프트웨어의 경우 최소한 공급업체가 책임을 져야 한다. 오픈 소스 공급업체들은 ‘24시간 연중무휴 사고 대응’ 조건으로 가입하지 않은 사용자들을 선호하는게 문제”라고 IT프로에 밝혔다.

OSS에 대한 체계적인 접근 방식도 중요

또 무심코 오픈 소스 커뮤니티에서 만든 코드를 사용하거나 재사용할 위험이 있다.그런 경우 문제가 생겨도 공급자가 책임지지 않으며, 그런 오픈소스로 만든 시스템은 치명적인 약점이나 취약성이 생길 수 밖에 없다.

보안 취약성뿐만 아니다. 오픈소스 공급업체에 대한 종속성도 문제다. 라이선스 변경 등으로 개발 SW가 무용지물이 되거나, 오픈소스 유지 관리자가 의도적으로 프로젝트를 훼손 내지 훼방하기도 한다.

그래서 “오픈 소스 소프트웨어는 상업적 공급업체에서 제공한 것이든, 내부적으로 개발한 애플리케이션이든 늘 최신 상태로 유지, 예상되는 문제나 잠재적 취약성에 대비해야 한다”는 전문가들의 조언이다. 그렇지 않을 경우 취약점이 ‘침투’, 사이버 공격으로 이어질 수 있다는 경고다. 가장 대표적인 사례가 바로 ‘Log4J’ 취약성으로 인해 벌어진 사건이다. 이 도구는 여러 애플리케이션에서 널리 사용되었지만 취약점이 있다. 당시 이로 인해 발생한 보안 침해는 많은 기업들에게 치명적 타격을 주기도 했다.

독일증권거래소 보안 책임자 류바스는 “오픈소스는 강력하지만 통제력이 없는 힘은 위험하다”면서 “특히 (오픈소스) 공급망에서 OSS를 관리하는 체계적인 접근 방식이 없다면 매우 위험하므로, 그런 기회비용을 최소화하는 노력이 중요하다”고 ‘사이버시큐리티 인사이더’를 통해 강조했다.