Ngày càng nhiều tổ chức sử dụng các thực tiễn lập trình nhanh chóng và vòng đời phát triển an toàn, nhưng hầu hết đều thất bại trong việc cung cấp cho các nhà phát triển các công cụ và quy trình họ cần để tạo ra mã an toàn.
Một khảo sát mới nhất được công bố bởi nhà cung cấp dịch vụ DevOps GitLat cho thấy 70% lập trình viên được mong đợi có thể viết mã an toàn, nhưng chỉ 25% nghĩ rằng thực tiễn bảo mật của tổ chức của họ là “tốt”. Khoảng cách giữa việc mong đợi đến việc các nhà phát triển có thể làm được và thực tế môi trường làm việc của họ nhấn mạnh các khó khăn mà công ty gặp phải trong việc bảo mật phần mềm của họ, Kathy Wang, giám đốc bảo mật cấp cao của GitLab nói.
“Tôi thực sự nghĩ rằng về mặt an ninh của ngành công nghiệp phần mềm – tình trạng của nó hiện nay – chúng ta vẫn ở trong trạng thái phản ứng”, cô nói. “Có rất nhiều công ty ngoài kia đang chuyển sang tư duy DevOps, nhưng tôi nghĩ hầu hết họ chưa chuyển đổi được”.
Khảo sát của GitLab phỏng vấn hơn 4,000 nhà phát triển phần mềm, quản lý và các công ty sản suất phần mềm với khoảng 60% những người này là khách hàng của GitLab, để nghiên cứu các xu hướng đang ảnh hưởng tới các nhà phát triển. Khảo sát chỉ ra phần nhiều các công ty tập trung vào mô hình phát triển phần mềm nhanh nhạy, trong đó 50% sử dụng Scrum trong các nhóm phát triển, 37% sử dụng Kanban, và 36% sử dụng DevOps. 17% tiếp tục sử dụng thực tiễn phát triển phương pháp thác nước.
Trong số các vấn đề chính được họ trích dẫn là bảo mật và làm thế nào để sản xuất mã bảo mật tại các công ty. Khảo sát cũng chỉ ra dù phương pháp nhanh nhạy phá vỡ các rào cản giữa các nhóm – với sự thúc đẩy của DevOps cho đường ống phát triển và điều hành duy nhất – các công ty vẫn gặp khó khăn trong thực tế.
“Ý tưởng mọi người chịu trách nhiệm về bảo mật có thể rất tuyệt vời nhưng nó cũng là một phần của vấn đề khi mọi người dễ dàng chuyển thành “không ai cả”, khảo sát nói rõ. “Các chuyên gia bảo mật thường phàn nàn về việc ở bên ngoài, trong khi các nhà phát triển và đội ngũ điều hành không hài lòng khi được nói về cách ưu tiên công việc của họ”.
Kiểm tra 1-2-3
Trong khi 45% các công ty có một vài mô hình phát triển mã liên tiếp trong tổ chức (một phạm vi của phát triển nhanh nhạy), một nửa các nhà phát triển tin rằng hầu hết các lỗ hổng tiếp tục được tìm thấy chỉ sau khi mã hợp nhất được đưa vào môi trường thí nghiệm. Họ nói rằng họ gặp phải sự chậm trễ nhất trong suốt giai đoạn thí nghiệm phát triển.
Không hiểu rõ nhược điểm của phần mềm trong suốt quá trình phát triển làm tăng chi phí sửa chữa lên rất nhiều, Wang nói.
Chúng tôi có các nhóm bảo mật ứng dụng và quét mã nhưng không phải công ty nào cũng sử dụng các công cụ này, cô nói. “Nếu bạn không sử dụng nó, bạn đang dựa vào đánh giá mã thủ công và mọi thứ sẽ bị bỏ qua, nghĩa là bạn đang tìm những thứ sau thực tế, sau khi mã được cam kết và những thứ đó tốn kém hơn nhiều.
Khảo sát cũng tìm thấy những lợi ích bảo mật đáng kể với việc thực hiện DevOps trưởng thành: đội ngũ bảo mật có khả năng tìm thấy lỗ hổng cao gấp 3 lần trước khi mã được hợp nhất. Khoảng 1/3 các đội đã tự động sử dụng quét tĩnh mỗi lần mã được cam kết và hơn ¼ có tính năng bảo mật nội tuyến kiểm tra mã khi nó được viết.
Quét các phụ thuộc lỗi thời là cách kiểm tra an toàn phổ biến nhất, với 56% công ty được khảo sát sử dụng tính năng này. Chỉ 35% các công ty sử dụng thử nghiệm an toàn phân tích tĩnh (SAST) và 22% sử dụng thử nghiệm an toàn phân tích động (DAST).
Nói chung, phạm vi thử nghiệm đã mở rộng tới hơn 90% mã trong 14% nhóm DevOps trưởng thành nhất.
“Bạn muốn chắc chắn rằng các nhà phát triển được đào tạo càng nhiều càng tốt về các quá trình mã hóa bảo mật”, Wang nói. “Bạn muốn các công cụ và với DevOps, bạn có các thành phần nâng cao để thực hiện”.
Các số liệu bảo mật mà người trả lời coi là quan trọng nhất chính là mức độ nghiêm trọng của lỗ hổng, thời gian kể từ khi lỗ hổng được phát hiện, thời gian giải quyết và số lượng lỗ hổng được báo cáo.
Một điều thú vị đặc biệt: các nhà phát triển chủ yếu làm việc ở các địa điểm xa thường đánh giá sự trưởng thành của họ trong thực tiễn bảo mật của tổ chức cao hơn các nhà phát triển làm việc tại văn phòng. Wang không có giải thích nào cho khoảng cách trong thực tiễn bảo mật.
