DevSecOps

DevSecOps là cách đưa các hoạt động bảo mật vào cùng quy trình phát triển và vận hành phần mềm thay vì tách security thành một bước kiểm tra ở cuối.

Có thể hiểu ngắn gọn:

Dev + Security + Ops.

Nhưng ghép ba chữ lại chưa đủ để tạo ra DevSecOps.

DevSecOps là cách tổ chức con người quy trình và công cụ để security trở thành một phần bình thường của việc phát triển phần mềm.

Developer không viết code xong rồi ném sang đội Security để “kiểm tra giúp”.

Security cần xuất hiện sớm hơn.

Ngay từ requirement.

Ngay từ architecture.

Ngay từ Pull Request.

Và tiếp tục sau khi phần mềm đã lên production.

Đây là điểm cốt lõi.

DevSecOps không có nghĩa mọi developer phải trở thành chuyên gia cybersecurity.

Developer cần hiểu những rủi ro liên quan đến phần mình xây dựng.

Security team cung cấp framework hướng dẫn tooling và hỗ trợ những vấn đề chuyên sâu hơn.

Operations và Platform team bảo vệ hạ tầng pipeline secret và môi trường triển khai.

Mỗi bên có trách nhiệm riêng.

Security không còn là trách nhiệm của một nhóm đứng ngoài quy trình.

Một DevSecOps workflow thường bắt đầu từ Security Requirements.

Khi một feature được thiết kế đội phát triển nên biết dữ liệu nào nhạy cảm ai được truy cập và những hành động nào cần kiểm soát.

Ví dụ một API cho phép thay đổi thông tin thanh toán không chỉ cần requirement về chức năng.

Nó còn cần requirement về authentication authorization audit logging validation và protection của dữ liệu.

Nếu những yêu cầu này chỉ được phát hiện ở cuối sprint chi phí sửa thường cao hơn.

Threat Modeling cũng là một phần phù hợp với DevSecOps.

Đội phát triển có thể xem xét data flow trust boundary tài sản quan trọng và những đường tấn công khả dĩ trước khi code.

Mục tiêu không phải dự đoán mọi cuộc tấn công.

Mục tiêu là tìm ra những rủi ro rõ ràng đủ sớm để thiết kế phòng vệ hợp lý.

Sau đó đến Secure Coding.

Developer cần tránh những pattern dễ tạo lỗ hổng như SQL Injection hard-coded secret authorization sai hoặc xử lý input không an toàn.

Framework và library an toàn nên được ưu tiên thay vì tự xây lại các cơ chế bảo mật quan trọng.

Nhưng DevSecOps không dừng ở code.

Pull Request là một điểm kiểm soát rất tự nhiên.

Khi code thay đổi hệ thống có thể chạy nhiều kiểm tra tự động trước khi merge.

Ví dụ lint unit test dependency scan secret scan SAST và những security rule khác.

Điều này giúp phát hiện lỗi sớm.

Developer nhận feedback ngay trong workflow quen thuộc thay vì vài tuần sau mới nhận một file Excel chứa danh sách vulnerability.

SAST hay Static Application Security Testing có thể phân tích code để tìm một số pattern có khả năng gây lỗ hổng.

SAST phù hợp để tích hợp sớm trong quá trình phát triển hoặc CI.

Nhưng SAST không hiểu toàn bộ hành vi ứng dụng.

Nó có thể tạo false positive và cũng có thể bỏ sót vấn đề.

Do đó finding cần được xem xét trong context.

DAST kiểm tra ứng dụng khi đang chạy.

Nó có thể tìm những vấn đề mà static analysis khó phát hiện.

Nhưng DAST cũng không thay thế toàn bộ security testing.

Không tồn tại một scanner duy nhất có thể kiểm tra mọi thứ.

SCA hay Software Composition Analysis tập trung vào dependency và các thành phần bên thứ ba.

Ứng dụng hiện đại thường sử dụng hàng trăm hoặc hàng nghìn package.

Lỗ hổng không nhất thiết nằm trong code do đội phát triển tự viết.

Nó có thể nằm trong thư viện mà ứng dụng phụ thuộc vào.

DevSecOps vì vậy cần theo dõi dependency xuyên suốt vòng đời sản phẩm.

Secret Scanning cũng rất quan trọng.

API key password private key token hoặc credential không nên xuất hiện trong repository.

Pipeline có thể tự động phát hiện một số loại secret trước khi code được merge.

Nhưng secret scanning chỉ là lớp phòng vệ.

Secret nên được quản lý bằng cơ chế phù hợp thay vì hard-code ngay từ đầu.

CI/CD pipeline bản thân nó cũng là một tài sản cần bảo vệ.

Pipeline có thể có quyền build package deploy lên server hoặc truy cập secret.

Nếu pipeline bị kiểm soát attacker có thể thay đổi artifact ngay cả khi source code ban đầu hoàn toàn sạch.

Đây là lý do DevSecOps phải quan tâm đến security của chính hệ thống delivery.

Runner agent service account token và deployment credential nên tuân theo nguyên tắc least privilege.

Mỗi thành phần chỉ nên có quyền cần thiết cho nhiệm vụ của nó.

Không nên cấp quyền administrator cho mọi pipeline chỉ để cấu hình dễ hơn.

Artifact integrity cũng cần được quan tâm.

Đội phát triển cần biết artifact nào được build từ source nào pipeline nào và có bị thay đổi sau build hay không.

Hash signature provenance và những cơ chế xác minh khác có thể giúp tăng khả năng truy vết.

Điều này liên quan trực tiếp đến Software Supply Chain Security.

DevSecOps ngày nay không thể chỉ nhìn source code.

Cần quan tâm cả package manager registry CI runner container image build script artifact repository và môi trường deployment.

Một dependency bị chiếm quyền có thể ảnh hưởng đến hàng nghìn ứng dụng downstream.

SBOM hay Software Bill of Materials có thể giúp liệt kê những thành phần phần mềm đang được sử dụng.

Nó hỗ trợ việc xác định hệ thống nào bị ảnh hưởng khi một dependency có vulnerability mới.

Nhưng tạo SBOM thôi chưa đủ.

Nếu không có quy trình sử dụng thông tin đó thì SBOM chỉ trở thành một file nữa trong repository.

DevSecOps cần cả feedback loop.

Khi một security issue được phát hiện đội phát triển cần biết issue đến từ đâu vì sao xảy ra và cách ngăn nó quay lại.

Nếu một lỗi giống nhau xuất hiện nhiều lần có thể cần bổ sung coding rule test scanner hoặc training phù hợp.

Đây là điểm khác giữa sửa vulnerability và cải thiện hệ thống phát triển.

Security Gate có thể được đưa vào pipeline.

Ví dụ build không được deploy nếu tồn tại vulnerability có mức độ nghiêm trọng vượt quá ngưỡng đã định.

Nhưng quality gate cần được thiết kế hợp lý.

Nếu gate quá nghiêm và liên tục chặn deployment vì false positive đội phát triển sẽ tìm cách bypass.

Nếu gate quá lỏng thì nó mất ý nghĩa.

Risk-based policy thường thực tế hơn việc chặn mọi finding như nhau.

Một vulnerability critical trên Internet-facing authentication service và một finding low trong tool nội bộ không nên có cùng cách xử lý.

Risk nên quyết định mức ưu tiên.

DevSecOps cũng gắn với khái niệm Shift Left.

Shift Left nghĩa là đưa những hoạt động kiểm tra và phòng ngừa security về sớm hơn trong SDLC.

Requirement review threat modeling secure coding static analysis và dependency checking đều có thể diễn ra trước production.

Nhưng chỉ shift left là chưa đủ.

Security vẫn cần tiếp tục khi hệ thống đang chạy.

Đây thường được gọi là Shift Right.

Production monitoring runtime protection vulnerability detection log analysis và incident response vẫn rất cần thiết.

Phần mềm an toàn hôm nay không có nghĩa sáu tháng sau vẫn an toàn.

Dependency có thể xuất hiện vulnerability mới.

Credential có thể bị lộ.

Configuration có thể bị thay đổi.

Attack technique cũng thay đổi.

DevSecOps vì vậy là một vòng đời liên tục.

Infrastructure as Code cũng nằm trong phạm vi này.

Cloud infrastructure hiện thường được mô tả bằng Terraform YAML template hoặc những hình thức cấu hình bằng code khác.

Điều đó cho phép security rule được kiểm tra trước khi infrastructure được triển khai.

Ví dụ pipeline có thể phát hiện storage bucket public database mở Internet hoặc security group quá rộng.

Nhưng IaC cũng tạo ra rủi ro mới.

Một cấu hình sai có thể được nhân bản nhanh sang rất nhiều môi trường.

Tự động hóa làm đúng rất nhanh.

Nó cũng làm sai rất nhanh.

Container Security cũng thường xuất hiện trong DevSecOps.

Container image cần được kiểm tra dependency configuration user privilege base image và secret.

Không nên chỉ scan image một lần khi build.

Image cũ vẫn có thể xuất hiện vulnerability mới sau đó.

Registry và deployment environment cũng cần được quản lý.

Kubernetes Security nếu hệ thống sử dụng Kubernetes lại có thêm những vấn đề riêng như RBAC network policy secret container privilege và workload configuration.

Nhưng không nên sử dụng Kubernetes chỉ vì đang làm DevSecOps.

DevSecOps là phương pháp.

Nó không phụ thuộc vào một stack công nghệ cụ thể.

Observability cũng hỗ trợ security.

Log metric trace và audit event có thể giúp phát hiện hành vi bất thường.

Ví dụ số lần đăng nhập thất bại tăng đột biến hoặc một tài khoản truy cập hàng nghìn record trong thời gian ngắn.

Monitoring như vậy giúp security tiếp tục sau deployment.

Tuy nhiên log cần được thiết kế cẩn thận.

Nếu log toàn bộ request rồi vô tình lưu password hoặc access token thì chính hệ thống observability lại tạo ra rủi ro.

AI Code Review cũng có thể tham gia DevSecOps.

AI có thể kiểm tra diff tìm pattern đáng ngờ hoặc phân tích những thay đổi security-sensitive.

Nhưng AI không phải security gate đáng tin duy nhất.

AI có thể hallucinate.

Nó có thể bỏ sót vulnerability.

Nó cũng có thể tạo cảnh báo sai.

AI nên bổ sung cho automated tooling và human security review.

Khi AI Coding Agent bắt đầu tự tạo và sửa code DevSecOps càng quan trọng.

Agent có thể tạo thay đổi nhanh hơn rất nhiều so với developer viết thủ công.

Nhưng tốc độ code tăng cũng làm tăng nhu cầu kiểm soát đầu ra.

Agent nên hoạt động trong permission rõ ràng.

Không nên tự động có quyền deploy production hoặc truy cập secret chỉ vì nó cần chạy test.

Workflow agent có thể đi theo chuỗi:

Task Specification → Coding Agent → Tests → SAST → SCA → Secret Scan → AI Code Review → Human Review → CI Security Gate → Deployment.

Không phải task nào cũng cần tất cả các bước.

Điều quan trọng là risk quyết định mức kiểm soát.

DevSecOps cũng không nên biến thành việc thêm hàng chục tool vào pipeline.

Nhiều tool không đồng nghĩa security tốt.

Nếu mỗi tool tạo hàng nghìn cảnh báo và không ai xử lý thì hệ thống chỉ tạo thêm noise.

Một DevSecOps workflow tốt cần ưu tiên signal.

Finding phải có owner.

Có mức độ ưu tiên.

Có SLA xử lý.

Và có cách xác nhận issue đã được khắc phục.

Metrics cũng nên được chọn cẩn thận.

Đếm số vulnerability tìm được không nhất thiết phản ánh security tốt hay xấu.

Một đội tìm thấy nhiều issue có thể chỉ đơn giản là họ kiểm tra tốt hơn.

Các metric hữu ích hơn có thể bao gồm thời gian phát hiện thời gian xử lý tỷ lệ vulnerability lặp lại tỷ lệ dependency được cập nhật hoặc coverage của security controls.

DevSecOps còn liên quan đến văn hóa đội ngũ.

Nếu Security chỉ xuất hiện để nói “không được” Developer sẽ tìm cách né Security.

Nếu Developer xem security là chuyện của đội khác vulnerability sẽ tiếp tục xuất hiện.

Mô hình hiệu quả hơn là security trở thành một enabler.

Security team tạo guardrail template library guideline và tooling để developer có thể làm đúng dễ hơn.

Ví dụ thay vì chỉ viết tài liệu yêu cầu mọi service phải authentication đúng chuẩn đội platform có thể cung cấp middleware hoặc SDK đã được kiểm chứng.

Đó là DevSecOps thực tế hơn.

Security Champion cũng là một mô hình thường được sử dụng.

Một số thành viên trong đội development có hiểu biết sâu hơn về AppSec và làm cầu nối với đội Security.

Họ không thay thế chuyên gia security.

Nhưng họ giúp security knowledge nằm gần nơi code được tạo ra hơn.

DevSecOps không nhằm làm chậm delivery.

Nếu triển khai tốt nó có thể làm ngược lại.

Phát hiện lỗi authorization khi đang code thường nhanh hơn phát hiện nó trong penetration test trước ngày go-live.

Phát hiện secret ngay khi commit thường dễ xử lý hơn sau khi repository đã bị clone ở nhiều nơi.

Security càng xuất hiện muộn chi phí sửa thường càng lớn.

Một workflow DevSecOps tổng quát có thể đi theo chuỗi:

Requirement → Threat Modeling → Secure Design → Secure Coding → Pull Request → Automated Security Checks → Review → Build → Artifact Verification → Deployment Controls → Monitoring → Vulnerability Management → Feedback.

Điều quan trọng không phải có đầy đủ mọi tool.

Điều quan trọng là security được đưa vào đúng điểm của workflow.

Tag DevSecOps tổng hợp các bài viết và kiến thức về secure SDLC security trong CI/CD SAST DAST SCA secret scanning dependency security software supply chain container security infrastructure as code security automation và cách tích hợp bảo mật vào quá trình phát triển phần mềm hằng ngày.