Analysis and Design of Development Life Cycle Impact of Open Source Tool Vulnerabilities

오픈소스 도구 취약점의 개발생명주기 영향도 분석 및 설계

Abstract

Recently, automated tools and processes are being adopted using DevOps (Development, Operations). Many companies are embracing open source tools for each CI/CD stage, considering cost savings, flexible customization and scalability, and vendor lock-in. Furthermore, they are adopting IaC (Infrastructure as Code) to configure everything from development to initial infrastructure environments. Among these, Terraform, an IaC tool, is used for configuration. It is necessary to first diagnose vulnerabilities using SCA tools for both the infrastructure configuration code and application code, and then generate an SBOM to immediately track component usage and change history. This paper presents an architecture that analyzes and resolves the impact of open source tools on the development lifecycle when vulnerabilities arise in a CI/CD environment that leverages rapid development and automated security tools.

최근 DevOps(Development, Operation)을 이용하여 자동화된 도구와 프로세스를 도입하고 있다. 많은 기업들은 비용 절감, 유연한 커스터마이징 및 확장성, 벤더 종속성 등을 고려하여 CI/CD 각 단계별 도구를 선택할 때, 오픈소스 도구를 많이 사용하고 있다. 또한, IaC(Infrastructure as Code)를 도입하여 개발부터 초기 인프라 환경까지 많이 구성한다. 그 중 IaC 툴인 Terraform을 이용해서 구성하는데 인프라 환경 구성 코드와 애플리케이션 코드에 대해서 SCA 도구를 이용하여 취약점 진단을 선행하고 이후에 SBOM을 생성해 구성요소 사용처와 변경이력을 즉시 추적할 수 있어야 한다. 본 논문에서는 빠른 개발과 자동화된 보안 도구를 이용하는 CI/CD 환경에서 오픈소스 도구가 취약점 발생 시 개발생명주기에 미치는 영향도 분석과 해소가 가능한 아키텍처를 제시한다.

1. 서론

최근 개발과 운영을 하나의 흐름으로 통합하는 문화인 DevOps를 통해서 개발과 배포에 대하여 유연하게 대응하고 있다. 소프트웨어 개발팀과 운영팀의 협업을 강화하고, 소프트웨어 개발과 배포를 더 빠르고 안정적으로 진행할 수 있다. DevOps 환경을 구현하는 데 많이 사용하는 도구들은 오픈소스로 구성되어 있다. Open Source Software(이하 오픈소스 도구)들을 이용함으로써 비용 효율성, 유연성과 커스터마이징 가능성, 벤더 종속성, 투명성과 신뢰성, 활발한 커뮤니티와 빠른 업데이트 등 오픈소스의 여러 가지 장점으로 인해서 많은 기업이 사용하고 있으며 사용량이 증가하고 있다.

CI/CD(Continuous Integration/Continuous Deployment) 도구들을 통해서 지속적 통합과 지속적 배포를 자동화하는 기능을 제공하고 있는데 CI/CD에 구현된 오픈소스 도구에서 취약점이 발생할 때, CI/CD 파이프 라인은 빌드, 테스트, 배포 등 중요한 작업을 자동화하기 때문에, 취약점으로 인해 악성 코드 삽입, 배포 환경 조작, 민감 정보 유출 등의 보안 사고로 이어질 수 있다. 그리고, CI/CD 도구가 내부 네트워크와 연동되므로 취약점으로 인해 내부 시스템까지 공격자가 접근할 가능성이 있다. 오픈소스 CI/CD 도구는 많은 장점을 제공하지만, 적극적인 보안 관리가 필수이다.

또한, CI/CD 환경뿐만 아니라, 개발생명주기의 인프라 환경을 구성할 때, IaC 도구를 이용하여 코드로 작성하여 구성한다. 코드로 인프라를 구성할 경우 잘못된 네트워크 설정, 권한 과다 부여, 비밀 정보 노출, 보안 설정 누락, 취약한 기본값 사용, 업데이트 및 패치 관리 부재, 자동화 도구 취약점과 같이 보안 취약점 및 주의할 점이 필요하다. 따라서 코드로 작성 시에 위험 유형을 파악해야 하며 해당 유형에 맞게 대응 방안이 필요하다.

따라서 오픈소스 도구에만 취약점 진단이 필요한 것이 아닌 인프라 환경 구성 코드에서 제일 먼저 취약점 진단 및 대응이 필요하다. 그러므로 코드 내에 코드 취약점 분석할 수 있는 항목을 추가하여 코드 작성 후 인프라 환경 구성 단계 전에 코드에 대한 취약점을 분석하며 보안상 취약한 부분이 있으면 환경 구성이 실패하는 단계가 필요하다.

본 논문에서는 인프라 환경 구성 코드에 대해 사전 코드 점검을 수행하고, 빌드 단계에서 SBOM을 자동으로 생성한 다음 이를 바탕으로 SCA(Software Composition Analysis) 도구를 통해 CI/CD 파이프라인에 포함된 오픈소스 구성요소의 취약점을 진단한다. 제안된 아키텍처는 취약점의 조기 탐지 및 자동 대응을 통해 개발생명주기에 미치는 영향을 최소화하는 것을 목표로 한다.

2. 배경 및 관련 연구

2.1 Open Source Software 사용량

최근 DevOps 분야에서 오픈소스 도구 사용이 크게 증가하고 있으며 오픈소스 도구만으로 전체 DevOps 환경 구현이 가능하다. 2023년 Logz.io의 ‘DevOps Pulse’ 보고서에 따르면, 응답자의 95% 이상이 오픈 소스 도구를 활용하고 있다고 한다[1].

(그림 1)의 내용을 살펴보면, 2024년 OpenLogic의 ‘State of Open Source’ 보고서에는 조직에서 사용하는 오픈 소스 도구를 확인했을 때 GitLab이 41.79%, Jenkins 32.12%를 사용한다고 응답하였다[1]. 실제 Jenkins에서는 2024년 초 CVE-2024-23897의 위험도가 매우 높은 취약점이 발생하였다[2]. DevOps 환경에서 오픈 소스 도구의 사용량이 높아지고 있는 만큼 파이프라인에 구성되어 있는 오픈 소스 도구에 대한 사전 대응 및 사후 대응이 중요하다는 것을 확인할수 있다.

(그림 1) Open Source tool usage

2.2 DevOps 단계별 사용하는 Open Source Software 종류

DevOps 환경을 구현하기 위한 핵심은 지속적인 통합 및 지속적인 배포이다. DevOps 환경을 통하여 수동 작업이 자동화되며 개발자는 고객의 요구를 반영한 애플리케이션을 빠르게 개발 및 배포, 테스트가 가능해지며 애플리케이션에 대한 개발 및 테스트 부분을 무중단 운영 환경을 통해 배포할 수 있으므로 많은 기업은 DevOps 환경을 더 선호하고 있다.

<표 1>은 개발 단계에서 사용하는 오픈 소스 도구 종류를 나열한 것이다.

<표 1> DevOps Step-by-Step Open Source Software

<표 1>를 보면, DevOps 단계별로 사용할 수 있는 오픈 소스 도구 종류를 확인할 수 있다. 앞서 설명한 2.1의 내용과 같이 오픈 소스 도구 사용량은 증가하고 있으며 오픈 소스 도구만으로 DevOps CI/CD 환경 구성이 가능하다. 많은 기업에서 빠른 애플리케이션 개발과 배포를 위해 DevOps를 도입하지만, 비용 절약과 효율성 향상을 위해 오픈 소스 도구들을 활용하고 있다[3].

2.3 Open Source Software에서 발생한 취약점

DevOps 환경에 구현되어 있는 오픈 소스 도구에 취약점이 발생할 경우 빌드 및 배포 실패, CI/CD 인프라 침해, 컴플라이언스 위반, 취약한 오픈 소스 포함된 애플리케이션 배포, 취약한 컨테이너 이미지 확산 등 DevOps 자동화의 보안 문제가 발생할 것으로 예측된다.

<표 2>와 같이 Log4Shell 오픈 소스 취약점으로 인해 피해자의 시스템과 연결되어 원격으로 코드가 실행이 가능한 환경이 되며 원격 서버를 호출하여 시스템에서 임의의 코드가 실행되거나 내부 정보가 유출될 수 있다[4]. 실제로 CI/CD 자동화 도구인 Jenkins에서 원격 코드 실행 취약점으로 인해 약 8만 개의 인스턴스가 영향을 받았다[5]. 이 취약점은 Jenkins가 에이전트 프로세스를 관리하고 컨트롤러와 상호작용을 하는 방식에 존재한다. ClassLoaderProxy#fetchJar 방법을 악용하면 공격자는 에이전트 프로세스를 조작하여 민감한 구성 파일, 자격 증명 또는 소스 코드까지 노출될 수 있으며, 이러한 정보가 악의적으로 악용될 때 추가적인 보안 침해로 이어질 수 있다[6].

<표 2> Open Source Vunlerabilities

DevOps 환경에서 오픈소스 도구 취약에 대비하려면 먼저 CI/CD 도구(jenkins, sonarqube 등)의 취약성 검증을 선행하고, 그 이후에 SCA로 파이프라인의 모든 오픈소스 구성요소를 자동 스캔하며 SBOM을 생성, 관리해 구성요소 사용처와 변경이력을 즉시 추적할 수 있도록 아키텍처를 설계해야 한다.

3. 대응 설계 및 도구 특성 분석

3.1 SCA 도구 및 사용 환경

SCA(Software Composition Analysis)은 오픈소스 및 서드파티 라이브러리를 사용하는 프로젝트에서 보안 취약점, 라이선스 이슈, 컴플라이선스 리스크 등을 식별 및 관리하기 위한 도구이다.

<표 3>과 같이 SCA 도구로는 OWASP Dependency-Check, Synk, Grype, Trivy 등이 있으며 개발 환경 또는 CI/CD 도구들이 구현되어 있는 환경 및 특성에 따라 적절한 도구를 선택해야 한다. Trivy와 Grype 도구처럼 SCA 역할을 하는 것 뿐만이 아닌 SBOM 생성을 지원하는 도구로 취약점 스캔 이상의 소프트웨어 공급망 보안 확보와 운영 효율성 향상 시킬수 있을 것으로 보여진다.

<표 3> SCA Tools

3.2 SBOM 사용 필요성

SBOM은 해당 소프트웨어를 구성하는 모든 오픈 소스 및 서드파티 컴포넌트의 이름, 버전, 라이선스, 출처 등을 기록한 목록이다.

<표 4>와 같이 SBOM을 사용하여 취약점을 식별하고, 보안 표준 준수를 보장하며, 신속한 사고 대응을 촉진하는데 도움이 된다. 강력한 SBOM을 활용하여 소프트웨어 자산을 유지 관리하고, 변경 사항을 추적하며 잠재적인 보안 위험을 조기에 감지할 수 있다.

<표 4> Benefits of Using SBOM

또한, SCA만 사용하여 취약점 스캔 및 조치만 하는 것보다는 SCA와 SBOM을 병행으로 사용하여 구성 요소를 자산으로 만들고 관리하여 장기적인 보안 및 자동화, 감사, 규제 대응을 관리할 수 있을 것으로 판단된다[11].

3.3 SBOM 도구 특징

SBOM 도구는 단순 목록 생성에 그치지 않고, 보안, 라이선스, 공급망 관리까지 확장된 기능을 제공하는 경우가 많다. 특히 CI/CD 과정에 SBOM 생성을 자동화해 릴리즈 전 취약점 차단과 정책 준수 검증을 함께 수행하는 것이 일반적이다.

<표 5>와 같이 각 상황에 맞는 도구를 선택하여 사용할 수 있다[9]. 목적, 환경, 자원이 다르면 최적의 도구를 적용하여도 불필요하게 무겁거나, 기능이 부족하거나, 운영에 부담이 될 수 있다. 또한, 각 개발생명 주기 환경이 다르기 때문에 현재 개발 환경에 맞게 SBOM 도구를 선택해야 효율적으로 사용할 수 있을 것으로 보여진다.

<표 5> Features of SBOM tools

3.4 대응방안 설계도

SCA 도구를 사용하여 정적 코드 분석만을 하는 것이 아닌 CI/CD 도구 자체 내부에 포함된 오픈소스 라이브러리들의 취약점 진단이 필요하다.

DevOps 단계 중 Build 단계를 실행하기 전에 SCA 도구를 통하여 CI/CD 각 단계에 구성되어 있는 오픈 소스 도구의 취약점 진단을 통하여 취약점 발견이 될 경우에는 CI/CD 단계가 실패하게 된다. 그 후, 취약점에 대한 조치가 완료되었을 때 다음 단계를 진행할 수 있도록 아키텍처를 설계하였다. Build 단계에서는 코드 컴파일 및 빌드 자동화를 수행하므로 Build 단계에서 사용하는 도구의 취약점 진단 이후 코드 분석을 진행한다.

따라서, (그림 2)와 같이 Build 단계 전에 SCA 도구로 BUILD, TEST, RELEASE, DEPLOY, OPERATE, MONITOR 도구들의 취약점 진단을 진행하며 정책 설정을 통하여 단계를 진행할 수 있도록 한다. CI/CD 도구들이 어떤 오픈 소스 컴포넌트가 적용돼 있으며, 이 컴포넌트가 어떤 버전을 갖고 있는지 파악해야 한다.

(그림 2) DevOps Architecture with SCA

SCA 도구로 오픈 소스 도구에 대해서 점검을 진행했을 때 CVE ID, 라이브러리 버전, 심각도, 설명 및 대응하기 위한 방법에 대해서 확인이 가능하다. 또한, SBOM(Software Bill of Materials) 생성과 SCA 검증을 통해 실제로 사용되는 구성 요소 기반의 정밀한 보안 분석이 가능할 것으로 예상된다.

4. 구현 및 검증

4.1 빌드 환경과 IaC 적용 현황

최근에는 개발생명주기 전반에서 IaC 도구를 사용하여 인프라 환경을 구성하는 사례가 많아지고 있다. 2024년 기준으로 72% 기업이 IaC를 사용하며 그중 60% 이상이 Terraform을 채택하여 사용하고 있다[8]. 또한 애플리케이션의 빌드 파이프라인 내에서도 Terraform을 활용하여 인프라 설계부터 운영까지 전 주기를 자동화하고 코드로 관리할 수 있다. IaC 도구를 활용하면 코드로 안전하고 일관되게 관리하고 자동화된 배포 및 변경 이력 추적이 가능하며 운영 효율성과 재현성, 감사 추적성을 확보할 수 있다.

Terraform으로 CI/CD 환경을 구성하는 사례가 많아지는 만큼 SCA 및 SBOM을 통합하여 보안 취약점 탐지와 오픈소스 라이선스 확인하는 자동화가 필요하다. 본 논문에서 제시했던 대응방안 설계도와 같이 Terraform으로 작성한 코드에 대해서 SCA 및 SBOM 도구 실행하여 취약점 검사를 진행하도록 한다. SCA를 통해서는 Terraform 코드, 모듈, 의존성 관련 취약점 검사를 진행하며 SBOM을 통해서는 코드 내 오픈소스 구성요소 문서화를 진행한다. 해당 결과를 확인하여 취약점 검출 시 파이프라인이 실패하도록 설계가 필요하다.

4.2 빌드 단계의 코드 취약점 분석

본 논문에서 제시한 바와 같이, 최근 IaC 도구를 사용하여 인프라 환경 구성 및 애플리케이션 빌드하는 경우가 많은 만큼 코드부터 취약점 분석이 필요하다. 아래 환경은 로컬에서 VSCode를 통해 Terraform을 이용하여 CI/CD 환경을 구성하였다. AWS 환경에 Public 인스턴스에 CI 도구인 Jenkins와 Jenkins Build Agent 서버를 구성하고 코드 작성 후 GitHub에 Push 하며 GitHub Action을 통해 자동으로 환경 구성이 이루어지도록 구성하였다. 빌드 전 코드에 보안에 취약한 부분이 있을 경우 빌드 단계가 실패하도록 코드 작성하였다.

(그림 3)과 같이 Terraform 코드에서 tfsec 단계 또는 trivy config를 선택하여 배포 전에 취약점 분석이 가능하다[10]. tfsec(Terraform Static Security Scanner)로 Terraform IaC 코드 내 보안 취약점, 잘못된 설정, 권장 사항 위반 등을 정적 분석하는 도구이다. tfsec, trivy config로 보안 점검을 하는 코드를 같이 넣을 경우 기능이 완전 같지는 않으므로 IaC 보안 점검을 병행해도 문제 없다[12]. 하지만 두 도구를 모두 실행하므로 점검 시간이 늘어날 수 있다. 이와 같이 코드에 해당 부분을 넣을 경우 보안 이슈 발견 시 Terraform 리소스가 배포되지 않고 워크플로우가 중단되게 된다.

(그림 3) Pre-deployment code vulnerability analysis

(그림 4)와 같이 Terraform 코드 작성 이후 Push를 했을 경우 이슈 발견 시 배포되지 않고 워크플로우가 중단되는 화면이다.

(그림 4) github action deployment failed

또한 (그림 5)와 같이 (그림 3)에서 작성했던 tfsec 단계에 의해 timings, counts, results와 같이 진단 결과를 확인할 수 있다. 현재 진단 결과를 확인하면, critical 4개, high 5개 등 17개의 보안/구성 문제를 tfsec이 발견한 걸 확인할 수 있다. 마지막 줄에 요약을 확인할 수 있는데 8개는 이상 없음, 17개는 잠재적 문제로 보고되며 Terraform 코드에서 여러 보안 취약점과 설정 문제를 찾아냄으로써 빌드가 수행되지 않고 워크플로우가 중단된 것을 확인할 수 있다. 이와 같이 빌드 전 코드에서도 보안에 취약하거나 잠재적 문제가 있을 경우에는 워크플로우가 중단되어 취약점을 조치해야만 빌드가 가능하며, 그 다음 단계를 진행할 수 있다. 코드 배포 전 취약점 분석을 통하여 보안 중점의 개발환경을 구성할 수 있을 것으로 보여 진다[13].

(그림 5) github action deployment failed

(그림 6)에서 tfsec가 감지한 보안 취약점에 대한 리스트와 상세 설명을 확인할 수 있다. 현재 CRITICAL 이슈로 Security Group 규칙이 모든 인터넷 대상으로 나가는 트래픽을 허용함으로써 보안상 위험하다는 부분을 확인할 수 있다. 해당 부분은 리소스를 불필요한 위험에 노출시킬 수 있다[14].

(그림 6) Security vulnerabilities detected by tfsec

5. 결론

오픈 소스 도구들을 사용함으로써 여러 가지 장점이 있지만 CI/CD 단계에서의 보안을 고려하여 오픈 소스 도구 취약점 발생 시 대응 방안을 마련해야 한다. 본 논문에서는 사전 대응으로 SCA를 추가하여 사전에 검증이 가능한 아키텍처를 제시하였으며, 사전 대응 방법 뿐만 아니라 사후 대응으로도 오픈 소스 취약점에 대한 검증이 필요하다. 사전 대응으로 SCA 도구와 SBOM을 통하여 CI 파이프라인에서 오픈 소스 취약점과 라이선스 위반을 미리 감지하고 차단한다. 또한 IaC 도구를 이용하여 인프라 환경을 구성할 경우 해당 환경이 구성되기 전에 인프라 환경 구성 코드를 사전에 취약점 진단이 필요하다. 그 후, 운영중인 서비스에서 취약점 발견 시 취약점 알림 수신, 자동 패치 제안과 같은 사후 대응이 필요할 것으로 판단된다.

향후 본 논문에서 SBOM과 제시한 아키텍처를 구성하여 개발 프로세스를 진행하면서 각 검증단계에서 실제 오픈 소스 취약점이 발생할 경우, 취약점 검증 방법 및 사후 대응 방안에 대해 재확인할 필요가 있다. 그리고, CI/CD 단계별 점검 방식에 대해 미비점을 확인 및 분석하여 추가로 보완할 예정이다.