Skip to content

Checkmarx và Klocwork (SAST)

Trang này trình bày kiểm thử bảo mật mã nguồn tĩnh (Static Application Security Testing, SAST) và hai công cụ thương mại thường gặp là Checkmarx và Klocwork, theo góc nhìn tìm lỗ hổng bảo mật trong mã của thiết bị nhúng. Nội dung đi theo thứ tự: vị trí của SAST trong kiểm thử bảo mật, so sánh hai công cụ, quy trình quét, cách chọn luật và xử lý kết quả. Khái niệm phân tích tĩnh và các công cụ mã nguồn mở nằm ở trang Phân tích tĩnh mã nguồn.

Vị trí của SAST

SAST tương ứng với hoạt động "review mã nguồn" trong Kiểm thử bảo mật cho thiết bị nhúng. Công cụ đọc mã trước khi build hoặc ngay trong lúc build, nên tìm được lỗi sớm, trước khi có firmware chạy được. Hạn chế là không thấy được hành vi lúc chạy: cấu hình sai khi triển khai, lỗi do tương tác giữa các thành phần hay lỗ hổng trong thư viện bên thứ ba đã biên dịch sẵn. Các phần này cần pentest, quét lỗ hổng hoặc phân tích thành phần phần mềm.

SAST thường bắt các lớp điểm yếu thuộc danh sách CWE (xem CVE): tràn bộ đệm, dùng chuỗi định dạng không an toàn, command injection, dùng hàm mật mã yếu, hard-code mật khẩu hoặc khóa.

So sánh Checkmarx và Klocwork

Tiêu chí Checkmarx Klocwork
Nhà cung cấp Checkmarx Perforce
Trọng tâm Bảo mật ứng dụng, nhiều ngôn ngữ, nền tảng gồm SAST và các module khác (SCA, DAST, IaC) Lỗi và bảo mật trong mã, mạnh ở C/C++ và các tiêu chuẩn mã an toàn
Cách lấy mã để phân tích Quét mã nguồn, ít phụ thuộc vào build với nhiều ngôn ngữ Ghi lại quá trình build để biết include path và macro
Tiêu chuẩn Ánh xạ kết quả sang CWE, OWASP Top 10 MISRA, CERT, CWE và một số tiêu chuẩn ngành
Tình huống phù hợp Tổ chức có nhiều dịch vụ web, backend và ứng dụng, thiết bị chỉ là một phần Firmware C/C++ cần chứng minh tuân thủ coding standard

Đây là so sánh ở mức định hướng. Hai công cụ có vùng chồng lấn, và mức hỗ trợ cụ thể cho C/C++ nhúng phụ thuộc vào phiên bản và giấy phép.

Todo

Chưa kiểm chứng với tài liệu của nhà cung cấp: danh sách ngôn ngữ và tiêu chuẩn mỗi công cụ hỗ trợ ở phiên bản hiện hành, và mức hỗ trợ build cross compile cho C/C++ của Checkmarx. Cần đối chiếu trước khi dùng bảng trên để chọn công cụ.

Quy trình quét với Klocwork

Klocwork phân tích trên một bản ghi quá trình build. Trình tự gồm ba bước, mỗi bước dùng một lệnh dòng lệnh:

  1. Ghi lại quá trình build bằng kwinject, bao quanh lệnh build hiện có (make, CMake).
  2. Phân tích bản ghi bằng kwbuildproject, sinh ra các bảng kết quả.
  3. Tải kết quả lên máy chủ bằng kwadmin load để xem và triage trên giao diện web.
kwinject -T trace.out make
kwbuildproject --url http://klocwork.example:8080/myproject \
    --tables-directory tables trace.out
kwadmin --url http://klocwork.example:8080 load myproject tables

Địa chỉ máy chủ và tên project trong ví dụ là giá trị minh họa. Cú pháp chính xác cần kiểm tra theo phiên bản đang dùng.

Với mã cross compile, lệnh build chạy trong kwinject nên ghi lại cả include path và macro của toolchain đích, nhờ đó phân tích không cần chạy trên thiết bị. Cấu hình build xem Cross compile.

Quy trình quét với Checkmarx

Checkmarx thường được dùng theo mô hình quét trên máy chủ hoặc dịch vụ của nhà cung cấp. Hai cách kích hoạt thường gặp:

  • Tích hợp vào CI: pipeline gửi mã nguồn (hoặc tham chiếu repository) tới Checkmarx sau mỗi commit hoặc pull request, rồi nhận kết quả để quyết định có chặn merge hay không.
  • Quét định kỳ: lập lịch quét toàn bộ repository, phù hợp với codebase lớn.

Chi tiết lệnh và plugin phụ thuộc vào sản phẩm và gói giấy phép, nên không ghi trong trang này.

Chọn luật và xử lý kết quả

Bộ luật mặc định thường sinh nhiều cảnh báo không liên quan tới thiết bị. Nên bắt đầu bằng các luật liên quan trực tiếp tới bề mặt tấn công của sản phẩm (dữ liệu từ mạng, từ giao diện quản trị, từ file cấu hình), rồi mở rộng dần.

Mức Cách xử lý
Lỗi mức cao có đường dữ liệu từ nguồn không tin cậy Sửa trước khi phát hành, chặn merge trong CI
Lỗi mức trung bình Lên kế hoạch sửa theo release
Cảnh báo về style hoặc chất lượng Theo dõi qua baseline, xử lý dần
False positive Ghi nhận lý do trong công cụ, không tắt luật trên toàn project

Lỗ hổng được xác nhận cần được theo dõi cùng quy trình quản lý lỗ hổng chung (xem CVE), kể cả khi lỗi chỉ nằm trong mã nội bộ chưa phát hành.

Liên quan

Tài liệu tham khảo