Inbox Zero của GitHub trong Quét Bí mật: Một Nghiên cứu Điển hình về Bảo mật Nhà phát triển

Tính năng quét bí mật của GitHub, phát hiện thông tin xác thực và khóa API bị rò rỉ trong các kho lưu trữ công khai, từ lâu đã là một con dao hai lưỡi. Nó bắt được các mối đe dọa thực sự, nhưng cũng tạo ra một dòng thác nhiễu làm nhà phát triển mất cảnh giác. Trong một bài đăng gần đây, kỹ sư bảo mật nhân viên Michael Recachinas giải thích cách nhóm cuối cùng đã thuần hóa được tiếng ồn đó và đạt được inbox zero.

Vấn đề: Mệt mỏi vì Cảnh báo

Quét bí mật hoạt động bằng cách khớp mẫu các định dạng thông tin xác thực đã biết. Vấn đề là nhiều mẫu trong số đó—như khóa API chung chung hoặc token thử nghiệm—là dương tính giả. Các nhà phát triển thấy hàng chục cảnh báo không liên quan mỗi ngày sẽ ngừng chú ý. Các rò rỉ thực sự bị chôn vùi.

Giải pháp: Phương pháp Ba Mũi nhọn

Recachinas và nhóm của anh ấy không chỉ thêm một nút báo lại. Họ đã thiết kế lại đường ống cảnh báo dựa trên ba nguyên tắc:

• Giảm nhiễu tại nguồn — Họ thắt chặt khớp mẫu để loại trừ các token thử nghiệm đã biết và thông tin xác thực nội bộ. Họ cũng giới thiệu một vòng phản hồi: khi một nhà phát triển đánh dấu một cảnh báo là dương tính giả, tín hiệu đó được sử dụng để huấn luyện lại máy quét.
• Tự động hóa khắc phục — Thay vì chỉ thông báo, GitHub hiện cung cấp thu hồi một cú nhấp chuột cho các dịch vụ được hỗ trợ (như AWS, token GitHub và Slack). Nếu thông tin xác thực có thể được xoay vòng tự động, cảnh báo trở thành một bản sửa lỗi, không phải một vé.
• Ưu tiên theo tác động — Các cảnh báo hiện được chấm điểm dựa trên độ nhạy của thông tin xác thực bị rò rỉ và mức độ phơi nhiễm (kho lưu trữ công khai so với riêng tư). Một khóa AWS sản xuất bị rò rỉ nhận được mức ưu tiên cao hơn một token thử nghiệm cũ.

Kết quả: Inbox Zero

Sau khi triển khai những thay đổi này, nhóm bảo mật của GitHub đã thấy giảm 90% số lượng cảnh báo quét bí mật hàng ngày. Quan trọng hơn, 10% còn lại hầu như đều có thể hành động được. Các nhà phát triển không còn bỏ qua các thông báo vì họ tin rằng một cảnh báo có nghĩa là điều gì đó thực sự.

Tại sao Điều này Quan trọng

Đây không chỉ là một câu chuyện nội bộ của GitHub. Đó là một kế hoạch chi tiết cho bất kỳ nền tảng nào tạo ra cảnh báo bảo mật ở quy mô lớn. Hiểu biết chính là nhiều cảnh báo hơn không tốt hơn. Một hệ thống bảo mật kêu cứu quá thường xuyên sẽ trở thành tiếng ồn nền. Chiến thắng thực sự không phải là bắt mọi rò rỉ có thể—mà là bắt những cái quan trọng và làm cho việc sửa chữa trở nên dễ dàng nhất có thể.

Đối với các nhóm xây dựng công cụ tương tự, bài học rất rõ ràng: đầu tư vào chất lượng tín hiệu hơn số lượng. Các nhà phát triển của bạn sẽ cảm ơn bạn.