Nhà Trắng đã hủy bỏ các quy định bắt buộc về tuân thủ an ninh phần mềm do lo ngại về gánh nặng hành chính.
Văn phòng Quản lý và Ngân sách (OMB) đã ban hànhBản ghi nhớ M-26-05(PDF) chính thức thu hồi chính sách năm 2022 được gọi là M-22-18 và chính sách bổ sung năm 2023 của nó, M-23-16.
Sự đảo ngược này thay đổi bối cảnh quản trị cho các kiến trúc sư doanh nghiệp và kỹ sư nền tảng phục vụ các hợp đồng liên bang hoặc tuân theo các tiêu chuẩn liên bang.
Các chỉ thị trước đây yêu cầu các phương pháp phát triển phần mềm an toàn cụ thể, bao gồm việc tạo và duy trì rộng rãi Hóa đơn Vật liệu Phần mềm (SBOM).
Bản ghi nhớ mới từ Giám đốc OMB Russell T.
Vought lập luận rằng M-22-18 “đã áp đặt các quy trình kế toán phần mềm chưa được chứng minh và gây nặng nề, ưu tiên sự tuân thủ hơn là các khoản đầu tư an ninh thực sự.”
Tim Mackey, Trưởng bộ phận Chiến lược Rủi ro Chuỗi Cung ứng Phần mềm tạiBlack Duck, lưu ý rằng việc hủy bỏ M-22-18 khiến bản ghi nhớ mới trên thực tế thu hồi các yếu tố đảm bảo phần mềm được mô tả trong Sắc lệnh Hành pháp 14028.
“Chỉ còn các chủ đề về Zero Trust và SBOM là những yếu tố quan trọng còn lại của EO 14028,” Mackey giải thích.
Ông cảnh báo rằng trong khi kiến trúc Zero Trust và SBOM cung cấp tính minh bạch nền tảng, “cả hai đều không phải là mô hình giảm thiểu rủi ro hiệu quả nếu đứng riêng lẻ.”
Luận điểm trung tâm của hướng dẫn mới là phân quyền về thẩm quyền an ninh.
Trách nhiệm giờ đây được đặt rõ ràng lên các trưởng cơ quan cá nhân để xác định tư thế an ninh phù hợp cho môi trường cụ thể của họ.
OMB tuyên bố rằng không có phương pháp “phổ quát, phù hợp cho tất cả” để bảo mật mạng lưới chính phủ.
Đối với các trưởng nhóm kỹ thuật, điều này cho thấy sự chuyển hướng khỏi việc tuân thủ cứng nhắc và gần như dựa trên danh sách kiểm tra sang một mô hình ưu tiên mô hình hóa mối đe dọa và ngữ cảnh.
Các cơ quan giờ đây phải xác thực bảo mật của nhà cung cấp bằng cách sử dụng các nguyên tắc phát triển an toàn và tiến hành đánh giá rủi ro toàn diện.
Cách tiếp cận này cho phép các bộ phận điều chỉnh các yêu cầu đảm bảo của họ thay vì tuân thủ một tiêu chuẩn chung cho toàn chính phủ có thể không phù hợp với mọi nhiệm vụ.
Nội dung chính
Tác động đến DevSecOps và các chuỗi công cụ
Nhiều nhóm kỹ thuật đã dành ba năm qua để tích hợp các quy trình tạo và xác nhận SBOM vào đường ống CI/CD của họ để đáp ứng các yêu cầu của M-22-18 vừa bị hủy bỏ.
Chỉ thị mới không cấm các thực hành này nhưng thay đổi trạng thái của chúng từ bắt buộc sang tùy chọn.
Bản ghi nhớ làm rõ rằng các cơ quan “có thể chọn sử dụng các tài nguyên phát triển phần mềm an toàn trên toàn chính phủ được phát triển theo M-22-18,” đặc biệt đề cập đếnMẫu Xác nhận Phát triển Phần mềm An toàn.
Hơn nữa, các cơ quan vẫn giữ tùy chọn áp dụng các điều khoản hợp đồng yêu cầu nhà sản xuất phần mềm cung cấp SBOM hiện tại khi được yêu cầu.
Tuy nhiên, lý lẽ đằng sau sự thay đổi đối với tuân thủ an ninh phần mềm đã thu hút sự giám sát từ các chuyên gia trong ngành.
Mackey chỉ ra một mâu thuẫn trong hướng dẫn mới:
M-26-05 đầu tiên bác bỏ việc tuân thủ Khung Phát triển Phần mềm An toàn (SSDF) là “chưa được chứng minh và gây nặng nề,” nhưng sau đó lại liên kết đến chính SSDF đó như một tài nguyên để các cơ quan sử dụng.
“Mặc dù có thể tranh luận liệu các bản tự xác nhận – chẳng hạn như trong M-22-18 – có giá trị nhiều hay không, thực tế là việc xác nhận các yếu tố của SSDF đã là một yêu cầu trong vài năm, và bất kỳ gánh nặng nào liên quan đều phản ánh nhu cầu cải thiện các thực hành an ninh mạng,” Mackey giải thích.
Đối với các kỹ sư nền tảng, điều này tạo ra một điểm quyết định.
Trong khi quy định bắt buộc của liên bang đã bị giải thể, tính hữu ích của khả năng hiển thị chuỗi cung ứng vẫn còn cho việc quản trị an ninh nội bộ.
Chính phủ Hoa Kỳ và các đồng minh đã phát hành hướng dẫn nêu bật lợi thế của việc áp dụng SBOM, cho thấy thực hành này vẫn giữ giá trị vượt ra ngoài việc tuân thủ.
Các nhóm đã tự động hóa các tạo tác này có thể thấy việc duy trì chúng cho mục đích gỡ lỗi, tuân thủ giấy phép và quản lý lỗ hổng là hiệu quả, ngay cả khi áp lực bên ngoài đã giảm bớt.
Phần cứng và môi trường đám mây
Một điểm mở rộng đáng chú ý trong M-26-05 là việc đưa rõ ràng bảo mật phần cứng vào.
OMB lưu ý rằng chính sách trước đây “đã bỏ sót việc tính đến các mối đe dọa do phần cứng không an toàn gây ra.” Hướng dẫn mới chỉ đạo các cơ quan phát triển các chính sách đảm bảo bao gồm cả phần mềm và phần cứng.
Điều này đưa cơ sở hạ tầng vật lý vào phạm vi quản lý rủi ro chuỗi cung ứng.
Bản ghi nhớ hướng dẫn các cơ quan đến ‘Khung Hóa đơn Vật liệu Phần cứng (HBOM) cho Quản lý Rủi ro Chuỗi Cung ứng‘ được CISA xuất bản năm 2023.
Các kiến trúc sư thiết kế hệ thống tại chỗ hoặc lai sẽ cần xem xét cách xác thực nguồn gốc của các thành phần vật lý cùng với ngăn xếp phần mềm của họ.
Về các nền tảng đám mây, hướng dẫn đưa ra lời khuyên cụ thể cho các cơ quan chọn duy trì các yêu cầu SBOM.
Nó đề xuất rằng hợp đồng nên quy định rằng nhà sản xuất phải cung cấp SBOM của “môi trường sản xuất runtime” khi được yêu cầu.
Sự phân biệt này giải quyết sự khác biệt giữa phân tích mã tĩnh và trạng thái thực tế của một triển khai đám mây trực tiếp, vốn thường xuyên có sự khác biệt.
Điều hướng tuân thủ an ninh phần mềm bị phân mảnh
Tác động trực tiếp của M-26-05 là loại bỏ các quy trình “kế toán phần mềm” cứng nhắc mà OMB cho là gây phân tâm.
Tuy nhiên, yêu cầu về sự cẩn trọng an ninh vẫn còn.
Các cơ quan vẫn được yêu cầu duy trì một danh mục đầy đủ về phần mềm và phần cứng.
Các trưởng nhóm nền tảng nên lường trước một tập hợp yêu cầu bị phân mảnh khi các cơ quan khác nhau phát triển các chính sách “phù hợp với xác định rủi ro và nhu cầu nhiệm vụ của họ.” Một cơ quan có thể tiếp tục yêu cầu xác nhận đầy đủ và SBOM, trong khi cơ quan khác có thể ưu tiên các phương pháp xác thực khác.
Sự biến đổi này sẽ đòi hỏi các đường ống phát hành linh hoạt có thể tạo ra các tạo tác tuân thủ theo yêu cầu thay vì mặc định.
Bản ghi nhớ cũng tham chiếu đếnKhung Phát triển Phần mềm An toànnhư một nguồn tài nguyên thông tin và tùy chọn tiếp tục.
Điều này chỉ ra rằng trong khi cơ chế thực thi đã thay đổi, các tiêu chuẩn kỹ thuật cơ bản cho phát triển an toàn vẫn là các tài liệu tham khảo có liên quan cho các nhóm kỹ thuật.
Việc hủy bỏ M-22-18 báo hiệu sự chuyển dịch khỏi các quy định tuân thủ an ninh phần mềm tập trung hóa hướng tới việc ra quyết định dựa trên rủi ro.
Đối với các nhà sản xuất phần mềm và phần cứng, điều này có thể làm giảm gánh nặng hành chính của việc báo cáo phổ quát nhưng làm tăng tính phức tạp của việc quản lý yêu cầu khách hàng.
Xem thêm:Keeper Security:
Các mối đe dọa chuỗi cung ứng phần mềm đã phát triển
Bạn muốn tìm hiểu thêm về an ninh mạng từ các chuyên gia hàng đầu?Hãy khám pháCyber Security & Cloud Expođược tổ chức tại Amsterdam, California và London.
Sự kiện toàn diện này là một phần củaTechExvà diễn ra cùng với các sự kiện công nghệ hàng đầu khác bao gồmAI & Big Data Expo.
Nhấpvào đâyđể biết thêm thông tin.
Developer được cung cấp bởiTechForge Media.
Khám phá các sự kiện và hội thảo trực tuyến về công nghệ doanh nghiệp sắp tớitại đây.







![[Tự học C++] Số dấu phẩy động(float, double,…) trong C++](https://cafedev.vn/wp-content/uploads/2019/12/cafedevn_c_develoment-100x70.jpg)

