개발자는 "보안 코딩"을 어떻게 정의할까요?

이 기사의 일부 내용은 TechRepublic에 게재되었습니다. 해당 내용은 업데이트되어 이곳에 다시 게시되었습니다.

‍

보안 팀과 개발 팀의 목표를 일치시키는 환경을 조성하는 것은 어렵지만 필수적인 싸움이었습니다. 아직 갈 길은 멀지만, 소프트웨어 보안에 대한 공동 책임을 실현하기 위해 필요한 시너지를 가로막는 장애물들이 분명해지고 있습니다. 현명한 기업들은 이러한 함정을 피하고 생산적인 발전 방향을 찾으며, DevSecOps를 통해 인적 자원의 잠재력을 최대한 활용하는 전략을 추구합니다.

제가 예상하지 못했던 점은 무엇이 안전한 코딩을 구성하는지에 대한 인식 자체가 논쟁의 대상이라는 사실입니다. Evans Data와 협력하여 진행한 최신 연구에 따르면 이러한 정서는 명확하게 드러났습니다. 2022년 개발자 주도 보안 현황 설문조사는 1,200명의 현직 개발자가 가진 핵심 통찰과 경험을 깊이 있게 다루며, 보안 영역에 대한 그들의 태도와 과제를 조명합니다.

주요 결과 중 하나는 개발자의 14%만이 코딩 시 보안을 우선순위로 고려한다는 점이었습니다. 이는 개선의 여지가 매우 크다는 것을 보여주는 동시에, 개발자 세계에서는 기능 구현이 최우선이며 보안을 개발의 본질로 삼기에는 여전히 준비가 부족하다는 사실을 확인시켜 줍니다. 그러나 개발자들이 안전한 코딩을 어떻게 정의하는지에 대한 데이터와 결합해 보면 이는 우려스러운 일입니다.

이러한 인식은 개발자의 일상적인 업무 경험에서 비롯되며, 많은 조직의 환경을 대변합니다. 즉, 개발자들이 일반적인 취약점과의 싸움에서 핵심적인 위치에 있지 않다는 것입니다. 개발자의 역량 강화는 매우 중요하지만, 그동안 우리는 '안전한 코딩'의 범위와 보안 기술을 갖춘 개발자에게 무엇을 기대해야 하는지에 대해 빠르게 합의점을 찾아야 합니다.

우리는 개발자의 세계에서 보안이라는 개념을 더 쉽게 이해할 수 있도록 만들어야 합니다.

사이버 보안은 언제나 다면적이고 다루기 힘든 거대한 과제이며, 안전한 코딩은 전체적인 환경의 일부일 뿐이지만 시스템 내에서 전문적인 주의가 필요한 복잡한 요소입니다.

설문조사에 따르면 일반적인 개발자에게 안전한 코드 작업이라는 개념은 매우 단편적으로 인식되고 있으며, 그 범위는 종종 근본적인 원칙에 대한 전체적인 시각보다는 특정 범주에 국한되어 있었습니다. 개발자들은 취약점이 없는 새로운 코드를 작성하는 관행보다는 기존의(또는 사전 승인된) 코드를 사용하는 것에 의존한다고 답했습니다. 타사 구성 요소에 대한 보안 인식(특히 패치 작업, Log4Shell 사태가 좋은 예입니다: 12월 이후 30%의 사례가 여전히 패치되지 않음)과 기존 코드 테스트는 매우 중요하지만, 이것만으로는 안전한 코딩 능력을 갖췄다고 볼 수 없습니다.

코드 수준의 취약점은 잘못된 코딩 패턴을 배운 개발자들에 의해 발생하며, KPI에서 안전한 코드 작성에 대한 강조가 부족하고 보안 문화가 미흡한 점은 이러한 관행을 용인되는 표준으로 고착화합니다.

보안 리더들은 개발자들에게 안전한 코딩이 무엇인지 전체적인 그림을 보여줌으로써 초기 인식을 개선하고 가장 시급한 지식 격차를 파악하는 데 큰 도움을 줄 수 있습니다. 사전 승인된 코드를 테스트하고 스캔하는 것도 하나의 기능이지만, 취약점을 줄이려면 현재 사용 중인 언어와 프레임워크를 바탕으로 안전하고 올바른 코딩 패턴에 대한 실무 교육이 필요합니다.

개발자의 역량을 강화할 때는 맥락이 중요하며, 비즈니스의 보안 목표를 달성하는 과정에 개발자들을 동참시켜야 합니다.

많은 조직이 보안 프로그램을 업그레이드해야 합니다.

지난 10년간 소프트웨어 기반 기술이 폭발적으로 성장하면서 사이버 보안 사고도 급증했고, 우리 모두는 귀중한 시스템의 허점을 찾아내려는 공격자들을 막기 위해 분주히 움직이고 있습니다.

DevSecOps 방법론은 개발자를 포함한 모두가 보안에 대한 책임을 공유한다는 아이디어를 바탕으로 하며, SDLC 초기 단계부터 이를 핵심적으로 고려합니다. 문제는 특히 대기업의 경우 DevSecOps를 표준으로 구현하기까지 매우 먼 길을 가야 할 수도 있다는 점입니다. 2017년 프로젝트 관리 협회(Project Management Institute)의 연구에 따르면 조직의 51%가 여전히 워터폴(Waterfall) 방식을 사용하고 있었습니다. 그 연구는 5년이 지났지만, 대기업의 변화 속도를 고려할 때 최신 보안 지향 방법론으로 급격하게 전환되었을 가능성은 낮습니다. 이러한 레거시 프로세스는 사이버 위협으로부터 보호하기 위한 포괄적인 전략을 세우려는 보안 전문가들에게 어려운 과제가 되며, 이 환경에 개발자와 그들의 요구사항을 맞추는 것 또한 도전입니다.

하지만 이를 핑계로 삼을 수는 없습니다. 비즈니스 내 보안 전문가들은 향상된 전략 속에서 개발자들을 활용할 수 있습니다. 단지 그들의 요구사항을 파악하고 방어 전략의 일부로 고려하기만 하면 됩니다. 개발자들에게는 포괄적인 교육이 필요하며, 보안에 대한 모든 책임은 그들의 기술 스택과 워크플로우를 존중하는 방식으로 구현되어야 합니다.

안전한 코딩 = 너무 어려운 일?

Evans Data의 조사에 따르면 개발자의 86%가 보안 코딩 실천에 어려움을 겪고 있으며, 개발 관리자의 92% 또한 팀에 보안 프레임워크 교육이 더 필요하다는 점을 인정했습니다. 더욱 우려스러운 점은 응답자의 48%가 취약점이 있는 코드를 알고도 그대로 방치한다고 답했다는 사실입니다.

이는 매우 우려스러운 상황을 보여줍니다. 전반적으로 개발자들은 충분하고 빈번한 교육을 받지 못하고 있으며, 올바른 보안 관행과 위생을 접할 기회도 부족한 것으로 보입니다. 행간을 읽어보면, 개발 업무에서 보안을 고려하는 것이 우선순위가 아니라는 문제의 핵심이 드러납니다. 또한, 그들이 받는 교육은 자신감이나 실무 능력을 길러주지 못하며, 취약한 코드를 배포했을 때의 영향력을 이해하는 데도 도움이 되지 않습니다.

Colonial Pipeline 랜섬웨어 공격은 작년 한 해 동안 가장 큰 혼란을 야기한 공급망 보안 사고 중 하나로, 미국 동부 해안 가스 공급의 절반이 기약 없이 중단될 수 있다는 공포를 불러일으켰습니다. 다행히 빠르게 복구되었지만, 업계에는 상당한 불안감이 남았습니다. 이는 일반 대중이 소프트웨어 기반이 아니라고 생각하거나 사이버 공격의 위험이 없다고 여겼던 물리적 세계의 요소가 사이버 사고로 인해 심각한 영향을 받을 수 있음을 실감하게 된 결정적인 순간이었습니다. 이 모든 혼란은 오래되고 패치되지 않은 두 가지 취약점, 그중 하나인 악명 높지만 널리 알려진 SQL 인젝션으로 인해 발생했습니다. 개발자들이 취약한 코드를 배포할 때 무엇이 걸려 있는지 진정으로 이해한다면, 그것이 결코 용납될 수 없는 비즈니스 리스크임을 즉시 깨달을 것입니다.

기능적인 “P-P-T”는 개발자에게만 달려 있는 문제가 아닙니다.

사람(People), 프로세스(Process), 도구(Tools)로 구성된 유명한 “황금 삼각형”은 신중하게 고려된 전략 없이는 달성할 수 없으며, 개발자들의 요구 사항과 어려움을 고려하지 않은 채 그들을 보안 프로세스에 통합할 수는 없습니다.

개발자 주도의 보안을 강화하려면 상당한 문화적 변화가 필요하며, 이는 엔지니어와 보안 팀 모두에게 더 큰 명확성을 제공하는 교육 경로에서 시작됩니다.