Bản ghi nhớ từ OMB yêu cầu các tổ chức liên bang tuân thủ hướng dẫn của về phát triển phần mềm an toàn và bảo mật chuỗi cung ứng khi sử dụng phần mềm của bên thứ ba. Để đảm bảo tuân thủ, các tổ chức ít nhất sẽ phải có được một biểu mẫu tự chứng thực từ các nhà phát triển phần mềm có sản phẩm mà họ đang sử dụng hoặc có kế hoạch sử dụng.

“Việc tự chứng thực của nhà sản xuất phần mềm đóng vai trò như một tuyên bố tuân thủ được mô tả bởi Hướng dẫn của NIST. Tổ chức phải có tự chứng thực cho tất cả phần mềm được sử dụng của bên thứ ba tuân theo các yêu cầu của bản ghi nhớ này, bao gồm cả việc gia hạn phần mềm và các thay đổi phiên bản lớn”, bản ghi nhớ viết. OMB lưu ý rằng tự chứng thực là mức tối thiểu bắt buộc, nhưng các tổ chức cũng có thể đưa ra các quyết định dựa trên rủi ro đối với đánh giá của bên thứ ba nếu sản phẩm hoặc dịch vụ đang được mua là quan trọng.

Các tổ chức có thể yêu cầu hóa đơn vật liệu phần mềm SBOM (danh sách các thành phần trong một phần mềm) và các bằng chứng khác có thể chứng minh sự tuân thủ của nhà cung cấp và họ cũng có thể yêu cầu triển khai chương trình tiết lộ lỗ hổng bảo mật - VDP (một khuôn khổ có cấu trúc cho các nhà nghiên cứu phát hiện về lỗ hổng bảo mật trên hệ thống và các sản phẩm của tổ chức đó).

Ngoài ra, các tổ chức được yêu cầu kiểm kê tất cả phần mềm tuân theo các yêu cầu mới (với phần mềm quan trọng nằm trong danh sách riêng), tạo một quy trình để thông báo các yêu cầu này với nhà cung cấp phần mềm và đảm bảo rằng họ nhận được thư xác nhận cần thiết từ nhà cung cấp. Thư xác nhận phải được nhận trong vòng 270 ngày đối với phần mềm quan trọng và trong vòng 1 năm đối với phần mềm khác.

Cơ quan An ninh mạng và Hoa Kỳ (CISA) đã được giao nhiệm vụ tạo ra một biểu mẫu tự chứng thực tiêu chuẩn để các tổ chức có thể sử dụng. Bản ghi nhớ được đưa ra ngay sau khi CISA, NSA và Văn phòng Giám đốc Tình báo Quốc gia (ODNI) bắt đầu xuất bản một loạt tài liệu hướng dẫn tập trung vào việc đảm bảo , trong đó tài liệu đầu tiên dành cho các nhà phát triển.

Vào tháng 1/2022, Nhà Trắng đã tổ chức một hội nghị thượng đỉnh, nơi các đại diện của chính phủ và lĩnh vực công nghệ tập trung để thảo luận về bảo mật phần mềm nguồn mở. Sự kiện đó được tổ chức ngay sau khi lỗ hổng được phát hiện.

Các tổ chức cần có quy trình phát triển phần mềm an toàn và hơn thế nữa

Nhiều năm trước, để có phần mềm cần có quy trình phát triển phần mềm an toàn, xuyên suốt từ khâu phân tích thiết kế cho tới phát triển, kiểm thử. Tuy nhiên, với việc sử dụng phần mềm nguồn mở và thuê ngoài các dịch vụ phát triển phần mềm, mua phần mềm từ rất nhiều đối tác khác nhau, các tổ chức cần làm nhiều hơn nữa để đảm bảo kiểm soát chặt chẽ toàn bộ chuỗi cung ứng phần mềm, từ khi phát triển cho tới khâu triển khai ứng dụng. Nếu không xem xét đầy đủ mọi khía cạnh, mọi nguy cơ đe dọa tiềm ẩn, các tổ chức không thể đảm bảo an toàn cho những phần mềm của họ, dù là tự phát triển hay thuê ngoài. Tài liệu hướng dẫn dành cho nhà phát triển của CISA, NSA và ODNI chỉ ra rằng trong vòng đời của phần mềm có thể tồn tại nhiều loại lỗ hổng do những nguyên nhân khác nhau:

Thứ nhất, các tính năng không được đưa vào tài liệu hoặc chức năng có thể gây rủi ro.
Thứ hai, những điều kiện, chức năng hay giả định không được biết hoặc bị thay đổi từ môi trường kiểm thử sang môi trường triển khai thực.
Thứ ba, nhà cung cấp thay đổi chủ sở hữu hoặc vị trí địa lý.
Thứ tư, không đảm bảo môi trường phát triển an toàn trong nội bộ hoặc tại nhà cung cấp.

Cụ thể hơn, quá trình phát triển và phân phối phần mềm có những mối đe dọa phổ biến sau:

Thứ nhất, kẻ xấu cố ý đưa mã độc vào hoặc nhà phát triển vô tình đưa mã dễ bị tấn công vào sản phẩm.
Thứ hai, cố ý hay vô tình kết hợp mã nguồn hoặc mã nhị phân của bên thứ ba dễ bị tấn công vào sản phẩm.
Thứ ba, khai thác các điểm yếu trong quy trình dựng phần mềm được sử dụng để đưa mã độc vào bên trong thành phần của sản phẩm.
Thứ tư, sửa đổi sản phẩm trong quy trình phân phối, dẫn đến việc đưa mã độc vào gói ban đầu, bản cập nhật hoặc gói nâng cấp do khách hàng triển khai.

Chỉ xét riêng quá trình viết mã, việc sửa đổi mã nguồn có thể xảy ra ở cấp nhà phát triển trong một hoặc nhiều tình huống sau:

Một là, Khi một lập trình viên bị tác động bởi ảnh hưởng bên ngoài hoặc không hài lòng với tổ chức. Lập trình viên cố tình làm sai quy trình là một mối đe dọa khó phát hiện và đánh giá. Một nhân viên có thể chịu áp lực từ những tác động bên ngoài hoặc có thể không hài lòng với các chính sách trong tổ chức. Một nhà phát triển có kiến thức sâu rộng về cơ sở mã và là chuyên gia về ngôn ngữ lập trình có thể thiết kế các lỗ hổng rất khó phát hiện. Ngoài ra, quyền truy cập vào các chi tiết thiết kế không được công khai có thể cung cấp thông tin các vùng mã có chứa điểm yếu bảo mật dễ bị khai thác. Sau khi được triển khai và đưa vào cơ sở hạ tầng, các lỗ hổng tích hợp sẽ được biên dịch, ký và băm, cho phép vượt qua các kiểm tra xác thực cấp cao mà không để lộ bất kỳ dấu hiệu nào.

Hai là, Khi lập trình viên chủ quan hoặc thiếu những kỹ năng bảo mật. Các lập trình viên có tâm lý chủ quan hoặc không được trang bị về những kỹ năng bảo mật cần thiết và thực hành có thể vô tình đưa các lỗ hổng trong mã nguồn. Các loại lỗ hổng có thể bao gồm từ tràn bộ nhớ đệm đến các lỗ hổng logic khó phát hiện. Những lỗi này có thể tồn tại trong sản phẩm trong một thời gian dài và cung cấp phương thức xâm phạm hệ thống dễ dàng cho những kẻ xấu phát hiện ra chúng.

Ba là, Khi các lập trình viên đưa các tính năng vào một sản phẩm để hỗ trợ quá trình phát triển. Các nhà phát triển đôi khi thêm các tính năng gỡ lỗi vào sản phẩm để tạo điều kiện cho các quy trình khắc phục sự cố, thiết lập hoặc báo cáo sự cố thường được thực hiện trong quá trình phát triển ban đầu. Trong nhiều trường hợp, các tính năng này là các cho phép nhóm phát triển lấy được số liệu thống kê và nhật ký, ra lệnh từ xa để cấu hình lại hệ thống đang được phát triển. Mặc dù có thể hữu ích, nhưng chúng thường được tích hợp chặt chẽ vào các thành phần cốt lõi của sản phẩm, nên thường khó loại bỏ chúng. Các tính năng này thường được lên kế hoạch để loại bỏ hoàn toàn trước khi phát hành, nhưng trong một số tình huống, chúng không bị loại bỏ do đã tích hợp vào cấu phần cốt lõi và mức độ công việc cần làm hoặc rủi ro liên quan đến việc loại bỏ chúng khiến tiến độ phát hành sản phẩm có thể bị chậm trễ. Một điều đáng lo ngại khác là khi chỉ một phần hoặc một chức năng của ứng dụng yêu cầu các đặc quyền nâng cao, nhưng toàn bộ ứng dụng lại được cấu hình để chạy với các đặc quyền cần thiết để thực hiện tác vụ đó. Đặc quyền nên được nâng lên để có thể hoàn thành các chức năng cụ thể và sau đó cần được hạ xuống ngay lập tức để giảm bề mặt tấn công.

Bốn là, Khi các hệ thống phát triển từ xa không được bảo mật hoặc khi các biện pháp bảo vệ bị bỏ qua. Một thực tế phổ biến trong các tổ chức là cho phép nhân viên hoặc đối tác truy cập từ xa vào môi trường phát triển (thường là qua ). Mặc dù điều này tạo điều kiện cho quá trình phát triển, nhưng làm việc từ xa đi luôn kèm với sự rủi ro. Mạng gia đình hoặc mạng văn phòng từ xa có thể không được bảo vệ nghiêm ngặt. Ngoài ra, các nhân viên làm việc từ xa có thể dễ bị cám dỗ hơn trong việc sử dụng các ứng dụng thường bị cấm như mạng xã hội, trò chơi và trong một số trường hợp, loại bỏ các biện pháp bảo vệ máy tính cục bộ để sử dụng dễ dàng hơn. Trong môi trường này, các hệ thống này có thể bị xâm phạm, cho phép kẻ xấu sử dụng trong môi trường từ xa để truy cập và sửa đổi mã nguồn trong cơ sở hạ tầng được bảo vệ của tổ chức.

Năm là, Khi tài khoản và thông tin đăng nhập cho nhân viên không hoạt động nhưng vẫn còn khả dụng. Khi nhân viên chuyển sang một dự án khác hoặc nghỉ làm trong một thời gian dài, các đặc quyền và tài khoản của họ thường vẫn hoạt động và có thể được sử dụng để thực hiện hành vi độc hại mà chủ sở hữu tài khoản không hề hay biết. Trong trường hợp này, chủ sở hữu tài khoản không giám sát việc sử dụng tài khoản và không biết về bất kỳ hành vi độc hại nào được thực hiện với tài khoản đó. Chính vì vậy, các tổ chức được khuyến nghị nên vô hiệu hóa các tài khoản không hoạt động trong khoảng thời gian nhất định trước các mối nguy cơ tiềm ẩn có thể xảy ra.