Dự án: threat model một trang cho hệ thống của bạn

Bốn mươi bốn bài trước dạy bạn nhận ra và vá từng lớp lỗi. Bài này khác về bản chất: nó không dạy gì mới, nó yêu cầu bạn tạo ra một thứ dùng được ở công việc thật.

Đó là lý do nó là một project chứ không phải một challenge. Một challenge có một đáp án bạn so được; một project có một sản phẩm mà giá trị của nó nằm ở việc nó áp dụng vào hệ thống của chính bạn — và không ai ngoài bạn kiểm được điều đó.

Việc phải làm: một threat model một trang cho một tính năng thật trong dự án của bạn.

Ba tiêu chí chọn tính năng, và tiêu chí thứ ba là tiêu chí quan trọng:

1. Nó đang được thiết kế hoặc mới bắt đầu code. Threat model sau khi code xong biến mọi phát hiện thành một lần refactor thay vì một quyết định — bài stride-in-practice đã nói.
2. Nó chạm vào tiền, quyền, hoặc dữ liệu của nhiều khách hàng. Một tính năng đổi màu giao diện không có gì để threat model.
3. Bạn là người sẽ viết code cho nó. Đây là tiêu chí quyết định giá trị: bài abuse-cases đã lập luận rằng với lớp lỗi logic nghiệp vụ thì người xây tính năng là người tìm ra tốt nhất, vì họ là người duy nhất biết hành vi nào đúng theo nghiệp vụ.

Rubric — sáu tiêu chí, và tiêu chí 5 và 6 là hai tiêu chí phân biệt một threat model tốt:

Tiêu chí 6 là tiêu chí cuối cùng của cả khoá học và nó là điều đáng mang đi nhất: mọi bài fix trong bốn mươi bốn bài trước đều kết thúc bằng một câu hỏi "bản vá này không chặn được gì". Đó không phải một quy ước trình bày — nó là kỹ năng mà một tech lead nhận ra ngay ở một người, và nó là thứ phân biệt một báo cáo bảo mật dùng được với một báo cáo tạo cảm giác an toàn.