DevSecOps-hub

개요

DevSecOps Hub는 CI/CD 파이프라인에서 생성되는 정적 분석(SAST), 동적 분석(DAST), 오픈소스 취약점 분석(SCA) 결과를 중앙에서 수집하고 정규화하여 저장하고, 취약점의 우선순위화, 조치, 검증, 재발 방지, 감사 대응까지 수행하는 통합 보안 운영 플랫폼입니다.

여러개의 보안도구를 도입한 개발환경에서 보안 도구가 개별적으로 동작하여 결과가 분산되고, 취약점이 탐지 단계에서 멈추는 문제가 발생합니다. 이로 인해 우선순위 판단에 불일치가 발생하면, 조치가 지연되고 운영에 차질이 생기는 상황이 발생하게 됩니다.

DevSecOps Hub는 이러한 문제를 해결하기 위해 보안 스캔 결과를 하나의 데이터 모델로 통합하고, 취약점 라이프사이클 기반의 운영 체계를 도입합니다.

이를 통해 취약점은 발견 후,
분석 → 우선순위화 → 조치 → 검증 → 종료까지 일관된 흐름으로 관리됩니다.

또한 Policy Engine을 도입하여 서비스에서의 영향도를 반영한 우선순위화가 이루어지며, AI 분석 시스템을 통해 취약점 설명, 공격 시나리오, 수정 가이드를 자동으로 제공하여 개발자가 보다 빠르고 정확하게 보안 조치를 수행할 있도록 지원합니다.

데이터 저장 구조는 운영 데이터와 원본 데이터를 분리하여, RDS(MySQL)에는 메타데이터를 저장하고, S3에는 원본 리포트를 저장하는 방식으로 설계되었습니다. 이를 통해 성능, 확장성, 보안성을 동시에 확보합니다.

DevSecOps Hub는 취약점의 전 생애주기를 관리하고, 보안 활동을 개발 프로세스에 자연스럽게 통합하는 중앙 집중형 DevSecOps 운영 플랫폼을 지향합니다.

목차

• 개요
• 사용 방법
• 1. 문제 정의
• 2. 시스템 목표
• 3. 아키텍처 개요
• 4. 데이터 흐름
• 5. Policy Engine
• 6. 취약점 Lifecycle
• 7. 스토리지 및 인프라 구조
• 8. 인증 및 권한 관리
• 9. 감사 로그 설계
• 10. 보안 설계 원칙

사용 방법

1. 문제 정의

DevSecOps 환경에서 보안 도구를 도입하더라도, 운영 단계에서는 다음과 같은 구조적 문제가 발생하게 됩니다.

1.1 보안 결과의 분산

• CI 로그에만 존재하거나,
• HTML 또는 JSON 파일로 분리되어 저장되거나,
• 개별 실행 결과로만 존재하는 등 분산되어 존재합니다.

1.2 조치 책임 및 우선순위 부재

• 누가 어떤 취약점을 언제 수정해야 하는지 명확하지 않습니다.
• 심각도와 실제 우선순위가 일치하지 않습니다.
• 수정이 지연되거나 누락되는 경우 발생합니다.

1.3 운영 추적 불가능

• 상태 변경 이력이 기록되지 않습니다.
• 검증 및 종료 여부를 확인할 수 없습니다.
• 감사 대응 시 증빙 확보가 어렵습니다.

1.4 개발자 생산성 저하

• 도구별 결과 포맷이 상이합니다.
• 취약점 이해와 수정에 시간이 소요됩니다.
• 보안팀 의존도가 지나치게 높아질 수 있습니다.

2. 시스템 목표

DevSecOps Hub는 위 문제를 해결하기 위해 다음 전략을 활용합니다.

• 중앙 수집: 다양한 보안 도구의 결과를 일관된 데이터 모델로 정규화
• 운영 체계화: 취약점 Lifecycle 관리, 이력 관리 제공
• 개발자 지원: AI 기반 설명, 수정 가이드, 코드 예시 제공
• 감사 대응성 확보: 상태 변경, 사용자 행위, 저장 위치 정보를 제공하여 원본 추적성 확보

3. 아키텍처 개요

        [CI/CD 파이프라인]
(GitHub Actions + 보안 스캔 도구)
               ↓
        [데이터 수집 API]
     (FastAPI 수집 엔드포인트)
               ↓
      [데이터 파싱 & 정규화]
(Semgrep/ZAP/pip-audit 결과 통합)
               ↓
          [데이터 저장]
    (MySQL DB & AWS S3 원본 저장)
               ↓
      [보안 분석 및 감사 서비스]
   (AI 조치 가이드 생성 & 감사 로그)
               ↓
        [보안 통합 대시보드]
     (취약점 관리 및 실시간 통계)

4. 데이터 흐름

4.1 스캔 수집

• Shift-Left 보안 적용: 개발자가 코드를 Push하거나 Pull Request를 생성하는 시점에 CI/CD 파이프라인이 자동으로 실행됩니다.
• 보안 도구 통합 실행:
  • SAST: Semgrep
  • DAST: OWASP ZAP
  • SCA: pip-audit
• 자동화된 보안 검증 단계를 통해 개발 초기 단계에서 취약점을 조기에 탐지합니다.

4.2 데이터 수신

• 검사 결과 전송: 파이프라인 종료 시점에 생성된 JSON 결과를 DevSecOps Hub의 Ingestion API로 전송합니다.
• API 인증: 승인된 CI/CD 파이프라인만 결과를 전송할 수 있도록 프로젝트별 API Token 인증을 적용합니다.
• 클라우드 접근 인증 분리: AWS S3 업로드와 같은 클라우드 리소스 접근은 GitHub Actions의 OIDC 기반 IAM Role Assume 구조를 사용합니다.
• 실시간 처리: 수신된 결과는 즉시 정규화 파이프라인으로 전달되며, 필요 시 알림과 후속 조치 프로세스를 발송합니다.

4.3 정규화

• 데이터 정제:
  • 도구별 상이한 출력 포맷(JSON 구조)을 공통 스키마로 변환합니다.
• 중복 제거 및 그룹화:
  • 동일 취약점의 중복 발생을 제거하고, 이를 그룹화합니다.
• 정규화 목적:
  • 다양한 보안 도구를 단일 데이터 모델로 통합하여 운영 효율성을 확보합니다.

4.4 저장

• 메타데이터 저장 (MySQL):
  • 스캔 정보, 취약점 정보, 상태, 담당자, 이력 등을 저장합니다.
• 원본 리포트 저장 (AWS S3):
  • 스캔 결과 JSON 및 HTML 리포트를 그대로 보관합니다.
• 데이터 분리 전략:
  • DB에는 조회 중심 데이터만 저장하고, 대용량 원본 데이터는 Object Storage에 저장하여 성능을 최적화합니다.

4.5 분석 및 운영

• AI 기반 분석 수행:
  • 취약점 설명, 공격 시나리오, 영향 범위, 수정 가이드를 자동 생성합니다.
• 정책 기반 우선순위 적용:
  • Policy Engine을 통해 Priority 및 SLA가 자동으로 부여됩니다.
• 운영 상태 관리:
  • 취약점 상태 변경, 담당자 지정, 조치 진행 상황을 추적합니다.
• 알림 및 연동:
  • Slack, Jira, GitHub 등과 연동하여 조치 프로세스를 자동화합니다.

5. Policy Engine

Policy Engine은 서비스 맥락과 보안 위험도를 종합적으로 고려하여 우선순위와 대응 전략을 자동으로 결정하도록 합니다.

입력 요소

Policy Engine은 다음 정보를 기반으로 평가를 수행합니다.

• Severity

  • Critical / High / Medium / Low

• 서비스 중요도

  • 핵심 서비스 여부

• 노출 범위

  • Public (외부 노출)
  • Internal (내부 시스템)

• 취약점 특성

  • CWE (Common Weakness Enumeration)
  • CVE

• 발생 위치

  • 인증/인가 로직 여부
  • 관리자 기능 여부
  • 사용자 입력 처리 영역 여부

처리 로직

• 정적 규칙 기반 정책 평가
• 조건 조합을 통한 위험도 재산정
• 특정 조건에 대한 가중치 적용

출력

• Priority (P0 ~ P3)

  • P0: 즉시 대응
  • P1: 단기 대응
  • P2: 일반 대응
  • P3: 장기 대응

• SLA (조치 기한)

  • P0: 24시간 이내
  • P1: 3일 이내
  • P2: 7일 이내
  • P3: 30일 이내

• 알림 대상

  • 담당 개발팀
  • 보안팀
  • 운영팀

설계 목적

• 보안 판단을 자동화하여 일관된 운영 체계를 유지합니다.
• 취약점의 기술적 심각도와 실제 서비스에서 영향도의 차이를 보완합니다.
• 보안 대응 우선순위를 자동화하여 운영 부담 감소합니다.

6. 취약점 Lifecycle

DETECTED → TRIAGED → IN_PROGRESS → FIXED → VERIFIED → CLOSED

상태 정의

• DETECTED
  보안 스캔 도구를 통해 취약점이 최초로 탐지된 상태입니다.
  이 단계의 취약점은 아직 검토되지 않았으며, 단순히 탐지 결과로만 존재합니다.

• TRIAGED
  보안 담당자 또는 정책 엔진이 취약점의 유효성을 검토하고, 우선순위와 처리 방향을 정리한 상태입니다.
  이 단계에서는 False Positive 여부, 위험도 재평가 등이 함께 수행됩니다.

• IN_PROGRESS
  취약점이 실제 조치 대상으로 확정되어, 개발자 또는 담당자가 수정 작업을 진행 중인 상태입니다.

• FIXED
  코드 또는 설정 변경을 통해 취약점에 대한 수정이 완료된 상태입니다.
  단, 실제로 취약점이 제거되었는지는 아직 확인되지 않았습니다.

• VERIFIED
  수정된 결과에 대해 재스캔 또는 수동 검토를 수행하여, 취약점이 실제로 해소된 것을 확인한 상태입니다.

• CLOSED
  취약점이 최종적으로 종료된 상태입니다.
  조치와 검증이 모두 완료되었거나, 종료가 승인된 항목이 여기에 해당합니다.
  이 단계의 취약점은 더 이상 활성 조치 대상이 아니며, 이력 관리와 감사 추적 목적으로 보관됩니다.

설계 의도

이 Lifecycle은 탐지 이후의 검토, 수정, 검증, 종료까지 일관된 운영 흐름으로 관리하기 위해 설계되었습니다.

FIXED와 VERIFIED를 분리한 이유는, 개발자가 수정했다고 보고한 시점과 실제로 취약점이 해소된 시점을 명확히 구분하기 위함입니다.
이를 통해 조치 완료 취약점에 대한 검증을 통해 높은 신뢰도의 운영 체계를 유지할 수 있습니다.

7. 스토리지 및 인프라 구조

AWS 스토리지 구성

데이터의 사용 목적에 따라 저장소를 분리하는 구조를 사용합니다.

Amazon S3 (Object Storage)

• 스캔 원본 결과(JSON, HTML 리포트) 저장
• 취약점 분석에 사용된 원본 데이터 보존

Amazon RDS (MySQL)

• 메타데이터 및 운영 데이터 저장
• 취약점 상태, 사용자 정보, 이력 데이터 관리

저장소 분리 설계

사용 목적에 따라 운영 데이터와 원본 데이터를 분리하는 구조를 사용합니다.

구분	저장소	데이터 유형
메타데이터	RDS (MySQL)	취약점, 상태, 사용자, 이력
원본 데이터	S3	JSON 리포트, HTML 리포트

이 구조를 통해 다음과 같은 이점을 확보합니다.

S3 선택 이유

• 대용량 데이터 처리에 최적화
  보안 스캔 결과는 크기가 크고 구조가 다양하여, DB에 저장할 경우 성능 저하가 발생할 수 있습니다.

• 원본 데이터 무결성 보장
  분석 및 감사 과정에서 원본 데이터를 그대로 확인할 수 있으며, 데이터 변조 여부 검증이 가능합니다.

• 확장성
  스캔 데이터 증가에 따라 자동으로 확장 가능하며, 저장 용량에 대한 제약이 거의 없습니다.

• 비용 효율성
  Object Storage는 RDB 대비 비용 효율적인 구조를 제공합니다.

RDS 선택 이유

• 정형 데이터 관리
  취약점 상태, 사용자, 권한, 이력과 같은 관계형 데이터를 효율적으로 관리할 수 있습니다.

• 트랜잭션 보장
  상태 변경 및 운영 데이터의 일관성을 유지할 수 있습니다.

• 쿼리 기반 조회
  대시보드와 통계 기능 구현에 적합합니다.

S3 저장 구조

s3://devsecops-hub/{project}/{scan_id}/report.json

• project: 서비스 단위 식별자
• scan_id: 스캔 실행 단위 식별자

8. 인증 및 권한 관리

DevSecOps Hub는 역할 기반 접근 제어(RBAC)를 기반으로 사용자 권한을 관리합니다.

보안 운영 과정에서 발생할 수 있는 권한 오남용을 방지하고, 책임 기반의 작업 수행을 보장하기 위해 명확한 역할 구분을 적용합니다.

역할 정의

Admin

• 전체 시스템 관리 권한을 보유
• 사용자 생성 및 권한 설정 가능
• Policy Engine 정책 수정 및 관리
• 감사 로그 조회 및 시스템 설정 변경

Security Analyst

• 취약점 분석 및 상태 변경 수행
• 우선순위 조정 및 정책 기반 판단 수행
• False Positive 검증 및 리스크 평가 수행
• 보안 리포트 검토 및 관리

Developer

• 할당된 취약점 조회 및 대응
• 취약점 상태 변경 (IN_PROGRESS, FIXED)
• AI 분석 결과 확인 및 코드 수정 수행
• 개발 단계에서의 보안 조치 수행

Viewer

• 취약점 및 통계 데이터 조회만 가능
• 상태 변경 및 수정 권한 없음

권한 설계 기준

• 최소 권한 원칙: 각 역할은 반드시 필요한 기능만 수행할 수 있도록 제한됩니다.

• 책임 분리: 보안 판단과 코드 수정 역할을 분리하여 운영 리스크를 감소시킵니다.

• 프로젝트 단위 권한 관리: 특정 프로젝트에 대한 접근 권한을 제한할 수 있도록 설계됩니다.

인증 구조

• API 인증: CI/CD 파이프라인은 API Token 기반으로 인증됩니다.

• 사용자 인증: 사용자 인증은 OAuth 2.0 / OpenID Connect(OIDC) 기반 로그인 구조를 사용하며, 인증 완료 후에는 JWT를 세션 토큰으로 활용하여 사용자 상태를 관리합니다.

• 클라우드 접근 인증: GitHub Actions와 애플리케이션 런타임 모두 OIDC 기반 IAM Role Assume 방식을 통해 AWS 리소스에 접근합니다.

• 정적 키 금지 정책: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY와 같은 장기 Access Key는 사용하지 않습니다. 런타임은 AWS_AUTH_MODE=oidc_only, AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE 구성을 필수로 사용합니다.

환경 변수 설정사항 (Render & GitHub)

1) Render 환경변수

• DATABASE_URL=<RDS MySQL 연결 문자열>
• DEVSECOPS_PROJECT_NAME=devsecops-hub
• DEVSECOPS_PROJECT_TOKEN=<프로젝트 API 토큰>
• SESSION_SECRET=<세션 암호화 키>
• OPENAI_API_KEY=<OpenAI API Key>
• GITHUB_OAUTH_CLIENT_ID=<GitHub OAuth App Client ID>
• GITHUB_OAUTH_CLIENT_SECRET=<GitHub OAuth App Client Secret>
• GITHUB_OAUTH_REDIRECT_URI=<예: https://<render-service>/auth/github/callback>
• AUTH_ADMIN_USERS=<쉼표구분 GitHub username/email 목록>
• AUTH_SECURITY_USERS=<쉼표구분 GitHub username/email 목록>
• AUTH_VIEWER_USERS=<쉼표구분 GitHub username/email 목록>

2) GitHub Actions 환경변수(Secrets)

.github/workflows/security_scan_and_s3_upload.yml 기준으로 아래 GitHub Secrets가 필요합니다.

• AWS_REGION
• AWS_S3_REPORT_BUCKET
• AWS_GITHUB_ROLE_ARN (OIDC로 Assume 할 Role ARN)
• DEVSECOPS_HUB_URL
• DEVSECOPS_PROJECT_NAME
• DEVSECOPS_PROJECT_TOKEN

id-token: write 권한 + aws-actions/configure-aws-credentials를 통해 OIDC AssumeRole을 수행합니다.

9. 감사 로그 설계

모든 주요 행위를 Audit Log로 기록하여, 보안 운영의 추적성과 감사 대응 능력을 확보합니다.

기록 대상

• 취약점 상태 변경
• 사용자 권한 변경
• Policy 변경
• 로그인 및 인증 이벤트
• 데이터 조회 및 접근 이벤트

로그 구조

• 사용자 ID
• 행위 유형 (Action)
• 대상 리소스 (Resource)
• 변경 전 상태 (Before)
• 변경 후 상태 (After)
• Timestamp
• 요청 출처 (IP 또는 시스템 식별자)

로그 예시 (개념적 구조)

user: developer_01  
action: UPDATE_STATUS  
resource: vulnerability_123  
before: IN_PROGRESS  
after: FIXED  
timestamp: 2026-03-26T12:00:00Z  

저장 방식

• 로그는 변경 불가능한 형태로 저장됩니다.
• 일정 기간 동안 보관 후 아카이빙 정책을 적용할 수 있습니다.

10. 보안 설계 원칙

DevSecOps Hub는 실제 운영 환경에서의 보안성을 확보하기 위해
다음과 같은 보안 설계 원칙을 기반으로 구축되었습니다.

• 1. 최소 권한 원칙: 모든 사용자와 시스템은 필요한 최소 권한만 부여받습니다.

• 2. 인증과 권한의 분리: Authentication과 Authorization을 명확히 분리하여 설계합니다.

• 3. 데이터 추적 가능성: 모든 행위와 상태 변화는 추적 가능해야 합니다.

• 4. 원본 데이터 보존: 모든 보안 스캔 결과는 원본 형태로 보존됩니다.

• 5. 입력 검증 및 로깅: 외부 입력은 반드시 검증되며, 모든 주요 요청은 기록됩니다.

• 6. 민감정보 보호: 민감한 정보는 코드에 포함되지 않도록 설계합니다.