Lợi nhuận:
- Khả năng xác minh đầu ra AI ở ba lớp: độ chính xác, bảo mật và nguồn/giấy phép
- Khả năng che đậy các rủi ro như tiêm thuốc, gói ảo giác và chôn giấu bí mật bằng khuôn và dụng cụ an toàn
- Khả năng trình bày mã quan trọng về bảo mật để được sự chấp thuận của kỹ sư có thẩm quyền và hiểu được tính không thể chuyển giao trách nhiệm
Tạo mã AI thật dễ dàng; Tin tưởng anh ấy là tốn kém. Mục đích duy nhất của học phần này là chuyển đổi nguyên tắc "xác minh" mà chúng tôi đã lặp lại trong tất cả các học phần trước thành một nguyên tắc kỹ thuật có hệ thống. Bởi vì mã do AI tạo ra, ngay cả khi thoạt nhìn nó có vẻ đúng, nhưng lại ẩn chứa ba mối nguy hiểm riêng biệt: không hoạt động/không chính xác (ảo giác), không an toàn (dễ bị tổn thương) và tiềm ẩn rủi ro pháp lý/cấp phép. Biết ba điều này và thiết lập cánh cửa cho mỗi điều đó sẽ giúp bạn trở thành một người chuyên nghiệp.
Ở đây, chúng tôi xem xét “xác thực” ở ba lớp: tính chính xác (mã có thực sự hoạt động được không?), bảo mật (mã có chịu được đầu vào độc hại không?) và xuất xứ/giấy phép (tôi có quyền sử dụng mã này không?). Mỗi lớp có phương tiện kiểm soát riêng và không lớp nào có thể vượt qua được bằng "đó là những gì AI đã nói".
Ba lớp rủi ro
1. Rủi ro về tính chính xác (ảo giác). Mô hình có thể gọi một hàm không tồn tại, sử dụng sai API, âm thầm bỏ qua trường hợp đặc biệt. Mã có vẻ "hợp lý" nhưng lại sai. Thuốc giải độc: biên soạn, thử nghiệm, phân tích tĩnh và kiểm tra trực quan.
2. Rủi ro bảo mật. AI có thể lặp lại các mẫu không an toàn trong dữ liệu đào tạo: truy vấn dễ bị tấn công bởi SQL SQL, đầu vào của người dùng không được xác thực, mã hóa yếu, khử tuần tự hóa không an toàn, chuyển hướng mở. Mã hoạt động nhưng dễ bị tấn công. Thuốc giải độc: đánh giá tập trung vào bảo mật, máy quét tự động (SAST) và áp đặt các mẫu bảo mật đã biết.
3. Rủi ro về nguồn/giấy phép. AI có thể tạo ra đầu ra gần giống với mã được cấp phép có bản quyền hoặc hạn chế hoặc có thể gợi ý sự phụ thuộc được cấp phép không phù hợp. Thuốc giải độc: kiểm tra sự phụ thuộc và giấy phép, kiểm tra tính nguyên bản, chính sách công ty.
Thận trọng: Rủi ro nguy hiểm nhất trong ba rủi ro này là vấn đề bảo mật; bởi vì mã có thể vượt qua quá trình kiểm tra, chạy trơn tru trong quá trình sản xuất và lỗ hổng chỉ lộ ra khi kẻ tấn công tìm thấy nó. “Đang làm việc” không giống như “an toàn”.
Từng bước: Cổng xác thực theo lớp
- Đọc có hiểu biết. Thực sự hiểu mã trước khi chấp nhận nó; Không hợp nhất mã bạn không hiểu. Nếu bạn không thể giải thích "tại sao nó hoạt động" thì nó chưa được xác thực.
- Xác minh nó tồn tại. Xác nhận rằng mọi chức năng, API và gói được sử dụng thực sự tồn tại và được sử dụng đúng cách (cổng ảo giác).
- Chạy các công cụ tự động. Trình biên dịch, trình nói dối (trình quét kiểu/lỗi), trình kiểm tra kiểu, kiểm tra đơn vị và nếu có thể, SAST (Kiểm tra bảo mật ứng dụng tĩnh - công cụ quét mã nguồn để tìm lỗ hổng).
- Hãy nhìn nó từ góc độ bảo mật. Đầu vào có được xác thực không? Truy vấn có được tham số hóa không? Bí mật có bị chôn vùi? Có kiểm soát ủy quyền không?
- Kiểm tra nguồn và giấy phép. Các phần phụ thuộc mới có được cấp phép không? Kết quả đầu ra có quá giống với một cơ sở mã đã biết không?
- Nếu nó quan trọng về mặt bảo mật, hãy yêu cầu sự chấp thuận của chuyên gia. Việc đánh giá độc lập bởi một kỹ sư có năng lực trong các lĩnh vực như xác thực, thanh toán, mật mã, kiểm soát truy cập là bắt buộc.
Ba hộp nhỏ
Trường hợp 1 - Việc tiêm SQL bị bắt tại cổng kiểm tra. Mã do AI tạo sẽ nối trực tiếp dữ liệu nhập của người dùng vào truy vấn SQL cho điểm cuối tìm kiếm ("... WHERE name = '" + q + "'"). Mã đã hoạt động và đã vượt qua bài kiểm tra. Kiểm tra tập trung vào bảo mật và quét SAST đã phát hiện ra điều này; Nó đã được chuyển đổi thành một truy vấn được tham số hóa (câu lệnh đã chuẩn bị sẵn). Nếu nó không bị phát hiện thì đó sẽ là một lỗ hổng rò rỉ dữ liệu cổ điển.
Trường hợp 2 - Gói ảo giác. AI đã đề xuất gói npm không tồn tại (phân tích cú pháp an toàn nhanh) cho một tác vụ. Khi nhà phát triển cố gắng cài đặt nó, gói này không được tìm thấy. Tệ hơn nữa: trong một số trường hợp, kẻ tấn công có thể điền tên gói "ma" như vậy bằng các gói thực, độc hại (nhầm lẫn phụ thuộc). Bài học: xác minh từng gói được đề xuất dựa trên sổ đăng ký chính thức và lịch sử tải xuống/bảo trì.
Trường hợp 3 - Giấy phép không tương thích. Một thư viện đồng hành tiện lợi do AI đề xuất có giấy phép copyleft mạnh nhưng không tương thích với giấy phép sản phẩm của tổ chức. Quét giấy phép phụ thuộc đã báo cáo điều này; Nhóm đã thay thế giấy phép bằng một giấy phép thay thế phù hợp. Nếu không xác minh, gánh nặng pháp lý sẽ phát sinh trong quá trình phân phối sản phẩm.
Bốn mẫu có thể sao chép
Tự kiểm tra trước khi nhập học:
Trước khi chấp nhận mã do AI tạo sau đây, hãy kiểm tra:1) Mọi chức năng/API/gói mà nó sử dụng có thực sự tồn tại không? Gắn cờ các nghi phạm.2) Có bất kỳ thông tin đầu vào nào không được xác thực, nối SQL/lệnh, bí mật bị chôn giấu, mật mã yếu không?3) Các lỗi/trường hợp ranh giới chưa được giải quyết là gì? Gắn nhãn mỗi phát hiện là "chắc chắn/có thể xảy ra" và đề xuất cách khắc phục.{{code}}
Đánh giá tập trung vào bảo mật:
Kiểm tra mã này bằng con mắt bảo mật. Tìm kiếm các lỗ hổng kiểu OWASP phổ biến: chèn, xác thực/ủy quyền bị hỏng, tiết lộ dữ liệu nhạy cảm, khử lưu lượng không an toàn, chuyển hướng không được xác thực. Đối với mỗi phát hiện: rủi ro, kịch bản khai thác, biện pháp khắc phục. Đây là buổi sàng lọc sơ bộ; chuyển những phát hiện quan trọng đến đánh giá an ninh con người.{{code}}
Kiểm tra sự phụ thuộc và giấy phép:
Liệt kê các phụ thuộc được thêm/đề xuất bởi mã này. Đối với từng câu hỏi: gói có thực sự tồn tại không, nó có được duy trì không, giấy phép thông thường của nó là gì (PHẢI ĐƯỢC XÁC MINH) và nó có thực sự cần thiết cho dự án hay nó có thể được thực hiện bằng một công cụ hiện có?{{code hoặc danh sách phụ thuộc}}
Thi công cốp pha an toàn (trong sản xuất):
Viết mã cho {{task}}. Các quy tắc bảo mật BẮT BUỘC:- Xác thực/khử trùng tất cả đầu vào bên ngoài.- Chỉ sử dụng truy vấn được tham số hóa khi truy cập cơ sở dữ liệu.- Không nhúng bí mật vào mã; giả sử biến môi trường/người quản lý bí mật - Đừng nuốt lỗi; Hãy xem xét nó một cách có ý nghĩa. Giải thích cách mã tuân thủ các quy tắc này trong 3 mục.
Dấu nhắc yếu / Dấu nhắc mạnh
Yếu: "Viết truy vấn tìm kiếm theo tên người dùng." (Có thể xảy ra mã dễ bị tiêm nhiễm.)
Mạnh: "Viết hàm tìm kiếm theo tên người dùng. Không bao giờ kết hợp dữ liệu đầu vào của người dùng vào một truy vấn dưới dạng chuỗi; sử dụng truy vấn được tham số hóa (câu lệnh đã chuẩn bị sẵn). Xác thực độ dài và ký tự đầu vào. Giải thích bằng 2 câu tại sao mã bị đóng để chèn."
Phiên bản mạnh áp đặt mô hình bảo mật ngay từ đầu; Vì vậy, nó đảm bảo rằng lỗ hổng hoàn toàn không xảy ra, thay vì phát hiện ra sau này. Tuy nhiên, điều cần thiết là phải chuyển mã được tạo qua các cổng xác minh.
Lớp xác thực
Công cụ/phương pháp
"AI nói" đã đủ chưa?
độ chính xác
Biên soạn, kiểm tra, kiểm tra trực quan
không
Thực tế API/gói
Kiểm soát tài liệu/hồ sơ chính thức
không
Bảo mật
SAST, đánh giá bảo mật
không
Giấy phép/nguồn
Kiểm tra phụ thuộc và giấy phép
không
Logic quan trọng về bảo mật
Phê duyệt kỹ sư chuyên gia
Tuyệt đối không
Trách nhiệm không thể được chuyển giao
Trách nhiệm đối với các lỗi, lỗ hổng hoặc vi phạm phát sinh từ mã do công cụ AI tạo ra thuộc về nhóm lắp ráp và phân phối mã đó chứ không thuộc về nhà cung cấp công cụ. Đây là một thực tế chuyên môn cũng như pháp lý: bạn ký. Vì vậy, "AI đã tạo ra nó" không phải là một cái cớ mà là một lời biện minh cho sự thận trọng hơn nữa. Đặc biệt trong các hệ thống quan trọng về an toàn, kết quả đầu ra AI không thể thay thế cho việc xem xét và phê duyệt của kỹ sư có trình độ trong mọi trường hợp; Nhiều nhất, AI cung cấp một bản thiết kế để tăng tốc kỹ sư đó.
Mẹo: Tạo một danh sách kiểm tra ngắn trong nhóm của bạn mà bạn gọi là “cổng xác thực cho mã do AI tạo” (xây dựng + kiểm tra + quét bảo mật + kiểm tra trực quan). Một khi cánh cổng này trở thành thói quen thì việc mất tốc độ là tối thiểu và giảm thiểu rủi ro là tối đa.
Những lỗi thường gặp
- Nhầm lẫn giữa "hoạt động" với "an toàn". Mã vượt qua thử nghiệm có thể dễ bị tấn công.
- Sử dụng gói/API mà không xác minh nó. Các gói ảo giác vừa bị hỏng vừa gây rủi ro bảo mật.
- Bỏ qua các công cụ tự động. Linter, type checker và SAST có thể bắt được những gì con người bỏ sót với giá rẻ.
- Bỏ qua giấy phép. Sự phụ thuộc được cấp phép không phù hợp tạo ra gánh nặng pháp lý cho việc phân phối.
- Đổ trách nhiệm lên xe. Nhóm chịu trách nhiệm về mã trong sản xuất; “AI đã làm được điều đó” không phải là lời bào chữa.
Tóm lại
Việc chấp nhận đầu ra AI yêu cầu ba lớp xác minh: tính chính xác (biên dịch, kiểm tra, kiểm tra trực quan), bảo mật (SAST và đánh giá tập trung vào bảo mật) và nguồn/giấy phép (kiểm tra phụ thuộc). Xác nhận rằng mỗi gói và API được sử dụng thực sự tồn tại, thực thi các mẫu bảo mật ngay từ đầu và gửi mã quan trọng về bảo mật để kỹ sư có trình độ phê duyệt. “Hoạt động” không có nghĩa là an toàn và “do AI sản xuất” không loại bỏ trách nhiệm pháp lý. Cổng xác minh là cái giá của sự chuyên nghiệp chứ không phải tốc độ.
Nhiệm vụ ứng dụng
Cố tình giao cho AI một nhiệm vụ nhạy cảm về bảo mật (ví dụ: “chức năng tìm kiếm cơ sở dữ liệu bằng thông tin đầu vào của người dùng”), lần này mà không áp đặt mẫu an toàn. Chuyển mã đến thông qua các mẫu "tự kiểm tra trước khi tiếp nhận" và "đánh giá tập trung vào bảo mật": có bất kỳ hành vi tiêm nhiễm, bí mật bị chôn giấu, gói ảo giác hoặc đầu vào không được xác thực nào không? Sau đó hỏi lại nhiệm vụ tương tự với mẫu “áp đặt mẫu an toàn” và so sánh hai kết quả đầu ra. Nếu có thể, hãy chạy công cụ nói dối/SAST và so sánh kết quả tìm được với khả năng tự điều chỉnh của AI.
danh sách kiểm tra
- [ ] Tôi xác minh đầu ra AI ở ba lớp: độ chính xác, bảo mật và giấy phép.
- [ ] Tôi xác nhận rằng mọi chức năng, API và gói được sử dụng đều thực sự tồn tại.
- [ ] Tôi chạy các công cụ biên dịch, kiểm tra, nói dối và nếu có thể, các công cụ SAST.
- [ ] Tôi áp đặt các mẫu bảo mật (truy vấn được tham số hóa, xác thực đầu vào, quản lý bí mật) ngay từ đầu.
- [ ] Tôi kiểm tra việc cấp phép và yêu cầu của các phụ thuộc mới.
- [ ] Tôi đang gửi mã quan trọng về bảo mật để kỹ sư có thẩm quyền phê duyệt và tôi hiểu rằng tôi phải chịu trách nhiệm.