취약성 지원·정확한 오류 검출·지속적인 품질 관리 기능 갖춰야

[보안뉴스= 정영범 파수닷컴 팀장] 몇 년 전에 TV에서 하는 다큐멘터리에 크게 감동을 받은 적이 있다. 두바이에 있는 세계 최고층 빌딩인 부르즈 할리파에 관한 다큐멘터리였다. 다큐멘터리는 우리나라 업체가 세계 최고층 빌딩을 세웠다는 것을 강조하면서 애국심을 자극했지만, 우리나라에 대한 자부심과 함께 인류가 쌓아 온 최첨단 과학기술이 조화를 이루는 과정에도 깊은 감동을 받았다. 엔지니어로서의 꿈은 이런 것이라고 말해주는 듯했다.

코딩 단계에서의 정적 분석 테스팅의 중요성

부르즈 할리파는 특이한 모양을 하고 있다. 올라갈수록 좁아지는 첨탑 비슷한 모양인데 어느 방향에서 보더라도 대칭이 되지 않는다. 일반적인 미적 감각에는 좀 어지러워 보이기도 하다. 두바이에는 강한 바람이 자주 불기 때문에 바람에 의해 고층건물이 힘을 받아 무너지는 일이 없도록 설계를 한 것으로 알려졌다.

만약 네모반듯하게 건물을 세우면 강한 바람이 그 면에 수직으로 불게 되는 경우에 무너질 수 있다. 게다가 이런 모양으로 지어야 하중을 분산시킬 수 있다는 것. 외관을 자세히 보면 띠가 보인다. 30층마다 특별히 튼튼하게 지어서 대나무의 마디가 하는 역할을 하여 휘어질지언정 부러지지는 않게 하는 역할을 한다. 이 층은 비상시에 사용할 수 있는 대피처로도 사용하며, 외벽에 레일을 설치해서 위아래의 건물 외벽을 청소할 수 있게 했다.

설계가 치밀하다. 보통 건물을 올릴 때 지면에 수직으로 올라가는지 검증하기 위해서 삼각 측량을 사용하는데 부르즈 할리파는 워낙 고층 건물이라 삼각 측량의 한계를 넘어선다고 한다. 이를 해결하기 위해 각 층마다 GPS를 3개 설치해서 건물이 바르게 올라가는지 위성으로 측량했다. 장력의 한계로 엘리베이터도 한 번에 제일 꼭대기 층으로 올라갈 수 없기에 여러 단계를 거쳐서 올라가도록 설계했고, 그렇게 설치하는 엘리베이터가 건물의 척추 역할을 하도록 만들었다. 마지막으로 건물을 완성하고 나면 건물 자체의 하중으로 65cm 주저앉는다는 것을 계산해서 층마다 2~4mm씩 높여서 지었다. 이 모든 것을 설계 단계에서 고려한다. 감동적이지 않은가?

눈에 보이지 않는 만큼 어려운 소프트웨어

이 모든 것을 설계 단계에서 고려할 수 있게 해주는 기반은 튼튼하다. 이는 인류가 오랫동안 축적해 온 모든 과학기술이다. 물리학은 건물에 실리는 하중의 크기, 위치, 방향을 정확히 계산하여 설계가 제대로 되었는지 검증해준다. 화학, 재료 공학, 건축 공학, 심지어 우주 공학(위성이 있어야 GPS 측정이 가능하니까)까지 모두 동원되어 이 설계가 문제가 없는지 실제로 건축 가능한지를 검증해준다. 엔지니어를 자극하는 그야말로 첨단기술의 향연이다.

언뜻 보면 화려하고 최첨단으로 보이는 소프트웨어는 현재 어느 수준일까? 소프트웨어의 역사는 컴퓨터가 만들어지기 전에 시작됐다. 앨런 튜링(Alan Turing)이 기계적으로 계산가능 한 것들에 대해서 논문을 발표한 것이 1930년대 말이다. 넉넉히 잡아도 80년 역사 밖에는 되지 않았다. 인류의 진보가 최근에 기하급수적으로 일어났다는 사실을 감안해도 건축학의 역사에 견주기에 한참 모자라다. 안전한 소프트웨어 개발의 기반이 되는 프로그래밍 언어와 소프트웨어 공학은 아직 먼 길을 떠나야 한다.

복잡한 소프트웨어를 개발하는 과정을 초고층 빌딩을 짓는 과정에 비교해보자. 전반적으로 소프트웨어의 개발과정이 보다 추상적이며 모호하다. 소프트웨어 개발은 설계단계에서 할 수 있는 것이 건축학에 비교해서 많지가 않다. 소프트웨어 개발 대상은 요구사항에 의해 결정되며, 건축설계사가 하는 역할은 프로젝트 리더나 개발팀장이 맡는다. 요구사항을 내는 주체는 대부분 상대적으로 전문 지식이 부족하다. 그래도 건축물은 눈에 보이는 결과물이 있기에 서로 조정을 구체적으로 할 수 있다.

반면 소프트웨어는 결과물이 소스코드이기 때문에 요구 사항을 내는 주체에게는 보이지 않는 것과 마찬가지다. 건축물은 설계를 할 때 빠짐없이 설계하는 것이 가능하다. 각 층마다 어떤 구조를 가져야할 지 빠짐없이 모든 공간을 다 기술하면 된다.

그러나 소프트웨어는 모든 부분을 기술하기가 어렵다. 어느 부분이 빠졌는지 알 수가 없다. 게다가 건축물은 짓고 있는 도중에 요구사항이 변경되는 일은 거의 없지만 소프트웨어 개발 중에는 요구사항이 바뀌는 경우가 빈번하다. 눈에 보이지 않기 때문에 빠뜨리는 혹은 실수한 요구사항이 있는 경우가 개발이 진행되면서 드러나기도 한다. 요구 사항을 바꾸는 주체는 소프트웨어는 ‘소프트’하니깐 변경하기 쉬울 것이라 말하기도 한다. 하지만, 개발 중인 소프트웨어는 짓고 있는 건축물과 마찬가지로 변경하기가 쉽지 않다.

소프트웨어는 창조적 활동이다

소프트웨어를 직접 구현하는 개발과정도 어렵기는 마찬가지다. 프로그래밍은 창조적인 활동이다. 1부터 100까지의 정수의 합을 구하라는 비교적 명백한 요구사항에 대해서도 개발자마다 작성한 결과물이 다 다를 수도 있다. 1부터 100까지 다 일일이 더해서 작성할 수도 있고(실제 개발자가 이렇게 개발하지는 않겠지만), 대부분의 경우 프로그램 loop를 써서 변수의 값을 1부터 100까지 1씩 증가시키면서 더하는 식으로 작성할 것이다. 혹은 loop 대신에 재귀 함수(Recursive Function)를 사용할 수도 있다.

고등학교 수학을 기억하는 사람은 등차수열의 합 공식을 사용할 테고, 답을 외우고 있는 사람은 5050이라고 적을 수도 있다. 재사용성을 고려하는 개발자라면 함수를 만들어서 인자를 받아 나중에 100까지의 합이 아니라 1부터 어떤 수의 합이라도 구하는 프로그램을 만들 수 있다. 보다 숙련된 프로그래머라면 모든 예외사항을 고려해서 작성할 것이다.

건축물을 짓는데 비유하면 모든 인부들이 각자의 방식으로 건물을 짓고 있는 것이다. 벽을 쌓으려고 할 때 어떤 사람은 벽돌을 수직으로 쌓는데 또 다른 사람은 수평으로 쌓기도 한다고 볼 수 있다. 통제가 어려울 수밖에 없다. 그렇게 쌓은 벽은 군데군데 벽돌이 빠져 있기도 하고, 어떤 부분은 너무 많이 쌓여 있어 삐져나오기도 한다. 설계단계에서 완벽한 설계가 어렵다 보니 구현 단계에서 통제가 더욱 힘들어 진다.  

소프트웨어는 검증하기도 어렵다. 건축물이 설계단계에서부터 최첨단 과학기술에 의해 검증 받아 구현이 시작되는 것에 비하면 한참 미개하다. 소프트웨어를 검증하는 기술은 프로그래밍 언어와 소프트웨어 공학을 연구하는 과학자들이 연구하고 있지만 아직 갈 길이 멀다. 프로그래밍 언어학자들이 프로그램이 명세와 일치하게 구현되었는가를 자동으로 검증하는 방법에 대해 오랫동안 연구하고 있지만, 대부분의 경우 프로그램으로 다른 프로그램을 자동으로 완벽하게 검증하는 것은 불가능하다. 그 유명한 정지 문제(Halting Problem)를 풀 수 없는 사실에 의해 증명된다.

정적 프로그램 분석으로 소프트웨어의 취약점을 찾아내는 기술이 발달하여 정적 프로그램 분석을 전문으로 하는 업체들이 나오기 시작한 것도 불과 10여년 정도 밖에 지나지 않았다. 소프트웨어 공학자들은 소프트웨어 개발 프로세스를 연구해서 문제를 해결하려 노력한다. 전통적인 V 모델 소프트웨어 개발 프로세스가 이에 해당한다. 단계별로 테스팅을 해서 문제를 해결하려 하지만 테스팅도 모든 테스트 케이스를 만들 수 없다는 근본적인 한계를 갖는다. 요구사항 분석과 설계만으로는 완벽한 소프트웨어 개발을 보장할 수가 없다.

소프트웨어 취약성을 막아주는 시큐어코딩

결국 소프트웨어 개발 프로세스에서 가장 중요한 단계는 소프트웨어 결과물을 만들어내는 코딩단계이다. 훌륭한 프로그래머라면 요구 사항이 변경될 수 있다는 여지, 재사용성, 예외상황, 소프트웨어의 취약성을 고려해서 프로그래밍을 해놓는다. 하지만 이 많은 것을 모두 고려하기란 불가능하다. 또, 모든 개발자가 훌륭한 프로그래머일 수도 없다. 개발자들이 훌륭한 프로그래머로 성장할 수 있는 기회를 주면서도 안전한 소프트웨어를 만들 수 있도록 도와줘야 한다.

소프트웨어 선진국인 미국은 오래 전부터 여러 기관에서 다양한 종류의 소프트웨어 취약성을 연구해 왔으며, CERT, CWE, OWASP 등이 그 결과물이다. 종류가 천 개도 넘는 소프트웨어 취약성을 정리해서 공개해 놓았다. 개발단계에서부터 이런 취약성이 없도록 개발하는 것을 시큐어코딩(Secure Coding)이라고 한다. 2012년부터 우리나라에서도 안전행정부에서 시큐어코딩을 발표해서 의무화하고 있다. 하지만, 아무리 노련한 프로그래머라도 수많은 취약성들을 모두 고려하며 개발하기란 여간 어려운 일이 아니다.

효과적인 개발 도구 선택이 당락 결정

소프트웨어 개발 단계에서부터 자동으로 시큐어코딩 위배 사항을 검출하기 위해서는 정적 프로그램 분석 도구를 사용해야 한다. 소스코드 상에서 위배 사항이 어떤 것인지 어떤 원인으로 위배가 되었는지를 알려주기 때문에 개발자가 수정하기 쉽다. 수많은 시큐어코딩 위반 사항에 대한 정보를 가지고 있기 때문에 소스코드 수정 과정에서 개발자를 교육시키는 효과도 있다.

정적 프로그램 분석기술은 학계에서 선도하고 있는 최첨단의 기술이므로 깊이가 없는 정적 프로그램 분석도구를 도입하는 경우에 오히려 소프트웨어 개발비용이 증가할 수 있다. 정적 프로그램 분석도구를 선택할 때는 다음의 세 가지 기준을 가져야 한다.

첫째, 다양한 소프트웨어 취약성을 모두 지원할 수 있어야 한다. 보안 취약성, 실행 오류, 코딩 표준을 지원하는 정적 분석 도구를 따로 구매하면 비용도 증가하고 관리도 어려워진다. 따라서 세 가지 영역을 모두 지원하는 포괄적인 정적 분석 도구를 선택해야 한다.

둘째, 같은 종류의 오류를 검출하더라도 얼마나 복잡한 오류를 얼마나 정확히 검출을 하느냐가 중요하다. 오탐(실제 오류가 아닌데 오류라고 하는 경우)과 미탐(실제 오류인데 도구가 검출 못하는 경우)이 적도록 분석을 깊이 있게 하는 정적 분석 도구여야 한다.

마지막으로 소프트웨어의 전반적인 품질을 지속적으로 관리할 수 있는 기능을 갖추고 있어야 한다. 이 세 가지 기준을 모두 충족하는 비용 대비 효과적인 개발 도구를 선택해야 개발 단계에서 소프트웨어의 보안성과 품질 모두를 향상 시킬 수 있다.

[글_ 장 영 범 파수닷컴 PA사업부 개발팀장/박사(yb@fasoo.com)]

<저작권자: 보안뉴스(http://www.boannews.com/) 무단전재-재배포금지>