Playbook Trivy + AI: biến kết quả quét thành backlog vá có ưu tiên
Dùng Trivy quét filesystem, container image và Kubernetes; sau đó dùng AI để gom phát hiện, nêu dữ kiện còn thiếu và soạn backlog xử lý. Quyết định ưu tiên, sửa và triển khai vẫn cần đội ngũ xác thực.
Một pipeline vừa xanh, image đã được đẩy đi, rồi kết quả scan trả về một danh sách dài CVE, dependency và cấu hình đáng ngờ. Câu hỏi khó không phải là “có lỗ hổng nào không?”, mà là: việc nào cần làm trước khi artefact này vào production?
Nếu mỗi lần quét đều sinh ra hàng loạt ticket rời rạc, DevOps, SRE và đội ứng dụng sẽ nhanh chóng quá tải cảnh báo. Cách làm thực tế hơn là dùng Trivy để thu thập tín hiệu, rồi dùng AI hỗ trợ gom nhóm phát hiện và soạn backlog khắc phục có ngữ cảnh. Quyết định cuối cùng vẫn thuộc về con người.
Từ phát hiện sang quyết định
Trivy là một security scanner có thể quét nhiều loại target:
Container image
Filesystem
Git repository từ xa
VM image
Kubernetes
Tùy target, Trivy có thể tìm các nhóm vấn đề như:
Package hệ điều hành, dependency phần mềm và thông tin SBOM
Lỗ hổng đã biết, chẳng hạn CVE
Lỗi cấu hình và vấn đề IaC
Thông tin nhạy cảm, secret
License phần mềm
Với CI/CD, điều này cho phép đặt nhiều điểm kiểm tra thay vì chỉ quét image ở cuối pipeline:
Quét filesystem tại repo checkout trước khi build để tìm vulnerability, secret và misconfiguration.
Quét container image sau khi build để kiểm tra artefact chuẩn bị phát hành.
Quét Kubernetes để có góc nhìn tổng quan ở cấp cluster.
Tổng hợp kết quả theo service, owner và môi trường để chuẩn bị backlog xử lý.
Trivy trả lời câu hỏi: “Target này có những tín hiệu bảo mật nào?” AI phù hợp với bước tiếp theo: “Những phát hiện nào có thể gom chung, còn thiếu dữ kiện gì và backlog nên được trình bày ra sao?”
AI không thay scanner. Scanner cũng không tự biết mức độ quan trọng của workload hay ưu tiên kinh doanh của hệ thống.
Thiết kế luồng quét: phát hiện sớm, tổng hợp có kiểm soát
Một playbook đơn giản có thể chia thành ba lớp.
1. Quét source và cấu hình trong pipeline
Khi pull request thay đổi mã ứng dụng, Dockerfile, manifest Kubernetes hoặc IaC, hãy quét filesystem tại thư mục checkout. README của Trivy minh họa ba scanner:
vuln
secret
misconfig
Lớp này hữu ích để phát hiện vấn đề trước khi build artefact.
2. Quét artefact sau build
Sau khi build, quét chính container image sẽ được phát hành. Đây là điểm phù hợp để liên kết kết quả với tag image, commit và service chịu trách nhiệm.
3. Xem tổng quan Kubernetes
Trivy hỗ trợ báo cáo tổng quan Kubernetes với --report summary. Hãy coi kết quả này là tín hiệu để điều tra hoặc tạo công việc khắc phục, không phải lý do để tự động sửa cluster.
README không quy định sẵn một pipeline hoàn chỉnh, ngưỡng fail build, định dạng dữ liệu đưa vào AI hay cách chấm điểm ưu tiên. Những phần này cần được đội ngũ chuẩn hóa, thử nghiệm và review trong môi trường của mình.
Các lệnh Trivy tối thiểu để bắt đầu
Trước khi đưa vào CI, hãy chạy thử trên máy phát triển hoặc runner thử nghiệm để hiểu loại tín hiệu Trivy trả về.
Cài đặt bằng Homebrew:
bash
brew install trivy
Hoặc chạy bằng Docker:
bash
docker run aquasec/trivy
Quét một container image:
bash
trivy image python:3.4-alpine
Quét thư mục dự án để kiểm tra vulnerability, secret và misconfiguration:
bash
trivy fs --scanners vuln,secret,misconfig myproject/
Xem báo cáo tổng quan Kubernetes:
bash
trivy k8s --report summary cluster
Hãy bắt đầu với một repo thử nghiệm. Chạy lệnh quét filesystem tại thư mục checkout, sau đó xem phát hiện được phân loại theo các scanner đã chọn.
Với production, tránh dùng bản canary. Theo README, canary build được tạo khi có thay đổi trên nhánh chính và có thể chứa lỗi nghiêm trọng.
Đưa AI vào đúng chỗ: gom nhóm, không “phán án”
Chỉ gửi cho AI phần kết quả đã được lọc. Không đưa secret, token, private key, kubeconfig, biến môi trường production hoặc log chứa dữ liệu khách hàng vào công cụ AI.
Mục tiêu không phải hỏi “CVE nào nguy hiểm nhất?” khi thiếu ngữ cảnh. Mục tiêu là yêu cầu AI cấu trúc hóa công việc để người vận hành review nhanh hơn.
Prompt mẫu:
text
Bạn là trợ lý DevSecOps. Hãy phân tích kết quả Trivy bên dưới để tạo backlog xử lý.
Bối cảnh:
Service/workload: <servicename>
Môi trường: <environment>
Image hoặc repo: <artifactreference>
Owner: <teamorowner>
Mức phơi nhiễm đã biết: <internetfacingorinternalorunknown>
Thay đổi gần đây: <changecontext>
Kết quả Trivy đã được loại bỏ secret:
<trivyfindings>
Yêu cầu:
Gom các phát hiện theo nguyên nhân chung, package/dependency hoặc workload.
Tách rõ: vulnerability, misconfiguration, secret và license nếu có.
Với từng nhóm, nêu giả định và thông tin còn thiếu để đánh giá phơi nhiễm.
Đề xuất backlog theo thứ tự: xử lý ngay, lên kế hoạch, cần xác minh.
Mỗi mục backlog gồm: phạm vi ảnh hưởng, hành động đề xuất, owner gợi ý và kiểm tra sau khi sửa.
Không tự khẳng định một phát hiện có thể khai thác nếu dữ liệu không chứng minh điều đó.
Không đưa secret, token, khóa hoặc nội dung nhạy cảm vào câu trả lời.
Trường mức phơi nhiễm đặc biệt quan trọng. Một dependency có CVE trong workload nội bộ không nhất thiết có cùng mức khẩn với phát hiện tương tự ở workload public-facing. Ngữ cảnh này cần do đội ngũ cung cấp và xác thực.
Ví dụ: từ kết quả quét đến backlog
Giả sử đầu vào đã được biên tập như sau:
text
Service: <checkoutservice>
Environment: <production>
Exposure: <internetfacing>
Trivy findings:
Vulnerability in <packagea>: <cveid>
Vulnerability in <packagea>: <cveid>
Misconfiguration in <kubernetesmanifest>
Secret finding in <repositorypath>
Một đầu ra AI hữu ích không chỉ lặp lại bốn dòng trên. Nó nên tổ chức công việc gần với backlog:
Xử lý ngay: xác minh secret finding; nếu là secret thật, thực hiện quy trình nội bộ để thu hồi hoặc xoay vòng thông tin liên quan, loại bỏ khỏi repo và đánh giá phạm vi ảnh hưởng.
Cần xác minh trước khi vá: gom hai CVE của <packagea> thành một hạng mục dependency hoặc image base; xác định package có được workload sử dụng ở runtime hay không và lựa chọn bản cập nhật phù hợp.
Lên kế hoạch khắc phục: giao owner xem lại misconfiguration tại <kubernetesmanifest>, đối chiếu với policy cluster và cách manifest được triển khai.
Kiểm tra sau sửa: chạy lại cùng lệnh Trivy, review pull request và xác minh deploy theo quy trình rollout của team.
Giá trị của AI ở đây là giảm công việc đọc, nhóm, viết ticket và chỉ ra thông tin còn thiếu. AI không nên được trao quyền tự merge hoặc tự sửa manifest.
Kiểm tra đề xuất trước khi áp dụng
AI có thể hiểu sai package, đường đi runtime hoặc đề xuất thay đổi gây lỗi tương thích. Trước khi merge hay áp dụng cấu hình do AI gợi ý:
Đối chiếu từng nhóm phát hiện với output Trivy gốc.
Review Dockerfile, lockfile, manifest Kubernetes và IaC trong pull request.
Chạy linter, test ứng dụng và các scanner hiện có của team.
Dùng plan hoặc dry-run của công cụ triển khai trước khi áp dụng thay đổi hạ tầng.
Quét lại filesystem hoặc image bằng Trivy sau khi sửa.
Với Kubernetes, theo dõi rollout, logs, metrics và alert sau triển khai.
Thay secret bằng placeholder như <redactedsecret> trước khi gửi dữ liệu sang AI.
Checklist vận hành
[ ] Quét filesystem tại repo checkout khi có thay đổi liên quan.
[ ] Quét container image trước khi phát hành.
[ ] Dùng quét Kubernetes để có tín hiệu ở cấp cluster.
[ ] Lọc secret và dữ liệu nhạy cảm trước khi gửi kết quả cho AI.
[ ] Yêu cầu AI gom nhóm theo service, owner và mức phơi nhiễm.
[ ] Review, test, dry-run và quét lại trước khi đóng backlog.
[ ] Không dùng canary build cho production.
Danh sách CVE sẽ không tự ngắn đi. Nhưng khi Trivy cung cấp tín hiệu nhất quán và AI hỗ trợ biến tín hiệu thành backlog có ngữ cảnh, đội DevOps có thể bớt thời gian phân loại cảnh báo để tập trung giảm rủi ro thực tế.