Các nhà phát triển thực sự dành bao nhiêu thời gian để viết mã?
Theo các nghiên cứu gần đây, các nhà phát triển dành nhiều thời gian để duy trì, thử nghiệm và bảo mật mã hiện có hơn là viết hoặc cải thiện mã. Các lỗ hổng bảo mật có thói quen xấu là xuất hiện trong quá trình phát triển phần mềm, chỉ xuất hiện sau khi một ứng dụng đã được triển khai. Phần đáng thất vọng là nhiều lỗi và lỗi bảo mật này có thể đã được giải quyết trong giai đoạn trước đó và có các phương pháp và công cụ thích hợp để phát hiện ra chúng.
Nhà phát triển dành bao nhiêu thời gian để học viết mã hoạt động? Và bao nhiêu được chi cho việc học về bảo mật mã? Hay học cách không viết mã? “
Sẽ tốt hơn nếu loại bỏ vấn đề khỏi hệ thống hơn là để nó ở đó, sau đó cố gắng phát hiện và ngăn chặn một cuộc tấn công đang diễn ra nhắm vào nó?
Bạn có thể kiểm tra kỹ năng mã hóa an toàn của mình bằng cách tự đánh giá ngắn này.
Cái giá thật sự của lỗi
Mọi người đều mắc lỗi, ngay cả những nhà phát triển. Lỗi phần mềm là không thể tránh khỏi và được chấp nhận như là “chi phí kinh doanh” trong lĩnh vực này.
Điều đó đang được nói, bất kỳ lỗi nào chưa được sửa chữa trong mã đều là mạch máu của những kẻ tấn công. Nếu họ có thể tìm thấy ít nhất một lỗi trong hệ thống có thể được khai thác theo đúng cách (tức là lỗ hổng phần mềm), họ có thể tận dụng lỗ hổng đó để gây ra thiệt hại lớn, có khả năng lên tới hàng chục triệu đô la – như chúng tôi xem qua các trường hợp được công khai nổi tiếng hàng năm.
Và ngay cả khi nói đến các lỗ hổng ít nghiêm trọng hơn, việc sửa chữa chúng có thể rất tốn kém – đặc biệt nếu một điểm yếu được giới thiệu sớm hơn nhiều trong SDLC do lỗi thiết kế hoặc thiếu yêu cầu bảo mật.
Tại sao cách tiếp cận hiện tại đối với bảo mật phần mềm lại bị hạn chế?
1 – Phụ thuộc quá nhiều vào công nghệ (và không đủ vào con người)
Tuy nhiên, các công cụ tự động hóa và an ninh mạng được cho là sẽ giảm bớt khối lượng công việc cho các nhà phát triển và nhân viên bảo mật ứng dụng bằng cách quét, phát hiện và giảm thiểu các lỗ hổng phần mềm:
Mặc dù những công cụ này đóng góp vào nỗ lực bảo mật không gian mạng, nhưng các nghiên cứu cho thấy rằng chúng chỉ có thể phát hiện ra 45% lỗ hổng tổng thể. cảm giác an toàn sai cực kỳ nguy hiểm 2 – Ngắt kết nối DevSec
Việc ngắt kết nối DevSec đề cập đến sự căng thẳng nổi tiếng giữa các nhóm phát triển và nhóm bảo mật do các ưu tiên khác nhau (và thường là xung đột) khi nói đến các tính năng mới và sửa lỗi.
Kết quả của sự xung đột này, 48% các nhà phát triển kết thúc thường xuyên đẩy mã dễ bị tổn thương vào sản xuất. Các lỗ hổng được phát hiện sau đó trong chu kỳ phát triển thường không được giảm thiểu, hoặc cuối cùng tạo ra chi phí bổ sung, sự chậm trễ và rủi ro hơn nữa. Đây là những hậu quả của suy nghĩ ngắn hạn: cuối cùng, sẽ tốt hơn nếu khắc phục sự cố tại nguồn thay vì dành thời gian và nguồn lực để tìm kiếm các lỗi mã sau đó trong vòng đời phát triển phần mềm.
3 – Giám sát chuỗi cung ứng của bạn nhưng không phải phần mềm của riêng bạn
Một sai lầm phổ biến khác là chỉ tập trung vào bảo mật chuỗi cung ứng phần mềm và chỉ giải quyết các lỗ hổng đã biết trong các gói và sản phẩm phần mềm hiện có được liệt kê trong cơ sở dữ liệu Các lỗ hổng phổ biến và Phơi nhiễm hoặc Cơ sở dữ liệu Quốc gia về Lỗ hổng bảo mật.
Xử lý bất kỳ lỗ hổng nào trong các thành phần của bên thứ ba, phụ thuộc của bạn hoặc môi trường hoạt động là điều cần thiết, nhưng điều này sẽ không giúp bạn giải quyết các lỗ hổng trong mã của riêng bạn.
Tương tự, theo dõi các cuộc tấn công tiềm ẩn thông qua hệ thống phát hiện xâm nhập (IDS) hoặc tường lửa, theo sau là phản ứng sự cố là một ý tưởng hay – và được OWASP Top 10 công nhận là cần thiết – nhưng những hoạt động này chỉ giải quyết hậu quả của các cuộc tấn công mạng hơn là nguyên nhân.
Giải pháp: làm cho mã hóa an toàn trở thành một môn thể thao đồng đội
An ninh mạng của bạn chỉ mạnh bằng liên kết yếu nhất của bạn. Phát triển phần mềm không phải là một công việc trong dây chuyền lắp ráp, và – bất chấp mọi dự đoán – nó sẽ không sớm được tự động hóa hoàn toàn. Các lập trình viên là những người giải quyết vấn đề sáng tạo, những người cần phải đưa ra hàng trăm quyết định mỗi ngày khi họ viết mã, bởi vì phát triển phần mềm là một loại hình thủ công.
Khi nói đến nó, một đoạn mã có an toàn hay không là tùy thuộc vào kỹ năng của từng nhà phát triển.
Các quy trình, tiêu chuẩn và công cụ có thể giúp thúc đẩy và củng cố các phương pháp hay nhất, nhưng nếu nhà phát triển không biết về một loại phương pháp xấu cụ thể, họ có thể sẽ tiếp tục phạm phải cùng một lỗi (và đưa ra cùng một loại lỗ hổng trong mã) lặp đi lặp lại.
6 mẹo để trao quyền cho mã hóa an toàn
Số lượng lỗ hổng bảo mật mới được phát hiện đang tăng lên và các mối đe dọa do các tác nhân mạng độc hại gây ra ngày càng tinh vi hơn. Hầu hết các tổ chức bắt đầu triển khai vòng đời phát triển an toàn sau một sự cố, nhưng nếu bạn hỏi chúng tôi khi nào bạn nên bắt đầu, tất nhiên câu trả lời sẽ luôn là càng sớm càng tốt.
Đó là bởi vì khi nói đến các lỗ hổng nghiêm trọng, thậm chí hàng giờ có thể có nghĩa là sự khác biệt giữa không có thiệt hại lâu dài và một thảm họa tài chính.
Dưới đây là các mẹo hàng đầu của chúng tôi để thực hiện chính xác điều đó:
1 – Dịch chuyển sang trái – mở rộng quan điểm bảo mật sang các giai đoạn phát triển ban đầu
Chỉ dựa vào tự động hóa công cụ bảo mật kiểu DevSecOps là chưa đủ, bạn cần phải thực hiện thay đổi văn hóa thực tế. SAST, DAST hoặc kiểm tra thâm nhập nằm ở bên phải trong SDLC; chuyển sang trái theo hướng bắt đầu của vòng đời phát triển phần mềm để có phạm vi bao phủ toàn diện hơn.
2 – Áp dụng phương pháp tiếp cận vòng đời phát triển an toàn
Ví dụ như MS SDL hoặc OWASP SAMM sẽ cung cấp một khuôn khổ cho các quy trình của bạn và hoạt động như một điểm khởi đầu tốt cho sáng kiến an ninh mạng của bạn.
3 – Bao phủ toàn bộ hệ sinh thái CNTT của bạn
Các lỗ hổng của bên thứ ba gây ra rủi ro rất lớn cho an ninh mạng của doanh nghiệp bạn, nhưng các nhà phát triển của chính bạn cũng có thể gây ra các vấn đề cho ứng dụng. Bạn cần có khả năng phát hiện và giải quyết các lỗ hổng bảo mật trên cơ sở, trên đám mây và trong môi trường của bên thứ ba.
4 – Chuyển từ phản ứng sang phòng ngừa
Thêm các khái niệm lập trình phòng thủ vào hướng dẫn mã hóa của bạn. Mạnh mẽ là những gì bạn cần. Rốt cuộc thì bảo mật tốt là do hoang tưởng.
5 – Tư duy quan trọng hơn công nghệ
Tường lửa và IDS sẽ không tự bảo vệ phần mềm của bạn khỏi tin tặc; họ chỉ giải quyết hậu quả của các lỗ hổng đã tồn tại. Giải quyết tận gốc vấn đề: tư duy của nhà phát triển và trách nhiệm giải trình cá nhân.
6 – Đầu tư vào đào tạo mã an toàn
Tìm kiếm một ngôn ngữ lập trình bao gồm nhiều loại ngôn ngữ lập trình và cung cấp phạm vi bao quát kỹ lưỡng về các tiêu chuẩn mã hóa an toàn, cơ sở dữ liệu về lỗ hổng bảo mật và các loại điểm yếu quan trọng của phần mềm nổi tiếng trong ngành. Các bài tập thực hành trong phòng thí nghiệm trong môi trường gốc của các nhà phát triển là một điểm cộng rất lớn để giúp họ bắt kịp tốc độ một cách nhanh chóng và thu hẹp khoảng cách kiến thức khó khăn đó.
Hành trình học tập kết hợp của Cydrill cung cấp đào tạo về mã hóa an toàn chủ động và hiệu quả cho các nhà phát triển từ các công ty trong danh sách Fortune 500 trên toàn thế giới. Bằng cách kết hợp đào tạo do người hướng dẫn hướng dẫn, học trực tuyến, phòng thí nghiệm thực hành và trò chơi, Cydrill cung cấp một cách tiếp cận mới và hiệu quả để học cách viết mã an toàn.
.
