A06: ভালনারেবল ও আউটডেটেড কম্পোনেন্ট
এই পাঠে যা শিখবেন
- কেন থার্ড-পার্টি ডিপেন্ডেন্সি একটি বিশাল অ্যাটাক সারফেস — শুধু নিজের কোড নয়
- SBOM কী এবং কেন এটি "আপনি ঠিক কী ব্যবহার করছেন" জানার প্রথম ধাপ
- স্বয়ংক্রিয় ডিপেন্ডেন্সি-স্ক্যানিং টুল কীভাবে কাজ করে (উচ্চ-স্তরে)
- একটি ছোট ডিপেন্ডেন্সি-অডিট ফাংশন লেখা — কোড সহ
১ · সমস্যাটি কতটা বড়
একটি আধুনিক ওয়েব বা মোবাইল অ্যাপ্লিকেশনের কোডবেস দেখলে অবাক হবেন — প্রায়ই এর সংখ্যাগরিষ্ঠ কোড লাইনই ডেভেলপার নিজে লেখেননি, বরং থার্ড-পার্টি ডিপেন্ডেন্সিThird-Party Dependencyঅন্য কেউ লিখেছে এমন একটি লাইব্রেরি/প্যাকেজ যা আপনার প্রজেক্টে ইমপোর্ট/ইনস্টল করে ব্যবহার করা হয় (যেমন pip বা npm-এর মাধ্যমে)। থেকে এসেছে — লগিং লাইব্রেরি, HTTP ক্লায়েন্ট, ফ্রন্টএন্ড ফ্রেমওয়ার্ক, ইত্যাদি। প্রতিটি ডিপেন্ডেন্সি নিজেই একটি সফটওয়্যার — এবং যেকোনো সফটওয়্যারের মতোই এতে দুর্বলতা থাকতে পারে, যার CVE আইডি পাবলিকলি ঘোষিত হতে পারে (ties to L14)। সমস্যা হলো, অনেক দল জানেই না তারা ঠিক কোন কোন ডিপেন্ডেন্সি এবং কোন ভার্সন ব্যবহার করছে — ফলে যখন একটি নতুন CVE ঘোষিত হয়, তারা জানতেই পারে না তারা প্রভাবিত কি না।
এই কারণেই A06 কে হালকাভাবে নেওয়া উচিত নয় — এটি L14/L16-এর মতো একই মৌলিক নীতির (জানা দুর্বলতা + সময়মতো প্যাচ) প্রয়োগ, কিন্তু স্কেলটি অনেক বড়, কারণ একটি একক অ্যাপ্লিকেশনে শত শত (কখনো হাজার হাজার) পরোক্ষ (transitive) ডিপেন্ডেন্সি থাকতে পারে — যেগুলো আপনি সরাসরি ইনস্টল করেননি, বরং আপনার ব্যবহৃত লাইব্রেরিগুলোই ভেতরে ভেতরে ইনস্টল করেছে।
২ · SBOM — আপনি ঠিক কী ব্যবহার করছেন তা জানা
SBOMSoftware Bill of Materialsএকটি অ্যাপ্লিকেশনে ব্যবহৃত প্রতিটি উপাদান (লাইব্রেরি, ফ্রেমওয়ার্ক, তাদের সঠিক ভার্সন) -এর একটি সম্পূর্ণ, মেশিন-পাঠযোগ্য তালিকা। (Software Bill of Materials) হলো একটি অ্যাপ্লিকেশনে ঠিক কী কী উপাদান, কোন ভার্সনে ব্যবহৃত হচ্ছে তার একটি সম্পূর্ণ তালিকা — অনেকটা একটি খাবারের প্যাকেটের "উপাদান তালিকা"-র মতো। SBOM ছাড়া, একটি নতুন CVE ঘোষিত হলে একটি প্রতিষ্ঠানের জানার কোনো দ্রুত উপায় নেই তারা প্রভাবিত কি না — তাদের ম্যানুয়ালি প্রতিটি প্রজেক্ট খুঁজে দেখতে হয়। SBOM থাকলে এই প্রশ্নের উত্তর সেকেন্ডের মধ্যে পাওয়া যায়।
৩ · স্বয়ংক্রিয় ডিপেন্ডেন্সি-স্ক্যানিং টুল
বাস্তব-জগতে এই কাজটি ম্যানুয়ালি করা হয় না — স্বয়ংক্রিয় টুল ব্যবহার করা হয়:
- npm audit — Node.js প্রজেক্টের ডিপেন্ডেন্সি ট্রি স্ক্যান করে জানা দুর্বলতা রিপোর্ট করে।
- pip-audit — একই কাজ Python প্যাকেজের জন্য।
- Dependabot (GitHub) — স্বয়ংক্রিয়ভাবে দুর্বল ডিপেন্ডেন্সি চিহ্নিত করে এবং আপডেটের জন্য পুল-রিকোয়েস্ট তৈরি করে।
এই টুলগুলো মূলত একটি জিনিসই করে (উচ্চ-স্তরে): ইনস্টল করা প্রতিটি ডিপেন্ডেন্সি ও তার ভার্সনকে একটি ক্রমাগত হালনাগাদ হওয়া জানা-দুর্বলতার ডেটাবেসের বিপরীতে ক্রস-রেফারেন্স করা। নিচের কোড সেলে আমরা ঠিক এই যুক্তিটিই একটি ছোট, স্যান্ডবক্সড উদাহরণে বাস্তবায়ন করব।
৪ · কোড ডেমো — একটি সরল ডিপেন্ডেন্সি অডিটর
নিচের কোড সেলটি সম্পূর্ণ স্যান্ডবক্সড — এটি দুটি ভুয়া ইন-মেমরি ডিকশনারি ব্যবহার করছে: একটি "ইনস্টল করা" ডিপেন্ডেন্সি তালিকা এবং একটি "জানা-ভালনারেবল-ভার্সন" লুকআপ। কোনো বাস্তব প্যাকেজ ম্যানেজার, ইন্টারনেট কল বা ফাইল-সিস্টেম এখানে জড়িত নয়।
# ভুয়া "ইনস্টল করা" ডিপেন্ডেন্সি তালিকা — শুধুই ইন-মেমরি ডেটা
installed_dependencies = {
"web-framework-x": "2.3.1",
"logging-lib-y": "1.0.4",
"http-client-z": "4.5.0",
"template-engine-q": "1.9.9",
}
# ভুয়া "জানা-ভালনারেবল-ভার্সন" লুকআপ — বাস্তব CVE ডেটাবেসের একটি সরলীকৃত অনুকরণ
known_vulnerable_versions = {
"web-framework-x": {"2.3.1", "2.3.0"}, # CVE-2024-XXXX অনুকরণ
"logging-lib-y": {"0.9.0"}, # এই ভার্সনটি ইনস্টল করা ভার্সনের সাথে মেলে না
"template-engine-q": {"1.9.9", "1.9.8"}, # CVE-2023-YYYY অনুকরণ
}
def audit_dependencies(installed, vulnerable_lookup):
findings = []
for package, version in installed.items():
vulnerable_versions = vulnerable_lookup.get(package, set())
if version in vulnerable_versions:
findings.append(f"[ঝুঁকিপূর্ণ] {package}=={version} — এই ভার্সনে জানা দুর্বলতা আছে")
return findings
report = audit_dependencies(installed_dependencies, known_vulnerable_versions)
print("== ডিপেন্ডেন্সি অডিট রিপোর্ট ==")
print(f"মোট ইনস্টল করা ডিপেন্ডেন্সি: {len(installed_dependencies)}")
print()
if report:
for line in report:
print(line)
else:
print("কোনো জানা-ভালনারেবল ডিপেন্ডেন্সি পাওয়া যায়নি।")
print()
print(f"সিদ্ধান্ত: {len(report)}টি প্যাকেজ আপগ্রেড করা প্রয়োজন (patch management, ties to L16)।")
web-framework-x এবং template-engine-q দুটোই তাদের বর্তমান ইনস্টল করা
ভার্সনে জানা-ভালনারেবল হিসেবে চিহ্নিত হয়েছে, কিন্তু logging-lib-y হয়নি — কারণ এর ইনস্টল করা
ভার্সন (1.0.4) লুকআপের ভালনারেবল-সেটের (0.9.0) সাথে মেলে না, যদিও প্যাকেজটি
নিজেই লুকআপে উল্লেখ আছে। এটাই দেখায় কেন এই ধরনের অডিট শুধু "প্যাকেজটি কি পরিচিত" তা নয়, বরং
"এই নির্দিষ্ট ভার্সনটি" ভালনারেবল কি না তা নির্ভুলভাবে চেক করে।
আপনার নিজের কোড নিখুঁত হলেও, একটি একক অপ্যাচড থার্ড-পার্টি লাইব্রেরিই পুরো অ্যাপ্লিকেশনকে ঝুঁকিতে ফেলতে পারে। SBOM বজায় রাখা এবং প্রতিটি ডিপ্লয়মেন্টের আগে (বা নিয়মিত শিডিউলে) স্বয়ংক্রিয় ডিপেন্ডেন্সি-স্ক্যানিং চালানো — এই দুটিই আধুনিক নিরাপত্তা অনুশীলনের মৌলিক অংশ, ঠিক যেমন L15-এ শেখা ভালনারেবিলিটি ম্যানেজমেন্ট লাইফসাইকেল।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ "পরোক্ষ (transitive) ডিপেন্ডেন্সি" ঠিক কী, এবং এটি কেন A06-কে বিশেষভাবে কঠিন করে তোলে?
পরোক্ষ ডিপেন্ডেন্সি হলো এমন একটি লাইব্রেরি যা আপনি নিজে ইনস্টল করেননি, বরং আপনার সরাসরি ব্যবহৃত একটি লাইব্রেরিই ভেতরে ভেতরে ইনস্টল করেছে (একটি লাইব্রেরির নিজের একটি ডিপেন্ডেন্সি)। এটি কঠিন করে তোলে কারণ আপনি হয়তো জানেনই না এটি আপনার অ্যাপ্লিকেশনে বিদ্যমান — তাই এতে একটি CVE ঘোষিত হলে, আপনি সরাসরি সেই প্যাকেজ-নাম দেখেই চিনতে পারবেন না যে আপনি প্রভাবিত। এই কারণেই SBOM ও dependency-scanning টুল গুরুত্বপূর্ণ — তারা পুরো নির্ভরতা-ট্রি (পরোক্ষসহ) স্বয়ংক্রিয়ভাবে ম্যাপ করে দেয়।
প্র ০২ A06 কীভাবে L14 (CVE/CVSS) ও L16 (প্যাচ ম্যানেজমেন্ট)-এর সরাসরি প্রয়োগ — নতুন কী শিখলাম এই পাঠে?
L14/L16 শিখিয়েছিল কীভাবে জানা দুর্বলতা (CVE) চিহ্নিত ও প্যাচ করতে হয় — সাধারণভাবে, যেকোনো সফটওয়্যারের জন্য। A06 এই একই নীতিকে নির্দিষ্টভাবে থার্ড-পার্টি কোড-এ প্রয়োগ করে, যেখানে অতিরিক্ত চ্যালেঞ্জ হলো স্কেল (শত-হাজার ডিপেন্ডেন্সি) এবং দৃশ্যমানতার অভাব (পরোক্ষ ডিপেন্ডেন্সি আপনি দেখতেই পান না সহজে)। নতুন যা শিখলাম: SBOM ও স্বয়ংক্রিয় স্ক্যানিং টুল — এই স্কেল সমস্যাটির ব্যবহারিক সমাধান।
প্র ০৩ একটি প্রতিষ্ঠান যদি একটি পুরনো, আর কোনো আপডেট না পাওয়া (end-of-life) লাইব্রেরির উপর নির্ভরশীল হয়, তাহলে তাদের বাস্তবসম্মত অপশন কী কী?
বাস্তবসম্মত অপশনগুলো: (১) একটি সক্রিয়ভাবে রক্ষণাবেক্ষণকৃত বিকল্প লাইব্রেরিতে মাইগ্রেট করা (সবচেয়ে নিরাপদ কিন্তু সবচেয়ে বেশি কাজ), (২) নিজেরাই ফর্ক করে জরুরি নিরাপত্তা প্যাচ নিজে বজায় রাখা (রিসোর্স-ভারী), অথবা (৩) কম্পেনসেটিং কন্ট্রোল যোগ করা — যেমন সেই লাইব্রেরিকে নেটওয়ার্ক-স্তরে বিচ্ছিন্ন (segment) করে রাখা বা এর ইনপুট অতিরিক্ত কঠোরভাবে ফিল্টার করা যাতে জানা দুর্বলতাগুলো ট্রিগার হওয়ার সুযোগ কম থাকে। কোনো অপশনই আদর্শ নয় — এই কারণেই end-of-life ডিপেন্ডেন্সি এড়ানো (আগে থেকেই সক্রিয়ভাবে রক্ষণাবেক্ষণকৃত লাইব্রেরি বেছে নেওয়া) সবচেয়ে ভালো দীর্ঘমেয়াদি কৌশল।
অনুশীলন
-
চিন্তা করুন: উপরের কোডে
http-client-zকেন কোনো ফাইন্ডিং তৈরি করেনি —known_vulnerable_versionsডিকশনারিটি আরেকবার দেখুন।কারণ
http-client-zআসলেknown_vulnerable_versionsলুকআপ ডিকশনারিতেই নেই — অর্থাৎ আমাদের ভুয়া "ডেটাবেসে" এই প্যাকেজের জন্য কোনো জানা দুর্বলতা নথিভুক্ত নেই।audit_dependencies-এরvulnerable_lookup.get(package, set())লাইনটি এই ক্ষেত্রে একটি খালি সেট ফেরত দেয়, তাই কোনো ভার্সনই "ভালনারেবল" হিসেবে ম্যাচ করে না। এটি গুরুত্বপূর্ণ একটি সীমাবদ্ধতাও মনে করিয়ে দেয়: একটি অডিটর শুধু তার লুকআপ-ডেটাবেসে থাকা তথ্য অনুযায়ী কাজ করে — বাস্তবে যদি ডেটাবেসটি হালনাগাদ না থাকে, একটি সত্যিকারের ভালনারেবল প্যাকেজও অলক্ষিত থেকে যেতে পারে। -
পরীক্ষা করুন:
installed_dependencies-এlogging-lib-y-এর ভার্সন"0.9.0"করে দিয়ে Run চাপুন — রিপোর্ট কীভাবে বদলায়?এখন
logging-lib-y==0.9.0-ও একটি ফাইন্ডিং হিসেবে যুক্ত হবে, কারণ এই ভার্সনটিknown_vulnerable_versions["logging-lib-y"]সেটে বিদ্যমান। মোট ফাইন্ডিং সংখ্যা ২ থেকে বেড়ে ৩ হয়ে যাবে। এটি স্পষ্ট করে যে একই প্যাকেজ ভিন্ন ভিন্ন ভার্সনে ভিন্ন ঝুঁকি বহন করতে পারে — তাই শুধু "প্যাকেজের নাম" নয়, প্রতিটি স্থাপনার সঠিক ভার্সন নাম্বার ট্র্যাক করা অপরিহার্য।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৬০টি পাঠ পরবর্তী পাঠ — A07: আইডেন্টিফিকেশন ও অথেন্টিকেশন ফেইলিওর — এবং আরও অনেক কিছু।
- Discrete Mathematics কোর্স সহায়ক কোর্স RSA এনক্রিপশন ও নাম্বার থিওরির গণিত শিখতে দেখুন — M7 ক্রিপ্টোগ্রাফি মডিউলের ভিত্তি।
- System Design & Software Architecture কোর্স সঙ্গী কোর্স ডিপেন্ডেন্সি ম্যানেজমেন্ট ও CI/CD পাইপলাইন কীভাবে বড় সিস্টেমে প্রয়োগ হয় তা শিখতে দেখুন।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design ও Cybersecurity — সব এক জায়গায়।