엔터프라이즈 AI 에이전트를 위한 복원력 있는 DevSecOps 파이프라인 설계

AI 요약

자율형 AI 에이전트는 외부 API를 동적으로 호출하고 코드를 생성하며 데이터베이스 상태까지 변경할 수 있으므로, 전통적인 마이크로서비스와 동일한 CI/CD 보안 모델만으로는 충분하지 않다고 설명합니다. 전통적인 서비스가 비교적 예측 가능한 결정적 코드 경로를 따른다면, 에이전트 애플리케이션은 일반적인 백엔드 코드에 더해 비결정적인 prompt template, 동적으로 호출되는 function-calling schema, 빠르게 바뀌는 서드파티 SDK를 함께 사용합니다. 이 때문에 소스 코드와 의존성뿐 아니라 프롬프트와 도구 실행 정의까지 소프트웨어 공급망의 일부로 다뤄야 합니다.

■ 에이전트 애플리케이션의 주요 공격 표면

글은 먼저 기존의 강화되지 않은 CI/CD 워크플로에서 발생할 수 있는 위험을 네 가지로 나눕니다. 개발자가 빠르게 반복 작업을 하면서 테스트용 API key, cloud provider service account, Model Context Protocol(MCP) 인증 토큰을 저장소에 커밋할 수 있습니다. 저장소에 포함된 자연어 system prompt는 적대적인 jailbreak나 prompt injection에 대한 검증이 부족할 수 있으며, OWASP LLM01 Prompt Injection에 해당하는 방식으로 에이전트의 실행 흐름이 조작될 수 있습니다. LangChain, LlamaIndex, AutoGen 같은 프레임워크는 깊은 transitive dependency tree에 의존하므로 검증되지 않은 패키지가 공급망 취약점을 가져올 가능성도 있습니다. 또한 SAST 결과가 늦게 나오면 팀이 출시 속도를 위해 보안 게이트를 우회하게 되고, 해결되지 않은 CWE가 staging과 production으로 전달될 수 있습니다.

■ 참조 시나리오: Core Banking Payment Orchestrator Agent

이 위험을 구체화하기 위해 Core Banking Payment Orchestrator Agent를 예시로 듭니다. 이 에이전트는 비동기 거래 분쟁을 처리하고, MCP tool을 통해 핵심 SAP ledger를 조회하며, 잔액 조정을 실행합니다. 금융 거래 endpoint와 민감한 고객 PII에 직접 접근하므로 HTTP client library의 공개 CVE, custom tool definition의 escape되지 않은 SQL parameter, 노출된 API token, 분쟁 데이터 파싱 과정의 prompt injection vector가 금융·규제상 중대한 결과로 이어질 수 있다고 설명합니다. 따라서 이 서비스를 변경하는 모든 pull request는 병합 전에 자동화된 4단계 파이프라인을 통과해야 합니다.

■ 1단계: Secret Scanning

첫 단계는 코드가 build되거나 package되기 전에 실행됩니다. GitHub Actions가 pull request를 감지하면 Gitleaks와 TruffleHog 같은 고속 secret detection engine을 호출하고, 예시 workflow에서는 전체 커밋 이력을 가져오기 위해 actions/checkout@v4에 fetch-depth: 0을 지정한 뒤 gitleaks/gitleaks-action@v2를 실행합니다. 검사는 git diff뿐 아니라 commit history, commit message, configuration file의 문자열을 살펴보며, entropy가 높은 문자열과 cloud token, Anthropic·OpenAI·Google Gemini foundation model API key, 내부 private key의 패턴을 확인합니다. 해시되지 않은 credential이나 secret token이 발견되면 non-zero exit code로 즉시 workflow를 실패시키고, 이후 단계로 진행하지 않습니다. 이 방식은 ephemeral runner의 build log나 container layer에 credential이 남는 것을 막는 것을 목표로 합니다.

■ 2단계: AI 코드 리뷰와 프롬프트 보안 검사

Secret Scanning이 성공하면 AI 기반의 두 가지 검증이 진행됩니다. Autonomous AI Code Reviewer는 권한을 줄인 read-only GitHub token으로 pull request diff를 분석하고, anti-pattern, 입력값 정제 누락, concurrency race condition, 아키텍처 규칙 위반을 검토합니다. 예시 구성에서는 pull_request 이벤트일 때 coderabbitai/ai-pr-reviewer@v1을 실행하며 GITHUB_TOKEN과 OPENAI_API_KEY를 환경 변수로 전달합니다.

동시에 prompt template과 agent instruction file을 일반 텍스트로 취급하지 않고 보안 테스트 대상으로 지정합니다. .txt, .yaml, .json 파일을 대상으로 prompt injection과 jailbreak 패턴을 검사하고, 사용자 입력으로 전달되는 template variable이 system instruction을 쉽게 덮어쓰지 못하는지 확인합니다. 또한 tool execution description이 least privilege를 강제하는지 검증합니다. workflow는 Python 3.11 환경에서 promptfoo와 giskard를 설치하고, promptfoo eval --config tests/promptfoo-security.yaml --no-telemetry 명령으로 OWASP LLM01 관련 검사를 실행하는 형태입니다.

■ 3단계: Veracode Agent-Based SCA

세 번째 단계는 외부 package ecosystem의 위험을 통제합니다. GitHub Actions runner 안에서 경량 Veracode CLI agent를 ephemeral하게 초기화하고, 소스 코드를 별도로 업로드하는 대신 package manager manifest와 runner에 설치된 library를 직접 검사합니다. 대상 예시로 package-lock.json, poetry.lock, pom.xml, requirements.txt를 제시합니다. Agent는 direct dependency와 transitive dependency를 포함한 Software Bill of Materials(SBOM)를 구성하고, 이를 Veracode의 vulnerability database와 대조합니다. 이 과정에서 취약한 open-source component뿐 아니라 licensing risk와 유지보수되지 않는 package도 식별하며, enterprise vulnerability policy에 따라 high-severity Common Vulnerabilities and Exposures(CVE)를 탐지하고 remediation pull request 지침을 생성합니다. 예시 명령은 SRCCLR_API_TOKEN을 사용해 sourceclear의 CI script를 실행하고 --update-advisor와 --allow-dirty 옵션을 전달합니다.

■ 4단계: Veracode Pipeline SAST

네 번째 단계는 first-party code의 결함을 확인합니다. 전체 개발 주기가 끝날 때 수행하는 무거운 정적 분석 대신 CI/CD용 Veracode Pipeline Scan을 사용하며, 원문은 대부분의 코드베이스에서 90초 이내에 완료된다고 설명합니다. workflow는 테스트와 GitHub 설정 디렉터리를 제외한 deployment-package.zip을 만들고, Pipeline Scan CLI를 내려받아 Veracode API ID와 API key로 분석합니다. SQL Injection(CWE-89), OS Command Injection(CWE-78) 같은 결함을 포함해 CVSS 7.0 이상으로 분류되는 문제는 pipeline status check를 실패시키고 병합을 차단합니다. 결과는 results.json으로 저장한 뒤 SARIF(Static Analysis Results Interchange Format)로 변환하며, GitHub Code Scanning Alerts에 업로드해 저장소의 Security 탭에서 확인할 수 있도록 합니다. 예시 workflow는 Very High와 High severity에서 실패하도록 --fail_on_severity를 지정하고, 결과 변환과 SARIF 업로드 단계에는 if: always()를 사용합니다.

■ GitHub Actions에서의 실행 구조와 정책

워크플로의 권한은 contents: read, pull-requests: write, security-events: write로 제한합니다. secret-scan이 선행되어야 한다는 점은 모든 후속 검증의 공통 전제입니다. Stage 2의 AI 리뷰·프롬프트 검사, Stage 3의 SCA, Stage 4의 SAST는 각각 secret-scan을 needs로 지정하므로, 비밀 검사가 끝난 뒤 서로 독립적으로 실행되는 구조입니다. 즉 모든 보안 검사를 하나의 긴 순차 작업으로 묶기보다 빠른 PR 게이트를 여러 작업으로 나눠 피드백 시간을 줄이는 방식입니다.

마지막으로 글은 prompt와 schema에 application source code와 같은 자동 회귀 테스트 및 보안 테스트를 적용하고, 빠른 PR 게이트와 무거운 비동기 검사를 분리하라고 제안합니다. PR 검증 루프에서는 3분 이내의 가벼운 SAST와 SCA를 적용하고, 종합적인 동적 분석과 정기 compliance audit은 post-merge 비동기 작업으로 남기는 방식입니다. 또한 처리되지 않은 high-severity CVE나 정적 분석 결함이 있는 pull request는 병합하지 않도록 policy-as-code 품질 게이트를 설정하며, 예외가 필요하다면 암호학적으로 서명된 승인과 저장소 audit log 등록을 요구해야 한다고 설명합니다. 핵심은 runtime guardrail과 proxy만으로 문제를 해결하려 하지 않고, secret·prompt·dependency·first-party code를 production 배포 전에 각각 검증하는 것입니다.

원문: dev.to / 번역·요약: Trawling