Hãy tắt Dependabot

• Có ý kiến cho rằng các thông báo quá mức của Dependabot khiến lập trình viên lãng phí thời gian hơn là giải quyết các vấn đề bảo mật thực sự
• Như trường hợp xảy ra trong hệ sinh thái Go, hàng nghìn PR và cảnh báo được tạo ra ngay cả với các kho lưu trữ không bị ảnh hưởng, gây ra nhầm lẫn
• Sử dụng GitHub Action dựa trên govulncheck có thể chỉ phát hiện đoạn mã thực sự dễ bị tổn thương và loại bỏ các cảnh báo không cần thiết
• Việc cập nhật dependency nên được quản lý bằng kiểm thử định kỳ và xác minh phiên bản mới nhất thay vì PR tự động, như vậy sẽ an toàn và hiệu quả hơn
• Cách tiếp cận này rất quan trọng để giảm mệt mỏi vì cảnh báo (alert fatigue) và giảm gánh nặng cho những người bảo trì mã nguồn mở

---

Vấn đề của Dependabot

• Dependabot tạo ra hàng loạt cảnh báo bảo mật và PR tự động, khiến lập trình viên khó phân biệt đâu là vấn đề thực sự quan trọng
  • Chỉ một chỉnh sửa nhỏ trong gói Go filippo.io/edwards25519 cũng tạo ra hàng nghìn PR
  • Các cảnh báo bảo mật sai còn được gửi tới cả những kho lưu trữ không bị ảnh hưởng (như Wycheproof)
• Các cảnh báo này còn bao gồm điểm CVSS sai và chỉ số tương thích thấp, làm dấy lên cảm giác lo lắng không cần thiết
• Những thông báo quá mức như vậy bị chỉ ra là nguyên nhân làm suy giảm độ tin cậy và hiệu quả của phản ứng bảo mật

Giải pháp thay thế bằng govulncheck

• Go Vulnerability Database cung cấp metadata chi tiết ở cấp phiên bản, gói và symbol
  • Ví dụ, lỗ hổng GO-2026-4503 chỉ ảnh hưởng tới symbol Point.MultiScalarMult
• govulncheck dùng phân tích tĩnh để chỉ phát hiện đoạn mã dễ bị tổn thương thực sự có thể được gọi tới
  • Khi dùng cùng go mod why, có thể xác định chính xác dependency gián tiếp có bị ảnh hưởng hay không
  • Kết quả kiểm tra sẽ không cảnh báo nếu có lỗ hổng nhưng mã không gọi tới symbol đó
• Có thể tích hợp dễ dàng qua CLI (govulncheck -json) hoặc Go API (golang.org/x/vuln/scan)

Thay thế bằng GitHub Actions

• Thay vì Dependabot, có thể cấu hình govulncheck GitHub Action để chạy kiểm tra tự động hằng ngày
  • Chỉ gửi thông báo khi phát hiện lỗ hổng thực sự
  • Không tạo PR tự động, nhờ đó lập trình viên có thể tập trung vào các vấn đề bảo mật quan trọng
• Giảm các cảnh báo sai giúp giảm mệt mỏi vì cảnh báo (alert fatigue) và nâng cao chất lượng ứng phó
• Đồng thời cũng giải quyết vấn đề gửi PR không cần thiết tới những người bảo trì mã nguồn mở

Cách quản lý cập nhật dependency

• Dependency nên được quản lý đồng loạt theo chu kỳ phát triển của từng dự án
  • Kiểm thử với phiên bản mới nhất mỗi ngày, nhưng chỉ cập nhật thực tế khi đến thời điểm cần thiết
  • Trong Go có thể kiểm thử phiên bản mới nhất bằng lệnh go get -u -t ./..., còn với npm là npm update
• Cách làm này đảm bảo cả tốc độ xử lý lỗ hổng bảo mật lẫn tính ổn định
  • Có thể phát hiện sớm vấn đề tương thích thông qua việc kiểm thử phiên bản mới nhất
  • Ngăn dependency chứa mã độc bị triển khai ngay lập tức
• Có thể dùng geomys/sandboxed-step để chạy cách ly bằng gVisor trong môi trường CI

Kết luận và bối cảnh hỗ trợ

• Tính tự động hóa của Dependabot trong nhiều trường hợp tạo ra nhiễu (noise) nhiều hơn là bảo mật
• Cách tiếp cận dựa trên govulncheck và kiểm thử định kỳ là phương thức quản lý bảo mật chính xác và bền vững hơn
• Việc bảo trì mã nguồn mở của tác giả bài viết được duy trì thông qua tổ chức Geomys, với sự tài trợ từ Ava Labs, Teleport, Tailscale, Sentry và các bên khác
• Mô hình này góp phần vào việc duy trì ổn định hệ sinh thái mã nguồn mở và nâng cao chất lượng bảo mật

[GN⁺]

Ý kiến Hacker News

• Dependabot có giá trị ở một mức độ nhất định
  Nhưng các công cụ chỉ đơn giản so sánh số phiên bản với cơ sở dữ liệu lỗ hổng thì không thể xác định liệu mã thực tế có bị phơi nhiễm trước lỗ hổng đó hay không, nên gây rất nhiều nhiễu
  Công cụ gây ấn tượng với tôi gần đây là CodeQL. Có thể chạy trong GitHub Advanced Security, và nó theo dõi luồng thực tế của mã để hiển thị trực quan toàn bộ đường đi từ đầu vào đến cách sử dụng nguy hiểm
  Nhờ vậy, nó cung cấp thông tin có thể sửa được trong thực tế và ít dương tính giả. Tất nhiên trong các ngôn ngữ động như Python vẫn có thể có mã né được phát hiện, nhưng trong đa số trường hợp thì vẫn đủ hữu ích
  • Trước đây CodeQL có ích cho dự án, nhưng gần đây nó đã ở mức gây khó chịu quá mức nên nhóm đã tắt đi
    Xuất hiện những bình luận kiểu thêm biến trung gian vô dụng chỉ để né cảnh báo của CodeQL. Nó cho cảm giác như một công cụ overfit vào dữ liệu
  • Tôi khó đồng ý với nhận định “hầu như không có dương tính giả”. Theo định lý Rice, kiểu phân tích hoàn hảo đó là bất khả thi
  • Theo kinh nghiệm của tôi, CodeQL có nhiều dương tính giả, và không có cách nào dễ dàng để chạy cục bộ nên tạo ra sự phụ thuộc vào nhà cung cấp
  • Việc nâng phiên bản dependency không đảm bảo bảo mật được cải thiện. Phiên bản mới cũng có thể mang theo lỗ hổng mới
• Trong các gói NPM, cảnh báo ReDoS xuất hiện quá nhiều. Phần lớn là các gói chỉ dùng ở phía client, nhưng cảnh báo không liên quan tới backend lại quá nhiều. ReDoS phía client với chúng tôi không có ý nghĩa gì
  • Thực ra tôi nghĩ DoS không phải là lỗ hổng bảo mật mà là vấn đề về tính sẵn sàng. Nó đúng là một phần trong bộ CIA của bảo mật, nhưng trên thực tế lại gần với vấn đề vận hành hơn. Việc phân loại DoS là vấn đề bảo mật chỉ là một di tích lịch sử
  • Tôi đang bảo trì gói debug, và có quá nhiều báo cáo ReDoS tào lao. Có trường hợp còn được đăng ký thành CVE, khiến tôi muốn rời khỏi hệ sinh thái JS luôn
  • Tôi cũng gặp vấn đề tương tự với các công cụ review code bằng AI. Dù là công cụ chạy cục bộ với quyền người dùng, chúng vẫn bảo phải sanitize đầu vào một cách không cần thiết. Rốt cuộc chỉ là lãng phí thời gian
  • Chúng tôi cũng gặp vấn đề tương tự. Đặc biệt, các cảnh báo ReDoS đến từ Dev dependency tạo ra rất nhiều tiếng ồn không cần thiết
  • ReDoS là lỗi của regex engine, nhưng các engine như V8 vẫn chưa cung cấp regex engine an toàn làm mặc định
• Govulncheck là một trong những tính năng tốt nhất của hệ sinh thái Go
  Tôi đang dùng GitHub Action tự tạo để cảnh báo khi một lời gọi dễ tổn thương được thêm vào trong PR.
  Khi dùng cùng tự động merge của Dependabot, đây là một tổ hợp khá ổn để quản lý cả codebase JS
  • Govulncheck cũng không hoàn hảo. Nó có dương tính giả, và không có cách loại trừ một lỗ hổng cụ thể bằng số CVE
• Dependabot hữu ích, nhưng đồng thời cũng nhắc tôi mỗi ngày về tầm quan trọng của việc tối thiểu hóa dependency
  • Tôi cũng bắt đầu ngày mới bằng việc xử lý các PR Dependabot.
    Nếu test đủ tốt thì đôi khi còn phát hiện bug trong phiên bản mới, và quá trình đó cũng dẫn tới đóng góp mã nguồn mở. Phiền thật, nhưng nó tạo ra một thói quen tốt
  • Tôi cũng đồng ý. Dù không có nhiều dự án, Dependabot vẫn khá dùng được
• Tôi muốn Dependabot được quản lý dưới dạng một tab trong repository thay vì email.
  Thông báo qua email thì phiền, mà để PR chất đống cũng không thích. Tôi muốn chỉ tập trung xử lý vào những khung giờ nhất định
  • Có thể dùng cấu hình dependabot.yml để điều chỉnh chu kỳ chạy và số lượng PR
    Xem tài liệu chính thức
  • Cũng có thể tắt PR tự động và chỉ tạo thủ công khi cần.
    Bạn cũng có thể tự sửa trực tiếp để giảm số lượng issue
  • Nếu dùng tiện ích Refined GitHub thì giao diện mặc định sẽ gọn gàng hơn một chút.
    Cá nhân tôi khuyên dùng Renovate. Nó hỗ trợ nhiều ngôn ngữ hơn và có thêm tùy chọn tự động merge
• Cách làm của govulncheck trong Go (theo dõi đường đi gọi thực tế) nên trở thành mặc định cho mọi hệ sinh thái
  Vấn đề gốc rễ của Dependabot là nó đang nhầm quản lý dependency thành vấn đề bảo mật.
  Lỗ hổng trong một hàm không được gọi tới không phải là vấn đề bảo mật mà là nhiễu
  Trong Python, tôi thấy pip-audit --desc tốt hơn Dependabot.
  Cho đến khi có phân tích tĩnh hoàn hảo, kiểm tra thủ công theo quý có khi còn an toàn hơn
  • Nhưng khi khách hàng quét code bằng các công cụ kiểu này, họ sẽ không tin câu trả lời rằng “chúng tôi không dùng hàm đó”.
    Sự chênh lệch giữa bảo mật thực tế và thực hành bảo mật phát sinh từ đây
  • Câu hỏi “nếu không dùng thì tại sao hàm đó vẫn còn trong code” cũng là một câu hỏi hợp lý
• Tôi không hiểu vì sao ngành này lại chấp nhận những trình quét bảo mật hời hợt như vậy
  Phần lớn CVE trên thực tế không gây ảnh hưởng, nhưng các công ty lại cố đưa số lỗ hổng trong container image về 0
  Hơn nữa, cứ cập nhật dependency là lại phát sinh CVE mới. Bởi đa số phần mềm không backport bản vá
  • Tôi không rõ đoạn “không backport” liên hệ với câu trước như thế nào
• Điểm mạnh của Dependabot hay Renovate là chúng hoạt động không phụ thuộc ngôn ngữ
  Càng có nhiều repository và càng nhiều ngôn ngữ, việc thêm workflow CI hoàn hảo càng thiếu thực tế
  Dù không hoàn hảo, tôi vẫn nghĩ nó tốt hơn rất nhiều so với không làm gì cả
• Tôi tò mò không biết điểm CVSS của Dependabot đến từ đâu.
  Có phải nó tự động tạo CVE không?
  • CVSS là thang điểm giả định trường hợp xấu nhất, nên không phản ánh rủi ro thực tế.
    Cơ sở dữ liệu lỗ hổng của GitHub tập trung vào số lượng hơn là chất lượng, và Dependabot hoạt động như một máy spam cảnh báo không có trí tuệ
  • Thậm chí còn đáng nghi liệu lỗi đó có thực sự là lỗ hổng hay không.
    Nếu vấn đề chỉ xảy ra khi gọi hàm theo cách sai, thì có lẽ code vốn dĩ đã không hoạt động đúng rồi
• Công ty chúng tôi cũng gặp vấn đề tương tự.
  Tính năng quét container image của GCP đổ về Vanta vô số cảnh báo CVE, mà phần lớn либо không thể sửa hoặc thực tế nằm trên các đường đi không được dùng tới
  Tôi tự hỏi có công cụ nào làm được kiểu lọc theo ngữ cảnh này không
  • Công ty chúng tôi đang dùng Aikido Code. Họ cố lọc tác động thực tế của lỗ hổng bằng AI.
    Kết quả nhìn chung là tích cực, nhưng với codebase lớn và nhiều dependency thì việc giảm số lượng CVE vẫn rất khó khăn