CI/CD에서 AI 기반 DevSecOps로: 보안 보고서 분석을 위한 로컬 LLM 학습시키기

이전 article에서, 저는 Spring Boot 모놀리스(monolith)를 중심으로 한 완전한 CI 파이프라인을 구축했습니다: GitHub → Jenkins → SonarQube → Trivy → Nexus → Docker. 저는 품질 게이트(quality gates), 보안 스캐닝(security scanning), 그리고 아티팩트 관리(artifact management)를 도입했습니다.

하지만 그 과정의 끝에서, 저는 해답보다 더 많은 질문을 갖게 되었습니다. 가장 중요한 질문은 이것이었습니다 - Trivy가 보안 보고서(security report)를 생성하고 이를 Nexus 저장소에 업로드한 후에는 어떤 일이 벌어질까요? 사람들이 실제로 보고서 전체를 검토할까요?

이 글에서는 이전 프로젝트에서 이어가며 AI 기반의 DevSecOps 워크플로(workflow)를 구축할 것입니다:

• Jenkins가 Trivy 보안 보고서를 생성합니다.
• 보고서가 Nexus에 업로드됩니다.
• Jenkins가 n8n 웹훅(webhook)을 트리거합니다.
• n8n이 보고서를 다운로드합니다.
• 로컬 Ollama + phi3가 취약점(vulnerabilities)을 분석합니다 (연산 능력의 제한으로 인해 더 작은 LLM을 사용합니다).
• AI가 HIGH/CRITICAL 탐지 결과를 요약합니다.
• 이메일 알림이 자동으로 생성됩니다.

아키텍처(The Architecture):

흐름(The Flow):

• 애플리케이션 빌드
• SonarQube 분석
• 품질 게이트(Quality Gate) 검증
• Docker 빌드
• Trivy 보안 스캔
• Nexus에 보고서 업로드
• AI 워크플로 트리거
• 보고서 동적 다운로드
• 로컬 LLM에 탐지 결과 분석 요청
• AI가 생성한 권장 사항 전송

이 설정에서 AI 구성 요소는 제가 이전에 가졌던 "만약에(What if's)"라는 질문들에 답을 해줍니다. 설정을 살펴보기 전에, 왜 제가 AI 레이어를 추가했는지에 대한 정당성을 설명하고 싶습니다. 보안 담당자들에게 공정하게 말하자면, 보안 보고서(Security reports)는 길고 노이즈가 많을 수 있습니다. 수십 개의 CVE, 의존성 취약점(dependent vulnerabilities) 등이 포함될 수 있죠. 어떤 누락에 대해서도 그들에게 책임을 묻는 것은 불공평하게 느껴질 수 있습니다. 바로 이 지점에서 AI가 도움을 줄 수 있습니다. 마치 누군가에게 "이 보고서를 읽고 내가 10초 안에 걱정해야 할 상위 10가지를 알려줘"라고 말하는 것과 같습니다.

설정 미리보기:

1. Docker 이미지를 사용하여 ollama를 로컬(locally)에서 실행했습니다. 로컬에서 실행한 이유는 외부 API를 피하고 싶었기 때문이며, 또한 경제적인 이유(😂) 때문이기도 합니다.
2. 마찬가지로 Docker 이미지를 사용하여 n8n도 로컬에 설정했습니다. 이곳은 워크플로(workflows)를 사용하여 전체 프로세스를 오케스트레이션(orchestrate)하는 곳입니다.
   • Jenkins 작업이 n8n이 대기 중인 웹훅(webhook)을 호출합니다.
   • n8n은 다음과 같은 단계로 워크플로를 시작합니다: Trivy 보고서 가져오기 -> 다음 단계로 AI 프롬프트(prompt) 준비 -> Ollama로 전송 및 응답 변환 -> 이메일로 보고서 전송

n8n UI에서의 워크플로 모습은 다음과 같습니다:

취약점 보고서의 변환된 요약:

더 나은 개선 방향은 우리의 LLM을 주니어 SRE(Site Reliability Engineer)로 학습시키는 것입니다.