Tại sao các thư viện mã nguồn mở lại là "bom hẹn giờ" trong dự án của bạn (và cách vô hiệu hóa chúng)

Nếu bạn từng chạy lệnh npm audit và thấy 47 lỗ hổng bảo mật "nhìn chằm chằm" vào mình, bạn chắc chắn sẽ hiểu cảm giác đó. Đó là khoảnh khắc "tại sao lại ra nông nỗi này" khiến bạn nhận ra ứng dụng của mình đang được xây dựng trên một tháp mã mà không ai — kể cả bạn — thực sự xem xét kỹ.

Đây không phải là vấn đề mới, nhưng nó đang trở nên tồi tệ hơn. Một ứng dụng hiện đại trung bình kéo về hàng trăm dependency gián tiếp. Và sự thật khó chấp nhận là gì? Hầu hết các thư viện mã nguồn mở quan trọng đều được duy trì bởi một số ít người, thậm chí chỉ có một người, và họ chỉ xem xét mã trong thời gian rảnh rỗi.

Những nỗ lực gần đây trong ngành — bao gồm các sáng kiến sử dụng mô hình AI để kiểm toán bảo mật tự động cho các kho mã nguồn mở — đã đưa vấn đề này trở lại tâm điểm chú ý. Hãy cùng thảo luận về vấn đề thực tế, tại sao các phương pháp tiếp cận truyền thống không hiệu quả, và bạn có thể làm gì ngay hôm nay để ngừng coi nhẹ bảo mật của các thư viện phụ thuộc.

Nguyên nhân gốc rễ: Tin tưởng mà không xác minh

Đây là cách hầu hết chúng ta thêm thư viện phụ thuộc:

# Sáng thứ Hai, cần một thư viện xử lý ngày tháng
npm install cool-date-lib
# ...không bao giờ nhìn vào mã nguồn của nó
# ...không bao giờ kiểm tra ai đang duy trì nó
# ...không bao giờ kiểm toán 14 dependency gián tiếp của nó

Chúng ta ngầm tin rằng có người khác đã thực hiện việc xem xét bảo mật. Nhưng ai? Người duy trì thường chỉ là một lập trình viên quá tải. Cộng đồng chủ yếu bao gồm những người báo cáo vấn đề (issue), không phải những người đọc mã nguồn từng dòng một.

Vấn đề trở nên phức tạp ở ba cấp độ:

• Lỗ hổng trực tiếp trong mã của chính dependency đó (tràn bộ đệm, lỗi injection, deserialization không an toàn).
• Tấn công chuỗi cung ứng nơi tài khoản của người duy trì bị xâm phạm hoặc một gói độc hại được đưa vào thông qua việc đánh lách tên gói (typosquatting).
• Rủi ro truyền dẫn nơi dependency của dependency của bạn mới là nơi chứa lỗ hổng thực sự, bị chôn vùi sâu ba cấp độ.

Lỗ hổng Log4Shell vào cuối năm 2021 là hồi chuông cảnh tỉnh. Một lỗi nghiêm trọng trong thư viện ghi log nằm trong gần mọi ứng dụng Java trên hành tinh. Nó đã ở đó nhiều năm. Không ai phát hiện ra vì không ai để ý — ít nhất là không ở quy mô đó.

Bước 1: Thực sự hiểu bạn đang chạy cái gì

Bạn không thể bảo vệ thứ bạn không nhìn thấy. Hãy bắt đầu với Hóa đơn phần mềm (SBOM - Software Bill of Materials). Đây không chỉ là một từ ngữ tuân thủ — nó là danh mục kiểm kê các dependency của bạn.

# Tạo SBOM cho dự án Node.js sử dụng CycloneDX
npx @cyclonedx/cyclonedx-npm --output-file sbom.json

# Đối với dự án Python
pip install cyclonedx-bom
cyclonedx-py requirements -i requirements.txt -o sbom.json

# Đối với dự án Go
# Sử dụng đồ thị go module để tạo cây dependency đầy đủ
cyclonedx-gomod mod -json -output sbom.json

Khi bạn đã có SBOM, bạn có thể đưa nó vào cơ sở dữ liệu lỗ hổng. Nhưng chỉ tạo nó một lần là chưa đủ — hãy biến nó thành một phần của quy trình CI (Continuous Integration) để nó luôn được cập nhật.

Bước 2: Tự động hóa quét trong CI (Không chỉ cục bộ)

Chạy npm audit trên máy tính cá nhân thì ổn, nhưng chỉ chạy trên máy tính cá nhân thì không. Bạn cần điều này trong CI, nơi nó có thể thực sự chặn mã độc hại được triển khai.

Dưới đây là thiết lập thực tế cho GitHub Actions sử dụng OSV-Scanner, một công cụ mã nguồn mở được hỗ trợ bởi cơ sở dữ liệu lỗ hổng OSV:

# .github/workflows/dependency-audit.yml
name: Dependency Audit
on:
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 6 * * 1'  # quét định kỳ vào sáng thứ Hai hàng tuần

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run OSV-Scanner
        uses: google/osv-scanner-action/osv-scanner-action@v2
        with:
          scan-args: |-
            --recursive
            ./

      # Hành động này sẽ làm thất bại bản build nếu tìm thấy lỗ hổng
      # vượt quá ngưỡng mức độ nghiêm trọng đã cấu hình

Công việc cron theo lịch trình rất quan trọng. Các lỗ hổng mới được công bố liên tục — một dependency sạch sẽ tuần trước có thể có CVE hôm nay. Nếu bạn chỉ quét trên PR, bạn sẽ bỏ lỡ các lỗ hổng được phát hiện sau khi mã của bạn được hợp nhất.

Bước 3: Khóa chặt việc phân giải dependency

Các tệp khóa (lockfiles) tồn tại vì một lý do. Nhưng tôi đã thấy rất nhiều dự án nơi package-lock.json nằm trong .gitignore (vui lòng đừng làm thế) hoặc nơi các lập trình viên thường xuyên chạy npm install thay vì npm ci.

# Trong CI, LUÔN LUÔN sử dụng ci thay vì install
# npm ci sử dụng tệp khóa chính xác — không có nâng cấp bất ngờ
npm ci

# Đối với Python, hãy cố định mọi thứ bao gồm cả dependency gián tiếp
pip freeze > requirements.txt
# Hoặc tốt hơn, hãy sử dụng pip-tools để tạo bản dựng có thể tái tạo
pip-compile requirements.in --generate-hashes  # hashes xác minh tính toàn vẹn

Cờ --generate-hashes chính là người hùng thực sự ở đây. Nó đảm bảo rằng nội dung gói chính xác mà bạn đã xem xét là thứ được cài đặt. Nếu ai đó đẩy một phiên bản bị xâm phạm lên PyPI với cùng số phiên bản (vâng, điều này đã từng xảy ra), việc kiểm tra hash sẽ phát hiện ra nó.

Bước 4: Giảm bề mặt tấn công

Lỗ hổng tốt nhất là lỗ hổng nằm trong một dependency mà bạn chưa bao giờ cài đặt. Tôi đã đếm không xuể bao nhiêu dự án tôi thấy với cây dependency khổng lồ cho các chức năng có thể viết trong 20 dòng code.

// Trước khi: cài đặt một gói để kiểm tra số chẵn
// (đây là một gói npm thật với hàng triệu lượt tải xuống)
const isEven = require('is-even');

// Sau khi: chỉ cần... viết nó
function isEven(n) {
  return n % 2 === 0;
}

// Trước khi: kéo toàn bộ lodash chỉ cho một hàm
const _ = require('lodash');
_.get(obj, 'a.b.c');

// Sau khi: optional chaining đã tồn tại từ ES2020
const value = obj?.a?.b?.c;

Tôi không nói là "viết mọi thứ từ đầu". Đó là một cơn ác mộng bảo mật khác. Nhưng hãy có chủ đích. Trước khi thêm một dependency, hãy tự hỏi:

• Tôi có thể làm điều này với thư viện chuẩn hoặc các tính năng có sẵn của ngôn ngữ không?
• Nó kéo về bao nhiêu dependency gián tiếp?
• Ai duy trì nó và họ duy trì tích cực như thế nào?

Bước 5: Thiết lập cập nhật dependency tự động

Các dependency cũ kỹ là nguy hiểm. Bạn càng để lâu không cập nhật, khả năng bạn đang chạy mã có các lỗ hổng đã biết càng cao — và việc nâng cấp sau này càng trở nên khó khăn hơn.

Dependabot và Renovate là hai lựa chọn mã nguồn mở chính ở đây. Tôi thích Renovate vì tính linh hoạt của nó, nhưng cả hai đều hoàn thành tốt công việc. Quyết định cấu hình quan trọng là chiến lược nhóm:

// renovate.json — nhóm các cập nhật minor/patch để giảm tiếng ồn PR
{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "packageRules": [
    {
      "matchUpdateTypes": ["minor", "patch"],
      "groupName": "minor and patch dependencies",
      "automerge": true
    },
    {
      "matchUpdateTypes": ["major"],
      "dependencyDashboardApproval": true
    }
  ],
  "vulnerabilityAlerts": {
    "enabled": true,
    "labels": ["security"]
    // Các bản vá bảo mật sẽ có PR riêng, không bị gộp nhóm
  }
}

Tự động hợp nhất (automerge) các bản cập nhật minor và patch (giả sử bạn có độ phủ bài kiểm tra tốt) giúp giữ cho các dependency của bạn mới mẻ mà không khiến bạn ngập trong các PR. Các bản cập nhật major sẽ được gắn cờ để xem xét thủ công vì chúng có khả năng chứa các thay đổi phá vỡ (breaking changes).

Bức tranh lớn: Kiểm toán hỗ trợ bởi AI

Đây là điều đang thay đổi. Ngành công nghiệp đang bắt đầu khám phá việc sử dụng các mô hình ngôn ngữ lớn (LLM) để kiểm toán mã nguồn ở quy mô mà người xem xét không thể theo kịp. Ý tưởng rất đơn giản: hướng một mô hình AI vào một cơ sở mã và yêu cầu nó tìm kiếm các mẫu lỗ hổng, quyền truy cập bộ nhớ không an toàn, điểm injection và lỗi logic.

Tôi chưa kiểm tra kỹ các phương pháp này trong quy trình làm việc của mình, và thành thật mà nói thì các công cụ này vẫn đang trưởng thành. Nhưng tiền đề là hợp lý — các công cụ phân tích tĩnh luôn bị giới hạn bởi bộ quy tắc của chúng, và các mô hình ML có khả năng bắt được các mẫu lỗ hổng mới mà các trình quét dựa trên quy tắc bỏ sót.

Điều mà AI không thể thay thế là những điều cơ bản. Không có bao nhiêu kiểm toán AI nào giúp ích nếu bạn không theo dõi các dependency, không chạy trình quét trong CI, và không giữ mọi thứ được cập nhật. Những điều cơ bản vẫn quan trọng.

Danh sách kiểm tra phòng ngừa

Nếu bạn không lấy gì khác từ bài viết này, hãy nhớ:

• Tạo và duy trì SBOM cho mọi dự án.
• Chạy quét lỗ hổng trong CI, không chỉ cục bộ, và theo lịch trình.
• Sử dụng lockfiles một cách nghiêm ngặt với xác minh hash nếu có thể.
• Kiểm toán cây dependency của bạn — xóa những thứ bạn không cần.
• Tự động hóa cập nhật với Renovate hoặc Dependabot.
• Cố định các hành động CI của bạn vào các commit SHA cụ thể, không phải thẻ (tags có thể bị force-push).

Bảo mật dependency không phải là công việc hào nhoáng. Không ai sẽ tweet về cấu hình Renovate hoàn hảo của bạn. Nhưng sự thay thế là phát hiện ra lỗ hổng của mình theo cách khó khăn nhất — từ một nhà nghiên cứu bảo mật nếu bạn may mắn, hoặc từ một kẻ tấn công nếu không.