Giới thiệu
Theo nhiều cách, chuỗi cung ứng phần mềm tương tự như chuỗi cung ứng của hàng hóa sản xuất, mà tất cả chúng ta đều biết đã bị ảnh hưởng phần lớn bởi đại dịch toàn cầu và tình trạng thiếu nguyên liệu thô.
Tuy nhiên, trong thế giới CNTT, không phải sự thiếu hụt hay đại dịch là trở ngại chính cần vượt qua trong những năm gần đây, mà là các cuộc tấn công nhằm sử dụng chúng để gây hại cho hàng trăm hoặc thậm chí hàng nghìn nạn nhân cùng một lúc. Nếu bạn đã nghe nói về một cuộc tấn công mạng từ năm 2020 đến ngày nay, có khả năng chuỗi cung ứng phần mềm đã đóng một vai trò nào đó.
Khi chúng ta nói về một cuộc tấn công vào chuỗi cung ứng phần mềm, chúng ta thực sự đang đề cập đến hai cuộc tấn công liên tiếp: một cuộc tấn công nhắm vào nhà cung cấp và một cuộc tấn công nhắm vào một hoặc nhiều người dùng hạ nguồn trong chuỗi, sử dụng cuộc tấn công đầu tiên làm phương tiện.
Trong bài viết này, chúng tôi sẽ đi sâu vào các cơ chế và rủi ro của chuỗi cung ứng phần mềm bằng cách xem xét một lỗ hổng điển hình của chu kỳ phát triển hiện đại: sự hiện diện của thông tin nhận dạng cá nhân, hoặc "bí mật", trong tài sản kỹ thuật số của các công ty. Chúng ta cũng sẽ xem các công ty đang thích ứng với tình hình mới này như thế nào bằng cách tận dụng các chu kỳ cải tiến liên tục.
Chuỗi cung ứng, trung tâm của chu kỳ phát triển CNTT
Chuỗi cung ứng là gì?
Ngày nay, cực kỳ hiếm khi thấy các công ty sản xuất phần mềm 100% nội bộ. Cho dù đó là thư viện nguồn mở, công cụ dành cho nhà phát triển, hệ thống triển khai và phân phối tại chỗ hoặc dựa trên đám mây hay dịch vụ phần mềm dưới dạng dịch vụ (SaaS), các khối xây dựng này đã trở nên thiết yếu trong nhà máy phần mềm hiện đại.
Mỗi "viên gạch" này tự nó là sản phẩm của một chuỗi cung ứng dài, làm cho chuỗi cung ứng phần mềm trở thành một khái niệm bao gồm mọi khía cạnh của CNTT: từ phần cứng, đến mã nguồn được viết bởi các nhà phát triển, đến các công cụ và nền tảng của bên thứ ba, mà còn lưu trữ dữ liệu và tất cả các cơ sở hạ tầng được đưa ra để phát triển, thử nghiệm và phân phối phần mềm.
Chuỗi cung ứng là một cấu trúc phân lớp cho phép các công ty triển khai các nhà máy phần mềm có tính linh hoạt cao, là động cơ chuyển đổi kỹ thuật số của họ.
Việc tái sử dụng hàng loạt các thành phần và thư viện mã nguồn mở đã đẩy nhanh đáng kể chu kỳ phát triển và khả năng cung cấp chức năng theo mong đợi của khách hàng. Nhưng đối tác của lợi nhuận ấn tượng này là mất kiểm soát nguồn gốc của mã đi vào sản phẩm của các công ty. Chuỗi phụ thuộc này khiến các tổ chức và khách hàng của họ phải đối mặt với các lỗ hổng được đưa ra bởi những thay đổi nằm ngoài tầm kiểm soát trực tiếp của họ.
Đây rõ ràng là một vấn đề an ninh mạng lớn, và một vấn đề chỉ đang gia tăng khi chuỗi cung ứng ngày càng trở nên phức tạp hơn qua từng năm. Vì vậy, không có gì ngạc nhiên khi các cuộc tấn công mạng quy mô lớn đã có thể khai thác nó để có lợi cho họ gần đây.
Rủi ro của liên kết yếu
Đối với tin tặc, chuỗi cung ứng phần mềm của các công ty đại diện cho một mục tiêu thú vị vì một số lý do. Trước hết, vì sự phức tạp của nó và số lượng "viên gạch" tương tác ở trung tâm của nhà máy phần mềm, bề mặt tấn công của nó rất lớn. Thứ hai, bảo mật ứng dụng, vốn trước đây tập trung vào việc bảo mật ứng dụng trong sản xuất (tức là tiếp xúc với công chúng), thường thiếu khả năng hiển thị và công cụ để bảo mật hiệu quả các máy chủ xây dựng nội bộ và các phần khác của quy trình CI / CD.
Ngoài ra, điều quan trọng là phải hiểu rằng chuỗi phát triển ngày nay không ngừng phát triển, bổ sung các công cụ mới liên tục. Đây là một trong những đặc điểm xác định của phong trào DevOps, đã làm mờ ranh giới giữa phát triển và vận hành rất nhiều, cho phép các nhà phát triển tự do cung cấp các tính năng cho khách hàng của họ nhanh nhất có thể.
Những lựa chọn này mặc dù thường được thực hiện mà không có sự giám sát và có thể rất khác nhau giữa các nhóm, ngay cả trong cùng một bộ phận. Việc tích lũy các công cụ, thư viện và nền tảng hơi khác nhau khiến việc tạo ra hàng tồn kho chính xác là nền tảng của việc quản lý bảo mật hiệu quả trở nên rất khó khăn.
Cuối cùng, bằng cách khai thác chuỗi cung ứng, tin tặc tìm cách tối đa hóa tác động, và do đó mang lại lợi nhuận của một cuộc tấn công. Để hiểu điều này, chúng ta phải xem xét rằng các sản phẩm và dịch vụ của chuỗi cung ứng của một công ty dịch vụ phần mềm là nền tảng của các chuỗi cung ứng khác. Kẻ tấn công đã xâm nhập thành công vào một liên kết trong chuỗi có thể xâm phạm toàn bộ cơ sở người dùng, điều này có thể gây ra hậu quả tai hại.
Sự gia tăng của các cuộc tấn công chuỗi cung ứng
Trong cuộc tấn công SolarWinds, từ tháng 3 đến tháng 6 năm 2020, khoảng 18.000 khách hàng nền tảng Orion, bao gồm một số cơ quan chính phủ Hoa Kỳ, đã tải xuống các bản cập nhật với mã độc được tiêm vào chúng. Mã này đã cấp quyền truy cập cửa hậu trái phép vào các hệ thống và mạng riêng. SolarWinds đã không phát hiện ra vi phạm cho đến tháng 2020 năm XNUMX. Một vụ bê bối quốc tế xảy ra sau đó.
Vài tuần sau, vào tháng 1 năm 2021, kẻ tấn công đã lấy được thông tin đăng nhập được sử dụng trong việc tạo hình ảnh Docker liên quan đến phần mềm Codecov, do lỗi trong quá trình xây dựng. Những thông tin đăng nhập này cho phép kẻ tấn công chiếm đoạt Codecov, một phần mềm để kiểm tra phạm vi mã của nhà phát triển và biến nó thành một con ngựa Trojan thực sự: vì phần mềm được sử dụng trong môi trường tích hợp liên tục (CI), nó có quyền truy cập vào thông tin đăng nhập bí mật của các quy trình xây dựng (chúng tôi sẽ quay lại điều này).
Do đó, kẻ tấn công đã có thể hút hàng trăm thông tin đăng nhập từ người dùng Codecov, cho phép anh ta truy cập vào nhiều hệ thống an toàn. Công ty chỉ phát hiện ra vi phạm vài tháng sau đó, vào tháng Tư.
Vào ngày 2 tháng 7 năm 2021, khoảng 90ngày sau, một nhóm ransomware tinh vi đã khai thác lỗ hổng trong các máy chủ của Quản trị viên hệ thống ảo Kaseya (VSA) - ảnh hưởng đến khoảng 1500 doanh nghiệp nhỏ. Kaseya là nhà phát triển phần mềm quản lý mạng, hệ thống và cơ sở hạ tầng được sử dụng bởi các nhà cung cấp dịch vụ được quản lý (MSP) và các nhà thầu CNTT khác. Mặc dù một cuộc tấn công ransomware đã kiểm soát hệ thống của khách hàng, cuộc tấn công đã được ngăn chặn và đánh bại sau vài ngày.
Nhưng đây không phải là lỗ hổng chuỗi cung ứng lớn nhất của năm 2021. Vào tháng 12 năm 2021, một vài tháng sau sự cố Kaseya, điều được cho là cuộc tấn công đơn giản nhất nhưng phổ biến nhất vào chuỗi cung ứng phần mềm đã xảy ra. Sau khi bằng chứng khái niệm ban đầu (POC) được tiết lộ, những kẻ tấn công bắt đầu khai thác ồ ạt một lỗ hổng ảnh hưởng đến Apache Log4j, một thư viện ghi nhật ký mã nguồn mở cực kỳ phổ biến trong hệ sinh thái Java.
Mặc dù một bản cập nhật khắc phục sự cố đã được đề xuất tương đối nhanh chóng, nhưng thực tế là thư viện này, chỉ được duy trì bởi một số ít người, được sử dụng trên quy mô rất lớn trên khắp thế giới và hiếm khi một cách minh bạch, đã tạo ra một bề mặt tấn công khổng lồ sẽ mất nhiều năm để giải quyết: Cơ quan An ninh Cơ sở hạ tầng và An ninh mạng Hoa Kỳ (CISA) vừa mô tả nó là "đặc hữu, " có nghĩa là nó có thể sẽ xuất hiện trở lại trong thập kỷ tới.
Bất chấp mức độ nghiêm trọng của nó, lỗ hổng này không phải là một trường hợp cá biệt: số lượng các cuộc tấn công sử dụng hệ sinh thái nguồn mở làm vectơ lan truyền để tiếp cận chuỗi cung ứng đã tăng 650% từ năm 2020 đến năm 2021. Cơ quan An ninh mạng châu Âu (ENISA) dự đoán rằng các cuộc tấn công chuỗi cung ứng sẽ tăng gấp bốn lần vào năm 2022.
Tất cả các cuộc tấn công và lỗ hổng này đã làm nổi bật sự thiếu tầm nhìn và các công cụ để bảo vệ hiệu quả chuỗi cung ứng, cho dù đó là hệ thống kiểm kê việc sử dụng các thành phần nguồn mở, để xác minh tính toàn vẹn của chúng hay để ngăn chặn rò rỉ thông tin nhạy cảm. Về điểm cuối cùng này, điều quan trọng là phải lùi lại một bước và xem xét kỹ hơn yếu tố bảo mật quan trọng này.
Chìa khóa của chuỗi cung ứng: bí mật
Nắm giữ thông tin đăng nhập không được mã hóa là cách hoàn hảo để tin tặc xoay trục và di chuyển chuỗi cung ứng từ nhà cung cấp sang khách hàng của mình: với thông tin đăng nhập hợp lệ, những kẻ tấn công hoạt động như người dùng được ủy quyền và việc phát hiện sau xâm nhập trở nên khó khăn hơn nhiều.
Từ quan điểm phòng thủ, các bí mật được mã hóa cứng là một loại lỗ hổng duy nhất. Mã nguồn là một tài sản rất rò rỉ vì về bản chất nó được dự định thường xuyên được sao chép và phân phối trên nhiều máy. Trong thực tế, những bí mật trong mã nguồn đi cùng với nó. Nhưng vấn đề hơn nữa là mã cũng có 'bộ nhớ'.
Ngày nay, bất kỳ kho lưu trữ mã nào cũng được quản lý thông qua hệ thống kiểm soát phiên bản (VCS), thường là Git, giữ một dòng thời gian hoàn hảo về tất cả các thay đổi đã được thực hiện đối với các tệp trong cơ sở mã, đôi khi qua nhiều thập kỷ. Vấn đề là những bí mật vẫn còn hiệu lực có thể ẩn bất cứ nơi nào trên dòng thời gian đó, mở ra một chiều hướng mới, lần này là lịch sử, cho bề mặt tấn công phần mềm.
Thật không may, hầu hết các lần quét bảo mật bị giới hạn trong việc kiểm tra trạng thái hiện tại, được triển khai hoặc sắp được triển khai của mã nguồn của ứng dụng. Nói cách khác, khi nói đến những bí mật bị chôn vùi trong một cam kết cũ hoặc thậm chí là một nhánh chưa bao giờ được triển khai, các công cụ truyền thống hoàn toàn mù quáng.
Chỉ riêng năm ngoái, hơn 6 triệu bí mật đã được công bố trong các cuộc repos công khai chỉ riêng trên GitHUb: trung bình, 3 cam kết trong số 1,000 bí mật chứa một bí mật Đây là mức tăng năm mươi phần trăm so với năm trước.
Một số lượng lớn những bí mật này đã cho phép truy cập vào các nguồn lực của công ty. Điều quan trọng là phải hiểu rằng ngay cả khi phần lớn các dự án mã nguồn mở được lưu trữ trên GitHub là kho lưu trữ cá nhân, thì rất dễ dàng để một nhà phát triển chuyên nghiệp vô tình xuất bản mã cho phép truy cập vào tài nguyên của công ty. Nó xảy ra thường xuyên!
Do đó, không có gì đáng ngạc nhiên khi một tác nhân độc hại đang tìm cách thực hiện một cuộc tấn công vào chuỗi cung ứng phần mềm sẽ xem xét kỹ các kho lưu trữ công khai trên GitHub: họ sẽ có cơ hội tốt để phát hiện ra sai sót trong tầm tay, chủ yếu là các bí mật có trong mã nguồn cho phép anh ta xác thực bản thân với một hệ thống mà không làm dấy lên bất kỳ nghi ngờ nào.
Khi một bí mật được công bố, nó phải ngay lập tức được coi là bị xâm phạm: một thử nghiệm đơn giản bao gồm việc tự nguyện xuất bản một "mã thông báo chim hoàng yến", tức là một mã có sự xuất hiện khá của một bí mật hợp lệ, với cơ chế cảnh báo được kích hoạt khi nó được sử dụng. Thời gian từ khi xuất bản đến cảnh báo trung bình là 4 giây! Không gian này được giám sát chặt chẽ và tích cực khai thác.
Để vô hiệu hóa nguy cơ xâm nhập càng nhanh càng tốt, chỉ có một giải pháp: thu hồi ngay lập tức bí mật. Tuy nhiên, do hoảng loạn hoặc thiếu kiến thức kỹ thuật, một số người cố gắng che đậy lỗi bằng cách thêm một cam kết xóa bí mật, điều này hoàn toàn không làm giảm thiểu lỗ hổng bảo mật: thực sự, Git theo dõi tất cả lịch sử mã được thêm, sửa đổi hoặc xóa theo thời gian. Trong thực tế, điều này có nghĩa là rất khó để xóa tất cả dấu vết của một lỗi trong quá khứ. Điều đó cũng có nghĩa là, trong nhiều trường hợp, bí mật sẽ vẫn có sẵn trực tuyến ngay cả sau khi nó đã bị xóa khỏi trạng thái "cuối cùng" của mã.
Nhưng vấn đề không kết thúc ở đó. Trong kịch bản của chúng tôi, khi tệp chứa bí mật được thay thế bằng tệp "sạch", bí mật sẽ không còn có thể phát hiện được nữa trong quá trình xem xét mã thủ công bởi đồng nghiệp (một thực tế phổ biến) hoặc bằng các công cụ bảo mật ứng dụng truyền thống như máy quét, cũng chỉ xem xét phiên bản mã nguồn mới nhất. Tệ hơn nữa, lỗ hổng sẽ bị trùng lặp mỗi khi mã được nhân bản, và do đó có nguy cơ bị tuyên truyền âm thầm trong một thời gian dài. Nói cách khác, một ơn trời cho tin tặc.
Vào ngày 3 tháng 7, Giám đốc điều hành của gã khổng lồ tiền điện tử Binance đã cảnh báo về một vụ vi phạm lớn được cho là đã làm rò rỉ "1 tỷ hồ sơ của cư dân [Trung Quốc]" thuộc cảnh sát Thượng Hải, bao gồm "tên, địa chỉ, danh tính quốc gia, điện thoại di động, cảnh sát và hồ sơ y tế". Nguyên nhân? Một đoạn mã nguồn chứa bí mật kết nối với cơ sở dữ liệu thông tin cá nhân khổng lồ đã được cho là sao chép và dán vào blog bởi các nhà phát triển CSDN của Trung Quốc.
Repos riêng tư cũng bị ảnh hưởng
Không có gì đáng ngạc nhiên, đây chỉ là phần nổi của tảng băng chìm. Kho lưu trữ riêng tư ẩn nhiều bí mật hơn so với các đối tác công khai của họ. Làm việc trong một môi trường khép kín mang lại cảm giác an toàn sai lầm, khiến những người đóng góp bớt nghi ngờ hơn một chút, và do đó về mặt thống kê có nhiều khả năng "để rò rỉ bí mật". Chịu đựng sự hiện diện của bí mật trong các kho lưu trữ không được tiết lộ công khai sẽ là một sai lầm lớn.
Thật vậy, bất kể các kho lưu trữ này riêng tư đến đâu, những bí mật mà chúng chứa có thể được sử dụng làm đòn bẩy trong một cuộc tấn công, cho phép các đối thủ có quyền truy cập vào kho lưu trữ xoay trục sang các hệ thống khác hoặc nâng cao đặc quyền của họ. Có rất nhiều kịch bản hack, nhưng tất cả chúng đều có một điểm chung: sử dụng bất kỳ bí mật nào được tìm thấy để tối đa hóa tác động của một cuộc tấn công.
Các nhóm bảo mật ứng dụng nhận thức rõ vấn đề. Thật không may, khối lượng công việc liên quan đến việc điều tra, thu hồi và luân chuyển bí mật mỗi tuần chỉ đơn giản là quá sức, chứ đừng nói đến việc đào bới nhiều năm mã chưa được khám phá.
Các nhóm an ninh mạng đang xem xét các bí mật được mã hóa cứng trong mã nguồn và những rủi ro mà chúng mang lại, rất nghiêm túc. Chúng được xếp hạng thứ 15 trong số các lỗ hổng "phổ biến và có tác động" nhất trong danh sách CWE Top 25 nổi tiếng năm 2022 (Liệt kê điểm yếu chung).
Một sự khác biệt chính, thường bị lãng quên rằng tách lỗ hổng này khỏi tất cả các lỗ hổng khác, như các ví dụ trước đã cho chúng ta thấy là các bí mật được tìm thấy trong mã nguồn có thể bị khai thác mà không cần phần mềm đang được sản xuất! Nói cách khác, chính mã mang một lỗ hổng, không phải logic cơ bản.
Do đó, chúng ta đã thấy bí mật đại diện cho một yếu tố quan trọng như thế nào trong việc đảm bảo chuỗi cung ứng. Bây giờ chúng ta hãy xem các tổ chức đang ứng phó với mối đe dọa mới này như thế nào trong chu kỳ phát triển.
Phản ứng của các tổ chức: đưa bảo mật vào chu kỳ phát triển
Sự xuất hiện của DevSecOps
Chuỗi cung ứng phần mềm có nhiều vùng xám không được giải quyết bằng các phương pháp bảo mật truyền thống. Các tổ chức đã nhận ra sự cần thiết phải đưa bảo mật vào vòng đời phát triển nhằm đạt được sự cân bằng phù hợp giữa năng suất và khả năng phục hồi.
Đây là cách phong trào DevSecOps ra đời. DevSecOps bao gồm việc chèn bảo mật vào các phương pháp thực hành DevOps. Xin nhắc lại, DevOps là một triết lý phát triển tập hợp các quy trình và công nghệ cho phép các nhà phát triển hợp tác hiệu quả hơn với các nhóm vận hành. Chúng ta thường nói về quy trình DevOps (xương sống của chuỗi cung ứng phần mềm) được đặc trưng bởi tính liên tục của nó: đó là về việc có thể tích hợp, kiểm tra, xác thực và cung cấp mã trong giai đoạn tiền sản xuất, một cách liên tục.
Các phương pháp tiếp cận bảo mật truyền thống mâu thuẫn với triết lý DevOps: cung cấp ngày càng nhanh hơn và thích ứng khi bạn tiếp tục. Đã có xích mích đáng kể giữa các nhóm bảo mật ứng dụng và nhóm nhà phát triển, với các nền văn hóa, chuyên môn và phương pháp rất khác nhau. Sự chia rẽ này, một nguồn gốc của nhiều hiểu lầm, cuối cùng đã góp phần vào sự mong manh của chu kỳ phát triển.
Đối với các nhà quản lý bảo mật, thách thức là duy trì tốc độ của DevOps đồng thời củng cố vị thế bảo mật được cải thiện: bao gồm các quy tắc bảo mật từ giai đoạn đầu của chu kỳ phát triển (lập kế hoạch, thiết kế), phổ biến các phương pháp hay nhất và giảm thời gian khắc phục trung bình (MTTR) bằng cách nắm bắt các lỗ hổng "lành tính" hơn trước đó.
Hơn cả một phương pháp, trên hết nó là một lý tưởng mà các công ty muốn phấn đấu. Con đường không dài: sự khác biệt về văn hóa rất ngoan cường và thường mất nhiều năm để biến mất. Một số con đường đã được đưa ra để thúc đẩy quá trình chuyển đổi này.
Con đường đầu tiên là dựa vào các công cụ hiện đại. Các nhà phát triển áp dụng các công cụ trực quan tích hợp hoàn hảo với môi trường làm việc của họ: dòng lệnh, API, IDE (Môi trường phát triển tích hợp) hoặc thậm chí hệ thống kiểm soát phiên bản (VCS) của họ. Cho đến gần đây, các công cụ phân tích bảo mật điển hình đã bị loại bỏ khỏi thế giới này, với biệt ngữ rất cụ thể và thường không thể xuyên thủng. Các nhà cung cấp phần mềm bảo mật đã có những bước tiến lớn trong lĩnh vực này, mang đến cho các nhà phát triển cơ hội làm quen với các khái niệm bảo mật và trở nên tự cung tự cấp trên một khu vực rộng lớn.
Tự động hóa cũng là chìa khóa cho phép tạo ra các hệ thống bảo mật hiệu quả. Các kỹ sư phần mềm là chuyên gia về tự động hóa, vì vậy thực sự không có ý nghĩa gì khi họ không thể thực hiện hoặc thậm chí hiểu các quy tắc bảo mật áp đặt cho họ để bảo vệ chuỗi cung ứng. Họ cũng là những người hiểu biết nhất về các hệ thống cần được bảo vệ. Kết hợp kiến thức của họ với chuyên môn của các kỹ sư bảo mật cho phép sử dụng tốt nhất các tài nguyên có sẵn và các nhóm hạnh phúc hơn về tổng thể.
Có lẽ yếu tố quan trọng nhất của DevDecOps là ý tưởng rằng bảo mật phải là một phần của tất cả các giai đoạn của chu kỳ phát triển. Tính bảo mật của nó không thể chỉ tồn tại như một danh sách kiểm tra đơn giản được đánh dấu ngay trước khi ra mắt phiên bản mới.
Để đạt được kết quả này, điều cần thiết là phải giải quyết một khái niệm quan trọng: chia sẻ trách nhiệm.
Chia sẻ trách nhiệm và ca trái
Mô hình bảo mật mới có nghĩa là chia sẻ trách nhiệm giữa tất cả các thành viên tham gia vào dự án. Chia sẻ trong các nhóm liên chức năng, thay vì trong các silo, điều này đã xảy ra trong lịch sử (một nhóm độc lập duy nhất phụ trách bảo mật, kiểm toán và đảm bảo chất lượng).
Thuật ngữ "dịch chuyển sang trái" thường được sử dụng để minh họa mong muốn di chuyển an ninh ra khỏi silo của nó để di chuyển các hoạt động bảo mật sớm hơn và tiết kiệm tiền cho việc phát hiện và khắc phục. Tuy nhiên, thuật ngữ này, được phổ biến vào đầu những năm 2000, mô tả một kết quả hoạt động mong muốn hơn là một cách thực sự để đạt được nó. Đối với một tổ chức muốn bắt tay vào chuyển đổi DevSecOps, tốt hơn là tập trung vào cách tạo ra sự thay đổi này để bảo mật hiệu quả chuỗi cung ứng phần mềm của mình.
Việc trao quyền cho các nhà phát triển là một động lực thiết yếu cho việc này. Là những nghệ nhân đầu tiên của thế giới kỹ thuật số, họ phải tham gia vào các quyết định bảo mật để tính đến nhu cầu và phương pháp làm việc của họ. Một hướng dẫn đơn giản nhưng mạnh mẽ là luôn làm cho con đường ngắn nhất cũng là an toàn nhất.
Do đó, một công cụ để ngăn chặn các lỗi phổ biến nhất (chẳng hạn như quên bí mật trong mã nguồn) phải dễ sử dụng và không tạo ra xích mích với cách các nhóm phát triển mã. Một công cụ tốt phải chứng minh tính hữu dụng và giá trị của nó mà không cảm thấy như nó sẽ dẫn đến 'khóa nhà cung cấp'. Nó cũng có thể giao tiếp với các nhóm bảo mật, những nhóm này sẽ không biến mất! Ngược lại, các nhóm bảo mật, có xu hướng nhỏ hơn các nhóm phát triển tương ứng của họ phải được huy động nhanh chóng cho các trường hợp phức tạp nhất.
Trước đây, bảo mật ứng dụng được coi là một lĩnh vực phải không thể xuyên thủng để đảm bảo tính hiệu quả của nó, nhưng những ngày đó đã không còn nữa. Ngày nay, mong muốn kiểm tra bảo mật được thực hiện trong suốt chu kỳ và kết quả cho phép khắc phục mà không nhất thiết phải leo thang cho các nhóm bảo mật.
Thúc đẩy quyền sở hữu bảo mật ở mỗi giai đoạn của chu kỳ đòi hỏi nỗ lực minh bạch chung giữa tất cả các nhóm. Đây là điều kiện bắt buộc để tạo ra một môi trường tin cậy và nuôi dưỡng một nền văn hóa từ chối sử dụng đổ lỗi như một công cụ trách nhiệm.
Trên thực tế, ngay cả các chức năng ở xa miền kỹ thuật cũng phải là một phần của sự chuyển đổi này. Ví dụ, các nhà quản lý sản phẩm cũng phải tính đến sự an toàn của các sản phẩm mà họ thiết kế trong quá trình ra quyết định của họ.
Do đó, phản ứng của các công ty để đối mặt với những rủi ro mới của chuỗi cung ứng phần mềm sẽ mang tính kỹ thuật cũng như tính tổ chức. Sự hợp tác giữa các ngành nghề khác nhau làm việc dọc theo chuỗi cung ứng hiện là ưu tiên hàng đầu của bảo mật hệ thống thông tin.