4.9 Vòng đời phát triển phần mềm an toàn

Tổng quan và động lực

Hầu hết khiếm khuyết bảo mật không kỳ lạ. Chúng là những sai lầm bình thường: một kiểm tra cấp quyền bị thiếu, một đầu vào được tin, một phụ thuộc không ai cập nhật, một bí mật dán vào tệp cấu hình. Điều khiến chúng đắt là khi chúng bị bắt. Một lỗi tìm thấy lúc viết một yêu cầu tốn một cuộc trò chuyện. Cùng lỗi đó tìm thấy trong một cuộc kiểm thử xâm nhập tuần trước ra mắt tốn một cuộc chạy vạy, và tìm thấy trên môi trường thực tốn một sự cố, một lần công bố, và mất niềm tin. Vòng đời phát triển phần mềm an toàn (SSDLC) là kỷ luật bắt những lỗi này sớm và liên tục, bằng cách xây bảo mật vào mọi giai đoạn của cách bạn hoạch định, thiết kế, xây dựng, rà soát, phát hành và vận hành phần mềm, thay vì gắn một bài kiểm thử bảo mật vào cuối.

Chương này là xương sống quy trình của Phần 4. Nó gắn kết các phòng thủ cấp ứng dụng của chương 4.2 (cách bạn viết mã chống chịu tấn công) và kỷ luật thời gian chạy của chương 4.4 (cách bạn phát hiện và phản ứng khi phòng thủ bị thử thách), thừa hưởng tư duy từ chương 4.1 (nền tảng và văn hóa bảo mật), và tạo ra bằng chứng mà chương 4.6 (tuân thủ và quản trị) biến thành sản phẩm kiểm toán. Nếu các chương đó bao quát cái gì và vì sao, thì chương này bao quát khi nào và thế nào: ở điểm nào trong luồng phân phối của bạn mỗi biện pháp kiểm soát thuộc về, ai sở hữu nó, và nó canh giữ cổng nào.

Với các đội lớn, phần thưởng là đòn bẩy. Khi hàng trăm kỹ sư mỗi người tự quyết định bao nhiêu bảo mật cần làm, mắt xích yếu nhất định đoạt mức phơi nhiễm thực của bạn. Một vòng đời được xác định biến con đường an toàn thành con đường mặc định, để một kỹ sư trung bình phát hành phần mềm an toàn hợp lý mà không cần anh hùng. Với doanh nghiệp, sự nhất quán đó hạ chi phí của mọi cuộc kiểm toán và tích hợp. Với chính phủ, nơi công dân không thể chọn nhà cung cấp khác cho dữ liệu thuế hay trợ cấp của họ, một vòng đời có tài liệu thường là điều kiện pháp lý để vận hành, và các khung trong chương này ánh xạ vào nghĩa vụ đó.

Các nguyên tắc chính

Dịch chuyển bảo mật sang trái: tìm và sửa lỗi ở giai đoạn rẻ nhất, luôn là giai đoạn sớm nhất.
Biến bảo mật thành thuộc tính của đường ống, không phải của một người: tự động hóa các cổng để con đường an toàn là con đường dễ.
Giao cho mỗi giai đoạn một chủ sở hữu và một cổng, từ yêu cầu đến vận hành, với điều kiện vượt qua rõ ràng.
Quản lý rủi ro, không phải ô đánh dấu: ưu tiên các lỗi quan trọng theo khả năng khai thác và tác động, và ưu tiên nhiều kiểm tra nhỏ liên tục hơn một cuộc kiểm toán chậm cuối chu kỳ.
Coi các phụ thuộc và hệ thống dựng là một phần của bề mặt tấn công, vì kẻ tấn công làm vậy.
Đo chương trình, vì một vòng đời bạn không đo được là một vòng đời bạn không cải thiện được.

Khuyến nghị

Dịch chuyển bảo mật sang trái qua toàn bộ vòng đời

Kiểm thử dịch chuyển sang trái nghĩa là chuyển việc xác minh sớm hơn trong luồng phân phối, về phía khoảnh khắc một quyết định được đưa ra thay vì khoảnh khắc trước khi phát hành. Áp dụng cho bảo mật, nó đóng khung lại mục tiêu: bạn không kiểm thử bảo mật vào cuối, bạn thiết kế và xây nó vào từ đầu, rồi xác minh liên tục. Kinh tế học rõ rệt. Một yêu cầu viết lại trong buổi hoạch định gần như miễn phí; một lỗi thiết kế làm lại sau khi mã đã có tốn vài ngày; một lỗ hổng vá trên môi trường thực tốn một sự cố. Dịch chuyển sang trái có một chế độ thất bại: đổ một đống công cụ bảo mật lên lập trình viên và gọi là xong. Làm tốt, nó ghép mỗi kiểm tra sớm với sự hỗ trợ để hành động trên nó, để một phát hiện đến với ngữ cảnh, một gợi ý sửa và một chủ sở hữu.

Viết yêu cầu bảo mật và ca lạm dụng

Bảo mật bắt đầu trước mọi mã, trong cách bạn đóng khung công việc. Cùng với yêu cầu chức năng nói hệ thống nên làm gì, hãy viết yêu cầu bảo mật nói nó không bao giờ được làm gì và phải bảo đảm gì: dữ liệu nào nhạy cảm, ai được cấp quyền, cái gì phải được ghi nhật ký, quy định nào áp dụng. Rồi bổ sung câu chuyện người dùng của bạn bằng ca lạm dụng và ca sử dụng sai: những tường thuật ngắn về cách một tác nhân thù địch sẽ cố đánh bại mỗi tính năng. Nơi một câu chuyện người dùng nói “khách hàng đặt lại mật khẩu của họ,” ca lạm dụng hỏi “kẻ tấn công đặt lại mật khẩu của người khác,” và câu hỏi đó thúc đẩy một yêu cầu thực về giới hạn tốc độ, hết hạn token và xác minh. Điều này phơi bày cả các lớp lỗi khi chúng còn là chữ trên màn hình. Hãy giữ ca lạm dụng gắn với câu chuyện để chúng đi vào thiết kế, rà soát và định nghĩa hoàn thành.

Đặt một cổng mô hình hóa mối đe dọa trong thiết kế

Mô hình hóa mối đe dọa là thực hành có cấu trúc kiểm tra một thiết kế để tìm điều gì có thể sai trước khi bạn xây: xác định tài sản, ánh xạ dữ liệu chảy qua các ranh giới tin cậy thế nào, liệt kê mối đe dọa, và quyết định biện pháp giảm thiểu. Đó là hoạt động bảo mật có đòn bẩy cao nhất bạn có thể làm, vì nó hoạt động trên một thiết kế khi việc thay đổi nó còn rẻ. Hãy biến nó thành một cổng nhẹ cho bất kỳ tính năng nào chạm vào xác thực, dữ liệu nhạy cảm, tiền, hay một ranh giới tin cậy mới, đi qua các loại mối đe dọa như giả mạo, can thiệp, chối bỏ, tiết lộ thông tin, từ chối dịch vụ và nâng đặc quyền, một danh sách kiểm tra được biết bằng từ viết tắt STRIDE. Giữ nghi thức tương xứng: một buổi một giờ với bảng trắng, một sơ đồ luồng dữ liệu và các ca lạm dụng bắt được hầu hết những gì một tài liệu chính thức sẽ bắt. Ghi lại các mối đe dọa tìm thấy, biện pháp giảm thiểu đã chọn, và các rủi ro được chấp nhận có ý thức; bản ghi đó trở thành bằng chứng giai đoạn thiết kế cho chương 4.6 và bản đồ xuất phát cho thiết kế an toàn của chương 4.2. Hãy gắn nó với các thay đổi thiết kế quan trọng, nếu không nó thoái hóa thành một tài liệu viết một lần và không bao giờ xem lại.

Áp dụng tiêu chuẩn lập trình an toàn và mặc định an toàn

Hãy trao cho kỹ sư một tiêu chuẩn lập trình an toàn cụ thể cho mỗi ngôn ngữ và khung phát triển bạn dùng: cách tham số hóa truy vấn, cách mã hóa đầu ra, cách xác thực đầu vào, cách xử lý bí mật, thư viện mật mã nào để gọi và cái nào không bao giờ tự viết. Ghép nó với các khối xây dựng an toàn-theo-mặc-định: thư viện dùng chung khiến lựa chọn an toàn là mặc định và lựa chọn không an toàn thì khó, để một kỹ sư có mã hóa đầu ra hay truy vấn tham số hóa miễn phí thay vì bằng cách nhớ. Tiêu chuẩn tốt nhất là cái mà công cụ của bạn thực thi, để vi phạm làm hỏng một kiểm tra thay vì phụ thuộc vào người rà soát nhận ra. Hãy tuyển chọn nó đối chiếu với một danh mục điểm yếu nổi tiếng để bạn bao quát các lớp thực sự gây ra xâm phạm, và cắt tỉa các quy tắc tạo ra nhiễu nhiều hơn giá trị.

Làm bảo mật tường minh trong rà soát mã

Rà soát mã (chương 2.5) là một cổng bảo mật tự nhiên, vì một người thứ hai đọc thay đổi ở vị thế tốt để phát hiện một kiểm tra cấp quyền bị thiếu hay một đầu vào được tin. Hãy làm chiều bảo mật tường minh thay vì hy vọng người rà soát nhớ: thêm một danh sách kiểm tra bảo mật ngắn vào mẫu rà soát của bạn, gắn với các vùng rủi ro là xử lý đầu vào, cấp quyền, bí mật, mật mã và thay đổi phụ thuộc. Định tuyến các thay đổi đến mã nhạy cảm, như các đường xác thực hay thanh toán, tới người rà soát có chiều sâu bảo mật, và đánh dấu các đường đó để việc định tuyến là tự động. Chạy kiểm tra tự động trước rà soát của con người, để người rà soát dành sự chú ý cho logic và ý định thiết kế (phần theo ngữ cảnh và mới lạ) thay vì các phát hiện mức lint mà một công cụ đã bắt.

Đặt đúng cổng tự động ở đúng điểm trong đường ống

Nhiều loại công cụ bảo mật thuộc về đường ống tích hợp và phân phối liên tục của bạn (chương 8.1), và biết mỗi cái vừa ở đâu giữ bạn khỏi kỳ vọng một công cụ làm việc của công cụ khác. Kiểm thử bảo mật ứng dụng tĩnh (SAST) phân tích mã nguồn mà không chạy nó, bắt các lỗi như chèn mã và dùng API không an toàn trên mỗi commit. Phân tích thành phần phần mềm (SCA) kiểm tra các phụ thuộc bên thứ ba và mã nguồn mở của bạn tìm lỗ hổng đã biết và vấn đề giấy phép, nhánh đường ống của quản lý phụ thuộc và chuỗi cung ứng ở chương 2.18. Quét bí mật tìm thông tin xác thực, token và khóa vô tình bị commit, và thuộc về cả lúc commit (qua một hook pre-commit) lẫn trong đường ống như một điểm tựa. Quét hạ tầng-dưới-dạng-mã (IaC) kiểm tra Terraform, CloudFormation hay manifest Kubernetes của bạn tìm cấu hình không an toàn, bắt một thùng lưu trữ mở khi nó còn là một diff.

Kiểm thử bảo mật ứng dụng động (DAST) thực hành một ứng dụng đang chạy từ bên ngoài, như kẻ tấn công dò các điểm cuối, và vừa muộn hơn đối với một môi trường kiểm thử hay thử nghiệm đã triển khai. Kiểm thử bảo mật ứng dụng tương tác (IAST) đo đạc ứng dụng đang chạy để quan sát nó từ bên trong trong các bài kiểm thử chức năng, kết hợp hiểu biết tĩnh với độ bao phủ động và giảm dương tính giả. Theo quy tắc: SAST, SCA, quét bí mật và quét IaC kiểm soát bản dựng; DAST và IAST xác minh hệ thống đang chạy. Hãy điều chỉnh từng cái để thất bại trên những gì quan trọng và cảnh báo phần còn lại, vì một cổng kêu sói là một cổng các đội tắt.

Nhúng nhà vô địch bảo mật vào các đội phân phối

Một đội bảo mật trung tâm không thể rà soát mọi thay đổi cho hàng trăm kỹ sư, và một chức năng bảo mật hoạt động như người gác cổng xa xôi trở thành nút thắt mà các đội đi vòng. Mô hình nhà vô địch bảo mật giải quyết điều này bằng cách nhúng một kỹ sư có tư duy bảo mật vào mỗi đội phân phối: không phải chuyên gia toàn thời gian, mà là một lập trình viên được đào tạo thêm, có đường dây trực tiếp đến đội trung tâm, và có thời gian tường minh để nâng thanh bảo mật cục bộ. Nhà vô địch chạy các buổi mô hình hóa mối đe dọa, tuyển chọn tiêu chuẩn lập trình cho ngăn xếp của họ, phân loại phát hiện của công cụ, và dịch chính sách trung tâm thành thực tế của đội họ, mở rộng tầm với của đội trung tâm mà không mở rộng biên chế tuyến tính. Hãy đầu tư vào nhà vô địch bằng một cộng đồng thực hành, sự ghi nhận và giờ thật, nếu không vai trò thoái hóa thành một cái tên trên sơ đồ tổ chức.

Neo chương trình vào một khung đã thiết lập

Bạn không cần phát minh một vòng đời từ đầu, vì các khung trưởng thành mã hóa nhiều thập kỷ học hỏi và cho kiểm toán viên một từ vựng chung. Vòng đời Phát triển Bảo mật của Microsoft (SDL) là một mô hình dựa trên thực hành, sinh ra từ những bài học khó khăn của chính Microsoft, quy định các hoạt động cụ thể cho từng giai đoạn. OWASP SAMM (Mô hình Trưởng thành Bảo đảm Phần mềm) và BSIMM (Mô hình Trưởng thành Xây dựng Bảo mật Vào) là các mô hình đánh giá: SAMM mang tính quy định, cho bạn một mục tiêu trưởng thành để xây hướng tới, trong khi BSIMM mang tính mô tả, nói cho bạn biết một mẫu lớn các công ty thực sự làm gì để bạn có thể so chuẩn. Khung Phát triển Phần mềm An toàn NIST (SSDF), công bố là Ấn phẩm Đặc biệt 800-218, là một tập thực hành ngắn gọn, tập trung vào kết quả ngày càng làm nền cho các yêu cầu chuỗi cung ứng phần mềm của chính phủ Hoa Kỳ. Hãy chọn một cái làm xương sống thay vì trộn cả bốn thành sự nhầm lẫn. Khung là một bản đồ, không phải lãnh thổ: áp dụng các thực hành phù hợp với rủi ro của bạn, và ghi lại cái nào bạn đã triển khai, vì bản ghi đó chính là thứ chương 4.6 và chương 10.2 (rủi ro, kiểm toán và bảo đảm) cần.

Đặt bảo mật vào định nghĩa hoàn thành và chạy khắc phục theo SLA

Một cổng chỉ đứng vững nếu nó là một phần của nghĩa “hoàn thành.” Hãy mở rộng định nghĩa hoàn thành của đội để một thay đổi chưa hoàn chỉnh cho đến khi các điều kiện bảo mật của nó được đáp ứng: không có phát hành bộ quét mức nghiêm trọng cao chưa xử lý, mô hình mối đe dọa được cập nhật nếu thiết kế đổi, bí mật được quản lý đúng, và phụ thuộc không có lỗ hổng nghiêm trọng đã biết. Điều này biến bảo mật thành tiêu chí nghiệm thu thường lệ, không phải sự kiện đặc biệt. Với các phát hiện thoát vào môi trường thực, hãy chạy một quy trình quản lý lỗ hổng với các thỏa thuận mức dịch vụ (SLA) khắc phục tường minh: thời gian tối đa để sửa, đặt theo mức nghiêm trọng, để một lỗi nghiêm trọng được đo bằng ngày và một lỗi thấp trong một cửa sổ dài hơn, được theo dõi. Hãy ưu tiên theo rủi ro thực, pha trộn điểm số nghiêm trọng với khả năng khai thác và mức phơi bày, để bạn sửa lỗi khai thác được hướng internet trước lỗi lý thuyết đằng sau ba bức tường lửa. Theo dõi mọi phát hiện đến khi đóng trong một hệ thống, và báo cáo độ tuổi như bất kỳ chỉ số vận hành nào. Một SLA không ai đo là một điều ước.

Bảo vệ tính toàn vẹn chuỗi cung ứng từ đầu đến cuối

Kẻ tấn công ngày càng nhắm không phải vào mã của bạn mà vào con đường nó đi: một phụ thuộc bị xâm phạm, một bước dựng bị đầu độc, một sản phẩm không ký bị tráo trong lúc truyền. Đây là tấn công chuỗi cung ứng, và phòng thủ chống lại nó chạm vào nhiều giai đoạn. Hãy tạo một danh mục vật liệu phần mềm (SBOM) để bạn biết chính xác cái gì trong mỗi bản phát hành. Ghim và xác minh phụ thuộc, và kéo chúng qua một kho đăng ký nội bộ được kiểm soát thay vì trực tiếp từ internet công cộng. Gia cố chính hệ thống dựng, vì một máy chủ dựng với quyền rộng là mục tiêu giá trị cao, và tạo các sản phẩm có ký, xác minh được với nguồn gốc để người tiêu thụ xác nhận được thứ họ chạy là thứ bạn đã dựng. Những điểm chạm này liên kết với kỷ luật phụ thuộc của chương 2.18 và nghĩa vụ bảo đảm của chương 10.2. Hãy coi đường ống dựng và phát hành của bạn là hạ tầng sản xuất, vì một vụ xâm phạm ở đó làm tổn hại mọi thứ hạ nguồn cùng lúc.

Đo chương trình và đưa kết quả trở lại

Bạn cải thiện những gì bạn đo. Hãy theo dõi các chỉ báo dẫn đầu cho bạn biết liệu vòng đời có hoạt động: độ bao phủ mô hình mối đe dọa của các thay đổi quan trọng, phần trăm đường ống có các cổng kỳ vọng được bật, thời gian trung bình để khắc phục theo mức nghiêm trọng, tỷ lệ khiếm khuyết thoát (lỗi tìm thấy trên môi trường thực mà một cổng lẽ ra phải bắt), và tỷ lệ dương tính giả dự đoán liệu các đội có tiếp tục tin một công cụ. Hãy đưa kết quả trở lại: khiếm khuyết thoát điều chỉnh các cổng của bạn, công cụ ồn ào được điều chỉnh hoặc thay thế, và các lớp lỗi lặp lại thúc đẩy mặc định an toàn mới và đào tạo. Một vòng đời không có đo lường trôi thành nghi lễ.

Đánh đổi: ưu và nhược điểm

Cách tiếp cận	Ưu điểm	Nhược điểm
Cổng dịch chuyển sang trái trong đường ống	Sửa rẻ nhất; phản hồi nhanh, liên tục	Lan tràn công cụ và mệt mỏi vì cảnh báo nếu không điều chỉnh
Cổng mô hình hóa mối đe dọa trong thiết kế	Bắt lỗi thiết kế khi còn rẻ để sửa	Cần kỹ năng và thời gian; phân rã nếu không xem lại
Nhà vô địch bảo mật nhúng trong đội	Mở rộng bảo mật; quyền sở hữu và ngữ cảnh cục bộ	Loãng nếu thiếu nguồn lực hoặc không được ghi nhận
Người gác cổng bảo mật trung tâm	Ngưỡng nhất quán; trách nhiệm rõ ràng	Trở thành nút thắt các đội đi vòng
Chương trình neo vào khung (SDL, SAMM, SSDF)	Thực hành đã được chứng minh; từ vựng sẵn sàng kiểm toán	Rủi ro nghi lễ; sùng bái hình thức thiếu phán đoán
SLA khắc phục nghiêm ngặt	Phơi nhiễm có giới hạn; trách nhiệm đo được	Lách luật và đánh dấu cho có nếu chấm sai mức nghiêm trọng
Cổng chặn (làm hỏng bản dựng)	Bảo đảm mạnh không gì xấu được phát hành	Dừng phân phối trên dương tính giả; áp lực bỏ qua

Căng thẳng trung tâm là giữa sự chặt chẽ và dòng chảy. Đẩy quá ít vào đường ống thì lỗi thoát đến nơi chúng đắt; đẩy quá nhiều, không điều chỉnh, thì bạn hoặc chặn phân phối trên nhiễu hoặc dạy các đội bấm qua cảnh báo cho đến khi các cổng chẳng có nghĩa gì. Hãy giải quyết bằng cách điều chỉnh tàn nhẫn và bằng cách khớp sức mạnh của mỗi cổng với rủi ro nó canh giữ: chặn bản dựng trên một thông tin xác thực bị rò rỉ hay một lỗ hổng nghiêm trọng đã biết, nhưng chỉ cảnh báo trên một phát hiện kiểu cách mức thấp. Khi ma sát một đội cảm thấy tỷ lệ với nguy hiểm, con đường an toàn vẫn là con đường ít kháng cự nhất.

Câu hỏi để thảo luận với đội của bạn

Bảo mật thực sự xảy ra ở những giai đoạn nào trong luồng phân phối của chúng ta hôm nay, và nó chỉ giả vờ ở đâu? Hầu hết các tổ chức phát hiện nỗ lực bảo mật thực của họ tập trung ở cuối, trong một lần quét trước phát hành hay một cuộc kiểm thử xâm nhập hằng năm, trong khi các giai đoạn yêu cầu, thiết kế và rà soát chỉ nhắc đến bảo mật như khát vọng. Hãy ánh xạ luồng hiện tại của bạn một cách trung thực, từng giai đoạn, và đánh dấu nơi một hoạt động bảo mật có chủ sở hữu thật và cổng thật so với nơi nó là khẩu hiệu. Hãy mang một tính năng gần đây và truy công việc bảo mật nào thực sự đã xảy ra với nó, từ yêu cầu đầu tiên đến triển khai. Những khoảng trống bạn tìm thấy là tồn đọng dịch-chuyển-sang-trái của bạn, và các giai đoạn toàn khẩu hiệu không cổng là nơi lỗi đang lặng lẽ đi vào sản phẩm của bạn.
Khi một bộ quét báo một phát hiện, điều gì xảy ra tiếp theo, và chúng ta có chứng minh được không? Giá trị của mọi cổng trong chương này sống hoặc chết ở quy trình sau khi một phát hiện xuất hiện. Hãy đi qua một ví dụ thật: một công cụ SAST hay SCA đánh dấu một thứ, và rồi ai được thông báo, mức nghiêm trọng và khả năng khai thác được đánh giá thế nào, SLA là gì, nó được theo dõi ở đâu, và làm sao bạn biết nó đã được sửa thay vì bị hoãn? Nhiều đội có công cụ ấn tượng mà không có câu trả lời, nghĩa là các phát hiện của họ chất đống vào một hàng đợi mà ai cũng đã học cách bỏ qua. Nếu bạn không đưa ra được, cho quý trước, danh sách các phát hiện và thời gian khắc phục của chúng theo mức nghiêm trọng, bạn có thói quen quét nhưng không có chương trình quản lý lỗ hổng, và sự khác biệt đó chính xác là điều cả kiểm toán viên lẫn kẻ tấn công sẽ dò.
Khung đơn lẻ nào neo chương trình của chúng ta, và mỗi đội có nói được “hoàn thành an toàn” nghĩa là gì cho công việc của họ không? Không có xương sống chung, mỗi đội ứng biến định nghĩa riêng về đủ an toàn, và tư thế thực của tổ chức trở thành trung bình của một trăm phán đoán riêng tư. Hãy cùng quyết định khung đã thiết lập nào (SDL của Microsoft, OWASP SAMM, BSIMM, hay NIST SSDF) là tham chiếu của bạn, rồi kiểm tra liệu lựa chọn đó đã đến mặt đất chưa: một đội phân phối có thể đọc thuộc các điều kiện bảo mật trong định nghĩa hoàn thành của họ và chỉ ra cổng thực thi từng cái không? Hãy so sánh định nghĩa hoàn thành của ba đội khác nhau. Hội tụ nghĩa là vòng đời là thật; phân kỳ nghĩa là bạn có một khung trên một slide và ứng biến trong các đường ống.
Phát hiện nào chặn bản dựng, cái nào chỉ cảnh báo, và ai quyết định lằn ranh nằm ở đâu? Sức mạnh của mỗi cổng là một lựa chọn chính sách, và làm sai theo cả hai hướng đều tốn kém: chặn trên nhiễu và các đội học cách vượt qua hay tắt cổng dưới áp lực phân phối; cảnh báo mọi thứ và các lỗi nghiêm trọng trượt qua không ai đọc. Với một tổ chức lớn mối nguy là sự trôi, nơi mỗi đội lặng lẽ chỉnh lại ngưỡng của riêng mình cho đến khi “đường ống xanh” có nghĩa khác nhau ở mỗi nhóm và mức phơi nhiễm thực của bạn không thể biết từ trung tâm. Hãy mang chính sách đạt hoặc không đạt hiện tại cho từng công cụ, tỷ lệ dương tính giả mà các đội thực sự trải nghiệm, và một ví dụ gần đây về một phát hiện bị ghi đè và vì sao. Trong bối cảnh doanh nghiệp và chính phủ, hãy thêm ai có thẩm quyền chấp nhận một rủi ro và sự chấp nhận đó được ghi lại ở đâu, vì một lỗi nghiêm trọng không bị chặn mà không có chủ sở hữu có tên và không có biện minh bằng văn bản chính xác là khoảng trống mà kiểm toán viên sẽ chê và kẻ tấn công sẽ tìm.
Nhà vô địch bảo mật của chúng ta là năng lực thật hay một cái tên trên sơ đồ tổ chức, và chi phí trung thực để giữ họ thật là bao nhiêu? Mô hình nhà vô địch là cách một đội trung tâm nhỏ với tới hàng trăm kỹ sư, nhưng nó thất bại trong im lặng: vai trò được gán, không giờ nào được bảo vệ, không đào tạo nào đến, và trong một quý nó là một danh hiệu không ai hành động. Lực kéo đối lập luôn là áp lực phân phối, vì giờ bảo mật của nhà vô địch là thứ đầu tiên bị hy sinh khi một hạn chót lù lù, nên câu hỏi là ban lãnh đạo đã thực sự dành riêng thời gian đó hay chỉ ước nó. Hãy mang danh sách các nhà vô địch có tên, số giờ họ thực sự dành cho công việc bảo mật quý trước, đào tạo và hỗ trợ cộng đồng họ nhận được, và các buổi mô hình hóa mối đe dọa họ đã chạy. Với một doanh nghiệp lớn hay cơ quan chính phủ trải qua nhiều đội và hệ thống sống lâu, năng lực này là thứ giữ vòng đời sống giữa các kiểm toán, nên hãy coi việc cấp thiếu nguồn lực cho nó là quyết định để chương trình phân rã hơn là một sơ suất.
Nếu một lỗ hổng nghiêm trọng đáp xuống một phụ thuộc được dùng rộng rãi chiều nay, chúng ta tìm mọi dịch vụ bị ảnh hưởng và chứng minh đã sửa nhanh đến đâu? Phơi nhiễm chuỗi cung ứng là chế độ thất bại biến một lỗi thượng nguồn thành sự cố toàn tổ chức, và câu trả lời phụ thuộc hoàn toàn vào các nền móng bạn đã xây trước đó hoặc chưa: một danh mục vật liệu phần mềm (SBOM) cho mỗi bản phát hành, phụ thuộc được ghim và xác minh kéo qua một kho đăng ký nội bộ được kiểm soát, và một hệ thống dựng được gia cố. Căng thẳng là đầu tư so với tốc độ, vì tạo và truy vấn SBOM cùng định tuyến mọi phụ thuộc qua một kho đăng ký thêm ma sát mà các đội oán cho đến ngày nó cứu họ. Hãy mang bản kiểm kê phụ thuộc hiện tại, liệu bạn có thể truy vấn nó theo gói và phiên bản qua mọi dịch vụ, tình trạng quyền hệ thống dựng, và lần cuối bạn diễn tập một bản vá nhanh. Với doanh nghiệp và cơ quan chính phủ có nghĩa vụ báo cáo luật định và SLA khắc phục theo hợp đồng, khả năng trả lời “hệ thống nào của chúng ta chứa thành phần này” trong vài phút thay vì vài tuần là sự khác biệt giữa một công bố có kiểm soát và một vụ xâm phạm bạn biết qua tin tức.

Góc nhìn theo lĩnh vực

Công ty khởi nghiệp. Không có đội bảo mật và đường băng ít ỏi, hãy xây vòng đời vào công cụ thay vì biên chế: SAST, phân tích thành phần phần mềm và quét bí mật trên mỗi pull request, chỉ làm hỏng bản dựng với các phát hiện mức nghiêm trọng cao để các cổng giữ uy tín. Hãy chỉ định một kỹ sư làm nhà vô địch bảo mật và chạy một buổi mô hình hóa mối đe dọa ba mươi phút cho bất cứ thứ gì chạm vào tiền hay dữ liệu cá nhân. Bỏ qua tài liệu nặng và khung chính thức bây giờ, nhưng giữ nhật ký đường ống, vì chúng trở thành bằng chứng kiểm toán của bạn ngay khoảnh khắc khách hàng doanh nghiệp đầu tiên hỏi SOC 2.

Doanh nghiệp nhỏ. Bạn không có chuyên gia bảo mật và ngân sách eo hẹp, vì vậy hãy dựa vào mặc định an toàn bạn mua hơn là xây: một kho mã được lưu trữ chạy quét phụ thuộc và bí mật giúp bạn, một đường ống được quản lý với các cổng bật, và các khung phát triển với mặc định hợp lý. Hãy áp dụng một tiêu chuẩn lập trình an toàn ngắn, mượn thay vì viết riêng, và chọn một thực hành nhẹ từ một khung đã thiết lập thay vì phát minh một vòng đời. Ưu tiên các công cụ làm hỏng bản dựng trên rủi ro thực ngay từ đầu, để bảo mật đứng vững mà không cần người chăm sóc hằng ngày.

Doanh nghiệp lớn. Ở quy mô lớn qua nhiều đội vấn đề là sự nhất quán và bằng chứng: neo vào một khung, chuẩn hóa các cổng đường ống, và nhúng một nhà vô địch bảo mật được đào tạo vào mỗi đội phân phối kết nối với một nhóm bảo mật sản phẩm trung tâm. Hãy theo dõi SLA khắc phục tập trung và báo cáo độ tuổi cho các ủy ban rủi ro, lưu mô hình mối đe dọa và kết quả quét như sản phẩm kiểm toán, và định tuyến phụ thuộc qua một kho đăng ký nội bộ phát ra SBOM cho mỗi bản phát hành. Mục tiêu là một kỹ sư chuyển giữa các đơn vị kinh doanh gặp cùng các cổng ở mọi nơi và bất kỳ bản phát hành nào cũng truy được từ yêu cầu đến môi trường thực.

Chính phủ. Quy tắc mua sắm, nghĩa vụ minh bạch và trách nhiệm giải trình công định hình mọi lựa chọn, và một vòng đời có tài liệu thường là điều kiện pháp lý để vận hành. Hãy căn chỉnh với một khung được công nhận như NIST SSDF và danh mục kiểm soát liên quan (ví dụ NIST 800-53) ánh xạ vào yêu cầu giấy phép vận hành của bạn, biến mô hình hóa mối đe dọa thành bắt buộc và được rà soát bởi một chức năng bảo đảm độc lập, và thực thi bộ cổng quét đầy đủ với sản phẩm có ký, mang nguồn gốc. Hãy viết SLA khắc phục vào hợp đồng và giữ bản ghi bất biến về phát hiện và bản sửa, vì công chức thừa hưởng các hệ thống này hàng thập kỷ và dấu vết kiểm toán là thứ cho phép một đội mới vận hành chúng an toàn và trả lời trước công chúng.

Ví dụ

Công ty khởi nghiệp. Một công ty khởi nghiệp fintech hai mươi người không thể bố trí đội bảo mật, nên xây vòng đời vào công cụ và thói quen. Mỗi pull request chạy SAST, SCA và quét bí mật, với bản dựng chỉ hỏng trên các phát hiện mức nghiêm trọng cao để các cổng giữ uy tín. Một kỹ sư tình nguyện làm nhà vô địch bảo mật, chạy một buổi mô hình hóa mối đe dọa ba mươi phút cho bất kỳ tính năng nào chạm vào tiền hay dữ liệu cá nhân, và giữ một tiêu chuẩn lập trình an toàn một trang. Định nghĩa hoàn thành bao gồm “không có phát hiện nghiêm trọng chưa xử lý” và “bí mật trong kho, không trong mã.” Khi sau này họ theo đuổi khách hàng doanh nghiệp đầu tiên và một cuộc kiểm toán SOC 2, nhật ký đường ống và bộ theo dõi khắc phục đã là bằng chứng họ cần.

Doanh nghiệp lớn. Một ngân hàng toàn cầu với hàng nghìn kỹ sư neo chương trình của mình vào NIST SSDF, đo độ trưởng thành bằng OWASP SAMM, và so chuẩn với các đồng nghiệp bằng BSIMM. Mỗi đội phân phối có một nhà vô địch bảo mật được đào tạo kết nối với nhóm bảo mật sản phẩm trung tâm. Mô hình hóa mối đe dọa là cổng bắt buộc cho bất kỳ thay đổi nào băng qua ranh giới tin cậy, đầu ra của nó được lưu làm bằng chứng kiểm toán. Đường ống thực thi SAST, SCA, quét IaC và quét bí mật trên bản dựng, với DAST đối chiếu môi trường thử nghiệm, và phụ thuộc chỉ chảy qua một kho đăng ký nội bộ tạo SBOM cho mỗi bản phát hành. SLA khắc phục được theo dõi tập trung và báo cáo cho các ủy ban rủi ro, nên một kỹ sư chuyển giữa các đơn vị kinh doanh thấy cùng các cổng và kiểm toán viên có thể truy bất kỳ bản phát hành nào từ yêu cầu đến môi trường thực.

Chính phủ. Một cơ quan thuế quốc gia vận hành dưới nghĩa vụ bảo mật luật định và không thể phát hành phần mềm chưa vượt qua một vòng đời xác định. Nó căn chỉnh thực hành theo NIST SSDF và các biện pháp kiểm soát NIST 800-53, ánh xạ vào yêu cầu giấy phép vận hành của nó. Yêu cầu bảo mật và ca lạm dụng được viết cho mọi dịch vụ hướng đến công dân, mô hình mối đe dọa là bắt buộc và được rà soát bởi một chức năng bảo đảm độc lập (chương 10.2), và mọi đường ống thực thi bộ cổng quét đầy đủ với sản phẩm có ký, mang nguồn gốc. SLA khắc phục là theo hợp đồng, và một bản ghi bất biến về phát hiện và bản sửa hỗ trợ các cuộc kiểm toán cấp phép tiếp tục vận hành. Vì công chức thừa hưởng các hệ thống này hàng thập kỷ, vòng đời có tài liệu cho phép một đội mới duy trì một dịch vụ an toàn rất lâu sau khi các tác giả đã chuyển đi.

Luận chứng kinh doanh: động lực, ROI và TCO

Lợi tức của một vòng đời an toàn là chi phí của các vụ xâm phạm, sự cố và việc làm lại khẩn cấp mà nó ngăn chặn, trừ chi phí khiêm tốn, chủ yếu một lần của việc xây các cổng. Kinh tế học đều chỉ cùng một hướng: lỗi bị bắt càng sớm càng rẻ. Một lỗi thiết kế bị bắt trong mô hình mối đe dọa là một cuộc trò chuyện bảng trắng; cùng lỗi bị bắt trên môi trường thực là một sự cố kèm công bố, khắc phục, phơi nhiễm quy định và thiệt hại danh tiếng. Vì các cổng tự động là hạ tầng tái sử dụng, chi phí của chúng được trả một lần và phân bổ qua mọi thay đổi tương lai, trong khi các sự cố chúng ngăn mỗi cái sẽ tốn hơn nhiều so với cả chương trình.

Tổng chi phí sở hữu bị chi phối không phải bởi giấy phép công cụ mà bởi điều chỉnh và quy trình. Một vòng đời không điều chỉnh làm ngập các đội bằng dương tính giả lãng phí sự chú ý kỹ thuật, sinh ra cảnh báo bị bỏ qua, và kết thúc bằng các cổng bị tắt, tệ hơn không có chương trình vì nó chế tạo sự tự tin giả. Hãy ngân sách cho mặt con người: thời gian của nhà vô địch, quy trình phân loại, và điều chỉnh liên tục. Để trình bày lập luận với ban lãnh đạo, hãy nối vòng đời với các chỉ số họ đã theo dõi: tỷ lệ khiếm khuyết thoát, thời gian trung bình để khắc phục, phát hiện kiểm toán, và chi phí chu kỳ của các bất ngờ bảo mật giai đoạn muộn. Trong bối cảnh chịu quy định và chính phủ, một vòng đời có tài liệu, được thực thi thường là điều kiện tiên quyết để vận hành, biến bảo mật từ trung tâm chi phí thành giấy phép làm ăn.

Phản mẫu và cạm bẫy

Sân khấu bảo mật ở cuối: một lần quét trước phát hành hay kiểm thử xâm nhập hằng năm thay cho một vòng đời, nên lỗi được tìm thấy khi chúng đắt nhất.
Lan tràn công cụ không có quy trình: mua SAST, DAST và SCA nhưng không có chủ sở hữu, SLA hay phân loại, nên phát hiện chất vào một hàng đợi mà ai cũng bỏ qua.
Mệt mỏi vì cảnh báo từ cổng không điều chỉnh: công cụ ồn ào đánh dấu mọi thứ, dạy kỹ sư bấm qua cảnh báo cho đến khi các cổng chẳng có nghĩa gì.
Nút thắt người gác cổng: một đội trung tâm phải phê duyệt mọi thay đổi, trở thành hàng đợi các đội đi vòng hoặc oán giận.
Nhà vô địch chỉ trên danh nghĩa: vai trò được gán nhưng không có đào tạo, thời gian hay sự ghi nhận, nên nó thoái hóa thành một danh hiệu rỗng.
Mô hình mối đe dọa một lần, không bao giờ nữa: một tài liệu giai đoạn thiết kế viết lúc khởi động và không bao giờ xem lại khi thiết kế đổi.
Sùng bái hình thức khung: áp dụng các hoạt động SDL hay SSDF như nghi lễ mà không điều chỉnh theo rủi ro thực hay kiểm tra chúng có đổi kết quả.
Chuỗi cung ứng không được quản lý: kéo phụ thuộc thẳng từ internet công cộng, không ghim và không xác minh, không SBOM và hệ thống dựng được cấp quá nhiều quyền.
SLA trên giấy: hạn chót khắc phục không ai đo, nên các lỗi nghiêm trọng lặng lẽ già đi quá hạn chót được cho là của chúng.

Mô hình trưởng thành

Mức 1, Khởi đầu: Bảo mật là phần thêm muộn và phần lớn phản ứng. Kiểm thử diễn ra gần phát hành nếu có, không có mô hình hóa mối đe dọa, quét là thủ công hoặc vắng mặt, phát hiện được xử lý tùy nghi, và chuỗi cung ứng không được quản lý. Một tính năng nhất định có an toàn hay không phụ thuộc hoàn toàn vào ai viết nó.
Mức 2, Phát triển: Các thực hành cơ bản xuất hiện nhưng đáp xuống không đều. Một số đường ống chạy SAST hay SCA và quét bí mật, rà soát mã nhắc đến bảo mật, và các phát hiện nghiêm trọng được sửa, nhưng độ bao phủ rải rác, mô hình hóa mối đe dọa hiếm, khắc phục thiếu SLA được theo dõi, và mỗi đội ứng biến cách tiếp cận riêng nên ngưỡng khác nhau rất nhiều giữa các nhóm.
Mức 3, Chuẩn hóa: Một vòng đời có tài liệu neo vào một khung đã thiết lập được thực thi toàn tổ chức. Yêu cầu bảo mật và ca lạm dụng, một cổng mô hình hóa mối đe dọa, tiêu chuẩn lập trình an toàn, bộ cổng đường ống đầy đủ, bảo mật trong định nghĩa hoàn thành, SLA khắc phục được theo dõi, nhà vô địch bảo mật, và biện pháp kiểm soát chuỗi cung ứng là tiêu chuẩn qua các đội, để một kỹ sư gặp cùng kỳ vọng ở bất cứ đâu họ làm việc.
Mức 4, Quản lý: Chương trình được đo và kiểm soát theo các đường cơ sở. Các chỉ báo dẫn đầu được theo dõi và báo cáo: độ bao phủ mô hình mối đe dọa của các thay đổi quan trọng, phần trăm đường ống có các cổng kỳ vọng được bật, thời gian trung bình để khắc phục theo mức nghiêm trọng so với SLA, tỷ lệ khiếm khuyết thoát, và tỷ lệ dương tính giả theo công cụ. Mục tiêu được đặt, sai lệch kích hoạt hành động, và quyết định đi hay không đi dựa trên bằng chứng thay vì ý kiến, để ban lãnh đạo thấy được liệu vòng đời có thực sự đứng vững thay vì giả định.
Mức 5, Điều phối: Chương trình liên tục cải thiện và thích ứng, tích hợp trong toàn tổ chức. Khiếm khuyết thoát điều chỉnh các cổng, công cụ ồn ào được cắt tỉa, các lớp lỗi lặp lại thúc đẩy mặc định an toàn và đào tạo mới, nhà vô địch hình thành một cộng đồng hoạt động, nguồn gốc chuỗi cung ứng được xác minh từ đầu đến cuối, và hoạch định bảo mật được đan vào phân phối và quản lý rủi ro để vòng đời tự cân bằng lại khi bức tranh mối đe dọa và doanh nghiệp dịch chuyển.

Ý tưởng để thảo luận

Giai đoạn nào của vòng đời của bạn yếu nhất hôm nay, và cần gì để thêm một cổng thật ở đó thay vì một khẩu hiệu?
Nếu một lỗ hổng nghiêm trọng trong một phụ thuộc được công bố chiều nay, mất bao lâu để mọi dịch vụ bị ảnh hưởng được vá, và làm sao bạn biết?
Lằn ranh giữa một cổng chặn bản dựng và một cổng chỉ cảnh báo nằm ở đâu, và ai quyết định phát hiện nào nằm ở bên nào?
Nhà vô địch bảo mật của bạn có được cho giờ thật và sự ghi nhận, hay vai trò là một danh hiệu lặng lẽ phân rã?
Bạn có thể đưa ra, cho kiểm toán viên, mô hình mối đe dọa và kết quả quét của một bản phát hành bạn đã phát hành tháng trước không?
Chỉ số đơn lẻ nào, nếu bạn bắt đầu theo dõi nó sprint tới, sẽ thay đổi nhiều nhất cách các đội của bạn thực sự hành xử quanh bảo mật?

Những điểm cần ghi nhớ

Vòng đời phát triển phần mềm an toàn xây và xác minh bảo mật trong mọi giai đoạn, dịch chuyển lỗi sang trái đến nơi chúng rẻ nhất để sửa, và nó là xương sống quy trình nối bảo mật ứng dụng (chương 4.2) với vận hành bảo mật (chương 4.4).
Giao cho mỗi giai đoạn một chủ sở hữu và một cổng: yêu cầu bảo mật và ca lạm dụng, một cổng mô hình hóa mối đe dọa trong thiết kế, tiêu chuẩn lập trình an toàn, bảo mật trong rà soát mã, và bảo mật trong định nghĩa hoàn thành.
Đặt mỗi công cụ tự động ở nơi nó vừa: SAST, SCA, quét bí mật và quét IaC kiểm soát bản dựng, trong khi DAST và IAST xác minh hệ thống đang chạy, và điều chỉnh mọi cổng để nó thất bại trên điều quan trọng và không kêu sói.
Mở rộng chương trình bằng nhà vô địch bảo mật nhúng trong đội, neo nó vào một khung đã thiết lập (SDL của Microsoft, OWASP SAMM, BSIMM, hay NIST SSDF), và chạy khắc phục theo SLA tường minh, được đo.
Phòng thủ chuỗi cung ứng từ đầu đến cuối bằng SBOM, phụ thuộc được xác minh, và một hệ thống dựng được gia cố, và đo toàn bộ chương trình để nó tiếp tục cải thiện thay vì phân rã thành nghi lễ.

Tài liệu tham khảo và đọc thêm

Michael Howard và Steve Lipner, The Security Development Lifecycle
Adam Shostack, Threat Modelling: Designing for Security
Gary McGraw, Software Security: Building Security In
National Institute of Standards and Technology, Secure Software Development Framework (SSDF), Special Publication 800-218
OWASP Foundation, Software Assurance Maturity Model (SAMM)
Synopsys, Building Security In Maturity Model (BSIMM)
OWASP Foundation, OWASP Application Security Verification Standard (ASVS)
Laura Bell, Michael Brunton-Spall, Rich Smith và Jim Bird, Agile Application Security