모의 해커는 나의 적일까? 개발자가 밝히는 모의 해킹 및 정적 분석 결과에 대한 솔직한 생각

개발자는 평소 깊은 집중 상태에서 촉박한 마감 기한에 맞춰 멋진 기능을 구현하는 모습으로 자주 목격됩니다. 기능 구현은 우리가 가장 좋아하는 업무 중 하나이며, 사실 이는 소프트웨어 개발 수명 주기(SDLC)의 근본적인 결과물입니다.

하지만 앞서 논의했듯이, 우리 중 많은 이들이 여전히 보안 모범 사례보다 기능을 우선시하고 있습니다. 결국 대부분의 조직에서 보안은 다른 사람의 업무로 설정되어 있고, 우리에게 제공되는 적절한 보안 교육은 제한적이기 때문입니다. 모의 해킹 및 정적 분석 스캔 도구(SAST)는 보안 위험을 완화하는 전체 프로세스의 일부일 뿐이며, 우리가 하는 일과는 다소 독립적으로 운영됩니다... 물론, 핫픽스를 위해 코드가 다시 우리에게 돌아오기 전까지는 말이죠.

바로 그 순간 많은 개발자는 이렇게 생각합니다. "모의 해킹 담당자가 나를 싫어하나?"

이러한 상호작용은 종종 팀과 문화를 정의합니다. 우려스러운 점은 소통과 이해, 전반적인 협업의 부족이 적어도 개발자 측면에서는 긴장감을 조성했다는 것입니다. 한번 생각해보세요. 수백 시간을 들여 멋진 조각상을 만들었는데, 누군가 나타나서 기초가 부실하다며 망치로 조각상을 부수기 시작한다고 상상해보세요. 이것이 바로 테스터와 개발자 사이에 인식되는 역학 관계입니다. 개발자는 외부인이 자신과 함께 고생하지도 않은 채 자신의 소프트웨어 결과물을 망쳐놓았다고 느끼며, 오히려 업무량을 늘리고 코드 배포의 만족감을 지연시킨다고 생각합니다.

오래전 보안 분야로 넘어온 저는 양쪽의 입장을 모두 이해할 수 있습니다. 아니요, 모의 해킹 담당자는 개발자를 싫어하지 않습니다. 모의 해킹 담당자 역시 과도한 업무와 압박에 시달리고 있을 가능성이 큽니다. 따라서 코드 수준에서 쉽게 수정할 수 있는 흔한 보안 버그들이 끊임없이 쏟아져 나오면, 정말 심각한 문제를 해결하는 데 필요한 시간과 자원, 집중력을 빼앗기게 됩니다.

저는 항상 모의 해킹 담당자를 부모님 같은 존재라고 생각했습니다. 그들은 여러분이 잘하기를 바라며, 그렇지 못할 때면 화를 내기보다는 실망할 뿐입니다.

이제 여러분의 머릿속에 (다소 불공평할 수도 있는) 이미지를 심어드렸으니, 조금 더 깊이 파고들어 보겠습니다. 개발자들 사이에서 이러한 세계관이 형성된 원인은 무엇일까요?

"당연히 방어적인 태도가 나오죠. 그들이 내 업무 방식을 지적하고 있으니까요!"

자신이 일을 잘못했거나 누군가 자신의 작업을 좋아하지 않는다는 느낌을 좋아하는 사람은 없습니다. 안타깝게도 개발자에게 정적 분석 및 모의 해킹 결과가 돌아오는 것은 성적표처럼 느껴질 수 있습니다. 낮은 점수를 받았지만, 결국 그들의 상사는 소프트웨어에 취약점이 있는지 여부가 아니라, 구현한 기능과 납기 준수 여부로 그들을 평가하기 때문입니다.

안타까운 모의 해킹 담당자 입장에서는 "메신저를 탓하지 마라"는 상황입니다. 개인적인 감정은 없습니다. 그들은 버그를 찾는 임무를 수행했고, 실제로 버그를 찾아낸 것뿐입니다. 물론 사람에 따라 더 까칠한 모의 해킹 담당자도 있을 수 있지만, 그들이 개발 팀을 괴롭히려는 의도는 없습니다(그래서는 안 됩니다). 양 팀이 보안 모범 사례에 대해 같은 기준을 공유한다면 훨씬 수월할 것입니다. 개발자에게 완벽함을 요구하는 것은 아닙니다. 현실적으로 테스트 팀은 개발자가 취약한 코드를 배포하지 않도록 보호하기 위해 존재하는 것입니다.

"그들은 사소한 문제들을 다 고치라고 하는데, 더 중요한 우선순위가 있다는 걸 모르는 걸까요? 그리고 그렇게 신경이 쓰인다면 왜 수정하는 걸 도와주지 않는 거죠?"

사실입니다. 개발자의 최우선 순위는 항상 기능 구현이며, 급격한 디지털화가 이루어지는 이 미친 세상에서는 속도감 있게 진행되어야 합니다. 보안과 안전한 코딩에 개인적인 관심을 가진 개발자들도 있지만, 일반적인 정서는 보안은 "다른 사람의 문제"라는 것이며, 여기에는 필연적으로 모의 해킹 담당자도 포함됩니다.

가장 흔한 취약점들은 사실 해결하기 사소한 문제들입니다. 일단 알고 나면 크로스 사이트 스크립팅(XSS)이나 SQL 인젝션 같은 문제들은 수정하기가 간단합니다. 문제는 많은 개발자가 애초에 이런 취약점을 만들고 있다는 사실조차 깨닫지 못한다는 점이며, 이런 사소해 보이는 문제들이 공격자에게는 기업에 치명적인 문제를 일으킬 수 있는 작은 기회의 창이 된다는 것입니다. Akamai에 따르면 2017년 11월부터 2019년 3월 사이 SQL 인젝션 취약점은 전체 웹 기반 공격 벡터의 65%를 차지했습니다. 20년 넘게 알려진 수정 방법이 존재하는 취약점에 대해 이는 매우 뼈아픈 통계입니다.

일부 모의 해킹 팀은 보안 버그 수정을 지원하기도 하지만, 어떤 팀은 나쁜 소식만 담긴 보고서를 제공하고 개발자가 핫픽스를 작업하기를 기대합니다. 심지어 그 시점에는 개발자가 이미 다른 프로젝트로 넘어간 경우도 있죠. 어떤 경우에는 개발 팀이 수정할 수 없는(혹은 수정할 것으로 기대해서는 안 되는) 버그가 포함된 보고서를 받기도 합니다. 하지만 이는 여전히 결과의 일부여야 하며, 개인적으로 받아들여서는 안 됩니다.

이에 대한 "이상적인 절충안"은 모의 해킹 담당자, 보안 담당자, 개발 관리자가 멘토 역할을 수행하여 팀이 효과적인 교육과 도구를 갖추도록 보장하고, 개별 개발자가 SDLC 초기부터 성공적으로 안전한 코드를 작성할 수 있도록 돕는 것입니다. 양 팀은 건전한 DevSecOps 관행의 일환으로 보안을 처음부터 고려할 수 있도록 중간 지점에서 만나야 합니다.

"나는 인정받는 것보다 훨씬 뛰어난 보안 지식을 가지고 있어요. 이 보고서들은 대부분 오탐이거나 중요하지 않은 것들입니다."

정적 분석은 SDLC 보안 프로세스의 한 요소이며, 정적 분석 스캔 도구(SAST)는 근본적인 역할을 합니다. 그리고 네, 오탐은 이러한 스캐너나 다른 유형(DAST/IAST/RAST)의 스캐너에서 발생하는 문제입니다. 이는 이미 느린 프로세스를 더욱 번거롭게 만들며, 수동 코드 검토를 요구하고 개발자와 모의 해킹 담당자 모두에게 압박을 줍니다. 모의 해킹 담당자들은 부정확한 결과를 피하기 위해 세심하게 사용자 지정 규칙을 설정하고 회사별 지침을 제공하지만, 일부 잘못된 결과가 빠져나가 당황한 개발자 앞에 놓이게 됩니다.

이 과정이 완벽한 것은 아니지만, 또 다른 문제는 많은 개발자가 일반적인 취약점을 지속적으로 완화할 지식이 부족하다는 점입니다. 고등 교육 과정에서 보안 교육이 드물고 현장 교육의 효과도 제각각인 상황에서, 어느 정도의 과신이 작용하고 있다는 점은 충분히 짐작할 수 있습니다(이는 개발자의 잘못이 아닙니다. 업계 차원에서 필요한 역량을 갖출 수 있도록 더 나은 지원을 제공해야 합니다).

"이 애플리케이션이 테스트 대상이 될 줄 몰랐는데, 이제 수정 작업에 발목이 잡혔네요."

업무에 시달리는 엔지니어들은 종종 모의 해커들이 언제든 공격할 기회만 엿보며 애플리케이션을 테스트하고 개발 팀의 노력을 물거품으로 만들려 한다고 생각합니다. 그들이 과도하게 테스트하고, 사소한 것을 트집 잡으며, 불필요한 업무를 늘린다고 느끼는 것이죠.

하지만 문제는 그들 역시 과도한 업무에 시달리고 있다는 점입니다(사실 사이버 보안 인력 부족은 심각한 수준이며 점점 더 악화되고 있습니다). 그들에게는 이유 없이 테스트할 시간적 여유가 없습니다. 테스트 우선순위를 결정하는 것은 모의 해커 혼자가 아닙니다. 경영진이나 고객의 요청, 보안 감사, 또는 버그 바운티 프로그램의 결과로 결정되었을 수도 있습니다.

개발자 입장에서 현재 진행 중인 기능 개발 스프린트를 중단하고 보안 수정 작업에 매달리는 것은 짜증 나는 일입니다. 특히 그 작업이 본인이 작성한 코드가 아닐 때는 더욱 그렇습니다. 이전 팀이나 다른 업체가 업데이트를 담당했을 수도 있죠. 하지만 보안은 모두의 문제입니다. 모든 개발자가 보안 버그를 자신이 직접 만든 것처럼 책임져야 한다는 뜻은 아니지만, 보안이 공동의 책임이라는 점을 인식하고 협력해야 합니다.

앞으로 나아가려면 어떻게 해야 할까요?

때로는 사고방식의 전환만으로도 문제 해결에 큰 진전을 이룰 수 있습니다. 모의 해킹 결과가 좋지 않을 때 개발자가 보이는 냉담한 반응에 대해 이야기했지만, 이를 하나의 도전으로 바꿔보면 어떨까요? 모의 해커를 친근한 경쟁자로 생각하고, 그들의 게임에서 이겨보는 것입니다. 보안을 잘 아는 개발자가 코드를 작성하면서 일반적인 버그를 제거한다면 모의 해커의 업무는 훨씬 어려워질 것입니다. 반대로 보안에 무관심한 개발자는 소프트웨어를 쉽게 뚫어버리는 모의 해커에게 완패하고 말 것입니다.

모의 해커와 개발자가 항상 완벽하게 조화를 이룰 수는 없겠지만, 조직이 보안을 핵심 우선순위로 삼고 팀이 성공할 수 있도록 올바른 지식과 도구를 제공한다면 두 관계는 크게 개선될 수 있습니다. 결국 전사적인 긍정적인 보안 문화가 우선순위인지가 관건이며, 현재 일반적인 취약점과의 싸움에서 밀리고 있는 상황을 타개하려면 반드시 그렇게 해야 합니다.