Một lệnh npm install không chỉ tải tên package và số phiên bản. Máy developer, CI runner hoặc coding agent còn lấy metadata, tarball và có thể chạy preinstall/postinstall trước khi ứng dụng được mở. GitHub Package Firewall chen vào đúng đường tải đó: request đi qua một registry proxy của enterprise, được so với policy rồi mới tới npm registry.
GitHub công bố tính năng này ngày 20/10/2026 dưới dạng public preview cho GitHub Enterprise Cloud, kể cả gói có data residency. Hiện firewall chỉ hỗ trợ npm và miễn phí trong giai đoạn preview; khi GA, GitHub nói sẽ tính theo lượng dùng tương tự Actions nhưng chưa công bố đơn giá. Bài này đối chiếu changelog và tài liệu công khai lúc 15:00 ngày 21/10. Môi trường viết bài không có entitlement Enterprise, nên phần dưới là hướng dẫn đánh giá và rollout, không phải review kết quả block/allow trên tài khoản thật.
Mục lục [Hiển thị]
- Package Firewall nằm ở đâu trong một lần cài?
- Năm policy mặc định thực sự kiểm gì?
- Cooldown mua thời gian, không mua sự chắc chắn
- Cấu hình npm mà không lộ token
- Pilot nhỏ trước khi áp cho toàn enterprise
- Khi bị chặn, ngoại lệ phải có owner
- Firewall không thay lockfile, Dependabot hay sandbox
- Ai nên thử và ai nên chờ?
Package Firewall nằm ở đâu trong một lần cài?
Theo thông báo GitHub, firewall đứng giữa endpoint và upstream package registry. Cả request metadata lẫn package download đều đi qua lớp này. Enterprise admin đặt policy ở phía GitHub; máy developer, runner và agent phải đổi registry để traffic thực sự đi qua firewall.
Điểm quan trọng nằm ở vế sau. Nếu một job vẫn trỏ thẳng tới registry.npmjs.org, policy không tự bay tới bảo vệ nó. Với Artifactory, tài liệu còn yêu cầu loại các remote kéo trực tiếp từ public npm registry khỏi virtual repository, nếu không sẽ tạo một đường bypass rất đẹp trên sơ đồ và rất dở ngoài đời.
Firewall vì thế không phải antivirus chạy trên mọi máy, cũng không phải runtime sandbox. Nó quyết định package nào được tải qua endpoint đã cấu hình. Code nội bộ, package lấy từ Git URL, file tarball riêng hoặc một registry không đi qua proxy vẫn cần lớp kiểm soát khác.
Năm policy mặc định thực sự kiểm gì?
GitHub Docs liệt kê năm nhóm kiểm soát. “On” không có nghĩa chúng phát hiện mọi tình huống xấu; nó chỉ mô tả policy mặc định cho request đã đi qua firewall.
| Policy | Mặc định | Chặn khi | Chỗ dễ hiểu nhầm |
|---|---|---|---|
| Known malware | On | Package khớp malware advisory đang active trong GitHub Advisory Database | Không phải quét hành vi package trên máy |
| Vulnerability advisory | Critical only | Phiên bản bị advisory từ ngưỡng severity đã chọn | Có thể đặt High, Medium hoặc Any severity |
| Attestation downgrade | On | Bản trước có SLSA attestation nhưng bản được yêu cầu không còn | Mất attestation là tín hiệu cần xem, chưa tự chứng minh có malware |
| Install script mới | On | Package vừa thêm script chạy lúc cài như preinstall hoặc postinstall | Script hợp lệ vẫn có thể cần ngoại lệ sau review |
| Minimum package age | 1 ngày | Phiên bản mới hơn khoảng cooldown | Có thể đặt 0 hoặc 1–365 ngày; hết cooldown không đồng nghĩa đã an toàn |
Cooldown mua thời gian, không mua sự chắc chắn
Minimum package age dễ tạo cảm giác “qua một ngày là sạch”. Thực tế, policy chỉ trì hoãn phiên bản mới để cộng đồng và hệ thống phát hiện có thêm thời gian quan sát. Một package có thể không bị phát hiện trong ngày đầu, hoặc chỉ trở nên đáng ngờ khi kết hợp với môi trường cụ thể. Vì vậy cooldown nên là một lớp giảm rủi ro, không phải dấu kiểm an toàn.
Mặt trái cũng khá rõ: một hotfix bảo mật vừa phát hành có thể bị chính cooldown chặn. GitHub lấy tình huống này làm ví dụ cho exception flow. Khi pilot, team cần xác định trước ai duyệt bản vá khẩn, cần bằng chứng gì và ngoại lệ tồn tại bao lâu; đợi tới lúc production cháy mới bàn sẽ hơi “tới công chuyện”.
Cấu hình npm mà không lộ token
Tài liệu hiện dùng registry dạng https://package-firewall.githubapp.com/npm/enterprises/ENTERPRISE. Mỗi request cần token của user hoặc bot là thành viên enterprise. GitHub ghi token không cần quyền cao hơn mức read-only với public repositories, nhưng nó vẫn là credential và phải nằm trong secret store, không commit vào repository hay chụp nguyên màn hình cấu hình.
registry=https://package-firewall.githubapp.com/npm/enterprises/ENTERPRISE
//package-firewall.githubapp.com/npm/enterprises/ENTERPRISE/:_authToken=${GITHUB_TOKEN}Đoạn trên dùng đúng placeholder công khai, không phải cấu hình tài khoản thật. Với CI, nên đặt registry ở phạm vi job hoặc runner pilot, dùng bot riêng và redaction log. Với máy cá nhân, GitHub hướng dẫn file .npmrc cấp user; trước khi đổi, lưu lại giá trị registry cũ để rollback. Đừng ghi token trực tiếp bằng một lệnh có thể lọt vào shell history.
Pilot nhỏ trước khi áp cho toàn enterprise
Một pilot hữu ích không cần package đáng ngờ. Chọn một repository npm vô hại có lockfile ổn định, runner disposable và một tập package/version đã biết. Mục tiêu vòng đầu là chứng minh ba việc: request thật sự đi qua endpoint mới, build bình thường vẫn chạy, và team biết rollback khi registry hoặc policy gây gián đoạn.
- Ghi snapshot policy và owner trước khi thay đổi; không chỉ chụp giao diện rồi quên ai chịu trách nhiệm.
- Chọn 1–2 pipeline ít rủi ro, cố định lockfile và cache key. Xóa hoặc tách cache cũ để tránh kết luận “firewall cho qua” khi package thực tế được lấy từ cache.
- Đặt registry qua secret/runner config, xác nhận log đã redaction và chạy install package hợp lệ.
- Theo dõi thời gian cài, lỗi network, package bị chặn và đường xin exception. Không tạo malware mẫu hoặc cài typosquat để biểu diễn.
- Khôi phục registry cũ bằng một thay đổi có kiểm soát, rồi mới mở rộng theo nhóm runner hoặc repository.
Bài pin dependency trong GitHub Actions giải quyết lớp “đã chọn phiên bản nào”; firewall thêm lớp “phiên bản đó có được tải lúc này hay không”. Hai lớp bổ sung nhau chứ không thay thế nhau.
Khi bị chặn, ngoại lệ phải có owner
Khi policy chặn package, npm output hoặc log CI có thể đưa URL tạo bypass request. Form gồm repository, ecosystem, package, version, lý do và comment. Enterprise administrator hoặc enterprise security manager review; người có custom role phù hợp cũng có thể được cấp quyền quản lý policy.
GitHub cho phép đổi version/range thành *, nhưng chính docs cảnh báo thao tác này mở rộng ngoại lệ ra ngoài phiên bản được yêu cầu. Mặc định tốt hơn là scope hẹp theo version/range cần dùng, kèm link tới upstream release, advisory hoặc diff install script. Team cũng nên đặt lịch review các approval cũ vì bypass đã được duyệt sẽ được thêm vào policy cho tới khi bị gỡ.
Quy trình này giống một control plane hơn là nút “bỏ chặn cho xong”. Phân quyền phê duyệt, bằng chứng và thời hạn nên được viết trước. Nếu pipeline security fix có SLA 30 phút nhưng chỉ một admin ở múi giờ khác được duyệt, công nghệ không phải nút thắt chính.
Firewall không thay lockfile, Dependabot hay sandbox
Mỗi lớp trả lời một câu hỏi khác. Lockfile cố định dependency đã chọn. Dependabot và advisory giúp phát hiện, theo dõi rồi cập nhật phiên bản có vấn đề. Package Firewall áp policy ngay trên đường download. Sandbox và permission giới hạn hậu quả nếu code đã chạy. Review provenance hoặc source giúp trả lời package có đến từ quy trình tin cậy hay không.
Trong CI, chặn workflow đáng ngờ vẫn cần thiết vì package chỉ là một đầu vào. Với coding agent, security review trước commit cũng không nhìn cùng thời điểm với registry proxy. Ghép các lớp theo threat model sẽ thực tế hơn việc gọi bất kỳ sản phẩm nào là tường thành cuối cùng.
Ai nên thử và ai nên chờ?
Package Firewall đáng pilot nếu team đã dùng GitHub Enterprise Cloud, có nhiều npm runner/agent, quản lý được registry tập trung và sẵn sàng vận hành exception flow. Public preview đang miễn phí, nhưng vẫn nên đo số request, thời gian cài và nhu cầu bypass để chuẩn bị cho mô hình tính phí theo usage khi GA.
Nên chờ nếu team chưa dùng Enterprise Cloud, workload chính là Composer/PyPI, hoặc chưa kiểm soát được đường registry trực tiếp. Artifactory đã có hướng dẫn nhưng còn experimental. Ngoài ra, feature preview có thể đổi endpoint, policy hoặc behavior; hãy đọc lại docs trước mỗi rollout, không copy cấu hình trong bài này rồi để nguyên nhiều tháng.
Kết luận ngắn: firewall có giá trị nhất khi nó biến một lần cài package thành quyết định policy có owner, evidence và đường ngoại lệ. Bắt đầu bằng pilot nhỏ, giữ rollback rõ, scope bypass hẹp và tiếp tục duy trì lockfile, advisory, sandbox cùng review. Nếu traffic vẫn lách qua registry khác, năm policy đẹp đến mấy cũng chỉ đứng nhìn.
