Tweet
DevSecOps (Phần 6): SAST và DAST – Hai "lớp lá chắn" bảo vệ ứng dụng ngay trong CI/CD Pipeline
Một ứng dụng có thể build thành công, Unit Test đều đạt, nhưng vẫn tồn tại lỗ hổng bảo mật nghiêm trọng.
Đó là lý do trong các CI/CD Pipeline hiện đại, sau Build và Test luôn có thêm một bước rất quan trọng:
Security Testing.
Mục tiêu không chỉ là kiểm tra xem ứng dụng có chạy được hay không, mà còn phải đảm bảo chạy an toàn trước khi được triển khai.
Security Testing trong CI/CD gồm những gì?
Thông thường, Security Testing được chia thành hai nhóm chính:
Hai kỹ thuật này bổ sung cho nhau và thường được triển khai dưới dạng các Job độc lập trong cùng một Stage của CI/CD Pipeline.
1. SAST – Kiểm tra bảo mật từ Source Code
SAST phân tích trực tiếp source code hoặc mã đã được biên dịch để tìm các lỗ hổng bảo mật mà không cần chạy ứng dụng.
Đây là phương pháp Shift Left Security, giúp phát hiện vấn đề ngay từ khi developer vừa commit code.
Một số lỗi SAST có thể phát hiện:
Vì không cần thực thi ứng dụng nên SAST có tốc độ rất nhanh và thường được chạy ngay sau Build Stage.
2. DAST – Tấn công ứng dụng giống như Hacker
Nếu SAST "đọc mã nguồn", thì DAST hoạt động theo cách hoàn toàn khác.
DAST không quan tâm bên trong source code.
Thay vào đó, nó sẽ tương tác trực tiếp với ứng dụng đang chạy, giống như một người dùng hoặc một kẻ tấn công từ bên ngoài.
DAST sẽ chủ động gửi các yêu cầu để tìm kiếm những lỗ hổng phổ biến như:
Nói cách khác, DAST đánh giá mức độ an toàn của ứng dụng từ góc nhìn thực tế khi hệ thống đã được triển khai.
SAST và DAST được triển khai như thế nào?
Trong các hệ thống DevSecOps hiện đại, cả SAST và DAST thường được đóng gói dưới dạng Container.
Pipeline sẽ:
Việc container hóa giúp các công cụ bảo mật dễ triển khai, dễ cập nhật và hoạt động nhất quán trên mọi môi trường CI/CD.
Điều gì xảy ra khi phát hiện lỗ hổng?
Đây chính là điểm mạnh của DevSecOps.
Giả sử công cụ SAST phát hiện ứng dụng vi phạm một quy tắc bảo mật thuộc OWASP Top 10.
Khi đó:
Developer Commit
│
▼
Build
│
▼
SAST Scan
│
▼
❌ Vulnerability Found
│
▼
Job Failed
│
▼
Stage Failed
│
▼
Pipeline Stopped
│
▼
Security Report Generated
Chỉ cần một Job thất bại, toàn bộ Stage sẽ được đánh dấu Failed, Pipeline dừng ngay lập tức và hệ thống sinh ra báo cáo chi tiết để developer phân tích nguyên nhân và khắc phục.
Sau khi sửa lỗi thì sao?
Quy trình DevSecOps không dừng ở việc phát hiện lỗ hổng.
Sau khi sửa mã nguồn:
Nhờ vậy, nhóm phát triển không chỉ xác nhận rằng lỗ hổng đã được khắc phục, mà còn giảm nguy cơ vô tình tạo ra lỗi mới trong quá trình sửa chữa.
Vì sao nên tích hợp Security Testing vào CI/CD?
Khi Security Testing được thực hiện tự động sau mỗi lần commit, doanh nghiệp có thể:
Đến đây, chúng ta đã đi qua những thành phần quan trọng nhất của một CI/CD Pipeline hiện đại: từ Build, Static Code Analysis, Pipeline → Stage → Job, đến SAST và DAST. Đây chính là nền tảng để triển khai DevSecOps, nơi chất lượng và bảo mật được kiểm tra liên tục trong suốt vòng đời phát triển phần mềm, thay vì chỉ đánh giá khi sản phẩm đã sẵn sàng phát hành.
Một ứng dụng có thể build thành công, Unit Test đều đạt, nhưng vẫn tồn tại lỗ hổng bảo mật nghiêm trọng.
Đó là lý do trong các CI/CD Pipeline hiện đại, sau Build và Test luôn có thêm một bước rất quan trọng:
Security Testing.
Mục tiêu không chỉ là kiểm tra xem ứng dụng có chạy được hay không, mà còn phải đảm bảo chạy an toàn trước khi được triển khai.
Security Testing trong CI/CD gồm những gì?
Thông thường, Security Testing được chia thành hai nhóm chính:
- SAST (Static Application Security Testing)
- DAST (Dynamic Application Security Testing)
Hai kỹ thuật này bổ sung cho nhau và thường được triển khai dưới dạng các Job độc lập trong cùng một Stage của CI/CD Pipeline.
1. SAST – Kiểm tra bảo mật từ Source Code
SAST phân tích trực tiếp source code hoặc mã đã được biên dịch để tìm các lỗ hổng bảo mật mà không cần chạy ứng dụng.
Đây là phương pháp Shift Left Security, giúp phát hiện vấn đề ngay từ khi developer vừa commit code.
Một số lỗi SAST có thể phát hiện:
- Hardcoded Password
- Insecure Coding Practices
- SQL Injection tiềm ẩn
- Command Injection
- Buffer Overflow
- Sử dụng API không an toàn
- Các lỗi thuộc OWASP Top 10
Vì không cần thực thi ứng dụng nên SAST có tốc độ rất nhanh và thường được chạy ngay sau Build Stage.
2. DAST – Tấn công ứng dụng giống như Hacker
Nếu SAST "đọc mã nguồn", thì DAST hoạt động theo cách hoàn toàn khác.
DAST không quan tâm bên trong source code.
Thay vào đó, nó sẽ tương tác trực tiếp với ứng dụng đang chạy, giống như một người dùng hoặc một kẻ tấn công từ bên ngoài.
DAST sẽ chủ động gửi các yêu cầu để tìm kiếm những lỗ hổng phổ biến như:
- Cross-Site Scripting (XSS)
- SQL Injection
- Command Injection
- Path Traversal
- Lỗi cấu hình máy chủ (Insecure Server Configuration)
Nói cách khác, DAST đánh giá mức độ an toàn của ứng dụng từ góc nhìn thực tế khi hệ thống đã được triển khai.
SAST và DAST được triển khai như thế nào?
Trong các hệ thống DevSecOps hiện đại, cả SAST và DAST thường được đóng gói dưới dạng Container.
Pipeline sẽ:
- Tải (Pull) Docker Image của công cụ quét.
- Khởi chạy Container.
- Cấu hình mục tiêu cần quét.
- Thực hiện quá trình phân tích.
- Sinh ra Artifact chứa báo cáo lỗ hổng để nhóm phát triển xem xét.
Việc container hóa giúp các công cụ bảo mật dễ triển khai, dễ cập nhật và hoạt động nhất quán trên mọi môi trường CI/CD.
Điều gì xảy ra khi phát hiện lỗ hổng?
Đây chính là điểm mạnh của DevSecOps.
Giả sử công cụ SAST phát hiện ứng dụng vi phạm một quy tắc bảo mật thuộc OWASP Top 10.
Khi đó:
Developer Commit
│
▼
Build
│
▼
SAST Scan
│
▼
❌ Vulnerability Found
│
▼
Job Failed
│
▼
Stage Failed
│
▼
Pipeline Stopped
│
▼
Security Report Generated
Chỉ cần một Job thất bại, toàn bộ Stage sẽ được đánh dấu Failed, Pipeline dừng ngay lập tức và hệ thống sinh ra báo cáo chi tiết để developer phân tích nguyên nhân và khắc phục.
Sau khi sửa lỗi thì sao?
Quy trình DevSecOps không dừng ở việc phát hiện lỗ hổng.
Sau khi sửa mã nguồn:
- Developer commit lại code.
- Pipeline được kích hoạt từ đầu.
- Toàn bộ Build, Test, SAST, DAST và các bước kiểm tra khác được thực hiện lại.
- Chỉ khi tất cả các kiểm tra đều thành công, Pipeline mới tiếp tục đến các Stage tiếp theo như Deploy.
Nhờ vậy, nhóm phát triển không chỉ xác nhận rằng lỗ hổng đã được khắc phục, mà còn giảm nguy cơ vô tình tạo ra lỗi mới trong quá trình sửa chữa.
Vì sao nên tích hợp Security Testing vào CI/CD?
Khi Security Testing được thực hiện tự động sau mỗi lần commit, doanh nghiệp có thể:
- Phát hiện lỗ hổng bảo mật ngay từ giai đoạn phát triển.
- Ngăn mã nguồn không an toàn được triển khai lên Staging hoặc Production.
- Tạo báo cáo bảo mật cho từng lần Build.
- Rút ngắn thời gian xử lý sự cố vì biết chính xác commit nào gây ra vấn đề.
- Đưa bảo mật trở thành một phần tự nhiên của quy trình phát triển thay vì một bước kiểm tra ở cuối dự án.
Đến đây, chúng ta đã đi qua những thành phần quan trọng nhất của một CI/CD Pipeline hiện đại: từ Build, Static Code Analysis, Pipeline → Stage → Job, đến SAST và DAST. Đây chính là nền tảng để triển khai DevSecOps, nơi chất lượng và bảo mật được kiểm tra liên tục trong suốt vòng đời phát triển phần mềm, thay vì chỉ đánh giá khi sản phẩm đã sẵn sàng phát hành.
Attached Files