DevSecOps là từ viết tắt của Development (phát triển), Security (bảo mật) và Operations (vận hành). DevSecOps là một phương thức kết hợp công việc được thực hiện bởi team phát triển (Dev), bảo mật (Sec) và hoạt động IT (Ops) để cung cấp các phương pháp phát triển phần mềm hiệu quả nhất. Bài viết này giải thích tại sao DevSecOps vẫn rất hiếm, xem xét những khó khăn khi triển khai DevSecOps và cách loại bỏ chúng.
Tại sao DevOps mà không phải DevSecOps?
DevOps là một phương pháp thực hành chủ yếu đi cùng với các phương pháp luận lin hoạt cho vòng đời phát triển phần mềm (SDLC). Mục tiêu chính là cung cấp phần mềm trong các chu kỳ phát hành ngắn, hiệu quả cũng như hợp lý hóa và tự động hóa càng nhiều quy trình phát triển và quy trình phân phối phần mềm càng tốt. Thật khó để tưởng tượng một quy trình lập trình linh hoạt mà không có tự động hóa rộng rãi các quy trình xây dựng và kiểm tra, tức là không có các pipeline tích hợp liên tục / phân phối liên tục (CI/CD) tạo thành nền tảng của DevSecOps.
Sẽ không thể có DevOps nếu quá trình xây dựng và thử nghiệm – một phần của chu trình phát triển, vẫn là thủ công. Tuy nhiên, trong cách tiếp cận ban đầu với DevOps, dường như không ai nghĩ đến việc tích hợp bảo mật. Nguyên nhân có thể là gì?
DevOps CI/CD pipeline điển hình bao gồm các bước sau:
- Cung cấp môi trường được định cấu hình trước (ví dụ: vùng chứa Docker qua Kubernetes)
- Xây dựng ứng dụng (hoặc API / microservice)
- Triển khai ứng dụng vào môi trường được định cấu hình trước
- Chạy các bài kiểm tra tự động trên ứng dụng đã biên soạn để đảm bảo rằng chức năng của nó đáp ứng các yêu cầu (ví dụ: kiểm tra giao diện người dùng Selenium)
Dường như sẽ logic hơn khi thêm 1 bước vào pipeline trên:
- Chạy các thử nghiệm bảo mật tự động trên ứng dụng được biên soạn để đảm bảo rằng nó đáp ứng các yêu cầu bảo mật.
Nhưng đây không phải là trường hợp trong hầu hết các môi trường DevOps – đó là lý do tại sao chúng không phải là quá trình DevSecOps.
Nguyên nhân của thiếu sót đó trên DevSecOps
Hãy xem xét các lý do tại sao các tổ chức thực hiện thành công Devops thường không bao gồm bất kỳ thực hành bảo mật nào trong các quy trình DevOPS của họ.
Nguyên nhân 1. Thiếu nhận thức về an ninh
Nhiều tổ chức không bao gồm các biện pháp kiểm soát bảo mật trong các quy trình DevOps của họ đơn giản vì họ không nghĩ rằng việc cung cấp phần mềm bảo mật quá quan trọng.
Ngay cả trong thế giới biến đổi kỹ thuật số, nhiều tổ chức có nhận thức hạn chế về an ninh mạng và chủ yếu tiếp nhận thông tin đó từ quan điểm của phương tiện truyền thông về ransomware và phishing. Mặc dù đúng là ransomware và phishing là các mối đe dọa bảo mật lớn và bạn không thể làm gì trong các pipeline để giảm thiểu những rủi ro bảo mật như vậy, đây không phải là tất cả mọi thứ về an ninh mạng.
Các tổ chức đôi khi không nhận ra rằng ngoài tấn công phi kỹ thuật, hacker mũ đen có thể rất dễ dàng khai thác lỗ hổng trong ứng dụng để truy cập dữ liệu nhạy cảm hoặc thậm chí chiếm quyền kiểm soát ứng dụng, hoặc toàn bộ máy chủ. Điều này có thể dẫn đến các cuộc tấn công tiếp theo, bao gồm cả ransomware. Ví dụ: nếu một hacker mũ đen có thể thực thi code từ xa bằng ứng dụng web gốc đám mây của bạn và cài đặt một trình bao ngược lại, chúng có thể thực hiện các lệnh trên máy chủ và, giả sử, triển khai ransomware lây lan và tàn phá toàn bộ môi trường mạng của bạn. Và trong trường hợp như vậy, nguyên nhân gốc rễ là do thiếu bảo mật của ứng dụng và không có ransomware và chống phishing nào sẽ giúp bạn.
Do đó, bước đầu tiên và quan trọng nhất đối với DevSecOps là thu hút mọi người tham gia và thúc đẩy trách nhiệm chung, đặc biệt là giữa những người ra quyết định. Họ phải nhận ra rằng code bảo mật là điều quan trọng hàng đầu. Họ phải hỗ trợ bạn trong hành trình DevSecOps của bạn.
Nguyên nhân 2. Thiếu hiểu biết về bảo mật
Các đội bảo mật thường làm việc trong silo các hầm chứa đơn giản vì công việc của họ hoàn toàn không được hiểu. Thuật ngữ bảo mật bao gồm một phạm vi cực kỳ rộng. Bảo mật tổ chức của bạn bằng cách thực hiện các quy trình giám sát tuân thủ và truyền bá nhận thức rất khác với việc bảo mật các ứng dụng của bạn thông qua thử nghiệm thâm nhập sâu. Nó đòi hỏi những kỹ năng hoàn toàn khác. Và ngay cả các lĩnh vực có vẻ liên quan như an ninh mạng và bảo mật ứng dụng cũng hoàn toàn khác nhau, đòi hỏi các kỹ năng, công cụ và cách tiếp cận chính sách bảo mật khác nhau.
Sự thiếu hiểu biết dẫn đến các nhiệm vụ bảo mật được coi là “thứ ta kiểm tra ở cuối” thay vì “thứ ta kiểm tra khi ta phát triển và cung cấp”. Nhiều chuyên gia bảo mật trong các tổ chức hiện tại xuất thân từ nền tảng an ninh mạng và không thực sự hiểu khái niệm về bảo mật ứng dụng. Họ không coi DevSecOps là có thể đạt được đơn giản vì họ chủ yếu nghĩ về bảo mật mạng – không phải điều bạn cần xem xét trong quá trình phát triển ứng dụng.
Nhiều tổ chức vẫn không đề cao vấn đề nhận thức về bảo mật, mà không nghĩ đến nguyên nhân chính của rất nhiều vi phạm an ninh lớn. Ví dụ về việc này là vụ hack Capital One nổi tiếng năm 2019.
Nguyên nhân 3. Thiếu kiến thức về tự động hóa bảo mật
Bảo mật thông tin vẫn thường được coi là một quy trình thủ công. Nhiều tổ chức tin rằng phần cốt lõi của việc kiểm tra tính bảo mật của một ứng dụng là kiểm tra thâm nhập (PenTest) thủ công. Công việc của kỹ sư kiểm thử (Pentester) thường được kết hợp với các công cụ hoàn toàn thủ công giúp họ, ví dụ như, yêu cầu bộ nhớ cache và gửi payload.
Tuy nhiên, các dịch vụ bảo mật phần mềm đã vượt ra khỏi thử nghiệm thủ công. Cũng giống như các kỹ sư an ninh mạng không gửi các lệnh thủ công qua Telnet mà sử dụng rò quét tự động, các kỹ sư bảo mật ứng dụng hiện đại sử dụng các công cụ tự động để khám phá những vấn đề phổ biến nhất. Như vậy, họ có thể tập trung vào việc đào sâu hơn vào các lỗ hổng nâng cao sau đó – điều mà đối với hầu hết các kỹ sư bảo mật hài lòng hơn nhiều so với việc kiểm tra một SQL Injection cơ bản khác.
Cũng giống như kiểm tra giao diện người dùng (UI) tự động đã gần như thay thế hoàn toàn kiểm tra thủ công ngoại trừ các trường hợp đặc biệt, do đó, việc rò quét lỗ hổng tự động đã thay thế phần lớn kiểm tra thâm nhập thủ công – nhưng kiểm tra thâm nhập vẫn được thực hiện cho các vấn đề không thể được phát hiện tự động. Kiểm tra tư thế bảo mật (security posture) theo cách thủ công trong silo cũng hiện đại như cách click thủ công qua giao diện người dùng của ứng dụng thay vì sử dụng Selenium.
Nguyên nhân 4. Thiếu niềm tin vào các công cụ bảo mật
Ngay cả khi một tổ chức đánh giá cao tầm quan trọng của bảo mật ứng dụng và những người ra quyết định đã hoàn toàn sẵn sàng, vẫn có một vấn đề cản trở DevSecOps: khả năng hạn chế của một số công cụ.
Hãy tưởng tượng một DevOps pipeline với những kiểm tra tự động thường không thành công mặc dù ứng dụng được kiểm tra thực sự đúng. Tưởng tượng sẽ mất bao nhiêu thời gian để các nhà phát triển quay lại môi trường phát triển, xem lại code ứng dụng, đảm bảo rằng mọi thứ đều ổn và sau đó liên hệ với nhóm phát triển thử nghiệm sửa các bài kiểm tra tự động để chúng không bị lỗi (hoặc đơn giản, nếu có thể, hãy đánh dấu các bài kiểm tra theo cách thủ công là đã thông qua). Và thử tưởng tượng sự thất vọng nếu điều này tiếp tục xảy ra.
Đối với kiểm thử đơn vị tự động, đây không phải là một tình huống phổ biến. Tuy nhiên, trong thế giới bảo mật ứng dụng, nơi mà việc kiểm tra thường được thực hiện bằng các công cụ phân tích code (SAST – kiểm tra bảo mật ứng dụng tĩnh), điều này xảy ra hàng ngày. Và nhà phát triển đang đấu tranh với một kết quả false positive không thể đơn giản yêu cầu nhóm phát triển thử nghiệm sửa công cụ, vì công cụ này thường là ứng dụng của bên thứ ba.
Đây là lý do tại sao các nỗ lực giới thiệu các phương pháp DevSecOps có xu hướng thất bại thường xuyên. Các thành viên trong nhóm DevOps ban đầu có thể hào hứng với việc giới thiệu thử nghiệm bảo mật tự động vào các pipeline, nhưng sau đó họ triển khai nó bằng cách sử dụng một trong nhiều công cụ phân tích tĩnh được tiếp thị là lựa chọn tốt nhất cho DevSecOps, và phát hiện ra rằng nó không hoạt động vì số lượng false positive nhiều đến mức không thể chấp nhận được. Tổ chức càng lớn, sự thất vọng càng lớn – và nguy cơ DevSecOps sẽ không được xem xét lại càng lớn.
Nguyên nhân 5. Thiếu hiểu biết về các công cụ
Một phần do thiếu nhận thức (xem Nguyên nhân 3), các nhóm DevOps thường tập trung vào SAST như là công cụ DevSecOps được lựa chọn và thậm chí không coi DAST là thứ có thể được đưa vào CI/CD pipeline. Lý do rất đơn giản: hầu hết các công cụ DAST không phù hợp với DevSecOps vì chúng không cung cấp đủ tính năng tự động hóa.
Các công cụ DAST vẫn được coi là những trình quét đơn giản, chạy một lần như cách đây vài năm và chúng vẫn thường được phát triển trong hệ sinh thái mã nguồn mở. Cách sử dụng truyền thống của công cụ DAST là chạy quét bảo mật trên một ứng dụng runtime đã được triển khai trong môi trường dàn dựng hoặc môi trường sản xuất – và điều đó rõ ràng là không linh hoạt chút nào. Chỉ cần tưởng tượng điều gì sẽ xảy ra khi quá trình quét tìm thấy lỗ hổng bảo mật nghiêm trọng – để tiếp tục khắc phục, ứng dụng phải quay trở lại bảng vẽ và toàn bộ chu trình nhanh mà nó đã trải qua cần được lặp lại.
Tuy nhiên, không phải tất cả các công cụ DAST đều là trình quét đơn giản. Một số, như Acunetix, hiện được sản xuất để tích hợp trực tiếp vào CI/CD pipeline. Chúng có thể làm việc trực tiếp với các công cụ như Jenkins, bạn có thể thiết lập chúng thông qua hoặc trượt tùy thuộc vào loại lỗ hổng được phát hiện và – quan trọng nhất – chúng vượt xa SAST về độ chính xác, hiệu suất và phạm vi lỗ hổng được phát hiện. Chúng được tạo ra để làm việc trong một trường hợp kiểm thử shift-left.
Có một nhược điểm nhỏ đối với DAST khi so sánh với SAST: các công cụ phân tích code có thể xác định chính xác dòng code nơi phát hiện ra vấn đề bảo mật, trong khi DAST không thể làm điều đó. Tuy nhiên, trong một môi trường Agile điển hình, các thay đổi và bổ sung code trong mỗi bản dựng là rất nhỏ và do đó nhà phát triển rất dễ dàng xác định được vấn đề nằm ở đâu trong mã nguồn. Nhà phát triển rất thường xuyên nhận được báo cáo rằng bản dựng không thành công khi quét bảo mật DAST cũng chính là người đã đưa ra các thay đổi ngay từ đầu. Và nếu điều đó là không đủ, một số công cụ DAST như Acunetix có tùy chọn IAST (AcuSensor) kết hợp những gì tốt nhất của cả hai thế giới với chi phí triển khai phức tạp hơn một chút.
Con đường bảo mật ứng dụng phía trước
Làm cách nào để bạn có thể vượt qua những khó khăn khi đưa kiểm thử bảo mật trực tiếp vào việc phát triển ứng dụng của mình?
- Giáo dục mọi người trong tổ chức của bạn về tầm quan trọng của bảo mật ứng dụng. Đảm bảo rằng họ nhận ra rằng nó phải được chú ý tương tự như các mối đe dọa được thổi phồng hơn như ransomware và phishing.
- Giáo dục mọi người trong tổ chức của bạn rằng an ninh mạng và bảo mật ứng dụng là hai thứ hoàn toàn khác nhau, và mặc dù an ninh mạng không có chỗ đứng như một phần của DevOps, bảo mật ứng dụng phải là một phần của DevOps để tổ chức của bạn thực sự linh hoạt.
- Hướng dẫn mọi người trong tổ chức của bạn rằng các công cụ DAST không còn là những công cụ quét bảo mật đơn giản như cách đây vài năm. Đảm bảo rằng họ nhận ra rằng các công cụ DAST hiện được thiết kế để đưa vào CI/CD pipeline – và chúng có thể thực hiện công việc tốt hơn nhiều so với các công cụ SAST trong vai trò đó.