"레프트 오브 레프트"로 시작하기: 보안 코드는 항상 품질 좋은 코드일까?

이 기사의 일부 내용은 Dark Reading에 게재되었으며, 업데이트를 거쳐 이곳에 다시 게시되었습니다.

개발자들에게 보안에 대해 이야기할 때 제가 항상 강조하는 말은 "품질 좋은 코드만이 보안 코드다"라는 것입니다. 이 말은 여전히 유효합니다. 90년대에는 취약한 소프트웨어가 세상에 나와도 운 좋게 재앙을 피했을지 모르지만, 오늘날에는 그런 위험을 감수할 가치가 없습니다. 지난 수년간 많은 이들이 개발자들에게 보안 의식을 심어주기 위해 노력해 왔으며, 그 결과 개발자들이 스스로 코드를 평가할 때 보안을 품질과 동일시하게 되었기를 바랍니다.

하지만 돌이켜 생각해보면(동료들과의 토론을 거쳐보니), 이는 다소 개념을 지나치게 단순화한 것일지도 모릅니다. 보안은 확실히 갖추었지만, 초보적인 개발 기법을 사용했거나 그 외의 문제점들로 인해 이상적이라고 보기 어려운 코드를 만드는 것은 충분히 가능한 일이기 때문입니다.

우리 업계에서는 '시프트 레프트(shifting left)'라는 개념을 자주 언급합니다. 제 생각에 이는 엔지니어링 팀이 보안(품질의 한 측면)에 대한 책임을 공유하도록 하고, 흔한 취약점들을 그들의 손끝에서 바로 제거할 수 있는 권한을 부여함으로써 '왼쪽에서 시작'하는 것이 핵심입니다. 하지만 현재의 난제를 고려할 때, 이제는 그 범위를 조금 더 확장해야 할 필요가 있어 보입니다.

일정 수준 이상의 품질을 갖춘 코드는 정의상 보안성도 뛰어나지만, 보안성이 뛰어난 모든 코드가 반드시 고품질인 것은 아닙니다. '왼쪽보다 더 왼쪽(left of left)'에서 시작하는 것이 완벽한 보안 코딩 표준을 보장하는 공식일까요?

'품질이 낮은' 보안 코드란 어떤 모습일까요?

이 코드 조각을 자세히 들여다봅시다.

보안 관점에서 이 코드를 분석해보면, 이 조각은 확실히 안전하며 공격자가 SQL 인젝션 취약점을 악용할 수 있는 진입점이 아닙니다.

그렇다면 이것이 고품질 코드의 예시일까요? 안타깝게도 그렇지는 않습니다. 인수를 int(정수)에서 String(문자열) 값으로 간단히 변경하기만 해도, 숫자와 달리 자유로운 사용자 입력이 쿼리를 조작할 수 있게 됩니다. 그러한 변경이나, 혹은 다른 곳에서 String sql을 무분별하게 복사해서 붙여넣는 행위는 즉시 SQL 인젝션 취약점이 발생할 수 있는 환경을 조성하며, 그와 관련된 모든 위험을 초래합니다.

여기서 보안 조치는 매우 제한적인 범위에 머물렀습니다. 반면, 더 철저하거나 경험이 많은 개발자라면 다른 접근 방식을 취하고 비효율적인 인수 구조가 미칠 영향을 고려했을 것입니다. 이런 코드를 배포하는 것은 나쁜 관행일 뿐만 아니라, 동료 개발자들에게도 좋지 않은 선례를 남깁니다.

소프트웨어의 '트리플 위협(triple threat)': 형태, 기능, 그리고 요새 같은 보안?

엔터테인먼트 업계에서 '트리플 위협'이란 연기, 춤, 노래를 모두 수준급으로 해내는 사람을 말합니다. 이들은 모든 오디션에서 두려움과 선망의 대상이 되며, 경쟁이 치열한 분야에서 보기 드문 인재들입니다. 모든 산업에는 그 분야의 최고 수준을 보여주는 제품이나 서비스가 존재하며, 소프트웨어 업계도 예외는 아닙니다.

애플리케이션에서 균형을 맞추기 어려운 세 가지 핵심 요소를 꼽자면 기능성/우아함, 철통같은 보안, 그리고 요구되는 배포 속도를 고려한 비용 효율성일 것입니다. 마지막 요소인 비용 효율성은 앞선 두 가지 옵션이 얼마나 잘 적용되는지를 결정짓는 결정적인 요인이며, 시간이 지남에 따라 전체적인 품질이 저하되는 촉매제가 될 수 있습니다.

하지만 모든 소프트웨어가 휴 잭맨처럼 완벽해야 할까요, 아니면 니콜라스 케이지 정도로도 충분할까요? 이렇게 생각해보세요. 만약 울버린을 팀에 합류시킬 수 있다면, 최선을 다해 그를 영입해야 합니다.

마틴 파울러는 소프트웨어 개발에서 고품질은 비용을 들일 가치가 있는가?라는 질문을 던지며, 그것이 '가치가 있을' 뿐만 아니라 장기적으로는 오히려 더 저렴하다고 결론지었습니다. 대부분의 사용자는 코드가 엉망인지, 보안이 다른 요소만큼 중요하게 다뤄졌는지 확인하기 위해 내부를 들여다보지 않습니다. 하지만 실무자들은 엉성한 코드를 수정해 새로운 기능을 추가하느라 귀중한 시간을 낭비하거나, 프로젝트의 핵심 부분을 뒤지며 상황을 파악하느라 애를 먹게 됩니다. 최악의 경우, 보안 팀으로부터 지적받은 취약점을 수정하느라 제품 출시가 지연되기도 합니다. 지금 시간을 투자해 보안성과 품질을 모두 갖춘 코드를 만드는 것은 나중에 발생할 수많은 골칫거리를 방지하며, 잘못된 작업을 바로잡는 데 드는 비용도 절감해 줍니다.

숙련된 보안 의식을 갖춘 개발자들은 기능 구현에 있어 창의적인 문제 해결 능력을 유지하면서도, 개발 단계에서 엔지니어가 통제할 수 있는 일반적인 보안 취약점들을 제거하는 코드를 작성합니다. 보안 코드는 단독으로는 큰 효과를 발휘하기 어렵습니다. 그렇기에 '왼쪽보다 더 왼쪽'에서 시작한다는 개념은 개발자들에게 보안을 제2의 천성으로 여기는 문화를 조성하고, 위험을 줄이면서도 놀라운 기능을 제공할 수 있는 역량을 키우는 데 도움을 줄 것입니다.

'왼쪽보다 더 왼쪽'에서 시작하는 것은 안전한 사용자 경험을 위해 필수적입니다.

보안은 오랫동안 소프트웨어 사용자 경험에서 고려 대상이었지만, 그 결과는 분명 엇갈렸습니다. 보안 설정 오류는 지난 한 해 동안 발생한 클라우드 기반 데이터 유출 사고의 21%를 차지했습니다. 비밀번호를 평문으로 저장하는 것과 같은 아마추어적인 실수는 생산성, 수익, 그리고 고객 신뢰 측면에서 해당 기업들에 심각한 손실을 초래했습니다.

게다가 사용자 스스로가 자신의 데이터를 보호하는 데 있어 가장 큰 적이 되기도 합니다. 너무나 많은 사람들이 여전히 비밀번호를 "password"로 설정하거나, 여러 중요한 계정에 동일한 비밀번호 조합을 사용하고 있습니다.

로그인 화면을 작업하라는 지시를 받고 기뻐하는 개발자는 본 적이 없습니다. 그럴 만도 한 것이, 강력하면서도 기능적이고, 사용자가 최소한의 불편함으로 직관적으로 이용할 수 있는 보안 흐름을 설계하는 것은 매우 까다로운 균형 잡기이기 때문입니다.

복잡한 단계와 제한을 너무 많이 추가하면 사용자가 아예 떠나버릴 수 있고(신규 앱에는 치명적입니다), 너무 혼란스럽게 만들면 계정 접근 문제로 문의하는 사용자들을 상대하느라 지원 팀이 골머리를 앓게 될 것입니다. 반대로 너무 쉽게 만들면 보안이라는 본연의 목적을 달성하지 못하게 됩니다.

성공적인 보안 사용자 경험은 소프트웨어의 매력을 해치지 않으면서도 논리적인 흐름 속에 탄탄한 보안을 녹여내는 것입니다. 물론 온갖 복잡한 비밀번호 요구 사항, 캡차, 미니 게임, 좀비 방어전 같은 요소를 넣어 보안 로그인 기능을 구현할 수는 있겠지만, 사용자가 외면할 만큼 엉망이라면 본질을 놓친 것입니다.

소프트웨어 우수성을 위한 기반을 다지세요.

저 또한 개발자로서 대다수의 개발자가 자신의 작업에 자부심을 느끼며 올바른 방향을 추구한다는 것을 잘 알고 있습니다. 시간 제약, 갑작스러운 목표 변경, 긴급한 핫픽스와 같은 예상치 못한 변수들이 흐름을 방해하고 실수를 유발할 수 있지만, 냉정하게 말해 많은 소프트웨어 엔지니어들이 성공할 수 있는 환경을 갖추지 못한 것이 현실입니다.

‘레프트 오브 레프트(left of left)’로 시작하는 것은 개발자 중심의 개념이며, 조직이 엔지니어링 팀의 역량을 강화하는 데 진지하게 임할 것을 요구합니다. 보안 의식을 갖춘 개발자는 무엇과도 바꿀 수 없는 귀중한 자산입니다. 교육, 적절한 도구 제공, 숙련된 개발자의 멘토링 기회와 같은 지원은 보안을 최우선으로 생각하며 정교하고 세심하게 코드를 작성하는 환경을 조성하여 소프트웨어를 한 단계 더 발전시킬 것입니다.

보안 코딩에 대한 열정을 불태울 준비가 되셨나요? 도전에 나서보세요.

‍