Cách biến quy trình DevOps thành quy trình DevSecOps: Tổng quan về khái niệm chuyển hướng sang trái

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.

Khái niệm dịch chuyển sang trái

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.

Cấu trúc quy trình DevSecOps

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ọ:

• Cam kết trước. Nó ngụ ý kiểm tra tính bảo mật của mã nguồn trước khi nhà phát triển đưa mã đó vào hệ thống kiểm soát phiên bản. Kiểm tra này cho phép bạn phát hiện thông tin bí mật không được mã hóa như mật khẩu hoặc khóa API.

• Xây dựng trước. Nó ngụ ý kiểm tra tính bảo mật của mã nguồn sau khi nó được đưa vào hệ thống kiểm soát phiên bản. Các công cụ này thực hiện phân tích tĩnh mã nguồn và các phần phụ thuộc của nó để phát hiện các lỗ hổng phổ biến, chẳng hạn như nhiều lỗ hổng bảo mật. Top 10 của OWASP danh sách.

• Sau xây dựng. Đó là kiểm tra bảo mật của một tạo phẩm được xây dựng từ mã nguồn, chẳng hạn như tệp Docker, gói RPM hoặc kho lưu trữ JAR. Các công cụ này phân tích môi trường ứng dụng và các phần phụ thuộc, tìm ra các phiên bản lỗi thời của các gói và thư viện đã có bản vá trong các phiên bản mới hơn.

• Thời gian thử nghiệm. Nó ngụ ý kiểm tra tính bảo mật của một ứng dụng chạy từ một tạo phẩm được thu thập. Các công cụ trong giai đoạn này cố gắng "phá" ứng dụng bằng cách mô phỏng hành động của kẻ tấn công.

• Sau khi triển khai. Nó ngụ ý kiểm tra tính bảo mật của ứng dụng sau khi nó được triển khai trong môi trường sản xuất. Các công cụ này giám sát các sổ đăng ký mở về các lỗ hổng đã biết trong thời gian thực và thông báo khi phát hiện thấy mối đe dọa đối với ứng dụng.

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

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.

Công cụ kiểm tra trước khi cam kết

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:

1. Gileaks
2. bí mật git
3. Quét bí mật Trivy
4. Thì thầm
5. git-tất cả bí mật
6. phát hiện bí mật
7. rò rỉ gitty

Đây là những công cụ tuyệt vời để kiểm tra trước khi cam kết.

Kiểm tra trước khi xây dựng

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:

• Phát hiện bí mật
• Kiểm tra bảo mật ứng dụng tĩnh (SAST)
• Phân tích thành phần phần mềm (SCA)

Bây giờ, hãy thảo luận chi tiết về chúng.

Kiểm tra phát hiện bí mật trước khi xây dự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 .

Công cụ phát hiện bí mật

Phát hiện bí mật có thể được cấu hình bằng cách sử dụng Gileaks , bí mật git , hoặc phát hiện bí mật . Tuy nhiên, tốt nhất nên sử dụng các dịch vụ được cung cấp bởi các nền tảng CI/CD nổi tiếng, chẳng hạn như Phát hiện bí mật GitLab .

Kiểm tra SAST trước khi xây 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ố Top 10 của OWASP danh sách. Điều cần thiết là phải nói rằng máy quét SAST không chỉ tìm thấy lỗ hổng mà còn cả đoạn mã gây ra lỗ hổng đó.

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.

Công cụ SAST

Giải pháp độc quyền:

• SonarQub e
• Dấu kiểm SAST
• Trình sàng lọc ứng dụng năng lượng mặt trời

Giải pháp miễn phí là GitLab SAST.

Kiểm tra SCA nguồn trước khi xây dựng

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à Log4Shell . Lỗ hổng này được phát hiện vào cuối năm 2021 trong Log4j, một khung ghi nhật ký Java phổ biến. Nó trở thành một trong những lỗ hổng đáng sợ nhất vì nó cho phép kẻ tấn công thực thi mã Java tùy ý trên hàng trăm triệu thiết bị.

công cụ SCA

Chuyện tầm thường là một giải pháp nguồn mở.

Giải pháp thương mại với gói giá miễn phí:

• FOSSA
• Sửa chữa SCA

Là một phần của GitLab (chỉ có ở phiên bản Ultimate), bạn có thể sử dụng Quét phụ thuộc GitLab .

Kiểm tra sau xây dựng: SCA nhị phân

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ư Cơ sở dữ liệu dễ bị tổn thương quốc gia (NVD) hoặc Cơ sở dữ liệu về lỗ hổng Snyk .

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.

Ví dụ về Máy phân tích SCA nhị phân phổ biến

Giải pháp miễn phí là Quét vùng chứa GitLab .

Giải pháp nguồn mở:

• chuyện vặt
• Clair
• Quả nho
• Bến cảng
• JFrog Xray
• Trung tâm Docker

Docker Đăng ký với bộ phân tích tích hợp - Hải cảng .

Kiểm tra thời gian thử nghiệm: DAST, IAST và OAST

Ở 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.

Kiểm tra DAST thời gian thử nghiệm

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).

Ví dụ về công cụ DAST

Các công cụ đáng để bạn quan tâm:

• GitLab DAST - chỉ có ở phiên bản Ultimate
• Proxy tấn công OWASP Zed (ZAP) — một giải pháp nguồn mở, cũng được sử dụng trong GitLab DAST
• Acunetix
• Củng cố WebInspect
• Quét ứng dụng bảo mật HCL
• Tóm tắt DAST được quản lý
• Tenable.io (Quét ứng dụng web)
• Phân tích động Veracode

Tuyệt vời, tiếp tục nào.

Kiểm tra IAST thời gian thử nghiệm

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ể.

Ví dụ về Công cụ IAST

Dưới đây là những công cụ tuyệt vời dành cho bạn:

• Người tìm kiếm tóm tắt
• Phân tích tương tác Veracode
• Microfocus Củng cố WebInspect
• Checkmarx CxIAST
• Đánh giá độ tương phản
• Phát hiện HDv (IAST)

Tuyệt vời, tiếp tục nào.

Kiểm tra OAST thời gian thử nghiệm

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 CổngSwigger và là phần mở rộng của DAST giúp tìm ra các lỗ hổng mà DAST không nhìn thấy, chẳng hạn như log4shell.

Ví dụ về các công cụ OAST

Tôi khuyên bạn:

• Phòng ợ
• OWASP ZAP với Plugin OAST
• Dịch vụ OAST KHOE KHOANG , Xe lam , Và tương tác

Đi tiếp.

Kiểm tra sau triển khai

Đâ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.

Giám sát sự an toàn của đồ tạo tác

Để 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ư Thùng chứa Snyk , Trivy, GitLab Container Scanning hoặc phát triển mô-đun tích hợp của bạn.

Giám sát bảo mật ứng dụng

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:

• Tường lửa ứng dụng web (WAF) là một công cụ lọc lưu lượng. Nó hoạt động ở lớp ứng dụng và bảo vệ các ứng dụng web bằng cách phân tích lưu lượng HTTP/HTTPS.

• RASP (Tự bảo vệ ứng dụng thời gian chạy) là công nghệ phát hiện và chặn các cuộc tấn công vào ứng dụng trong thời gian thực. Nó bổ sung chức năng bảo vệ vào môi trường thời gian chạy, cho phép ứng dụng tự động tự bảo vệ.

Ư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.

RASP ngu ngốc

Tôi khuyên bạn:

• củng cố
• màn hình vuông
• OpenRASP là một giải pháp nguồn mở được phát triển bởi Baidu
• Khoa học tín hiệu
• Jscrambler
• hdv
• không thấm nước

Tuyệt vời, tiếp tục nào.

Trực quan hóa kết quả của DevSecOps P ipelines và quản lý lỗ hổng

Ở 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.

Công cụ DevSecOps

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.

Khái niệm Shift Left: Hãy tóm tắt

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:

• Cam kết trước. Nó ngụ ý kiểm tra tính an toàn của mã nguồn trước khi nó đi vào hệ thống kiểm soát phiên bản.

• Xây dựng trước. Đó là kiểm tra tính bảo mật mã nguồn trong hệ thống kiểm soát phiên bản (Phát hiện bí mật, SAST, SCA).

• Sau xây dựng. Đó là kiểm tra bảo mật của một tạo phẩm được xây dựng từ mã nguồn (SCA nguồn, SCA nhị phân).

• Thời gian thử nghiệm. Nó ngụ ý kiểm tra tính bảo mật của ứng dụng đang chạy từ tạo phẩm được thu thập (DAST, IAST và OAST).

• Sau triển khai. Nó ngụ ý kiểm tra bảo mật ứng dụng sau khi triển khai trong môi trường sản xuất (WAF, RASP).

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ụ.