귀사의 조직은 정말로 DevSec을 도입할 준비가 되었나요? 테스트를 통해 확인해보세요.

2020년이 절반도 지나지 않았지만, 이미 데이터 유출 사고는 기록적인 수준을 향해 가고 있습니다. 2019년 상반기와 비교해 도난당한 데이터가 273% 증가했습니다. 요즘은 데이터가 얼마나 유출되었는지보다 아직 유출되지 않은 데이터가 얼마나 남았는지 묻는 것이 더 정확할 정도입니다. 코로나19 팬데믹과 같은 세계적 사건들로 인해 공격의 빈도와 강도는 더욱 거세졌고, 공격 대상은 점점 더 취약해지고 있습니다.

우리 모두가 이미 알고 있듯이, 보안은 이제 선택이 아닌 필수이며 선제적인 대응에 집중해야 합니다. 이를 효과적으로 수행하려면 SDLC의 모든 구성원, 특히 개발자가 보안 의식을 갖춰야 합니다. 이것이 바로 DevSecOps의 'DevSec' 부분이며, 현 상황에 가장 이상적인 소프트웨어 개발 방법론이지만, 많은 조직이 이를 효과적으로 실행할 준비가 되어 있지 않습니다.

조직의 입장에서 본인의 역할을 고려하며 다음 질문들을 생각해보세요. 귀사의 조직은 DevSec 테스트를 통과할 수 있을까요?

DevSec 자가 진단: 귀사의 SDLC는 보안 의식을 갖춘 엔지니어를 길러낼 준비가 되었나요?

1. 내부 개발 프로세스에서 보안을 최우선으로 고려하고 있나요?
   수많은 사이버 보안 위험 요소들이 CISO들의 밤잠을 설치게 하지만, 우려스러운 현실은 많은 기업이 보안을 우선순위에 두고 있음에도 불구하고 내부적인 접근 방식이 잠재적인 재난(또는 최소한 AppSec 팀의 엄청난 골칫거리와 소프트웨어 출시 지연)을 막기에는 충분히 견고하지 않다는 점입니다.
   DevSecOps가 현재 보안의 이상향일지 모르지만, 이를 실천하는 기업은 드뭅니다. 여전히 애자일(Agile)이나 폭포수(Waterfall) 모델을 사용 중이라면, 보안은 프로세스와 동떨어진 전문가들의 영역으로 간주되어 SDLC 후반부에나 개입하게 되고, 결국 개발자의 코드에 핫픽스를 적용하며 업무를 방해하는 존재로 여겨지기 쉽습니다. 이런 환경에서는 DevSec 문화를 조성하기 어렵습니다. 개발자들은 기능 구현을 최우선으로 생각하며, 보안을 매력적인 역량 강화 경로로 인식할 만큼 충분한 실무 경험을 쌓지 못했을 가능성이 큽니다. 오히려 보안과의 접점이 부정적인 경험으로 남았을 수도 있습니다. 소프트웨어 개발 과정에 참여하는 모든 이가 보안을 최우선으로 생각하도록 빠르게 개선해야 합니다.
   ‍
2. 귀사의 조직은 위협 모델링 측면에서 여전히 뒤처져 있나요?
   중소기업의 60%가 성공적인 사이버 공격을 받은 후 6개월 이내에 폐업한다는 통계는 매우 충격적이며, 다른 재난과 마찬가지로 적절한 계획이 없으면 그 피해는 훨씬 더 큽니다.
   위협 모델링은 보안 모범 사례의 핵심 요소로, AppSec 전문가가 공격 표면의 전체 범위를 평가하고 적절한 방어, 대응책 및 계획을 수립할 수 있게 합니다. DevSecOps를 완전히 도입한 기업에서는 CI/CD 파이프라인 초기 단계부터 보안이 적용되어 과거처럼 생산 속도를 크게 늦추지 않습니다. 보안, 안전한 코딩, 지속적 배포가 프로세스의 일부가 되며, 개발 팀은 견고한 코드를 생산하는 핵심 엔진이 될 수 있도록 필요한 자원과 경험을 제공받습니다.
   ‍
3. 개발 관리자가 보안 모범 사례를 우선시하나요?
   원하든 원치 않든, 개발 관리자는 팀의 롤모델입니다. 이는 사무실에서 슬리퍼를 신거나 '상향 관리'를 하는 것과 같은 문화적인 측면뿐만이 아닙니다. 관리자의 업무 우선순위는 팀원들에게 자연스럽게 스며들기 때문에, 보안이 핵심 목표에 포함되지 않거나 교육 및 지원 계획이 없다면 엔지니어들은 뒤처지게 되고 비즈니스는 불필요한 위험에 노출됩니다.
   ‍
4. 개발자들에게 보안을 신경 써야 할 이유를 제공하고 있나요?
   경험상, 누군가에게 반감을 사는 가장 빠른 방법은 이유를 설명하지 않은 채 기존 방식과 다른 일을 강요하는 것입니다.
   
   '변화'하라는 말은 이전 방식이 틀렸다는 의미로 들릴 수 있지만, 많은 경우 이는 나중에 업무를 더 쉽고 효율적으로 만들기 위한 개선일 뿐입니다. DevSec 운동을 진정으로 받아들이려면 개발자들에게 보안을 신경 써야 할 이유를 먼저 제시해야 합니다. 결국 대부분의 조직에서 보안은 여전히 '다른 사람(멀리 떨어진 방에 갇힌 AppSec 마법사들)의 문제'로 치부되기 때문입니다.
   
   보안이 공동의 책임이 아니라면 DevSecOps는 작동하지 않습니다. 개발자들에게는 자신의 역할을 수행할 올바른 도구, 지원, 교육이 필요하며, 이는 전체 보안 프로그램의 일부로서 정착되고 완성되기까지 시간이 걸립니다. 가장 나쁜 접근 방식은 개발자들에게 너무 많은 우선순위를 강요하고 도움 없이 혼란에 빠뜨려 소외감을 느끼게 하는 것입니다. 이는 문화적 변화이며, 하루아침에 이루어지지 않습니다.
   ‍
5. 소수의 마법 같은 보안 유니콘에게 모든 업무를 의존하고 있나요?
   보안 전문가는 매우 부족한 실정이며, 현재보다 훨씬 더 많은 인력이 필요합니다. 이는 당연한 사실이지만, 보안 중심의 역할로 전환하는 개발자가 늘고 있습니다. 보통 '보안 엔지니어'나 'DevOps 엔지니어'라는 직함으로 불리며(운이 좋다면 점차 DevSecOps 엔지니어로 직함이 바뀔 것입니다!). 뛰어난 DevOps 엔지니어는 진정한 CI/CD 파이프라인을 사용하여 배포하면서 거의 모든 애플리케이션의 기능을 개발할 수 있습니다. 이들은 엔드투엔드로 모든 작업을 수행하며, 보통 상당한 수준의 보안 의식을 갖추고 있습니다. 그런 의미에서 이들은 마법 같은 존재이며, 그만큼 희귀합니다.
   
   하지만 일부 기업은 이러한 전문 엔지니어를 채용해 팀에 배치하기만 하면 개발 과정의 모든 단계에서 보안 문제를 해결해 줄 것이라고 착각하는 실수를 범합니다. DevSecOps 마법사들에게 과도한 업무를 지우면 결국 처음으로 돌아가게 됩니다. 즉, 그들이 수행해야 할 검사, 균형, 보안 정밀함 없이 보안이 취약한 코드를 배포하게 되는 것입니다. 개발 팀 전체의 역량을 강화하고 긍정적인 보안 환경에서 육성하여, 그들이 의미 있는 방식으로 업무를 분담할 수 있도록 준비시키는 것이 무엇보다 중요합니다.

조직에서 보고 싶은 변화를 찾아보세요.

보안 프로그램의 일환으로 탄탄한 교육을 시행하면 개발자 그룹 내에서 숨은 보석을 발견하게 될 것입니다. 이들은 일상 업무에서 겪은 부정적인 경험에도 불구하고 안전한 코딩과 보안 모범 사례에 열정을 가진 사람들입니다. 이들은 팀 내 보안 챔피언이 될 최적의 후보입니다. 보안과 엔지니어링 사이의 연락책으로서 다른 이들에게 훌륭한 본보기가 되고, 보안 의식을 높이며, 참여 이니셔티브를 돕는 역할을 합니다. 이들의 대인 관계 능력은 보안의 즐거움을 널리 퍼뜨리고, 개발자의 요구 사항을 경영진과 보안 팀에 대변하는 데 매우 중요합니다.

"나에게 어떤 이득이 있는가?"라는 질문은 긍정적인 첫걸음입니다.

가장 고결한 사람이라도 낯선 영역에 발을 들이거나 학습 곡선이 가파른 활동을 할 때는 일종의 '당근'이 필요합니다.
"Dev"에서 "DevSec"으로 도약하는 것은 개발자의 커리어에 엄청난 힘이 됩니다. 보안 의식을 갖춘 개발자는 보안을 이해하고 자신이 통제할 수 있는 영역에서 책임을 지며, 오직 안전한 코드만이 품질 좋은 코드라는 이해를 바탕으로 업무를 수행합니다. 일반적으로 개발자들은 성장하고, 새로운 문제를 해결하며, 동료들 사이에서 돋보일 수 있는 뛰어난 기능을 만들고 싶어 합니다. 그들에게 더 높은 수준의 소프트웨어 개발로 나아갈 경로를 제시한다면, 모두에게 윈윈(win-win)이 될 것입니다.

DevSec 드림팀을 구성하기에 너무 늦은 때란 없습니다.

개발자를 관리하거나, AppSec 인식 팀을 이끌거나, 보안 프로그램 전략을 수립하는 많은 분들께 지금은 '시프트 레프트(Shift Left)' 그 이상을 실천해야 할 때입니다. 올바른 교육, 도구, 환경을 갖추면 모든 이해관계자에게 큰 이익을 가져다줄 개발자 보안 인큐베이터를 만들 수 있습니다. 이 체크리스트를 통해 개선할 점을 확인했다면, SDLC 초기부터 위험을 줄일 수 있는 DevSec 중심의 엔지니어링 부서로 조직을 탈바꿈할 좋은 기회입니다.