[CIO BIZ+/기고]시큐어코딩 내재화를 생각할 때

관련 통계자료 다운로드 시큐어 코딩 적용 프로세스

작년 11월 `Darwinare`라는 이름을 사용하는 해커에 의해 호주 국방대학 2만2500여개 개인 정보 기록이 유출돼 웹 사이트에 공개되는 사건이 발생했다. 여기에는 직원·학생들의 사용자 계정, 평문 형태의 암호, 생년월일 등 매우 중요한 개인 정보가 포함돼 있다. 이 해커는 `SQL 삽입`이라는 널리 알려진 고전적 방법을 사용했다. 그럼에도 불구하고 아무런 제약 없이 3분 만에 모든 정보를 얻을 수 있어서 스스로도 매우 놀랐다고 한다.

SQL 삽입은 데이터베이스(DB)와 연동된 웹 애플리케이션에서 사용자가 입력한 데이터 값의 유효성 검증을 제대로 하지 않을 경우, 공격자가 악의적 SQL문을 입력해 DB로부터 임의로 정보를 열람하거나 조작할 수 있는 보안 약점을 말한다.

이같은 보안 약점이 내포된 소프트웨어(SW), 특히 웹 애플리케이션은 해커의 공격 목표가 돼 심각한 보안 위협을 초래할 수 있다. 만일 호주 국방대학의 웹 애플리케이션이 SQL 삽입 보안 약점에 대비할 수 있도록 시큐어 코딩을 적용해 개발됐다면 해커에 의한 개인 정보 유출을 미연에 방지할 수도 있었을 것이다.

◇운영 단계 결함 제거는 큰 손실

지난해 6월 행정안전부 `정보시스템 구축 및 운영 지침`이 개정·고시되면서 지난 12월부터 40억원 이상 전자정부 서비스 개발 시 시큐어 코딩 적용이 의무화됐다. 시큐어 코딩은 SW 개발 과정 중 소스 코드 구현 단계부터 보안 약점을 배제하기 위한 개발 기법이다.

행정안전부는 이미 2009년부터 전자정부 서비스 개발 단계에서 SW 보안 약점을 진단해 제거하는 시큐어 코딩 관련 연구를 진행했다. 지난해까지 전자정부 지원사업 등을 대상으로 보안 약점 시범 진단을 수행한 바 있다. 이런 성과를 토대로 상기 고시를 통해 필수 제거 대상 보안 약점 43개를 발표했다.

SW가 개발 완료돼 운영 및 서비스 단계에 들어서면 결함을 발견해도 이를 교정하기 위해서 매우 많은 노력과 비용이 소요된다. IBM 보고서에 따르면 운영 단계에서의 결함 제거 비용은 개발 단계보다 60∼100배 소요된다. 따라서 보다 근본적이고 효과적인 대처 방법은 개발 단계부터 보안성을 고려해 SW를 구현하고 보안 취약점을 배제하는 것이다.

시큐어 코딩 도입은 개발자에게 안전한 코딩 기법을 교육하고 개발자가 구현한 소스 코드에 보안 취약점이 내포돼 있는지 검사하는 것이다. 소스 코드 보안 약점을 사람이 직접 검사하는 것에는 명확한 한계가 있다. 소스 코드만 있으면 비교적 짧은 시간 안에 자동화된 방법으로 보안 약점을 진단할 수 있는 `소스 코드 정적 분석 도구`의 활용이 반드시 필요하다.

물론 정적 분석 도구가 모든 보안 취약점을 100% 정확하게 잡아 낼 수 있는 것은 아니다. 하지만 수작업 검사의 한계와 동적인 모의 해킹 방식이 가지는 제약 때문에 많은 기업과 기관이 소스 코드 보안 취약점 진단 도구를 도입했거나 도입하고 있다.

◇소스 코드에 대한 전사 관리체계 필요

상식적인 얘기지만 소스 코드 보안 취약점 진단 도구만 도입한다고 해서 시큐어 코딩이 저절로 정착되는 것은 아니다. 보안팀에서 정기적으로 개발팀이나 품질관리팀이 제출한 소스 코드에 대해 보안 취약점 진단 후, 그 결과를 통보해 발견된 보안 취약점을 수정하도록 권고만 하는 방식에는 맹점이 있다. 혹은 개발팀이 정기적으로 시큐어 코딩 적용 여부를 검사한 후 그 결과만 보안 팀에 전달하는 방식에도 맹점이 있다. 소스 코드에 대한 전사적 관리 체계 안에 보안 취약점 진단이 내재화 돼야 한다. 즉 각 팀 사이의 협조·관리 프로세스에 대한 시스템적 제어 장치가 없다면 소스 코드 보안 취약점 진단이나 시큐어 코딩이 단순한 이벤트성 업무로 전락할 수 있다는 의미다.

소스 코드 중요성을 인지하고 제대로 관리하는 기업은 품질 조직을 별도로 갖추고 통합 품질 관리 시스템을 구축해 운영하고 있다. 이런 통합 시스템 안에는 대개 형상관리, 변경요청 관리, 개발 표준 및 소스 코드 품질 자동 검사, 소스 코드 변경 영향 분석 등 기능이 통합돼 애플리케이션 개발과 변경 프로세스 단계 별로 필요한 액션들을 취한다.

여기서 지적하고 싶은 것이 있다. 보안 취약점 진단이 보안 팀의 별도 영역이라는 이유로 품질 관리 조직을 중심으로 이미 잘 갖춰진 소스 코드 관리 체계와 프로세스 밖에서 수행된다면 앞서 지적한 폐해가 발생할 수 있다는 점이다.

◇보안과 품질관리 동시에 추진

이런 관점에서 요즘 기업들은 품질 관리 워크플로우 시스템 안에서 시큐어 코딩이 자연스럽게 녹아들 수 있는 단일 관리 체계와 프로세스를 적용하고 있다. 개발자들이 각각 소스 코드 개발과 변경 작업을 마친 후 스스로 보안 취약점 진단을 수행하며 미리 정해 놓은 일정 기준을 통과해야 한다. 이후 품질 관리 워크플로우의 다음 단계로 진행할 수 있도록 하고, 정기적으로 전체 소스 코드에 대한 일괄적인 보안 취약점 진단 단계를 추가하는 것이 하나의 예다.

이를 위해서는 형상관리 솔루션, 요청 관리 워크플로우 솔루션, 소스 코드 품질검사 솔루션 등과의 효율적인 시스템 연계가 중요한 고려 요소다. 특히 각 기업의 고유 개발 표준 및 코딩 베트스 프랙티스 준수 여부를 중점적으로 검사하는 소스 코드 품질 검사와 보안 취약점 검사가 이중화 될 수 있다는 점에 주목할 필요가 있다.

이는 실제 사용자 편의성 관점에서 시큐어 코딩 내재화에 걸림돌로 작용할 수도 있다. 동일한 소스 코드에 대해서 보안 취약점과 품질 측면을 이중으로 검사해야 하는 비효율성이 존재하기 때문이다. 이런 이유로 근래에 시큐어 코딩 솔루션을 도입하는 금융 기업들은 소스 코드 보안 취약점과 품질을 이중 작업으로 진단하지 않고 단일 환경 안에서 한 번에 양 측면을 모두 진단할 수 있는 제품 아키텍처를 선호하고 있다.

한 조직에서 시큐어 코딩이 제대로 정착되고 내재화 되려면 애플리케이션에 대한 보안 관리와 품질 관리가 따로 따로 추진돼서는 안 된다. 전사적 관점에서 단일화된 관리 체계 안에서 함께 추진되어야 한다. 또 각자의 고유 환경에 가장 적합한 방식으로 이를 실행할 수 있는 시스템적 프로세스 제어 장치가 마련되어야 한다. 그렇지 않으며 시큐어 코딩이 요식 행위에 지나지 않게 돼 애플리케이션을 통한 보안 사고를 미연에 방지하고자 하는 본연의 도입 목적을 달성하기 어렵다.

권현준 지티원 정보기술연구소장(hjkwoen@gtone.co.kr)