Cybersecurity News

Đến nay, rõ ràng là “thần đèn” trí tuệ nhân tạo (AI) đã thoát ra khỏi chai – và sẽ không quay lại. Điều này mở rộng đến lĩnh vực phát triển phần mềm, như một cuộc khảo sát của GitHub cho thấy 92% các nhà phát triển ở Hoa Kỳ đã đang sử dụng các công cụ lập trình AI cả trong và ngoài công việc. Họ nói rằng công nghệ AI giúp họ cải thiện kỹ năng (được 57% đề cập), tăng năng suất (53%), tập trung vào xây dựng/sáng tạo thay vì các công việc lặp đi lặp lại (51%) và tránh kiệt sức (41%).

Có thể nói chắc chắn rằng phát triển có hỗ trợ AI sẽ trở thành chuẩn mực trong tương lai gần. Các tổ chức sẽ phải thiết lập các chính sách và thực hành tốt nhất để quản lý hiệu quả tất cả điều này, giống như họ đã làm với việc triển khai đám mây, Bring Your Own Device (BYOD) và các xu hướng công nghệ khác trong môi trường làm việc. Tuy nhiên, sự giám sát như vậy vẫn đang trong quá trình phát triển. Ví dụ, nhiều nhà phát triển tham gia vào cái gọi là “AI ngầm” bằng cách sử dụng các công cụ này mà không có sự biết đến hoặc phê duyệt của bộ phận IT hoặc ban quản lý trong tổ chức của họ.

Những nhà quản lý này bao gồm các giám đốc an ninh thông tin (CISO), những người chịu trách nhiệm xác định các rào cản, để các nhà phát triển hiểu được công cụ và thực hành AI nào được chấp nhận, và cái nào không. Các CISO cần dẫn dắt quá trình chuyển đổi từ sự không chắc chắn của AI ngầm sang một môi trường Bring Your Own AI (BYOAI) được kiểm soát và quản lý tốt hơn.

Đây là thời điểm để chuyển đổi, khi nghiên cứu gần đây từ học thuật và ngành công nghiệp tiết lộ một tình trạng bấp bênh: 44% tổ chức lo ngại về các rủi ro liên quan đến mã được tạo bởi AI, theo Báo cáo Tình trạng Bảo mật Đám mây Bản địa 2024 (PDF). Nghiên cứu từ Snyk cho thấy 56% thành viên của đội ngũ phần mềm và bảo mật nói rằng các đề xuất AI không an toàn là phổ biến. Bốn trong năm nhà phát triển bỏ qua các chính sách bảo mật để sử dụng AI (tức là AI ngầm), nhưng chỉ có một trong mười người quét hầu hết mã của họ, thường vì quá trình này thêm nhiều chu kỳ cho việc xem xét mã và do đó làm chậm quy trình làm việc tổng thể.

Trong một nghiên cứu của Đại học Stanford, các nhà nghiên cứu phát hiện ra rằng chỉ có 3% nhà phát triển sử dụng trợ lý AI viết ra sản phẩm an toàn, so với 21% những người không sử dụng AI. 36% những người có quyền truy cập AI tạo ra các sản phẩm dễ bị tấn công SQL injection, so với 7% những người không có quyền truy cập.

Việc áp dụng một chiến lược BYOAI được thiết kế và thực hiện tốt sẽ giúp các CISO vượt qua những thách thức khi các nhà phát triển tận dụng các công cụ này để tạo ra mã với tốc độ nhanh chóng. Với sự hợp tác chặt chẽ giữa các đội ngũ bảo mật và lập trình, các CISO sẽ không còn đứng ngoài môi trường lập trình mà không biết ai đang sử dụng gì. Họ sẽ nuôi dưỡng một văn hóa trong đó các nhà phát triển nhận ra rằng họ không thể tin tưởng mù quáng vào AI, vì làm như vậy sẽ dẫn đến vô số vấn đề về sau. Nhiều đội ngũ đã quen thuộc với việc phải “làm ngược lại” để sửa chữa lập trình và bảo mật kém không được giải quyết từ đầu, vì vậy có lẽ nhận thức về bảo mật AI cũng sẽ làm nổi bật điều này rõ ràng hơn cho các nhà phát triển trong tương lai.

Vậy làm thế nào các CISO đạt được trạng thái này? Bằng cách kết hợp các thực hành và quan điểm sau:

Thiết lập khả năng hiển thị. Cách chắc chắn nhất để loại bỏ AI ngầm là đưa AI ra khỏi bóng tối, phải không? Các CISO cần có được “cái nhìn tổng quan” về các công cụ mà các đội ngũ phát triển đang sử dụng, những công cụ họ không sử dụng, và lý do tại sao. Với điều này, họ sẽ có một cảm nhận chắc chắn về nguồn gốc của mã và liệu có bất kỳ sự tham gia nào của AI đang gây ra rủi ro an ninh mạng hay không.

Cân bằng giữa bảo mật và năng suất. Các CISO không thể ngăn cản các đội ngũ tìm kiếm công cụ riêng của họ – và cũng không nên làm vậy. Thay vào đó, họ phải tìm kiếm sự cân bằng tinh tế giữa năng suất và bảo mật. Họ cần sẵn sàng cho phép các hoạt động liên quan đến AI trong một số giới hạn nhất định, nếu nó dẫn đến việc đạt được mục tiêu sản xuất với rủi ro tối thiểu hoặc ít nhất là chấp nhận được.

Nói cách khác, thay vì áp dụng tư duy “Bộ phận Nói Không”, các CISO nên tiếp cận việc tạo ra hướng dẫn và quy trình được chấp thuận cho các đội ngũ phát triển của họ với tư duy: “Chúng tôi đánh giá cao việc bạn đang khám phá các giải pháp AI mới sẽ cho phép bạn tạo ra phần mềm hiệu quả hơn. Chúng tôi chỉ muốn đảm bảo rằng các giải pháp của bạn sẽ không gây ra các vấn đề bảo mật cuối cùng cản trở năng suất. Vì vậy, hãy cùng nhau làm việc về điều này.”

Đo lường nó. Một lần nữa, trong tinh thần hợp tác, các CISO nên làm việc với các đội ngũ lập trình để đưa ra các chỉ số hiệu suất chính (KPI) đo lường cả năng suất và độ tin cậy/an toàn của phần mềm. Các KPI nên trả lời các câu hỏi, “Chúng ta đang sản xuất bao nhiêu với AI? Chúng ta đang làm điều đó nhanh như thế nào? Bảo mật của quy trình của chúng ta đang trở nên tốt hơn hay tệ hơn?”

Hãy nhớ rằng đây không phải là các KPI “bảo mật”. Chúng là các KPI “tổ chức” và phải phù hợp với chiến lược và mục tiêu của công ty. Trong trường hợp tốt nhất có thể, các nhà phát triển sẽ nhận thức các KPI như một thứ giúp họ hiểu biết hơn, thay vì một gánh nặng. Họ sẽ nhận ra rằng KPI giúp họ đạt được mức độ “nhiều hơn/nhanh hơn/tốt hơn”, trong khi vẫn kiểm soát được yếu tố rủi ro.

Các đội ngũ phát triển có thể sẵn sàng hợp tác “bảo mật trước” hơn các CISO dự đoán. Thực tế, các thành viên của đội ngũ này xếp việc xem xét bảo mật lên hàng đầu trong danh sách ưu tiên của họ khi triển khai các công cụ lập trình AI, cùng với việc xem xét mã. Họ cũng tin rằng sự hợp tác dẫn đến việc viết mã sạch hơn và được bảo vệ tốt hơn.

Đó là lý do tại sao các CISO nên nhanh chóng tiến hành với một kế hoạch khả năng hiển thị AI và KPI hỗ trợ sự cân bằng “vừa đủ” để đạt được kết quả tối ưu về bảo mật và năng suất. Rốt cuộc, thần đèn sẽ không quay trở lại chai—không bao giờ. Vì vậy, điều quan trọng là phải đảm bảo rằng thần đèn có thể mang lại công việc tốt nhất của chúng ta mà không gây ra những rủi ro không cần thiết.

(Nguồn: https://www.securityweek.com/how-to-improve-the-security-of-ai-assisted-software-development/)