Bài học từ việc biến 127 triệu điểm dữ liệu thành báo cáo ngành về bảo mật

Đầu năm nay, tôi đã xuất bản một báo cáo ngành mang tên Remediation at Scale, phân tích sâu sắc cách các đội ngũ bảo mật ứng dụng (AppSec) khắc phục các lỗ hổng trong mã nguồn của họ. Bộ dữ liệu bao gồm hàng chục nghìn kho lưu trữ, dữ liệu quét trong một năm đầy đủ và các tổ chức quy mô từ startup đến doanh nghiệp lớn. Tổng cộng, có hơn 127 triệu điểm dữ liệu bao gồm các phát hiện riêng lẻ, sự kiện quét và hành động khắc phục trên hai loại hình quét bảo mật (SAST và SCA).

Tôi là một Quản lý Sản phẩm Kỹ thuật (Senior Technical PMM) tại Semgrep với nền tảng về khoa học máy tính, khoa học dữ liệu và kỹ thuật giải pháp. Dự án này đã cho tôi kết hợp tất cả những kỹ năng đó: viết SQL, xây dựng tập lệnh để quản lý phân tích, phân tích và làm sạch dữ liệu, tìm ra câu chuyện đằng sau những con số và xuất bản sản phẩm hoàn chỉnh.

Bài viết này sẽ chia sẻ năm bài học tôi đúc kết được trong quá trình thực hiện dự án. Nếu bạn từng phải đối mặt với một bộ dữ liệu khổng lồ và cần biến nó thành một thông điệp có thể hành động được cho cả đối tượng kỹ thuật và phi kỹ thuật, những kinh nghiệm này sẽ rất hữu ích.

1. Bắt đầu từ dữ liệu, không phải từ câu chuyện

Sự cám dỗ trong bất kỳ dự án dữ liệu nào là quyết định trước câu chuyện mà bạn muốn kể, sau đó đi tìm con số để chứng minh nó. Tôi đã làm điều ngược lại.

Tôi đã dành nhiều tuần ở chế độ khám phá thuần túy. Thực hiện các truy vấn trên Snowflake, xem xét phân phối, chạy các thao tác tổng hợp trên nhiều chiều khác nhau. Không có giả thuyết, không có góc nhìn. Chỉ đơn giản là cố gắng hiểu dữ liệu thực sự nói lên điều gì.

Đây là một giai đoạn khó khăn nhưng lại quan trọng nhất. Dữ liệu đã tiết lộ một câu chuyện mà tôi không thể đoán trước: khoảng cách giữa các đội ngũ bảo mật hoạt động xuất sắc và phần còn lại không nằm ở công cụ (tooling). Nó nằm ở việc thực hiện có hệ thống quy trình khắc phục (remediation).

Shell script để tự động phát hiện và chạy các truy vấn cho báo cáo

Tôi cũng sử dụng các LLM cục bộ thông qua Ollama để phân loại hơn 10.000 bản ghi phân loại dựa trên văn bản thành 20 chủ đề khác nhau. Điều nổi lên là một mô hình rõ ràng: các chủ đề phổ biến nhất liên quan đến tệp kiểm thử (test files), tính năng bảo vệ của framework và các dịch vụ tin cậy. Điều đó kể một câu chuyện về cách các đội ngũ thực sự sử dụng công cụ phân loại mà tôi sẽ không bao giờ tìm thấy chỉ bằng cách nhìn vào các số liệu tổng hợp.

2. Trở thành chuyên gia trong lĩnh vực

Bạn không thể kể một câu chuyện về dữ liệu mà bạn không hiểu. Trước khi viết một phần nào đó, tôi cần biết cách hoạt động của trình quét phân tích tĩnh (static analysis scanners), cách luồng khắc phục hoạt động trong thực tế và các chỉ số thực sự quan trọng với đội ngũ bảo mật.

Nhiều công ty trong lĩnh vực này xuất bản các báo cáo hàng năm về các chủ đề tương tự. Tôi đã thu thập và đọc càng nhiều càng tốt để hiểu định dạng, chiều sâu và kỳ vọng của ngành. Điều này giúp tôi nhận ra các khoảng trống: hầu hết các báo cáo tập trung vào khối lượng phát hiện, nhưng rất ít đi sâu vào những gì xảy ra sau khi phát hiện. Đó chính là góc nhìn của tôi.

3. Giao tiếp sớm và thường xuyên với đối tượng mục tiêu

Các phiên bản phân tích ban đầu chỉ hiển thị các con số trung bình. Tỷ lệ khắc phục trung bình, thời gian khắc phục trung bình... Các con số thì ổn, nhưng câu chuyện thì nhàm chán.

Sự đột phá đến sau khi nói chuyện với những người thực tế: các kỹ sư bảo mật, trưởng bộ phận AppSec và CISO. Ai cũng muốn trả lời một câu hỏi: "Làm sao để so sánh đội ngũ của tôi với những người đang làm tốt?".

Phản hồi này đã định hình hai quyết định lớn nhất trong báo cáo.

Thứ nhất, dẫn đến việc phân khúc dựa trên nhóm (cohort-based segmentation). Tôi chia các tổ chức thành hai nhóm: 15% hàng đầu về tỷ lệ sửa lỗi ("Leaders") và phần còn lại ("The Field"). Đột nhiên, dữ liệu có sự tương phản rõ ràng:

• Leaders sửa nhiều lỗ hổng hơn gấp 2-3 lần.
• Họ giải quyết các vấn đề phát hiện trong quá trình review mã nhanh hơn gấp 9 lần so với quét toàn bộ kho lưu trữ.
• Họ áp dụng các tính năng tự động hóa quy trình làm việc ở tỷ lệ cao hơn.

Phân chia các nhóm thành Leaders và Field giúp người đọc có tham chiếu về vị thế của chương trình của họ

Thứ hai, nó tái định hình cấu trúc báo cáo. Mọi người không chỉ muốn các tiêu chuẩn tham chiếu (benchmarks), họ muốn biết phải làm gì với chúng. Điều này dẫn đến việc tôi thêm một phần khuyến nghị dựa trên bằng chứng, được sắp xếp theo tốc độ thực hiện: chiến thắng nhanh trong tuần, thay đổi quy trình trong quý và đầu tư chiến lược trong nửa năm.

4. Tận dụng thiết kế từ sớm

Dữ liệu báo cáo sống hay chết phụ thuộc vào ngoại hình của nó. Một bức tường biểu đồ không có thứ bậc thị giác cũng tệ như không có dữ liệu nào cả.

Tôi đã mời đội ngũ thiết kế tham gia sớm hơn bình thường và dành thời gian giải thích cho họ về lĩnh vực này. Khi các nhà thiết kế hiểu câu chuyện, họ đưa ra các lựa chọn (màu mã cho các nhóm, hộp chú thích cho các thông tin chính, ví dụ mã trước/sau) giúp củng cố nội dung mà không cần tôi giải thích quá nhiều bằng văn bản.

Bản thiết kế khái niệm cho bìa báo cáo

5. Dành cho mình đủ thời gian

Dự án này đã mất hàng tháng. Việc khám phá dữ liệu thôi cũng đã mất nhiều tuần. Sau đó là các vòng lặp phân tích, chu kỳ thiết kế, xem xét pháp lý và các vòng phản hồi từ các bên liên quan.

Nếu tôi cố gắng hoàn thành nó trong một quý, kết quả sẽ không đáng nhớ. Nhìn lại, hai điều tôi sẽ thay đổi là: ghi lại mọi định nghĩa và giả định ngay từ ngày đầu tiên, và mang thêm một cặp mắt khác vào giai đoạn khám phá để kiểm tra xem một phát hiện có thú vị hay chỉ là nhiễu.

Báo cáo "Remediation at Scale" bao gồm sáu mô hình được chứng thực bằng thực tế phân tách các đội ngũ bảo mật hoạt động cao hiệu quả với phần còn lại.