দশক ধরে, স্ট্যাটিক অ্যাপ্লিকেশন সিকিউরিটি টেস্টিং (SAST) নিরাপত্তা দলগুলোর জন্য কোড রিভিউকে স্কেল করার অন্যতম কার্যকর উপায় হয়ে আছে.
তবে যখন আমরা Codex Security তৈরি করি, তখন আমরা একটি সুচিন্তিত নকশা বেছে নিয়েছিলাম: আমরা কোনো স্ট্যাটিক অ্যানালাইসিস রিপোর্ট ইমপোর্ট করে এবং এজেন্টকে সেটি যাচাই-বাছাই করতে বলে কাজ শুরু করিনি. আমরা সিস্টেমটিকে এমনভাবে ডিজাইন করেছি যাতে এটি সরাসরি রিপোজিটরি থেকেই কাজ শুরু করে—এর আর্কিটেকচার, ট্রাস্ট বাউন্ডারি এবং প্রত্যাশিত আচরণ বিশ্লেষণ করে—এবং মানুষের সময় ব্যয় করার অনুরোধ জানানোর আগেই এটি নিজের প্রাপ্ত ফলাফলগুলো যাচাই করে নেয়.
কারণটি সহজ: সবচেয়ে কঠিন দুর্বলতাগুলো সাধারণত ডেটাফ্লো সমস্যা নয়. এগুলো ঘটে যখন কোডটি সিকিউরিটি চেক প্রয়োগ করছে বলে মনে হয়, কিন্তু সেই চেকটি আসলে সিস্টেমটি যে বৈশিষ্ট্যের উপর নির্ভর করে তা নিশ্চিত করে না. অন্য কথায়, চ্যালেঞ্জটি কেবল একটি প্রোগ্রামের মাধ্যমে ডেটা কিভাবে চলাচল করে তা ট্র্যাক করা নয়—বিষয়টি হলো কোডের প্রতিরক্ষা ব্যবস্থা সত্যিই কাজ করে কিনা তা নির্ধারণ করা.
SAST-কে প্রায়ই একটি পরিষ্কার পাইপলাইনের মতো ফ্রেম করা হয়: অবিশ্বাসযোগ্য ইনপুটের একটি উৎস শনাক্ত করা, প্রোগ্রামের মধ্য দিয়ে ডেটা ট্র্যাক করা এবং এমন ক্ষেত্রে ফ্ল্যাগ করা যেখানে সেই ডেটা স্যানিটাইজেশন ছাড়া একটি সংবেদনশীল সিঙ্কে পৌঁছে যায়. এটি একটি চমৎকার মডেল এবং এটি অনেক বাস্তব ত্রুটিকে অন্তর্ভুক্ত করে.
বাস্তব ক্ষেত্রে, বড় পরিসরে কার্যক্রম বজায় রাখার জন্য SAST-কে কিছু আনুমানিক হিসাবের উপর নির্ভর করতে হয়—বিশেষ করে এমন সব রিয়েল কোডবেসের ক্ষেত্রে যেখানে ইনডিরেকশন, ডায়নামিক ডিসপ্যাচ, কলব্যাক, রিফ্লেকশন এবং ফ্রেমওয়ার্ক-নির্ভর কন্ট্রোল ফ্লো রয়েছে. এই আনুমানিক হিসাবগুলো যে SAST-এর কোনো ত্রুটি, তা নয়; বরং কোড রান না করেই সেটির যুক্তি বোঝার চেষ্টা করার এটিই বাস্তব চিত্র.
এটিই একমাত্র কারণ নয় যে Codex নিরাপত্তা SAST রিপোর্ট দিয়ে শুরু করে না.
আরও গভীর সমস্যা হলো আপনি সফলভাবে একটি উৎসকে একটি সিঙ্কে ট্রেস করার পরে কী হয়.
স্ট্যাটিক বিশ্লেষণ একাধিক ফাংশন ও স্তরের মধ্যে ইনপুট সঠিকভাবে ট্রেস করলেও, তাকে সেই প্রশ্নের উত্তর দিতে হয়—যেটি আসলে নির্ধারণ করে কোনো দুর্বলতা আছে কি না.
একটি সাধারণ প্যাটার্ন ধরুন: অবিশ্বাসযোগ্য কনটেন্ট রেন্ডার করার আগে কোড sanitize_html() এর মতো একটি ফাংশন কল করে. একটি স্ট্যাটিক অ্যানালাইজার দেখতে পারে যে স্যানিটাইজারটি চালানো হয়েছে. এটি সাধারণত নির্ধারণ করতে পারে না যে সেই স্যানিটাইজারটি সংশ্লিষ্ট নির্দিষ্ট রেন্ডারিং কনটেক্সট, টেমপ্লেট ইঞ্জিন, এনকোডিং বিহেভিয়ার এবং সংশ্লিষ্ট ডাউনস্ট্রিম ট্রান্সফরমেশনগুলোর জন্য যথেষ্ট কিনা.
সেখানেই বিষয়টি জটিল হয়ে ওঠে. সমস্যাটি কেবল ডেটা একটি সিঙ্কে পৌঁছায় কিনা তা নয়. এটি হলো কোডের মধ্যে থাকা চেকগুলো আসলে সিস্টেম যেভাবে ধরে নেয়, সেইভাবে মানটিকে সত্যিই সীমাবদ্ধ করে কিনা.
অন্যভাবে বললে: “কোডটি একটি স্যানিটাইজার কল করে” এবং “সিস্টেমটি নিরাপদ”-এর মধ্যে বড় পার্থক্য রয়েছে.
এখানে এমন একটি প্যাটার্ন আছে যা বাস্তব সিস্টেমে সব সময়ই দেখা যায়.
একটি ওয়েব অ্যাপ্লিকেশন একটি JSON পে-লোড গ্রহণ করে, একটি redirect_url এক্সট্র্যাক্ট করে, এটিকে একটি allowlist regex-এর বিরুদ্ধে ভ্যালিডেট করে, URL-ডিকোড করে, এবং ফলাফলটি একটি রিডাইরেক্ট হ্যান্ডলারের কাছে পাঠায়.
একটি ক্লাসিক সোর্স-টু-সিঙ্ক রিপোর্ট প্রবাহটি ব্যাখ্যা করতে পারে.
অবিশ্বাসযোগ্য ইনপুট → regex চেক → URL ডিকোড → রিডাইরেক্ট
কিন্তু আসল প্রশ্নটি এই নয় যে চেকটি আছে কিনা. পরবর্তী রূপান্তরগুলোর পরে সেই যাচাইটি এখনও মানকে সীমাবদ্ধ করে কিনা, সেটাই প্রশ্ন.
যদি regex ডিকোড করার আগে চলে, তাহলে এটি কি রিডাইরেক্ট হ্যান্ডলার যেভাবে ব্যাখ্যা করে, সেইভাবে ডিকোড করা URL সীমাবদ্ধ করে?
এর উত্তর দিতে হলে পুরো রূপান্তর প্রক্রিয়ার শৃঙ্খলটি নিয়ে যুক্তি করতে হয়: regex কী অনুমোদন করে, ডিকোডিং ও নর্মালাইজেশন কিভাবে আচরণ করে, URL পার্সিং এজ কেসগুলোকে কিভাবে বিবেচনা করে এবং রিডাইরেক্ট লজিক কিভাবে স্কিম ও অথরিটি নির্ণয় করে.
বাস্তবে গুরুত্বপূর্ণ অনেক দুর্বলতা দেখতে এমনই: অপারেশনের ক্রমে ভুল, আংশিক নরমালাইজেশন, পার্সিং-এর অস্পষ্টতা এবং ভ্যালিডেশন ও ইন্টারপ্রিটেশনের মধ্যে অমিল. ডেটাফ্লো দৃশ্যমান. এই দুর্বলতাটি মূলত কনস্ট্রেইন্ট বা সীমাবদ্ধতাগুলো যেভাবে ট্রান্সফরমেশন চেইনের মাধ্যমে অগ্রসর হয়—অথবা অগ্রসর হতে ব্যর্থ হয়—তার মধ্যে নিহিত.
এটি কেবল একটি তাত্ত্বিক প্যাটার্ন নয়. CVE-2024-29041(একটি নতুন উইন্ডোতে খোলে)-এ, Express একটি ওপেন রিডাইরেক্ট সমস্যার দ্বারা প্রভাবিত হয়েছিল, যেখানে বিকৃত URL-গুলো রিডাইরেক্ট লক্ষ্যগুলো কিভাবে এনকোড করা হয়েছিল এবং পরে ব্যাখ্যা করা হয়েছিল তার কারণে সাধারণ অ্যালাওলিস্ট ইমপ্লিমেন্টেশনগুলোকে বাইপাস করতে পারত. ডেটাফ্লোটি সহজ ছিল. আরও কঠিন প্রশ্নটি—এবং যে প্রশ্নটি নির্ধারণ করেছিল বাগটি ছিল কিনা—ছিল যে রূপান্তর চেইনের পরে যাচাইকরণটি এখনও বহাল ছিল কিনা.
Codex Security একটি সহজ লক্ষ্যকে কেন্দ্র করে তৈরি: আরও শক্তিশালী প্রমাণসহ সমস্যাগুলো প্রকাশ করে ট্রায়াজ কমানো. প্রোডাক্টে, তার মানে হলো রিপো-নির্দিষ্ট কনটেক্সট (থ্রেট মডেলসহ) ব্যবহার করা এবং উচ্চ-সিগন্যাল ইস্যুগুলোকে সামনে আনার আগে একটি বিচ্ছিন্ন পরিবেশে যাচাই করা.
Codex Security যখন এমন কোনো সীমানার সম্মুখীন হয় যা "ভ্যালিডেশন" বা "স্যানিটাইজেশন" এর মতো মনে হয়, তখন এটি সেটিকে কেবল একটি সাধারণ চেকবক্স হিসেবে বিবেচনা করে না. এটি কোডটি কী নিশ্চয়তা দেওয়ার চেষ্টা করছে—তা বোঝার চেষ্টা করে—এবং তারপর সেই নিশ্চয়তাটিকে মিথ্যা প্রমাণ করার চেষ্টা করে.
বাস্তবে, এটি সাধারণত নিম্নোক্তগুলোর এক ধরনের মিশ্রণ বলে মনে হয়:
- সম্পূর্ণ রিপোজিটরি কন্টেক্সট সহ প্রাসঙ্গিক কোড পাথ পড়া, যেমনভাবে একজন নিরাপত্তা গবেষক করবেন এবং উদ্দেশ্য ও বাস্তবায়নের মধ্যে অমিল খোঁজা. এটিতে মন্তব্য অন্তর্ভুক্ত আছে, কিন্তু মডেল মন্তব্যগুলোকে সবসময় বিশ্বাস করে না, তাই আপনার কোডের উপরে //Halvar says: this is not a bug যোগ করলে সেটাকে বিভ্রান্ত করা যায় না, যদি সত্যিই কোনো বাগ থাকে.
- সমস্যাটিকে সবচেয়ে ছোট পরীক্ষাযোগ্য অংশে (যেমন, একক ইনপুটের চারপাশে ট্রান্সফরমেশন পাইপলাইন) নামিয়ে আনুন, যাতে সিস্টেমের বাকি অংশ বাধা না দেয় এবং আপনি এটি সম্পর্কে যুক্তি করতে পারেন. এই অর্থে, Codex Security ছোট ছোট কোড স্লাইস বের করে এবং সেগুলোর জন্য মাইক্রো-ফাজার তৈরি করে.
- প্রতিটি যাচাইকরণকে স্বাধীনভাবে গণ্য না করে, রূপান্তর জুড়ে সীমাবদ্ধতা সম্পর্কে যুক্তি প্রদান. যেখানে প্রাসঙ্গিক, এটি সন্তোষজনকতার প্রশ্ন হিসেবে আনুষ্ঠানিকীকরণ অন্তর্ভুক্ত করতে পারে. অন্য কথায়, আমরা মডেলকে z3-solver সহ একটি Python পরিবেশে অ্যাক্সেস দিই এবং প্রয়োজন হলে এটি তা ব্যবহার করতে দক্ষ, যেমন একজন মানুষ একটি বিশেষভাবে জটিল ইনপুট সীমাবদ্ধতা সমস্যার উত্তর দিতে হলে করত. এটি নন-স্ট্যান্ডার্ড আর্কিটেকচারে ইন্টিজার ওভারফ্লো বা অনুরূপ বাগগুলো বিশ্লেষণ করার জন্য বিশেষভাবে উপযোগী.
- যতটা সম্ভব, স্যান্ডবক্সযুক্ত যাচাইকরণ পরিবেশে হাইপোথিসিসগুলো এক্সিকিউট করা, যাতে “এটা সমস্যা হতে পারে” আর “এটা সমস্যা” — এই দুটোর মধ্যে পার্থক্য বোঝা যায়. কোডটি 'ডিবাগ মোড'-এ কম্পাইল করে সম্পূর্ণ এন্ড-টু-এন্ড PoC (প্রুফ অফ কনসেপ্ট)-এর চেয়ে বড় কোনো প্রমাণ আর হতে পারে না.
এটাই হলো মূল পরিবর্তন: "একটি পরীক্ষা বিদ্যমান"—এই পর্যায়ে থেমে যাওয়ার পরিবর্তে সিস্টেমটি "ইনভ্যারিয়েন্ট কাজ করছে (অথবা করছে না) এবং এই হলো তার প্রমাণ"—এই দিকে অগ্রসর হয়. আর মডেল সেই কাজের জন্য সেরা টুলটি বেছে নেয়.
একটা যৌক্তিক প্রতিক্রিয়া হলো: কেন দুটোই করা হবে না? প্রথমে একটি SAST রিপোর্ট দিয়ে শুরু করুন, তারপর আরও গভীরভাবে বিশ্লেষণ করতে এজেন্ট ব্যবহার করুন.
কিছু ক্ষেত্রে প্রাকগণিত ফলাফল সহায়ক হতে পারে, বিশেষত সংকীর্ণ এবং পরিচিত বাগ শ্রেণির জন্য. কিন্তু প্রেক্ষাপটে দুর্বলতা আবিষ্কার ও যাচাই করার জন্য ডিজাইন করা একটি এজেন্টের ক্ষেত্রে, SAST রিপোর্ট থেকে শুরু করলে তিনটি পূর্বানুমেয় ব্যর্থতার মোড তৈরি হয়.
প্রথমত, এটি আগেভাগে সীমিত করার জন্য উৎসাহিত করতে পারে. একটি ফাইন্ডিংস তালিকা হলো এমন একটি মানচিত্র, যেখানে একটি টুল ইতিমধ্যেই দেখেছে. আপনি যদি এটিকে শুরুর বিন্দু হিসেবে ধরেন, তাহলে আপনি সিস্টেমকে একই অঞ্চলগুলোতে অসামঞ্জস্যপূর্ণভাবে বেশি প্রচেষ্টা ব্যয় করতে, একই অ্যাবস্ট্র্যাকশন ব্যবহার করতে এবং টুলটির দৃষ্টিভঙ্গির সঙ্গে খাপ খায় না এমন সমস্যার শ্রেণিগুলো মিস করতে পক্ষপাতী করে তুলতে পারেন.
দ্বিতীয়ত, এটি এমন অন্তর্নিহিত বিচার প্রবর্তন করতে পারে যা খুঁজে বের করা কঠিন. অনেক SAST ফাইন্ডিংস স্যানিটাইজেশন, ভ্যালিডেশন বা ট্রাস্ট সীমারেখা সম্পর্কে অনুমান এনকোড করে. যদি সেই অনুমানগুলো ভুল হয়—অথবা শুধু অসম্পূর্ণ হয়—সেগুলোকে যুক্তিতর্কের লুপে ঢোকালে এজেন্ট “তদন্ত” থেকে “নিশ্চিত বা খারিজ” করতে সরে যেতে পারে, যা আমরা এজেন্টকে করতে চাই না.
তৃতীয়ত, এটি যুক্তিবিচার সিস্টেমটাকে মূল্যায়ন করা আরও কঠিন করে তুলতে পারে. যদি পাইপলাইনটা SAST আউটপুট দিয়ে শুরু হয়, তাহলে এজেন্টটি নিজের বিশ্লেষণ থেকে কী পেয়েছে আর অন্য কোনো টুল থেকে কী পেয়েছে—এটা আলাদা করে দেখা কঠিন হয়ে যায়. সিস্টেমের সক্ষমতা যদি নির্ভুলভাবে মাপতে চান, তাহলে এই আলাদা করে দেখাটা গুরুত্বপূর্ণ—কারণ সময়ের সাথে সিস্টেম উন্নত হতে এটা দরকার.
তাই আমরা Codex Security তৈরি করেছি নিরাপত্তা গবেষণা যেখান থেকে শুরু হয় সেখান থেকেই শুরু করতে: কোড এবং সিস্টেমের অভিপ্রায় থেকে—এবং কোনো মানুষকে বিরক্ত করার আগে আত্মবিশ্বাসের মানদণ্ড উঁচু করতে যাচাই ব্যবহার করতে.
SAST টুলস তাদের ডিজাইন করা কাজের ক্ষেত্রে অসাধারণ হতে পারে: নিরাপদ কোডিং মানদণ্ড প্রয়োগ করা, সরল সোর্স-টু-সিঙ্ক ইস্যু ধরা এবং পূর্বানুমেয় ট্রেডঅফসহ স্কেলে পরিচিত প্যাটার্ন শনাক্ত করা. এগুলি ডিফেন্স-ইন-ডেপথ-এর একটি শক্তিশালী অংশ হতে পারে.
এই পোস্টটি আরও সংকীর্ণ: এটি এই বিষয়ে যে আচরণ সম্পর্কে যুক্তিবিচার করতে এবং ফলাফল যাচাই করতে ডিজাইন করা একটি এজেন্টের কাজ কেন একটি স্থির ফলাফল তালিকাকে ভিত্তি করে শুরু করা উচিত নয়.
পিওর সোর্স-টু-সিঙ্ক ভাবনার একটি প্রাসঙ্গিক সীমাবদ্ধতার কথাও উল্লেখ করা প্রয়োজন: প্রতিটি দুর্বলতাই কিন্তু ডেটাফ্লো সমস্যা নয়. অনেক প্রকৃত ব্যর্থতাই হলো স্টেট এবং ইনভ্যারিয়েন্ট সংক্রান্ত সমস্যা—যেমন ওয়ার্কফ্লো বাইপাস, অথোরাইজেশন গ্যাপ এবং "সিস্টেমটি ভুল স্টেটে রয়েছে" এমন সব বাগ. এই ধরনের বাগের ক্ষেত্রে, একটি tainted মান কোনো একক “বিপজ্জনক sink”-এ পৌঁছায় না. ঝুঁকিটা হলো—প্রোগ্রামটি যা ধরে নেয় তা সবসময় সত্য হবে.
আমরা আশা করি নিরাপত্তা টুলিং ইকোসিস্টেম ক্রমাগত উন্নত হতে থাকবে: স্ট্যাটিক অ্যানালাইসিস, ফাজিং, রানটাইম গার্ডস এবং এজেন্টিক ওয়ার্কফ্লোগুলো (যা স্বয়ংক্রিয় কাজের প্রবাহকে নির্দেশ করে)—সবগুলোরই ভূমিকা থাকবে.
আমরা চাই Codex Security সেই কাজে দক্ষ হয়ে উঠুক যা সিকিউরিটি টিমের জন্য সবচেয়ে ব্যয়বহুল: "এটি সন্দেহজনক মনে হচ্ছে" থেকে "এটি একটি বাস্তব ত্রুটি, এটি এভাবে ব্যর্থ হয় এবং সিস্টেমের উদ্দেশ্য অনুযায়ী এর সমাধান এখানে"—এই পর্যায়ে রূপান্তর করা.
Codex Security কিভাবে রিপোজিটরি স্ক্যান করে, ফলাফল যাচাই করে এবং সমাধানের প্রস্তাব দেয় তা জানতে আমাদের ডকুমেন্টেশন(একটি নতুন উইন্ডোতে খোলে) দেখুন.
