Các cuộc tấn công vào chuỗi cung ứng phần mềm đang lợi dụng những lỗ hổng nào?

Tháng mười một 5, 2025
4:21 chiều

Tấn công chuỗi cung ứng đang khai thác những giả định của chúng ta

Mỗi khi bạn chạy lệnh `cargo add` hoặc `pip install`, bạn đang thực hiện một bước nhảy vọt của niềm tin. Bạn tin rằng mã bạn đang tải xuống chứa những gì bạn mong đợi, đến từ người bạn mong đợi và thực hiện những gì bạn mong đợi. Những kỳ vọng này rất cơ bản đối với sự phát triển hiện đại đến nỗi chúng ta hiếm khi nghĩ về chúng. Tuy nhiên, những kẻ tấn công đang khai thác một cách có hệ thống từng giả định này.

Chỉ riêng trong năm 2024, PyPI và npm đã xóa hàng nghìn gói độc hại; nhiều dự án nổi tiếng đã bị chèn phần mềm độc hại trực tiếp vào quy trình xây dựng; và backdoor XZ Utils suýt chút nữa đã lọt vào hàng triệu hệ thống Linux trên toàn thế giới.

Quét sự phụ thuộc chỉ phát hiện các lỗ hổng đã biết. Nó sẽ không phát hiện ra khi một gói bị lỗi chính tả đánh cắp thông tin đăng nhập của bạn, khi một người bảo trì bị xâm phạm xuất bản phần mềm độc hại hoặc khi những kẻ tấn công đầu độc chính đường dẫn xây dựng. Những cuộc tấn công này thành công vì chúng khai thác chính sự tin tưởng vốn làm cho phát triển phần mềm hiện đại trở nên khả thi.

Bài đăng này chia nhỏ các giả định tin cậy khiến chuỗi cung ứng phần mềm dễ bị tấn công, phân tích các cuộc tấn công gần đây khai thác chúng và nêu bật một số biện pháp phòng thủ tiên tiến đang được xây dựng trên khắp các hệ sinh thái để biến niềm tin ngầm thành các đảm bảo rõ ràng, có thể kiểm chứng.

Niềm tin ngầm

Đối với nhiều nhà phát triển, chuỗi cung ứng phần mềm bắt đầu và kết thúc bằng hóa đơn nguyên vật liệu phần mềm (SBOM) và quét sự phụ thuộc, cùng nhau trả lời hai câu hỏi cơ bản: bạn có mã gì và nó có chứa các lỗ hổng đã biết không? Nhưng hiểu những gì bạn có chỉ là mức tối thiểu. Khi các cuộc tấn công tinh vi trở nên phổ biến hơn, bạn cũng cần hiểu mã của bạn đến từ đâu và nó đến với bạn như thế nào.

Bạn tin rằng bạn đang cài đặt gói bạn mong đợi. Bạn cho rằng việc chạy `cargo add rustdecimal` là an toàn vì `rustdecimal` là một thư viện nổi tiếng và được sử dụng rộng rãi. Hoặc đợi đã, có lẽ nó được đánh vần là `rust_decimal`?

Bạn tin rằng các gói được xuất bản bởi những người bảo trì gói. Khi một gói phổ biến bắt đầu vận chuyển với một tệp nhị phân được biên dịch sẵn để tiết kiệm thời gian xây dựng, bạn có thể quyết định tin tưởng tác giả gói. Tuy nhiên, nhiều sổ đăng ký thiếu xác minh mạnh mẽ rằng nhà xuất bản là người mà họ tuyên bố.

Bạn tin rằng các gói được xây dựng từ mã nguồn gói. Bạn có thể làm việc trong một nhóm có ý thức về bảo mật, kiểm tra các thay đổi mã trong kho lưu trữ công khai trước khi nâng cấp các phụ thuộc. Nhưng điều này là vô nghĩa nếu gói được phân phối được xây dựng từ mã không xuất hiện trong kho lưu trữ.

Bạn tin tưởng chính những người bảo trì. Cuối cùng, cài đặt mã của bên thứ ba có nghĩa là tin tưởng những người bảo trì gói. Không thực tế khi kiểm tra mọi dòng mã mà bạn phụ thuộc vào. Chúng tôi cho rằng những người bảo trì các gói được thiết lập tốt và được áp dụng rộng rãi sẽ không đột nhiên quyết định thêm mã độc hại.

Những giả định này mở rộng ra ngoài trình quản lý gói truyền thống. Sự tin tưởng tương tự tồn tại khi bạn chạy hành động GitHub, cài đặt một công cụ bằng Homebrew hoặc thực thi tập lệnh cài đặt `curl … | bash` tiện lợi. Hiểu các mối quan hệ tin cậy ngầm này là bước đầu tiên trong việc đánh giá và giảm thiểu rủi ro chuỗi cung ứng.

Các cuộc tấn công gần đây

Những kẻ tấn công đang khai thác các giả định tin cậy trên mọi lớp của chuỗi cung ứng. Các sự cố gần đây từ việc giả mạo đơn giản đến các chiến dịch kéo dài nhiều năm, chứng minh cách các chiến thuật của kẻ tấn công đang phát triển và ngày càng phức tạp hơn.

Nhân đôi lừa đảo

Typosquatting liên quan đến việc xuất bản một gói độc hại có tên tương tự như tên của một gói hợp pháp. Chạy `cargo add rustdecimal` thay vì `rust_decimal` có thể cài đặt phần mềm độc hại thay vì thư viện hợp pháp dự kiến. Cuộc tấn công [chính xác này](https://blog.rust-lang.org/2022/05/10/malicious-crate-rustdecimal/) đã xảy ra trên crates.io vào năm 2022. `rustdecimal` độc hại bắt chước gói `rust_decimal` phổ biến nhưng chứa một hàm `Decimal::new` thực thi một tệp nhị phân độc hại khi được gọi.

Sự đơn giản của cuộc tấn công đã giúp những kẻ tấn công dễ dàng khởi động nhiều chiến dịch quy mô lớn, đặc biệt là chống lại PyPI và npm. Kể từ năm 2022, đã có nhiều chiến dịch typosquatting nhắm mục tiêu đến các gói chiếm tổng cộng [1,2 tỷ lượt tải xuống hàng tuần](https://blog.phylum.io/phylum-detects-active-typosquatting-campaign-targeting-npm-developers/). Hàng nghìn gói độc hại đã được xuất bản chỉ riêng cho PyPI và npm. Loại tấn công này xảy ra thường xuyên đến mức có quá nhiều ví dụ để liệt kê ở đây. Vào năm 2023, các nhà nghiên cứu đã ghi lại [một chiến dịch đã đăng ký 900 typosquat của 40 gói PyPI phổ biến](https://blog.phylum.io/a-pypi-typosquatting-campaign-post-mortem/) và phát hiện [phần mềm độc hại đang được dàn dựng trên crates.io](https://blog.phylum.io/rust-malware-staged-on-crates-io/). Các cuộc tấn công chỉ trở nên dữ dội hơn, với [500 gói độc hại được xuất bản](https://blog.phylum.io/typosquatting-campaign-targets-python-developers/) trong một chiến dịch năm 2024.

Dependency confusion tiếp cận theo một cách khác, khai thác trực tiếp logic của trình quản lý gói. Nhà nghiên cứu bảo mật Alex Birsan [đã chứng minh và đặt tên](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610) loại tấn công này vào năm 2021. Ông phát hiện ra rằng nhiều tổ chức sử dụng tên cho các gói nội bộ bị rò rỉ hoặc có thể đoán được. Bằng cách xuất bản các gói có cùng tên với các gói nội bộ này lên các sổ đăng ký công khai, Birsan đã có thể đánh lừa các trình quản lý gói tải xuống phiên bản của mình. Proof of concept của Birsan đã xác định các lỗ hổng trên ba ngôn ngữ lập trình và 35 tổ chức, bao gồm Shopify, Apple, Netflix, Uber và Yelp.

Vào năm 2022, một kẻ tấn công đã sử dụng kỹ thuật này để [bao gồm mã độc hại](https://pytorch.org/blog/compromised-nightly-dependency/) trong các bản phát hành hàng đêm của PyTorch trong năm ngày. Một phụ thuộc nội bộ có tên `torchtriton` đã được lưu trữ từ chỉ mục gói hàng đêm của PyTorch. Một kẻ tấn công đã xuất bản một gói độc hại có cùng tên lên PyPI, gói này được ưu tiên. Do đó, các phiên bản hàng đêm của PyTorch chứa phần mềm độc hại trong năm ngày trước khi phần mềm độc hại bị bắt.

Mặc dù các cuộc tấn công này xảy ra tại thời điểm cài đặt, nhưng các cuộc tấn công khác tiếp cận trực tiếp hơn bằng cách xâm phạm chính quy trình xuất bản.

Bí mật bị đánh cắp

Tài khoản bị xâm phạm là một vectơ tấn công thường xuyên khác. Những kẻ tấn công có được một khóa bị rò rỉ, mã thông báo bị đánh cắp hoặc mật khẩu bị đoán và có thể trực tiếp xuất bản mã độc hại thay mặt cho một thực thể đáng tin cậy. Một vài sự cố gần đây cho thấy quy mô của loại tấn công này:

ctrl/tinycolor (tháng 9 năm 2025): [Phần mềm độc hại tự lan truyền](https://www.stepsecurity.io/blog/ctrl-tinycolor-and-40-npm-packages-compromised) đã thu thập thông tin xác thực API npm và sử dụng thông tin xác thực để xuất bản các gói độc hại bổ sung. Hơn 40 gói đã bị xâm phạm, chiếm hơn 2 triệu lượt tải xuống hàng tuần.
Nx (tháng 8 năm 2025): Một mã thông báo bị xâm phạm cho phép những kẻ tấn công xuất bản [các phiên bản độc hại](https://github.com/nrwl/nx/security/advisories/GHSA-cxm3-wv7p-598c) chứa các tập lệnh tận dụng các công cụ AI CLI đã được cài đặt (Claude, Gemini, Q) để trinh sát, đánh cắp ví tiền điện tử, mã thông báo GitHub/npm và khóa SSH từ hàng nghìn nhà phát triển trước khi lọc dữ liệu vào kho lưu trữ GitHub công khai.
rand-user-agent (tháng 5 năm 2025): Một [bản phát hành độc hại chứa phần mềm độc hại](https://www.bleepingcomputer.com/news/security/supply-chain-attack-hits-npm-package-with-45-000-weekly-downloads/) chỉ bị bắt sau khi các nhà nghiên cứu nhận thấy các bản phát hành gần đây mặc dù không có thay đổi nào đối với mã nguồn trong nhiều tháng.
rspack (tháng 12 năm 2024): Mã thông báo npm bị đánh cắp cho phép những kẻ tấn công [xuất bản trình khai thác tiền điện tử](https://www.sonatype.com/blog/npm-packages-rspack-vant-compromised-blocked-by-sonatype) trong các gói với 500.000 lượt tải xuống hàng tuần kết hợp.
UAParser.js (tháng 10 năm 2021): Một mã thông báo npm bị xâm phạm đã được sử dụng để xuất bản các bản phát hành độc hại chứa trình khai thác tiền điện tử. Thư viện có hàng triệu lượt tải xuống hàng tuần vào thời điểm xảy ra cuộc tấn công.
Máy chủ PHP Git (tháng 3 năm 2021): Thông tin xác thực bị đánh cắp cho phép những kẻ tấn công [chèn backdoor trực tiếp vào mã nguồn của PHP](https://news-web.php.net/php.internals/113981). Rất may, nội dung của các thay đổi đã dễ dàng được phát hiện và loại bỏ bởi nhóm PHP trước bất kỳ bản phát hành nào.
Codecov (tháng 1 năm 2021): Những kẻ tấn công đã tìm thấy một khóa triển khai trong một lớp hình ảnh Docker công khai và sử dụng nó để [sửa đổi công cụ Bash Uploader của Codecov](https://about.codecov.io/apr-2021-post-mortem/), âm thầm lọc các biến môi trường và khóa API trong nhiều tháng trước khi phát hiện.

Bí mật bị đánh cắp vẫn là một trong những vectơ tấn công chuỗi cung ứng đáng tin cậy nhất. Nhưng khi các tổ chức triển khai xác thực mạnh mẽ hơn và quản lý bí mật tốt hơn, những kẻ tấn công đang chuyển từ việc đánh cắp khóa sang xâm phạm các hệ thống sử dụng chúng.

Đường ống bị nhiễm độc

Thay vì đánh cắp thông tin xác thực, một số kẻ tấn công đã tìm cách phân phối phần mềm độc hại thông qua các kênh hợp pháp bằng cách xâm phạm chính các hệ thống xây dựng và phân phối. Kiểm tra mã và các kiểm tra bảo mật khác bị bỏ qua hoàn toàn bằng cách chèn trực tiếp mã độc hại vào đường dẫn CI/CD.

Cuộc tấn công SolarWinds vào năm 2020 là một trong những cuộc tấn công nổi tiếng trong danh mục này. Những kẻ tấn công đã xâm phạm môi trường xây dựng và [chèn mã độc hại trực tiếp vào phần mềm Orion](https://www.solarwinds.com/blog/new-findings-from-our-investigation-of-sunburst) trong quá trình biên dịch. Phiên bản độc hại của Orion sau đó đã được ký và phân phối thông qua các kênh cập nhật hợp pháp của SolarWinds. Cuộc tấn công ảnh hưởng đến hàng nghìn tổ chức bao gồm nhiều công ty Fortune 500 và các cơ quan chính phủ.

Gần đây hơn, vào cuối năm 2024, một kẻ tấn công đã [xâm phạm đường dẫn xây dựng Ultralytics](https://blog.pypi.org/posts/2024-12-11-ultralytics-attack-analysis/) để xuất bản nhiều phiên bản độc hại. Kẻ tấn công đã sử dụng một mẫu chèn trong GitHub Actions của dự án để có được quyền truy cập vào đường dẫn CI/CD và đầu độc bộ nhớ cache GitHub Actions để bao gồm mã độc hại trực tiếp trong bản dựng. Vào thời điểm xảy ra cuộc tấn công, Ultralytics có hơn một triệu lượt tải xuống hàng tuần.

Vào năm 2025, một kẻ tấn công đã sửa đổi thẻ v1 của hành động `reviewdog/actions-setup` [để trỏ đến một phiên bản độc hại](https://www.wiz.io/blog/new-github-action-supply-chain-attack-reviewdog-action-setup) chứa mã để đổ bí mật. Điều này có thể dẫn đến việc xâm phạm một hành động phổ biến khác, `tj-actions/changed-files`, thông qua sự phụ thuộc của nó vào `tj-actions/eslint-changed-files`, đến lượt nó lại dựa vào hành động `reviewdog` bị xâm phạm. Sự xâm phạm tầng này đã ảnh hưởng đến hàng nghìn dự án sử dụng hành động `changed-files`.

Mặc dù các cuộc tấn công đường ống bị nhiễm độc tương đối hiếm so với giả mạo hoặc trộm cắp thông tin xác thực, nhưng chúng thể hiện sự leo thang về độ tinh vi của kẻ tấn công. Khi các biện pháp phòng thủ mạnh mẽ hơn được đưa ra, những kẻ tấn công buộc phải di chuyển lên chuỗi cung ứng. Những kẻ tấn công quyết tâm nhất sẵn sàng dành nhiều năm để chuẩn bị cho một cuộc tấn công duy nhất.

Người bảo trì độc hại

Backdoor XZ Utils, được phát hiện vào tháng 3 năm 2024, suýt chút nữa đã xâm phạm hàng triệu hệ thống Linux trên toàn thế giới. Kẻ tấn công đã dành hơn hai năm để đóng góp hợp pháp cho dự án trước khi có được quyền truy cập của người bảo trì. Sau đó, họ đã lạm dụng sự tin tưởng này để chèn một backdoor tinh vi thông qua một loạt các cam kết có vẻ vô hại sẽ cấp quyền truy cập từ xa vào bất kỳ hệ thống nào sử dụng phiên bản bị xâm phạm.

Cuối cùng, bạn phải tin tưởng những người bảo trì các phụ thuộc của mình. Đường dẫn xây dựng an toàn không thể bảo vệ chống lại một người bảo trì đáng tin cậy, người quyết định chèn mã độc hại. Với việc những người bảo trì mã nguồn mở ngày càng quá tải và với các công cụ AI giúp tạo ra các đóng góp thuyết phục ở quy mô lớn dễ dàng hơn, mô hình tin cậy này đang phải đối mặt với những thách thức chưa từng có.

Biện pháp phòng thủ mới

Khi các cuộc tấn công ngày càng tinh vi, những người bảo vệ đang xây dựng các công cụ để phù hợp. Các phương pháp tiếp cận mới này đang làm cho các giả định tin cậy trở nên rõ ràng và có thể kiểm chứng hơn là ngầm và có thể khai thác. Mỗi địa chỉ một lớp khác nhau của chuỗi cung ứng, nơi những kẻ tấn công đã tìm thấy thành công.

TypoGard và Typomania

Hầu hết các trình quản lý gói hiện nay đều bao gồm một số hình thức bảo vệ chống giả mạo, nhưng chúng thường sử dụng các kiểm tra tương tự truyền thống như các kiểm tra đo khoảng cách Levenshtein, tạo ra quá nhiều dương tính giả cần được xem xét thủ công.

[TypoGard](https://github.com/mt3443/typogard) lấp đầy khoảng trống này bằng cách sử dụng nhiều số liệu nhận biết ngữ cảnh, như sau, để phát hiện các gói typosquatting với tỷ lệ dương tính giả thấp và chi phí tối thiểu:

Các ký tự lặp lại (ví dụ: `rustdeciimal`)
Các lỗi chính tả phổ biến dựa trên bố cục bàn phím
Các ký tự được hoán đổi (ví dụ: `reqeusts` thay vì `requests`)
Ngưỡng mức độ phổ biến của gói để tập trung vào các mục tiêu có rủi ro cao

Công cụ này nhắm mục tiêu npm, nhưng các khái niệm có thể được mở rộng sang các ngôn ngữ khác. Rust Foundation đã xuất bản một cổng Rust, [Typomania](https://github.com/rustfoundation/typomania), đã được [crates.io](https://github.com/rust-lang/crates.io/tree/main/src/typosquat) chấp nhận và đã bắt thành công nhiều gói độc hại.

Zizmor

[Zizmor](https://github.com/zizmorcore/zizmor) là một công cụ phân tích tĩnh cho GitHub Actions. Các hành động có một bề mặt lớn và việc viết các quy trình làm việc phức tạp có thể khó khăn và dễ mắc lỗi. Có rất nhiều cách tinh tế mà quy trình làm việc có thể gây ra lỗ hổng.

Ví dụ: Ultralytics đã bị xâm phạm thông qua chèn mẫu trong một trong các quy trình làm việc của nó.

- name: Commit and Push Changes
  if: (... || github.event_name == 'pull_request_target' || ...
  run: |
      ...
      git pull origin ${{ github.head_ref || github.ref }}
      ...

Quy trình làm việc được kích hoạt bởi các sự kiện `pull_request_target` chạy với quyền truy cập ghi vào các bí mật của kho lưu trữ. Một kẻ tấn công [đã mở một yêu cầu kéo từ một nhánh có tên độc hại](https://blog.yossarian.net/2024/12/06/zizmor-ultralytics-injection). Khi quy trình làm việc chạy, biến `github.head_ref` đã mở rộng thành tên nhánh độc hại và được thực thi như một phần của lệnh chạy với các đặc quyền nâng cao của quy trình làm việc.

Cuộc tấn công `reviewdog/actions-setup` cũng được thực hiện một phần bằng cách thay đổi thẻ v1 của hành động để trỏ đến một cam kết độc hại. Bất kỳ ai sử dụng `reviewdog/actions-setup@v1` trong quy trình làm việc của họ đều âm thầm bắt đầu nhận được một phiên bản độc hại mà không thực hiện bất kỳ thay đổi nào đối với quy trình làm việc của riêng họ.

Zizmor gắn cờ tất cả những điều trên. Nó bao gồm một quy tắc kích hoạt nguy hiểm để gắn cờ quy trình làm việc được kích hoạt bởi `pull_request_target`, một quy tắc chèn mẫu và một kiểm tra `unpinned-uses` sẽ cảnh báo các hành động chống lại việc sử dụng các tham chiếu có thể thay đổi (như thẻ hoặc tên nhánh) khi sử dụng `reviewdog/actions-setup@v1`.

PyPI Trusted Publishing và chứng thực

PyPI đã thực hiện các bước quan trọng để giải quyết một số giả định tin cậy ngầm thông qua hai tính năng bổ sung: Trusted Publishing và chứng thực.

Trail of Bits đã làm việc với PyPI trên [Trusted Publishing](https://blog.trailofbits.com/2023/05/23/trusted-publishing-a-new-benchmark-for-packaging-security/)[1](https://blog.trailofbits.com/2025/09/24/supply-chain-attacks-are-exploiting-our-assumptions/#fn:1), loại bỏ nhu cầu về mã thông báo API tồn tại lâu dài. Thay vì lưu trữ các bí mật có thể bị đánh cắp, các nhà phát triển định cấu hình mối quan hệ tin cậy một lần: “kho lưu trữ và quy trình làm việc GitHub này có thể xuất bản gói này.” Khi quy trình làm việc chạy, GitHub sẽ gửi mã thông báo OIDC tồn tại ngắn đến PyPI với các tuyên bố về kho lưu trữ và quy trình làm việc. PyPI xác minh rằng mã thông báo này đã được ký bởi khóa của GitHub và phản hồi bằng mã thông báo PyPI tồn tại ngắn, mà quy trình làm việc có thể sử dụng để xuất bản gói. Sử dụng mã thông báo được tạo tự động, có phạm vi tối thiểu, tồn tại ngắn giúp giảm đáng kể rủi ro xâm phạm.

Nếu không có mã thông báo API tồn tại lâu dài và có đặc quyền quá mức, những kẻ tấn công thay vào đó phải xâm phạm chính quy trình làm việc GitHub xuất bản. Mặc dù cuộc tấn công Ultralytics đã chứng minh rằng sự xâm phạm đường dẫn CI/CD vẫn là một mối đe dọa thực sự, nhưng việc loại bỏ nhu cầu người dùng quản lý thông tin xác thực theo cách thủ công sẽ loại bỏ một nguồn lỗi của người dùng và giảm thêm bề mặt tấn công.

Dựa trên nền tảng này, Trail of Bits đã làm việc với PyPI một lần nữa để giới thiệu [chứng thực kỹ thuật số do chỉ mục lưu trữ](https://blog.trailofbits.com/2024/11/14/attestations-a-new-generation-of-signatures-on-pypi/) vào cuối năm 2024 thông qua PEP 740. Chứng thực liên kết mật mã mỗi gói đã xuất bản với nguồn gốc xây dựng của nó bằng Sigstore. Các gói sử dụng [hành động GitHub xuất bản PyPI](https://github.com/pypa/gh-action-pypi-publish) tự động bao gồm chứng thực, hoạt động như một bản ghi có thể kiểm chứng về chính xác nơi, khi nào và cách gói được xây dựng.

Hình 1: Chúng ta đã PEP 740 chưa?

Hơn 30.000 gói sử dụng Trusted Publishing và “[Chúng ta đã PEP 740 chưa?](https://trailofbits.github.io/are-we-pep740-yet/)” theo dõi việc áp dụng chứng thực trong số các gói phổ biến nhất (86 trong số 360 gói hàng đầu tại thời điểm viết bài). Mảnh ghép cuối cùng, xác minh phía máy khách tự động, vẫn là một công việc đang được tiến hành. Các công cụ máy khách như pip và uv vẫn chưa tự động xác minh chứng thực. Cho đến lúc đó, chứng thực cung cấp tính minh bạch và khả năng kiểm tra, nhưng không bảo vệ chủ động trong quá trình cài đặt gói.

Nguồn gốc xây dựng Homebrew

Các giả định tin cậy ngầm mở rộng ra ngoài ngôn ngữ lập trình và thư viện. Khi bạn chạy `brew install` để cài đặt một gói nhị phân (hoặc, một chai), bạn tin rằng chai bạn đang tải xuống được xây dựng bởi CI chính thức của Homebrew từ mã nguồn dự kiến và nó không được tải lên bởi một kẻ tấn công đã tìm cách xâm phạm lưu trữ chai của Homebrew hoặc bằng cách khác giả mạo nội dung của chai.

Trail of Bits, hợp tác với Alpha-Omega và OpenSSF, đã giúp thêm [nguồn gốc xây dựng vào Homebrew](https://blog.trailofbits.com/2024/05/14/a-peek-into-build-provenance-for-homebrew/) bằng cách sử dụng chứng thực của GitHub. Mỗi chai được xây dựng bởi Homebrew hiện đi kèm với bằng chứng mật mã liên kết nó với quy trình làm việc GitHub Actions cụ thể đã tạo ra nó. Điều này khiến cho một người bảo trì bị xâm phạm thay thế âm thầm các chai bằng các phiên bản độc hại trở nên khó khăn hơn đáng kể.

% brew verify --help
Usage: brew verify [options] formula [...]
Verify the build provenance of bottles using GitHub's attestation tools.
This is done by first fetching the given bottles and then verifying their provenance.

Mỗi chứng thực bao gồm cam kết Git, quy trình làm việc đã chạy và các siêu dữ liệu thời gian xây dựng khác. Điều này biến giả định tin cậy (“Tôi tin rằng chai này được xây dựng từ nguồn mà tôi mong đợi”) thành một sự thật có thể kiểm chứng.

Việc triển khai chứng thực đã xử lý các chai lịch sử thông qua một quy trình “điền lại”, tạo chứng thực cho các gói được xây dựng trước khi hệ thống được đưa ra. Do đó, tất cả các gói Homebrew chính thức đều bao gồm chứng thực.

Lệnh `brew verify` giúp dễ dàng kiểm tra nguồn gốc, mặc dù tính năng này vẫn đang ở giai đoạn beta và xác minh không tự động theo mặc định. Có kế hoạch cuối cùng sẽ mở rộng tính năng này sang các kho lưu trữ của bên thứ ba, mang lại các đảm bảo bảo mật tương tự cho hệ sinh thái Homebrew rộng lớn hơn.

Go Capslock

[Capslock](https://github.com/google/capslock) là một công cụ xác định tĩnh các khả năng của một chương trình Go, bao gồm những điều sau:

Các thao tác hệ thống tệp (đọc, ghi, xóa tệp)
Kết nối mạng (yêu cầu исходящие, lắng nghe trên cổng)
Thực thi quy trình (tạo quy trình con)
Truy cập biến môi trường
Sử dụng lệnh gọi hệ thống

% capslock --packages github.com/fatih/color
Capslock is an experimental tool for static analysis of Go packages.
Share feedback and file bugs at https://github.com/google/capslock.
For additional debugging signals, use verbose mode with -output=verbose
To get machine-readable full analysis output, use -output=jso`
Analyzed packages:
    github.com/fatih/color v1.18.0
    github.com/mattn/go-colorable v0.1.13
    github.com/mattn/go-isatty v0.0.20
    golang.org/x/sys v0.25.0
CAPABILITY_FILES: 1 references
CAPABILITY_READ_SYSTEM_STATE: 41 references
CAPABILITY_SYSTEM_CALLS: 1 references

Phương pháp này thể hiện một sự thay đổi trong bảo mật chuỗi cung ứng. Thay vì tập trung vào ai đã viết mã hoặc nó đến từ đâu, phân tích khả năng kiểm tra những gì mã thực sự có thể làm. Một thư viện phân tích cú pháp JSON bất ngờ có được quyền truy cập mạng sẽ ngay lập tức gióng lên hồi chuông cảnh báo, bất kể thay đổi đến từ một chuỗi cung ứng bị xâm phạm hay trực tiếp từ một người bảo trì.

Trong thực tế, việc phát hiện khả năng tĩnh có thể khó khăn. Các tính năng ngôn ngữ như phản ánh thời gian chạy và các thao tác không an toàn khiến việc phát hiện tĩnh các khả năng hoàn toàn chính xác là không thể. Mặc dù có những hạn chế, việc phát hiện khả năng cung cấp một mạng lưới an toàn quan trọng như một phần của biện pháp phòng thủ nhiều lớp chống lại các cuộc tấn công chuỗi cung ứng.

Capslock đã đi tiên phong trong phương pháp này cho Go và khái niệm này đã chín muồi để áp dụng trên các ngôn ngữ khác. Khi các cuộc tấn công chuỗi cung ứng ngày càng tinh vi, phân tích khả năng cung cấp một con đường đầy hứa hẹn phía trước. Xác minh những gì mã có thể làm, không chỉ nơi nó đến.

Chúng ta sẽ đi đâu từ đây

Các cuộc tấn công chuỗi cung ứng không chậm lại. Nếu có, chúng đang trở nên tự động hơn, phức tạp hơn và tinh vi hơn để nhắm mục tiêu đến đối tượng rộng hơn. Các chiến dịch typosquatting đang nhắm mục tiêu đến các gói có hàng tỷ lượt tải xuống, mã thông báo nhà xuất bản và đường dẫn CI/CD đang bị xâm phạm để đầu độc phần mềm tại nguồn và những kẻ tấn công kiên nhẫn đang dành nhiều năm để xây dựng danh tiếng trước khi tấn công.

Sự tin tưởng ngầm cho phép các hệ sinh thái phần mềm mở rộng quy mô đang bị vũ khí hóa chống lại chúng ta. Hiểu các giả định tin cậy của bạn là bước đầu tiên. Hãy tự hỏi bản thân những câu hỏi sau:

Hệ sinh thái của tôi có chặn các gói typosquatting không?
Nó bảo vệ chống lại mã thông báo nhà xuất bản bị xâm phạm như thế nào?
Tôi có thể xác minh nguồn gốc xây dựng không?
Tôi có biết những khả năng mà các phụ thuộc của tôi có không?

Một số hệ sinh thái đã bắt đầu xây dựng các biện pháp phòng thủ. Biết những công cụ nào có sẵn và bắt đầu sử dụng chúng ngay hôm nay. Sử dụng Trusted Publishing khi xuất bản [lên PyPI](https://docs.pypi.org/trusted-publishers/using-a-publisher/) hoặc [lên crates.io](http://crates.io). Kiểm tra GitHub Actions của bạn bằng [Zizmor](https://github.com/zizmorcore/zizmor). Sử dụng [It-Depends](https://github.com/trailofbits/it-depends) và [Deptective](https://github.com/trailofbits/deptective) để hiểu phần mềm thực sự phụ thuộc vào những gì. Xác minh chứng thực khi khả thi. Sử dụng [Capslock](https://github.com/google/capslock) để xem các khả năng của các gói Go và quan trọng hơn, hãy nhận thức được khi các khả năng mới được giới thiệu.

Nhưng không có hệ sinh thái nào được bao phủ hoàn toàn. Thúc đẩy các mặc định tốt hơn khi thiếu công cụ. Mỗi chứng thực đã được xác minh, mỗi gói bị bắt typosquatting và mỗi hành động GitHub dễ bị tấn công được gắn cờ làm cho toàn bộ ngành trở nên kiên cường hơn. Chúng ta không thể loại bỏ hoàn toàn sự tin tưởng khỏi chuỗi cung ứng, nhưng chúng ta có thể cố gắng làm cho sự tin tưởng đó trở nên rõ ràng, có thể kiểm chứng và có thể thu hồi.

Nếu bạn cần trợ giúp để hiểu các giả định tin cậy chuỗi cung ứng của mình, [hãy liên hệ với chúng tôi](https://www.trailofbits.com/contact/).

1. Nhóm [crates.io](http://crates.io) đã phát hành [Trusted Publishing cho Rust](https://blog.rust-lang.org/2025/07/11/crates-io-development-update-2025-07/#trusted-publishing) vào tháng Bảy. ↩︎

Giải thích thuật ngữ:

Chuỗi cung ứng phần mềm: Là quy trình mà phần mềm được tạo ra, từ mã nguồn đến khi được phân phối và sử dụng.
Typosquatting: Lợi dụng lỗi đánh máy của người dùng để tạo ra các gói phần mềm độc hại có tên gần giống với các gói phổ biến.
Dependency Confusion: Tấn công bằng cách tải lên các gói độc hại lên kho phần mềm công cộng với cùng tên với các gói nội bộ của một tổ chức.
Phần mềm độc hại (Malware): Phần mềm được thiết kế để gây hại cho hệ thống máy tính, mạng hoặc người dùng.
Backdoor: Một phương pháp bí mật để vượt qua xác thực hoặc mã hóa thông thường trong một hệ thống máy tính.
CI/CD (Continuous Integration/Continuous Delivery): Một phương pháp phát triển phần mềm hiện đại, trong đó các thay đổi mã được tích hợp và triển khai thường xuyên và tự động.
SBOM (Software Bill of Materials): Danh sách đầy đủ các thành phần phần mềm được sử dụng trong một ứng dụng.
PyPI: Kho lưu trữ gói phần mềm Python.
npm: Trình quản lý gói mặc định cho JavaScript.
API token: Chuỗi mã được sử dụng để xác thực và cấp quyền truy cập vào một API (Application Programming Interface).