우리 조직의 DevSecOps 성숙도를 체크 해보세요!
GitLab에서 만든 DevSecOps 자가진단 가이드는 DevSecOps 운영상의 성숙도를 파악하고, 개선이 필요한 부분을 찾아내는 데에 도움을 드리기 위해 제작되었습니다. DevSecOps 수행에 중요한 20가지 역량 체크리스트를 통해 자가 진단을 진행하시고, 뒤에 이어지는 정의를 참조하세요. 해당 역량이 왜 중요한지 확인하세요. 그리고 무엇을 더 고려하고 발전시켜야 할 지에 대해 저희와 같이 검토해보세요.
평가가 완료되면 각 역량 충족으로 얻는 이상적인 프로세스를 확인하실 수 있습니다. 문의하기으로 연락 주시면 인포그랩에서 맞춤형으로 성숙도 진단지를 만들어서 진단하시는 것을 도와드립니다.
맞춤형 진단은 인포그랩에서 컨설팅시 제공하는 개발팀의 성숙도 체크를 참고하세요.
성숙도 체크리스트
이번 장에서는 DevSecOps를 운영하는 조직들이 일반적으로 갖추고있는 역량 및 성격 목록을 제시하고 있습니다. 각 항목 별로 귀사의 점수를 0, 1, 3, 5 중 하나로 매겨보십시오.
점수표:
- 0 = 전혀 일어나지 않음
- 1 = 가끔 일어남
- 3 = 빈번히 일어남
- 5 = 조직 전반에 널리 일어남
속도
귀사의 개발 프로세스 내에서 보안 파트를 떠올려 보십시오. 그것이 론칭까지의 시간을 지연시키고 있습니까 아니면 가속시키고 있습니까?
항목 | 점수 | |
---|---|---|
1. | 애자일 프로세스를 사용중이며 워터폴 구조에서 대부분 탈피하였음 | |
2. | 작은 코드 수정이 필요할 때는 전체 프로젝트나 코드에 대한 변경 없이도 빠르고 안전하게 런치됨 | |
3. | 보안스캔을 기다리느라 프로젝트가 일시 중단되는 경우가 드물다 |
프로세스 효율성과 개발 초기 보안성 테스트
귀하의 팀에서 최근에 착수한 프로젝트들을 떠올려 보십시오. 소프트웨어 개발 단계의 어떤 시점에서 보안 테스트가 시작되었습니까? 사일로화된 개발과 보안 부서의 마찰로 인해 시간이 낭비되진 않았습니까? 팀 간의 비효율적인 업무 전달, 시스템 전반의 부족한 가시성, 미비한 계획과 배려 등으로 인해 프로젝트가 지연된 적은 없습니까?
항목 | 점수 | |
---|---|---|
4. | 보안 스캐닝이 개발자 워크플로우에 내제되어 코드가 다른 이에게 넘어가기 전에 취약점을 감지하고 보수함 | |
5. | 보안팀에게 전달되기 전에 전체 코드 최소 90%사 테스트 되었음 | |
6. | 보안팀이 스캔 결과를 리뷰하기 이전에 이미 다수의 취약점이 교정됨 | |
7. | 절대 다수의 취약점이 런칭 이전에 교정됨 |
협업 방법
보안팀이 개발 및 운영팀과 협업하는 게 얼마나 원활한지를 평가해보세요. 각자 분야에서 사용하는 툴에 대한 가시성과 투명성이 확보되어 있습니까?
항목 | 점수 | |
---|---|---|
8. | 개발팀과 보안팀 모두 코드 내의 취약점 위치, 작성자, 수정 진행 내역 및 결과를 쉽게 추적할 수 있음 | |
9. | 커뮤니케이션은 신속하고 투명하여, 저체 프로젝트팀 사이의 협업이 쉬움 | |
10. | 협업은 대게 어려운 수정 작업을 트러불 슈팅하기 위해, 혹은 이를 미연에 방지하기 위해 진행됨 |
자동화 수준
DevOps 파이프라인 내의 보안 운영은 얼마나 자동화되어있습 니까? 코드 수정은 어느 정도 비율로 취약성이 스캔 됩니까? 언제, 그리고 어떻게 테스트가 진행됩니까? 교정은 어떻게 진행합니까?
항목 | 점수 | |
---|---|---|
11. | 모든 코드 수정에 보안 스캔이 자동으로 적용됨 | |
12. | 스캔 결과가 설정에 따라 자동으로 작업 티켓 혹은 이슈를 생성하거나, 빌드를 중단시킴 | |
13. | 설정에 대한 예외 사항이 리포팅되고 설정 변경에 대한 평가 가능함 | |
14. | 중대한 수동 작업이 거의 필요하지 않음 |
보안 문화
모든 팀들이 보안에 대한 책임을 지니고 있는지를 생각해 보십시오. 모든 팀들이 보안 교육, 가이드라인, 정책을 전달받았습니까? 개발자들이 보안성을 충족하는 코드를 생성하고 전달하기 위한 책임감과 권한을 가지고 있습니까?
항목 | 점수 | |
---|---|---|
15. | 보안팀이 아닌 직원들도 보안의 중요성을 인지하고 있음 | |
16. | 직원들이 테스트와 코드리뷰와 같은 보안 절차를 본인 일과에 포함시키기 위한 자율권이 있음 | |
17. | 직원들이 본인 작업의 보안성을 평가하고 유지하는데 책임을 지님 | |
18. | 전사적인 보안 정책이 분명하고 정기적으로 소통되고 있고 기본적으로 실시됨 |
표준화된 수행 절차
보안 기준이 자동적으로 집행되고 있습니까?
항목 | 점수 | |
---|---|---|
19. | 보안 전문가들이 확립한 보안 기준이 어디서나 자동적으로 적용되게 설정됨 | |
20. | 컴플라이언스가 정기적으로 평가되고 예외가 검토되고 있음 |
진단결과 계산
각각 항목에 대한 지금까지의 점수를 합산해보세요.
항목 | DevSecOps성숙도 |
---|---|
0~ 45점 | 초급 |
46~75점 | 중급 |
76~100점 | 고급 |
다음단계:개선을 위한 액션플랜 세우기
당장 원하는 만큼의 점수를 받지 못하였더라도, DevSecOps는 충분히 개선될 수 있습니다. 귀하의 팀이 개선할 수 있도록 낮은 점수를 받은 카테고리를 집중적으로 살펴보십시오. 그 후 개선하기 위한 액션 아이템의 리스트를 작성하시길 권합니다.
성공적인 DevSecOps를 위한 카테고리별 탐구
다음 정보를 검토하여 각 카테고리가 중요한 이유를 이해하고 팀이 DevSecOps 여정에서 달성해야 할 목표를 설정하도록 도와주십시오. 각 카테고리별 설명에는 성숙도별 시나리오와 필요 역량, 초기 액션 아이템 목록이 포함됩니다
속도
속도는 속력과 방향을 모두의 영향을 받습니다. 팀이 빠르게 일 처리를 하더라도 자꾸만 일을 반복해야 한다면 전체 속도는 늦춰질 것입니다. 대부분의 DevSecOps를 처음 접하는 팀들은 보안 스캔 및 테스트를 기존 DevOps에 통합하는 데 어려움을 겪습니다. 이는 애자일한 개발 프로세스를 늦추고 결과적으로 출시 일자를 지연시킵니다. 보안을 나중으로 미루는 게 아닌 개발 프로세스 전반에 통합시키면 보안 병목 현상을 최소화하고 결과적으로 론칭 속도를 극대화 할 수 있습니다. 속도는 귀하의 제품/서비스에 대한 비즈니스적인 기대와 고객으로부터의 기대 모두를 충족시키는 데 중요합니다. 보안 업무를 줄이면 당장은 릴리즈 시간을 높일 수도 있겠지만, 보안유지에 대한 고객의 기대치뿐 아니라 사건 발생 시의 브랜드 이미지와 수익에 끼치는 악영향까지 점점 높아지고 있음을 잊지 말아야 합니다.
DevSecOps 성숙도 | |
---|---|
초급 | 보안 스캔은 소프트웨어 개발 수명 주기 막바지에 이루어지며 스캔 후의 수정으로 인해 릴리즈가 지연되는 경우가 종종 있습니다. 지연을 방지하기 위해 일부 오픈소스 라이브러리나 컨테이너는 검색되지 않습니다. 소프트웨어는 자주 업데이트되지만, 보안 스캔은 자주 수행되지 않음으로 코드는 보안 테스트를 위해 일괄 처리되거나 론칭 후에 모의침투 테스트 됩니다. |
중급 | 개발자가 사용하는 스캐너나, 보안팀 멤버를 스크럼에 포함해 진행하는 수동 보안 리뷰를 통해 소프트웨어 개발 과정에 보안을 통합합니다. |
고급 | 전 과정에서 이루어지는 자동화된 보안 스캔을 통해 모든 코드 변경을 점검하므로 취약점은 작성 즉시 발견됩니다. 작은 변화조차도 빠르고 안전하게 론칭할 수 있습니다. 보안 테스트가 애자일 프로세스와 궤를 함께합니다. |
필요 역량 | 액션 아이템 |
---|---|
1. SDLC에 통합된 애자일한 보안 워크플로우 2. CI파이프 라인에 통합된 보안 스캔 결과 3. 프로젝트 모든 요소의 보안 상태에 대한 완전한 가시성 | 1. SDLC내에서 워터폴 형태의 보안 프로세스를 줄이거나 제거하기 2. 개발팀과 보안팀 사이의 불만을 파악하고 이를 해결하기 위한 계획을 세우기 3. 모든 새로운 변경 사항이 스캔되도록 보안 검색을 자동화하기 4. 코드가 머지된 후 취약점을 처리하는 데 낭비되는 시간을 측정하기 |