잘못된 코딩 패턴은 심각한 보안 문제를 야기할 수 있습니다. 그런데 왜 우리는 이를 장려하고 있을까요?

이 글은 DZone에 게재되었던 내용을 업데이트하여 다시 발행한 것입니다.

‍

이제는 영겁의 시간처럼 느껴질 만큼 오랫동안 우리는 소프트웨어 개발 초기 단계부터 보안 모범 사례를 고려하는 "시프트 레프트(Shifting Left)"에 대해 논의해 왔습니다. DevSecOps는 보안 에 대한 공동 책임 의식을 강조하고, 개발자가 코드를 작성할 때 흔한 취약점을 방어할 수 있는 보안 역량을 갖추게 함으로써 큰 도약을 이루어냈습니다.

또한 우리는 개발자의 참여를 유도하고 역량을 강화하기 위해 어떤 보안 코드 교육을 선택하느냐가 매우 중요하다는 사실을 이미 오래전부터 알고 있습니다. 규제 준수만을 목적으로 하는 저효율 솔루션은 미래의 뛰어난 보안 인재를 양성할 수 없으며, 대부분의 보안 인식 전문가들도 이를 잘 알고 있습니다. 역동적이고 맥락에 맞는 학습이 가장 좋지만, 그 안에 담긴 미묘한 차이를 이해하는 것이 무엇보다 중요합니다.

위협 행위자들에 맞서 승산 있는 싸움을 하려면 - 그들은 항상 조직보다 한발 앞서 있습니다 - 개발자들에게 모범 사례를 바탕으로 기술을 지속적으로 쌓아 올리는 계층적 학습을 포함한 종합적인 교육 환경이 필요합니다.

개발자 주도의 방어적 보안 조치가 곧바로 성공을 보장하는 것은 아닙니다.

우리의 철학은 예방적 보안 전략의 중심에 개발자를 두는 것입니다. 이는 코드 수준에서부터 시작됩니다. 보안 기술을 갖춘 개발자는 잘못된 코딩 패턴으로 인해 발생하는 흔한 보안 버그(최근의 파괴적인 사례인 Log4Shell과 같은)를 방어하는 가장 쉬운 길을 제시합니다.

하지만 개발자의 역량을 강화하기 위해 우리가 활용할 수 있는 방어 기법은 교육의 범주가 같더라도 그 방식은 다를 수 있습니다.

예를 들어, 케이크를 굽는 방법을 배우는데 '하지 말아야 할 것'에 대한 지침만 받는다고 상상해 보세요. "너무 오래 굽지 마라", "계란을 잊지 마라"와 같은 말은 해석의 여지가 많고, 결국 Nailed It! 프로그램에 나올 법한 결과물을 만들게 될 위험이 큽니다. 방어적 보안 교육도 마찬가지입니다. 하지 말아야 할 것만 알려주는 것은 대화의 극히 일부분일 뿐이며, 진정한 방어적 사고방식을 갖추기 위한 실질적인 조언이 되지 못합니다. 개발자에게 "API 설정을 잘못하지 마라"고 말할 수는 있지만, 무엇이 올바르고 안전한 설정인지에 대한 이해가 없다면 오류가 발생할 여지는 여전히 많습니다.

개발자가 취약점의 작동 원리, 위험성, 취약점을 유발하는 패턴, 그리고 이를 해결하는 설계 및 코딩 패턴을 자신의 업무 맥락에서 근본적으로 이해하지 못한다면 취약점 감소에 긍정적인 영향을 줄 수 없습니다. 단계별 학습 접근 방식은 지식을 층층이 쌓아 올려 안전하게 코딩하고, 코드베이스를 방어하며, 보안 의식을 갖춘 개발자로 성장하는 데 필요한 전체적인 그림을 그려줍니다. 물론, 이러한 계층적 학습의 일부는 공격적인 측면과 공격자의 사고방식을 이해하는 데 할애되어야 합니다. 이는 위협 모델링과 방어 전략 수립에 필수적인 수평적 사고 능력을 연마하는 데 매우 중요합니다.

잘못된 코딩 패턴을 강화하는 것은 우리가 간과해서는 안 될 함정입니다.

일부 개발자 학습 방식의 안타까운 현실은, 교육이 공격 기법을 바탕으로 구조화되어 있더라도 '방어'라는 측면이 오히려 나쁜 습관을 강화할 수 있다는 점입니다. 기술적으로는 코드 보안을 검증하고 있을지라도 말이죠.

고품질 코드의 생산은 모든 소프트웨어 개발의 기본이 되어야 하지만, '품질'의 정의는 여전히 논쟁의 대상입니다. 현실은 안전하지 않은 코드는 기능적으로 완벽하고 아름다울지라도 고품질 코드로 볼 수 없다는 것입니다. 더 큰 문제는 안전한 코드라고 해서 반드시 고품질인 것은 아니라는 점입니다. 즉, 잘못된 코딩 패턴으로 보안 문제를 해결할 수는 있지만, 그 과정에서 또 다른 문제를 일으키거나 소프트웨어 전체를 망가뜨릴 수 있습니다.

인증 오류를 해결하는 과정에서 나타나는 저품질 코드의 예와 모범 사례를 따른 가장 안전한 버전을 살펴보겠습니다.

‍

using System;

using System.Collections.Generic;

using System.Linq;

using System.Threading.Tasks;

using Microsoft.AspNetCore.Authorization;

using Microsoft.AspNetCore.Http;

using Microsoft.AspNetCore.Mvc;

‍

namespace BadFixesAPI.Controllers

{

    [Route("api/[controller]")]

    [ApiController]

    public class AlertsController : ControllerBase

    {

        private DatabaseContext context = new DatabaseContext();

‍

        [HttpGet(Name = "GetAlerts")]

        // 사용자가 인증되었는지 확인하지 않음

        public IEnumerable<Alert> Get()

        {

            return context.GetAlerts();

        }

‍

        [HttpGet(Name = "GetAlerts")]

        // 사용자가 인증되었는지 확인하지만, 역할은 확인하지 않음

        [Authorize()]

        public IEnumerable<Alert> GetBadFix()

        {

            return context.GetAlerts();

        }

‍

        [HttpGet(Name = "GetAlerts")]

        // 사용자가 인증되었는지, 그리고 "Administrator" 역할을 가지고 있는지 확인합니다

        [Authorize(Roles = "Administrator")]

        public IEnumerable<Alert> GetGoodFix()

        {

            return context.GetAlerts();

        }

    }

}

‍

첫 번째 코드 조각에는 사용자 인증 확인 절차가 없어 매우 위험합니다. 두 번째는 인증 확인을 수행한다는 점에서는 낫지만, 할당된 역할이나 요청된 정보에 필요한 권한 수준을 검토하지 못합니다. 세 번째는 사용자 인증 및 "Administrator" 역할 할당 여부를 모두 확인합니다. 최소 권한 제어가 표준이 되어야 하는 오늘날, 정보가 필요한 사람에게만 공개되도록 역할을 설정하고 확인하는 것은 매우 중요합니다.

개발자에게 최우선 순위는 기능을 구현하는 것입니다. 보안을 의도적으로 뒷전으로 미루는 것은 아니지만, 보안 취약점으로 이어지는 잘못된 코딩 패턴을 피할 기술이 부족한 경우가 많으며, 훌륭한 엔지니어의 기준에 보안 코딩 능력이 포함되는 경우도 드뭅니다. 기능만 뛰어나다면 이러한 나쁜 습관을 간접적으로 장려하게 되는데, 바로 이런 사고방식을 바꿔야 합니다. 문제는 일부 학습 경로에서 권장하는 실습형 코드 수정 방식이 보안은 지키되 품질은 떨어지는 코드를 고착화할 수 있다는 점입니다. 버그를 해결하고 소프트웨어 무결성을 유지하는 최선의 방법인지 깊이 고민하기보다 "보안상 안전함/안전하지 않음"이라는 이분법적 평가를 적용하면, 세부적인 문제들을 놓치기 쉽습니다.

개발자에게 보안 코딩의 전체 과정을 보여주지 않는 접근 방식은 해결하려는 문제를 오히려 영속화합니다. 목적지에 도착하기만 하면 면허를 주는 상황을 상상해 보세요. 신호를 위반하고, 울타리를 들이받고, 횡단보도를 건너는 보행자를 아슬아슬하게 피해서 도착했더라도 합격점을 주는 것과 같습니다. 목표는 달성했지만, 그 과정이 무엇보다 중요합니다.

개발자가 보안 소프트웨어 제작에 더 관심을 가질 수 있도록 환경을 조성해야 합니다.

현대 개발자들은 수많은 업무를 동시에 처리해야 합니다. 보안 교육이 업무 흐름을 고려하지 않고 마감 기한과 우선순위를 방해한다면 지루하게 느껴지는 것은 당연합니다. 또한, 정기적이고 적절한 학습 기회나 보조 도구 없이 보안 코딩을 강조하며 KPI를 변경하는 것은 매우 불공평합니다. 하지만 보안 소프트웨어 개발의 중요성은 아무리 강조해도 지나치지 않으며, 개발자들의 공감을 이끌어내는 것이 무엇보다 중요합니다.

전직 개발자로서 말하자면, 우리는 대체로 훌륭한 성과를 내고 싶어 하며, 품질 면에서 남들보다 뛰어나다는 평가를 받는 것은 큰 동기부여가 됩니다. 개발자가 지속적으로 보안 역량을 쌓도록 장려하는 것은 당연한 일이며, 코드 수준의 보안 중요성을 인식하는 이들에게는 보상이 주어져야 합니다. 보안 챔피언 프로그램, 버그 바운티, 해커톤은 긍정적인 보안 문화를 구축할 좋은 기회이며, 적극적으로 참여하는 이들에게는 그에 걸맞은 보상이 따라야 합니다.