Anthropic-এর বিনামূল্যের OSS Scanner—রিপোর্টে মানব যাচাই নেই

৮ অক্টোবর ২০২৬-এ Anthropic বিনামূল্যের OSS Scanner চালু করেছে। নিবন্ধিত ওপেন সোর্স প্রকল্প নিয়মিত স্ক্যান এবং সম্ভাব্য দুর্বলতার ব্যাখ্যা, সেটি কাজে লাগানোর প্রমাণ ও সম্ভব হলে সংশোধনের প্রস্তাবসহ রিপোর্ট পাবে। মেইনটেইনারের কাছে পাঠানোর আগে এসব রিপোর্ট মানব বিশেষজ্ঞ যাচাই করবেন না; ফলে রিপোর্ট পাওয়া আর ত্রুটি নিশ্চিত হওয়া এক বিষয় নয়।

Anthropic-এর প্রযুক্তিগত বিবরণ অনুযায়ী, চালুর আগের ছয় মাসে তাদের মডেল ২৯ হাজারের বেশি সম্ভাব্য দুর্বলতা শনাক্ত করলেও মানুষ যাচাই ও বাছাই করতে পেরেছেন প্রায় ৬ হাজার; পরীক্ষামূলক রিপোর্ট সম্পর্কে PostgreSQL-এর নোয়া মিশ বলেছেন, “Several reports came with fixes we can use nearly as-is”। যাচাইয়ের এই চাপ কমাতেই আগ্রহী প্রকল্পে মডেল তৈরি করা ফল সরাসরি পৌঁছানোর ব্যবস্থা করা হয়েছে। কিন্তু সংশোধনের প্রস্তাব থাকলেও সেটি নিজের প্রকল্পে নিরাপদে কাজ করবে কি না, সেই সিদ্ধান্ত মেইনটেইনারের।

কোন প্রকল্প কীভাবে নিবন্ধন করবে

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

কনফিগারেশনের project.yaml ফাইলে স্ক্যান করার কোড রিপোজিটরি, প্রধান নিরাপত্তা যোগাযোগের ইমেইল এবং স্ক্যানের পরিবেশ তৈরির Dockerfile-এর তথ্য লাগে। কোড GitHub-এ রাখতেই হবে এমন শর্ত নেই; পুল রিকোয়েস্টটি নিবন্ধনের জন্য। Dockerfile দিয়ে আগে থেকেই নির্ভরতা বসানো পরিবেশ তৈরি হয়, যাতে পরে ইন্টারনেট সংযোগ ছাড়াই স্ক্যানকারী এজেন্ট কাজ করতে পারে। তাই ফাইলটি স্থানীয়ভাবে তৈরি হয় কি না এবং সেই পরিবেশে প্রকল্পের পরীক্ষাগুলো চলে কি না, আবেদন পাঠানোর আগে দেখা যুক্তিসংগত।

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

ইমেইলের রিপোর্টে কী থাকবে

প্রথম স্ক্যানের পর মেইনটেইনার ইমেইলে সম্ভাব্য দুর্বলতার রিপোর্টের একটি গুচ্ছ পাবেন। প্রতিটি রিপোর্টে ত্রুটিটি পুনরুৎপাদনের স্বয়ংসম্পূর্ণ প্রমাণ ও ব্যাখ্যা থাকার কথা। সম্ভব হলে সমস্যার সূচনাকারী পরিবর্তনের বিশ্লেষণ এবং একটি সম্ভাব্য প্যাচও থাকবে। পরের স্ক্যানগুলো নতুন পরিবর্তনে আসা দুর্বলতার পাশাপাশি আগের স্ক্যানে বাদ পড়া সমস্যা খুঁজতে পারে; স্ক্যানের নির্দিষ্ট ব্যবধান ঘোষণা করা হয়নি।

রিপোর্ট তৈরির প্রক্রিয়ায় এজেন্ট ত্রুটি আবার পরীক্ষা, মূল কারণ বিশ্লেষণ এবং প্যাচ প্রস্তাব করতে পারে। এসব স্বয়ংক্রিয় ধাপ প্রমাণকে পরীক্ষা করার উপযোগী করে, কিন্তু প্রকল্পের বাস্তব ব্যবহারে ত্রুটিটির প্রভাব বা প্রস্তাবিত সংশোধনের সামঞ্জস্য নিশ্চিত করে না। বিশেষত তীব্রতার চিহ্নটি প্রকল্পের থ্রেট মডেলের সঙ্গে না মিললে মেইনটেইনারকে সেই মূল্যায়ন নতুন করে করতে হবে।

ফাইন্ডিং থেকে প্যাচ পর্যন্ত সিদ্ধান্তের পথ

রিপোর্টের প্রমাণকে প্রথমে সংশ্লিষ্ট কোডের সংস্করণ ও পরীক্ষার শর্তের সঙ্গে মিলিয়ে দেখা দরকার। নিচের ক্রমটি অযাচাইকৃত ফল বাছাইয়ের ব্যবহারিক পথ; প্রতিটি ধাপে প্রকল্পের নিজস্ব নিরাপত্তা ও প্রকাশের নিয়ম প্রযোজ্য।

1. রিপোর্ট যে সংস্করণ, ইনপুট ও নির্ভরতার কথা বলছে, সেগুলো মিলিয়ে উৎপাদন ব্যবস্থার বাইরে নিয়ন্ত্রিত পরিবেশে প্রমাণটি পুনরুৎপাদন করুন। ফল না মিললে আগে পরিবেশ বা সংস্করণের অমিল খুঁজুন। অমিল দূর করেও প্রমাণ ব্যর্থ হলে সেই শর্তগুলো লিখে রাখুন; শুধু ব্যর্থ পরীক্ষার ভিত্তিতে ত্রুটিকে সত্য বা মিথ্যা ঘোষণা করার প্রয়োজন নেই।
2. প্রমাণ কাজ করলে আক্রান্ত কোডপথে অবিশ্বস্ত ব্যবহারকারী পৌঁছাতে পারে কি না এবং ঘটনাটি প্রকল্পের নিরাপত্তা সীমার মধ্যে পড়ে কি না দেখুন। একই সমস্যা আগে রিপোর্ট হয়েছে কি না মিলিয়ে নিন। এতে নতুন দুর্বলতা, পুরোনো সমস্যার পুনরাবৃত্তি এবং অতিরঞ্জিত তীব্রতা আলাদা করা যায়।
3. নতুন ও প্রাসঙ্গিক দুর্বলতা নিশ্চিত হলে প্রস্তাবিত প্যাচকে পরীক্ষাধীন পরিবর্তন হিসেবে নিন। সংশোধনের আগে প্রমাণটি কাজ করে এবং পরে আর করে না, তা যাচাইয়ের সঙ্গে বিদ্যমান পরীক্ষা ও বৈধ ব্যবহারও চালিয়ে দেখুন। এরপর প্রকল্পের স্বাভাবিক কোড পর্যালোচনা ও প্রকাশ প্রক্রিয়ায় প্যাচ নিন।

এই ক্রমের কারণ হলো একটি কাজ করা প্রমাণও প্যাচের মানের নিশ্চয়তা দেয় না। সংশোধন ত্রুটিপূর্ণ কোডপথ বন্ধ করলেও অন্য ইনপুট বা সমর্থিত ব্যবহারে সমস্যা তৈরি করতে পারে। আবার প্রমাণ পুনরুৎপাদিত না হলে রিপোর্টের সংস্করণ, পরীক্ষার পরিবেশ ও প্রকল্পের থ্রেট মডেলের পার্থক্যই সিদ্ধান্তের সবচেয়ে দরকারি তথ্য। ভুল, সদৃশ বা অতিরঞ্জিত ফাইন্ডিংয়ের কারণ রিপোর্টের ইমেইলের জবাবে জানানো যায়।

প্রকাশের সময়সীমা ও রিপোর্ট বন্ধ করার সুযোগ

মানব যাচাই ছাড়া পাঠানো এসব ফাইন্ডিংয়ের ওপর স্বয়ংক্রিয় সমন্বিত প্রকাশের সময়সীমা চাপানো হচ্ছে না। কোনো রিপোর্ট পরে প্রচলিত মানব যাচাইকৃত দুর্বলতা প্রকাশের প্রক্রিয়ায় গেলে সেই প্রক্রিয়ার আলাদা নিয়ম কার্যকর হতে পারে। তাই ইমেইলে পাওয়া মডেল তৈরি ফল এবং পরে যাচাই করা নিরাপত্তা বিজ্ঞপ্তির অবস্থাকে এক করে দেখা ঠিক হবে না।

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

আরও পড়ুন:

• Cisco IOS XR-এর সব সংস্করণ ঝুঁকিতে—patch ছাড়া কোনো workaround নেই
• Claude দিয়ে আক্রমণের প্রায় পুরো কাজ—Anthropic-এর রিপোর্টে নতুন ঝুঁকি
• Anthropic-এর ভেতরেই মডেল যাচাই করবে Accenture—পাঁচ বছরে যৌথ $২ বিলিয়ন