개발자들은 보안 테스트에 대한 책임이 증가하면서 보안 지침과 표준 코딩 사례 등에 대한 정보를 찾고 있다.
보안은 더 이상 보안팀 만의 책임이 아니다. 새로운 도구를 사용하면, 데브옵스(DevOps) 모델에 쉽게 테스트를 도입해 개발자가 앱이나 소프트웨어를 빌드할 때 코드를 검토하고 테스트할 수 있도록 할 수 있다. 그러나 개발자가 항상 보안 테스트 업무를 직접 수행할 수 있는 것은 아니다. 깃랩(GitLab)의 2020 글로벌 개발자 보고서(GitLab’s 2020 Global Developer Report)에 따르면, 설문조사에 참여한 보안 전문가의 거의 절반(49%)이 개발자가 최우선으로 취약성 문제를 해결하도록 하는데 어려움을 겪고 있다고 응답했다. 개발자 및 운영전문가와 마찬가지로 설문조사에 참여한 50%의 보안팀 또한 개발 속도를 가장 저하시키는 요인으로 테스트를 지적했다. 앱데브(AppDev) 리더는 개발자들이 아래 설명한 5가지 원칙을 쉽게 따를 수 있는 도구를 채택하고, 이를 팀이 수용할 수 있도록 함으로써 팀의 보안 실행방식을 개선할 수 있다.
보안은 모든 단계에서 고려되어야 한다
오늘날 보안은 더 이상 사후에 고려해야 할 작업이거나 접근이 어려운 영역이 아니다. 모든 사람들은 자신의 업무가 고객이나 기업을 위험에 빠뜨리지 않도록 책임을 가져야 한다. 보안은 단순한 확인 항목이 아니라 개발 및 배포, 업데이트 전 과정에 걸쳐 유지될 수 있도록 운영되어야 한다. 개발자는 다음 5가지 원칙에 따라 자체적으로 보안 업무를 수행할 수 있다:
1. 보안 책임을 확대한다
개발자들이 보안에 더 많은 책임을 가지고 있지만, 전반적인 책임 소유는 여전히 문제로 남아 있다. 모든 사람들이 보안에 책임을 가져야 하지만, ‘모든 사람’이라는 개념은 자칫 ‘아무도’ 책임지지 않는 상황을 초래할 수도 있다. 개발 팀 리더는 보안과 이러한 문제를 해결할 적절한 시점에 대해 분명한 기준을 세워야 한다. 적절하게 대응하지 못하면, 리소스 할당이 어려워지고, 보안은 위험부담이 큰 기술적 문제로 남게 된다. 소프트웨어 개발 과정에 시프트 레프트(Shift Left, 가능한 개발 초기부터 보안 관련 점검이나 테스트를 수행해서 비용이나 시간적인 노력을 최소화하자는 트렌드) 보안을 통합하게 되면, 개발자는 리소스가 풍부한 개발 초기에 리소스를 할당할 수 있다. 팀 전체의 지침을 만들고, 개발자들에게 모범 코딩 사례와 공통 과제를 교육하고, 팀 및 개인별 보안 메트릭스를 통해 기대치를 표준화해 개발자들이 강력한 보안 실행방식을 쉽게 채택할 수 있도록 해야 한다.
2. 테스트는 초기에, 자주 수행한다
데브섹옵스(DevSecOps)는 데브옵스 이니셔티브의 중요한 차기 단계이다. 보안팀은 코드를 병합하기 전에 버그를 발견할 가능성이 3배나 높기 때문에 코드를 작성할 때 테스트를 수행하고, 가능한 조기에 취약성을 수정할 수 있다. 또한 개발자는 종속성 스캐닝(Dependency Scanning), DAST(Dynamic Application Security Testing), SAST(Static Application Security Testing)를 지원하는 도구를 통합함으로써 코드를 작성하고, 커밋할 때 피드백을 받을 수 있다. 이러한 도구는 개발 프로세스 초기에 코드 보안에 대한 정보를 개발자에게 제공함으로써 나중에 수정하는 것보다 빠르고 경제적으로 문제를 해결할 수 있도록 해준다. 성숙한 데브옵스 모델을 사용하는 팀은 초기 단계의 데브옵스를 사용하는 기업들 보다 모든 코드의 91%~100%까지 테스트를 수행할 가능성이 90% 더 높다. 테스트는 개발자가 코드를 광범위한 코드베이스에 통합하기 전에 코드를 변경할 수 있도록 데브옵스 라이프사이클 전반에 걸쳐 지속되어야 한다. 테스트를 자주 수행함으로써 궁극적으로 시간소모를 줄이고, 리소스를 적게 사용할 수 있으며, 배포 시간을 단축하고, IT와 보안 간의 마찰을 줄일 수 있다.
3. 항상 제2의 눈으로 변경사항을 확인한다
코드 작성 및 업데이트는 항상 공동작업으로 진행되어야 한다. 제2의 눈은 작성자가 볼 수 없었던 잠재적인 문제를 발견하고, 취약성이 남아 있는 코드가 배포되는 위험을 줄여준다. 임의의 버디 시스템(Buddy System)은 매번 동일한 사람이 코드를 검토하지 않고, 다른 팀 구성원이 자신의 활동과 다른 작업을 검토하도록 하는데 유용하다. 코드를 검토하고, 승인을 처리하는데 도움이 되는 도구를 적극적으로 사용해야 한다. 코드 배포 작업 요청 프로세스 내에 승인자가 개입할 수 있도록 도구를 구성한다. 개발자들간에 코드를 서로 검토하는 문화는 중요한 요소이다. 개발 팀은 자체 코드 개발 속도나 품질뿐만 아니라 제품 또는 프로젝트 전반의 무결성에 대해서도 관심을 가져야 한다.
4. 모든 코드 배포 및 종속성, 업데이트에 대한 마스터 로그를 기록한다
개발 전반에 걸친 투명성은 코드의 품질을 보장하는 핵심이다. 코드에 대한 전체 기록을 작성하면, 검토 및 사고 대응에 도움이 되며, 보안 팀이나 개발자가 취약점이 발생한 시기와 지점을 정확히 식별할 수 있다. 또한 팀은 수동 빌드 또는 배포 프로세스를 최소화하여 애플리케이션에 대한 완벽한 이력추적과 로깅이 이뤄질 수 있도록 해야 한다. 대부분의 애플리케이션 코드는 오픈소스이기 때문에 종속성은 주요 공격 취약지점이 된다. 또한 오픈소스 코드의 버그는 일반적으로 감지하기 어렵고, 개발자가 알았을 때는 이미 늦은 경우가 많다. 워너크라이(WannaCry)와 같은 치명적인 공격이 누락된 업데이트나 패치로 인해 발생할 수 있기 때문에 종속성을 이해하고, 패치 및 업데이트하는 것이 중요하다. 업데이트된 취약성 데이터베이스를 이용하는 보안 스캔은 이전에 스캔한 코드라 하더라도 앱 보안을 유지하기 위해 정기적으로 실행되어야 한다.
5. 보안 포트폴리오를 다각화한다
문제에 대비하기 위해서는 다양한 유형의 테스트를 사용해야 한다. 정적분석(SAST), 동적분석(DAST), 시험판 스캐닝, 펜 테스트(Pen Testing) 또는 종속성 스캐닝과 같은 단일 유형의 테스트도 도움이 되지만, 애플리케이션 환경 전반에 대한 검토는 이뤄지지 않는다. 포레스터(Forrester)의 연간 애플리케이션 보안 보고서에 따르면, 보안팀은 개발자들이 개발 속도를 유지하면서도 취약성에 대응할 수 있도록 실행방식을 조정하고 있는 것으로 나타났다. 일부 팀들은 이제 프로덕션에 앞서 소프트웨어 구성 분석을 실시하고, 정적분석(SAST)을 초기 개발 단계로 전환(팀이 깃랩을 통해 달성할 수 있음)하고 있다. 한편 다른 팀들은 알려진 보안 결함 패턴에 속하지 않는 문제를 발견하는데 특히 유용한 버그 바운티(Bug Bounty) 프로그램을 사용하여 취약점을 크라우드 소싱하고 있다.
데브섹옵스 모델 구현 작업
개발자의 약 70%가 보안 코드를 작성하고 있는 것으로 예상되지만, 보안 실행방식에 대해서는 개발자의 25% 만이 ‘적절’하다고 판단하고 있다. 데브옵스는 이를 개선할 수 있는 탁월한 선택이다. 깃랩이 조사한 데이터에 따르면, 보다 성숙한 데브옵스 모델이 혁신과 협업을 촉진하고, 더 많은 코드를 더 빠르게 테스트할 수 있다는 것은 분명하다. 더 많은 팀들이 보안 실행방식을 시프트 레프트로 전환함에 따라 데브섹옵스는 개발자와 보안 전문가 모두에게 실질적인 혜택을 제공하게 될 것이다.
[글. 바네사 웨그너(Vanessa Wegner), 깃랩(GitLab) 보안 부문 컨텐츠 마케팅 매니저 /세스 버거(Seth Berger), 깃랩(GitLab) 보안 부문 백엔드 엔지니어링 매니저]
★정보보안 대표 미디어 데일리시큐!★
