Hai bề mặt vốn dễ bị xem nhẹ—crate chạy trong lúc biên dịch và extension chạy bên trong trình soạn thảo—đang nhắc lại một bài học quan trọng: chuỗi cung ứng phần mềm bắt đầu trước khi ứng dụng được đóng gói. Một dependency không cần xuất hiện trong runtime production vẫn có thể gây hại nếu nó thực thi mã trên máy lập trình viên hoặc build runner.

Các phát hiện liên quan đến Rust và VS Code xuất hiện cùng lúc AWS mở rộng Security Hub Extended sang bảo mật chuỗi cung ứng. Dù đây là ba diễn biến riêng biệt, chúng cùng chỉ ra nhu cầu hợp nhất hoạt động kiểm kê, phòng ngừa và giám sát thay vì chỉ quét thư viện ứng dụng.

Những báo cáo mới đã phát hiện điều gì?

Theo phân tích chiến dịch nhắm vào crate arrayref, các phiên bản độc hại của arrayref và một số crate khác thực thi backdoor ở thời điểm biên dịch. Báo cáo cũng nhận thấy hạ tầng của chiến dịch có điểm trùng lặp đáng kể với những hoạt động chuỗi cung ứng gần đây liên quan đến Mastra và axios, đồng thời liên hệ các dấu hiệu đó với chiến dịch của DPRK.

Điểm kỹ thuật đáng chú ý là thời điểm thực thi. Mã chạy khi biên dịch có thể tác động trực tiếp đến workstation hoặc hệ thống CI đang giữ source code và thông tin xác thực, ngay cả khi artefact cuối cùng không chứa backdoor theo cách mà một công cụ quét runtime dễ nhận diện.

Ở bề mặt khác, ProjectDiscovery phân tích Markdown Preview Enhanced, một extension VS Code được báo cáo có khoảng 9,5 triệu lượt cài đặt. Cuộc kiểm tra bằng Neo tìm thấy năm CVE trên hai bề mặt tấn công; trong đó, lỗi kết xuất WaveDrom cho phép một tệp Markdown thông thường dẫn đến thực thi JavaScript trong phần preview.

Hai trường hợp không chứng minh rằng mọi crate hay extension đều nguy hiểm. Chúng cho thấy cơ chế tin cậy hiện tại có khoảng trống: extension có thể tự động cập nhật và chạy với quyền của người dùng, trong khi công cụ dành cho lập trình viên thường không xuất hiện trong software bill of materials của ứng dụng.

Vì sao SBOM của ứng dụng chưa đủ?

SBOM thường mô tả thành phần được dùng để tạo ra hoặc phân phối một sản phẩm. Cách nhìn đó hữu ích nhưng có thể bỏ sót các công cụ tác động lên mã nguồn trước khi sản phẩm tồn tại: editor extension, compiler plugin, build script, package manager hook và tiện ích CI.

Một mô hình kiểm kê thực tế hơn nên phân biệt ít nhất ba lớp. Lớp dependency ứng dụng ảnh hưởng đến artefact; lớp build ảnh hưởng đến quá trình tạo artefact; lớp workstation có quyền truy cập repository, khóa ký, SSH và registry. Một gói có thể xuất hiện ở nhiều lớp, nhưng biện pháp giảm thiểu tại mỗi lớp không giống nhau.

Bảng trên là khung đánh giá được đề xuất, không phải mô tả đầy đủ về khả năng của từng sản phẩm được báo cáo. Mục tiêu là giúp đội ngũ xác định nơi mã bên thứ ba có thể chạy và quyền hạn mà mã đó thực sự nhận được.

Đội ngũ phát triển nên thay đổi kiểm soát nào?

Trước hết, hãy đưa extension, build plugin và công cụ cục bộ vào inventory có chủ sở hữu. Với VS Code, tổ chức có thể xác định danh sách extension được phê duyệt, kiểm tra publisher và phạm vi sử dụng, sau đó thử bản cập nhật trong môi trường ít đặc quyền trước khi triển khai rộng.

Thứ hai, giảm tác động nếu mã độc chạy được. Không để workstation hoặc CI runner giữ credential lâu dài khi không cần thiết; phân tách quyền đọc source, ký artefact và phát hành package; đồng thời giới hạn khả năng truy cập mạng của job build nhạy cảm. Những thay đổi này không ngăn mọi cuộc tấn công, nhưng thu hẹp phạm vi thiệt hại.

Thứ ba, biến thay đổi dependency thành sự kiện cần xem xét. Lockfile, phiên bản mới, thay đổi publisher hoặc hành vi build mới đều đáng được kiểm tra theo mức rủi ro. Cách tiếp cận này cũng phù hợp với việc thiết kế một control plane có quản trị: chính sách, phê duyệt và dấu vết kiểm toán nên được áp dụng nhất quán thay vì phụ thuộc vào thao tác thủ công của từng lập trình viên.

• Liệt kê extension và công cụ có thể thực thi mã trên máy phát triển.
• Rà soát script chạy trong quá trình cài đặt, biên dịch và đóng gói.
• Tách credential phát hành khỏi môi trường chỉnh sửa mã hằng ngày.
• Cảnh báo khi lockfile, publisher hoặc nguồn phân phối thay đổi bất thường.
• Chuẩn bị quy trình thu hồi token và cô lập runner khi có sự cố.

AWS Security Hub Extended phản ánh xu hướng nào?

AWS đã bổ sung Supply Chain Security làm danh mục thứ mười của Security Hub Extended. Theo thông báo, sáng kiến này đã tăng từ 14 đối tác trong chín danh mục lên 23 đối tác trong mười danh mục kể từ tháng Hai.

Đây không phải bằng chứng cho thấy một dashboard có thể tự giải quyết rủi ro dependency hoặc extension. Ý nghĩa thực tế là bảo mật chuỗi cung ứng đang được kết nối với quy trình vận hành bảo mật rộng hơn, nơi phát hiện từ nhiều công cụ có thể được đưa vào cùng một ngữ cảnh đánh giá và xử lý.

Điểm cần theo dõi tiếp theo là chất lượng tích hợp: công cụ có nhận diện được cả dependency, môi trường build và workstation hay không; phát hiện có đủ thông tin để ưu tiên hay không; và đội vận hành có thể chuyển cảnh báo thành hành động thu hồi credential, chặn phiên bản hoặc cô lập hệ thống nhanh đến đâu.

Kết luận

• Rủi ro chuỗi cung ứng bao gồm cả mã chạy lúc build và công cụ chạy trên workstation.
• SBOM ứng dụng không thể thay thế inventory extension, plugin và build tool.
• Danh sách cho phép, quyền tối thiểu và credential ngắn hạn giúp giảm phạm vi thiệt hại.
• Nền tảng tập trung chỉ có giá trị khi phát hiện dẫn đến quy trình ứng phó rõ ràng.

Bài viết liên quan

• Ventura React: thư viện component nhẹ còn phù hợp cho dự án mới?
• Nova MCP: Biến AI trong Cursor và Claude thành đội ngũ sản phẩm
• Ansible Automation Orchestrator: thiết kế control plane có quản trị

Nguồn tham khảo

• Security Hub Extended adds Supply Chain Security as its tenth category
• Supply Chain Security Analysis of a 9.5M-Install VS Code Extension
• Rust Supply Chain Attack on arrayref: Significant Overlap with DPRK Campaigns