Astral đang phát triển các công cụ mà hàng triệu nhà phát triển trên toàn thế giới phụ thuộc vào (Ruff, uv, ty), và gần đây, nhân dịp các vụ tấn công chuỗi cung ứng nhằm vào Trivy và LiteLLM, công ty đã công khai cách mình thực hành bảo mật. Độc giả mục tiêu gồm ba nhóm: người dùng, các maintainer mã nguồn mở khác và nhà phát triển hệ thống CI/CD.
1. Bảo mật CI/CD
Các mặc định bảo mật của GitHub Actions khá yếu, và các sự cố xâm nhập như Ultralytics, tj-actions, Nx đều bắt nguồn từ những trigger rủi ro như pull_request_target. Cách Astral ứng phó như sau:
Cấm hoàn toàn các trigger nguy hiểm
Cấm trên toàn bộ tổ chức các trigger gần như không thể dùng an toàn như pull_request_target và workflow_run. Phần lớn dự án nghĩ rằng mình cần các trigger này, nhưng trên thực tế, đa số trường hợp chỉ cần trigger pull_request với quyền hạn thấp hơn hoặc log workflow đơn giản là đủ.
Ghim hash commit cho action (Hash Pinning)
Thay vì dùng tag hoặc branch (có thể thay đổi), Astral ghim vào commit SHA cụ thể và đối chiếu chéo để xác minh commit đó thật sự khớp với trạng thái release, nhằm ngăn chặn “commit mạo danh”. Công ty dùng kết hợp zizmor và chính sách gốc của GitHub, đồng thời áp dụng ghim hash cho cả các action lồng nhau được gọi gián tiếp.
Nguyên tắc đặc quyền tối thiểu
Ở cấp tổ chức, quyền mặc định được đặt là chỉ đọc, và mọi workflow đều bắt đầu với permissions: {}, sau đó chỉ bổ sung quyền cần thiết ở cấp job. Secret cũng được cô lập theo từng môi trường triển khai thay vì đặt ở cấp tổ chức hoặc repository, để các job kiểm thử không thể truy cập secret dùng cho phát hành.
2. Bảo mật repository và tổ chức
Astral giảm tối đa số lượng tài khoản quản trị hoặc có đặc quyền cao; đa số thành viên trong tổ chức chỉ có quyền đọc/ghi đối với các repository mà họ cần. 2FA cũng được yêu cầu ở mức mạnh hơn mặc định của GitHub (bất kỳ phương thức nào), tối thiểu phải là TOTP, và trong tương lai công ty dự định siết tiếp theo hướng chỉ cho phép WebAuthn·passkey.
Nhánh main được áp dụng quy tắc bảo vệ: không cho force push, bắt buộc pull request, và tag release chỉ được tạo sau khi triển khai thành công. Đặc biệt, các quy tắc này được áp đặt ở cấp tổ chức để ngay cả quản trị viên repository cũng không thể vượt qua.
3. Tự động hóa (sử dụng GitHub App)
Những việc không thể làm an toàn trong GitHub Actions, chẳng hạn để lại bình luận trên PR từ bên thứ ba, sẽ được tách sang GitHub App astral-sh-bot. Tuy vậy, Astral cũng nhấn mạnh rằng GitHub App không phải là không có lỗ hổng, và nếu cần chạy mã không đáng tin cậy thì bắt buộc phải dùng trigger pull_request.
4. Bảo mật phát hành
Với PyPI·crates.io·NPM, Astral dùng Trusted Publishing để phát hành mà không cần thông tin xác thực dài hạn; còn với binary và image Docker, công ty đính kèm attestation dựa trên Sigstore để tạo liên kết mật mã giữa artifact phát hành và workflow.
Astral dùng tính năng immutable releases của GitHub để ngăn việc chỉnh sửa hậu kỳ đối với các bản build đã công khai, đồng thời cấm dùng cache trong quá trình build phát hành để chặn các cuộc tấn công cache poisoning.
Bản thân quy trình phát hành cũng được bảo vệ hai lớp: việc kích hoạt môi trường release cần có phê duyệt thủ công từ ít nhất 1 thành viên có quyền khác trong tổ chức. Nghĩa là để tạo một bản phát hành độc hại, kẻ tấn công phải đồng thời chiếm đoạt hai tài khoản đều có 2FA mạnh.
5. Bảo mật phụ thuộc
Astral quản lý cập nhật phụ thuộc và cảnh báo lỗ hổng đã biết bằng Dependabot·Renovate, đồng thời vận hành thêm chính sách “cooldown” không cập nhật ngay lập tức sau khi có release mới. Mục đích là để giảm thiểu tác động nếu một dependency vừa bị xâm phạm tạm thời. uv đã tích hợp sẵn tính năng này.
Công ty cũng duy trì kết nối xã hội với các dự án và nhóm làm việc lân cận như Python Packaging Authority (PyPA) và Python Security Response Team để chia sẻ thông tin, chẳng hạn khi một vấn đề được báo cáo cho pip cũng có thể ảnh hưởng đến uv. Việc thêm dependency mới được tiếp cận rất thận trọng, tránh các dependency chứa binary blob và vô hiệu hóa các tính năng không cần thiết.
Để hỗ trợ tính bền vững của các dự án mà mình phụ thuộc, Astral cũng tiếp tục đóng góp tài chính thông qua OSS Fund.
Tóm tắt các khuyến nghị cốt lõi
Bốn nguyên tắc cốt lõi mà Astral nhấn mạnh là: nhận thức rõ giới hạn của CI/CD và mạnh dạn từ bỏ những việc không thể làm an toàn hoặc tách chúng sang GitHub App; loại bỏ thông tin xác thực dài hạn khi có thể và cô lập chúng trong phạm vi tối thiểu; tăng cường quy trình phát hành bằng môi trường triển khai, phê duyệt và tag bất biến; đồng thời liên tục nắm bắt tình trạng sức khỏe của toàn bộ cây phụ thuộc.
Hàm ý
Nếu nhìn từ góc độ đang tham gia sâu vào PyPI và bảo mật chuỗi cung ứng, bài viết này vượt ra ngoài phạm vi một hướng dẫn bảo mật đơn thuần để trở thành một ví dụ thực chiến về cách thiết kế cấu trúc niềm tin cho toàn bộ hệ sinh thái mã nguồn mở. Đặc biệt, Trusted Publishing, chính sách cooldown và quy trình phát hành với phê duyệt kép là những điểm đáng tham khảo đối với các dự án mã nguồn mở có quy mô.
Nguồn gốc bài viết: Astral Blog, 2026.04.08
Chưa có bình luận nào.