Ý nghĩa của DevSecOps

Vậy, chính xác thì DevSecOps có nghĩa là gì? Điều đầu tiên (có thể rõ ràng) bạn cần biết chính là "Sec" trong DevSecOps là viết tắt của từ Security - bảo mật.

Đối với nhiều tổ chức, việc thực hiện một tư duy DevOps bao gồm "thu hẹp khoảng cách" - hoặc "xóa bỏ các silo trung gian" - trong các nhóm phát triển phần mềm và hoạt động công nghệ thông tin, thường với mục tiêu có thể phát hành phần mềm nhanh hơn và ổn định hơn.

DevSecOps, sau đó, là một phần mở rộng của tư duy DevOps và thường được trình bày với khẩu hiệu " dịch chuyển bảo mật lên sớm hơn" trong vòng đời phát triển phần mềm (SDLC - software development lifecycle), thay vì xử lý các đánh giá/kiểm tra bảo mật ở cuối chu trình, khi bất kỳ phát hiện nào cần xử lý sẽ gây khó khăn và tốn kém hơn để thực hiện.

Trên thực tế, nguyên tắc đằng sau DevSecOps - tiếp tục đẩy chất lượng đến gần nguồn hơn - là nguyên lý chính của The Second Way of DevOps (phản hồi) như được thảo luận trong Cẩm nang DevOps:

"Trong các hệ thống phức tạp, việc thêm nhiều bước kiểm tra và quy trình phê duyệt thực sự làm tăng khả năng thất bại trong tương lai. Hiệu quả của các quy trình phê duyệt giảm xuống khi các quyết định bị đẩy xa khỏi nơi công việc được thực hiện. Làm như vậy không chỉ làm giảm chất lượng của các quyết định, mà cũng làm tăng thời gian chu kỳ, do đó làm giảm sức mạnh của sự phản hồi giữa nguyên nhân và kết quả và giảm khả năng học hỏi từ những thành công và thất bại".

W. Edwards Deming, một kỹ sư, giáo sư thống kê và tư vấn quản lý đã giúp phát động Phong trào Chất lượng Toàn diện ở Hoa Kỳ, đưa ra ý tưởng tương tự (sớm hơn nhiều) trong phần thứ ba (trong tổng số 14) các nguyên tắc quản lý chính để chuyển đổi hiệu quả kinh doanh:

"Dễ dàng phụ thuộc vào kiểm tra để đạt được chất lượng. Loại bỏ nhu cầu kiểm tra lớn bằng cách xây dựng chất lượng vào sản phẩm ngay từ đầu".

Nguyên tắc không nhất thiết phải thực hành bình đẳng

Những nguyên tắc này không mới và về lý thuyết có vẻ khá đơn giản, nhưng sự thật là trong thực tế, nhiều tổ chức không vận hành theo cách này.

Nếu một tổ chức ưu tiên bảo mật, điều đó thường nhằm đạt được các tiêu chí tối thiểu cho một số loại tuân thủ, thường là với một nhóm bảo mật được bảo vệ.

Trong bài viết DZone của mình: "10 lời khuyên để tích hợp bảo mật vào DevOps", Gene Kim đã mô tả thách thức này:

"Tỷ lệ kỹ sư phát triển, vận hành và Infosec (An toàn thông tin) trong một tổ chức công nghệ điển hình là 100:10:1. Khi Infosec trở nên vượt trội mà không tự động hóa và tích hợp bảo mật thông tin vào công việc hàng ngày của Dev và Ops, Infosec chỉ có thể tuân thủ kiểm tra, và điều này trái ngược lại với kỹ thuật bảo mật".

Một ví dụ điển hình của kịch bản này được minh họa trong “Dự án Phượng hoàng: Câu chuyện về Công nghệ thông tin, DevOps và Giúp bạn giành chiến thắng trong kinh doanh”, nơi nhân vật Giám đốc công nghệ thông tin (CISO), John, đi qua một cuộc khủng hoảng hiện hữu khi công ty của anh ta vượt qua cuộc kiểm toán SOX-404 mà không cần phải phụ thuộc vào các biện pháp kiểm soát bảo mật nặng nề của mình.

Sau một thời gian khi nhận thấy tất cả công việc khó khăn của mình không thực sự tăng thêm giá trị cho công ty, CISO John "trỗi dậy từ đống tro tàn". Anh bắt đầu tìm hiểu làm thế nào vai trò của mình có thể giúp công ty đạt được mục tiêu doanh nghiệp, làm việc hợp tác hơn với các bộ phận phát triển phần mềm và hoạt động công nghệ thông tin để hiểu cách anh ấy có thể giúp công việc của họ trở nên dễ dàng hơn. Chẳng bao lâu, bộ ba Dev, Ops và Infecec bắt đầu làm việc cùng nhau để giải quyết các mục tiêu kinh doanh chung đó, và trở nên linh hoạt hơn trong các quá trình, tăng thêm tự động hóa để giảm thiểu công việc và rủi ro bảo mật bất cứ khi nào có thể.

Sự thay đổi văn hóa trong cả hai hướng

Trong một cuộc phỏng vấn với Computer Business Review, Giám đốc công nghệ của Sonatype, Brian Fox, đã chia sẻ suy nghĩ của mình về sự thay đổi đang diễn ra trong không gian DevOps và DevSecOps: "Những gì chúng ta thấy trên thị trường chính là: thách thức lớn nhất của khách hàng ngày nay, thường là sự thay đổi văn hóa cần có để khiến tất cả các chủ sở hữu quy trình phải suy nghĩ cởi mở hơn, vượt ra ngoài những quy trình kế thừa mà họ tìm thấy."

Một trong những người sáng lập DevSecOps, Shannon Lietz của Intuit, cũng lặp lại quan điểm đó trong một bài đăng trên blog What is DevSecOps? trên devsecops.org, nêu rõ "... với sự thay đổi đang diễn ra của DevOps, bảo mật truyền thống không còn là một lựa chọn nữa."

Lietz cho biết: "Mục đích của DevSecOps là xây dựng trên suy nghĩ rằng 'mọi người đều có trách nhiệm bảo mật', với mục tiêu phân phối các quyết định bảo mật một cách an toàn, với tốc độ và quy mô, để những người nắm giữ vị trí cao nhất mà không phải hy sinh sự an toàn cần thiết".

Khi bạn nghĩ về DevSecOps như một môn học hợp tác, thành phần quan trọng cho cách tiếp cận thành công thường dẫn đến sự thay đổi trong tư duy văn hóa của tổ chức khi bạn chuyển hướng.

Các tác giả của Cẩm nang DevOps đều đồng ý với quan điểm trên:

"Bằng cách này, chúng tôi thực sự làm cho chất lượng trở thành trách nhiệm của mọi người, thay vì đó là trách nhiệm duy nhất của một bộ phận riêng biệt. Bảo mật thông tin không chỉ là công việc của đội ngũ Bảo mật thông tin, giống như sự sẵn có không chỉ là công việc của đội ngũ hoạt động".

Tại Sonatype, cách tiếp cận với DevSecOps bao gồm "xây dựng chất lượng", bằng cách tích hợp các biện pháp bảo mật vào tất cả các giai đoạn của đường ống DevOps – từ trên xuống dưới, từ lựa chọn thành phần nguồn mở ban đầu đến xây dựng, dàn dựng và phát hành ứng dụng của bạn.

Khi bạn tích hợp bảo mật vào tất cả các giai đoạn của vòng đời phát triển phần mềm, bạn cũng đang làm những công việc bao gồm:

• Quét và đánh giá các rủi ro thành phần nguồn mở trong cả các ứng dụng cũ và hiện có;
• Ngăn chặn các thành phần OSS (Hệ thống hỗ trợ vận hành - Operating Support System) "xấu" không xâm nhập vào hệ sinh thái của bạn ngay từ đầu;
• Liên tục theo dõi tất cả các ứng dụng trong sản xuất, tự động cảnh báo cho các nhóm phát triển khi có lỗ hổng phát sinh ảnh hưởng đến ứng dụng của họ.

Các chuyên gia đã đề cập đến một đoạn trích từ Tuyên ngôn DevSecOps từ devsecops.org, là trung tâm của nhiệm vụ của các chuyên gia tại Sonatype:

"Bằng cách phát triển bảo mật dưới dạng mã, các chuyên gia sẽ cố gắng tạo ra các sản phẩm và dịch vụ tuyệt vời, cung cấp thông tin chuyên sâu, trực tiếp cho các nhà phát triển, và thường lặp đi lặp lại để luôn đưa ra câu trả lời tốt nhất trước khi triển khai. Các chuyên gia sẽ vận hành như các nhà phát triển, nhằm đảm bảo sự sẵn có của bảo mật và tuân thủ, để sẵn sàng sử dụng như các dịch vụ. Các chuyên gia sẽ mở khóa và bỏ chặn các đường dẫn mới, để giúp các chuyên gia khác thấy ý tưởng của họ trở thành hiện thực".

Bài viết này ban đầu được xuất bản dưới dạng Hướng dẫn Sonatype, một phần của Cộng đồng Sonatype. Cộng đồng Sonatype là nơi bạn có thể đặt câu hỏi cho những người dùng Nexus khác và nhóm Sonatype. Nó cũng cung cấp nội dung và lộ trình học tập từ một nhóm các chuyên gia, giúp việc sử dụng Nexus trở nên dễ dàng hơn.