Xác minh những gì đi vào bản phát hành

Hỏi dependency có cần thiết không

Agent có thể đề xuất package có vẻ giải quyết vấn đề. Đó là đề xuất, không phải bằng chứng package tồn tại hoặc phù hợp. Xác minh registry, bên phát hành, tên package và phiên bản chính xác trước khi cài.

Với tính năng xuất CSV giả định, runtime có thể đã cung cấp hành vi cần thiết. Package mới vẫn có thể phù hợp, nhưng thêm nghĩa vụ bảo trì và đường thực thi. So sánh công sức hiện thực hóa với trách nhiệm liên tục mà dependency mang lại.

Review giấy phép và runtime được hỗ trợ. Kiểm tra hoạt động bảo trì và thông báo bảo mật liên quan. Tên quen thuộc có thể chỉ package khác trong registry khác. Cài đặt thành công chỉ cho biết quá trình cài đã hoàn tất.

Kiểm tra hành vi cài đặt và build

Dependency có thể thực thi mã khi cài hoặc build. Giới hạn thông tin xác thực và quyền mạng trong các môi trường này. Không để job xử lý pull request không đáng tin cậy tiếp cận secret production.

Dùng lockfile đã commit khi hệ sinh thái hỗ trợ. Yêu cầu build tuân theo tệp đó. Review thay đổi lockfile cùng thay đổi mã nguồn, kể cả package phụ thuộc gián tiếp ngoài dự kiến. Ghim phiên bản cải thiện khả năng tái lập nhưng không làm phiên bản có lỗ hổng trở nên an toàn.

SSDF của NIST bao gồm bảo vệ phần mềm và thực hành phát triển xuyên vòng đời. Dùng góc nhìn rộng đó khi thiết kế môi trường build. Đọc framework.

Phân biệt danh mục với provenance

Danh mục thành phần phần mềm, hay SBOM, ghi các thành phần trong phần mềm. Nó giúp xác định bản phát hành bị ảnh hưởng khi một thành phần trở thành mối lo. Tự nó không chứng minh các thành phần an toàn.

Provenance đề cập cách artifact được tạo. SLSA định nghĩa định dạng provenance cho thông tin về build và đầu vào. Việc xác minh phải kết nối thông tin này với bên tạo đáng tin cậy và artifact bạn định dùng. Tệp có tên “provenance” là chưa đủ. SLSA provenance.

Với dịch vụ xuất, ghi chuỗi có thể kiểm tra:

1. Commit đã review xác định mã nguồn được chấp nhận.
2. Build xác định đầu vào và môi trường thực thi.
3. Artifact có digest ổn định.
4. Các kiểm tra xác định artifact hoặc mã nguồn đã kiểm tra.
5. Bản ghi triển khai xác định artifact được đưa vào môi trường đích.

Tránh build lại theo cách khác sau phê duyệt mà không có quy trình xác minh xác định. Tag có thể thay đổi như latest có thể trỏ tới image khác về sau.

Quyết định ý nghĩa của phát hiện

Phát hiện lỗ hổng cần ngữ cảnh: phiên bản bị ảnh hưởng, liệu hành vi bị ảnh hưởng có thể được thực thi hay không, mức phơi nhiễm, bản sửa sẵn có và hậu quả. Ghi bằng chứng cho mọi ngoại lệ tạm thời. Giao người phụ trách, thời hạn và điều kiện xem lại.

Không tắt toàn bộ công cụ quét vì một phát hiện không áp dụng. Không tuyên bố kết quả sạch khi lần quét chưa hoàn tất. Timeout, package không được hỗ trợ hoặc nguồn thông báo bảo mật không truy cập được đều là bằng chứng còn thiếu.

Cuối cùng, lập kế hoạch cập nhật sau phát hành. Thông báo bảo mật mới có thể ảnh hưởng artifact đã chấp nhận hôm qua. Người phụ trách dịch vụ cần danh mục, quy trình ứng phó và năng lực tạo bản phát hành đã sửa.

Tiếp tục với quản lý lỗ hổng liên tục để kết nối quét lặp lại với bản sửa production đã xác minh.