본 글은 보안 학습과 본인이 관리하는 시스템의 방어를 위한 교육 목적입니다. 타인의 시스템에 대한 무단 접근·공격은 불법이며 법적 처벌 대상입니다.

Trivy IaC 보안 전환: tfsec 마이그레이션과 운영비 분석

Trivy IaC 보안을 검토하는 팀이라면 대개 비슷한 시점이 옵니다. Terraform만 보던 흐름에서 Kubernetes manifest, Helm, 컨테이너 이미지, secret 노출까지 같이 챙겨야 하거든요. 저도 그 구간에서 tfsec 중심 운영을 오래 끌고 갔는데, 결국 Trivy로 표준화를 잡는 쪽이 더 편했습니다. 핵심은 단순히 도구를 하나 더 붙인 게 아니라, CI 실패 기준과 예외 관리, 결과 소비 방식까지 다시 설계했다는 점입니다.

이번 글은 Trivy IaC 보안을 단순 소개로 끝내지 않겠습니다. 실제 마이그레이션에서 어디서 시간이 새는지, 어떤 옵션이 운영비를 줄이는지, tfsec를 바로 걷어내면 왜 반발이 생기는지까지 실무 기준으로 정리해보겠습니다. 이미 tfsec를 쓰는 분이라면 더 중요하죠. 필요한 건 “Trivy도 됩니다”가 아니라, 언제 바꾸고 언제 병행할지 판단할 재료니까요.

결론부터 짧게 말하면 이렇습니다. Terraform만 안정적으로 검사하면 되는 단일 저장소라면 tfsec 병행 검증 후 천천히 넘어가도 됩니다. 반대로 IaC, secret, 파일시스템, 이미지 스캔을 한 CLI 체계로 묶고 싶다면 Trivy 쪽이 운영 밀도가 더 좋습니다. 라이선스 비용보다 사람 시간이 비싼 팀일수록 이 차이가 크게 느껴지더라고요.

Terraform, Kubernetes, CI 파이프라인, 결과 리포트가 한 흐름으로 연결된 IaC 보안 전환 개요 이미지입니다.

1. 왜 Trivy IaC 보안으로 옮기게 되었는가

tfsec은 Terraform 보안 검사 도구로 여전히 익숙하고 빠릅니다. 다만 팀 요구사항은 보통 Terraform에서 끝나지 않더라고요. 실제 운영에서는 “Terraform misconfiguration은 tfsec”, “secret은 다른 스캐너”, “이미지는 또 다른 스캐너”처럼 갈라지기 쉽습니다. 이 상태가 길어지면 보안 품질보다 도구 조합 관리가 일이 됩니다.

Trivy로 옮기며 가장 크게 본 장점도 기능 수 자체는 아니었습니다. 같은 CLI 습관으로 misconfiguration, secret, filesystem, image 스캔을 묶을 수 있다는 점이 컸습니다. 신규 팀원이 들어왔을 때도 “저 저장소는 이 도구, 저 저장소는 저 도구”가 아니라 “우리는 우선 Trivy를 기준으로 본다”고 설명하면 훨씬 빨랐습니다. 이거 진짜 온보딩에서 차이가 납니다.

• tfsec 유지가 맞는 경우: Terraform만 안정적으로 검사하고 있고, 다른 보안 영역은 이미 별도 체계가 자리 잡은 팀입니다.
• Trivy 전환이 맞는 경우: IaC 외에 secret, 파일시스템, 이미지, SBOM 흐름까지 한 도구권으로 정리하려는 팀입니다.
• 가장 흔한 착각: 오픈소스라서 비용이 거의 없다고 보는 것입니다. 실제 비용은 도구 수, 예외 재검토 시간, CI 노이즈, 신규 입사자 온보딩에서 나옵니다.

2. tfsec 마이그레이션의 본질은 명령어 치환이 아니라 정책 재설계입니다

Aqua Security는 tfsec을 계속 공개해 두고 있지만, 공식적으로는 스캔 역량을 Trivy로 통합하는 방향을 안내하고 있습니다. 그래서 마이그레이션을 어렵게 만드는 건 설치가 아니라 같은 문제를 어떤 기준으로 실패 처리할지, 그리고 예외를 어디에 어떤 기한으로 남길지입니다. 저는 tfsec에서 Trivy로 옮길 때 아래 네 항목부터 고정했습니다.

1. 현재 tfsec가 막고 있는 위험이 무엇인지 목록화
2. Trivy에서 동일하거나 더 나은 방식으로 재현 가능한지 확인
3. CI 실패 기준을 룰 이름보다 심각도와 자산 노출도 기준으로 재정의
4. 예외를 무기한 방치하지 않도록 만료일이 있는 방식으로 정리

여기서 중요한 건 tfsec 룰 이름과 Trivy 결과를 1:1로 맞추겠다는 집착을 버리는 겁니다. 운영 관점에서는 그게 핵심이 아니거든요. 실제로 중요한 건 두 가지였습니다. 이 PR이 위험한 변경을 추가했는가, 개발자가 왜 막혔는지 스스로 이해하고 수정할 수 있는가. 이 기준으로 보면 도구 이름보다 결과 전달 방식이 더 중요합니다.

또 하나, tfsec에서 오래 누적된 예외는 그대로 가져오지 않는 편이 좋습니다. 경험상 문제였던 예외는 두 종류였습니다. “급해서 일단 무시”한 것, 그리고 “당시에는 합리적이었지만 지금은 맥락이 사라진 것”입니다. 이걸 새 도구로 그대로 옮기면 전환 첫 주부터 신뢰가 흔들립니다.

3. Trivy IaC 보안 기본 구성: 로컬 재현부터 잡아야 덜 흔들립니다

CI부터 붙이면 로그만 길어지고 해석은 느려집니다. 저는 반드시 로컬에서 같은 결과가 나오는 최소 루틴부터 만듭니다. Trivy는 Terraform 디렉터리, Terraform plan 파일, plan JSON까지 공식 문서 기준으로 지원해서 시작점이 비교적 분명합니다.

3-1. Terraform 디렉터리 스캔: 가장 먼저 붙일 최소 명령

trivy config ./terraform

trivy config \
  --severity HIGH,CRITICAL \
  --exit-code 1 \
  --format table \
  ./terraform

첫 번째 줄은 탐색용이고, 두 번째 줄은 CI 차단용 기본형입니다. 실무에서 특히 중요한 옵션은 세 가지입니다.

• --severity HIGH,CRITICAL: 초기 도입 단계에서 잡음이 과도하게 늘어나는 걸 막아줍니다.
• --exit-code 1: 결과가 발견되면 빌드를 실패시켜 정책을 기술적으로 강제합니다.
• --format table: 사람이 바로 읽기 좋습니다. 개발자 피드백 단계에서는 아직도 꽤 유효합니다.

초기부터 MEDIUM까지 한꺼번에 막고 싶어질 수 있는데, 저는 대체로 말립니다. 첫 도입의 목적은 모든 문제를 한 번에 청소하는 게 아니라, 새로운 고위험 변경이 무심코 들어오는 걸 차단하는 것이기 때문입니다. 이 순서를 뒤집으면 도구가 바로 미움받습니다.

3-2. tfvars와 다운로드 모듈 처리: 실제 결과 품질을 좌우하는 옵션

trivy config \
  --tf-vars env/prod.tfvars \
  --tf-exclude-downloaded-modules \
  --severity HIGH,CRITICAL \
  --exit-code 1 \
  ./infra/env/prod

이 명령은 보기보다 중요합니다. --tf-vars를 주지 않으면 기본값 기준으로 해석돼 실제 배포 맥락과 다른 결과가 나올 수 있습니다. 반대로 다운로드된 모듈까지 전부 스캔하면, 현재 PR과 직접 관련 없는 외부 모듈 이슈가 섞여 리뷰 집중도가 떨어질 수 있습니다. 그래서 저는 애플리케이션 팀 저장소에서는 --tf-exclude-downloaded-modules를 먼저 켜고, 공통 플랫폼 팀 저장소에서는 별도 검증 잡으로 모듈까지 본다는 식으로 나눕니다.

이 지점이 운영비와 바로 연결됩니다. 도구가 무료여도 리뷰 시간이 비싸면 이미 손해입니다. 실제 위험과 직접 수정 가능성이 높은 결과부터 보여줘야 개발자도 반응합니다.

3-3. JSON 아티팩트 저장: 운영 자동화는 여기서 시작됩니다

mkdir -p artifacts
trivy config \
  --format json \
  --output artifacts/trivy-iac.json \
  ./terraform

jq '.Results[] | {target: .Target, misconfig_count: (.Misconfigurations | length)}' artifacts/trivy-iac.json

표 형식은 사람이 보기 좋고, JSON은 시스템이 다루기 좋습니다. 저도 Trivy로 넘어오면서 이 부분이 꽤 편해졌습니다. 같은 결과를 PR 코멘트, 대시보드, 주간 리포트에 재사용하기 쉬워지거든요. 인프라 코드 보안 자동화를 넓히려면 결국 여기까지 가게 됩니다.

개발자가 커밋하면 CI에서 Trivy가 IaC를 검사하고 결과 JSON과 요약 리포트를 남기는 흐름을 보여주는 이미지입니다.

4. tfsec에서 Trivy로 옮길 때 실제로 손보게 되는 지점

현업에서 삽질을 줄이려면 차이를 추상적으로 보면 안 됩니다. “둘 다 IaC 검사 도구” 수준으로는 의사결정이 안 나옵니다. 운영 포인트를 기준으로 봐야 합니다.

표에서 핵심은 기능 수가 아닙니다. 운영비가 어디서 줄고 어디서 새는지입니다. 저도 도구를 비교할 때 늘 “한 달 뒤 누가 덜 귀찮은가”를 봅니다. Trivy는 그 질문에 꽤 강한 편입니다.

4-1. GitHub Actions 예시: SARIF 업로드 단계까지 넣어야 보안 탭 연계가 됩니다

name: trivy-iac-scan

on:
  pull_request:
  push:
    branches:
      - main

jobs:
  scan:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Run Trivy config scan
        uses: aquasecurity/[email protected]
        with:
          scan-type: 'config'
          scan-ref: '.'
          hide-progress: true
          format: 'sarif'
          output: 'trivy-iac.sarif'
          severity: 'HIGH,CRITICAL'
          exit-code: '1'

      - name: Upload SARIF to GitHub code scanning
        if: always()
        uses: github/codeql-action/upload-sarif@v4
        with:
          sarif_file: trivy-iac.sarif
          category: trivy-iac

      - name: Upload artifact
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: trivy-iac-sarif
          path: trivy-iac.sarif

여기서 버전 고정을 강조하는 이유가 있습니다. 보안 도구 도입 시 액션 참조를 떠다니는 브랜치에 두면 운영 안정성이 떨어집니다. 스캔 결과 변화가 코드 변경 때문인지, 액션 변경 때문인지 구분이 어려워지거든요. 실무에서는 탐지 정확도만큼이나 결과의 재현성이 중요합니다.

하나 더 짚으면, SARIF 파일을 만드는 것만으로 GitHub 보안 탭에 자동 반영되지는 않습니다. github/codeql-action/upload-sarif 같은 업로드 단계가 있어야 코드 스캐닝 결과로 연결됩니다. 이 부분을 빼먹는 팀이 꽤 많았습니다.

4-2. trivy.yaml로 정책을 저장소에 고정해두면 운영이 덜 흔들립니다

format: json
exit-code: 1
severity:
  - HIGH
  - CRITICAL
scan:
  skip-dirs:
    - modules/legacy
misconfiguration:
  scanners:
    - terraform
terraform:
  vars:
    - env/prod.tfvars
  exclude-downloaded-modules: true

옵션이 CI 파일 곳곳에 흩어지면 유지보수가 피곤합니다. 반대로 정책 파일로 묶어두면 저장소 단위 코드 리뷰가 됩니다. 저는 이 방식을 선호합니다. 보안 정책이 파이프라인 구현 세부사항 속에 숨어 있으면, 변경 이력이 결국 사람 기억에만 남기 때문입니다.

4-3. 재현 가능한 시나리오 하나: 왜 막혔는지가 보여야 수정이 빨라집니다

AWS security group에 SSH를 0.0.0.0/0로 열어둔 Terraform 변경이 PR에 들어왔다고 가정해보겠습니다. 이런 건 교육용 환경, 임시 장애 대응, 외부 벤더 점검 같은 이유로 종종 등장합니다. 문제는 대부분 넣은 이유보다 그 상태가 운영에 남는 것입니다.

제가 해보니 개발자가 가장 빨리 반응하는 메시지는 단순한 “빌드 실패”가 아니었습니다. 어느 리소스가 왜 위험한지, 이 변경이 인터넷 노출인지 내부 한정인지를 같이 보여줄 때 반응 속도가 훨씬 빨랐습니다. 그래서 PR 자동화도 개수 집계만 하지 말고 Target, 리소스 위치, 심각도, 수정 우선순위를 함께 전달하는 쪽이 낫습니다.

안전한 설정과 위험한 설정을 나란히 보여주며, IaC 보안 검사에서 어떤 패턴을 주의해야 하는지 설명하는 이미지입니다.

5. Trivy IaC 보안에서 비용 효율은 라이선스가 아니라 운영 마찰에서 갈립니다

오픈소스 보안 비용을 설명할 때 “무료니까 이득”으로 끝내면 실제 예산 설명이 잘 안 됩니다. 보안 리더나 팀장이 궁금한 건 구매비보다 사람 시간을 얼마나 아끼거나 태우는가입니다. 저는 비용을 다섯 덩어리로 나눠 봅니다.

• 학습 비용: CLI 사용법, 결과 해석, 예외 작성 방식에 팀이 적응하는 시간
• 파이프라인 유지 비용: 액션 버전 고정, 캐시, 출력 포맷, 실패 기준 조정 비용
• 예외 관리 비용: 무시한 항목의 사유, 소유자, 만료 시점을 추적하는 비용
• 도구 중복 비용: Terraform, secret, image를 다른 도구로 운영하며 문서와 자동화가 흩어지는 비용
• 리뷰 비용: 결과는 많은데 실제 수정 우선순위가 안 보여 triage 시간이 불어나는 비용

여기서 Trivy 장점은 도구 수를 줄여 문맥 전환 비용을 낮춘다는 데 있습니다. 반면 한 CLI에 여러 스캔을 몰아넣기 시작하면 초기에 결과량이 급격히 많아져 시끄럽게 느껴질 수 있습니다. 그래서 저는 “통합은 하되 차단은 분리”를 권합니다. 명령 체계는 하나로 모으되, IaC misconfiguration 차단과 secret 경고, image 취약점 차단은 운영 단계를 다르게 두는 방식입니다.

6. 흔한 실패 모드와 근본 원인: 여기서 시간이 제일 많이 샙니다

문서만 보면 보안 스캔은 명령 한 줄처럼 보이지만, 실제 장애는 대부분 입력 경계와 해석 방식에서 납니다. 제가 자주 본 문제를 원인 중심으로 정리해보겠습니다.

6-1. 결과가 너무 많아져서 아무도 안 보는 문제

근본 원인은 도구 성능보다 정책 설계 실패인 경우가 많습니다. 처음부터 모든 심각도와 모든 스캐너를 한 번에 차단하면, 개발자는 보안 경고를 “수정해야 할 문제”가 아니라 “우회해야 할 소음”으로 인식합니다.

현실적인 해법은 이 순서가 좋았습니다.

1. 1단계: HIGH,CRITICAL만 차단
2. 2단계: MEDIUM은 JSON 또는 SARIF로 남기고 주간 triage
3. 3단계: 반복 발생 항목은 공통 모듈 수정 또는 코딩 가이드로 환류

차단 기준이 곧 팀의 메시지입니다. 이걸 너무 넓게 잡으면 보안 경고가 금방 배경 소음이 됩니다.

6-2. 로컬은 통과하는데 CI만 실패하는 문제

이건 보통 세 가지 원인으로 갈립니다. 첫째, 스캔 루트가 다릅니다. 둘째, tfvars가 다릅니다. 셋째, Terraform이 참조하는 파일 경계가 다릅니다. Trivy는 스캔 루트를 신뢰 경계로 보기 때문에, 하위 디렉터리만 스캔하면 상위 경로의 file() 참조가 깨질 수 있습니다.

# 저장소 루트에서 실행해 참조 파일 경계를 맞춥니다.
trivy config --skip-dirs envs/staging ./

# 배포 단위별로 동일한 규칙을 강제합니다.
for dir in infra/env/dev infra/env/prod; do
  echo "Scanning ${dir}"
  trivy config --tf-vars "${dir}/terraform.tfvars" --severity HIGH,CRITICAL --exit-code 1 "${dir}"
done

이럴 때 저는 “왜 CI만 다르지?”보다 “스캔 루트를 누가 정의하고 있지?”부터 봅니다. 대부분 거기서 답이 나옵니다.

6-3. downloaded module까지 스캔되어 현재 PR과 무관한 노이즈가 섞이는 문제

근본 원인은 책임 범위가 섞였기 때문입니다. 애플리케이션 팀 PR에서 외부 모듈 내부 구현까지 한 번에 막아버리면, 수정 권한이 없는 이슈 때문에 파이프라인이 실패할 수 있습니다.

이럴 땐 애플리케이션 저장소 차단 잡에서는 --tf-exclude-downloaded-modules를 사용하고, 공통 모듈 검증은 모듈 저장소 자체에서 별도 강제하는 편이 낫습니다. 문제를 만든 저장소에서 문제를 막는 구조가 운영비도 가장 낮습니다.

6-4. private module 때문에 CI에서 스캔이 깨지는 문제

문제는 스캐너보다 인증입니다. Terraform이 private module을 내려받아야 하는데 CI가 그 권한을 갖고 있지 않으면 결과가 비거나 오류가 섞입니다. 이 경우 스캔 실패를 보안 이슈로 오해하면 안 됩니다. 먼저 모듈 접근 경로부터 복구해야 합니다.

실무에서는 체크아웃 뒤에 필요한 Git 인증이나 Terraform registry 토큰을 명시적으로 설정하는 방식이 가장 덜 헷갈렸습니다. 포인트는 이걸 보안 도구 오작동으로 분류하지 않는 것입니다. 입력 데이터를 못 읽는 스캔은 검사 품질 이전의 문제입니다.

6-5. secret도 본다고 생각했는데 사실은 misconfiguration만 돌고 있는 문제

이건 생각보다 자주 나옵니다. trivy config는 IaC misconfiguration 검사에 초점을 둡니다. secret까지 같이 보려면 filesystem 스캔에서 스캐너를 명시적으로 지정하는 편이 더 명확합니다.

trivy fs \
  --scanners misconfig,secret \
  --severity HIGH,CRITICAL \
  --exit-code 1 \
  ./infra

제가 권하는 운영 방식은 이렇습니다. PR 차단은 우선 trivy config로 IaC misconfiguration에 집중하고, secret 검사는 별도 잡으로 분리하세요. remediation 주체와 사고 대응 절차가 달라서 분리하는 편이 실제 운영에서는 편합니다.

6-6. plan 파일과 HCL 결과가 달라 보이는 문제

Terraform plan을 스캔하면 배포 직전 상태를 본다는 장점이 있습니다. 다만 Trivy 공식 문서도 plan JSON에서 for_each나 count 표현식 관련 한계를 안내하고 있습니다. 그래서 저는 HCL 스캔과 plan 스캔을 경쟁 관계로 보지 않습니다.

• HCL 스캔: 작성 습관과 코드 리뷰 단계에서 빠르게 막기 좋습니다.
• plan 스캔: 실제 적용 직전 리소스 상태를 한 번 더 확인하기 좋습니다.

terraform plan --out tfplan
trivy config tfplan

terraform show -json tfplan > tfplan.json
trivy config tfplan.json

운영 경험상 PR 단계에서는 HCL, 배포 직전에는 plan을 추가하는 2단 구성이 가장 안정적이었습니다.

6-7. 예외가 무기한 방치되는 문제

예외는 필요합니다. 문제는 만료일 없는 예외가 제도화되는 순간입니다. Trivy는 인라인 ignore에 만료일을 붙일 수 있어서 이 부분이 실무에서 꽤 유용합니다.

#trivy:ignore:aws-s3-enable-logging:exp:2026-12-31
resource "aws_s3_bucket" "example" {
  bucket = "example-bucket"
}

이 방식이 좋은 이유는 간단합니다. 왜 무시했는지와 언제 다시 봐야 하는지가 코드 옆에 남기 때문입니다. 중앙 ignore 파일만 계속 키우면 몇 달 뒤엔 아무도 그 사유를 설명하지 못합니다.

7. 검증과 결과 확인: 전환 성공 여부는 탐지와 운영 부담을 같이 봐야 합니다

도구 전환이 끝났다고 말하려면 두 가지를 같이 확인해야 합니다. 위험한 변경을 실제로 잡는가, 그리고 팀이 그 결과를 소화할 수 있는가입니다. 저는 아래 순서로 검증합니다.

1. 의도적으로 위험한 Terraform 변경을 샘플 브랜치에 넣어 탐지되는지 확인
2. HIGH,CRITICAL 결과에서만 CI가 실패하는지 확인
3. JSON 또는 SARIF 아티팩트가 남아 후처리에 재사용되는지 확인
4. 개발자가 경고 메시지를 보고 수정 포인트를 바로 찾을 수 있는지 확인
5. 예외가 코드 옆 또는 정책 파일에 이유와 만료일을 남기는 구조인지 확인

마지막 항목이 빠지면 전환은 반쪽입니다. 단순 탐지는 누구나 붙일 수 있지만, 결과가 조직 안에서 오래 유지되는 방식까지 설계해야 운영 품질이 올라갑니다.

제가 Trivy 전환 뒤 가장 크게 느낀 변화는 “보안 도구가 늘어나는 속도”가 늦어졌다는 점이었습니다. 문서도 짧아지고, 신규 입사자 설명도 간단해지고, 파이프라인 장애를 볼 때 원인 축도 줄어듭니다. 무료 도구의 가성비는 결국 이런 데서 갈립니다. Kubernetes나 컨테이너 이미지 쪽까지 넓힐 계획이라면 관련 보안 글도 함께 읽어보시면 흐름을 잡는 데 도움이 됩니다.

심각도별 결과 요약, 실패 여부, 아티팩트 저장 상태를 한눈에 확인하는 검증 결과 이미지입니다.

8. 현업 추천 시나리오와 다음 단계

선택 기준은 명확할수록 좋습니다. 제가 현장에서 자주 권하는 방식은 아래와 같습니다.

• Terraform 위주 소규모 저장소: tfsec를 당장 걷어내기보다 같은 경로를 Trivy로 병행 스캔해 결과 차이부터 확인하세요.
• Terraform과 Kubernetes, 이미지 스캔까지 같이 보는 팀: Trivy를 중심축으로 묶는 편이 유지비가 낮습니다.
• CI 실패에 민감한 조직: 차단은 HIGH,CRITICAL부터 시작하고, 나머지는 리포트만 남기세요.
• 예외가 많은 조직: 전환 전에 예외 사유 정리부터 해야 합니다. 이걸 건너뛰면 새 도구가 아니라 새 혼란만 생깁니다.
• 공통 모듈을 별도 저장소로 관리하는 조직: 애플리케이션 저장소 차단과 모듈 저장소 차단을 분리하세요.

제 추천은 단순합니다. 도구 표준화가 목표면 Trivy, 변경 리스크를 최소화해야 하면 tfsec와 병행 검증 후 단계 전환입니다. secret, image, filesystem까지 한 CLI 체계로 묶고 싶다면 운영 일관성 쪽 가치가 생각보다 큽니다.

다음 단계도 분명합니다. 1) 로컬에서 trivy config 최소 명령을 고정하고, 2) 저장소별 차단 심각도를 정하고, 3) JSON 또는 SARIF 아티팩트 소비처를 정하고, 4) 예외에 만료일을 붙이세요. 여기까지 가야 전환이 끝납니다. 설치만 끝난 상태는 아직 운영이 아닙니다.

언제 tfsec 병행이 맞고, 언제 Trivy 중심 전환이 유리한지 빠르게 판단할 수 있도록 정리한 요약 이미지입니다.

9. 짧은 FAQ

Q. tfsec를 바로 버려도 될까요?

저는 바로 교체하기보다 병행 검증을 권합니다. 같은 저장소를 일정 기간 둘 다 돌려보면, 어떤 결과가 달라지는지와 예외가 어디서 충돌하는지가 먼저 보입니다.

Q. Trivy IaC 보안만으로 secret까지 같이 해결되나요?

IaC misconfiguration 관점에서는 trivy config가 출발점이 맞습니다. 다만 secret까지 같은 단계에서 다루려면 trivy fs --scanners misconfig,secret처럼 스캐너 구성을 의도적으로 나누는 편이 운영상 더 낫습니다.

Q. 오픈소스 보안 비용은 어떻게 설명해야 할까요?

라이선스보다 운영 마찰로 설명하는 편이 낫습니다. 도구 수, 예외 재검토 시간, 리뷰 잡음, CI 유지비, 신규 인원 교육비가 핵심입니다.

Q. Trivy IaC 보안은 누구에게 특히 맞나요?

Terraform만 보는 팀보다, Terraform과 Kubernetes, 파일시스템, secret, 이미지 스캔을 한 체계로 가져가려는 팀에 더 잘 맞습니다.

마지막으로 다시 적겠습니다. 본 글은 보안 학습과 본인이 관리하는 시스템의 방어를 위한 교육 목적입니다. 타인의 시스템에 대한 무단 접근·공격은 불법이며 법적 처벌 대상입니다.