Lộ trình 05Bài học 3 / 8

Liên tục tìm và sửa lỗ hổng

Xây quy trình liên tục từ phát hiện lỗ hổng đến khắc phục production đã xác minh. Hiểu khoảng trống bảo trì mà prototype thành công có thể che giấu.

Thực hành12 minĐã review

Xuất bản bởi Cách chúng tôi viết

Kiểm tra mức hiểuỨng dụng không đổi trong ba tháng. Lần quét dependency cuối đạt lúc phát hành. Nhận định nào có căn cứ?Làm bài tập
Ứng dụng không đổi trong ba tháng. Lần quét dependency cuối đạt lúc phát hành. Nhận định nào có căn cứ?

Bạn sẽ học gì

  • Giải thích vì sao phần mềm không đổi vẫn cần review bảo mật liên tục.
  • Đối chiếu các loại quét với phạm vi bao phủ và giới hạn.
  • Theo dõi phát hiện qua ưu tiên, sửa, triển khai và xác minh.

Prototype hoạt động có thể thành dịch vụ không được hỗ trợ

Vibe coding có thể tạo prototype hữu ích nhanh. Rủi ro production tăng khi mọi người tiếp tục dùng mà không bảo trì bảo mật liên tục. Đây là khoảng trống nghiêm trọng: phần mềm vẫn phơi nhiễm trong khi người tạo coi công việc đã xong.

Khoảng trống thuộc cả tổ chức lẫn kỹ thuật. Có thể có công cụ quét nhưng không có người phụ trách. Phát hiện có thể có người phụ trách nhưng không có lộ trình phát hành. Bản sửa đã merge có thể để artifact production cũ tiếp tục chạy.

Đánh giá platform phát triển và cấu hình thực tế. Một số công cụ có tính năng bảo mật. Nhãn sản phẩm không xác định liệu ứng dụng đã triển khai có được quét liên tục và nhận bản sửa đã xác minh không.

Quét khi bằng chứng có thể thay đổi

Chạy kiểm tra liên quan trên thay đổi đề xuất và artifact đã build. Đánh giá lại phiên bản được hỗ trợ theo lịch vì thông tin thông báo bảo mật thay đổi mà không cần commit. Kích hoạt review thêm khi có thông báo liên quan, thay đổi mức phơi nhiễm hoặc sự cố.

Giữ phạm vi rõ. Xác định repository, branch, lockfile, image, digest đã triển khai, runtime và môi trường. Bao gồm ứng dụng không còn phát triển tính năng nhưng vẫn phục vụ người dùng.

Lần quét thất bại là bằng chứng còn thiếu. Giám sát độ cập nhật lần quét, lỗi nguồn thông báo bảo mật, lỗi xác thực, thành phần không hỗ trợ và khoảng trống bao phủ. Danh sách phát hiện trống sau job thất bại không phải kết quả sạch.

Dùng kiểm tra khác nhau cho câu hỏi khác nhau

Kiểm traPhạm vi hữu íchGiới hạn quan trọng
Phân tích thành phần phần mềm, hay SCALỗ hổng dependency đã biết, gồm package phụ thuộc gián tiếp được nhận diệnKhông chứng minh phân quyền ứng dụng đúng
Kiểm thử bảo mật ứng dụng tĩnh, hay SASTMẫu mã không an toàn mà công cụ hỗ trợ phát hiệnCó thể bỏ sót hành vi runtime và tạo phát hiện cần phân loại
Quét secretMẫu thông tin xác thực được nhận diện trong nội dung quétXóa chuỗi có thể để thông tin xác thực còn hiệu lực ở nơi khác
Kiểm tra hạ tầng và cấu hìnhVi phạm chính sách đã xác định trong tài nguyên hoặc cấu hình được quétCấu hình repository có thể khác môi trường đang chạy
Kiểm thử động được phépHành vi ứng dụng đang chạy trong phạm vi testCần quyền, dữ liệu phù hợp và cẩn trọng với tác động phụ

Kết hợp các kiểm tra này với review và test bảo mật liên quan. Không tuyên bố bất kỳ lần quét nào chứng minh không có lỗ hổng.

Theo dõi phát hiện giả định đến production

Thời gianSự kiệnTrạng thái thực tế
Thứ Hai 09:00Thông báo mới xác định dependency PDF bị ảnh hưởngBản phát hành hiện có cần đánh giá
Thứ Hai 09:15Quét theo lịch nhận diện phiên bản productionĐã phát hiện, chưa sửa
Thứ Hai 10:00Người phụ trách xác nhận mức phơi nhiễm và chọn bản vá được hỗ trợĐã lập kế hoạch khắc phục
Thứ Hai 13:00Test đạt và PR bản vá được mergeRepository đã sửa; production vẫn cần triển khai
Thứ Hai 14:00Pipeline triển khai image đã sửaArtifact mới đang chạy; còn xác minh
Thứ Hai 14:20Quét artifact và regression test xuất dữ liệu đạtBản sửa đã xác minh trong phạm vi kiểm tra

Ưu tiên theo mức nghiêm trọng, bằng chứng khai thác, mức phơi nhiễm, dữ liệu bị ảnh hưởng và biện pháp giảm tác động sẵn có. Danh mục CISA giúp nhận diện khai thác đã biết. Đây là một đầu vào, không phải đánh giá rủi ro đầy đủ. Danh mục CISA.

Ngoại lệ tạm thời cần bằng chứng, người phụ trách, kiểm soát bù trừ và thời hạn hoặc điều kiện xem lại. Nếu chưa có bản vá, cân nhắc cách xử lý tạm được phép, hạn chế tính năng hoặc loại thành phần bị ảnh hưởng.

Khép lại khoảng trống bảo trì

Đo thời gian đến phân loại và khắc phục đã xác minh theo mức ưu tiên. Theo dõi ngoại lệ quá hạn, lần quét lỗi thời, phiên bản production bị ảnh hưởng và phát hiện lặp lại. Số phát hiện giảm cũng có thể do phạm vi bao phủ giảm; hãy kiểm tra mẫu số.

Taiga Maintaining quét repository liên kết sau thay đổi và theo định kỳ. Nó ghi phát hiện và kết nối khắc phục với initiative cùng thay đổi đã review. Kiểm tra trạng thái lượt quét và hành vi hiện được mô tả. Maintaining.

Pipeline của bạn vẫn cần điều kiện phát hành phù hợp. Người phụ trách dịch vụ vẫn cần xác nhận triển khai và tính đúng đắn vận hành. Chuỗi liên tục này là một phần vận hành AI software factory, kể cả sản phẩm có phiên bản đầu bắt đầu từ prototype.

Làm bài tập

Dùng dòng thời gian giả định trong bài. Chỉ ra lúc nhóm có thể tuyên bố thành công sai. Xác định điều kiện quét, cảnh báo lỗi, người phụ trách khắc phục, xác minh phát hành và thời hạn ngoại lệ tạm thời.

Tải worksheet (Markdown)
Kiểm tra mức hiểu ↑

Tiếp tục học

Nguồn và đọc thêm

Đọc thêm liên quan từ Taiga

← Bài trước: Bảo trì phần mềm trong suốt thời gian sử dụng