4 bước để DevSecOps trong chuỗi cung ứng phần mềm

cloudFun

cropped-photo-1448387473223-5c37445527e7 (1).jpg
Các dev thường muốn làm điều “đúng đắn” khi nói đến bảo mật, nhưng họ không phải lúc nào cũng biết là phải làm gì. Để giúp các dev tiếp tục di chuyển nhanh chóng, đồng thời đạt được kết quả bảo mật tốt hơn, các doanh nghiệp đang chuyển sang DevSecOps .  DevSecOps là sự thay đổi tư duy về việc làm cho tất cả các bên tham gia development lifecycle có trách nhiệm đối với bảo mật của ứng dụng, bằng cách liên tục tích hợp bảo mật trong quá trình phát triển. Trên thực tế, điều này có nghĩa là chuyển sang việc đánh giá và kiểm tra bảo mật — tức là chuyển từ kiểm tra hoặc thực thi tại thời điểm triển khai sang kiểm tra các biện pháp kiểm soát bảo mật trước đó tại thời điểm xây dựng hoặc phát triển.

Với việc code mà dev viết sẽ ung cấp phản hồi về các vấn đề trong quá trình phát triển, do đó, dev sẽ không mất thời gian kiểm tra. Nhưng đối với các phần phụ thuộc mà đoạn code đó tham gia như một phần của chuỗi cung ứng phần mềm thì nên làm gì? 
Đầu tiên chúng ta hãy xác định một phụ thuộc. Phần phụ thuộc là một tệp nhị phân khác mà phần mềm cần để chạy, được chỉ định như một phần của ứng dụng. Sử dụng phần phụ thuộc cho phép tận dụng sức mạnh của mã nguồn mở và lấy code cho các chức năng không phải là phần cốt lõi của ứng dụng.

Sự phụ thuộc thường xác định chuỗi cung ứng phần mềm. Báo cáo trạng thái vào tháng 10 năm 2019 của GitHub đã chỉ ra rằng trung bình, mỗi kho lưu trữ có hơn 200 phụ thuộc . Lỗ hổng ngược dòng trong bất kỳ một trong những phần phụ thuộc này có nghĩa là bản thân doanh nghiệp cũng có thể bị ảnh hưởng.  Thực tế của chuỗi cung ứng phần mềm là việc phụ thuộc vào code bản thân không viết, nhưng các yếu tố phụ thuộc vẫn yêu cầu phải làm việc để duy trì liên tục. Vì vậy, nên bắt đầu từ đâu trong việc triển khai các biện pháp kiểm soát bảo mật?

Hợp nhất CI / CD pipeline 
Một phần mục tiêu của DevSecOps, và dịch chuyển sang trái, là cung cấp không chỉ phản hồi mà còn cả tính nhất quán và khả năng lặp lại như một phần của môi trường phát triển. Điều này không phải là duy nhất cho chuỗi cung ứng, nhưng áp dụng cho bất kỳ biện pháp kiểm soát an ninh nào.
Nhóm code càng sớm có thể thống nhất CI / CD pipeline của mình thì càng có thể triển khai các biện pháp kiểm soát sớm hơn, cho phép các kiểm soát bảo mật chuyển sang trái. Bạn sẽ không muốn áp dụng các điều khiển giống nhau nhiều lần trong các hệ thống khác nhau. Các kiểm soát trùng lặp không mở rộng quy mô, lây lan tài nguyên bảo mật (vốn đã mỏng) thậm chí còn mỏng hơn, cho phép đưa ra sự không nhất quán thông qua sự trôi dạt hoặc không tương thích trong hệ thống và tệ nhất là khiến nhiều khả năng có thứ gì đó sẽ lọt qua các vết nứt.

Tiền thân của việc chuyển sang trái và áp dụng DevSecOps hoàn toàn không phải là một biện pháp kiểm soát bảo mật. Đó là về việc cải thiện công cụ dành cho dev để cung cấp một cách nhất quán để viết, xây dựng, kiểm tra và triển khai code. Việc giới thiệu một hệ thống tập trung cho bất kỳ hệ thống nào trong số này có thể giúp cải thiện tính bảo mật của mình. Các doanh nghiệp thường sẽ xử lý các công cụ dành cho dev từ bước cuối cùng và làm việc ngược lại bước đầu tiên, áp dụng một chiến lược triển khai nhất quán trước khi áp dụng một chiến lược xây dựng nhất quán, chẳng hạn. Ngoại lệ cho quy tắc này là code. Ngay cả khi xây dựng cục bộ, rất có thể, dev lại đang kiểm tra code của mình cho sau này.
Hãy bắt đầu áp dụng các biện pháp kiểm soát bảo mật cho code của mình ngay cả khi chưa thống nhất tất cả các bước khác. Phương pháp lấy dev làm trung tâm có nghĩa là các dev có thể ở trong ngữ cảnh và phản hồi các vấn đề khi họ viết code, không phải vài ngày sau khi triển khai hoặc vài tháng sau từ báo cáo kiểm tra thâm nhập. Xây dựng trên một CI / CD pipeline thống nhất, dưới đây là một số mẹo về cách nhóm phát triển có thể áp dụng DevSecOps để đảm bảo chuỗi cung ứng phần mềm.

Khai báo các phụ thuộc trong code
Điều đầu tiên, để duy trì các phụ thuộc — ví dụ: áp dụng các bản vá bảo mật — điều này có nghĩa là cần biết các phụ thuộc của mình là gì. Có vẻ đơn giản, phải không?

Có nhiều cách để phát hiện các phần phụ thuộc, ở các phần khác nhau của quá trình phát triển: bằng cách phân tích các phần phụ thuộc được khai báo trong code (được dev chỉ định trong tệp kê khai hoặc tệp khóa), bằng cách theo dõi các phần phụ thuộc được kéo vào như một phần của quá trình xây dựng, hoặc bằng cách kiểm tra các tạo tác xây dựng đã hoàn thành khi chúng vào sổ đăng ký. Thật không may, không có giải pháp hoàn hảo vì tất cả các phương pháp đều có những thách thức, nhưng nên chọn giải pháp tích hợp tốt nhất với quy trình phát triển hiện có của mình hoặc sử dụng nhiều giải pháp để cung cấp thông tin chi tiết về các yếu tố phụ thuộc ở mỗi bước trong quá trình phát triển.

Tuy nhiên, có những lợi ích khi phát hiện các phụ thuộc trong code, hơn là sau này. Với việc chuyển sang trái bước quản lý phụ thuộc sẽ cho phép các dev thực hiện bảo trì ngay lập tức cho các phụ thuộc — áp dụng các bản cập nhật, áp dụng các bản vá bảo mật hoặc xóa các phụ thuộc không cần thiết — mà không cần đợi phản hồi từ bước xây dựng hoặc triển khai.

Ngay cả khi không có đường dẫn xây dựng tập trung hoặc nhất quán và không thể áp dụng kiểm tra sau này, việc phát hiện ra sự phụ thuộc trong code có nghĩa là vẫn có thể suy ra thông tin này. Nhược điểm chính của việc phát hiện sự phụ thuộc trong code là có thể bỏ lỡ bất kỳ phần mềm tạo tác nào được đưa vào sau này. Ví dụ: Gradle cho phép giải quyết các phụ thuộc như một phần của bản dựng , có nghĩa là phát hiện thời gian xây dựng sẽ chứa thông tin đầy đủ hơn. 

Để phát hiện chính xác các phần phụ thuộc trong code — và để dễ dàng kiểm soát hơn những phần phụ thuộc nào sẽ sử dụng — doanh nghiệp sẽ muốn chỉ định rõ ràng chúng như một phần của tệp kê khai hoặc tệp khóa của ứng dụng, thay vì cung cấp chúng vào một kho lưu trữ (tạo bản sao của một phụ thuộc như một phần của dự án, hay còn gọi là sao chép-dán nó). Bán hàng có ý nghĩa nếu có lý do chính đáng để phân nhánh code — ví dụ: để sửa đổi hoặc giới hạn chức năng cho doanh nghiệp — hoặc sử dụng điều này như một bước để xem xét các yếu tố phụ thuộc. Một số hệ sinh thái cũng ủng hộ việc sử dụng nhà cung cấp. 

Tuy nhiên, nếu đang lên kế hoạch sử dụng phiên bản ngược dòng, việc cung cấp sẽ khiến việc cập nhật các phần phụ thuộc trở nên khó khăn hơn. Bằng cách chỉ định rõ ràng các phần phụ thuộc, nhóm phát triển sẽ dễ dàng cập nhật chúng hơn, vì các bản cập nhật chỉ yêu cầu một dòng code trong tệp kê khai, thay vì tạo lại và sao chép toàn bộ kho lưu trữ. Trong một số hệ sinh thái nhất định, có thể sử dụng tệp khóa để đảm bảo tính nhất quán, do đó, hãy kiểm tra liệu có đang sử dụng cùng một phiên bản trong môi trường phát triển của mình như phiên bản dành cho phiên bản sản xuất của mình và xem xét các thay đổi giống như bất kỳ thay đổi code nào khác.

Chuẩn hóa các gói 'vàng' 
Mọi người có thể đã quen với khái niệm hình ảnh “vàng”, được duy trì bởi doanh nghiệp, bao gồm cả các bản vá bảo mật mới nhất. Đây là một khái niệm chung cho các vùng chứa, nhằm cung cấp cho các dev một hình ảnh cơ sở để họ có thể xây dựng các vùng chứa của mình mà không cần phải lo lắng về hệ điều hành bên dưới. Ý tưởng ở đây là chỉ phải duy trì một tập hợp hệ điều hành, được quản lý bởi một nhóm trung tâm đã được xem xét về các vấn đề bảo mật và được xác thực trong môi trường. Chà, tại sao không làm điều đó cho các đồ tạo tác khác? . Để bổ sung CI / CD pipeline thống nhất, có thể cung cấp một bộ tài liệu tham khảo gồm các tạo tác và thư viện được duy trì. Đây chỉ là một biện pháp kiểm soát an ninh phủ đầu. Thay vì xác minh rằng một gói được cập nhật sau khi nó được xây dựng, hãy cung cấp cho các dev những gì họ cần làm đầu vào cho quá trình xây dựng của họ.

Ví dụ: nếu nhiều nhóm đang sử dụng OpenSSL thì sẽ không cần mọi nhóm cập nhật nó. Nếu một nhóm cập nhật nó thì sẽ có thể thay đổi cài đặt mặc định cho tất cả các nhóm. Điều này có thể được thực hiện bằng cách có một sổ đăng ký gói nội bộ trung tâm của các tạo tác tốt đã biết, đã vượt qua bất kỳ yêu cầu bảo mật nào và có chủ sở hữu rõ ràng chịu trách nhiệm cập nhật nếu các phiên bản mới được phát hành. Bằng cách cung cấp một bộ gói duy nhất sẽ đảm bảo tất cả các nhóm đều tham khảo những gói này. Hãy nhớ rằng, điều mới nhất có thể làm là trong hệ thống xây dựng, nhưng điều này cũng có thể được thực hiện sớm hơn trong code, đặc biệt nếu doanh nghiệp đang sử dụng monorepo. Một lợi ích bổ sung của việc chia sẻ các tạo tác và thư viện chung là giúp dễ dàng biết được liệu sản phẩm có bị ảnh hưởng bởi một lỗ hổng mới được phát hiện hay không. 

Tự động hóa các bản dựng và triển khai hạ nguồn
Để đảm bảo rằng công việc khó khăn của các dev sẽ được đền đáp, những thay đổi của họ thực sự cần được đưa vào sản xuất! Khi tạo một CI / CD pipeline thống nhất đồng nghĩa với việc xóa một đường dẫn cho các thay đổi được thực hiện đối với code trong môi trường phát triển để truyền xuống các môi trường thử nghiệm và sản xuất. Bước tiếp theo là đơn giản hóa điều này bằng tự động hóa. Trong một thế giới lý tưởng, nhóm phát triển chỉ thực hiện các thay đổi đối với môi trường phát triển , với bất kỳ thay đổi nào đối với môi trường đó sẽ tự động được chuyển sang thử nghiệm, xác thực và triển khai (và quay lại, nếu cần).    

Thay vì áp dụng DevOps và DevSecOps bằng cách yêu cầu nhóm phát triển học các công cụ hoạt động, đơn giản hóa các công cụ và phản hồi đó cho những gì nhóm này cần biết để thực hiện các thay đổi ở nơi họ quen thuộc nhất, trong code. Điều này nghe có vẻ quen thuộc — đó là những gì đang xảy ra với các xu hướng như cơ sở hạ tầng dưới dạng code hoặc GitOps — xác định mọi thứ trong code và để các công cụ quy trình làm việc xử lý việc thực hiện thay đổi thực tế.  

Nếu có thể tự động hóa quá trình xây dựng, thử nghiệm và triển khai code của mình, thì các dev chỉ cần tập trung vào việc sửa code. Tuân theo các nguyên tắc của DevSecOps, họ không cần học công cụ để thực hiện kiểm tra xác thực, triển khai theo từng giai đoạn hoặc bất cứ điều gì có thể cần trong môi trường của mình. Điều quan trọng, để bảo mật, nhóm phát triển không cần phải học cách triển khai bản sửa lỗi để áp dụng bản sửa lỗi. Khắc phục sự cố bảo mật trong code và cam kết nó là đủ để đảm bảo rằng nó (cuối cùng) được khắc phục trong quá trình sản xuất. Thay vào đó, nhóm có thể tập trung vào việc nhanh chóng tìm và sửa lỗi trong code.

Tạo một CI / CD pipeline thống nhất cho phép chuyển sang trái các kiểm soát bảo mật, bao gồm cả bảo mật chuỗi cung ứng. Sau đó, để áp dụng tốt nhất các nguyên tắc của DevSecOps nhằm cải thiện tính bảo mật của các phần phụ thuộc của mình, nên yêu cầu các dev khai báo các phần phụ thuộc trong code và lần lượt cung cấp cho họ các tạo tác “vàng” được duy trì và các hành động tự động xuống dòng để họ có thể tập trung vào code. Bởi vì điều này yêu cầu những thay đổi không chỉ đối với kiểm soát bảo mật mà còn đối với trải nghiệm của dev, chỉ sử dụng công cụ bảo mật là không đủ để triển khai DevSecOps. Ngoài việc bật các tính năng quản lý phụ thuộc gốc nền tảng , dev cũng sẽ muốn xem xét kỹ hơn CI / CD pipeline và quản lý tạo tác của mình. 

Tất cả cùng nhau, việc áp dụng DevSecOps cho phép doanh nghiệp hiểu rõ hơn về những gì trong chuỗi cung ứng. Bằng cách sử dụng DevSecOps, việc quản lý các phần phụ thuộc sẽ trở nên đơn giản hơn, với sự thay đổi đối với tệp kê khai hoặc tệp khóa dễ dàng cập nhật một cấu phần duy nhất được sử dụng trên nhiều nhóm và với sự tự động hóa CI / CD pipeline đảm bảo rằng các thay đổi mà dev thực hiện sẽ nhanh chóng kết thúc trong sản xuất.

Nguồn:
 
Top