2018.07.19

데브섹옵스를 시작하는 5가지 방법

Scot Finnie | CSO
소프트웨어 개발 방식을 계속 변화시키는 기업과 기관의 수가 증가하고 있다. 처음에는 애자일(agile), 다음은 데브옵스(DevOps), 지금은 시큐어 데브옵스(Secure DevOps), 일명 '데브섹옵스(DevSecOps)'다.

이는 더 나은 품질의 애플리케이션 구현에 목적이 있다. 그러나 처음부터 '문샷(moonshots, 혁명적인 도전)'을 시도하지 않는다. 더 빠르게 시작해 '위대한 것(greatness)'으로 발전시켜 나가는 방식이다.

그러나 항상 데브옵스 기법의 이점과 혜택을 완전히 실현시키는 것은 아니다. 중요한 한 가지가 미흡한 경우가 많기 때문이다. 다름 아닌 '보안'이다.

지난 수년 간 보안에 대한 우선 순위를 높인 기업들이 아주 많다. 그러면서 데브섹옵스 시대가 도래했다. 지난 해 디지서트(DigiCert)의 '애자일 보안 구현(Making Security Agile)' 설문조사에 따르면, 데브옵스에 보안을 통합하는 것이 중요하다고 대답한 비율이 88%에 달했다. 데브옵스에 보안을 통합하지 않았을 때 초래될 수 있는 3가지 위험으로는 '추가적인 보안 위험', '비용 증가', '딜리버리(delivery) 주기 증가'가 꼽혔다.

데브옵스를 성공적으로 도입해 성공시킨 기업들이 많지만, 최초 프로세스에 보안 팀이 참여하는 것이 강조되지 않는다. 문화적으로도 조직적으로도 보안과 개발이 깊이 분리된 기업이 많다.
이에 소속 조직에서 데브섹옵스를 전파하는 방법을 터득하고 싶은 보안 분야 종사자와 CISO들에게 값진 정보가 될 팁과 방법들을 소개한다. 우선 먼저 현실을 직시하자. 데브옵스 프로세스에 보안 팀을 통합시키는 것은 불가피한 요구 사항이다.

데브섹옵스, 진화의 일부
데브섹옵스 이전에 데브옵스가 존재했다. 당연한 이야기로 치부하는 사람이 있겠지만 현재 데브섹옵스에 쏠린 관심과 이와 관련해 발생한 거품을 감안했을 때, 먼저 데브옵스를 강조할 필요가 있다. 시큐어 데브옵스는 데브옵스가 발전해 구현된 변종이다. 사실 시작부터 포함됐어야 했다.

데브옵스는 기본적으로 통합과 테스트, 딜리버리 프로세스를 자동화, 소프트웨어 개발 프로세스를 지속적으로 반복하는 프로세스로 전환하는 기법이다. 이를 위해서는 기업의 문화와 소프트웨어 개발 팀의 기대 사항을 바꿔야 한다.

단 한 번에 완벽을 기하려 시도할 경우 너무 많은 시간을 소비하게 되고, 성공하는 경우도 드물다. 이런 이유로 데브옵스의 핵심 원칙 가운데 하나는 코드의 CI/CD(Continuours Integration/Continuous Delivery)이다. 많은 기업과 기관에서 자동화된 테스트와 피드백에 바탕을 둔 지속적인 개발 프로세스가 훨씬 효율적이라는 점이 입증되고 있다. 그러나 시작할 때부터 보안을 통합시키면 더 효율적이 될 것이다. 따라서 처음부터 시작하는 경우, 가능하다면 데브옵스와 데브섹옵스를 동시에 도입하는 것이 좋다.

일부 데브옵스 전문가들은 데브섹옵스라는 용어를 불편하게 받아들였다. 전혀 다른 새로운 개념으로 인식될까 우려했기 때문이다. 데브옵스 2.0이 더 적절한 표현이라고 말했다. 이를 무엇이라 부르든 데브옵스 없이 데브섹옵스를 도입할 수 없다. 그리고 데브옵스는 애자일이 자연스럽게 성장한 개념이다.

1. 문화적 변화에 대한 계획 수립
페니 매(Fannie Mae)에서 데브섹옵스 도입과 이행을 성공적으로 이끈 크리스 포터 부사장이자 CISO는 데브섹옵스 구현의 '열쇠'는 문화적 변화와 조직적 변화라고 강조했다 페니 매는 데브섹옵스 도입으로 CSO50 상을 수상한 바 있다. 전문가 대부분은 이 문제에 있어 포터의 의견에 전적으로 동의했다.

주된 목표는 개발과 보안, 운영 부서가 보안을 공동 책임지는 문화를 조성하는 것이다. 이를 위해서는 세개 부서의 사고 방식이 일정 수준 바뀌어야 한다. 이런 문화적인 변화 자체를 위한 계획을 수립해야 한다. 이런 프로세스를 견인하는 CSO와 CISO에 도움이 될 수 있는 단계별 방법 가운데 일부는 다음과 같다.

- 데브옵스와 데브섹옵스를 철저히 학습하고, 자신의 의견과 주장을 준비한다.
- 제품 담당 부사장, 엔지니어링 담당 부사장과 협력한다.
- 개발과 운영 프로세스의 프레임워크와 관련된 보안 도전과제를 검토, 평가하는 부서 간 회의를 개최한다.
- 보안팀을 조기에 참여시켜야 한다. 데브섹옵스 이전 과정에서 가장 큰 도전 과제에 직면할 수도 있기 때문이다. 페니 매가 터득한 교훈에 따르면, 정보보안 팀은 자문이나 컨설팅에 중심을 두고, 코드 보안은 소프트웨어 엔지니어가 책임지는 것이 좋다. 이것이 좋은 방법이다. 그러나 일부 보안 담당 직원들 가운데에는 이런 문화적 변화에 어려움을 겪는 직원이 있을 수 있다.
- 데브섹옵스는 전적으로 협력(collaboration)을 기반으로 한다. 따라서 협력 촉진을 가장 중요하게 생각해야 한다. 이것이 처음에 직면하는 가장 큰 도전과제가 될 수 있다.
- 데브섹옵스에 있어 가장 큰 문화적 도전과제는 'No'라고 말하는 문화를 없애는 것이다. 전통적으로 보안은 단호히 'No'라고 말하는 문화를 갖고 있다. 여기에는 이유가 있다. 프로세스 후기에 보안 검토를 하는 경우가 많기 때문이다. 대신 서로 협력해 문제를 해결해고, 팀에 힘을 실어줘서 빨리 실패하고 지속적으로 개선을 하는 문화를 조성하는 것이다. 이런 변화를 주도하게 되는 사람은 통상 CSO와 CISO이다. 보안 팀은 '적색 깃발'을 들 때 대안을 제시하려 노력해야 하며, 해결책의 일부가 되어야 한다.
- 데브섹옵스로의 변화 과정 동안 변화 관리 기법으로 직원들을 지원해야 한다.
- 조직 재편이 필요할 수도 있다. 또는 데브옵스에 경험이 있는 새로운 직원을 채용해야 할 수도 있다.

2. 프로세스 재배치
SANS 인스티튜트 애플리케이션 및 보안 커리큘럼 관리자 에릭 존슨은 "조직 구조 측면에서 보면, 데브섹옵스를 구현하기 위해서는 보안과 컴플라이언스 팀이 각자의 프로세스, 정책, 요구 사항을 개발 및 운영 부문이 활용하는 동일한 데브옵스 워크플로우로 통합시켜야 한다"고 말했다. 보안 팀이 개발과 운영 엔지니어링 프로세스, 기술, 도구를 제대로 이해하지 못할 경우 데브섹옵스를 성공적으로 도입해 실천할 수 없다.

데브섹옵스의 가장 중요한 원칙이자 아주 중요한 프로세스 변화 가운데 하나는 '보안을 왼쪽으로 이동시키는 것'이다. 프로세스의 초기에 보안을 분석하고 테스트해야 한다는 의미다. 모든 프로젝트에서 보안 팀원들이 첫날부터 참여해 프로젝트를 책임지고, 프로젝트의 성공에 기여해야 한다. 개발자는 보안이 중시된 코딩에 대해 학습해야 한다. 보안 팀이 여기에 도움을 줄 수도 있다. 그러나 소프트웨어 엔지니어에게 이에 대한 교육을 해야 한다.

회사마다 적합한 프로세스가 다르다. 부즈 알렌 해밀턴(Booz Allen Hamilton)은 '여정에 대한 로드맵' 수립을 권장한다. 특정 기능(직능)에 있어 사용자가 통과하게 될 모든 것을 시뮬레이션 해야한다는 의미다. 이는 최종 프로세스가 처리하고 달성해야 하는 결과물을 확립하는 한 가지 방법이다.

3. 효율성과 정확성을 위한 자동화
데브옵스의 '핵심' 주제 가운데 하나는 자동화(Automation)이다. 데브섹옵스 또한 다르지 않다. 이는 데브섹옵스의 또 다른 주요 영역에서 아주 중요한 역할을 한다. 다름 아닌 '코드로 보안관리(Security as code)'라는 원칙이다.

보안 테스트, 가능한 많은 다른 접점들을 자동화하고, 소프트웨어 엔지니어들이 활용할 수 있는 보안 공유 코드 레포지토리(저장소)를 만들고, 데브옵스 CI/CD 파이프라인의 속도에 맞게 보안 프로세스를 단순화시켜야 한다. 이를 위해서는 보안, 엔지니어링, 운영 부서가 서로 협력해야 한다. 데브섹옵스라는 변화의 핵심 구성 요소다. 따라서 인재들을 배치해 추진해야 한다.

4. 현명하게 소프트웨어 도구를 선택
데브옵스 CI/CD 파이프라인과 기존 도구들에 쉽게, 그리고 효과적으로 연결할 수 있는 도구들을 선택해야 한다. 각 도구가 전달하는 기능, 자동화를 구현할 수 있는 수준 또한 고려하는 것이 좋다.

SANS 인스티튜트는 시큐어 데브옵스 툴체인(Secure DevOps Toolchain)과 SWAT 체크리스트라는 이름으로 다양한 데브옵스와 데브섹옵스 도구들을 분류, 정리했다.

SANS 인스티튜트의 에릭 존슨은 체크리스트의 데이터에서 대부분의 조직이 데브옵스 프로세스의 일부로 도입해야 하는 보안 점검과 이를 위해 고려해야 할 도구들 가운데 일부를 선정해 소개했다.
- 커밋 전 보안 파악(Pre-Commit Security Hooks) : 코드를 버전 제어로 커밋하기 전에 비밀(프라이빗 키, 시스템 비밀번호, 클라우드 액세스 키 등)을 스캔하는 코드 검사기
- 커밋 전 코드 검사(Pre-Commit Code Scanning) : 엔지니어가 쓴 코드를 실행해 간단히 보안을 검사할 수 있는 보안 플러그인이 포함되어 있는 아톰(Atom), 코드(Code), 인텔리제이(IntelliJ), 비주얼 스튜디오(Visual Studio)와 같은 코드 편집기
- 수동 보안 피어 평가(Manual Security Peer Review) : 깃허브(GitHub), 깃랩(GitLab), 비트버킷(Bitbucket)과 같은 곳에서는 기본 기능으로 탑재되어 있는, 고위험 코드 변경에 대해 보안 검사를 실시하기 위한 코드 검사 도구
- 정적 소스코드 스캐닝(Static Source Code Scanning) : 빌드 파이프라인의 보안 취약점을 찾기 위해 소스코드 파일(인프라 템플릿, 애플리케이션 소스코드 등)을 스캐닝
- 보안 유닛 테스트(Security Unit Tests) : 보안 및 엔지니어링 팀이 악의적 사용자에 대한 사례와 부정적인 테스트 사례를 다루기 위해 구현한 보안 유닛 테스트
- 종속성 관리 스캔(Dependency Management Scans) : 알려진 취약점을 찾기 위해 오픈소스 인프라 템플릿와 애플리케이션 구성 요소를 스캐닝
- 컨테이너 보안 스캐닝(Container Security Scanning) : 데브옵스에서 사용이 증가하고 있는 도커(Docker) 같은 컨테이너의 경우, 보안 팀은 컨테이너 이미지를 분석해 취약점과 노출된 비밀, 안전하지 않은 구성, 정책 컴플라이언스 등을 확인해야 함
- 동적 애플리케이션 보안 테스트(Dynamic Application Security Testing) : 실행 애플리케이션을 대상으로 공통된 보안 취약점(OWASP Top 10)을 스캔하고, Ganutlt/BDD 시큐리티 같은 도구를 사용해 승인 기준을 적용
- 인프라 승인 테스트(Infrastructure Acceptance Tests) : ISpec과 OpenSCAP 같은 도구를 사용, 인프라 승인 테스트로 강화된 기준(CIS 등)을 토대로 '금색' 이미지를 식별할 수 있음
- 비밀 관리(Secrets Management) : 볼트(Vault), 컨저(Conjure), AWS KMS, 애저 키 볼트(Azure Key Vault) 같은 도구를 사용해 비밀에 대한 프로비저닝 및 스토리지를 자동화.
- 지속적인 모니터링(Continuous Monitoring) : 프로덕션 환경을 모니터링해 취약점(vulnerabilities), 변칙(anomalies), 진행 중인 공격을 탐지(스태스디(StatsD), 그래파이트(Graphite), 그래판타(Graphanta) 등의 도구 사용)

5. 성과 측정
이런 주요 프로젝트에 앞서 매트릭스를 준비하는 것이 아주 중요하다. 투자 가치가 있는 성과를 일궈낼 수 있는지 여부를 판단할 수 있는 유일한 방법이기 때문이다. 놀랍게도 현재 이런 종류의 측정 및 평가에 사용할 수 있는 도구나 매트릭스는 존재하지 않는다. 부즈 알렌과 여러 전문가에 따르면, 도입하는 매트릭스가 무엇이든 '전달 리드 타임(lead time to deliver)', '배포 빈도 및 주기(the number and frequency of deployments)', '장애 복구 시간(mean time to recover, MTTR )', '비율로 표현된 결함 수의 변화'와 같은 데이터 포인트를 토대로 활용해야 한다. 일부 자동화된 코드 품질 스캐닝 솔루션은 지표로 사용할 수 있는 보안 코드 품질 점수를 제공한다. 이런 데이터 포인트를 결합해 사용하는 것이 가장 좋은 방법이 될 것이다. editor@itworld.co.kr  


2018.07.19

데브섹옵스를 시작하는 5가지 방법

Scot Finnie | CSO
소프트웨어 개발 방식을 계속 변화시키는 기업과 기관의 수가 증가하고 있다. 처음에는 애자일(agile), 다음은 데브옵스(DevOps), 지금은 시큐어 데브옵스(Secure DevOps), 일명 '데브섹옵스(DevSecOps)'다.

이는 더 나은 품질의 애플리케이션 구현에 목적이 있다. 그러나 처음부터 '문샷(moonshots, 혁명적인 도전)'을 시도하지 않는다. 더 빠르게 시작해 '위대한 것(greatness)'으로 발전시켜 나가는 방식이다.

그러나 항상 데브옵스 기법의 이점과 혜택을 완전히 실현시키는 것은 아니다. 중요한 한 가지가 미흡한 경우가 많기 때문이다. 다름 아닌 '보안'이다.

지난 수년 간 보안에 대한 우선 순위를 높인 기업들이 아주 많다. 그러면서 데브섹옵스 시대가 도래했다. 지난 해 디지서트(DigiCert)의 '애자일 보안 구현(Making Security Agile)' 설문조사에 따르면, 데브옵스에 보안을 통합하는 것이 중요하다고 대답한 비율이 88%에 달했다. 데브옵스에 보안을 통합하지 않았을 때 초래될 수 있는 3가지 위험으로는 '추가적인 보안 위험', '비용 증가', '딜리버리(delivery) 주기 증가'가 꼽혔다.

데브옵스를 성공적으로 도입해 성공시킨 기업들이 많지만, 최초 프로세스에 보안 팀이 참여하는 것이 강조되지 않는다. 문화적으로도 조직적으로도 보안과 개발이 깊이 분리된 기업이 많다.
이에 소속 조직에서 데브섹옵스를 전파하는 방법을 터득하고 싶은 보안 분야 종사자와 CISO들에게 값진 정보가 될 팁과 방법들을 소개한다. 우선 먼저 현실을 직시하자. 데브옵스 프로세스에 보안 팀을 통합시키는 것은 불가피한 요구 사항이다.

데브섹옵스, 진화의 일부
데브섹옵스 이전에 데브옵스가 존재했다. 당연한 이야기로 치부하는 사람이 있겠지만 현재 데브섹옵스에 쏠린 관심과 이와 관련해 발생한 거품을 감안했을 때, 먼저 데브옵스를 강조할 필요가 있다. 시큐어 데브옵스는 데브옵스가 발전해 구현된 변종이다. 사실 시작부터 포함됐어야 했다.

데브옵스는 기본적으로 통합과 테스트, 딜리버리 프로세스를 자동화, 소프트웨어 개발 프로세스를 지속적으로 반복하는 프로세스로 전환하는 기법이다. 이를 위해서는 기업의 문화와 소프트웨어 개발 팀의 기대 사항을 바꿔야 한다.

단 한 번에 완벽을 기하려 시도할 경우 너무 많은 시간을 소비하게 되고, 성공하는 경우도 드물다. 이런 이유로 데브옵스의 핵심 원칙 가운데 하나는 코드의 CI/CD(Continuours Integration/Continuous Delivery)이다. 많은 기업과 기관에서 자동화된 테스트와 피드백에 바탕을 둔 지속적인 개발 프로세스가 훨씬 효율적이라는 점이 입증되고 있다. 그러나 시작할 때부터 보안을 통합시키면 더 효율적이 될 것이다. 따라서 처음부터 시작하는 경우, 가능하다면 데브옵스와 데브섹옵스를 동시에 도입하는 것이 좋다.

일부 데브옵스 전문가들은 데브섹옵스라는 용어를 불편하게 받아들였다. 전혀 다른 새로운 개념으로 인식될까 우려했기 때문이다. 데브옵스 2.0이 더 적절한 표현이라고 말했다. 이를 무엇이라 부르든 데브옵스 없이 데브섹옵스를 도입할 수 없다. 그리고 데브옵스는 애자일이 자연스럽게 성장한 개념이다.

1. 문화적 변화에 대한 계획 수립
페니 매(Fannie Mae)에서 데브섹옵스 도입과 이행을 성공적으로 이끈 크리스 포터 부사장이자 CISO는 데브섹옵스 구현의 '열쇠'는 문화적 변화와 조직적 변화라고 강조했다 페니 매는 데브섹옵스 도입으로 CSO50 상을 수상한 바 있다. 전문가 대부분은 이 문제에 있어 포터의 의견에 전적으로 동의했다.

주된 목표는 개발과 보안, 운영 부서가 보안을 공동 책임지는 문화를 조성하는 것이다. 이를 위해서는 세개 부서의 사고 방식이 일정 수준 바뀌어야 한다. 이런 문화적인 변화 자체를 위한 계획을 수립해야 한다. 이런 프로세스를 견인하는 CSO와 CISO에 도움이 될 수 있는 단계별 방법 가운데 일부는 다음과 같다.

- 데브옵스와 데브섹옵스를 철저히 학습하고, 자신의 의견과 주장을 준비한다.
- 제품 담당 부사장, 엔지니어링 담당 부사장과 협력한다.
- 개발과 운영 프로세스의 프레임워크와 관련된 보안 도전과제를 검토, 평가하는 부서 간 회의를 개최한다.
- 보안팀을 조기에 참여시켜야 한다. 데브섹옵스 이전 과정에서 가장 큰 도전 과제에 직면할 수도 있기 때문이다. 페니 매가 터득한 교훈에 따르면, 정보보안 팀은 자문이나 컨설팅에 중심을 두고, 코드 보안은 소프트웨어 엔지니어가 책임지는 것이 좋다. 이것이 좋은 방법이다. 그러나 일부 보안 담당 직원들 가운데에는 이런 문화적 변화에 어려움을 겪는 직원이 있을 수 있다.
- 데브섹옵스는 전적으로 협력(collaboration)을 기반으로 한다. 따라서 협력 촉진을 가장 중요하게 생각해야 한다. 이것이 처음에 직면하는 가장 큰 도전과제가 될 수 있다.
- 데브섹옵스에 있어 가장 큰 문화적 도전과제는 'No'라고 말하는 문화를 없애는 것이다. 전통적으로 보안은 단호히 'No'라고 말하는 문화를 갖고 있다. 여기에는 이유가 있다. 프로세스 후기에 보안 검토를 하는 경우가 많기 때문이다. 대신 서로 협력해 문제를 해결해고, 팀에 힘을 실어줘서 빨리 실패하고 지속적으로 개선을 하는 문화를 조성하는 것이다. 이런 변화를 주도하게 되는 사람은 통상 CSO와 CISO이다. 보안 팀은 '적색 깃발'을 들 때 대안을 제시하려 노력해야 하며, 해결책의 일부가 되어야 한다.
- 데브섹옵스로의 변화 과정 동안 변화 관리 기법으로 직원들을 지원해야 한다.
- 조직 재편이 필요할 수도 있다. 또는 데브옵스에 경험이 있는 새로운 직원을 채용해야 할 수도 있다.

2. 프로세스 재배치
SANS 인스티튜트 애플리케이션 및 보안 커리큘럼 관리자 에릭 존슨은 "조직 구조 측면에서 보면, 데브섹옵스를 구현하기 위해서는 보안과 컴플라이언스 팀이 각자의 프로세스, 정책, 요구 사항을 개발 및 운영 부문이 활용하는 동일한 데브옵스 워크플로우로 통합시켜야 한다"고 말했다. 보안 팀이 개발과 운영 엔지니어링 프로세스, 기술, 도구를 제대로 이해하지 못할 경우 데브섹옵스를 성공적으로 도입해 실천할 수 없다.

데브섹옵스의 가장 중요한 원칙이자 아주 중요한 프로세스 변화 가운데 하나는 '보안을 왼쪽으로 이동시키는 것'이다. 프로세스의 초기에 보안을 분석하고 테스트해야 한다는 의미다. 모든 프로젝트에서 보안 팀원들이 첫날부터 참여해 프로젝트를 책임지고, 프로젝트의 성공에 기여해야 한다. 개발자는 보안이 중시된 코딩에 대해 학습해야 한다. 보안 팀이 여기에 도움을 줄 수도 있다. 그러나 소프트웨어 엔지니어에게 이에 대한 교육을 해야 한다.

회사마다 적합한 프로세스가 다르다. 부즈 알렌 해밀턴(Booz Allen Hamilton)은 '여정에 대한 로드맵' 수립을 권장한다. 특정 기능(직능)에 있어 사용자가 통과하게 될 모든 것을 시뮬레이션 해야한다는 의미다. 이는 최종 프로세스가 처리하고 달성해야 하는 결과물을 확립하는 한 가지 방법이다.

3. 효율성과 정확성을 위한 자동화
데브옵스의 '핵심' 주제 가운데 하나는 자동화(Automation)이다. 데브섹옵스 또한 다르지 않다. 이는 데브섹옵스의 또 다른 주요 영역에서 아주 중요한 역할을 한다. 다름 아닌 '코드로 보안관리(Security as code)'라는 원칙이다.

보안 테스트, 가능한 많은 다른 접점들을 자동화하고, 소프트웨어 엔지니어들이 활용할 수 있는 보안 공유 코드 레포지토리(저장소)를 만들고, 데브옵스 CI/CD 파이프라인의 속도에 맞게 보안 프로세스를 단순화시켜야 한다. 이를 위해서는 보안, 엔지니어링, 운영 부서가 서로 협력해야 한다. 데브섹옵스라는 변화의 핵심 구성 요소다. 따라서 인재들을 배치해 추진해야 한다.

4. 현명하게 소프트웨어 도구를 선택
데브옵스 CI/CD 파이프라인과 기존 도구들에 쉽게, 그리고 효과적으로 연결할 수 있는 도구들을 선택해야 한다. 각 도구가 전달하는 기능, 자동화를 구현할 수 있는 수준 또한 고려하는 것이 좋다.

SANS 인스티튜트는 시큐어 데브옵스 툴체인(Secure DevOps Toolchain)과 SWAT 체크리스트라는 이름으로 다양한 데브옵스와 데브섹옵스 도구들을 분류, 정리했다.

SANS 인스티튜트의 에릭 존슨은 체크리스트의 데이터에서 대부분의 조직이 데브옵스 프로세스의 일부로 도입해야 하는 보안 점검과 이를 위해 고려해야 할 도구들 가운데 일부를 선정해 소개했다.
- 커밋 전 보안 파악(Pre-Commit Security Hooks) : 코드를 버전 제어로 커밋하기 전에 비밀(프라이빗 키, 시스템 비밀번호, 클라우드 액세스 키 등)을 스캔하는 코드 검사기
- 커밋 전 코드 검사(Pre-Commit Code Scanning) : 엔지니어가 쓴 코드를 실행해 간단히 보안을 검사할 수 있는 보안 플러그인이 포함되어 있는 아톰(Atom), 코드(Code), 인텔리제이(IntelliJ), 비주얼 스튜디오(Visual Studio)와 같은 코드 편집기
- 수동 보안 피어 평가(Manual Security Peer Review) : 깃허브(GitHub), 깃랩(GitLab), 비트버킷(Bitbucket)과 같은 곳에서는 기본 기능으로 탑재되어 있는, 고위험 코드 변경에 대해 보안 검사를 실시하기 위한 코드 검사 도구
- 정적 소스코드 스캐닝(Static Source Code Scanning) : 빌드 파이프라인의 보안 취약점을 찾기 위해 소스코드 파일(인프라 템플릿, 애플리케이션 소스코드 등)을 스캐닝
- 보안 유닛 테스트(Security Unit Tests) : 보안 및 엔지니어링 팀이 악의적 사용자에 대한 사례와 부정적인 테스트 사례를 다루기 위해 구현한 보안 유닛 테스트
- 종속성 관리 스캔(Dependency Management Scans) : 알려진 취약점을 찾기 위해 오픈소스 인프라 템플릿와 애플리케이션 구성 요소를 스캐닝
- 컨테이너 보안 스캐닝(Container Security Scanning) : 데브옵스에서 사용이 증가하고 있는 도커(Docker) 같은 컨테이너의 경우, 보안 팀은 컨테이너 이미지를 분석해 취약점과 노출된 비밀, 안전하지 않은 구성, 정책 컴플라이언스 등을 확인해야 함
- 동적 애플리케이션 보안 테스트(Dynamic Application Security Testing) : 실행 애플리케이션을 대상으로 공통된 보안 취약점(OWASP Top 10)을 스캔하고, Ganutlt/BDD 시큐리티 같은 도구를 사용해 승인 기준을 적용
- 인프라 승인 테스트(Infrastructure Acceptance Tests) : ISpec과 OpenSCAP 같은 도구를 사용, 인프라 승인 테스트로 강화된 기준(CIS 등)을 토대로 '금색' 이미지를 식별할 수 있음
- 비밀 관리(Secrets Management) : 볼트(Vault), 컨저(Conjure), AWS KMS, 애저 키 볼트(Azure Key Vault) 같은 도구를 사용해 비밀에 대한 프로비저닝 및 스토리지를 자동화.
- 지속적인 모니터링(Continuous Monitoring) : 프로덕션 환경을 모니터링해 취약점(vulnerabilities), 변칙(anomalies), 진행 중인 공격을 탐지(스태스디(StatsD), 그래파이트(Graphite), 그래판타(Graphanta) 등의 도구 사용)

5. 성과 측정
이런 주요 프로젝트에 앞서 매트릭스를 준비하는 것이 아주 중요하다. 투자 가치가 있는 성과를 일궈낼 수 있는지 여부를 판단할 수 있는 유일한 방법이기 때문이다. 놀랍게도 현재 이런 종류의 측정 및 평가에 사용할 수 있는 도구나 매트릭스는 존재하지 않는다. 부즈 알렌과 여러 전문가에 따르면, 도입하는 매트릭스가 무엇이든 '전달 리드 타임(lead time to deliver)', '배포 빈도 및 주기(the number and frequency of deployments)', '장애 복구 시간(mean time to recover, MTTR )', '비율로 표현된 결함 수의 변화'와 같은 데이터 포인트를 토대로 활용해야 한다. 일부 자동화된 코드 품질 스캐닝 솔루션은 지표로 사용할 수 있는 보안 코드 품질 점수를 제공한다. 이런 데이터 포인트를 결합해 사용하는 것이 가장 좋은 방법이 될 것이다. editor@itworld.co.kr  


X