2023년 글로벌 데브시크옵스 현황 보고서

아웃라인

시놉시스의 2023년 정보개발자 보안 운영현황 조사 보고서

2023년 초 시놉시스사이버 보안리서치 센터(CyRC)는 국제 시장조사 컨설팅 업체인 Censuswide와 함께 보안을 담당하는 1,000명의 IT 전문가를 대상으로 설문조사를 실시했습니다. 응답자에는 개발자, 앱 보안 전문가, DevOps 엔지니어, CISO, 인테크 전문가가 포함되었습니다,사이버 보안및 애플리케이션/소프트웨어
미국, 영국, 프랑스, 핀란드, 독일, 중국, 싱가포르, 일본 등 개발 분야에서 다양한 역할을 맡고 있는 전문가들이 인터뷰에 참여했습니다.
설문조사에는 업종이나 회사 규모에 관계없이 모든 응답자가 참여할 수 있었습니다. 이 설문조사를 개발할 때 어려웠던 점 중 하나는 "DevSecOps"라는 용어가 여러 분야를 포괄하며, 각 분야마다 고유한 역할이 있다는 점입니다. 이 설문조사는 코드를 '직접' 작성하는 개발자와 소프트웨어 보안을 담당하는 CISO 직급을 포함한 다양한 직업적 배경을 가진 사람들을 대상으로 진행하고자 했습니다.

DevOps 및 DevSecOps 정보

개발 가속화, 지속적 배포, 파이프라인 복원력, 확장성, 엔드투엔드 투명성은 데브옵스를 구현하기 위한 핵심 원칙입니다. 이러한 기준을 충족하려면 개발, 보안 및 운영 부서의 공동 노력이 필요합니다.

DevSecOps는 여러 팀에 보안 문화를 심어주고, 항상 보안 관행을 소프트웨어 개발에 통합하여 DevOps 환경에서 보안을 조기에 일관되게 해결하도록 설계된 DevOps 방법론의 확장입니다.
수명 주기 (SDLC) 및 CI 파이프라인을 통해 DevSecOps는 보안을 독립적인 단계에서 개발 라이프사이클의 일부로 전환하는 것을 목표로 합니다.

데브섹옵스는 소프트웨어 개발과 관련된 조직 전반에서 인기를 얻고 있으며, SANS의 데브섹옵스 현황 조사 2023에 따르면 데브섹옵스는 리스크 관리를 위한 중요한 비즈니스 관행 및 접근 방식이 되었습니다. 그러나 과거에는 보안팀과 개발팀이 보안을 프로세스에 통합하려고 할 때 종종 의견 충돌이 발생했는데, 그 이유는 대부분 다음과 같습니다.

이 관행은 전통적인애플리케이션 보안테스트(AST) 도구를 소프트웨어 개발 수명주기(SDLC)에 도입했습니다. 개발자들은 AST 도구가 너무 복잡하고, 배우기 어렵고, 성능이 낮고, '마찰' 즉, 소프트웨어 개발 과정에서 개발자가 쉽고 빠르게 코드를 작성하는 데 방해가 되는 '노이즈'를 많이 발생시킨다고 불평하는 경우가 많습니다. 소프트웨어 개발 과정에서 개발자가 쉽고 빠르게 코드를 작성하는 데 방해가 되는 것들. 응답자의 대다수는 현재 사용하는 AST 도구에 대해 전반적으로 불만을 표시했습니다.

자동화의 이점

데브옵스의 핵심 원칙은 SDLC의 모든 단계에서 수동 프로세스를 자동화하는 것입니다. 자동화는 모든 조직이 지속적 통합 또는 지속적 배포를 통해 코드의 개발 및 배포를 가속화하기 위한 필수 전제 조건입니다.
성공적인 데브섹옵스를 위해서는 통합과 자동화의 상호 작용은 물론 표준과 정책의 지침이 필요합니다. 이를 통해 보안팀은 보안이 보호되고 있다는 확신을 가질 수 있으며, 데브옵스 팀은 작업을 계속할 수 있고 파이프라인 중단이 발생하지 않을 것이라는 확신을 가질 수 있습니다. 수동 테스트와 달리 자동화된 보안 테스트는 빠르고 일관되게 실행할 수 있으므로 개발자는 배포 일정이나 생산성에 영향을 주지 않고 개발 프로세스 초기에 문제를 식별할 수 있습니다.

• 일관성
  자동화된 테스트는 모든 빌드 및 배포에 대해 보안 검사를 일관되게 수행하도록 보장합니다. 수동 테스트는 일관성 없는 테스트 프로세스와 적용 범위로 이어질 수 있습니다.
• 확장성
  소프트웨어의 복잡성이 증가함에 따라 수동 테스트는 비실용적이 될 것입니다. 자동화된 테스트는 다양한 구성 요소에 걸쳐 많은 수의 테스트를 수행할 수 있도록 쉽게 확장할 수 있습니다.
• 지속적 통합 및 지속적 배포(CI/CD)
  자동화된 테스트는 코드 변경이 빠르고 빈번하게 발생하는 CI/CD 파이프라인에서 매우 중요합니다. 자동화된 테스트를 통해 변경 사항을 빠르게 검증하고 버그가 있는 코드가 프로덕션 환경에 유입되는 것을 방지할 수 있습니다.
• 지속적인 개선
  자동화된 테스트는 개발 및 보안 팀이 시간이 지남에 따라 보안 관행을 개선하는 데 도움이 되는 데이터와 인사이트를 제공하여 취약성 패턴을 체계적으로 분석하고 해결할 수 있도록 합니다.
• 기록(스포츠 등)
  자동화된 테스트는 전체 테스트 프로세스를 문서화하여 보안 조치 및 규정 준수 요구 사항을 더 쉽게 추적하고 감사할 수 있습니다.
• 인적 오류 감소
  수동 테스트는 피로감이나 부주의로 인해 오류가 발생하기 쉽습니다. 자동화된 테스트는 미리 정의된 스크립트를 따르므로 인적 오류의 위험을 줄일 수 있습니다.
• 시간 및 비용 절감
  개발 프로세스 후반이나 생산 중에 안전 문제를 식별하고 수정하는 데는 많은 시간과 비용이 소요됩니다. 자동화된 테스트는 이러한 비용을 최소화합니다.
• 개발자 환경 개선
  자동화된 애플리케이션 보안 테스트를 통해 개발자는 보안 지식과 기술을 학습하고 개선하는 데 기여하는 사전 예방적이고 종합적인 접근 방식으로 보안 문제를 해결할 수 있으므로 개발자 경험을 향상시키고 궁극적으로 개발 프로세스 전반의 소프트웨어 보안과 효율성을 개선할 수 있습니다.

DevSecOps에서 ASOC/ASPM의 사용 증가 추세

이 보고서에서는 조직의 특성과 채택한 보안 도구/관행 등 데브섹옵스 성숙도의 여러 단계에 있는 조직을 조사합니다. 조사 결과를 바탕으로 소프트웨어 보안 성숙도를 더욱 향상시키는 데 도움이 되는 권장 사항을 제공합니다.
흥미로운 점은 설문조사 결과에 따르면 애플리케이션 보안 오케스트레이션 및 상관관계(ASOC)(현재는 애플리케이션 보안 상황 관리(ASPM)로 통칭)의 사용이 점점 더 보편화되고 있다는 것입니다. Gartner에 따르면, 여러 개발 및 보안 도구를 사용하는 모든 조직에서 ASPM을 우선적으로 고려해야 한다고 합니다.

개발부터 배포까지 ASPM 솔루션을 사용하면 보안 문제의 탐지, 상관관계, 우선순위 지정 등 광범위한 애플리케이션 리스크를 지속적으로 관리할 수 있으며, ASPM 도구는 여러 소스에서 데이터를 가져와 상관관계를 파악하고 분석하여 쉽게 해석, 분류, 수정할 수 있습니다.
ASPM은 보안 정책의 제어 및 시행을 지원하는 보안 도구의 관리 및 오케스트레이션 레이어 역할도 하며, 애플리케이션 보안 결과를 통합적으로 볼 수 있어 전체 애플리케이션 또는 시스템의 보안 및 위험 상태를 완벽하게 파악할 수 있습니다.
1,000명의 응답자 대부분이 비즈니스 요구에 따라 수정의 우선순위를 정하거나(351명) 문제 해결을 위해 데이터를 병합/연관시킬 수 없다(291명)고 불평하는 등 사용 중인 AST 도구에 전반적으로 불만족스러워했다는 점을 고려하면, ASOC/. ASPM의 사용이 빠른 성장세를 보이고 있는 것은 당연한 일입니다.

Synopsys의 2023 데브섹옵스 현황 설문조사의 주요 결과

대다수의 데브옵스 팀이 어느 정도 데브섹옵스를 도입했으며, 총 911명의 응답자가 소프트웨어 개발 파이프라인에 데브섹옵스 활동 수행을 위한 특정 보안 조치를 통합했다고 답했습니다. 이제 데브섹옵스 방법론의 도입은 소프트웨어 개발의 일부라고 해도 과언이 아닙니다.
보안 프로그램이 더 성숙한 조직일수록 보안 전담 인력을 보유하고 있습니다.291 TP3T 응답자들은 보안 프로그램의 성공에 중요한 요소로 개발, 보안, 운영 부서의 구성원들로 구성된 협업 팀인 교차 기능 DevSecOps 팀을 보유하고 있다고 답했습니다. 보안에 중점을 두고 개발자/소프트웨어 엔지니어 및/또는 QA 및 테스트와 함께 일하는 직원은 성숙한 보안 프로그램을 갖춘 조직에서 보안 테스트의 최전선에 있을 가능성이 높습니다.

효과적인 DevSecOps 구현에는 많은 장벽이 있습니다.

응답자의 331명 이상이 보안 교육 부족을 주요 장애물로 꼽았습니다. 그다음으로는 보안 인력 부족(311명), 개발/운영의 투명성 부족(311명), 우선순위 변경(301명)이 그 뒤를 이었습니다.

응답자의 3분의 1 이상이 자동화된 보안 테스트를 빌드/배포 워크플로에 통합하는 것이 보안 프로그램의 성공에 중요하다고 답했으며, 다른 주요 성공 요인으로는 코드형 인프라를 통한 보안/규정 준수 정책 시행, 개발 및 운영 팀의 보안 챔피언 육성, 개발, 운영 및 보안 팀 간의 커뮤니케이션 개선 등이 있습니다. 개발팀, 운영팀, 보안팀 간의 커뮤니케이션.

SDLC 후반에 주요 취약점을 처리하면 이득을 크게 잃을 수 있습니다.

응답자의 801TP3% 이상이 배포된 소프트웨어의 주요 취약점/보안 문제가 2022~2023년에 어떤 형태로든 업무 진행에 영향을 미쳤다고 답했습니다.
응답자의 281%는 배포된 애플리케이션의 주요 보안 위험/취약점을 패치하는 데 최대 3주가 걸린다고 답했으며, 나머지 201%는 최대 한 달이 걸릴 수 있다고 답했습니다.
이러한 수치는 취약점이 그 어느 때보다 빠르게 악용되고 있다는 점을 고려할 때 특히 문제가 됩니다. 최근 연구에 따르면 전체 취약점의 절반 이상이 공개 후 일주일 이내에 익스플로잇되는 것으로 나타났습니다.

표 1은 코드에서 보안 취약점 및 기타 결함을 스캔하기 위해 일반적으로 사용되는 자동화된 스캔 조치의 유형을 보여주는 것으로, '도구/프로세스의 유용성'이 1위를 차지했고, 'SDLC의 요구사항 채굴 단계에서 보안 요구사항 명시'와 'BSIMM, SAMM 등의 모델을 통한 소프트웨어 보안 계획의 공식적인 평가'가 그 뒤를 이었습니다. 그 뒤를 이어 'SDLC의 요구 사항 발견 단계에서 보안 요구 사항 명확화'와 'BSIMM 및 SAMM과 같은 모델을 통한 소프트웨어 보안 계획의 공식적인 평가'가 그 뒤를 이었습니다.

거의 모든 응답자가 AST 도구가 비즈니스 요구사항과 호환되지 않는다는 데 동의했습니다.

응답자 1,000명 중 대부분은 AST 도구가 비즈니스 요구에 따라 수정의 우선순위를 정하지 못한다는 점(351명)과 문제 해결에 도움이 되는 데이터 병합/연관성 부족(291명) 등 다양한 문제점을 주요 과제로 꼽았습니다.
52% 보안 전문가들이 데브섹옵스 이벤트에서 AI와 적극적으로 협업하기 시작했지만, 4분의 3 이상이 AI 사용에 대해 우려하고 있는 것으로 나타났습니다.
조사 결과에 따르면 보안팀은 AI, 머신러닝, 자연어 처리 및 신경망을 적극적으로 사용하고 있습니다. 그러나 AI 기반 코딩 조언과 같은 생성형 AI 도구의 사용이 증가함에 따라 AI 생성 코드와 관련된 다양한 지적 재산권, 저작권 및 라이선스 문제가 발생하고 있으며, 경우에 따라서는 소송까지 제기되고 있습니다.

2023년 데브시크옵스 현황 설문 조사

DevSecOps 배포

응답자 1,000명 중 1/3 이상이 보안 프로그램이 조직 전체에 걸쳐 보안 프로세스가 문서화되고 반복 가능하며 표준화된 성숙도 3단계에 도달했다고 답했습니다. 추가로 251명의 응답자는 보안 프로그램이 보안 프로세스가 문서화되고, 모니터링 및 평가되는 레벨 4에 도달했다고 답했습니다.
총 911명의 TP3T 응답자가 소프트웨어 개발 파이프라인에 어떤 유형의 DevSecOps 활동을 적용했다고 답했으며, DevSecOps의 도입은 이제 DevOps의 일부로 자리 잡은 것으로 보입니다.

귀사의 현재 소프트웨어 보안 프로젝트/프로그램의 성숙도는 어느 정도라고 생각하시나요?

보안 관행의 구현은 더 높은 수준의 성숙도를 나타냅니다.

그림에 표시된 데브섹옵스 성숙도의 또 다른 척도는 응답자들이 지속적인 모니터링 및 평가(30%)부터 자동화된 테스트(28%)에 이르기까지 광범위한 보안 관행을 채택하고 있음을 나타냅니다.
358명의 응답자(35.1%)가 모범 사례로 꼽은 보안 위험 관리에는 소프트웨어 애플리케이션과 관련된 잠재적 보안 위험을 식별, 평가 및 완화하기 위해 개발 프로세스의 각 단계에 보안 고려 사항을 통합하는 것이 포함됩니다. SDLC 프레임워크에 따라 전반적인 보안 위험 관리에는 다음과 같은 활동이 포함됩니다.

• 요구 사항 분석. SDLC 초기에 보안 요구 사항과 제약 조건을 파악하고 보안 목표를 정의하세요.
• 설계. 보안 원칙을 시스템 아키텍처와 설계에 통합하여 애플리케이션이 일반적인 취약성에 대한 적절한 보호 장치를 갖추고 설계되도록 하세요.
• 개발. 안전한 코딩 관행을 구현하고 보안 문제를 해결하는 코딩 표준을 준수하세요. 정적 애플리케이션 보안 테스트(SAST) 및 소프트웨어 구성 분석(SCA)과 같은 통합 보안 테스트 도구를 사용하여 코드를 작성하고 오픈 소스 또는 타사 코드를 도입할 때 취약점을 파악하세요.
• 테스트. SAST, 동적 애플리케이션 보안 테스트(DAST), SCA, 침투 테스트 등 다양한 유형의 보안 테스트를 수행하여 애플리케이션의 취약점을 파악하세요.
• 배포. 애플리케이션이 실행될 환경을 안전하게 구성합니다. 액세스 제어, 네트워크 보안, 적절한 인증 및 권한 부여 메커니즘을 구현합니다.
• 모니터링 및 평가. 프로덕션 환경의 애플리케이션에서 보안 이벤트와 이상 징후를 지속적으로 모니터링하세요. 로깅 및 모니터링 솔루션을 구현하여 다음을 감지하세요.
• 잠재적 침해 탐지 및 대응.301명의 TP3T 응답자는 이것이 조직에서 채택한 주요 보안 관행이라고 답했습니다.
• 대응 및 수정. 보안 인시던트를 신속하고 효율적으로 처리하기 위한 인시던트 대응 계획을 개발하세요. 테스트 단계에서 발견된 문제를 수정합니다.
• 투명성 및 보안. 명확한 규범, 표준 및 전략을 수립하고 보안 위험과 위험 허용 범위에 대해 보고합니다.
• 교육. 개발팀에게 안전한 코딩 방법, 일반적인 취약점, 보안 모범 사례에 대한 교육을 제공하여 개발자가 보안 문제를 선제적으로 해결할 수 있도록 지원하세요. 안타깝게도 341명의 응답자는 '개발자/엔지니어를 위한 불충분하거나 비효율적인 보안 교육'을 조직에서 효과적인 데브섹옵스 구현을 가로막는 주요 장애물 중 하나로 꼽았습니다.
• 지속적인 개선. SDLC의 안전 프로세스와 관행을 주기적으로 검토하고 개선합니다.

귀사는 어떤 보안 관행을 사용하고 있나요? (해당 항목에 모두 체크)

보안 계획 평가

약 701명의 TP3T 응답자가 소프트웨어 보안 아키텍처 성숙도 모델(BSIMM)과 같은 평가 도구를 통해 보안 프로그램을 평가하는 것이 유용할 것이라고 답했으며, 3분의 1 이상이 이러한 평가가 '매우 유용하다'고 평가했습니다.
보안 상태에 대한 외부 평가는 소프트웨어 보안 프로그램을 분석하고 다른 조직 및 동종 업계와 비교하는 데 도움이 될 수 있으며, BSIMM과 같은 도구는 리소스, 시간, 예산 및 우선순위에 대한 결정을 내릴 수 있는 데이터 기반의 객관적인 분석을 제공합니다. 보안 프로그램을 막 시작했든, 변화하는 비즈니스 및 보안 요구 사항을 충족하기 위해 기존 프로그램을 조정하든, 소프트웨어 보안 프로그램을 다른 프로그램과 비교하면 전략을 수립하는 데 도움이 될 수 있습니다.
소프트웨어 보안 프로그램을 책임지고 있거나 이제 막 개발하기 시작한 경우, 동료들의 앱 보안 동향을 이해하면 보안 노력을 전략적으로 개선하는 데 도움이 될 수 있습니다. 기술적인 관점에서 보안 프로그램을 관리하고 있다면 BSIMM 또는 SAMM(소프트웨어 보증 성숙도 모델) 평가의 정보를 사용하여 보안 챔피언 프로그램 개발과 같은 인력 및 프로세스에 대한 전술적 개선 사항을 개발할 수 있습니다.

실제로 BSIMM 보고서에 따르면, 많은 소프트웨어 보안 팀이 가장 먼저 하는 일 중 하나는 소프트웨어 보안을 주도하지만 소프트웨어 보안 팀과 직접적으로 연결되지 않은 사람들을 식별하는 것입니다. '소프트웨어 보안 옹호자'로 통칭되는 이러한 개인은 소프트웨어 보안 노력을 지원하고 추진할 수 있습니다. 예를 들어 엔지니어링 팀의 보안 옹호자는 엔지니어가 자신의 소프트웨어 결과물에 대한 보안을 책임지도록 독려할 수 있습니다.331 TP3T 응답자들은 소프트웨어 보안 프로그램의 성공 요인 중 하나로 보안 옹호자 프로그램을 개발하는 것을 꼽았습니다.

BSIMM 및 SAMM과 같은 모델을 통한 소프트웨어 보안의 공식적인 평가의 효과.

DevSecOps 성공을 위한 교차 기능 팀의 중요성

291명의 응답자는 개발, 보안, 운영 인력의 협업 팀인 교차 기능 DevSecOps 팀이 보안 프로그램 성공의 핵심이라고 답했습니다(부록 Q16 참조). 보안 전문가는 개발자/소프트웨어 엔지니어 및/또는 QA 및 테스트 팀(공식적으로 DevSecOps 팀의 일원이든 아니든)과 협력하여 보안 테스트를 위한 첫 번째 방어선이 될 수 있으며, 조직이 보다 성숙한 보안 프로그램을 구축하는 데 도움을 줄 수 있습니다.
보안 팀이 배포 전후에 단일 파이프라인으로 테스트하는 것은 이제 과거의 일이 되었습니다. 오늘날의 소프트웨어 개발 환경에서 보안 테스트는 품질 보증, 개발 및 운영 팀을 포함한 전체 엔지니어링 팀의 책임이며, 대부분의 팀은 소프트웨어 개발 수명 주기의 다양한 단계에서 소프트웨어에 보안을 구축합니다.
331명의 TP3T 응답자는 조직에서 외부 컨설턴트를 고용하여 보안 테스트를 실시한다고 답했습니다. 가장 좋은 방법은 정기적인 보안 감사를 실시하는 것입니다. 외부 감사기관이나 모의 침투 테스터를 고용하여 이러한 테스트를 실시하는 것은 조직 전체의 보안 상태를 객관적으로 파악하는 데 매우 유용합니다.

조직에서 보안 테스트는 누가 담당하나요? (해당 항목에 모두 체크)

최적의 결과를 위한 수동 및 자동 테스트의 조합

설문조사 결과에 따르면 응답자의 대다수는 수동 보안 테스트와 자동화된 보안 테스트를 함께 사용하면 비즈니스 크리티컬 애플리케이션의 보안을 평가하는 데 더 포괄적인 접근 방식을 제공할 수 있다고 생각하는 것으로 나타났습니다. 자동화된 테스트는 일관성, 확장성, 시간 및 비용 절감을 위해 중요하지만, 사람이 직접 참여하면 복잡하고 미묘한 보안 문제를 식별하는 데 필수적인 인사이트와 적응력을 더할 수 있습니다. 예를 들어, '블랙박스' 테스트(즉, 애플리케이션 내부에 대한 지식 없이 테스트하는 것)로서 DAST는 개발자와 개발자가 모두 테스트 프로세스에 참여해야 합니다.보안 전문가테스트 결과의 유효성 검사 및 분류.
마찬가지로 44% 응답자가 외부 모의 침투 테스트를 보안 테스트의 핵심 요소로 간주한다는 사실은 모의 침투 테스트가 내부 테스트를 보완하는 중요한 요소라는 것을 증명합니다. 외부 모의 침투 테스트는 종종 업계 규범과 표준을 준수하기 위해 수행되며, 조직의 보안 태세를 객관적으로 평가하고 외부 공격자가 악용할 수 있는 잠재적 위협과 취약점을 정확하게 시뮬레이션하는 등의 추가적인 이점을 제공할 수 있습니다.

비즈니스 크리티컬 애플리케이션의 보안을 어떻게 평가하거나 테스트하나요? (해당 항목 모두 선택)

주요 성과 지표

이 설문조사에서는 응답자들에게 데브섹옵스 프로그램의 성공을 평가하는 데 가장 중요한 3가지 핵심 성과 지표(KPI)를 선택하도록 요청했습니다. 1위는 295명의 응답자(29%)가 꼽은 '공개 취약점의 전반적인 감소'가 차지했으며, 2위는 288명의 응답자(28%)가 꼽은 'SDLC 후반부에 발견된 보안 관련 이슈의 감소'가, 3위는 288명의 응답자(28%)가 꼽은 'SDLC 후반부에 발견된 보안 관련 이슈의 감소'가 그 뒤를 이었습니다. 그 뒤를 이어 응답자 288명(28%)이 꼽은 'SDLC 후기 단계에서 발견되는 보안 관련 이슈 감소'가 2위, 응답자 281명(28%)이 꼽은 '이슈 해결 시간 단축'이 3위를 차지했습니다.

설문조사 결과에서 알 수 있듯이 시간, 생산성, 비용은 앞선 세 가지 KPI의 공통점이자 조직이 안전한 SDLC를 구현할 때 직면하는 과제입니다. 다시 말해, 데브섹옵스 참여자들이 직면한 세 가지 주요 문제는 다음과 같습니다.

• 취약점/이슈 발생 건수를 줄이려면 어떻게 해야 할까요?
• SDLC 초기에 취약점을 찾으려면 어떻게 해야 하나요?
• 문제 해결에 걸리는 시간을 단축하여 빌드 지연을 줄이고 개발 효율성을 개선하려면 어떻게 해야 할까요?

데브시크옵스 활동의 성공을 평가하는 데 사용하는 주요 KPI는 무엇인가요? (최대 3개까지 선택)

어떤 AST 도구를 사용하고 계신가요? 유용한 도구인가요?

조사 결과에 따르면 성공적인 데브섹옵스 전략은 동적 애플리케이션 보안 테스트(DAST), 대화형 애플리케이션 보안 테스트(IAST), 정적 애플리케이션 보안 테스트(SAST), 소프트웨어 구성 분석(SCA) 도구 등 소프트웨어 개발 수명 주기 전반에 걸쳐 코드 품질 및 보안 문제를 해결하기 위해 완전한 보안 도구 세트를 사용합니다.
설문조사 결과, 응답자의 72%가 유용하다고 답한 SAST가 가장 인기 있는 AST 도구로 나타났습니다. 그 뒤를 이어 IAST(69%), SCA(68%), DAST(67%)가 그 뒤를 이었습니다.
SAST와 DAST는 SDLC 단계에 따라 서로 다른 테스트 방법론을 사용합니다. SAST는 SDLC 초기(즉, 애플리케이션 배포 전)에 독점 코드의 취약점을 발견하고 제거하는 데 중요한 반면, DAST는 배포 후 인증 및 네트워크 구성 결함 등 운영 중 문제를 발견하는 데 적합합니다. SAST는 SDLC 초기(즉, 애플리케이션 배포 전)에 독점 코드의 취약점을 발견하고 제거하는 데 중요하며, DAST는 배포 후 인증 및 네트워크 구성 결함과 같은 운영상의 문제를 발견하는 데 적합하고, IAST는 다른 유형의 테스트에서는 식별할 수 없는 중요한 보안 결함을 탐지하기 위해 SAST와 DAST의 일부 기능을 결합한 테스트입니다.
SCA는 오픈 소스 보안 및 라이선스 위험을 식별하고 관리하는 데 적합하며, 이는 특히 특정 애플리케이션 코드의 4분의 3 이상이 오픈 소스일 가능성이 높은 최신 소프트웨어 개발의 핵심 요건입니다. 많은 조직이 독립 소프트웨어 공급업체에서 구매한 패키지 소프트웨어와 사물인터넷(IoT) 디바이스 및 임베디드 펌웨어를 사용하고 있기 때문에 AST 툴킷 내에서 어떤 형태로든 SCA 바이너리 분석을 수행해야 할 수도 있습니다.

조직에서 사용하는 다음 애플리케이션 보안 도구가 유용한가요(있는 경우)?

언제 테스트하나요? 패치는 언제 적용되나요? 작업 일정에 어떤 영향을 주나요?

애플리케이션 보안 테스트의 빈도는 애플리케이션의 일상적인 비즈니스 중요도, 업계, 위협 환경 등 여러 가지 요인에 따라 달라집니다. 설문조사 결과에서 알 수 있듯이 매우 중요한 애플리케이션은 정기적으로 평가해야 합니다(그림). 이 설문조사에 참여한 대부분의 응답 조직은 일주일에 평균 2~3일에 한 번씩 비즈니스 크리티컬 애플리케이션에 대한 취약성 스캔을 수행한다고 답했습니다.
언뜻 보기에 281개의 TP3T를 보유한 조직이 주요 취약점을 패치하는 데 최대 3주가 걸린다는 조사 결과(그림 1)는 걱정스러워 보일 수 있지만, 다른 요인들과 함께 고려해야 합니다. 전설적인 개발자들이 모든 취약점을 패치할 수 있다는 오해가 있지만, 그 누구도 개발자들에게 중요하지 않은 취약점을 아무 이유 없이 파헤치라고 요구하지 않습니다.
데브섹옵스 구현을 가로막는 주요 장벽으로 311명의 TP3T 응답자가 '개발/운영의 투명성 부족'을, 291명의 TP3T 응답자가 '개발, 운영, 보안 간의 조직적 사일로'를 꼽았다는 점에 주목할 필요가 있습니다(그림 1). 그리고 291명의 TP3T 응답자는 "개발, 운영, 보안 간의 조직적 사일로"를 꼽았습니다(그림 2). 이 두 가지 모두 보안팀과 개발팀 간의 리스크 커뮤니케이션 문제와 보안 정책의 신속한 알림 및 자동화의 필요성을 지적합니다.
모든 경우에 취약점 패치의 우선순위는 패치 대상 자산의 비즈니스 중요도, 중요도, 자산이 악용될 위험도, 특히 마지막 사항을 고려하여 결정해야 합니다. 연구에 따르면 모든 취약점의 절반 이상이 공개 후 1주일 이내에 악용되는 것으로 나타났습니다.

조직에서 비즈니스 크리티컬 애플리케이션의 보안에 대한 평가 또는 테스트를 평균적으로 얼마나 자주 수행하나요?

조직에서 배포되었거나 사용 중인 애플리케이션의 중대한 보안 위험/취약점을 패치/해결하는 데 평균적으로 얼마나 걸리나요?

따라서 조직은 취약점 공개 '0일차'뿐만 아니라 애플리케이션의 전체 수명 주기 동안 공통 취약점 점수 시스템(CVSS) 점수, 공통 취약점 열거(CWE) 정보, 취약점 악용 가능성을 기반으로 취약점 수정의 우선순위를 정해야 합니다.
CVSS 점수는 위험의 심각성을 평가하기 위한 업계 표준입니다. 국가 취약점 데이터베이스(NVD)의 각 취약점에는 취약점의 심각도를 계산하고 취약점 해결의 우선순위를 안내하는 기본 점수가 있으며, CVSS 점수는 취약점의 악용 가능성 및 영향을 고려한 종합적인 기본 점수입니다.
시간 점수는 취약점 외부의 이벤트로 인한 시간 경과에 따른 변화를 고려한 지표입니다. 수정 수준(공식적인 수정 프로그램이 있는가?) 및 보고 신뢰도(보고서가 확인되었는가?). 그리고 보고 신뢰도(보고서가 검증되었는가?). 전체 CVSS 점수를 적절한 위험 수준으로 조정하는 데 도움이 될 수 있습니다.
CWE 정보에는 보안에 영향을 미치는 소프트웨어 또는 하드웨어 결함이 나열되며, CWE는 개발자에게 어떤 결함이 악용될 수 있는지(이용 가능한 취약점이 있는 경우) 알려줍니다. 이 정보는 보안팀과 개발팀이 개발자 보안 교육에 중점을 둘 부분, SDLC와 프로덕션에 구현할 추가 보안 제어, 위험 심각도 평가 메커니즘을 추가할지 여부를 파악하는 데 도움이 됩니다. 예를 들어, 개발팀은 애플리케이션이 다루는 데이터, 애플리케이션이 배포된 위치, 기타 환경 및 보안 요인에 따라 SQL 인젝션, 버퍼 오버플로 또는 서비스 거부에 서로 다른 우선순위를 할당할 수 있습니다.

취약점이 있으면 위험 점수가 높아지며, 작업팀은 위험도가 가장 높은 취약점에 대한 수정의 우선순위를 정하는 데 도움이 됩니다. 전반적인 위험도를 평가한 후에는 패치, 완화 또는 보완 제어를 즉시 사용할 수 있는지 여부를 파악하는 것도 고려해야 할 또 다른 핵심 정보입니다. 예를 들어, 위험도는 중간이지만 사용되지 않는 취약점이 두 개 있는 경우, 어떤 취약점을 먼저 수정할지는 결국 기존 패치나 솔루션이 있는지 여부에 따라 달라질 수 있습니다.
배포된 애플리케이션의 주요 보안 또는 취약성 문제는 다이어그램에 표시된 것처럼 조직(또는 고객)의 비즈니스 운영뿐만 아니라 SDLC 전체에 영향을 미치는 연쇄적인 영향을 미치는 경우가 많습니다.
개발 초기에 발견된 문제는 사소한 것일 수 있지만, 배포된 애플리케이션에서 발견되면 '모두가 나서서 해결해야 하는' 중대한 문제가 될 수 있습니다. IDE와 CI 파이프라인에 통합된 자동화된 보안 테스트 도구는 코드가 커밋된 직후(또는 커밋되기 전)에도 코드의 취약성과 결함을 식별할 수 있으므로 개발자는 문제가 다운스트림으로 전파되기 전에 문제를 해결할 수 있습니다.

지난 1년(2022~2023년) 동안 주요 보안/취약성 문제의 해결이 귀사의 소프트웨어 배포 계획에 미친 영향은 어느 정도였나요?

효과적인 DevSecOps를 위한 과제

그림 K에서 볼 수 있듯이 사이버 보안 인재 부족은 데브섹옵스의 주요 과제입니다. 많은 조직이 주요 사이버 보안 역할에 적합한 인재를 채용하지 못하고 있습니다. 일부 연구에 따르면 전 세계적으로 350만 개의 사이버 보안 공석이 있다고 합니다. 숙련된 사이버 보안 전문가 시장이 성장함에 따라 공급 부족은 숙련된 실무자의 임금 상승으로 이어져 많은 정부 기관과 중소기업이 감당할 수 없는 수준의 임금을 지불하게 될 것입니다. 그러나 그림 K에서 볼 수 있듯이 '개발자/엔지니어에 대한 보안 교육 부족'이 여전히 가장 큰 과제로 남아 있습니다.
보안 챔피언 프로그램을 구축하는 것은 조직 전체에서 보안에 대한 평균 이상의 관심이나 기술을 보유하고 있으며 이미 개발, 품질 보증 및 운영 팀을 지원하기 위해 자신의 전문성을 활용하고 있는 개인을 식별하여 이러한 문제를 해결하는 효과적인 전략임이 입증되었습니다. 보안 챔피언은 새로운 프로젝트에 대한 아이디어와 피드백을 제공할 뿐만 아니라 보안팀이나 엔지니어링팀이 소프트웨어 보안 기술과 신기술 또는 급변하는 기술에서 부족할 수 있는 도메인 지식을 결합할 수 있도록 도울 수 있습니다. 애자일 코치, 스크럼 마스터, 데브옵스 엔지니어는 특히 프로세스의 마찰을 파악하고 제거하는 데 있어 보안 옹호자가 될 수 있는 훌륭한 후보입니다.

조직에서 데브시크옵스를 구현하는 데 있어 어려운 점/장벽은 무엇인가요? (해당 항목 모두 선택)

이 보고서의 앞부분에서 언급했듯이, 응답자들은 SAST, DAST, IAST, SCA와 같은 AST 도구를 모두 널리 사용하고 있지만, 이러한 도구를 비즈니스 요구사항에 효과적으로 연결하는 것은 여전히 과제로 남아 있습니다.
많은 응답자가 사용하는 보안 테스트 도구가 보안 취약점의 노출, 악용 가능성, 심각도 등의 요인에 따라 수정 노력의 우선순위를 정하지 않고, 너무 느려서 빠른 릴리스 주기/지속적인 배포를 수용하지 못하며, 부정확하고 신뢰할 수 없다고 불평했습니다.
서로 다른 보안 테스트의 결과를 통합하거나 상호 연관시킬 방법이 없기 때문에 보안 및 DevOps 팀은 먼저 수정해야 할 취약점을 파악하는 데 너무 많은 시간을 소비하며, 이는 응답자의 약 4분의 3이 조직에서 알려진 중요 취약점을 패치하는 데 2주에서 한 달이 걸린다고 답한 이유 중 하나일 수 있습니다.
취약점을 신속하게 패치하지 않으면 근본적인 이익에 영향을 미칩니다. 응답자의 80% 이상이 배포된 소프트웨어의 주요 취약점 또는 관련 보안 문제를 해결하는 것이 2022~2023년에 업무 일정에 영향을 미쳤다고 답했습니다.

AST 도구의 파편화와 느린 문제 해결은 애플리케이션 보안 오케스트레이션 및 상관관계(ASOC) 및 애플리케이션 보안 상황 관리(ASPM)가 해결하도록 설계되었으며, Gartner는 ASOC/ASPM이 여러 AST 도구를 조율하는 관리 계층으로 작동하여 발견된 문제의 상관관계와 컨텍스트화를 자동화하여 문제 해결 프로세스를 가속화하고 최적화할 수 있다고 지적합니다.

ASOC/ASPM은 여러 소스에서 결과를 추출하고 통합하여 전체 애플리케이션 환경에 대한 통합된 위험 뷰를 제공하므로 비즈니스 컨텍스트(예: 심각도)에 따라 데이터 기반 수정 노력의 우선순위를 지정하여 가장 위험도가 높은 취약점을 더 빠르게 수정할 수 있습니다. 또한 ASOC/ASPM은 프로덕션 환경에 대한 가시성을 제공하여 배포된 애플리케이션의 취약점을 수정하는 데 오랜 시간이 걸리는 문제를 해결하고 대부분 취약점 공개 후 며칠 이내에 발생하는 익스플로잇을 효과적으로 방지할 수 있습니다.

조직에서 사용하는 애플리케이션 보안 테스트 도구의 주요 문제점은 무엇인가요? (최대 3개 선택)

AI의 약속과 함정

설문조사 결과에 따르면 응답자의 501% 이상이 DevSecOps 관행에 AI를 적극적으로 사용하고 있다고 답했으며, 응답자의 541%는 보안 조치의 효율성과 정확성을 개선하기 위해 AI를 활용하고 있고, 응답자의 481%는 보안 테스트의 수동 검토를 줄이기 위해 AI를 활용하고 있다고 답하는 등 AI가 많은 조직의 소프트웨어 보안 프로그램에 침투한 것으로 나타났습니다. 수동으로 테스트합니다.
AI가 데브섹옵스에 제공할 수 있는 주요 이점을 고려하면 이는 당연한 결과입니다. 앱 보안 팀은 완벽하고 일관된 보안 테스트의 필요성과 데브옵스 방법론 및 CI 파이프라인을 사용하는 개발 팀과 보조를 맞춰야 하는 필요성 사이에서 종종 딜레마에 빠지곤 합니다. 마감 기한이 촉박하면 개발자는 중요한 보안 위험 평가 프로세스를 건너뛰기 쉽습니다.
이 설문조사에 참여한 응답자들은 '보안 조치의 정확성과 효율성 향상'(541명)과 '보안 데이터의 수동 검토 및 분석 필요성 감소'(481명)를 보안 SDLC에 AI를 도입하는 두 가지 주요 목표로 꼽았습니다. 보안 SDLC에 AI를 도입하는 두 가지 주요 목표는 다음과 같습니다.
그러나 인터뷰 참여자들은 AI가 "소프트웨어 보안의 복잡성과 기술적 요구 사항을 증가시킬 것"으로 예상하며, AI가 생성한 코드를 적절히 조사할 수 있는 유일한 주체가 AI 그 자체일 때가 올 수도 있다고 답했습니다.

데브섹옵스에서 AI를 구현하려면 데이터 품질 보장, 보안 및 개인 정보 보호 문제 해결과 같은 추가적인 과제가 있습니다. AI 도구가 점점 더 DevOps 파이프라인에 통합됨에 따라 보안 위협의 주요 표적이 될 것이 거의 확실합니다. AI 학습에 사용되는 민감한 데이터를 처리할 때 개인정보 보호 문제도 제기됩니다.
예를 들어 AI 지원 코딩은 AI가 생성한 코드에 대한 소유권, 저작권 및 라이선스 문제를 야기할 수 있으며, AI 사용과 관련된 여러 가지 잠재적 위험이 있습니다.
2022년 말, 개발자에게 코딩 시 자동화된 보완 제안을 제공하는 클라우드 기반 AI 도구인 GitHub Copilot이 저작권법 및 소프트웨어 라이선스 요건을 위반하고 있으며 Copilot을 학습시키는 데 사용되는 오픈 소스 코드가 저작권을 침해한다는 주장이 제기되어 GitHub, Microsoft, OpenAI에 대한 집단 소송이 제기되었습니다. Copilot의 서비스를 학습시키는 데 사용되는 오픈 소스 코드도 개발자의 권리를 침해하고 있습니다. 이 소송은 또한 Copilot에서 제안하는 코드가 출처 표시, 저작권 고지 또는 원래 라이선스 조건을 준수하지 않고 라이선스 자료를 사용한다고 주장합니다.

ChatGPT 및 Google Bard와 같은 대규모 언어 모델에 기반한 생성형 AI 챗봇도 '환상', 즉 신뢰할 수 있고 자신감 있어 보이지만 실제로는 잘못된 응답, 즉 쉽게 말해 '거짓말'을 무작위로 생성하는 문제를 안고 있습니다. "거짓말".
AI 환각은 소프트웨어 공급망의 보안을 위협하는 것이 분명합니다. 연구원들은 ChatGPT가 존재하지 않는 환상적인 코드베이스 또는 소프트웨어 패키지를 제안할 수 있다는 사실을 발견했습니다. 악의적인 공격자는 동일한 이름의 패키지를 만들어 악성 코드를 채운 다음 AI의 조언을 따르는 순진한 개발자에게 배포할 수 있습니다. 이는 사이버 범죄자들에게 파괴적인 영향을 미칠 수 있으며, 철자 오류나 위장과 같이 쉽게 탐지되는 기존의 기술을 우회할 수 있게 해줍니다. 실제로 연구원들은 ChatGPT의 유령 조언을 기반으로 만들어진 멀웨어 패키지가 이미 PyPI 및 npm과 같은 유명 패키지 관리자에 존재한다는 사실을 발견했습니다.
이러한 위협은 이론적인 것이 아니라 실제로 일어나고 있습니다. 공급망 공격의 원인이 인공지능이든 악의적인 행위자든, 이를 방어하기 위해서는 코드의 출처를 파악하고, 개발자와 관리자의 신원을 확인하고, 신뢰할 수 있는 공급업체나 출처에서만 패키지를 다운로드하는 것이 중요합니다.

배운 교훈

대부분의 조직이 데브섹옵스 관행을 상당 부분 채택하고 있지만, 이를 효과적으로 구현하는 데 여전히 어려움을 겪고 있습니다. 설문조사에 따르면 이러한 문제는 크게 두 가지 영역에 집중되어 있는 것으로 나타났습니다.
- 여러 애플리케이션 보안 테스트(AST) 도구의 결과를 통합하고 비즈니스 우선순위에 맞게 조정하세요.
- 중요한 취약점을 해결하는 데 필요한 시간 단축
응답자의 281%는 조직에서 배포된 애플리케이션의 주요 보안 위험/취약점을 패치하는 데 최대 3주가 걸린다고 답했습니다. 또 다른 응답자 20%는 취약점을 패치하는 데 최대 한 달이 걸릴 수 있지만 대부분의 취약점은 공개 후 며칠 이내에 악용된다고 답했습니다. 응답자들은 AST 도구가 비즈니스 요구에 따라 취약점 패치의 우선순위를 정할 수 없다는 점이 가장 불편하다고 답했습니다.
이 보고서의 서문에서 언급했듯이, 설문지를 개발할 때 어려웠던 점 중 하나는 "DevSecOps"라는 용어가 여러 분야를 포괄하고 있으며, 각 분야마다 고유한 역할이 있다는 점입니다. "비즈니스 우선순위"라는 측면에서 보면 역할에 따라 이 용어에 대한 이해가 다를 수 있습니다.
예를 들어, 비즈니스 경영진은 앱보안 도구의 효과에 대해 가장 관심이 많으며, 프로세스를 종합적으로 파악하고 팀 전체의 성과를 개선할 수 있는 방법을 알고 싶어합니다. 개발 및 운영 팀은 모든 이슈를 중앙에서 파악하여 가장 가치 있는 보안 활동을 식별하는 데 AppSec이 도움이 되기를 원합니다. 보안 전문가는 잡음을 제거하여 중요한 문제의 우선순위를 정하고 신속하게 해결할 수 있기를 원합니다.
애플리케이션 보안 태세 관리(ASPM)는 사일로화된 보안 툴을 통합하는 동시에 비즈니스 요구 사항을 충족하는 데 어려움을 겪고 있는 조직에 필요한 개선 기능을 제공하여 사일로화된 툴을 자동으로 조율하고 컨텍스트화하며 우선순위를 지정하여 조직이 비즈니스에 가장 중요한 애플리케이션 보안 이슈에 집중할 수 있도록 지원합니다.
- ASPM은 개발 및 보안 테스트 도구는 물론 운영 및 유지 관리 모니터링 도구와 통합하여 조직 전체에 보안 관련 정보를 통합된 단일 뷰로 제공할 수 있습니다.
- 특정 애플리케이션과 취약점을 분석하는 여러 도구의 데이터를 상호 연관시키고 그룹화하여 애플리케이션의 전반적인 보안 상태를 종합적으로 파악할 수 있습니다. DevSecOps 팀은 자신의 역할과 책임과 관련된 데이터를 생성할 수 있으며, ASPM은 이 데이터를 현업 관리자 및 더 넓은 관점을 필요로 하는 다른 사람들에게 의미 있는 방식으로 제공할 수 있습니다. DevSecOps 팀은 자신의 역할과 책임과 관련된 데이터를 생성할 수 있으며, ASPM은 현업 관리자와 더 넓은 관점을 필요로 하는 다른 사람들에게 의미 있는 방식으로 이 데이터를 제공할 수 있습니다.
- ASPM을 사용하면 특정 애플리케이션 및 취약성과 관련된 특정 위험을 해결하는 보안 정책을 개발하고 시행할 수 있습니다. 또한 ASPM을 개발 또는 운영 인프라와 통합하면 보안 문제를 가능한 한 빨리 식별하고 해결할 수 있습니다.
2021년 가트너 보고서에 따르면 설문조사에 참여한 조직 중 약 51개 TP3T가 ASPM 또는 그 이전 버전인 애플리케이션 보안 오케스트레이션 및 상관관계(ASOC) 도구를 채택했으며, 2023년에는 설문조사에 참여한 조직 중 281개 TP3T가 이미 ASOC/ASPM을 사용하기 시작했다는 결과를 통해 이러한 채택률이 빠르게 증가할 것으로 예상하고 있습니다. 또한 Gartner는 얼리 어답터들은 성숙한 DevSecOps 프로그램을 갖춘 팀이며 여러 보안 도구를 사용하는 경향이 있으며, 이는 DevSecOps 설문조사 응답자의 특징이기도 합니다.

응답자의 특성

이 보고서에서 조사한 설문조사에 따르면 보안 도구가 제공하는 단편적인 결과, 과중한 업무 부담, 느린 취약점 수정 속도가 데브섹옵스의 성공을 방해하는 근본적인 문제입니다. 다양한 데브섹옵스 팀을 보유하고 여러 애플리케이션 보안 테스트 도구를 사용하는 조직의 경우 ASPM이 이러한 문제를 효과적으로 해결할 수 있는 열쇠가 될 수 있습니다.

응답자의 산업 분포