2018.01.11

데브섹옵스란 무엇인가, 더 안전한 애플리케이션 개발하기

Doug Drinkwater | CSO
데브섹옵스(DevSecOps)의 전제는 단순하다. 소프트웨어 개발 라이프사이클에 관여하는 모든 사람에게 보안에 대한 책임이 있으며, 본질적으로 운영과 개발을 보안 기능과 함께 하나로 합치는 것이다.

데브섹옵스의 목표는 개발 프로세스의 모든 부분에 보안을 내장하는 데 있다. 중요한 점은 끝에 덧붙이는 것이 아닌 데브옵스 워크플로우의 초반에 보안 제어와 프로세스를 내장함으로써 핵심 보안 작업을 자동화하는 것이다. 예를 들어 마이크로서비스 마이그레이션, 지속적 통합 및 지속적 딜리버리(CI/CD) 파이프라인 확장, 컴플라이언스 자동화 또는 단순한 클라우드 인프라 테스트 등이 여기에 해당된다.

데브섹옵스가 중요한 이유
IT 인프라는 최근 몇 년 사이 큰 변화를 거쳤다. 다이내믹 프로비저닝, 공유 리소스, 클라우드 컴퓨팅으로의 전환은 IT 속도와 민첩성, 비용 측면의 혜택을 이끌었으며 이러한 모든 장점이 애플리케이션 개발의 개선으로 이어졌다.

클라우드에서 애플리케이션을 배포하는 기능은 규모와 속도 두 가지를 모두 개선했다. 애자일(agile) 및 데브옵스(DevOps) 방법론으로의 전환과 이를 통한 지속적 딜리버리로 인해 "빅뱅" 방식의 애플리케이션 출시는 과거 속으로 사라졌다. 특히 데브옵스(개발과 IT 운영을 '하나의 자동화된 우산' 아래로 통합하는 방식)는 더 빈번한 기능 릴리스와 애플리케이션 안정성 향상에 이르기까지 모든 부분에 기여했다.

그러나 여전히 많은 보안 및 컴플라이언스 모니터링 툴이 이런 변화의 속도에 발을 맞추지 못하는 실정이다. 애초에 데브옵스에 필요한 속도로 코드를 테스트하도록 만들어지지 않았기 때문이다. 이로 인해 보안이 빠른 애플리케이션 개발, 더 일반적으로는 IT 혁신의 가장 큰 장벽이라는 시각이 더욱 굳어졌다.

라드웨어(Radware)의 보안 연구원 파스칼 지넨스는 "데브옵스는 민첩하고 실적이 우수한 기업의 제2의 천성이 되었으며, 온라인 비즈니스의 성공을 위한 기본"이라며, "IT와 소비자 요구의 지속적인 변화로 인해 페이지 업로드 시간부터 쇼핑과 검색 기능에 이르기까지 다양한 기능을 최신 상태, 최상의 실행 성능으로 유지하기 위한 지속적인 업데이트 주기가 발생한다"고 말했다.

지넨스는 "그러나 과거 애플리케이션 보안은 대부분 사후 대응이었고 때로는 경쟁에서 앞서 나가기 어렵게 하는 장애물로 인식되기도 했다"며, "운영을 유지하기 위한 애플리케이션의 의존성을 감안할 때 보안을 생략하는 것은 고위험 전략으로 간주돼야 한다. 분산 또는 지속 서비스 거부 공격에 손쉽게 당할 수 있기 때문이다. 에퀴팩스(Equifax)처럼 아파치 스트럿츠(Apache Struts) 프레임워크를 업데이트하지 않았을 때 어떤 일이 일어나는 지를 알아야 한다. 데브섹옵스 운동은 이 문제를 바꾸기 위한 것이다"고 말했다.

데브섹옵스의 장점
장점은 간단하다. 시작부터 더 많은 부분을 자동화하면 다운타임 또는 공격으로 곧잘 이어지는 잘못된 관리상의 잘못과 실수가 줄어든다는 것이다. 또한 이 자동화는 보안 설계자가 보안 콘솔을 수동으로 구성할 필요성도 줄여준다.

가트너에서 전한 바와 같이 이렇게 되면 IAM(Identity and Access Management), 방화벽, 취약점 스캔과 같은 보안 기능이 데브옵스 라이프사이클 전반에서 프로그램을 통해 활성화되고 보안 팀은 자유롭게 정책을 설정할 수 있게 된다. 가트너는 2021년이면 고속 개발 팀의 80%가 데브섹옵스를 채택할 것으로 예측했다(참고로 데브섹옵스는 섹데브옵스(SecDevOps)와는 약간 다르다).

샌탠더(Santander)의 사이버보안 연구 글로벌 책임자인 다니엘 쿠스버트는 "핵심은 보안을 라이프사이클로 다시 가져오는 것, 또는 흔히 말하듯이 '보안을 왼쪽, 즉 라이프사이클의 초반으로 옮기는 것'"이라며, "보안은 혁신을 가로막는 장벽으로 간주되고 부정적인 의미를 함축하는 경우가 많다. 보안을 왼쪽으로 옮긴다는 것은 혁신적이면서 안전한 제품을 만드는 데 도움이 됨을 의미한다. 제대로 하면 현재 우리가 직면한 보안에 대한 부정적인 이미지를 반전시킬 수 있다"고 말했다.

지넨스 역시 "데브섹옵스는 모두가 보안에 대해 책임을 진다는 것을 전제하는 건강한 모델이다. 한 팀이 애플리케이션을 만든 다음 보안을 담당하는 다른 팀에 넘기는 모습은 상상할 수 없다. 두 팀은 함께 결정하고 구현해야 한다. 이런 움직임이 데브옵스 체인의 여러 단계에서 보안을 강화하기 위한 툴과 기술의 개발로 이어졌다"고 말했다.

레드햇의 최고 보안 설계자인 마이크 버셀은 "두 팀의 구분이 없어져야 한다"고 주장하면서 "데브옵스를 제대로 한다면 보안을 포함해야 한다. 그 방식을 이해하는 것이 바로 데브섹옵스"라고 말했다.

데브옵스와 데브섹옵스, 통합이 중요하다
데브섹옵스를 위해 데브옵스에 보안을 통합하려면 새로운 시각과 프로세스, 툴이 필요하다. 보안과 위험 관리 책임자는 개발 프로세스의 원활한 진행과 투명성을 위해 데브옵스의 협업적이고 민첩한 특성에 따르고 보안을 최대한 조용히, 단절 없이 구현해야 한다. 그러나 두 가지 분야에서 이는 어려운 일이다.

쿠스버트는 "문제는 데브옵스의 핵심이 서비스, 민첩한 접근 방법과의 정렬에 있다는 점"이라며, "예를 들어 인프라를 코드로 취급하면서 보안 요소는 거의 논의되지 않는다. 지금은 여전히 데브옵스 프로세스에 따르는 쪽과 데브섹옵스를 선택한 쪽, 두 개의 진영으로 나뉘어 있다. 이 두 가지 캠프를 정렬해 보안이 프로세스의 모든 측면에서 라이프사이클과 의사 결정에 포함되도록 해야 한다"고 말했다.

쿠스버트는 이 정렬이 간단한 일은 아니라면서 "현재 프로세스와 라이프사이클을 완전히 이해해야 한다. 보안을 추가로 넣는 것과 관련된 단점은 무엇인가? 이 부분을 이해하는 대변자가 있는가? 이들에게 변화를 위해 행동할 권한이 있는가? 이런 기본적인 사항들을 파악하고 나면 이제 행동으로 옮길 차례다"고 말했다.

쿠스버트는 "이 협업을 올바르게 고려해야 한다"면서, "예를 들어 개발 부서에서 코드를 쓸 때 개발자에게 로컬 빌드 프로세스 가운데 취약점을 확인하기 위한 툴이 있는가, 또는 CI/CD 프로세스 내에서 젠킨스를 사용해서 하는가? 아니면 두 가지 모두 해서 각 빌드 프로세스에서 코드의 보안을 확인하는 보안 요소가 있는가?"라고 말했다.

레드햇의 버셀에게 더 큰 문제는 문화적으로 '왼쪽으로 이동'이 쉽지 않은 주제라는 점이다. 버셀은 "프로세스 초반으로 가져오는 것이 절대적으로 중요하고 이에 못지않게 중요한 것은 보안에 대해 이야기하는만큼 위험에 대해서도 이야기하는 것이다. 거버넌스의 핵심도 결국 여기에 있다. 사업부 측은 보안을 위한 보안에는 거의 관심이 없지만 위험 완화 수단으로서의 보안에는 관심을 둔다"고 말했다.

다만 버셀은 "보안이 '모든 사람의 책임'이라는 개념과 관련해 기업에서는 보안을 책임지는 역할을 결정해야 한다"고 경고하면서, "예를 들어 사용할 수 있는 컨테이너 이미지를 정의하는 역할이 있고, 블랙리스트든 화이트리스트든 허용되는 미들웨어 라이브러리를 선택하는 역할이 있다. 그러나 가장 필요한 요소는 이것을 보안 정책과 연결하는 것"이라고 말했다.

버셀은 "대부분의 조직은 위험에 대한 명확한 거버넌스가 있고 이를 바탕으로 보안 정책이 파생된다. 이것을 데브(섹)옵스에 연결하기 위한 단계는 이런 정책을 데브섹옵스 프로세스 내에 집어넣는 프로세스를 구현하는 것이다"고 설명했다.

데브섹옵스의 긍정적인 결과, 과제 선결 필요
일부 기업은 개발, 보안, 운영 팀을 결합해 책임 공유를 통해 피드백 루프를 단축하고 사고를 줄이고 보안을 개선하는 등 긍정적인 결과를 얻고 있다. 화이트 햇(White Hat)의 최고 보안 연구원 라이언 올리리는 "이것이 조직에서 코드를 더 신속하고 안전하게 릴리스하는 데 도움이 된다"면서, "애플리케이션 보안 프로그램이 효과적인지 여부를 판단하는 한 가지 중요한 척도는 취약점이 발견된 이후 이를 수정하는 데 소요되는 시간이다. 이 시간은 팀이 얼마나 민첩하게 문제의 경중을 판단해 대처하는 지를 보여준다"고 말했다.

올리리는 "화이트 햇의 평균적인 고객은 동적 분석(dynamic analysis)을 사용해 발견된 취약점을 수정하는 데 174일이 소요된다. 그러나 데브섹옵스를 구현한 고객은 92일만에 수정한다. 개발 중에 정적 분석(static analysis)을 사용해 발견된 취약점의 경우 평균적인 기업은 113일, 데브섹옵스 기업은 51일이 소요된다. 비약적인 개선이다. 또한 평균적인 고객이 10일 이내에 발견하고 수정한 취약점은 최종적으로 수정된 모든 취약점 가운데 15%에 불과하다. 데브섹옵스 기업의 경우 53%의 취약점을 10일 이내에 발견해 수정했다"고 말했다.

상황은 점차 좋아질 수 있다. 최근 디지서트(DigiCert) 보고서에 따르면, 설문 대상인 300개 미국 기업 가운데 98%는 데브옵스에 보안을 통합할 계획을 수립 중이거나 이미 통합했다고 응답했다(응답자의 1/3은 IT 또는 보안 부서 직원).

그러나 통합을 위해 넘어야 할 장애물이 있다. 쿠스버트가 말했듯이 데브옵스와 데브섹옵스는 운영 모델과 목표가 서로 다르고, 거버넌스 구조와 개발자 책임, 이른바 기술과 솔루션의 부족에 대한 우려도 있다.

퀄리스(Qualys)의 제품 관리 부사장인 크리스 칼슨은 "데브섹옵스에 대한 지식을 갖춘 보안 실무자의 수가 아직 적다"며, "업체들은 엔드포인트와 경계 보안에 주력하고 있으므로 데브섹옵스를 전파할 만한 유인 요소가 없다. 데브옵스 보안을 위한 제한된 툴셋만 제공하는 소규모 신생 업체들은 솔루션 범위도 넓지 않고 인지도도 부족해 힘을 얻기 어렵다"고 지적했다.

또한 버셀은 "실무자들 사이에서 '한번 하면 그것으로 끝'이라는 잘못된 인식이 있는 것 같다"면서, "데브옵스 프로세스와 사용 사례는 서로 다른 인프라와 정책 또는 비즈니스 요구 사항으로 인해 끊임없이 변화한다"고 강조했다.

쿠스버트는 "개발 스택과 프로세스의 폭이 넓기 때문에 모든 툴 또는 접근 방법에 맞는 한 가지 해결책은 없다. 하나의 제품을 연결한다고 해서 이 제품이 자동으로 작동해 보안 코드를 생산할 수는 없다"고 말했다.

그러나 전문가들은 이런 과제는 극복할 수 있으며 궁극적으로는 안전한 애플리케이션과 취약점 감소를 이끌 것임을 확신한다. 버셀은 "메시지가 일단 전달되면 대체로 잘 받아들여진다. 단순히 개발과 운영에 사후에 보안을 적용하려고 하는 것이 아니라 보안과 위험에 대한 비즈니스의 이해와 연결되기 때문이다"고 말했다. editor@itworld.co.kr  


2018.01.11

데브섹옵스란 무엇인가, 더 안전한 애플리케이션 개발하기

Doug Drinkwater | CSO
데브섹옵스(DevSecOps)의 전제는 단순하다. 소프트웨어 개발 라이프사이클에 관여하는 모든 사람에게 보안에 대한 책임이 있으며, 본질적으로 운영과 개발을 보안 기능과 함께 하나로 합치는 것이다.

데브섹옵스의 목표는 개발 프로세스의 모든 부분에 보안을 내장하는 데 있다. 중요한 점은 끝에 덧붙이는 것이 아닌 데브옵스 워크플로우의 초반에 보안 제어와 프로세스를 내장함으로써 핵심 보안 작업을 자동화하는 것이다. 예를 들어 마이크로서비스 마이그레이션, 지속적 통합 및 지속적 딜리버리(CI/CD) 파이프라인 확장, 컴플라이언스 자동화 또는 단순한 클라우드 인프라 테스트 등이 여기에 해당된다.

데브섹옵스가 중요한 이유
IT 인프라는 최근 몇 년 사이 큰 변화를 거쳤다. 다이내믹 프로비저닝, 공유 리소스, 클라우드 컴퓨팅으로의 전환은 IT 속도와 민첩성, 비용 측면의 혜택을 이끌었으며 이러한 모든 장점이 애플리케이션 개발의 개선으로 이어졌다.

클라우드에서 애플리케이션을 배포하는 기능은 규모와 속도 두 가지를 모두 개선했다. 애자일(agile) 및 데브옵스(DevOps) 방법론으로의 전환과 이를 통한 지속적 딜리버리로 인해 "빅뱅" 방식의 애플리케이션 출시는 과거 속으로 사라졌다. 특히 데브옵스(개발과 IT 운영을 '하나의 자동화된 우산' 아래로 통합하는 방식)는 더 빈번한 기능 릴리스와 애플리케이션 안정성 향상에 이르기까지 모든 부분에 기여했다.

그러나 여전히 많은 보안 및 컴플라이언스 모니터링 툴이 이런 변화의 속도에 발을 맞추지 못하는 실정이다. 애초에 데브옵스에 필요한 속도로 코드를 테스트하도록 만들어지지 않았기 때문이다. 이로 인해 보안이 빠른 애플리케이션 개발, 더 일반적으로는 IT 혁신의 가장 큰 장벽이라는 시각이 더욱 굳어졌다.

라드웨어(Radware)의 보안 연구원 파스칼 지넨스는 "데브옵스는 민첩하고 실적이 우수한 기업의 제2의 천성이 되었으며, 온라인 비즈니스의 성공을 위한 기본"이라며, "IT와 소비자 요구의 지속적인 변화로 인해 페이지 업로드 시간부터 쇼핑과 검색 기능에 이르기까지 다양한 기능을 최신 상태, 최상의 실행 성능으로 유지하기 위한 지속적인 업데이트 주기가 발생한다"고 말했다.

지넨스는 "그러나 과거 애플리케이션 보안은 대부분 사후 대응이었고 때로는 경쟁에서 앞서 나가기 어렵게 하는 장애물로 인식되기도 했다"며, "운영을 유지하기 위한 애플리케이션의 의존성을 감안할 때 보안을 생략하는 것은 고위험 전략으로 간주돼야 한다. 분산 또는 지속 서비스 거부 공격에 손쉽게 당할 수 있기 때문이다. 에퀴팩스(Equifax)처럼 아파치 스트럿츠(Apache Struts) 프레임워크를 업데이트하지 않았을 때 어떤 일이 일어나는 지를 알아야 한다. 데브섹옵스 운동은 이 문제를 바꾸기 위한 것이다"고 말했다.

데브섹옵스의 장점
장점은 간단하다. 시작부터 더 많은 부분을 자동화하면 다운타임 또는 공격으로 곧잘 이어지는 잘못된 관리상의 잘못과 실수가 줄어든다는 것이다. 또한 이 자동화는 보안 설계자가 보안 콘솔을 수동으로 구성할 필요성도 줄여준다.

가트너에서 전한 바와 같이 이렇게 되면 IAM(Identity and Access Management), 방화벽, 취약점 스캔과 같은 보안 기능이 데브옵스 라이프사이클 전반에서 프로그램을 통해 활성화되고 보안 팀은 자유롭게 정책을 설정할 수 있게 된다. 가트너는 2021년이면 고속 개발 팀의 80%가 데브섹옵스를 채택할 것으로 예측했다(참고로 데브섹옵스는 섹데브옵스(SecDevOps)와는 약간 다르다).

샌탠더(Santander)의 사이버보안 연구 글로벌 책임자인 다니엘 쿠스버트는 "핵심은 보안을 라이프사이클로 다시 가져오는 것, 또는 흔히 말하듯이 '보안을 왼쪽, 즉 라이프사이클의 초반으로 옮기는 것'"이라며, "보안은 혁신을 가로막는 장벽으로 간주되고 부정적인 의미를 함축하는 경우가 많다. 보안을 왼쪽으로 옮긴다는 것은 혁신적이면서 안전한 제품을 만드는 데 도움이 됨을 의미한다. 제대로 하면 현재 우리가 직면한 보안에 대한 부정적인 이미지를 반전시킬 수 있다"고 말했다.

지넨스 역시 "데브섹옵스는 모두가 보안에 대해 책임을 진다는 것을 전제하는 건강한 모델이다. 한 팀이 애플리케이션을 만든 다음 보안을 담당하는 다른 팀에 넘기는 모습은 상상할 수 없다. 두 팀은 함께 결정하고 구현해야 한다. 이런 움직임이 데브옵스 체인의 여러 단계에서 보안을 강화하기 위한 툴과 기술의 개발로 이어졌다"고 말했다.

레드햇의 최고 보안 설계자인 마이크 버셀은 "두 팀의 구분이 없어져야 한다"고 주장하면서 "데브옵스를 제대로 한다면 보안을 포함해야 한다. 그 방식을 이해하는 것이 바로 데브섹옵스"라고 말했다.

데브옵스와 데브섹옵스, 통합이 중요하다
데브섹옵스를 위해 데브옵스에 보안을 통합하려면 새로운 시각과 프로세스, 툴이 필요하다. 보안과 위험 관리 책임자는 개발 프로세스의 원활한 진행과 투명성을 위해 데브옵스의 협업적이고 민첩한 특성에 따르고 보안을 최대한 조용히, 단절 없이 구현해야 한다. 그러나 두 가지 분야에서 이는 어려운 일이다.

쿠스버트는 "문제는 데브옵스의 핵심이 서비스, 민첩한 접근 방법과의 정렬에 있다는 점"이라며, "예를 들어 인프라를 코드로 취급하면서 보안 요소는 거의 논의되지 않는다. 지금은 여전히 데브옵스 프로세스에 따르는 쪽과 데브섹옵스를 선택한 쪽, 두 개의 진영으로 나뉘어 있다. 이 두 가지 캠프를 정렬해 보안이 프로세스의 모든 측면에서 라이프사이클과 의사 결정에 포함되도록 해야 한다"고 말했다.

쿠스버트는 이 정렬이 간단한 일은 아니라면서 "현재 프로세스와 라이프사이클을 완전히 이해해야 한다. 보안을 추가로 넣는 것과 관련된 단점은 무엇인가? 이 부분을 이해하는 대변자가 있는가? 이들에게 변화를 위해 행동할 권한이 있는가? 이런 기본적인 사항들을 파악하고 나면 이제 행동으로 옮길 차례다"고 말했다.

쿠스버트는 "이 협업을 올바르게 고려해야 한다"면서, "예를 들어 개발 부서에서 코드를 쓸 때 개발자에게 로컬 빌드 프로세스 가운데 취약점을 확인하기 위한 툴이 있는가, 또는 CI/CD 프로세스 내에서 젠킨스를 사용해서 하는가? 아니면 두 가지 모두 해서 각 빌드 프로세스에서 코드의 보안을 확인하는 보안 요소가 있는가?"라고 말했다.

레드햇의 버셀에게 더 큰 문제는 문화적으로 '왼쪽으로 이동'이 쉽지 않은 주제라는 점이다. 버셀은 "프로세스 초반으로 가져오는 것이 절대적으로 중요하고 이에 못지않게 중요한 것은 보안에 대해 이야기하는만큼 위험에 대해서도 이야기하는 것이다. 거버넌스의 핵심도 결국 여기에 있다. 사업부 측은 보안을 위한 보안에는 거의 관심이 없지만 위험 완화 수단으로서의 보안에는 관심을 둔다"고 말했다.

다만 버셀은 "보안이 '모든 사람의 책임'이라는 개념과 관련해 기업에서는 보안을 책임지는 역할을 결정해야 한다"고 경고하면서, "예를 들어 사용할 수 있는 컨테이너 이미지를 정의하는 역할이 있고, 블랙리스트든 화이트리스트든 허용되는 미들웨어 라이브러리를 선택하는 역할이 있다. 그러나 가장 필요한 요소는 이것을 보안 정책과 연결하는 것"이라고 말했다.

버셀은 "대부분의 조직은 위험에 대한 명확한 거버넌스가 있고 이를 바탕으로 보안 정책이 파생된다. 이것을 데브(섹)옵스에 연결하기 위한 단계는 이런 정책을 데브섹옵스 프로세스 내에 집어넣는 프로세스를 구현하는 것이다"고 설명했다.

데브섹옵스의 긍정적인 결과, 과제 선결 필요
일부 기업은 개발, 보안, 운영 팀을 결합해 책임 공유를 통해 피드백 루프를 단축하고 사고를 줄이고 보안을 개선하는 등 긍정적인 결과를 얻고 있다. 화이트 햇(White Hat)의 최고 보안 연구원 라이언 올리리는 "이것이 조직에서 코드를 더 신속하고 안전하게 릴리스하는 데 도움이 된다"면서, "애플리케이션 보안 프로그램이 효과적인지 여부를 판단하는 한 가지 중요한 척도는 취약점이 발견된 이후 이를 수정하는 데 소요되는 시간이다. 이 시간은 팀이 얼마나 민첩하게 문제의 경중을 판단해 대처하는 지를 보여준다"고 말했다.

올리리는 "화이트 햇의 평균적인 고객은 동적 분석(dynamic analysis)을 사용해 발견된 취약점을 수정하는 데 174일이 소요된다. 그러나 데브섹옵스를 구현한 고객은 92일만에 수정한다. 개발 중에 정적 분석(static analysis)을 사용해 발견된 취약점의 경우 평균적인 기업은 113일, 데브섹옵스 기업은 51일이 소요된다. 비약적인 개선이다. 또한 평균적인 고객이 10일 이내에 발견하고 수정한 취약점은 최종적으로 수정된 모든 취약점 가운데 15%에 불과하다. 데브섹옵스 기업의 경우 53%의 취약점을 10일 이내에 발견해 수정했다"고 말했다.

상황은 점차 좋아질 수 있다. 최근 디지서트(DigiCert) 보고서에 따르면, 설문 대상인 300개 미국 기업 가운데 98%는 데브옵스에 보안을 통합할 계획을 수립 중이거나 이미 통합했다고 응답했다(응답자의 1/3은 IT 또는 보안 부서 직원).

그러나 통합을 위해 넘어야 할 장애물이 있다. 쿠스버트가 말했듯이 데브옵스와 데브섹옵스는 운영 모델과 목표가 서로 다르고, 거버넌스 구조와 개발자 책임, 이른바 기술과 솔루션의 부족에 대한 우려도 있다.

퀄리스(Qualys)의 제품 관리 부사장인 크리스 칼슨은 "데브섹옵스에 대한 지식을 갖춘 보안 실무자의 수가 아직 적다"며, "업체들은 엔드포인트와 경계 보안에 주력하고 있으므로 데브섹옵스를 전파할 만한 유인 요소가 없다. 데브옵스 보안을 위한 제한된 툴셋만 제공하는 소규모 신생 업체들은 솔루션 범위도 넓지 않고 인지도도 부족해 힘을 얻기 어렵다"고 지적했다.

또한 버셀은 "실무자들 사이에서 '한번 하면 그것으로 끝'이라는 잘못된 인식이 있는 것 같다"면서, "데브옵스 프로세스와 사용 사례는 서로 다른 인프라와 정책 또는 비즈니스 요구 사항으로 인해 끊임없이 변화한다"고 강조했다.

쿠스버트는 "개발 스택과 프로세스의 폭이 넓기 때문에 모든 툴 또는 접근 방법에 맞는 한 가지 해결책은 없다. 하나의 제품을 연결한다고 해서 이 제품이 자동으로 작동해 보안 코드를 생산할 수는 없다"고 말했다.

그러나 전문가들은 이런 과제는 극복할 수 있으며 궁극적으로는 안전한 애플리케이션과 취약점 감소를 이끌 것임을 확신한다. 버셀은 "메시지가 일단 전달되면 대체로 잘 받아들여진다. 단순히 개발과 운영에 사후에 보안을 적용하려고 하는 것이 아니라 보안과 위험에 대한 비즈니스의 이해와 연결되기 때문이다"고 말했다. editor@itworld.co.kr  


X