이 글에서는 GitLab의 보안 정책 관리 기능이 ‘보안과 컴플라이언스가 소프트웨어 개발 속도를 따라가는 데 어떻게 도움이 되는지’ 살펴보겠습니다.
보안팀은 소프트웨어 개발 속도를 따라잡아야 하는 과제에 직면해 있습니다. 이들은 개발 프로세스에서 보안의 중요성과 개발자 대 보안 인력의 비율을 간과하는 리더와 같은 장애물을 계속 마주합니다. 이제 AI를 통한 코드 추천이나 자동 생성이 등장해 개발 속도가 훨씬 더 높아지고 있습니다. 기업이 엔터프라이즈 수준으로 확장함에 따라 개발 속도는 더 빨라질 겁니다. 따라서 개발 프로세스를 관리하는 데 사용되는 보안 도구는 이러한 성장에 맞춰야 합니다.
애플리케이션 보안팀은 취약점을 효과적으로 관리하고 우선순위를 지정해야 합니다. GitLab의 보안 정책 기능을 다양한 보안 도구 제품군과 함께 사용하면, 조직은 보안팀과 개발팀 간에 협업을 촉진하여 효율적인 취약점 탐지, 분류, 해결을 가능하게 할 수 있습니다. 또한 보안 정책은 보안 컴플라이언스를 자동화하고 이를 엔터프라이즈 규모로 관리하는 메커니즘을 제공합니다.
잠재적인 취약점 소스를 더 많이 스캔하면 문제를 조기에 탐지하고 해결하는 기회가 더 많이 생기지만, 엄청난 양의 검출 결과가 보안팀을 압도할 수 있습니다. 추가 스캔에서 취약점 관련 인사이트를 종합적으로 확보함에 따라, 이를 해결하기 위해 실행 가능한 일을 확인하는 건 무척 어려워지고 있습니다.
취약점 관리 분류 프로세스
오늘날 취약점 분류를 다루는 몇 가지 일반적인 접근 방식이 있습니다.
- 공통 취약점 점수 시스템(Common Vulnerability Scoring System·CVSS): CVSS는 취약점 심각도를 평가하는 표준화된 방법을 제공합니다. CVSS 점수를 활용하면서, 조직은 잠재적인 영향에 기반해 취약점의 우선순위를 지정하고 이에 따라 리소스를 할당할 수 있습니다.
- 위험 기반 점수(Risk-based scoring): 위험 기반 점수를 사용하면, 조직은 악용 가능성과 잠재적인 비즈니스 영향에 기반해 취약점을 평가할 수 있습니다. 자산 가치, 위협 행위자의 힘, 익스플로잇(취약점 공격) 확산과 같은 상황적 요인을 고려하면서, 조직은 취약점의 우선순위를 효과적으로 지정할 수 있습니다.
- 위협 모델링(Threat modeling): 위협 모델링은 애플리케이션이나 시스템에 잠재적인 위협을 확인하고 평가하는 일을 포함하는 접근 방식입니다. 시스템 아키텍처, 데이터 흐름, 잠재적인 공격 벡터를 종합적으로 분석하면서, 조직은 잠재적 위협과의 관련성에 기반해 취약점의 우선순위를 지정할 수 있습니다. 이 접근 방식은 악용될 가능성이 높은 취약점에 집중하면서, 리소스를 효과적으로 할당하는 데 도움이 됩니다.
- 비즈니스 영향 분석(Business Impact Analysis·BIA): BIA는 취약점이 비즈니스 운영과 목표에 미치는 잠재적인 영향을 평가하는 데 사용되는 기법입니다. 여기에는 중요한 자산을 확인하고, 조직에 그들의 중요성을 평가하며, 공격이 성공할 때 잠재적인 결과를 정량화하는 작업이 포함됩니다. 잠재적인 재무, 평판, 운영 영향을 고려하면서, 조직은 핵심 비즈니스 기능에 가장 심각한 위험을 초래하는 취약점의 우선순위를 지정할 수 있습니다.
AI 생성 코드가 점점 더 확산되면서, 의도하지 않게 도입되는 취약점이 늘고 있습니다. 이러한 분류 기법은 기업이 우선순위를 분류하고 이해하는 데 중요합니다. 그렇다면 이러한 개념 프레임워크를 현실에 어떻게 적용할까요? 이러한 기법을 실행하는 방법을 살펴보겠습니다.
보안 정책 관리
보안 정책은 비즈니스 수준의 정책과 컴플라이언스 요구 사항을 DevSecOps 관행과 소프트웨어 개발 라이프사이클에 반영된 실질적인 운영 지침에 내재화하는 것이 해답입니다. GitLab의 보안 정책 안에서 규칙을 생성하면서, 조직은 취약점 평가의 세분화된 기준을 정의하여 실행 가능한 조사 결과만 더 주의하도록 표시할 수 있습니다.
보안 정책을 사용하면 보안과 컴플라이언스 요구 사항과 모범 관행을 코드에 인스턴스화하여 실행할 수 있습니다. 스캔 실행 정책은 사용자의 수요와 요구 사항에 기반해 특정 프로젝트 안에서 스캐너가 실행되도록 하여 코드를 프로덕션 환경에 merge 하기 전에 모든 취약점과 노출이 탐지되도록 합니다.
또한 스캔 결과 정책을 활용하여 취약점을 해결하는 맞춤형 워크플로를 생성할 수도 있습니다. 정책은 보안과 컴플라이언스 스캐너 결과를 평가하여 Merge Request(MR)가 ‘사용자가 정의한 규칙’에 따라 철저하게 리뷰받고 승인되지 않으면, 이 MR이 merge 되는 걸 방지하거나 차단합니다.
스캔 결과 정책과 스캔 실행 정책을 활용하면서, 개발 프로세스에 감독 계층을 추가할 수 있습니다. 이는 사람이 작성한 코드(또는 다른 방식으로 작성된 코드)가 자동으로 검사받고, 정책 위반이 일어나면 실행 가능성이 가장 높은 엔지니어링팀과 보안팀 간에 협업을 장려하도록 할 수 있습니다.
스캔 결과 정책에서 세분화된 규칙 정의
한 단계 더 나아가려면, 아래에 공유된 필터와 속성에 기반해 스캔 결과 정책 안에서 세분화된 규칙을 정의할 수 있습니다. 이러한 규칙은 ‘어떤 취약점을 가장 잘 조치할 수 있는지’ 결정하고, 정적 신호(결함이 될 수 있는 코드 요소들)를 찾는 데 도움이 될 수 있습니다.
- 취약점 상태(Vulnerability status): 보안 정책은 취약점 상태에 기반해 대상을 지정할 수 있으며 분류가 필요한, 새롭게 탐지된 취약점에 초점을 둘 수 있습니다. 이전에 탐지된 특정 심각도의 취약점에 따라 규칙을 생성하거나, 무시된 취약점을 포함/제외할 수도 있습니다.
- 브랜치(Branch): 중요한 프로젝트의 기본 브랜치에 적용을 집중하거나 보호된 브랜치를 대상으로 지정하는 것과 같이 특정 브랜치에만 적용을 지정할 수 있습니다.
- Fix available: 의존성과 컨테이너 스캐닝 결과에서 수정 사항을 이용할 수 없는 조사 결과를 필터링합니다. 이는 서드 파티의 업스트림 변경 사항에 의존하며, 아직 실행할 수 없습니다. 이슈는 취약점에서 생성되고, 기한을 추적하여 수정 사항을 이용할 수 있게 되면 이를 해결할 수 있습니다.
- 거짓 긍정(False positive): GitLab 스캐너가 조사 결과를 거짓 긍정(컨테이너와 의존성 스캐닝에서)으로 판단하면, 취약점 안에 상태를 표시합니다. 그다음, 보안 정책은 이를 활용하여 보안 정책 감독에서 거짓 긍정을 필터링하며, 보안팀 엔지니어와 개발자가 이러한 조사 결과를 무시하고 구애받지 않은 채 코드를 merge 하도록 합니다. 필요하면, 심층 분석을 위해 취약점을 취약점 보고 서에서 계속 사용할 수 있습니다.
- 시기(Age) 또는 서비스 수준 계약(SLA): 때로는 조직에서 심각도가 낮은 취약점을 한동안 허용할 수 있지만, 이를 합리적인 SLA 안에서 계획하고 해결해야 합니다. 보안 정책을 사용하면, 중간 수준의 취약점이 60일의 SLA를 승인받지 않고(기한이 있는 후속 이슈에서 해결할 수 있음) merge 되도록 허용하는 것처럼, 조사 결과의 심각도에 기반해 SLA를 설정할 수 있습니다. 그러나 취약점이 60일 SLA를 초과하는 걸로 탐지되면, MR을 차단하고 취약점을 해결해야 합니다.
조직 전체에서 중요한 조사 결과의 우선순위 지정
대량의 취약점을 처리하는 일반적인 접근 방식 중 하나는 작은 규모로 시작하여 조직 전체에서 발견된 가장 중요한 조사 결과의 우선순위를 지정하는 겁니다. 취약점 관리 분류 SLA는 취약점 심각도에 기반해 특정 SLA 안에서 취약점을 해결하는 규칙을 정의하여 이를 충족하도록 지원합니다. 아래 영상은 GitLab 스캔 결과 정책을 활용하여- 각 취약점 심각도에 서로 다른 SLA를 실행하는 간단한 데모입니다. 이때 심각도가 높은 조사 결과가 탐지되면 MR이 30일 동안 차단되지 않으므로 개발자가 SLA 기간 안에 문제를 해결할 시간을 확보할 수 있습니다.
출처=GitLab
업무 분리 보장
보안 정책은 다양한 방법으로 관리할 수 있지만, 보안 전문가와 개발팀 간의 업무 분리를 보장하는 격리된 GitLab 프로젝트에서 관리하는 게 가장 좋습니다. 정책은 YAML 파일로 저장됩니다. 이러한 코드형 정책 접근 방식은 보안팀의 역량을 키우고, 가시성 측면에서 정책 변경 사항의 Git 이력, 중대한 변경 사항을 더 쉽게 롤백하는 버전 제어, 정책 변경 사항의 감독과 필수 승인(필요한 경우), GitLab 감사 이벤트(audit events)를 통한 감사 가능성, 감사자에게 증거로 공유할 수 있는 구체적인 관리 기능을 포함해 수많은 이점을 제공합니다.
모든 걸 하나로 묶기
계속 늘어나는 취약점을 관리하려면 철저한 스캐닝과 효율적인 분류와 해결 간의 균형을 맞추는 정교한 접근 방식이 필요합니다. GitLab의 보안 정책은 협업을 가능하게 하고, 맞춤형 정책 규칙을 정의할 때 유연성을 제공하는 강력한 솔루션과 비즈니스 요구 사항과 컴플라이언스 프레임워크를 정확하게 운용하는 수단을 지원합니다. GitLab의 보안 도구를 활용하고 맞춤형 필터와 속성을 적용하면서, 조직은 취약점 관리를 간소화하고 가장 중요한 위험을 해결하는 데 노력을 집중하여 궁극적으로 전체 보안 태세를 강화하며, 외부 기구의 요구 사항을 충족할 수 있습니다. AI 생성 코드가 두려울 수 있지만 보안의 세 가지 요소(사람, 프로세스, 기술)는 여전히 유효합니다. 비즈니스 프로세스에 보안 정책을 통합하면, 이러한 위험에서 비즈니스를 보호할 수 있습니다.
보안 정책을 활용하여 규모 있게 코드형 정책을 시행하는 걸 넘어서, GitLab DevSecOps 플랫폼은 강력한 보안 도구 모음을 제공합니다. 최근 GitLab의 2023년 글로벌 DevSecOps 보고서에서 보안 전문가의 57%가 소프트웨어 개발에 6개 이상의 도구를 사용한다고 응답했으며, 보안 전문가의 69%는 툴체인을 통합하고 싶다고 밝혔습니다. 도구 통합은 수많은 CISO(최고정보보안임원)가 유념하고 있으며, GitLab은 툴체인의 무질서한 확장을 줄이도록 지원합니다. GitLab은 SAST(정적 애플리케이션 보안 테스트, IaC 포함), Secret Detection(비밀 탐지), Container Scanning(컨테이너 스캐닝), DAST(동적 애플리케이션 보안 테스트, API 포함), Dependency Scanning(의존성 스캐닝), API Security(API 보안) 등 핵심 보안 스캐닝 솔루션을 제공합니다. 아울러 동적 취약점 보고서를 사용해 보안팀의 취약점 관리를 지원합니다. 또 컴플라이언스 프레임워크, 컴플라이언스 보고서, 감사 이벤트(audit events)를 활용해 컴플라이언스의 루프를 줄여줍니다.
GitLab을 사용하여 애플리케이션 보안을 관리하는 방법을 더 자세히 알아보세요.
인포그랩은 GitLab 및 DevOps에 대한 맞춤 기술 지원을 제공합니다. GitLab(Omnibus/Cloud Native Hybrid) 구축 관련한 지원이 필요하시면 문의하기 로 연락 주십시오.
이 포스트는 GitLab의 동의를 받아 공식 블로그의 영문 포스트를 우리말로 번역한 글입니다.