![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
Xin chào HackerNoon! Tên tôi là Sofia và tôi là kỹ sư DevOps/Cloud. Tôi quyết định tham gia cuộc thi do HackerNoon và Aptible tổ chức.
Trong bài viết này, tôi sẽ nói về các tính năng của quy trình DevSecOps và khái niệm Shift Left. Bạn sẽ tìm hiểu về các giai đoạn chính của quy trình DevSecOps, kiểm tra bảo mật tự động trong quá trình phát triển phần mềm cũng như các công cụ nguồn mở và miễn phí. Bạn cũng sẽ tìm thấy các mẹo giúp bạn phát hiện lỗ hổng sớm hơn và cải thiện tính bảo mật của ứng dụng.
Bài viết này sẽ giúp bạn đánh giá mức độ trưởng thành của quy trình DevSecOps, xây dựng lộ trình phát triển, chọn công cụ phù hợp cho từng nhiệm vụ và hiểu rõ hơn cách quản lý dự án theo triết lý DevSecOps.
Mục tiêu chính của phương pháp DevSecOps là đưa các biện pháp kiểm tra bảo mật tự động vào quy trình DevOps, tức là vào chính quy trình phát triển phần mềm.
Cách đây không lâu, các chuyên gia bảo mật thông tin đã tiến hành kiểm tra sau khi hoàn tất quá trình phát triển. Cách tiếp cận này không hiệu quả - nếu phát hiện ra lỗi trong quá trình kiểm tra bảo mật, toàn bộ chu trình phát triển phải được khởi động lại. Việc này tốn thời gian và tốn kém.
Hãy nhìn vào hình ảnh dưới đây. Bạn có thể thấy rằng chi phí sửa lỗi tăng lên theo từng bước.
Hầu như không tốn kém gì để khắc phục các vấn đề bảo mật được phát hiện trong quá trình phát triển và thử nghiệm chức năng. Tất cả những thay đổi cần thiết có thể được thực hiện ngay lập tức đối với mã nguồn và gửi đi kiểm tra lại.
Việc khắc phục sự cố ở giai đoạn xây dựng tạo tác tốn ít nhất gấp đôi. Bạn sẽ phải thực hiện các thay đổi trong quá trình xây dựng, chẳng hạn như chỉnh sửa Dockerfile, nghĩa là bạn sẽ cần sự trợ giúp của các kỹ sư DevOps.
Nếu phát hiện lỗi trong quá trình kiểm thử tích hợp, việc sửa lỗi sẽ tốn kém gấp 10 lần. Trong trường hợp này, bạn phải khởi động lại chu kỳ phát triển và có sự tham gia của các nhà phát triển, kỹ sư DevOps và người thử nghiệm.
Các vấn đề bảo mật được phát hiện ở giai đoạn triển khai có thể dẫn đến rò rỉ dữ liệu người dùng. Công ty có thể phải nhận hàng triệu đô la tiền phạt và tổn hại đến danh tiếng của mình, đồng nghĩa với việc cái giá phải trả cho một sai sót sẽ tăng lên hàng trăm lần.
Do đó, kết luận chính là việc kiểm tra an toàn nên được thực hiện càng sớm càng tốt. Nếu bạn hình dung nó, hãy di chuyển chúng sang phía bên trái của Đường ống. Đây là khái niệm Shift Left, được các chuyên gia bảo mật rất thích nói đến.
Quy trình DevSecOps là một chuỗi các quy trình và công cụ tự động giúp xây dựng, thử nghiệm và phân phối ứng dụng trong môi trường sản xuất cũng như bảo mật chúng ở mọi giai đoạn.
Hình ảnh trên hiển thị cấu trúc Đường ống DevSecOps với tất cả các giai đoạn kiểm tra bảo mật chính. Dưới đây là một vài từ về mỗi người trong số họ:
Tiếp theo, chúng ta hãy xem xét kỹ hơn những bước kiểm tra này là gì và những công cụ nào được sử dụng để thực hiện chúng.
Kiểm tra trước khi cam kết cho phép bạn phân tích mã nguồn trên máy của nhà phát triển trước khi thực hiện các thay đổi đối với bản sao cục bộ của kho lưu trữ. Nếu bất kỳ câu lệnh nào trả về lỗi, thì cam kết sẽ không được thực hiện. Trong trường hợp này, nhà phát triển phải sửa lỗi và cam kết lại.
Việc kiểm tra này sẽ tránh được tình huống khi mã không được kiểm tra, chẳng hạn như với các bí mật không được mã hóa, sẽ được đưa vào kho lưu trữ.
Để thực hiện kiểm tra mã nguồn trước khi cam kết, cần phải cài đặt các công cụ trên máy cục bộ của nhà phát triển. Cách tiếp cận này không chỉ có ưu điểm mà còn có nhược điểm. Ví dụ: sự khác biệt về môi trường: các phiên bản khác nhau của công cụ, hệ điều hành khác nhau và thậm chí cả kiến trúc bộ xử lý.
Nếu nhà phát triển sử dụng các phiên bản khác nhau của công cụ xác nhận trước thì kết quả kiểm tra sẽ khác nhau và điều này có thể gây khó khăn khi làm việc cùng nhau. Hãy cân nhắc điều này khi thực hiện kiểm tra trước khi cam kết trong một nhóm hoặc trên toàn công ty.
Nhiều công cụ nguồn mở có thể được sử dụng để thiết lập kiểm tra trước khi cam kết:
Đây là những công cụ tuyệt vời để kiểm tra trước khi cam kết.
Trong giai đoạn tiền xây dựng, Kiểm tra hộp trắng được thực hiện. Những bước kiểm tra này được sử dụng để phân tích mã nguồn, giống như bước trước. Trong trường hợp này, ứng dụng là một "hộp trắng" vì chúng ta biết và hiểu kiến trúc cũng như cấu trúc bên trong của nó.
Có một số loại kiểm tra trước khi xây dựng:
Bây giờ, hãy thảo luận chi tiết về chúng.
Phát hiện bí mật là một biện pháp kiểm tra tự động nhằm phát hiện thông tin nhạy cảm không được mã hóa: các bí mật không được mã hóa trong mã nguồn đã được đưa vào hệ thống kiểm soát phiên bản.
Kiểm tra trước khi xây dựng được thực hiện sau khi mã nguồn đã vào kho lưu trữ của hệ thống kiểm soát phiên bản. Do đó, tất cả dữ liệu nhạy cảm không được mã hóa trong bộ lưu trữ đều có thể bị kẻ tấn công truy cập, chẳng hạn như nếu nội dung của kho lưu trữ bị rò rỉ.
Ngoài ra, quá trình thực hiện kiểm tra phát hiện bí mật có thể diễn ra không phải từ đầu mà trong một dự án đang phát triển. Trong trường hợp này, các bí mật không được mã hóa có thể được tìm thấy trong các cam kết cũ và các nhánh kho lưu trữ khác nhau.
Để giải quyết những vấn đề này, chúng ta cần phải làm nhiều việc khác nhau. Ví dụ: chúng tôi phải dọn sạch kho chứa các bí mật không được mã hóa hoặc triển khai các công cụ quản lý bí mật khác nhau như Hashicorp Vault .
Phát hiện bí mật có thể được cấu hình bằng cách sử dụng
Kiểm tra bảo mật ứng dụng tĩnh (SAST) là một thử nghiệm khi các máy phân tích không chỉ kiểm tra tính chính xác của cú pháp mà còn đo lường chất lượng mã với sự trợ giúp của các số liệu duy nhất. Nhiệm vụ chính của máy quét SAST là kiểm tra bảo mật.
Đặc biệt, các bộ phân tích SAST chứa mã nguồn cho các lỗ hổng phổ biến, ví dụ: một số
Phân tích SAST được gọi là Kiểm thử hộp trắng vì máy phân tích có thể truy cập vào cấu trúc bên trong của ứng dụng. Điều quan trọng cần lưu ý là máy phân tích kiểm tra mã nguồn mà không chạy mã, vì vậy chúng có thể tạo ra kết quả dương tính giả và không phát hiện được một số lỗ hổng.
Vì lý do này, bạn không nên chỉ giới hạn mình ở phân tích SAST. Tốt hơn là nên tiếp cận vấn đề một cách toàn diện và sử dụng các loại phân tích khác nhau: SCA, DAST, IAST và OAST.
Giải pháp độc quyền:
Giải pháp miễn phí là GitLab SAST.
Phân tích thành phần phần mềm (SCA) là một phương pháp bảo mật các ứng dụng bằng cách phân tích các thành phần nguồn mở của chúng.
Máy quét SCA tìm kiếm các phần phụ thuộc lỗi thời có chứa các lỗ hổng và hoạt động khai thác đã biết. Ngoài ra, một số công cụ SCA có thể xác định tính tương thích giấy phép của các thành phần và nguy cơ vi phạm giấy phép.
SCA nguồn phân tích mã nguồn và cụ thể hơn là các phần phụ thuộc của ứng dụng được xác định trong mã nguồn. Phân tích này thường được gọi là Quét phụ thuộc.
SCA cho phép bạn phát hiện sự cố trong đó lỗ hổng trong một thành phần có thể dẫn đến sự cố bảo mật trong tất cả các ứng dụng.
Một ví dụ điển hình là
Giải pháp thương mại với gói giá miễn phí:
Là một phần của GitLab (chỉ có ở phiên bản Ultimate), bạn có thể sử dụng
Giai đoạn hậu xây dựng diễn ra sau khi các tạo phẩm được tạo từ mã nguồn trong Đường ống CI: hình ảnh Docker, gói RPM hoặc kho lưu trữ JAR. Với các bước kiểm tra sau xây dựng, bạn có thể phân tích các phần phụ thuộc trong các tạo phẩm nhị phân này.
Phân tích SCA nhị phân bao gồm việc kiểm tra các tạo phẩm nhị phân như hình ảnh Docker, gói RPM và kho lưu trữ JAR/WAR/EAR. Nó cũng thường được gọi là Quét vùng chứa. Sẽ rất hợp lý khi chạy nó khi các tạo phẩm nhị phân được xây dựng, tức là không phải trước giai đoạn hậu xây dựng.
Có một số tính năng thú vị khi làm việc với Docker image. Máy phân tích SCA nhị phân kiểm tra các lớp hình ảnh Docker và tìm kiếm chúng dưới dạng tổng băm trong cơ sở dữ liệu về lỗ hổng công khai, chẳng hạn như
Một số máy phân tích không chỉ có thể tìm thấy các thành phần dễ bị tấn công mà còn đề xuất cách khắc phục, chẳng hạn như bằng cách chỉ định phiên bản yêu cầu tối thiểu của thành phần có lỗ hổng đã được sửa.
Giải pháp miễn phí là
Giải pháp nguồn mở:
Docker Đăng ký với bộ phân tích tích hợp -
Ở giai đoạn này, Kiểm tra hộp xám động và Kiểm tra hộp đen được thực hiện. Khi cấu trúc bên trong của ứng dụng chưa được xác định một phần hoặc toàn bộ, các hoạt động kiểm tra bảo mật này được thực hiện bằng cách mô phỏng hành động của kẻ tấn công tìm thấy lỗ hổng và cố gắng "phá vỡ" ứng dụng bằng cách khai thác chúng. Chúng ta hãy thảo luận ngắn gọn về từng loại: DAST, IAST và OAST.
Máy quét DAST tự động kiểm tra ứng dụng bằng cách mô phỏng các cuộc tấn công từ bên ngoài thông qua nhiều lỗ hổng khác nhau. Ứng dụng này là một hộp đen dành cho máy phân tích; không có gì được biết về nó
Để kiểm tra DAST, cần phải có sẵn một phiên bản ứng dụng đang chạy cho máy quét. Hơn nữa, các tham số của phiên bản thử nghiệm của ứng dụng càng gần với quá trình cài đặt sản xuất thì càng có ít kết quả dương tính giả.
Ví dụ: giả sử bạn đã triển khai một phiên bản ứng dụng thử nghiệm chỉ có thể truy cập được qua giao thức HTTP, nhưng trong quá trình sản xuất, ứng dụng này chỉ có thể truy cập được qua giao thức HTTP.
Trong trường hợp đó, máy quét DAST sẽ phát sinh một số lỗi liên quan đến việc thiếu mã hóa lưu lượng giữa máy khách (máy phân tích) và máy chủ (phiên bản ứng dụng).
Các công cụ đáng để bạn quan tâm:
Tuyệt vời, tiếp tục nào.
IAST (Thử nghiệm bảo mật ứng dụng tương tác) là Thử nghiệm hộp xám kết hợp các ưu điểm và điểm mạnh của Thử nghiệm hộp trắng SAST và Thử nghiệm hộp đen DAST.
Để thu thập tất cả các ưu điểm và loại bỏ nhược điểm của phương pháp SAST và DAST, các nhà phát triển đã phát minh ra IAST - một cơ chế lai kết hợp các phương pháp này. Nó làm tăng độ chính xác của thử nghiệm động vì nó cung cấp thêm thông tin về hoạt động của ứng dụng thông qua phân tích mã.
Điều đáng ghi nhớ là bên cạnh những ưu điểm của nó, IAST còn có những hạn chế. Điều cơ bản nhất là sự phụ thuộc vào ngôn ngữ mà ứng dụng đang được thử nghiệm được viết. Các giải pháp IAST hoạt động ở cấp ứng dụng và yêu cầu quyền truy cập vào mã thực thi để phân tích hành vi của nó.
Điều này có nghĩa là các giải pháp IAST phải có khả năng hiểu được ngôn ngữ lập trình mà ứng dụng được viết. Cần lưu ý rằng việc hỗ trợ cho một giải pháp IAST cụ thể có thể được triển khai tốt hơn đối với một số ngôn ngữ so với các ngôn ngữ khác.
Phân tích IAST cũng mất nhiều thời gian. Nó phụ thuộc vào nhiều yếu tố, chẳng hạn như kích thước và độ phức tạp của ứng dụng, số lượng phần phụ thuộc bên ngoài và hiệu suất của công cụ IAST được sử dụng.
Ngoài ra, quá trình phân tích không tự quét mã mà chỉ kiểm tra những đoạn được thực thi trực tiếp. Do đó, phân tích IAST được kết hợp tốt nhất với thử nghiệm chức năng khi bạn có thể thử nghiệm nhiều kịch bản ứng dụng nhất có thể.
Dưới đây là những công cụ tuyệt vời dành cho bạn:
Tuyệt vời, tiếp tục nào.
OAST (Kiểm tra bảo mật ứng dụng ngoài băng tần) là một kỹ thuật được phát triển bởi
Tôi khuyên bạn:
Đi tiếp.
Đây là một giai đoạn thiết yếu trong việc đảm bảo tính bảo mật và khả năng hoạt động của ứng dụng. Không giống như kiểm tra trước khi cam kết, được thực hiện ở giai đoạn phát triển, kiểm tra sau triển khai cho phép bạn xác định các sự cố có thể xảy ra trong quá trình vận hành ứng dụng trong môi trường tự nhiên.
Để phát hiện kịp thời các lỗ hổng mới, cần phải thực hiện kiểm tra tạo tác thường xuyên, kể cả sau khi ứng dụng đã được triển khai.
Điều này có thể được thực hiện bằng cách sử dụng các kho lưu trữ hoặc công cụ đặc biệt, chẳng hạn như
Một cách khác để đảm bảo an ninh là giám sát chính ứng dụng đó. Có một số công nghệ có sẵn cho mục đích này:
Ưu điểm chính của RASP so với WAF là nó hiểu cách ứng dụng hoạt động và phát hiện các cuộc tấn công cũng như lưu lượng truy cập bất hợp pháp. RASP không chỉ có thể phát hiện các cuộc tấn công điển hình bằng cách sử dụng khớp chữ ký mà còn cố gắng khai thác các lỗ hổng zero-day bằng cách phản ứng với các điểm bất thường.
Không giống như WAF, RASP hoạt động bên trong và cùng với ứng dụng. WAF có thể bị lừa. Nếu kẻ tấn công thay đổi mã ứng dụng, WAF không thể phát hiện ra mã đó vì nó không hiểu ngữ cảnh thực thi.
RASP có quyền truy cập vào thông tin chẩn đoán về ứng dụng, có thể phân tích nó, phát hiện các điểm bất thường và chặn các cuộc tấn công.
Công nghệ RASP có điểm đặc biệt là tập trung vào việc ngăn chặn các cuộc tấn công theo mặc định. Hệ thống không yêu cầu quyền truy cập vào mã nguồn.
Tôi khuyên bạn:
Tuyệt vời, tiếp tục nào.
Ở các giai đoạn khác nhau của Quy trình, tôi sử dụng nhiều máy phân tích Kiểm tra bảo mật ứng dụng/DevSecOps. Mỗi người trong số họ tạo ra một báo cáo theo định dạng riêng và một số trong số họ tạo ra cái gọi là Thông tin tích cực sai. Do đó, việc phân tích tính bảo mật của toàn bộ ứng dụng là không dễ dàng.
Để phân tích hiệu quả các lỗ hổng và quản lý quy trình khắc phục, các công cụ Quản lý lỗ hổng chuyên dụng, thường được gọi đơn giản là Bảng thông tin bảo mật , sẽ được sử dụng.
Bảng thông tin bảo mật giải quyết vấn đề bằng cách cung cấp kết quả phân tích DevSecOps ở dạng thống nhất và dễ phân tích. Bằng cách này, các kỹ sư bảo mật có thể biết vấn đề nào đang tồn tại, vấn đề nào nghiêm trọng nhất và vấn đề nào cần được giải quyết trước tiên.
Nhiều công cụ thường được sử dụng làm Bảng thông tin bảo mật: ví dụ: hệ thống SOAR/SIEM cổ điển và bộ điều phối DevSecOps chuyên dụng AppSec.Hub của Swordfish Security hoặc bộ công cụ quản lý lỗ hổng mã nguồn mở DefectDojo.
DefectDojo là một công cụ phổ biến. Nó được sử dụng rộng rãi ngay cả trong các công ty doanh nghiệp. Tuy nhiên, bất chấp sự phổ biến và lâu đời của nó, công cụ này đôi khi có một số lỗi ở mức độ ban đầu khi những người đóng góp phá vỡ chức năng cơ bản trong cam kết.
Tuy nhiên, điều tuyệt vời là các nhà phát triển và người bảo trì DefectDojo giúp giải quyết những vấn đề phức tạp. Các nhà phát triển DefectDojo là những người rất nhạy bén - chúng tôi khuyên bạn nên liên hệ trực tiếp với họ thông qua Sự cố trên GitHub.
Một lần nữa, đây là bản tóm tắt nhanh về những gì có trong bài viết.
Tôi đã giải thích khái niệm Shift Left là gì và nó giúp giảm chi phí sửa lỗi cũng như thời gian phát triển như thế nào: bạn bắt đầu kiểm tra bảo mật càng sớm trong quá trình phát triển thì càng tốt.
Sau đó, tôi giải mã cấu trúc Đường ống DevSecOps và xem xét những biện pháp kiểm tra bảo mật nào được thực hiện ở mỗi giai đoạn của Đường ống:
Bây giờ, bạn đã hiểu cách thức hoạt động của Đường ống DevSecOps. Giờ đây, bạn có thể đánh giá mức độ trưởng thành của quy trình DevSecOps, xây dựng lộ trình phát triển và chọn công cụ phù hợp cho từng nhiệm vụ.