오픈소스·레거시 프로그램의 오래된 코드를 수정하는 3가지 원칙

기업 환경에 남아 있는 오래되고 취약한 코드를 발견하더라도 정작 리소스가 부족해 문제를 수정하지 못하는 경우가 많다. 오픈소스, 오래된 프로그램 등 이유는 다양하지만 대부분의 기업은 언젠가는 이러한 상황에 직면하게 된다. 그러나 우선 순위화, 자동화, 완화 등의 몇 가지 방법으로 대처할 수 있다.

오래된 불량 코드 문제는 기업에서 흔히 볼 수 있다. 전반적으로 취약한 코드가 문제다. 올해 초에 발표된 베라코드(Veracode) 보고서에 따르면 2022년에 검사한 애플리케이션의 74%에 하나 이상의 보안 결함이 있었고 19%에는 심각도가 높은 취약점이 존재했다.

베라코드의 최고 연구 책임자인 크리스 엥은 애플리케이션이 오래될수록 문제가 있을 가능성도 높다고 말했다. 새 애플리케이션의 경우 첫 스캔에서 보안 결함이 발견되는 비율이 32%지만 5년 후 이 수치는 70%로 높아진다. 애플리케이션이 10년차에 이르면 하나 이상의 보안 결함이 존재할 가능성은 90%가 된다.
 

문제가 증가하는 이유는 애플리케이션에 추가되는 새 코드다. 베라코드에 따르면 애플리케이션은 첫 5년 동안 매년 평균 40% 커진다. 각 새 코드 라인마다 실수의 가능성이 추가되고, 코드가 복잡해질수록 문제를 찾고 해결하기는 더 어려워진다.
 
구성요소 역시 문제의 큰 부분을 차지한다. 엥은 CSO와의 인터뷰에서 “대부분의 개발자는 오픈소스 구성요소를 다운로드해서 애플리케이션에 넣고 나면 더 이상 업데이트를 하지 않는다”라고 말했다. 더 정확히 말하면 오래된 오픈소스 구성요소의 79%가 업데이트되지 않은 채 방치된다. 새 코드가 추가되지 않더라도 시간이 지나면서 새로운 취약점이 계속 발견된다. 엥은 “해당 애플리케이션의 보안 태세는 계속해서 더 나빠진다”라고 말했다.

2023년 2월에 발행된 시놉시스(Synopsys)의 오픈소스 보안 및 위험 분석에 따르면 모든 상업용 코드 기반의 96%에 오픈소스 구성요소가 포함되며, 4년 이상 된 오픈소스 코드가 포함된 비율도 89%에 이른다. 이는 애플리케이션 보안 측면에서 매우 중요한 문제로, 취약한 서드파티 라이브러리는 웹 애플리케이션 보안 위험의 OWASP 상위 10개 목록에 올라 있다.

해결 방법은 표면적으로는 간단해 보인다. 구성요소를 최신 버전으로 교체하기만 하면 된다. 이 방법은 코드 기반이 비교적 새로울 때는 쉽다. 엥은 “이런 경우에는 패치가 나오면 바로, 손쉽게 패치할 수 있다. 그러나 몇 년을 방치해서 여러 버전 뒤처진 상황이라면 최신 버전을 받기 위해서는 상당한 작업이 필요하다”라고 말했다.
 
매번 새 업데이트, 특히 주 버전이 나올 때는 동작이 바뀔 가능성이 높다. 주요 기능에 대한 지원이 중단될 수도 있다. 이 말은 즉, 구성요소가 최신 버전으로 업데이트되면 애플리케이션 전체의 동작이 멈출 수 있음을 의미한다. 엥은 “주 버전이 여러 단계 뒤처져 있다면 거의 확실히 문제가 발생한다”라고 말했다.
 
이 같은 상황에 처한 기업이 취할 수 있는 최선의 조치는 가장 중요한 문제에 먼저 집중하는 것이다.
 

가장 위험이 큰 불량 코드를 찾아서 우선 해결하기

취약점마다 기업에 미치는 영향도 다르다. 예를 들어 특정 기능에 보안 결함이 있다 해도 애플리케이션이 그 기능을 사용하지 않는다면 그 문제에 대한 시스템의 취약성은 비교적 낮을 수 있다. 또 익스플로잇이 외부에서 발견된 적이 있는지 여부와 관측된 공격 활동의 유형도 고려해야 한다.
 
컨텍스트도 중요하다. 시놉시스의 소프트웨어 무결성 그룹 컨설턴트인 애덤 브라운은 CSO와의 인터뷰에서 “아주 오래된 구식 애플리케이션이 있다 해도 네트워크 담당자 한두 명 외에는 아무도 접근할 수 없는 보안 네트워크에 배포되어 있다면 그 영향은 크지 않다. 취약점의 위험 등급이 매우 높게 분류되더라도 수정하는 데 많은 돈을 들여야 한다면 누구에게도 이득이 되지 않는다”라고 말했다.
 
규제 대상 산업에서는 코드 수정과 관련된 규정 준수 문제도 발생할 수 있다. 모든 변경 사항이 심사 대상이기 때문이다. 이 문제는 대체로 금융 및 의료 부문에서 발생한다. 오래된 애플리케이션의 경우 고치는 대신 교체하는 편이 더 나을 수도 있다. 브라운은 “예전 모델을 수정하는 것보다 새 모델을 구축해서 천천히 마이그레이션하는 편이 더 쉬운 경우도 종종 있다. 중대한 취약점을 수정하는 데 시간을 보낼 수 있지만 궁극적으로 해야 할 일은 플랫폼을 개편할 방법을 찾는 것”이라고 말했다.
 
이달 초에 시놉시스는 웹 및 모바일 애플리케이션에 초점을 두고 지난 3년 동안 실시한 1만 2,000회의 테스트를 기반으로 한 자체 소프트웨어 취약점 보고서를 발행했다. 이 보고서에 따르면 애플리케이션의 92%에 취약점이 존재하며 그 중 33%는 높음 또는 치명적 심각성 범주에 해당한다.
 
기업은 우선순위를 정할 때 언론 보도에 휘둘리지 않도록 주의해야 한다. 사이버 보안 벤더 사이뮬레이트(Cymulate)의 사이버 보안 설계자인 마이크 드나폴리는 “기업에서는 실질적인 위험 수준보다는 현재 언론의 관심 수준에 따라 위협의 시급성을 판단하는 경향이 있다”라고 말했다. 사이뮬레이트는 지난 3월 사이버 보안의 효과를 추적하는 보고서를 발표했는데, 이 보고서는 기업 내에 존재하는 안전하지 않은 코드도 살펴봤다. 보고서에 따르면 평균 위험 점수는 작년에 비해 더 악화됐다.
 
IEEE 선임 회원이자 보안 및 위험 전문 기업 하이퍼프루프(Hyperproof)의 CISO인 케인 맥글래드리에 따르면 소프트웨어 수정의 우선 순위를 정하는 데 있어 가장 큰 문제는 보안 통제와 비즈니스 위험 결과 사이에 자주 발생하는 단절이다. 맥글래드리는 이로 인해 경영진의 지원을 받기가 더 어려워진다고 말했다. 코드 유지 관리와 종속성 관리는 매력적인 주제가 아니다. 맥글래드리는 “경영진의 관심은 다운타임이 미치는 금전적 또는 평판 측면의 영향"에 집중되는 경향이 있다고 말했다.
 
맥글래드리는 “기업은 이 문제를 해결하려면 퍼스트 파티 및 서드파티 코드, 두 가지 모두와 관련된 비즈니스 위험을 문서화하고 합의해야 한다. 그런 다음 평판 손상, 금전적 피해, 법적 조사 같은 영역에서 얼마만큼의 위험을 감수할 것인지를 결정해야 한다. 경영진 수준에서 합의가 되면 핵심 시스템의 비즈니스 소유자는 이러한 위험을 줄이기 위한 통제 방법을 파악하고 구현해야 한다”라고 말했다.
 
기업에서 우선순위가 가장 높은 문제를 파악했다면 다음 단계는 문제를 수정하는 것이다. 그러나 문제 수정이 항상 가능하지는 않으므로 다른 방법을 강구해야 할 수 있다.
 

완화 외에는 대안이 없는 경우

오래된 시스템의 경우 코드 수정에 필요한 지식을 갖춘 사람이 당장 없을 수도 있다. 기술 서비스 기업 어드밴스드(Advanced)가 작년 11월에 발표한 설문조사 결과에 따르면 메인프레임을 사용하는 기업의 42%는 가장 많이 사용하는 레거시 언어가 코볼(COBOL)이라고 답했으며, 37%는 여전히 어셈블러(Assembler)를 사용 중이라고 답했다.
 
위드시큐어(WithSecure)의 사이버 보안 고문인 폴 브루치아니는 “구인 시장에서 코볼 같은 구세대 프로그래밍 언어 기술을 갖춘 사람을 찾기는 어렵다”라고 말했다.
 
또 다른 문제는 소스 코드가 소실된 경우다. 브루치아니는 “소스 코드가 분실되어 업데이트할 수 없는 오래된 소프트웨어를 기반으로 운영되는 기업이 생각 이상으로 많다”라고 말했다.
 
애플리케이션이 너무 중요해서 망가질 경우의 위험이 너무 크고 교체 시 발생하는 비즈니스 중단을 감당할 수 없다는 이유로 손대지 못하는 경우도 있다. 사이뮬레이트의 드나폴리는 “레거시 코드와 애플리케이션을 발견한다고 해서 무조건 바로 제거할 수 있는 것은 아니다. 레거시 시스템에서 수행되는 기능 및 워크플로우에 핵심적인 비즈니스 프로세스가 의존하는 경우가 많다”라고 말했다.
 
시간이나 리소스의 부족, 또는 규정준수 관련 사항으로 인해 소프트웨어 취약점이 수정되지 않는 경우도 있지만 이러한 취약점 역시 악용될 경우 위험을 초래하기는 마찬가지다. 이 경우 기업은 취약한 시스템에 대한 완화 조치를 취해야 한다. 문제를 보완하는 통제 수단을 구현하거나 강화하는 등 다른 전략을 사용해야 한다.
 
제로 트러스트 아키텍처, 네트워크 세분화, 인증 강화는 취약한 애플리케이션이 악용될 위험을 낮추는 데 도움이 될 수 있다. 베라코드의 엥은 “모든 것을 인증 계층 뒤에 두려는 추세가 뚜렷하다. 이 추세는 코드가 얼마나 오래되었는지에 관계없이 동일하게 일어나고 있다”라고 말했다.
 
그 외의 완화 전략으로는 암호화, 방화벽, 보안 자동화, 동적 데이터 백업 등이 있다.
 

오래된 코드를 찾고 더 안전한 코드를 생성하는 자동화

오래된 취약한 코드 문제에 대한 최신 해결 방법은 새로운 인공 지능의 발전과 관계가 있다. 이미 새로운 코드를 작성할 수 있는 생성형 AI 도구가 있지만 취약점을 수정하도록 특별히 학습된 전문화된 AI도 개발되는 중이다. 엥은 “AI가 해결 방안을 제시할 수 있고, 개발자가 이 제안을 약간 수정하면 된다”라고 말했다.
 
문제는 기업이 불량 데이터를 포함한 온갖 정보로 학습되는 대규모 공개 언어 모델을 사용하는 경우다. 엥은 “흔히 말하듯이 쓰레기가 입력되면 출력되는 것도 쓰레기다. 이러한 모델이 생성하는 코드에는 필연적으로 취약점이 포함된다. 즉, 코드가 생성되는 속도는 빨라지지만 오류는 여전히 존재하게 된다”라고 덧붙였다.
 
베라코드는 자체 심사를 거친 코드를 기반으로 자체 AI를 구축하고 있다. 엥은 “취약한 코드와 양질의 코드를 생성한 다음 두 가지 각 범주에 대해 모델을 학습시킨다. 이렇게 만들어진 모델은 아무 개발자의 깃허브 리포지토리에서 코드를 긁어와 결과로 출력하는 일이 없다”라고 말했다.
 
베라코드 픽스(Fix)는 지난 4월에 출시됐다. 회사 측에 따르면 이 제품은 자바 코드에서 발견되는 결함의 72%에 대한 수정 코드를 생성할 수 있고 이를 통해 기업의 수정 작업 속도를 비약적으로 높여준다.
 
어느 시점이 되면 규모가 큰 기업은 자체적인 맞춤형 AI 툴을 구축하기를 원하게 될 것이다. 엥은 “이 기업들은 자신들이 사용하는 코드 스타일로 수정을 생성하기를 원한다”라고 말했다.
 
그렇다고 AI가 모든 문제를 해결할 수 있게 될 때까지 가만히 앉아서 기다려야 한다는 말은 아니다. 엥은 “대부분의 기업이 방대한 보안 부채를 떠안고 있음을 감안하면 당장 가장 심각한 문제를 해결하는 작업만 해도 할 일이 매우 많을 것”이라고 말했다.
editor@itworld.co.kr