ADR 0012Chấp nhận

ADR 0012. Nguồn nhanh chính thống, kéo delta mỗi giờ, phát hành DB khi có thay đổi

1. secdb-build chạy mỗi giờ. Mỗi adapter nguồn (ADR 0007 điểm 4) kéo delta khi nguồn có (OSV modified_id.csv, CSAF changes.csv, CVE List delta), nếu không thì tải có điều kiện (If-Modified-Since, ETag) như tracker Debian; trạng thái kéo của từng nguồn lưu trong cache của bộ dựng. 2. Nhịp theo nguồn theo bảng 03 mục 6.2: hằng giờ cho nguồn quyết định và KEV, 15 phút cho tín hiệu sớm (USN JSON chỉ để kích hoạt dựng sớm), 6 giờ cho ELTS, hằng ngày cho OVAL và EPSS. 3. Chỉ phát hành phiên bản DB mới khi nội dung đổi (so sánh bản ghi đã chuẩn hóa). Mọi kiểm tra của ADR 0005 điểm 5 (số bản ghi giảm, tỉ lệ đồng ý giữa nguồn giảm) vẫn áp cho từng lần phát hành. 4. Bản ghi mới từ nguồn nhanh hơn được dùng ngay với cờ unconfirmed (ADR 0007 điểm 6); nguồn ưu tiên cao hơn quyết định khi có. 5. Mỗi nguồn có chỉ số độ trễ (thấy lần đầu so với published của bản ghi) và độ tươi (giờ kể từ lần kéo thành công); quá ngưỡng thì cảnh báo nền tảng.

Ngày quyết định

02/10/2026

Chấp nhận

03/10/2026

Phạm vi

Scanner

Người chấp nhận

Chưa ghi

1. Đề xuất02/10/2026
2. Chấp nhận03/10/2026

• Trạng thái: Chấp nhận (2026-10-03). Chủ dự án duyệt; nhịp kéo của từng nguồn có thể chỉnh sau khi vận hành thực tế
• Ngày: 2026-10-02

Bối cảnh

ADR 0005 và 03 mục 5 giả định dựng secdb hằng ngày. Nghiên cứu ở 03 mục 6 cho thấy các nguồn chính thống cho Ubuntu (OSV, USN), Debian (tracker), Red Hat và SUSE (CSAF changes.csv), cùng CVE List và KEV đều cập nhật trong vòng phút tới giờ, và phần lớn có cơ chế delta (modified_id.csv, changes.csv, tệp delta CVE mỗi giờ). Dựng hằng ngày làm finding chậm tới 24 giờ so với nguồn. Chủ dự án yêu cầu nhiều nguồn chạy song song, nguồn nhanh nhất thắng và nguồn khác xác nhận (ADR 0007 đã sửa).

Quyết định

1. secdb-build chạy mỗi giờ. Mỗi adapter nguồn (ADR 0007 điểm 4) kéo delta khi nguồn có (OSV modified_id.csv, CSAF changes.csv, CVE List delta), nếu không thì tải có điều kiện (If-Modified-Since, ETag) như tracker Debian; trạng thái kéo của từng nguồn lưu trong cache của bộ dựng.
2. Nhịp theo nguồn theo bảng 03 mục 6.2: hằng giờ cho nguồn quyết định và KEV, 15 phút cho tín hiệu sớm (USN JSON chỉ để kích hoạt dựng sớm), 6 giờ cho ELTS, hằng ngày cho OVAL và EPSS.
3. Chỉ phát hành phiên bản DB mới khi nội dung đổi (so sánh bản ghi đã chuẩn hóa). Mọi kiểm tra của ADR 0005 điểm 5 (số bản ghi giảm, tỉ lệ đồng ý giữa nguồn giảm) vẫn áp cho từng lần phát hành.
4. Bản ghi mới từ nguồn nhanh hơn được dùng ngay với cờ unconfirmed (ADR 0007 điểm 6); nguồn ưu tiên cao hơn quyết định khi có.
5. Mỗi nguồn có chỉ số độ trễ (thấy lần đầu so với published của bản ghi) và độ tươi (giờ kể từ lần kéo thành công); quá ngưỡng thì cảnh báo nền tảng.

Hệ quả

• Độ trễ từ nguồn tới finding khoảng 1 đến 2 giờ (secmatch đã kéo latest.json mỗi giờ), thay vì tới 24 giờ.
• Số phiên bản DB tăng (tối đa 24 mỗi ngày); secmatch so khớp lại theo delta nên chi phí mỗi lần nhỏ, nhưng cần đo (S5 trên máy thử riêng).
• Băng thông của bộ dựng giảm nhờ delta; riêng tracker Debian (khoảng 80 MB) và ELTS (khoảng 126 MB) không có delta, tải lại khi đổi.
• Dedicated (P10) vẫn nhận gói DB theo lịch thủ công; ADR này chỉ áp cho bộ dựng của nền tảng.

Phương án đã cân nhắc

Phương án	Lý do không chọn
Giữ dựng hằng ngày	Chậm tới 24 giờ, trái yêu cầu nguồn nhanh
Dựng theo sự kiện đẩy từ nguồn	Hầu hết nguồn không có cơ chế đẩy (chỉ RSS, git, tệp); kéo delta mỗi giờ đủ nhanh và đơn giản
Chỉ dùng OSV.dev cho mọi distro	Một điểm phụ thuộc, không có Amazon Linux, không có trạng thái chưa sửa đầy đủ cho mọi distro; vẫn dùng OSV như một nguồn trong nhiều nguồn