AI-নির্মিত কোড কি আসলেই নিরাপদ? একজন বিল্ডারের প্রশ্নোত্তর

প্রায় প্রতিটা অনবোর্ডিং কলেই আমি এই প্রশ্নের কোনো না কোনো রূপ পাই, সাধারণত সাবধানে বলা হয়, যেন প্রশ্নকর্তা অর্ধেক আশা করেন যে তাকে উদ্বেগ থেকে সরিয়ে দেওয়া হবে। কিন্তু তাকে সরিয়ে দেওয়া উচিত না। সিকিউরিটি সেই কয়েকটি ক্ষেত্রের একটি যেখানে একটা স্বাস্থ্যকর পরিমাণ সন্দেহবাতিকতা সঠিকভাবে পরিমাপিত, তা কোড মানুষ লিখুক বা একটা মডেল। নিচে সেই প্রশ্নগুলো দেওয়া হলো যেগুলো আমি আসলেই পাই, যতটা সরাসরি সম্ভব উত্তর দেওয়া হলো।

মানুষের লেখা কোডের চেয়ে AI-এর লেখা কোড কি কম নিরাপদ?

গড়ে, আর যদি অযাচিত রাখা হয়, তাহলে হ্যাঁ — সামান্য। কয়েক বছর আগের একটা স্ট্যানফোর্ড স্টাডি (Perry et al., যা প্রায়ই এই বিষয়ে প্রথম প্রকৃত পর্যালোচনা হিসেবে উদ্ধৃত হয়) দেখেছিল যে AI কোডিং অ্যাসিস্ট্যান্ট ব্যবহারকারী ডেভেলপাররা একটা কন্ট্রোল গ্রুপের চেয়ে কম নিরাপদ কোড তৈরি করেছিলেন, এবং — এই অংশটাই আপনাকে বেশি চিন্তিত করা উচিত — নিজেদের কোডকে যতটা নিরাপদ ছিল তার চেয়ে বেশি নিরাপদ বলে মূল্যায়ন করেছিলেন। আত্মবিশ্বাস বেড়ে গিয়েছিল যখন গুণমান কমে গিয়েছিল। Veracode-এর সাম্প্রতিক GenAI কোড সিকিউরিটি স্ক্যানও এটার একটা মোটামুটি সংখ্যা দেয়: তারা যে AI-জেনারেটেড কোড নমুনা পরীক্ষা করেছিল তার প্রায় ১০ টির মধ্যে ৪ টি অন্তত একটা শোষণযোগ্য ত্রুটি প্রবেশ করিয়েছিল, সাধারণত কিছু সাদামাটা যেমন অনুপস্থিত ইনপুট চেক বা একটা দুর্বল ডিফল্ট। এর কোনোটাই বোঝায় না যে AI-লিখিত কোড স্বাভাবিকভাবেই ধ্বংসপ্রাপ্ত। এটা বোঝায় যে যাচাই না করা AI-লিখিত কোড যাচাই না করা মানুষের কোডের মতোই একই ঝুঁকি বহন করে, আর "যাচাই না করা" অংশটিই যেখানে আসল বিপদ বাস করে। একটা মডেল যেটা দ্রুত লেখে আর কখনো চেক হয় না, শুক্রবার বিকেলে একজন জুনিয়র ডেভ যে ভুলগুলো করে ঠিক সেই একই ভুল করবে — শুধু আরও দ্রুত, আর আরও বেশি।

আমার API কী এবং সিক্রেটগুলোর কী হয়?

এটাই আসলে যা নিয়ে আমার ঘুম নষ্ট হয়, কারণ এটা এমন একটা ভুল যা ততক্ষণ অদৃশ্য থাকে যতক্ষণ না তা আর অদৃশ্য থাকে না। ব্যর্থতার ধরনটা নাটকীয় নয় — কারো সার্ভার সিনেমার হ্যাকারের মতো করে ব্রিচ হয় না। এটা একটা কী যা চ্যাটে পেস্ট করা হয়, একটা জেনারেট করা ফাইলে প্রতিধ্বনিত হয়ে ফিরে আসে, কমিট করা হয়, আর ছয় মাস পরে চুপচাপ একটা রিপোজিটরিতে প্লেইনটেক্সট হিসেবে বসে থাকে যতক্ষণ না কেউ কৌতূহলবশত এর বিরুদ্ধে একটা সিক্রেট স্ক্যানার চালায়। এই প্ল্যাটফর্মে, সিক্রেটগুলো কখনো জেনারেট করা সোর্সে থাকে না — এগুলো রানটাইমে একটা এনক্রিপ্টেড স্টোর থেকে ইনজেক্ট করা হয়, আপনার টেন্যান্টের সাথে সীমাবদ্ধ, আর বিল্ড এজেন্টদের নির্দেশ দেওয়া হয় সেগুলোকে নামে রেফারেন্স করতে, কখনো মান দিয়ে নয়। কিন্তু আপনি যদি অন্য কোথাও বিল্ড করেন, অথবা কোনো টুলের চ্যাট উইন্ডোতে সরাসরি ক্রেডেনশিয়াল পেস্ট করেন, তাহলে ধরে নিন সেই টেক্সট এখন কোথাও একটা প্রশিক্ষণ-সংলগ্ন লগের অংশ হয়ে গেছে যদি না প্রোভাইডার স্পষ্টভাবে অন্যথা না বলে। নীতিগতভাবে, আপনি যা কিছু কোনো চ্যাট বক্সে টাইপ করেছেন তা রোটেট করুন, টেস্টিং শেষ করার সেই দিনেই।

কেউ কি একটা প্রম্পটের মাধ্যমে আমার সাইট হ্যাক করতে পারে, যেমন একটা প্রম্পট ইনজেকশন অ্যাটাক?

এখানে দুটি ভিন্ন জিনিস মিশিয়ে ফেলা হয়, এবং পার্থক্যটা গুরুত্বপূর্ণ। বিল্ডারের বিরুদ্ধে প্রম্পট ইনজেকশন — অর্থাৎ কেউ আপনার অ্যাপ তৈরি করা AI-কে ধোঁকা দিয়ে এমন কিছু করাচ্ছে যা আপনি চাননি — এটা একটা বাস্তব, স্বীকৃত ঝুঁকি, এবং এই কারণেই বিল্ড এজেন্টগুলো ব্ল্যাঙ্কেট শেল অ্যাক্সেসের বদলে সীমিত টুল পারমিশন নিয়ে চলে, এবং যেকোনো কিছু যা আপনার ফাইলসিস্টেম বা ডিপ্লয় পাইপলাইনকে স্পর্শ করে তা একটি স্পষ্ট অ্যাকশন লগের মধ্য দিয়ে যায় যা আপনি পরে অডিট করতে পারেন। আপনার শিপ করা অ্যাপের বিরুদ্ধে প্রম্পট ইনজেকশন একটা আলাদা বিষয়, যা তখনই প্রযোজ্য যখন আপনার অ্যাপ নিজেই রানটাইমে একটা LLM এমবেড করে — একটা সাপোর্ট চ্যাটবট, একটা AI সার্চ ফিচার, এই ধরনের কিছু। যদি করে, তাহলে ব্যবহারকারী যা টাইপ করতে পারে তা ওই মডেলের জন্য অবিশ্বস্ত ইনপুট হিসেবে বিবেচনা করুন, ঠিক যেমন এটা একটা SQL কোয়েরির জন্য অবিশ্বস্ত ইনপুট হিসেবে বিবেচনা করতেন। নিয়মটা পুরনো, নতুন অংশটা শুধু এই যে কোন সিস্টেম স্ট্রিংটা পার্স করছে।

শিপ করার আগে বিল্ডার কি নিজের কোডে থাকা দুর্বলতাগুলো যাচাই করে দেখে?

স্বয়ংক্রিয় চেকগুলো নির্ভরযোগ্যভাবে সাধারণ, ঘন ঘন ঘটা সমস্যাগুলো ধরতে পারে: হার্ডকোড করা সিক্রেট, স্পষ্টতই প্রয়োজনীয় এন্ডপয়েন্টে মিসিং অথ, প্যারামিটারের বদলে স্ট্রিং কনক্যাটেনেশন দিয়ে তৈরি SQL, পরিচিত CVE-সহ ডিপেন্ডেন্সি। যা এগুলো ভালোভাবে ধরতে পারে না তা হলো বিজনেস-লজিকের ত্রুটি — যেখানে প্রতিটি আলাদা কোড লাইন ঠিক আছে এবং দুর্বলতাটা লুকিয়ে থাকে দুটি ফিচারের মাঝের ফাঁকে যা কারো একসাথে যাচাই করার কথা মাথায় আসেনি। একটা ডিসকাউন্ট কোড যা রেফারেল বোনাসের সাথে অসীমভাবে স্ট্যাক হয়। একটা পাসওয়ার্ড রিসেট ফ্লো যা ফাঁস করে দেয় সিস্টেমে একটা ইমেইল আছে কিনা। এগুলো ধরতে দরকার এমন কাউকে যে বোঝে অ্যাপটা কীসের জন্য, শুধু কোড কী করে তা নয়, এবং কোনো স্ক্যানার — AI হোক বা না হোক — এখনও নির্ভরযোগ্যভাবে এগুলো খুঁজে পায় না। স্বয়ংক্রিয় রিভিউ একটা ভিত্তি, ছাদ নয়।

এটা যে থার্ড-পার্টি প্যাকেজগুলো ইনস্টল করে, সেটা কি সাপ্লাই-চেইন ঝুঁকি?

হ্যাঁ, এবং সৎভাবে বলতে গেলে এটা AI-লিখিত কোডের চেয়েও বড় বাস্তব-জগতের ঝুঁকি। বেশিরভাগ অ্যাপ লাইন-কাউন্টের হিসাবে ৮০-৯৫% ডিপেন্ডেন্সি; বিল্ডার যে কোড লেখে তা npm, PyPI, বা যে ইকোসিস্টেমই স্ট্যাকে ব্যবহৃত হোক না কেন, তার ওপর একটা পাতলা স্তর মাত্র। একটা ম্যালিশাস বা হাইজ্যাক করা প্যাকেজ আপনাকে ঝুঁকিতে ফেলতে পারে, আশেপাশের গ্লু কোড কে বা কী লিখেছে তা নির্বিশেষে — event-stream এবং colors.js ঘটনাগুলো দেখুন এটা বাস্তবে কীভাবে ঘটে তার উদাহরণ হিসেবে। প্রতিকারগুলো সাধারণ এবং কার্যকর: সবশেষ ভার্সন ট্র্যাক করার বদলে ভার্সন পিন করুন, গত সপ্তাহে প্রকাশিত প্যাকেজের চেয়ে প্রকৃত মেইনটেনেন্স ইতিহাসসহ প্যাকেজকে প্রাধান্য দিন, এবং একটা ডিপেন্ডেন্সি অডিট (`npm audit`, `pip-audit`, যেটা আপনার স্ট্যাকে খাটে) নিয়মিত অভ্যাস হিসেবে চালান, লঞ্চের আগে একবারের ধাপ হিসেবে নয়।

ব্রিচ হলে কার দায়?

আপনার — আইনগতভাবে, প্রায় সবসময়, যদি এটা আপনার অ্যাপ এবং আপনার গ্রাহকদের ডেটা হয়। এটা মানুষকে অবাক করে যারা ধরে নেয় "AI এটা লিখেছে" দায়িত্ব অন্য কোথাও সরিয়ে দেয়। তা করে না, ঠিক যেমন একজন ঠিকাদার ভাড়া করলে বিল্ডিং কোড লঙ্ঘনের দায় সম্পত্তির মালিকের থেকে সরে যায় না। প্ল্যাটফর্মগুলো তারা যে ইনফ্রাস্ট্রাকচার নিয়ন্ত্রণ করে তার দায়িত্ব বহন করে: সিক্রেট কীভাবে সংরক্ষিত হয়, টেন্যান্ট ডেটা কীভাবে আলাদা রাখা হয়, হোস্টিং স্তর নিজেই প্যাচড কিনা। কিন্তু আপনার নির্দিষ্ট করা অ্যাপ্লিকেশন লজিক, আপনার সংগ্রহ করার জন্য বেছে নেওয়া ডেটা, এবং আপনার ব্যবহারকারীদের দেওয়া শর্তাবলী আপনারই। যদি আপনি সংবেদনশীল কিছু নিয়ে কাজ করেন — পেমেন্ট বিবরণ, স্বাস্থ্য তথ্য, GDPR বা CCPA-র আওতায় থাকা যেকোনো কিছু — তাহলে "AI-নির্মিত" মানেই কোনো অতিরিক্ত আইনি সুরক্ষা স্তর ধরে নেওয়ার বদলে যে প্ল্যাটফর্মেই আছেন তার প্রকৃত ডেটা প্রসেসিং এগ্রিমেন্ট পড়ুন। তা নেই।

একজন ফাউন্ডার একবার আমাকে বলেছিলেন, প্রায় মজা করেই, যে তিনি নিজের কোডের চেয়ে AI-এর কোডকে বেশি বিশ্বাস করেন কারণ "অন্তত এটা রাত ২টায় ক্লান্ত হয় না।" হতে পারে। কিন্তু ক্লান্ত মানুষরা সাধারণত জানে যে তারা ক্লান্ত। একটা AI-এর কোনো ধারণা নেই যে সে এইমাত্র একটা ভুল করেছে, এবং এটা আপনাকে ঠিক একই আত্মবিশ্বাসী স্বরে বলবে কোডটা শেষ, তা সেটা নিখুঁত হোক বা ফুটো ভরা। আত্মবিশ্বাস কোনো নিরাপত্তা সংকেত নয়, উৎস যাই হোক না কেন।

লঞ্চ করার আগে কি সত্যিকারের সিকিউরিটি অডিটের জন্য টাকা খরচ করা উচিত?

যদি আপনি পেমেন্ট নিচ্ছেন, রেগুলেটর যাকে PII বলবে এমন কিছু সংরক্ষণ করছেন, অথবা এমন কোনো ব্যবসায়িক গ্রাহকের জন্য বানাচ্ছেন যিনি যেভাবেই হোক SOC 2 রিপোর্ট চাইবেন — তাহলে হ্যাঁ, এবং খরচকে আপনাকে এটা থেকে বিরত না রাখতে দিন। একটা ছোট অ্যাপে ফোকাসড অডিটের খরচ কয়েকশ থেকে নিম্ন হাজার ডলার পর্যন্ত হতে পারে স্কোপের উপর নির্ভর করে, যা একটা ব্রিচ নোটিফিকেশন চিঠির তুলনায় সস্তা। যদি আপনি একটা হবি প্রজেক্ট, একটা ইন্টারনাল টুল, বা এমন কিছু বানাচ্ছেন যাতে কোনো প্রকৃত ইউজার ডেটার ঝুঁকি নেই, তাহলে পেইড অডিট বাহুল্য; বরং বিনামূল্যে ও সস্তা স্তরটি চালান — ডিপেন্ডেন্সি স্ক্যানিং, প্রতিটি অথ বাউন্ডারির ম্যানুয়াল ক্লিক-থ্রু (একটা URL পরিবর্তন করে ইউজার A কি ইউজার B-র জিনিস দেখতে পারে?), এবং টাকা বা পাসওয়ার্ড স্পর্শ করা যেকোনো কিছুতে দ্বিতীয় একজোড়া মানুষের চোখ।

মানুষ সবচেয়ে বেশি যে সিকিউরিটি ভুলটা করে সেটা কী, এবং এটা কখন ঘটে?

লঞ্চের সময় নয় — তিন মাস পরে, যখন অ্যাপটা কাজ করছে এবং আর কেউ এটার দিকে তাকাচ্ছে না। এটা এমন একটা অ্যাডমিন রুট যা অরক্ষিত রয়ে গেছে কারণ এটা শুধুমাত্র যিনি বানিয়েছেন তিনিই নিজের লগইন দিয়ে টেস্ট করেছিলেন। এটা একটা ডিবাগ এন্ডপয়েন্ট যা প্রোডাকশনে পুরো স্ট্যাক ট্রেস ফেরত দেয়। এটা একটা ডাটাবেসে ডিফল্ট পাসওয়ার্ড যা "শুধু টেস্টিং-এর জন্য" রাখার কথা ছিল কিন্তু কখনো বদলানো হয়নি। এগুলোর কোনোটাই অস্বাভাবিক নয়। এগুলো সিকিউরিটির সেই সমতুল্য যেখানে তাড়াহুড়োয় একদিন দরজার সামনে ম্যাটের নিচে একটা বাড়তি চাবি রেখে দেওয়া হয়, তারপর ভুলে যাওয়া হয় সেটা সেখানে আছে। সমাধান কোনো ভালো টুল নয়, এটা পাঁচ মিনিটের একটা অভ্যাস: মাসে একবার, একজন আক্রমণকারীর দৃষ্টিতে পাঁচ মিনিট আপনার অ্যাপটা দেখুন, গর্বিত নির্মাতার দৃষ্টিতে দেখার আগে।