- Astral, công ty phát triển các công cụ như Ruff, uv, ty được các lập trình viên trên toàn thế giới sử dụng, luôn coi tính bảo mật và độ tin cậy của mọi sản phẩm là giá trị cốt lõi
- Trước tình trạng các cuộc tấn công chuỗi cung ứng gia tăng gần đây, công ty đã công bố các kỹ thuật nội bộ nhằm tăng cường bảo mật cho toàn bộ quy trình build, triển khai và phát hành
- Trong quy trình CI/CD dựa trên GitHub Actions, Astral áp dụng hệ thống bảo vệ nhiều lớp như ghim hash, đặc quyền tối thiểu, tách biệt thông tin bí mật
- Ở giai đoạn phát hành, công ty đảm bảo tính toàn vẹn của phân phối bằng Trusted Publishing, Sigstore attestations, Immutable Releases
- Thông qua cách tiếp cận này, Astral hướng tới nâng cao mức độ bảo mật cho toàn bộ hệ sinh thái mã nguồn mở và xây dựng cơ chế phòng vệ bền vững
Cách tiếp cận bảo mật mã nguồn mở của Astral
- Astral phát triển các công cụ như Ruff, uv, ty được hàng triệu lập trình viên trên toàn thế giới sử dụng, và luôn giữ tính bảo mật cùng độ tin cậy của những công cụ này là giá trị cốt lõi
- Khi các cuộc tấn công chuỗi cung ứng gia tăng, như các vụ xâm nhập Trivy và LiteLLM gần đây, Astral đã công bố các kỹ thuật bảo mật nội bộ để bảo đảm an toàn cho công cụ của mình cũng như quy trình build và triển khai
- Công ty chia sẻ các thực tiễn bảo mật tốt nhất để người dùng, người duy trì mã nguồn mở và nhà phát triển hệ thống CI/CD đều có thể tham khảo
Bảo mật CI/CD
- Astral tự động hóa phát triển và triển khai thông qua quy trình CI/CD quy mô lớn dựa trên GitHub Actions, đồng thời coi đây là thành phần cốt lõi của bảo mật
- Giúp việc build và kiểm thử được thực hiện trong môi trường có kiểm soát và có thể quan sát, thay vì môi trường cục bộ
- Nhận thức rằng cấu hình bảo mật mặc định của GitHub Actions còn yếu, công ty đã triển khai các biện pháp tăng cường sau
- Cấm hoàn toàn các trigger nguy hiểm như
pull_request_target, workflow_run
- Ghim mọi action vào một commit hash (SHA) cụ thể và đối chiếu chéo xem có phải impostor commit hay không
- Áp dụng song song công cụ kiểm tra
unpinned-uses, impostor-commit của zizmor cùng với chính sách GitHub
- Ghim hash toàn bộ đồ thị phụ thuộc, bao gồm cả các action phụ thuộc gián tiếp không thể ghim hash trực tiếp
- Vì chỉ ghim hash thôi vẫn chưa đủ, Astral còn phát hiện lỗi về tính bất biến thông qua rà soát thủ công, và khi cần sẽ phối hợp với dự án thượng nguồn để sửa
- Ví dụ: ánh xạ URL tải binary và hash để nhúng ở trạng thái bất biến
- Quyền của workflow được giới hạn ở chế độ chỉ đọc theo mặc định, và chỉ cấp quyền tối thiểu cần thiết cho từng job
- GitHub Secrets được quản lý bằng biến môi trường triển khai tách biệt theo từng môi trường, để các tác vụ test và lint không thể truy cập thông tin bí mật của bản phát hành
- Các công cụ phụ trợ được dùng gồm zizmor (phân tích tĩnh) và pinact (tự động ghim hash)
Bảo mật kho mã và tổ chức
- Astral giảm tối đa số tài khoản có quyền quản trị trong tổ chức, và phần lớn thành viên chỉ có quyền đọc/ghi với các kho cần thiết
- Tất cả thành viên đều phải dùng xác thực hai yếu tố (2FA) mạnh, tối thiểu ở mức TOTP
- Nếu GitHub chỉ cho phép các phương thức chống phishing như WebAuthn hoặc Passkeys, công ty sẽ chuyển đổi ngay
- Quy tắc bảo vệ nhánh được áp dụng trên toàn tổ chức
- Nhánh
main không cho phép force push, mọi thay đổi chỉ có thể thực hiện qua PR
- Cấm tạo các mẫu nhánh cụ thể như
advisory-*, internal-*
- Quy tắc bảo vệ tag bảo đảm chỉ có thể tạo tag sau khi phát hành thành công
- Cấm sửa hoặc xóa tag, và chỉ cho phép phát hành từ nhánh
main
- Ngay cả quản trị viên kho cũng không thể vượt qua các quy tắc bảo vệ; mọi bảo vệ đều được cưỡng chế ở cấp tổ chức
- Astral đã công bố bộ quy tắc này dưới dạng gist để các dự án khác có thể tham khảo
Tự động hóa
- Chỉ với GitHub Actions thì không thể an toàn thực hiện một số tác vụ như để lại bình luận trên PR từ bên thứ ba
- Để xử lý việc này, Astral dùng GitHub App astral-sh-bot để xử lý sự kiện an toàn bên ngoài Actions
- GitHub App nhận cùng dữ liệu sự kiện, nhưng chạy trong môi trường tách biệt giữa mã và dữ liệu
- Tuy vậy, App không tự động loại bỏ thông tin xác thực nhạy cảm
- Vì vẫn có thể tồn tại các lỗ hổng như SQLi hay prompt injection, nên cần phát triển nó với mức độ bảo mật tương đương phần mềm thông thường
- Việc dùng App không đồng nghĩa với việc bảo đảm an toàn khi chạy mã không đáng tin cậy
- Cách dùng GitHub App có lợi hơn về mặt bảo mật nhưng làm tăng độ phức tạp
- Cần phát triển và tự lưu trữ App, nên có thể là gánh nặng với cá nhân hoặc dự án nhỏ
- Framework Gidgethub cho Python giúp đơn giản hóa việc phát triển
- Astral có kế hoạch mở mã nguồn astral-sh-bot, đồng thời khuyến nghị tham khảo hướng dẫn của Mariatta
Bảo mật phát hành
- Các công cụ của Astral được phân phối qua nhiều kênh ngoài GitHub như PyPI, Homebrew, Docker image
- Để ngăn chặn tấn công chuỗi cung ứng, công ty áp dụng các biện pháp sau
- Dùng Trusted Publishing để loại bỏ thông tin xác thực registry
-
Tạo attestations dựa trên Sigstore để bảo đảm mối liên kết mật mã giữa sản phẩm build và workflow
- Dùng tính năng Immutable Releases của GitHub để ngăn chỉnh sửa sau khi phát hành
- Không dùng build cache để chặn các cuộc tấn công làm ô nhiễm cache
- Quy trình phát hành được cô lập trong deployment environment chuyên dụng
- Khi kích hoạt môi trường phát hành, cần có phê duyệt từ thành viên khác trong nhóm, nhằm ngăn bản phát hành độc hại do chiếm đoạt một tài khoản đơn lẻ
- Duy trì phê duyệt nhiều bước bằng môi trường
release-gate và cơ chế chuyển tiếp phê duyệt dựa trên GitHub App
- Chỉ có thể tạo tag sau khi phát hành thành công
- Trình cài đặt độc lập (standalone installer) kiểm tra tính toàn vẹn của binary bằng checksum được nhúng sẵn
- Sau phát hành, các việc như cập nhật tài liệu, version manifest, pre-commit hook được thực hiện bằng tài khoản bot chuyên dụng và PAT phân quyền chi tiết
- Trong tương lai sẽ bổ sung ký mã cho macOS và Windows
Bảo mật phụ thuộc
- Astral sử dụng Dependabot và Renovate để quản lý cập nhật phụ thuộc và cảnh báo lỗ hổng
- Thiết lập khoảng cooldown để trì hoãn cập nhật ngay sau khi có bản phát hành mới, giúp giảm rủi ro từ các cuộc tấn công chuỗi cung ứng ngắn hạn
- Renovate hỗ trợ cấu hình cooldown theo từng nhóm, và công ty áp dụng nới lỏng cho các phụ thuộc do chính họ quản lý
- Công ty hợp tác liên tục và đóng góp về bảo mật cho các dự án thượng nguồn quan trọng
- Astral cũng hợp tác với Python Packaging Authority, Python Security Response Team để chia sẻ thông tin bảo mật
- Xem xét thận trọng khi thêm phụ thuộc mới, đồng thời thúc đẩy loại bỏ các phụ thuộc không cần thiết
- Đặc biệt tránh các phụ thuộc chứa binary blob, và vô hiệu hóa các tính năng không cần thiết
- Công ty hỗ trợ tài chính cho các dự án mã nguồn mở cốt lõi thông qua OSS Fund
Kết luận và bài học chính
- Bảo mật mã nguồn mở là tổ hợp của các vấn đề kỹ thuật và xã hội, nên cần ứng phó liên tục
- Những nguyên tắc chính mà Astral nhấn mạnh
- Nhận thức giới hạn của CI/CD, và khi bắt buộc thì dùng phương thức cô lập bên ngoài như GitHub App
- Loại bỏ và giảm thiểu thông tin xác thực dài hạn, tận dụng Trusted Publishing và xác thực OIDC
- Tăng cường quy trình phát hành, áp dụng quy tắc phê duyệt, tag, nhánh và Immutable Release
- Duy trì nhận thức về phụ thuộc, đồng thời dùng công cụ và hợp tác để cùng nâng cao bảo mật cho dự án thượng nguồn
- Astral sẽ tiếp tục đánh giá và cải tiến các kỹ thuật này, đồng thời phát triển hệ thống phòng vệ theo sự thay đổi của hành vi tấn công
Tóm tắt chú thích
- PEP 740 của PyPI cho phép tải lên attestations, nhưng hiện vẫn chưa tương thích với cách triển khai Trusted Publishing của Astral nên đang chờ áp dụng
- Checksum trong script cài đặt có hiệu quả hạn chế khi chạy trực tiếp bằng
curl ... | bash, nhưng hữu ích khi vendor trong CI/CD
1 bình luận
Ý kiến trên Hacker News
Có vẻ như phải qua quá nhiều bước mới có thể dùng CI của GitHub một cách an toàn
Với cấu trúc như vậy, tôi nghĩ gần như không thể vận hành an toàn về mặt bảo mật
Cảm giác như không thể xây dựng bảo mật chuỗi cung ứng trên một hệ thống mà ngay cả những nguyên tắc cơ bản như phân tách quyền hạn hay cô lập cũng không được tuân thủ
Nhưng cấu hình quá tinh vi nên không có vẻ là một cách tiếp cận có thể mở rộng. Nếu các thiết lập mặc định an toàn hơn thì mọi thứ sẽ tốt hơn nhiều
Đọc xong bài viết thì tôi lại nghĩ có khi sự phức tạp này là vấn đề mang tính bản chất của lĩnh vực này
Phần lớn không hỗ trợ bản phát hành bất biến, mà kể cả có hỗ trợ thì cấu trúc tự động kéo phiên bản mới về cũng khiến chúng dễ bị tấn công
Muốn thực sự an toàn thì phải quản lý các dependency đã được xác minh với phiên bản cố định trong registry nội bộ, nhưng đó gần như chỉ là việc Google mới làm nổi
Binary uv do đội chúng tôi tạo ra trong stagex là bản duy nhất trên thế giới được build bằng bootstrap hoàn toàn từ mã nguồn và artifact xác định có đa chữ ký
Nó sử dụng cơ chế ký dựa trên smartcard được kết nối với một mạng lưới tin cậy 25 năm tuổi và hơn 5000 khóa
Điều khiến tôi bức bối là các tình nguyện viên lại đang làm bảo mật chuỗi cung ứng nghiêm túc hơn
Dù những công cụ như OpenClaw có thể làm lộ khóa và bí mật, người dùng vẫn tiếp tục dùng chúng
Bạn đang cố giảm bề mặt tấn công, còn thị trường thì lại đang mở rộng nó ra
Nếu không có tình nguyện viên thì những dự án như Debian cũng đã không tồn tại. Thay vì phàn nàn, hãy cạnh tranh bằng kết quả tốt hơn
Nếu rốt cuộc bạn vẫn cung cấp artifact do bên thứ ba build ra thì mô hình đe dọa là gì vẫn chưa rõ
Tất cả bản build của uv đều đến từ độ phân giải đã khóa và cung cấp artifact có chữ ký. Giá trị của các commit được ký bởi một tập danh tính khác là điều chưa rõ ràng
Không có lý do gì để OpenAI phải bỏ tiền ra tăng cường bảo mật chuỗi cung ứng
Tôi hiểu các chỉ trích về mặt kỹ thuật, nhưng xét về thời điểm thì khó mà quy trách nhiệm cho OpenAI
Nhân tiện, Trusted Publishing của PyPI là do William Woodruff và đội Trail of Bits cùng triển khai
Tôi muốn hỏi đội Astral rằng họ quản lý thế nào khi đã nỗ lực đến mức này mà vẫn phụ thuộc khá nhiều vào chính GitHub
Nếu GitHub bị hack hoặc cấu hình bị thay đổi do lỗi thì họ sẽ ứng phó thế nào?
Hệ sinh thái mã nguồn mở rất bền bỉ, nhưng sandboxing cho mã của bên thứ ba vẫn còn thiếu
Mỗi lần dùng uv, người ta thường nhấn mạnh ưu điểm dễ quản lý nhiều phiên bản Python, nhưng điều đó cũng có nghĩa là nó chạy trên máy host mà không có cô lập, và điều đó khiến tôi lo ngại
Vấn đề lớn hiện nay của chuỗi cung ứng là nhiều công cụ và dependency được tải xuống mà không có xác minh nguồn gốc
Vì vậy tôi đang phát triển asfaload, một giải pháp xác thực tệp đa chữ ký, mã nguồn mở
Đây là kiểu cấu trúc có thể ngăn những sự cố như axios
Dù có ghim GitHub Actions theo commit SHA thì vẫn còn rủi ro nếu action đó kéo thêm dependency khác
Giải pháp thực sự là tự sở hữu trực tiếp mã trong pipeline CI hoặc fork rồi tự duy trì
Chúng tôi audit tất cả action, và nếu có dependency có thể thay đổi thì sẽ sửa hoặc thay thế chúng (tôi thuộc Astral)
Tự quản lý toàn bộ stack là an toàn nhất nhưng không thực tế
Ghim hash là một biện pháp tăng cường bảo mật gần như miễn phí
Cuối cùng, điều quan trọng là phải nhận thức rõ mình đang tin tưởng đến đâu
Nhìn vào các vụ việc gần đây của Trivy và litellm, có thể thấy hướng dẫn bảo mật cho quy trình phát hành thực sự rất cần thiết
Lời khuyên trong bài này mang tính thực tiễn và có thể áp dụng ngay
Cốt lõi của bảo mật chuỗi cung ứng phụ thuộc vào việc thiết lập mặc định của các nền tảng mà chúng ta dựa vào an toàn đến mức nào
Một bản tổng quan rất tuyệt. Có vẻ nó sẽ trở thành tài liệu tham khảo hữu ích cho nhiều dự án mã nguồn mở khác
Tôi đang duy trì
repomatic, một Python CLI đồng thời là công cụ workflow tái sử dụngNó mặc định bao gồm hầu hết các thực hành bảo mật trong bài này
Mục tiêu là tạo ra một môi trường nơi bảo mật là thiết lập mặc định
Sau khi đọc bài, tôi đã thêm kiểm tra chính sách phê duyệt PR cho fork
Xem chi tiết tại repository GitHub