보안 업계에서는 현재 개발자들에 대한 관심도가 높아지고 있다. 애플리케이션 보안 때문에 안전한 개발 방법론들도 등장하고 있다. 그런데 문제는 개발자들이 보안을 모른다는 것만이 아니다. 보안 담당자들도 개발자들을 잘 모르고 있다.

[보안뉴스 문정후 기자] 애플리케이션 보안 전문 업체의 창립자이자 수석 아키텍트로서 필자는 이 분야의 변화 과정과 개인적인 발전 여정을 통해 많은 스타트업들의 성장을 지켜볼 수 있었다. 예를 들어 2008년 이스라엘 내에서 보안 표준 중 하나인 PCI-DSS가 기업들의 필수 도입 요소가 되었을 때, 필자는 초기 인증서 발급 및 수여 과정에 관여해 기업들의 여러 가지 대응 전략을 현장에서 살필 수 있었다.


당시 필자는 애플리케이션과 관련이 있는 PCI의 요소들을 주로 담당했었다. 어느 한 오후, 이스라엘에서 가장 큰 의료 서비스 업체에 마련된 사무실에 앉아서 표준 도입과 관련된 여러 가지 질문들과 그에 대한 답들을 점검하고 있었다. 검토해야 할 것들은 끝도 없었다. 지루한 그 일과가 도무지 끝날 것 같지 않았다. 원래 이런 정보들을 통해 전체를 꿰뚫어 보는 통찰을 얻어냈어야 했는데, 솔직히 그날 퇴근을 하면서 난 내가 얻어낸 통찰이 무엇인지 도무지 감을 잡을 수가 없었다.

이런 일이 반복되자 한 가지 분명해지는 사실이 있었다. 기업들에 요구되는 보안 표준들이 현실과 맞지 않는다는 것이다. 2008년 당시의 현실과 보안 표준은 너무나 동떨어져 있었고, 솔직히 지금도 우리에게 비슷한 문제가 없다고 말할 수 없다. PCI-DSS라는 표준은 통합적인 증거 수집을 요구하고 있었고, 모든 자산들의 다각도적인, 그리고 과하기까지 한 평가 역시 필요로 했다. 그러니 적응하는 데에 수년이 걸릴 수밖에 없었고, 기업들은 우리 같은 감사원들에게 끝없는 질문을 할 수밖에 없었다.

유행어의 탄생
그 당시 SSDLC라는 유행어가 유행하기 시작했다. SSDLC는 ‘보안 소프트웨어 개발 생애 주기(Secure Software Development Life Cycle)’의 준말이었다. 보안을 개발의 모든 단계에 접목시킨다는 개념으로, 보안 담당자들의 전문성을 초기 단계에서부터 반영함으로써 실수를 줄이고 개발을 보다 온전하게 만드는 것을 추구했다. 많은 기업들이 SSDLC를 표방했다. 그 당시 클라우드와 모바일 애플리케이션의 활용률이 막 올라가고 있던 참이었다. 그러면서 SSDLC는 데브옵스와 데브섹옵스로 발전했다.

그러다가 프라이버시가 모든 기업들을 뒤흔들기 시작했다. GDPR이라는 희대의 프라이버시 규정이 등장하더니 세계 곳곳에서 아직도 그와 비슷한 것들이 나오고, 또 도입되는 중이다. 프라이버시 보호를 고려하지 않은 설계에는 크나큰 대가가 따르기 시작했다. 새로운 규정들이 등장할 때마다 필요한 준법 사항들을 전부 반영하는 것이 얼마나 중요한지 깨달은 조직들은 너도 나도 표준을 공부하고, 그것을 새로운 사업에 처음부터 적용하기 시작했다. 하지만 표준들은 끝도 없이 등장하고 있어 기업들의 골치를 썩게 만든다.

지난 20여 년 동안 애플리케이션들을 만지작거렸던 사람들이라면 이런 식의 흐름이 전부 기억날 것이다. 그리고 이 모든 것들을 지키려고 많은 노력을 기울여 왔을 것이다. 하지만 지금쯤이면 깨닫고도 남음이 있었을 것이라고 생각한다. 정말로 모든 단계에 보안을 빠짐없이 적용한다는 게 얼마나 어려운지 말이다. 아무리 보안 표준과 규정을 다 지킨다고 해도 해커들은 언젠가 반드시 뚫어낸다는 것도 말이다. 해커까지 가지 않아도 된다. 모의 해커들만으로도 충분하지 않던가. 솔직히 말해 고장 없이 제대로 작동하는 애플리케이션을 만드는 것만으로도 개발자들에겐 벅찬 일이다. 거기다가 각종 보안 규정을 반영하고 해킹을 당하지 않게 하라니, 가혹한 요구다.

간단히 말해 그러한 보안 관련 표준과 규정들을 애플리케이션 개발 프로세스에 100% 반영하려면 지금보다 더 많은 인력이 필요하다. 모든 조직들에 해당하는 말이다. 지금 개발자들이 떠안은 업무량은 현재의 개발자들의 수로도 이미 벅차다. 과도하게 일이 많아진 지금의 상황 가운데, 누가 옆에서 자꾸 보안을 가지고 프로젝트를 구겨버리면 사이가 좋아질 수가 없다. 개발자와 보안 담당자의 사이가 좋지 않은 건 이런 구조적인 이유 때문이다.

당신의 머릿속에 들어가
솔리윈즈(SolarWinds) 사태를 일으킨 해커들처럼 수준이 높은 공격자들은 개발자들이 어떤 식으로 생각하고 움직이는지를 잘 이해하고 있다. 그리고 그에 맞춰 고급 공격 도구들과 취약점 익스플로잇을 기획하고 만든다. 심지어 소프트웨어가 만들어지는 공정 또한 잘 이해하고 있기 때문에 개발이라는 업무 행위 자체의 취약점도 잘 파고든다. 소프트웨어 해킹 공격이란, 결국 개발자의 실수를 찾아서 찌르고 들어오는 건데 개발자를 잘 아는 공격자들은 당연히 우위에 설 수밖에 없다.

물론 개발자들이라고 해서 아무런 대책이 없는 건 아니다. 보안에 대한 교육을 충분히 받고, 내부적으로 원활하게 소통하며, 사고방식 기저에 보안을 깔아두고, 각종 실천 사항을 준수하면 된다. 하지만 이는 이상론이며, 실제로 이 모든 것들을 빠짐없이 해내기란 불가능에 가깝다. 꿈의 방어일 뿐, 실질적인 대책이 되지 못한다.

개발자들은 ‘보안’을 따로 떨어트려 놓고 고민하는 사람들이 아니다. 개발자들의 머릿속은 기능과 마감, 속도로 꽉 차있는데, 이는 이들이 무언가를 만들어내야 하는 사람들이며, 따라서 제작 경험을 필요로 하고, 사용하는 사람의 입장을 끊임없이 생각해야 하기 때문이다. 그런 맥락 가운데 ‘내가 만든 애플리케이션의 보호’가 없을 수 없다. 즉 애써 만든 애플리케이션이 고장이 나지 않고, 사용자의 목적이 달성되고, 회사의 사업이 잘 되기를 바라는 차원에서 보안을 생각한다는 것이다.

보안 담당자들은 개발자들이 애플리케이션 보호를 위해 투자하는 노력과 시간을 평가절하하는 경우가 많은데, 보안에 대하여 생각하는 맥락이 보안 담당자와 다를 뿐 개발자들 역시 애플리케이션이 올바로, 안전하게 작동하기를 그 누구보다 바라는 사람임을 잊지 말았으면 한다.

한 번은 천 명이 넘는 개발자들과 함께 한 기업의 프로그램을 제작해야 하는 프로젝트가 있었다. 수십 시간의 회의를 지나서 프로젝트 참여자들은 프로그램의 보안 수준에 대해 동의할 수 있었다. 합의점에 이르자 대장 엔지니어가 미소를 띄며 나에게 말했다. “보안은 항상 주인공이 되고 싶어 한다니까요!” 난 그가 무슨 말을 하려는지 정확히 이해할 수 있었다. 그러면서 큰 깨달음이 왔다. 보안은 항상 양치기 소년과 같은 역할을 해야 한다는 것을 말이다. 그들이 응하던 응하지 않던 항상 도움을 요청하는 그런 존재랄까.

개발자들은 취약점들에 대해 대수롭지 않게 여기는 경우가 꽤나 많다. 제로데이 취약점 정도 되지 않는다면 ‘호들갑 떨지 않고 그냥 고치면 되는 문제’ 정도일 뿐이다. 그래서 보안 담당자들은 취약점 하나가 얼마나 큰 위험을 초래할 수 있는지 귀가 아프게 설명하고 또 설명해야 한다. 양치기 소년처럼 도와달라고 외쳐야 한다. 개발자들 스스로가 취약점에 호들갑을 떨며 반응하기를 기다리지만 아무런 반응이 없으니 개발자들의 보안 인식 수준이 낮다는 둥 하는 이야기가 나오는 것이다. 취약점 때문에 사이렌을 울리는 건 보안의 몫이다. 개발자들이 어떻게 반응을 하던 상관 없이 말이다.

글 : 첸 구어아리(Chen Gour-Arie), 수석 아키텍트, Enso Security
[국제부 문정후 기자(globoan@boannews.com)]

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