OPSWAT 'S Secure Khung SDLC: Cam kết về khả năng phục hồi và an ninh phòng thủ chuyên sâu

Những kẻ xấu nhắm vào hệ thống để kiếm lợi nhuận hoặc phá hoại, dẫn đến chi phí, rủi ro kinh doanh và tổn hại đến danh tiếng của tổ chức. 

Theo một khảo sát gần đây, chi phí sửa lỗi bảo mật cao hơn 30 lần khi phát hiện lỗi trong quá trình sản xuất so với giai đoạn phân tích và yêu cầu.

OPSWAT 'S Secure Khung SDLC xác định các phương pháp có cấu trúc và nguyên tắc bảo mật hướng dẫn phát triển phần mềm an toàn. 

OPSWAT theo Agile Software Vòng đời phát triển. Để tuân thủ đầy đủ các yêu cầu của khách hàng, chúng tôi đã áp dụng Secure Khung SDLC đáp ứng các yêu cầu quy định và tiêu chuẩn quốc tế. Cách tiếp cận này củng cố cam kết của chúng tôi về cải tiến liên tục và khả năng phục hồi trong bối cảnh an ninh mạng đang thay đổi.

OPSWAT 'S Secure Khung SDLC được xây dựng dựa trên NIST SP 800-218 SSDF ( Secure Software Khung phát triển), đảm bảo rằng bảo mật được cấu trúc, có thể đo lường và áp dụng nhất quán trong mọi giai đoạn của quy trình phát triển phần mềm.  

Bằng cách tích hợp các phương pháp hay nhất của SSDF, OPSWAT duy trì thế trận bảo mật chủ động, lồng ghép bảo mật vào mọi giai đoạn phát triển phần mềm—từ lập kế hoạch và thiết kế đến triển khai, xác minh và giám sát liên tục. 

Chứng nhận tuân thủ của từng sản phẩm được cung cấp theo yêu cầu cho khách hàng là Chính phủ Liên bang Hoa Kỳ. Xem thông tin liên hệ bên dưới.

Khi các quy định về an ninh mạng tiếp tục phát triển, OPSWAT vẫn cam kết điều chỉnh Secure Khung SDLC với các yêu cầu quy định toàn cầu, bắt đầu từ Đạo luật Khả năng phục hồi Mạng của EU và Chỉ thị NIS2. Bằng cách chủ động thích ứng với các tiêu chuẩn mới nổi, OPSWAT đảm bảo rằng nó Secure SDLC vẫn toàn diện, tuân thủ và linh hoạt trong bối cảnh quản lý ngày càng phức tạp.

Việc duy trì bảo mật thông tin mạnh mẽ là rất quan trọng đối với tính toàn vẹn hoạt động và tuân thủ quy định. OPSWAT 'S Secure Khung SDLC kết hợp các nguyên tắc ISO 27001 ISMS (Hệ thống quản lý bảo mật thông tin), đảm bảo các biện pháp kiểm soát bảo mật, chiến lược quản lý rủi ro và các biện pháp tuân thủ được tích hợp liền mạch vào hoạt động của các sản phẩm đám mây của chúng tôi. 

Với tư cách là nhà cung cấp và người tiêu dùng các giải pháp bảo mật của chúng tôi, OPSWAT áp dụng các chính sách bảo mật nội bộ của công ty, đảm bảo rằng các sản phẩm được chứng nhận của chúng tôi tuân thủ các kỳ vọng về bảo mật cấp doanh nghiệp trước khi triển khai.  

Xem thêm chi tiết về Tuân thủ & Chứng nhận .

Để đảm bảo các tiêu chuẩn cao nhất về chất lượng phần mềm, OPSWAT 'S Secure Khung SDLC được tích hợp vào Hệ thống Quản lý Chất lượng (QMS) ISO 9001. QMS thiết lập các biện pháp kiểm soát chất lượng đã được kiểm toán cho các quy trình quản trị, quản lý thay đổi và liên chức năng, hỗ trợ việc xác định, thiết kế, phát triển, sản xuất và bảo trì sản phẩm và dịch vụ hỗ trợ, mở rộng ra ngoài phạm vi R&D sang các lĩnh vực như bán hàng, hỗ trợ khách hàng, công nghệ thông tin và nhân sự.  

Cách tiếp cận này củng cố cam kết của chúng tôi đối với phương pháp tiếp cận có cấu trúc, dựa trên rủi ro đối với quản lý chất lượng, đảm bảo bảo mật ứng dụng vẫn là yếu tố cần cân nhắc không thể thiếu trong mọi chức năng kinh doanh.

Xem thêm chi tiết về Tuân thủ & Chứng nhận .

Mô hình trưởng thành đảm bảo Software OWASP (SAMM) là một khuôn khổ toàn diện được thiết kế để giúp các tổ chức đánh giá, xây dựng và triển khai các chiến lược bảo mật phần mềm hiệu quả trong SDLC hiện tại của họ.

Là một khuôn khổ mã nguồn mở, SAMM được hưởng lợi từ những đóng góp toàn cầu, đảm bảo một phương pháp tiếp cận hợp tác và liên tục phát triển đối với bảo mật ứng dụng. Phương pháp luận có cấu trúc của nó cho phép các tổ chức phân tích và cải thiện vòng đời phát triển một cách hiệu quả và có thể đo lường được. SAMM hỗ trợ toàn bộ vòng đời phát triển. SAMM không phụ thuộc vào công nghệ và quy trình. SAMM mang tính tiến hóa và định hướng rủi ro. Bằng cách tận dụng SAMM, các nhóm có được những hiểu biết thiết thực về các lỗ hổng bảo mật và có thể nâng cao năng lực bảo mật của mình một cách có hệ thống trong suốt vòng đời phát triển.

Tiêu chuẩn Xác minh Bảo mật Ứng dụng OWASP (ASVS) là một khuôn khổ được công nhận toàn cầu, được thiết kế để thiết lập một phương pháp tiếp cận có cấu trúc, có thể đo lường và thực hiện được đối với bảo mật ứng dụng web. ASVS cung cấp cho các nhà phát triển và nhóm bảo mật một bộ yêu cầu bảo mật và hướng dẫn xác minh toàn diện để đảm bảo các ứng dụng đáp ứng các thông lệ tốt nhất của ngành. 

Là một khuôn khổ mã nguồn mở, ASVS được hưởng lợi từ những đóng góp rộng rãi từ cộng đồng an ninh toàn cầu, đảm bảo rằng khuôn khổ này luôn cập nhật các mối đe dọa mới nổi và các tiêu chuẩn an ninh đang phát triển.

OPSWAT 'S Secure Chương trình SDLC dịch Secure Khung SDLC được xây dựng thành một hệ thống quản trị có cấu trúc, đảm bảo các yêu cầu bảo mật được ghi chép, duy trì, đo lường và liên tục cải tiến, đồng thời đảm bảo tất cả các bên liên quan đều được đào tạo đầy đủ. Khung này thiết lập các vai trò, trách nhiệm và biện pháp bảo mật cho môi trường phát triển, thử nghiệm và sản xuất, cũng như bảo mật đường ống, xác định Secure Môi trường phát triển và bắt buộc áp dụng các chính sách bảo mật trong Secure Quy trình SDLC.

Quản lý cấp cao – Giám đốc sản phẩm (CPO)

Giám đốc sản phẩm chính (CPO) chịu trách nhiệm giám sát chiến lược và thực thi Secure Chương trình SDLC áp dụng cho tất cả các nhóm sản phẩm cũng như các chương trình Nghiên cứu và Phát triển (R&D) khác như Chương trình Đảm bảo chất lượng (QA) và Chương trình Trải nghiệm người dùng (UX), đảm bảo phương pháp tiếp cận thống nhất để phát triển phần mềm an toàn, chất lượng cao và lấy người dùng làm trung tâm.

Với tư cách là chủ sở hữu rủi ro chính đối với tất cả các sản phẩm và quy trình R&D, CPO yêu cầu Hoạt động R&D sở hữu Secure Chương trình SDLC và đảm bảo rằng các nhà lãnh đạo sản phẩm đang thực thi việc áp dụng Secure Chương trình SDLC và việc thực hiện Secure Quy trình SDLC được thực hiện hiệu quả trong các nhóm sản phẩm. Trong vai trò này, CPO phê duyệt việc sửa đổi Secure Chương trình SDLC và những sai lệch so với Secure Quy trình SDLC.

CPO cũng giám sát Secure Kết quả của Chương trình SDLC, theo dõi mức độ hoàn thiện về bảo mật, lỗ hổng, tuân thủ và các hoạt động phát triển để duy trì thế trận bảo mật mạnh mẽ cho các sản phẩm.

Ngoài ra, CPO chịu trách nhiệm phân bổ và phê duyệt ngân sách an ninh R&D, đảm bảo rằng các nguồn lực đầy đủ được dành cho Secure Chương trình SDLC.

Ưu tiên chiến lược

OPSWAT Kế hoạch chiến lược của IBM về bảo mật ứng dụng được điều chỉnh phù hợp với các ưu tiên kinh doanh và mức độ chấp nhận rủi ro của công ty, cân nhắc mức độ trưởng thành của từng sản phẩm và khả năng tiếp xúc với các mối đe dọa bảo mật. Trọng tâm chính là bảo vệ các sản phẩm có rủi ro cao, đặc biệt là những sản phẩm có lượng khách hàng lớn, triển khai công khai hoặc tích hợp vào cơ sở hạ tầng trọng yếu .

Là một phần của Secure Chương trình SDLC, ngoài các khóa đào tạo nâng cao nhận thức bảo mật chung của công ty, còn có chương trình đào tạo bảo mật theo từng vị trí cụ thể cho tất cả nhân viên tham gia phát triển bảo mật. Tất cả các khóa đào tạo đều được theo dõi trong các công cụ đào tạo của công ty. Các chương trình đào tạo và nâng cao nhận thức được xem xét định kỳ để cập nhật các xu hướng bảo mật mới và đảm bảo tuân thủ liên tục các tiêu chuẩn bảo mật.

OPSWAT cam kết liên tục nâng cao Secure Chương trình SDLC thông qua việc đo lường hiệu suất có cấu trúc, đánh giá mức độ trưởng thành và cập nhật thường xuyên để đảm bảo hiệu quả bảo mật liên tục.  

Để duy trì một thế trận an ninh vững chắc, OPSWAT áp dụng phương pháp tiếp cận có hệ thống để theo dõi và cải thiện hiệu suất bảo mật. Điều này bao gồm đánh giá mức độ hoàn thiện bảo mật sản phẩm hàng quý, đánh giá bảo mật nội bộ để xác minh việc tuân thủ các thông lệ tốt nhất, và xác định các Chỉ số Hiệu suất Chính (KPI) hàng năm, được đo lường hàng quý.  

Để đo lường hiệu quả tình trạng bảo mật ứng dụng, OPSWAT đánh giá các nhóm bằng các số liệu có cấu trúc. Mức độ trưởng thành về bảo mật sản phẩm được đánh giá theo từng nhóm dựa trên khuôn khổ SAMM, cung cấp thước đo định lượng về tiến độ bảo mật. Ngoài ra, các sản phẩm cũng trải qua đánh giá tuân thủ ASVS để đảm bảo tuân thủ các yêu cầu xác minh bảo mật. Việc tuân thủ Secure Quy trình SDLC được giám sát, đánh giá chặt chẽ và việc đạt được các mục tiêu KPI dựa trên bằng chứng, đảm bảo rằng tình hình an ninh và các cải tiến an ninh đều có thể đo lường và thực hiện được. Tất cả các nhóm sản phẩm đều được yêu cầu đáp ứng các mục tiêu trưởng thành về an ninh như một phần của đánh giá hiệu suất hàng năm. 

Là một phần trong những nỗ lực cải tiến liên tục của mình, OPSWAT Định kỳ giới thiệu các sáng kiến bảo mật sản phẩm mới nhằm nâng cao mức độ hoàn thiện và củng cố bảo mật ứng dụng. Các sáng kiến này bao gồm cập nhật chính sách bảo mật để giải quyết các mối đe dọa mới nổi, tích hợp các công cụ bảo mật mới để tăng cường phát hiện và phòng ngừa, và mở rộng các mục tiêu KPI để thúc đẩy tiến độ liên tục. 

Để tăng cường hơn nữa việc quản lý an ninh, OPSWAT tiến hành đánh giá hàng năm về Secure Khung SDLC, kết hợp những hiểu biết sâu sắc từ phân tích nguyên nhân gốc rễ của các sự cố bảo mật trong quá khứ, đánh giá xu hướng lỗ hổng và cải tiến các quy trình và chính sách hiện có.  

Cách tiếp cận có cấu trúc này để cải tiến liên tục đảm bảo rằng OPSWAT duy trì tư thế bảo mật sản phẩm chủ động và linh hoạt, thích ứng hiệu quả với các thách thức an ninh mạng đang phát triển đồng thời đáp ứng cả mục tiêu bảo mật theo quy định và hoạt động.

Các Secure Quá trình SDLC tiếp tục vận hành Secure Chương trình SDLC bằng cách xác định các biện pháp kiểm soát bảo mật mà các nhóm phải tuân thủ, bao gồm các hoạt động cụ thể như kiểm tra bảo mật tự động và cơ chế xác minh ở mỗi giai đoạn phát triển. Quy trình này được liên kết với các chương trình R&D quan trọng khác, chẳng hạn như Chương trình Đảm bảo Chất lượng và Chương trình Trải nghiệm Người dùng, đảm bảo một phương pháp tiếp cận thống nhất để phát triển phần mềm an toàn, chất lượng cao và tập trung vào khách hàng. 

Các Secure Quy trình SDLC được trình bày chi tiết trong các phần sau:

• Secure Thiết kế và Đánh giá Rủi ro
• Secure Triển khai, Xây dựng và Triển khai
• Kiểm tra và xác minh bảo mật ứng dụng
• Secure Phát hành
• Secure Vận hành và Bảo trì

Các Secure Quy trình SDLC là một quy trình cấp cao, các nhóm có thể triển khai nó theo cách tùy chỉnh mở rộng với điều kiện bảo mật của quy trình phải được giữ ở mức tối thiểu. Độ lệch so với Secure Quy trình SDLC phải được ghi chép và phê duyệt.

Các Secure Chương trình SDLC bao gồm nhiều chính sách khác nhau, phải được các nhóm sản phẩm chính thức phê duyệt và xác nhận để đảm bảo tuân thủ các yêu cầu. Việc tuân thủ các chính sách này là bắt buộc trong nội bộ, và mỗi nhóm có trách nhiệm xem xét, ký kết và triển khai chúng như một phần của quy trình phát triển. 

Dưới đây là danh sách các chính sách quan trọng cùng với mục đích tương ứng của chúng. Đối với các chính sách có ý nghĩa bên ngoài, tài liệu này sẽ bổ sung thêm thông tin chi tiết.

Là một phần của Secure Quy trình SDLC, các yêu cầu bảo mật được theo dõi, ghi chép và duy trì trong suốt vòng đời phát triển. Các nhà cung cấp bên thứ ba được yêu cầu xác nhận và đáp ứng ASVS, đảm bảo tính nhất quán trong các kỳ vọng bảo mật và tuân thủ Chính sách Tuân thủ Quyền riêng tư Sản phẩm trên tất cả các thành phần phần mềm. 

Bảo mật được tích hợp vào mọi giai đoạn của vòng đời phát triển. Trách nhiệm của những người tiên phong về bảo mật là ghi nhớ những kỳ vọng của Secure Quy trình SDLC và đại diện cho họ trong nhóm của mình. 

Các Secure Bộ yêu cầu thiết kế bao gồm các yêu cầu bảo mật chức năng và phi chức năng dựa trên ASVS. Các mô hình tham chiếu được cung cấp bởi Bộ phận Nghiên cứu và Phát triển để hỗ trợ các quyết định thiết kế, cùng với các điều chỉnh được ghi chép lại đối với các yêu cầu ASVS nếu cần (ví dụ: yêu cầu mã hóa mạnh hơn).

Mô hình hóa mối đe dọa là một quy trình có cấu trúc để xác định các mối đe dọa và lỗ hổng ở giai đoạn đầu của vòng đời phát triển. Đây là một phần không thể thiếu của Secure Quy trình SDLC, được thực hiện thường xuyên—ít nhất mỗi năm một lần hoặc bất cứ khi nào các tính năng mới hoặc thay đổi kiến trúc được giới thiệu. Các nhóm sản phẩm thực hiện mô hình hóa mối đe dọa bằng cách xác định các mục tiêu bảo mật, xác định tài sản và các mối phụ thuộc, phân tích các kịch bản tấn công tiềm ẩn và giảm thiểu các mối đe dọa đã xác định.  

Phương pháp tiếp cận nâng cao kết hợp phân tích luồng dữ liệu và các phương pháp mô hình hóa mối đe dọa đã được thiết lập (ví dụ: mô hình STRIDE), đảm bảo đánh giá toàn diện trên toàn bộ sản phẩm. Khi cần thiết, Đánh giá Bảo mật được khởi tạo để xác thực việc tuân thủ các yêu cầu bảo mật và chủ động giải quyết các rủi ro tiềm ẩn. Các quyết định thiết kế được ghi chép cẩn thận, và bất kỳ rủi ro nào còn tồn tại đều được theo dõi liên tục trong suốt vòng đời sản phẩm.

Rủi ro bảo mật ứng dụng được đánh giá dựa trên nhiều nguồn, bao gồm các mối đe dọa còn sót lại được xác định trong quá trình mô hình hóa mối đe dọa, các lỗ hổng bảo mật được công nhận rộng rãi như các lỗ hổng trong Top 10 của OWASP và Top 25 của SANS, và việc thiếu các biện pháp kiểm soát bảo mật dựa trên hướng dẫn ASVS. Các yếu tố rủi ro bổ sung bao gồm điểm yếu trong quản lý bí mật trong suốt quá trình xây dựng, triển khai và phát hành, cũng như các lỗ hổng trong các thành phần nguồn mở và của bên thứ ba. 

Sau khi đánh giá rủi ro, các kế hoạch giảm thiểu được xây dựng để giảm mức độ nghiêm trọng của các rủi ro đã xác định, có tính đến cả tác động và khả năng xảy ra. Các kế hoạch này, cùng với các rủi ro và bước giảm thiểu tương ứng, được ghi chép đầy đủ. 

Rủi ro tồn đọng được theo dõi trong suốt vòng đời sản phẩm, được xem xét định kỳ và phải được chủ sở hữu rủi ro chính thức xác nhận. Chúng cũng được đưa vào báo cáo phát hành nội bộ để duy trì tính minh bạch và trách nhiệm giải trình. 

Khi cần thiết, Đánh giá bảo mật sẽ được khởi xướng để đảm bảo tuân thủ các yêu cầu bảo mật và chủ động giải quyết các rủi ro tiềm ẩn, củng cố thế trận bảo mật tổng thể của sản phẩm.

Là một phần của Secure Quy trình SDLC bao gồm Triển khai, Xây dựng và Triển khai nhằm mục đích ngăn ngừa các lỗ hổng và sai sót, dựa trên Secure Thiết kế và Đánh giá Rủi ro. Bộ yêu cầu bao gồm các kỳ vọng về các yêu cầu bảo mật chức năng và phi chức năng dựa trên ASVS, phương pháp phát triển và kiểm tra an toàn dựa trên Secure Môi trường phát triển.  

Trong quá trình thực hiện Secure Thực hành mã hóa tốt nhất, Secure Việc rà soát mã và phát hiện sớm các lỗ hổng bảo mật sẽ được áp dụng. Các nhóm phải tuân thủ Supply Chain Chính sách Bảo mật (bao gồm các chủ đề về tích hợp nhà cung cấp và phần mềm nguồn mở), Chính sách Sử dụng AI và Chính sách Xử lý Mẫu Phần mềm Độc hại. Trong quá trình xây dựng và triển khai Secure Cần phải xây dựng và triển khai với việc sử dụng đường ống CI/CD tập trung và Phân tách nhiệm vụ.

Các nhóm sản phẩm phải tuân thủ các phương pháp thực hành tốt nhất về mã hóa bảo mật độc lập với ngôn ngữ trong quá trình triển khai. Họ được yêu cầu xác thực dữ liệu đầu vào, khử trùng dữ liệu được gửi đến các hệ thống khác, loại bỏ cảnh báo của trình biên dịch, thiết lập thông báo lỗi bảo mật, áp dụng mã hóa đầu ra khi cần thiết, triển khai ghi nhật ký bảo mật mà không làm lộ dữ liệu nhạy cảm và tuân thủ các hướng dẫn xử lý lỗi và quản lý ngoại lệ phù hợp. Các nhóm cũng phải đảm bảo rằng mật mã, nếu được sử dụng, dựa trên các thuật toán đã được phê duyệt và tạo số ngẫu nhiên an toàn, đồng thời quản lý tài nguyên hệ thống một cách an toàn bằng cách xử lý bộ nhớ an toàn, ngăn ngừa tình trạng tranh chấp và tránh bế tắc thông qua đồng bộ hóa phù hợp. 

Các nhóm sản phẩm cũng được khuyên nên tuân theo các nguyên tắc mã hóa bảo mật dành riêng cho từng ngôn ngữ, được thực thi bởi các công cụ SAST, như minh họa dưới đây: 

Đối với Java , các nhóm phải đảm bảo rằng các khóa được sử dụng trong các hoạt động so sánh là không thể thay đổi, sử dụng SecureRandom thay vì Random và tránh hủy tuần tự hóa không an toàn bằng cách xác thực hoặc hạn chế các lớp đầu vào.

Trong C++ , người ta khuyến nghị phát hiện và xử lý lỗi phân bổ bộ nhớ, ngăn tràn bộ đệm thông qua kiểm tra giới hạn và sử dụng các con trỏ thông minh như std::unique_ptr(), đồng thời tránh các hàm không an toàn như strcpy() và sprintf(). 

Đối với Python , các nhà phát triển nên tránh sử dụng các hàm như eval() hoặc exec() để giảm thiểu rủi ro tiêm mã và ưu tiên các định dạng tuần tự hóa an toàn như mô-đun json hơn là pickle khi xử lý dữ liệu không đáng tin cậy.

Là một phần của Đánh giá bảo mật theo yêu cầu của Chính sách xác minh bảo mật ứng dụng, việc đánh giá mã bảo mật rất quan trọng và được thực hiện tùy thuộc vào công nghệ phát triển với nhiều Secure Danh sách kiểm tra đánh giá mã được áp dụng dựa trên loạt tài liệu hướng dẫn OWASP .

Theo yêu cầu của Chính sách Xác minh Bảo mật Ứng dụng, việc phát hiện sớm các lỗ hổng bảo mật là một thành phần quan trọng của quy trình phát triển. Để giảm thiểu các vấn đề bảo mật tiềm ẩn, phương pháp "không xây dựng" là bắt buộc, đảm bảo mã không an toàn không được đưa vào quy trình. Ngoài ra, phương pháp "không hợp nhất" cũng được áp dụng, yêu cầu các nhóm khắc phục bất kỳ sự cố nào được phát hiện trước khi có thể tích hợp các thay đổi. Việc giải quyết các lỗ hổng được phát hiện là điều cần thiết để đáp ứng các tiêu chí phát hành.

Là một phần của Secure Quy trình SDLC, việc sử dụng một quy trình CI/CD tập trung, được điều phối là bắt buộc để thực thi các bản dựng an toàn và tránh các cuộc tấn công chuỗi cung ứng. Nhật ký kiểm tra, bản dựng và triển khai được tạo, lưu giữ và xem xét theo quy định trong chính sách bảo mật của công ty. 

Mỗi nhóm sản phẩm có trách nhiệm tuân thủ các cấu hình biên dịch và bản dựng bảo mật khi cần thiết. Họ phải sử dụng các tùy chọn biên dịch bảo mật, vô hiệu hóa mã gỡ lỗi, tăng cường thời gian chạy cho các ngôn ngữ được thông dịch, ghim các phiên bản phụ thuộc, đảm bảo các bản dựng có thể tái tạo và tăng cường hình ảnh container. Các cấu hình được sử dụng phải được ghi lại và xem xét định kỳ. 

Theo nguyên tắc Phân tách Nhiệm vụ, các nhà phát triển và các thành viên khác trong nhóm có quyền truy cập mã hoặc bản dựng không thể truy cập vào môi trường sản xuất. Trong trường hợp sản phẩm đám mây, chỉ các kỹ sư phụ trách độ tin cậy của trang web sản phẩm mới được phép triển khai lên môi trường sản xuất.

Theo Chính sách Xác minh Bảo mật Ứng dụng của chúng tôi, chúng tôi triển khai tài liệu chính thức và theo dõi các vấn đề được phát hiện và chỉ định các công cụ tự động để xác minh liên tục. Là một phần của Secure Kiểm tra bảo mật quy trình SDLC được thực thi và theo dõi ở mọi giai đoạn của SDLC để đáp ứng các yêu cầu tuân thủ. Mục đích của việc này là tìm ra các lỗ hổng bảo mật tiềm ẩn một cách hiệu quả. Các vấn đề bảo mật phát sinh sẽ được các nhóm điều tra và xử lý trong khung thời gian quy định. Khung thời gian này là một phần của các KPI bảo mật đã được xác định.

• Đánh giá kiến trúc và thiết kế: Các kỹ sư cao cấp và thành viên của Nhóm bảo mật ứng dụng ảo đánh giá các khía cạnh bảo mật trong những thay đổi thiết kế, bao gồm mã hóa, xác thực, ủy quyền, kiểm tra, củng cố hệ thống, kiến trúc hệ thống và mạng. 
• Đánh giá mã: ngoài việc đánh giá mã thường xuyên của các kỹ sư cấp cao và đồng nghiệp, các thành viên của Nhóm bảo mật ứng dụng ảo sẽ xem xét các thay đổi để ngăn ngừa các lỗi phổ biến như tấn công chèn mã, xử lý lỗi và cấu hình không an toàn.

• Quét bí mật để tránh rò rỉ thông tin bí mật và đảm bảo thiết kế tốt cũng như triển khai an toàn việc xử lý thông tin bí mật.
• Công cụ SAST (Kiểm tra bảo mật ứng dụng tĩnh) để phát hiện lỗ hổng (ví dụ: SQL Injection, tràn bộ đệm).
• SCA (Phân tích thành Software ) được sử dụng để phát hiện lỗ hổng mã nguồn mở.
• DAST (Kiểm tra bảo mật ứng dụng động) được sử dụng để tìm các vấn đề về thời gian chạy (ví dụ: lỗi bộ nhớ) và môi trường

Các công cụ được định nghĩa trong phần Phát hiện sớm các vấn đề bảo mật là bắt buộc phải sử dụng trong quy trình CI/CD. Tất cả các lỗ hổng được xác định phải được khắc phục theo Quy trình Sản phẩm. Vulnerability Management Chính sách.

Cả phương pháp kiểm tra bảo mật tự động và thủ công đều được sử dụng phù hợp với Chương trình đảm bảo chất lượng thực hiện Kế hoạch kiểm tra bảo mật.

• Các công cụ DAST được sử dụng để phát hiện lỗ hổng thời gian chạy, kiểm tra cấu hình mặc định và kiểm tra khả năng phục hồi của hệ thống sau khi áp dụng các đề xuất tăng cường bảo mật. Các bài kiểm tra này nhắm vào cả phần mềm và cơ sở hạ tầng cơ bản. 
• Để tránh sự suy giảm trong các yêu cầu và tính năng bảo mật, chúng tôi sử dụng các công cụ kiểm tra tự động để liên tục xác minh tính toàn vẹn của các tính năng và biện pháp kiểm soát bảo mật. 
• Kiểm thử thủ công được áp dụng khi các công cụ tự động không đáp ứng được yêu cầu, chẳng hạn như khi xác minh các biện pháp kiểm soát rò rỉ thông tin, xác định lỗi logic kinh doanh và lỗ hổng theo ngữ cảnh. 
• Quét phần mềm độc hại tự động các hiện vật trong vòng đời phát triển cũng là một phần trong các bước tập trung vào việc ngăn ngừa các vấn đề bảo mật.

Là một phần của Secure Quy trình SDLC, quy trình phát hành thực thi các tiêu chí phát hành đảm bảo tuân thủ cả Secure Quy trình SDLC và bảo mật tổng thể của sản phẩm, dựa trên các phát hiện theo Kiểm tra và Xác minh Bảo mật Ứng dụng. Quản lý phiên bản sản phẩm đóng vai trò quan trọng trong việc duy trì các cải tiến bảo mật qua các bản phát hành, ngăn ngừa sự suy giảm liên quan đến bảo mật và duy trì trạng thái bảo mật đã đạt được, như một yêu cầu cơ bản cho mỗi bản phát hành. 

Quy trình phát hành bao gồm việc tạo báo cáo phát hành nội bộ, ghi lại các rủi ro còn tồn đọng và bất kỳ vấn đề bảo mật nào còn tồn đọng. Các báo cáo này phải được trưởng nhóm sản phẩm phê duyệt chính thức. Ngoài ra, các ghi chú phát hành bên ngoài cũng thông báo các thay đổi và bản sửa lỗi liên quan đến bảo mật như một phần của bản phát hành chính thức của sản phẩm. 

Đối với các sản phẩm đám mây, việc triển khai áp dụng phương pháp tự động hóa "triển khai không thành công", đảm bảo chỉ các bản dựng an toàn mới được phát hành. Kiểm tra và Xác minh Bảo mật Ứng dụng được tích hợp vào quy trình triển khai, với chiến lược kéo vận hành thay vì đẩy, giúp củng cố xác thực bảo mật trước khi triển khai sản xuất. 

Theo Chính sách quản lý SBOM, mỗi bản phát hành bao gồm một Software Bill of Materials (SBOM) để duy trì khả năng truy xuất nguồn gốc linh kiện, hỗ trợ tính minh bạch và bảo mật chuỗi cung ứng. Tất cả các tệp phát hành cần thiết đều được lưu trữ an toàn để đảm bảo khả năng truy cập lâu dài.

Theo Chính sách Toàn vẹn Phát hành, để duy trì tính toàn vẹn và bảo mật của các bản phát hành sản phẩm, một hệ thống quản lý phiên bản có cấu trúc (ví dụ: Quản lý Phiên bản Ngữ nghĩa) được áp dụng, đảm bảo khả năng truy xuất nguồn gốc rõ ràng các thay đổi và thời gian lưu giữ được xác định cho tất cả các sản phẩm đã phát hành, bao gồm cả tài liệu. Để tăng cường bảo mật hơn nữa, các sản phẩm phần mềm được ký số dưới tên công ty, với dấu vân tay SHA được công bố, cho phép người dùng xác minh tính xác thực và phát hiện mọi nỗ lực giả mạo. 

Tài liệu hướng dẫn phiên bản đi kèm với mỗi bản phát hành, cung cấp hướng dẫn chi tiết về các phương pháp xác minh tính toàn vẹn, quy trình cài đặt an toàn, các biện pháp tối ưu về cấu hình và các biện pháp tăng cường hệ thống. Các tài nguyên này giúp người dùng triển khai các biện pháp kiểm soát bảo mật hiệu quả, giảm thiểu các nguy cơ tấn công tiềm ẩn. Ngoài ra, Thỏa thuận Cấp phép Người dùng Cuối (EULA) cũng được bao gồm để thiết lập các nghĩa vụ tuân thủ và duy trì tính minh bạch về mặt pháp lý. 

SBOM cho từng sản phẩm sẽ được cung cấp theo yêu cầu của khách hàng. Liên hệ với chúng tôi .

Môi trường phát triển, thử nghiệm và sản xuất được tách biệt an toàn để ngăn chặn truy cập trái phép. Mỗi môi trường đều tuân thủ nghiêm ngặt các tiêu chuẩn bảo mật cơ bản và giao thức bảo mật điểm cuối. Môi trường phát triển phải tuân thủ chính sách bảo mật của công ty.

Là một phần của bảo vệ điểm cuối tất cả OPSWAT Các thiết bị sở hữu được giám sát về lỗ hổng bảo mật, phần mềm đã cài đặt, bản vá đã cài đặt và việc tuân thủ các chính sách bảo mật của công ty. Trong trường hợp không tuân thủ, các biện pháp hạn chế sẽ được thực hiện để hạn chế quyền truy cập vào tài nguyên của công ty. 

Các tài nguyên được phân loại là rủi ro cao chỉ có thể được truy cập thông qua các tuyến truy cập được kiểm soát (VPN). Các thiết bị bên ngoài mạng công ty buộc phải sử dụng các kênh bảo mật để truy cập tài nguyên R&D.

Bảo mật đường ống CI/CD tuân thủ các chỉ thị bảo mật nghiêm ngặt để giảm thiểu các mối đe dọa đang phát triển. Nguồn gốc của các mối đe dọa có thể đến từ các yếu tố cơ sở hạ tầng lỗi thời (như hệ điều hành, công cụ phân tích, v.v.), truy cập trái phép do kiểm soát đặc quyền yếu và môi trường cô lập kém. Việc duy trì cơ sở hạ tầng CI/CD luôn được cập nhật, kiểm tra kỹ lưỡng và kiểm soát chặt chẽ là nền tảng của SDLC an toàn của chúng tôi. 

Ở cấp khu vực, các máy chủ đặt tại Hoa Kỳ được sử dụng cho tất cả các dịch vụ tập trung, bao gồm lưu trữ mã, quy trình CI/CD, các công cụ phân tích và kiểm thử, và ký hiện vật an toàn. Việc cấu hình tất cả các công cụ tập trung đều do Bộ phận Vận hành Nghiên cứu và Phát triển (R&D) kiểm soát. 

Chúng tôi áp dụng cơ chế xác thực mạnh mẽ (Xác thực Đa yếu tố - MFA) và kiểm soát quyền hạn (Kiểm soát Truy cập Dựa trên Vai trò - RBAC). Chúng tôi thực hiện đánh giá quyền truy cập thường xuyên và đặc quyền tối thiểu. 

Các đường ống của chúng tôi kết hợp một số công cụ tự động phân tích và thử nghiệm, bao gồm Kiểm tra bảo mật ứng dụng tĩnh (SAST), Software Phân tích thành phần (SCA), Kiểm tra bảo mật ứng dụng động (DAST), Quét bí mật và Quét phần mềm độc hại. 

Trong giải pháp ký mã an toàn của chúng tôi, chúng tôi sử dụng Hardware Mô-đun Bảo mật (HSM) bảo vệ tài liệu khóa khỏi truy cập trái phép và tạo chữ ký. Giải pháp ký là một phần của cơ sở hạ tầng CI/CD, nhưng đã được phân đoạn mạng. Chỉ Bộ phận Vận hành R&D mới được phép truy cập HSM trong thời gian ngắn. Mọi hành động ký đều được ghi lại và có thể được xem xét trong quá trình kiểm tra. 

Bộ công cụ được sử dụng để xây dựng, biên dịch hoặc kiểm thử phần mềm phải có thông tin nguồn gốc và đến từ một nguồn đã được xác thực. Số lượng công cụ được sử dụng trong quy trình CI/CD bị giới hạn; chỉ những công cụ cần thiết mới được cài đặt. Chỉ phần mềm LTS mới được phép biên dịch và xây dựng các bước trong quy trình. Trong quá trình vận hành các dịch vụ tập trung, chu kỳ bảo trì định kỳ và luân chuyển khóa được xác định. Các công cụ được phát triển nội bộ thuộc phạm vi Secure Quy trình SDLC.

Việc củng cố môi trường cho tất cả các dịch vụ tập trung được thực hiện liên tục và các yêu cầu bảo mật này được xem xét định kỳ. Các hướng dẫn củng cố được truyền đạt đến các nhóm sản phẩm để đảm bảo họ đã sẵn sàng và có thể điều chỉnh quy trình phát triển cho phù hợp. Trong trường hợp xảy ra sự cố bảo mật, RCA được tiến hành để thực hiện hành động phòng ngừa và cập nhật các yêu cầu này.

Việc bảo vệ mã nguồn là một phần quan trọng của quá trình phát triển phần mềm nhằm đảm bảo tính bảo mật và toàn vẹn của mã nguồn trong công ty. 

Mã nguồn được lưu trữ theo nguyên tắc đặc quyền tối thiểu, chỉ cho phép nhân viên và công cụ được ủy quyền truy cập. Mã nguồn được kiểm soát phiên bản. Hệ thống quản lý kiểm soát phiên bản đảm bảo khả năng truy xuất nguồn gốc và trách nhiệm giải trình các thay đổi mã. Kho lưu trữ mã nguồn được mã hóa bằng mật mã tuân thủ FIPS 140-3 và được bảo vệ bằng độ dài khóa phù hợp.

Việc tuân thủ chính sách này là bắt buộc đối với tất cả các nhóm nội bộ. Tài liệu này phụ thuộc vào chính sách của công ty, nghĩa là trong trường hợp có bất kỳ mâu thuẫn nào, chính sách của công ty sẽ được ưu tiên và phải được tuân thủ. 

Quá trình leo thang cho Secure Vi phạm SDLC: Mọi vi phạm chính sách này đều được xử lý nội bộ, bắt đầu từ Bộ phận Vận hành R&D và chuyển lên Giám đốc sản phẩm (CPO) nếu cần.

Các nhà cung cấp cung cấp các thành phần hoặc dịch vụ cho các sản phẩm trong phạm vi của ISO 27001, SOC2, NIST SSDF được kỳ vọng sẽ tuân thủ các yêu cầu được nêu dưới đây từ Secure Khung SDLC. Việc tuân thủ phải tuân theo các cuộc kiểm tra bảo mật định kỳ, đánh giá của bên thứ ba và nghĩa vụ của mỗi bên theo hợp đồng đã ký kết. 

Tất cả các nhà cung cấp đều phải cung cấp thông tin về nguồn gốc và tính toàn vẹn, cùng với tài liệu hỗ trợ, như được định nghĩa trong phần Tính toàn vẹn của bản phát hành. 

Các nhà cung cấp thành phần sản phẩm và thư viện phải thiết lập môi trường phát triển phù hợp với các hoạt động của chúng tôi như được mô tả trong Secure Phần Môi trường Phát triển. Họ phải áp dụng thử nghiệm bảo mật cho các thành phần và thư viện của mình, như được mô tả trong phần Kiểm tra và Xác minh Bảo mật Ứng dụng. 

Các nhà cung cấp thành phần đường ống cũng phải thiết lập môi trường phát triển phù hợp với các hoạt động của chúng tôi như được mô tả trong Secure Phần Môi trường Phát triển. Ngoài ra, quy trình phát triển của họ phải phù hợp với OPSWAT 'S Secure Quy trình SDLC. 

Các nhà cung cấp dịch vụ dự kiến sẽ sử dụng các môi trường có trụ sở tại Hoa Kỳ cung cấp tư thế bảo mật tương đương với OPSWAT dịch vụ của họ. Secure SDLC phải bao gồm cả Secure Chương trình SDLC và một Secure Quá trình SDLC phản ánh OPSWAT kỳ vọng của.