CIO / 개발자 / 보안

데브섹옵스의 정의와 잘 하기가 어려운 이유

Lucian Constantin | CSO 2020.07.27
데브섹옵스(DevSecOps)는 보안을 현대 애플리케이션 개발 및 배포에 있어서 일반적인 RR(Rapid Release) 사이클에 통합하는 것이 목적인 소프트웨어 산업의 문화적 변화이며, 데브옵스(DevOps) 운동으로도 알려져 있다. 이 개념을 도입하기 위해서는 일반적으로 기업의 개발팀과 보안팀 사이에 존재하는 공백을 보안 프로세스의 많은 부분이 자동화하고 개발팀이 자체적으로 처리하는 수준까지 메워야 한다.




데브섹옵스는 기존의 소프트웨어 개발과 어떻게 다를까?

기존에는 주요 소프트웨어 개발업체가 수개월 또는 수년에 한 번씩 새로운 버전의 애플리케이션을 배포했다. 이를 통해 코드의 품질 확보 및 보안 테스트 등 내부 또는 외부 계약을 체결한 별도의 특수팀이 수행하는 프로세스를 거칠 충분한 시간을 확보했다.

하지만 지난 10년 동안 퍼블릭 클라우드, 컨테이너, 마이크로서비스(microservice) 모델이 등장하면서 하나의 애플리케이션이 독립적으로 실행되는 작은 부분으로 나뉘게 되었다. 이로 인해 소프트웨어가 개발되는 방식이 직접 영향을 받아 새로운 기능과 코드가 계속해서 빠른 속도로 생산에 투입되는 롤링 릴리즈(rolling releases) 및 애자일 개발(agile development) 활동으로 이어졌다. 이런 프로세스 가운데 다수가 새로운 기술과 도구를 활용해 자동화되면서 기업은 더 빠르게 혁신하고 경쟁에서 앞서게 되었다.

클라우드, 컨테이너, 마이크로서비스의 발전은 업계에서 이야기하는 데브옵스 문화의 등장으로 이어졌다. 데브옵스에서는 개발자가 별도의 인프라팀을 기다리지 않고 필요한 인프라를 제공받을 수 있다. 모든 주요 클라우드 제공업체가 현재 배포 템플릿을 사용해 인프라 구성을 코드로 처리할 수 있는 API와 구성 도구를 제공하고 있다.

데브옵스 문화는 소프트웨어 개발에 많은 혁신을 가져왔지만 보안은 코드가 생산되고 공개되는 새로운 속도를 따라잡을 수 없었다. 데브섹옵스는 이를 시정하고 보안 테스트를 CI(Continuous Integration)와 CD(Continuous Delivery) 파이프라인에 통합하면서 테스트 결과 및 해결을 내부적으로 수행할 수 있도록 개발팀에 필요한 지식과 기술을 쌓으려는 시도다. 

진정한 데브섹옵스 환경에는 다음과 같은 3가지가 필요하다.
 
  • 보안 테스트는 개발팀이 수행한다.
  • 테스트에서 발견된 문제는 개발팀이 관리한다.
  • 이런 문제를 개발팀이 내부적으로 해결한다.

애플리케이션 보안 테스트업체 베라코드(Veracode)의 공동 설립자 겸 CTO 크리스 와이소팔은 본지에 “마지막은 어느 정도 시간이 소요되지만, 여기에서 애플리케이션 보안이 진정한 데브섹옵스가 되며 별도의 팀이 필요없다”라고 말했다.


데브섹옵스, 진정한 보안/개발 통합 달성

와이소팔에 따르면, 마지막 단계를 달성하는 것이 어려운 이유가 개발자가 외부의 도움 없이 보안 관련 버그를 해결하기 위해 필요한 기술을 쌓아야 하며 여기에 시간이 소요되기 때문이다. 많은 팀이 개발팀 내에 소위 말하는 보안 전문가를 영입해 그렇게 하고 있다. 이 보안 전문가는 애플리케이션 보안에 대한 전문지식이 있으며 대부분의 팀원보다 이 분야에서 더 고급 교육을 받은 사람이다. 하지만 안전한 프로그래밍 활동에 대해 팀 전체를 교육하는 것도 이 과정에 포함되어야 한다. 또한 보안 픽스가 적절한지 검토할 수 있다.

보안 전문가가 고객에게 컨설팅 서비스를 제공할 수 있는 회사의 애플리케이션 보안 테스트 제공업체 등 외부 의견을 들을 수 없다는 의미는 아니다. 특별한 경우가 있을 수 있다. 개발팀과 보안팀을 분리하고 보안팀 구성원 가운데 1명 이상을 개발팀에 파견하는 것과는 다르다.

데브옵스 자동화 및 오픈소스 거버넌스 업체 소나타입(Sonatype) CTO 브라이언 폭스에 따르면, 개발과 보안 사이의 통합은 경영진 수준에서도 이뤄져야 한다. 폭스는 본지와의 인터뷰에서 “보안 미션이 개발에 완벽하게 통합되도록 하지 않으면 적절한 결과를 얻을 수 없을 것이다. 사람들이 같은 팀에서 일하더라도 목표가 다른 경영진 수준의 의견 충돌이 발생하게 된다. 아이들과 평행 놀이를 하는 것과 비슷하다. 2명의 걸음마를 배우는 아이들이 놀고 있는데 서로 싸우지 않는다고 해서 함께 노는 것은 아니다. 많은 조직에서 일어나는 일에 이 요소가 포함되어 있다고 생각한다”라고 밝혔다.

폭스는 이전에 QA에서 이런 일이 있었는데 QA 관리자와 엔지니어링 관리자가 협력하고 있었지만 항상 약간의 부서 중심주의가 있었다고 토로했다. 폭스는 "그것이 사라지자마자 QA는 개발팀 사람들이 하는 일에 참여했고 대립적인 정신이 사라졌다. 보안은 아직 그 정도 수준에 도달하지 못했다. 많은 기업들이 이 부분을 어려워하고 있다고 생각한다"라고 말했다.


데브섹옵스 테스트 및 도구 

실리콘 밸리 IT 업체들은 초기에 데브섹옵스 도입을 주도했지만 당시 제공되던 보안 테스트 도구가 개발자 친화적이지 않았다. 개발자들은 자동화할 수 있고 다양한 구성을 손쉽게 수정할 수 있으며 결과를 버그 추적 시스템으로 손쉽게 가져올 수 있는 명령 줄 도구를 원하지만 기존의 보안 검사들은 거버넌스, 보안 정책 준수, 위험 관리를 목표로 하는 보안팀과 CIO를 염두에 두고 고안됐다.

개발자들이 개발자를 위해 개발한 새로운 도구가 등장하기 시작했고 개발 환경과 CI/CD 워크플로우에 통합됐다. 일부는 오픈소스이며, 이를 기반으로 구축된 스타트업 비즈니스 모델도 있다. 이것이 개발자들의 니즈를 충족시키긴 했지만 CISO의 니즈는 더 이상 충족시키지 못했다.

많은 다양한 오픈소스 도구가 사용되고 있다면 개발팀은 해야 할 일을 하고 있다고 느낄 수도 있다. 와이소팔은 거버넌스 관점에서 보안팀이 이 모든 다양한 파편화된 도구를 회사의 정책에 맞추어 맵핑할 수 없다고 말했다.

지난 수년 동안 기존의 애플리케이션 보안 공급업체는 CISO가 필요로 하는 분석 및 보고서를 제공하고 개발자가 기대하는 유연성과 사용 편의성을 갖춘 두 사용례를 해결하기 위해 제품을 수정했다. 깃허브 같은 개발자를 대상으로 하는 클라우드 기반 서비스 제공업체 가운데 일부는 보안 테스트를 직접 자체 서비스에 추가하기 시작했다. 네이티브 기능으로 제공되지 않을 때는 일반적으로 해당 서비스의 마켓에서 서드파티 업체가 제공하는 통합 기능으로 제공된다.

폭스는 “나의 직업 생활 내내 반복되는 패턴을 목격했다. 하나의 공급업체와 만능 도구 스위트를 원하는 사람들과 동급 최고의 툴체인을 조합하는 사람들 사이에서 왔다갔다하는 것 같다. 지난 2년 동안 만능 스위트 쪽으로 꽤 치우치게 되었다”라고 말했다.

폭스는 차기 파괴적 기술이 등장하고 기업이 이에 대비해야 할 때가 되면 이런 통합이 역전될 수 있다고 경고했다. 스위트의 문제점은 조직이 필요로 하는 한 가지 이상의 작업에서 뛰어날 수 있지만 각각의 문제에 대한 최고의 솔루션이기 때문이 아니라 패키지에 무료로 제공되기 때문에 사용하는 다른 기능이 포함되어 있다는 점이다. 결국, 이로 인해 조직 내부에서 테스트를 시작하고 회사가 승인한 스위트보다 그들의 니즈를 잘 충족시키는 다른 도구를 사용하는 개발자 그룹이 생겨날 수 있다.

거버넌스 관점에서 팀이 관리되지 않으면 좋지 못하지만 기업들은 앞으로 1~2년 후에는 이런 일이 일어날 수밖에 없으며 도구 사용을 제한하기 위한 노력에도 불구하고 일부 개발자들은 항상 자신의 방식대로 할 것이라고 폭스가 말했다. “클라우드 얼리 어답터들은 훨씬 조직에 속하며 기기를 확보하는 데 소요되는 시간에 대해 저항하는 개별적인 팀인 경우가 있었다.”

폭스는 “이런 일이 발생하게 될 것임을 인정하고 생각해 보면 이 새로운 팀이 실제로 우리가 이 (스위트 기능을) 대체하고 싶어하는 것일 수도 있는 정말로 파괴적인 혁신의 가장자리에 서 있을 수도 있다는 사실을 더욱 유연하게 인정할 수 있다”라고 설명했다.


데브섹옵스 도입 현황과 어려운 점 

와이소팔에 따르면, 더 많은 기업이 CI/CD 파이프라인의 일환으로 자동화된 보안 스캔을 통합하고 있지만 개발자들이 해결하지 않기로 결정했기 때문에 생산에 투입되는 다수의 취약성을 의미하는 ‘보안 부채’로 인해 그 결과가 즉각적으로 드러나지 않을 수도 있다.

그 이유는 여러가지일 수 있으며, 즉시 해결할 능력이 없거나 다른 완화책이 마련되어 있어 해결할 계획을 세우지 않거나 심각도가 낮기 때문에 해결하지 않는 것 등이 포함된다. 1년 동안 8만 5,000개의 애플리케이션에 대해 수행한 스캔에서 수집한 데이터에 기초한 2019년 소프트웨어 보안 실태 보고서에서 베라코드는 애플리케이션에서 발견된 취약점의 평균 수정 시간이 해당 보고서가 처음으로 발표된 10년 전의 평균 59일과 비교해 더 긴 171일이라고 밝혔다. 하지만 축적된 보안 부채로 인해 왜곡된 부분이 있으며 중앙값 해결 시간은 실제로 거의 비슷했다.

특정 애플리케이션의 스캔 결과와 스캔 빈도를 연계시킬 때, 빈도가 증가한다는 것은 CI/CD 워크플로우의 자동화된 스캔 통합을 의미하며, 이 데이터는 매일 스캔한 애플리케이션의 중앙값 해결 시간이 19일임을 나타냈다. 매월 스캔한 애플리케이션은 68일이었다. 이를 통해 더 자주 스캔하면 취약점을 더 신속하게 패치할 가능성이 높다는 것을 알 수 있다.

이 보고서에서 “금융 부채와 마찬가지로 보안 부채에서 벗어나기 위해서는 잔액을 상환하는 습관을 바꾸어야 한다. 지난 수년 동안 소프트웨어 개발과 IT 운영이 통합(데브옵스)되고 보안이 이런 프로세스에 통합(데브섹옵스)되면서 분명 습관이 바뀌었다”라고 결론을 내렸다.

데브섹옵스를 향한 진정한 문화적 변화의 또 다른 이점은 코드에 존재하는 심각한 취약성의 수도 감소해야 한다는 점이다. 베라코드의 데이터에서 취약점이 없는 애플리케이션의 비율이 실제로 10년 전과 비교해 전체적으로 감소했으며, 이를 통해 상황이 악화되었다는 것을 알 수 있지만 심각도가 높은 결함이 없는 애플리케이션의 비율은 실제로 66%에서 80%로 증가했다.

폭스는 “너무 많은 조직이 이 모델로 고생하고 있다. 그들은 이 연속 개발 환경으로 이동하고 있으며 인프라와 CI가 있고 컨테이너를 사용하고 있다. 그리고 개발팀이 초기에 실수를 방지할 수 있는 도구를 활용하는 대신에 나중에 스캔하고 보고서(때로는 말 그대로 종이 인쇄 보고서)를 작성해 개발팀에 제공하는 애플리케이션 보안팀이 있다. 많은 조직이 여전히 '우리 대 그들', '개발 대 보안 정신'에 빠져 있다”라고 설명했다.

즉, 데브섹옵스라도 일부 작업은 여전히 보안 전문가가 수행해야 하며 테스트는 아직 해야 할 역할이 있다. 예를 들어, 완전히 자동화된 스캔으로 로직 결함이나 디자인 결함을 찾기가 어렵다.

와이소팔은 “수동 테스트를 더 이상 1년 또는 2년에 한 번씩 수행하지 않고 있다. 더욱 반복적이다. 특정 기능에 대해 이뤄지고 있는 수동 테스트의 작은 부분으로써 보안 영향을 미치는 새로운 기능을 수행하는 2주 스프린트가 있을 수 있는 데브옵스 과정의 일환으로써 수행되고 있다. 때로는 보안 전문가가 수행할 수 있으며, 수동 테스트에 관해 충분히 이해한다면 개발팀의 목표를 스스로 달성할 것이다”라고 말했다. editor@itworld.co.kr 

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.