TL; ডিআর
npm প্যাকেজের দুর্বলতা খুঁজে বের করা সহজ। npm audit চার সেকেন্ডে এটি করে এবং আপনাকে ৪০০টি ফলাফল ধরিয়ে দেয়। কঠিন অংশটি হলো পরবর্তী দুটি প্রশ্ন: এগুলোর মধ্যে কোনটি আপনার অ্যাপ্লিকেশনে আসলেই ব্যবহার করা সম্ভব, এবং কোন আপগ্রেডটি বিল্ড নষ্ট না করেই সমস্যাটি সমাধান করে।
- তালিকার বেশিরভাগই তোমার সমস্যা নয়। ‘গুরুত্বপূর্ণ’ ফাইন্ডিংগুলোর ক্ষেত্রে রিচেবিলিটি এবং রানটাইম কনটেক্সট প্রয়োগ করলেও অল্প কিছু ফাইন্ডিং গুরুতর থেকে যায়। কল-গ্রাফ অ্যানালাইসিসই আপনাকে বলে দেয় কোনগুলো গুরুতর।
npm audit fix --forceএটি কোনো স্থির কৌশল নয়। এটি প্রধান সংস্করণ এড়িয়ে গিয়ে সতর্কবার্তাগুলোর সমাধান করে, আর এভাবেই একটি নিরাপত্তা সংক্রান্ত কাজ বিভ্রাটে পরিণত হয়।- ট্রানজিটিভ ডিপেন্ডেন্সিগুলোর মধ্যেই মূল পরিধিটি নিহিত থাকে। আপনি তাদের বেছে নেননি, প্রায়শই সরাসরি তাদের আপগ্রেড করা যায় না, এবং প্রাপ্তির সংখ্যায় তাদেরই আধিপত্য।
- মার্জ করার আগে ঠিক করুন, রিলিজের পরে নয়। CI-তে একটি গেট এবং একটি স্বয়ংক্রিয় pull request খরচ হয় কয়েক মিনিট। একটি প্রোডাকশন প্যাচ তৈরি করতে পুরো সপ্তাহান্ত লেগে যায়।
কেন সংখ্যা খোঁজাটা সমস্যা নয়
প্রথম বছর পার হওয়ার পর প্রতিটি নোড প্রজেক্টেই একই অভিজ্ঞতা হয়। আপনি একটি স্ক্যান চালান, শত শত এনপিএম প্যাকেজের দুর্বলতা দেখতে পান, এবং তালিকাটি এতটাই বড় যে টার্মিনালটি বন্ধ করে দেওয়াই স্বাভাবিক প্রতিক্রিয়া।
সেই প্রতিক্রিয়াটি সঠিক, আর এটাই অস্বস্তিকর ব্যাপার। প্রায় তিন-চতুর্থাংশ কোডবেসে উচ্চ-ঝুঁকিপূর্ণ ওপেন-সোর্স কম্পোনেন্ট থাকে, এবং একটি স্ক্যানার যেকোনো দিন যা রিপোর্ট করে তার বেশিরভাগই আসলেই আপনার ডিপেন্ডেন্সি ট্রি-তে থাকে। তালিকাটি নির্ভুল। এটি শুধু কোনো ওয়ার্ক কিউ নয়।
একটি নির্ভুল তালিকা এবং একটি কার্যকর তালিকার মধ্যে পার্থক্য হলো প্রেক্ষাপট, এবং তা কয়েকটি প্রশ্নের উপর নির্ভর করে।
- দুর্বল কোডটি কি আমার অ্যাপ্লিকেশন থেকে আসলেই অ্যাক্সেসযোগ্য?
- বাস্তবে কি কেউ এর অপব্যবহার করছে?
- এটি যে বিষয়টিকে প্রভাবিত করে, তা কি ব্যবসার জন্য গুরুত্বপূর্ণ?
যে স্ক্যানার সেগুলোর উত্তর দিতে পারে না, সেটি আপনার হাতে একটি মজুত তালিকা তুলে দেয় এবং তাকেই রিপোর্ট বলে চালিয়ে দেয়।
npm প্যাকেজগুলিতে দুর্বলতা কীভাবে পরীক্ষা করবেন
এনপিএম প্যাকেজে দুর্বলতা পরীক্ষা করার চারটি কার্যকরী উপায় রয়েছে, এবং সেগুলো বিভিন্ন প্রশ্নের উত্তর দেয়।
শুরু করা npm audit কারণ এতে কোনো খরচ হয় না এবং কয়েক সেকেন্ড সময় লাগে। এখানেই থেমে যাবেন না, কারণ এটি যে উত্তর দেয় তা হলো “এই তো সবকিছু”, আর সবকিছু পরিকল্পনা নয়।
আপনি যদি অ্যাডভাইজরি ফিডের উপর নির্ভর করেন, তবে একটি বিষয় জেনে রাখা ভালো: গিটহাব অ্যাডভাইজরি ডেটাবেস এনপিএম ইকোসিস্টেমের জন্য ম্যালওয়্যার অ্যাডভাইজরি বহন করে, কিন্তু ডিপেন্ডাবট ইচ্ছাকৃতভাবে সেগুলোর জন্য অ্যালার্ট দেয় না, কারণ ডাউনস্ট্রিম ব্যবহারকারী সাধারণত আপগ্রেড করে সেগুলোর সমাধান করতে পারে না। এটি একটি কাঠামোগত ত্রুটি, এমন কোনো সেটিং নয় যা আপনি চালু করতে পারেন। ক্ষতিকারক প্যাকেজগুলোর জন্য ভিন্ন ধরনের নিয়ন্ত্রণ প্রয়োজন: প্রকাশের পরে নয়, বরং প্রকাশের সময়েই শনাক্তকরণ। জাইজেনির। ম্যালওয়্যারের প্রাথমিক সতর্কতা এটি সিগনেচারের জন্য অপেক্ষা না করে, আচরণগত এবং ব্যতিক্রমী বিশ্লেষণ ব্যবহার করে npm, PyPI, Maven এবং অন্যান্য রেজিস্ট্রি জুড়ে নতুন প্রকাশিত প্যাকেজগুলিকে প্রকাশের সাথে সাথেই বিশ্লেষণ করে, এবং এটি বিনামূল্যের ডেভেলপার প্ল্যানে অন্তর্ভুক্ত। আমরা এটি নিয়ে আলোচনা করেছি বিদ্বেষপরায়ণ এনপিএম প্যাকেজ।
যে ফিল্টারগুলো ৪০০টি ফলাফলকে একটি সংক্ষিপ্ত তালিকায় পরিণত করে
এই অংশটিই একটি দলের কাজের ধরন বদলে দেয়।
| ফিল্টার | যে প্রশ্নের উত্তর এটি দেয় | এটি সাধারণত যা অপসারণ করে |
|---|---|---|
| পুনঃব্যবস্থা | আমার অ্যাপ্লিকেশনের এক্সিকিউশন কি প্রকৃতপক্ষে ঝুঁকিপূর্ণ ফাংশনটি পর্যন্ত পৌঁছাতে পারে? | সবচেয়ে বড় কাটছাঁট। বেশিরভাগ পরামর্শ এমন কোডে থাকে যা অ্যাপ্লিকেশনটি কখনও কল করে না। |
| এক্সপ্লয়েট প্রাপ্যতা | কোনো কার্যকরী পাবলিক এক্সপ্লয়েট কি বিদ্যমান, এবং বর্তমানে কি বাস্তবে এর অপব্যবহার করা হচ্ছে? | তাত্ত্বিক ঝুঁকিকে অস্ত্রায়িত ঝুঁকি থেকে পৃথক করে। কোনো পাবলিক এক্সপ্লয়েটসহ প্রাপ্ত তথ্য, তার তীব্রতার স্কোর যা-ই বলুক না কেন, অগ্রাধিকার পেয়ে যায়। |
| শোষণের সম্ভাবনা (EPSS) | আগামী ৩০ দিনের মধ্যে বন্য পরিবেশে শোষণের সম্ভাবনা কতটা? | উচ্চ-গুরুত্বপূর্ণ আবিষ্কার যা কেউ কাজে লাগাচ্ছে না, এবং যা সচরাচর এই সপ্তাহের কাজ নয়। |
| ব্যবসায়িক প্রেক্ষাপট | প্রভাবিত পরিষেবাটি কি গুরুত্বপূর্ণ, এবং এটি কি ঝুঁকির সম্মুখীন? | এমন সিস্টেমে পৌঁছানো ও কাজে লাগানো যায় এমন ফলাফল, যেগুলোতে কোনো উল্লেখযোগ্য ঝুঁকি নেই। |
| প্রাপ্যতা ঠিক করুন | এমন কোনো সংস্করণ আছে কি যা আমার কোনো ক্ষতি না করে এর সমাধান করতে পারে? | আজ যা বন্ধ করা যায় এবং যার জন্য বিকল্প ব্যবস্থার প্রয়োজন, সেগুলোকে আলাদা করে। |
- পুনঃব্যবস্থা এটিই প্রথম এবং সবচেয়ে বড় পদক্ষেপ। আপনার নির্ভর করা কোনো প্যাকেজের দুর্বলতা তখনই কাজে লাগানো সম্ভব, যখন প্রোগ্রামটি প্রকৃতপক্ষে সেই দুর্বল ফাংশনটিতে পৌঁছাতে পারে। কল গ্রাফ ট্রেসিং ম্যানিফেস্ট থেকে অনুমান করার পরিবর্তে ফাংশন পর্যায়েই এর উত্তর দেয় এবং এটি আপনার ব্যবহৃত কম্পোনেন্টগুলোকে কেবল উপস্থিত কম্পোনেন্টগুলো থেকে আলাদা করে। জাইজেনির রিচেবিলিটি অ্যানালাইসিস ভুল পজিটিভের হার ৭০% পর্যন্ত কমিয়ে দেয়।
এক্সপ্লয়েট প্রাপ্যতা দ্বিতীয়টি হলো, এবং এটি কোনো পূর্বাভাস নয়, বরং একটি বাস্তব ঘটনা। একটি কার্যকর পাবলিক এক্সপ্লয়েট, বা বাস্তবে এর নিশ্চিত ব্যবহার, কোনো অনুসন্ধানের গুরুত্ব পরিবর্তন করে দেয়, তার তীব্রতার স্কোর যা-ই বলুক না কেন। এই পার্থক্যটি এখন আর উত্তম অনুশীলন নয়, বরং একটি বাধ্যবাধকতায় পরিণত হয়েছে: সাইবার রেজিলিয়েন্স অ্যাক্ট অনুযায়ী, কোনো নির্মাতা তার পণ্যে সক্রিয়ভাবে ব্যবহৃত কোনো দুর্বলতা সম্পর্কে অবগত হলে, তাকে ২৪ ঘণ্টার মধ্যে তা জানাতে হয়। যে প্রোগ্রাম “সক্রিয়ভাবে ব্যবহৃত” এবং “উচ্চ CVSS”-এর মধ্যে পার্থক্য করতে পারে না, সেটি এই সময়সীমা পূরণ করতে পারে না।
এক্সপ্লয়েটের সম্ভাবনা হলো তৃতীয়টি, এবং এটি সেই একই প্রশ্ন যেখানে পূর্বাভাসটি আবার যুক্ত করা হয়েছে। EPSS স্কোর নির্ধারণ করে যে আগামী ৩০ দিনের মধ্যে কোনো একটি ভালনারেবিলিটি বাস্তবে ব্যবহৃত হওয়ার সম্ভাবনা কতটুকু, যা বাস্তবে ঘটলে পরিস্থিতি কতটা খারাপ হবে সেই প্রশ্ন থেকে সম্পূর্ণ ভিন্ন। একটি উচ্চ CVSS স্কোর এবং একটি নগণ্য EPSS স্কোর সাধারণত এই সপ্তাহের কাজ নয়।
- ব্যবসায়িক প্রেক্ষাপট এটি হলো তৃতীয়টি, এবং এটি এমন একটি যা কোনো জেনেরিক ফিড সরবরাহ করতে পারে না। একটি ইন্টারনেট-মুখী পেমেন্ট সার্ভিসে পৌঁছানো ও কাজে লাগানো যায় এমন একটি দুর্বলতা খুঁজে পাওয়া এবং একটি অভ্যন্তরীণ রিপোর্টিং টুলে একই CVE খুঁজে পাওয়া—দুটো এক জিনিস নয়।
একসাথে প্রয়োগ করা হলে, এই ফিল্টারগুলো নিয়মিতভাবে এমন একটি তালিকাকে, যা কেউ পড়ে না, এমন একটি তালিকায় পরিণত করে যা কেউ শেষ করে। রানটাইম এবং রিচেবিলিটি কনটেক্সট সাধারণত "গুরুত্বপূর্ণ" ফাইন্ডিংগুলোর মধ্যে শুধুমাত্র একটি ক্ষুদ্র অংশকেই গুরুত্বপূর্ণ হিসেবে রেখে দেয়। জাইজেনি রিচেবিলিটি, এক্সপ্লয়েট অ্যাভেইলেবিলিটি, ইপিএসএস এবং বিজনেস কনটেক্সটকে একটি প্রায়োরিটাইজেশন ফানেলের কনফিগারযোগ্য পর্যায় হিসেবে বিবেচনা করে, যার সংখ্যা আটটি পর্যন্ত হতে পারে। ফলে, "রিচেবল এবং সক্রিয়ভাবে এক্সপ্লয়েট করা" বিষয়টি হাতে চালানো কোনো কোয়েরির পরিবর্তে একটি স্থায়ী কিউ-তে পরিণত হয়।
বিল্ডকে ব্যাহত না করে এনপিএম প্যাকেজের দুর্বলতা সমাধান করা
খুঁজে বের করাটা হলো সহজ অর্ধেক। এনপিএম প্যাকেজের দুর্বলতাগুলো মাসের পর মাস অমীমাংসিত থাকার কারণ হলো, সেগুলো ঠিক করার নিজস্ব ঝুঁকি রয়েছে এবং ডেভেলপাররা তা জানেন।
যেকোনো আপগ্রেডের আগে গুরুত্বপূর্ণ প্রশ্নটি এটা নয় যে, “এই প্যাচটি কি CVE-কে আপডেট করবে”। বরং একই সাথে তিনটি প্রশ্ন গুরুত্বপূর্ণ: এই সংস্করণের সাথে কোন দুর্বলতাগুলো দূর হবে, এর সাথে নতুন কোনগুলো আসবে, এবং এই সংস্করণ পরিবর্তনটি কি আমার কোডকে অকার্যকর করে দেবে।
জাইজেনি প্রতিটি ঝুঁকিপূর্ণ ডিপেন্ডেন্সির জন্য তিনটিই দেখায়, ফলে কোনো বড় পদক্ষেপ না নিয়ে দৃশ্যমান বিকল্পগুলোর মধ্যেই থেকে বেছে নিতে হয়। তারপর অটোফিক্স তৈরি করে pull request প্যাচ করা সংস্করণটির মাধ্যমে, বাল্ক রিমিডিয়েশন একবারে একাধিক সমাধান প্রয়োগ করে, এবং জাইজেনি বট চাহিদা অনুযায়ী চলে। pull requests অথবা দৈনিক ভিত্তিতে, ফলে কেউ সময়সূচী নির্ধারণ না করলেও জমে থাকা কাজের পরিমাণ কমে আসে।
ট্রানজিটিভ ডিপেন্ডেন্সির ক্ষেত্রে, যেখানে আপনি নিজে বেছে না নেওয়া কোনো ভার্সনে সরাসরি আপগ্রেড করতে পারেন না, সেখানে কার্যকরী আউটপুট হলো ট্রি-এর মধ্যে থাকা সংক্ষিপ্ততম আপগ্রেড পাথটি, যা অ্যাডভাইজরিটির সমাধান করে; এটি এমন কোনো অ্যালার্ট নয় যা আপনাকে জানায় যে চার লেভেল নিচের কোনো একটি প্যাকেজ ঝুঁকিপূর্ণ।
প্রেরণের পূর্বে: চেকটি কোথায় পাঠানো হবে
“প্রেরণের আগে” হলো সময়সূচী নির্ধারণের একটি দাবি, এবং বিষয়টি তিনটি প্লেসমেন্টের উপর নির্ভর করে।
- IDE-তেফলে একজন ডেভেলপার ডিপেন্ডেন্সি বেছে নেওয়ার সময়েই সমস্যাটি দেখতে পান এবং তখনই এটি পরিবর্তন করা সবচেয়ে সাশ্রয়ী হয়।
- উপরে pull requestযেখানে একটি বট কী পরিবর্তন হয়েছে তা জানিয়ে মন্তব্য করে এবং সমাধানটি উন্মুক্ত করে, এবং যেখানে একটি সিকিউরিটি গেট একটি নির্দিষ্ট সীমার উপরের ত্রুটির জন্য বিল্ডকে ব্যর্থ করে দিতে পারে। শুধুমাত্র তীব্রতার উপর ভিত্তি করে গেটিং করার কারণেই টিমগুলো গেটটি নিষ্ক্রিয় করে দেয়। আর অ্যাক্সেসযোগ্য এবং এক্সপ্লয়েটযোগ্য ত্রুটির উপর ভিত্তি করে গেটিং করার কারণেই তারা এটি চালু রাখে।
- মুক্তির পর ক্রমাগত, কারণ মার্জ করার সময় যে ডিপেন্ডেন্সিটি ঝুঁকিমুক্ত ছিল, কোনো অ্যাডভাইজরি প্রকাশিত হওয়ার দিনই সেটি ঝুঁকিপূর্ণ হয়ে ওঠে। রেজিস্ট্রি জুড়ে নিরবচ্ছিন্ন পর্যবেক্ষণই এটি শনাক্ত করে, যার ফলে কাউকে পুনরায় স্ক্যান করার কথা মনে রাখতে হয় না।
এবং এই তিনটির আউটপুট আপনার আউটপুটের পাশাপাশি একটি অগ্রাধিকারপ্রাপ্ত সারিতে থাকবে। SAST, অন্ধিসন্ধি, এবং কন্টেইনারের ফলাফল, যার মধ্যে আপনার ইতিমধ্যে চালানো টুলগুলো থেকে গৃহীতগুলোও অন্তর্ভুক্ত। দুর্বলতার তালিকা নিজস্ব কনসোলে থাকা তালিকাটি এমন একটি তালিকা, যা সেই কাজের সাথে মনোযোগের জন্য প্রতিযোগিতা করে, যেটিকে তথ্য দেওয়ার জন্য এটি তৈরি হয়েছিল।
সমাধানটি পাঠান, ফলাফলটি নয়।
একটি স্ক্যানার যা আপনাকে ৪০০টি এনপিএম প্যাকেজের দুর্বলতা দেখিয়ে দেয়, সেটি আসল কাজটি করেনি। এটি কেবল কাজটিকে স্থানান্তরিত করেছে।
জাইজেনি পৌঁছানোর যোগ্যতা, দুর্বলতার সম্ভাবনা এবং ব্যবসায়িক প্রেক্ষাপটের ভিত্তিতে নির্ভরতার ফলাফলকে সংকুচিত করে, প্রতিটি আপগ্রেড কী ঠিক করে এবং কী নষ্ট করতে পারে তা দেখায়, এবং উন্মুক্ত করে। pull request প্যাচ করা সংস্করণটি দিয়ে। এটি আপনার মধ্যে চলে। pipeline, উত্পাদন SBOM এবং SPDX ও CycloneDX-এ VDR আউটপুট, যা CRA, NIS2 এবং DORA চায় এমন প্রমাণ, এবং নির্ভরতার ফলাফলগুলোকে আপনার ঝুঁকির বাকি অংশের সাথে একই অগ্রাধিকারপ্রাপ্ত সারিতে রাখে, যার মধ্যে সেইসব স্ক্যানারের ফলাফলও অন্তর্ভুক্ত থাকে যা আপনি প্রতিস্থাপন করছেন না।
বিনামূল্যে শুরু করুন এবং একটি সংগ্রহস্থল স্ক্যান করুন, অথবা দেখুন কীভাবে পৌঁছানোর ক্ষমতা তালিকাটিকে পরিবর্তন করে।.
FAQ
আমি কীভাবে npm প্যাকেজগুলিতে দুর্বলতা পরীক্ষা করব?
চালান npm audit তাৎক্ষণিক পর্যালোচনার জন্য, এরপর রিচেবিলিটি অ্যানালাইসিস সহ একটি টুল ব্যবহার করে তালিকাটিকে সেইসব ফাইন্ডিং-এ সংকুচিত করুন যেখান থেকে ঝুঁকিপূর্ণ কোডটি আসলেই কল করা যায়। OSV এবং GitHub Advisory Database-এর মতো অ্যাডভাইজরি ডেটাবেসগুলো কোনো নির্দিষ্ট প্যাকেজ এবং ভার্সন পরীক্ষা করার জন্য উপযোগী।
Is npm audit fix চালানো কি নিরাপদ?
নন-ফোর্সড সংস্করণটি সাধারণত নিরাপদ, কারণ এটি সেমভার-সামঞ্জস্যপূর্ণ সীমার মধ্যে থাকে। npm audit fix --force বিষয়টা তা নয়: এটি পরামর্শমূলক বার্তাগুলো সমাধান করার জন্য প্রধান সংস্করণগুলো জুড়ে আপগ্রেড করে, এবং সেখান থেকেই ব্রেকিং চেঞ্জগুলো আসে।
আমার এনপিএম প্যাকেজে এতগুলো দুর্বলতা কেন আছে?
কারণ এগুলোর বেশিরভাগই স্থানান্তরযোগ্য। আপনি হাতেগোনা কয়েকটি সরাসরি নির্ভরতা ইনস্টল করেন এবং তার সাথে শত শত পরোক্ষ নির্ভরতা পেয়ে যান, যেগুলোর প্রতিটির নিজস্ব সতর্কতামূলক ইতিহাস থাকে। এই বিপুল পরিমাণ স্বাভাবিক। সমস্যাটা হলো বাছাই করে সঠিকটি বেছে নেওয়ার পদ্ধতির।
রিচেবিলিটি অ্যানালাইসিস বলতে কী বোঝায়?
আপনার অ্যাপ্লিকেশনের এক্সিকিউশন কোনো ডিপেন্ডেন্সির ঝুঁকিপূর্ণ ফাংশন পর্যন্ত পৌঁছাতে পারে কিনা, তা নির্ধারণ করা। ডিপেন্ডেন্সি সুরক্ষার ক্ষেত্রে এটিই সবচেয়ে বড় উপায়, কারণ রিপোর্ট করা বেশিরভাগ দুর্বলতা এমন কোডে থাকে যা আপনার অ্যাপ্লিকেশন কখনও কল করে না।
অগ্রাধিকার নির্ধারণের জন্য আমার কি CVSS নাকি EPSS ব্যবহার করা উচিত?
উভয়ই, তবে ভিন্ন ভিন্ন কাজের জন্য। CVSS বর্ণনা করে যে, কোনো দুর্বলতা কাজে লাগানো হলে তা কতটা গুরুতর হবে। EPSS অনুমান করে যে, আগামী ৩০ দিনের মধ্যে এটি কাজে লাগানোর সম্ভাবনা কতটা। সম্ভাবনা ছাড়া শুধু তীব্রতা জানা থাকলে, একটি সারি ভুল অক্ষ বরাবর সাজানো থাকে।
আমার কত ঘন ঘন npm প্যাকেজগুলিতে দুর্বলতা পরীক্ষা করা উচিত?
একটানা, কোনো নির্দিষ্ট সময়সূচী অনুযায়ী নয়। সোমবারের ক্লিন স্ক্যানের কোনো অর্থই বুধবার থাকে না, যদি আপনার পাঠানো কোনো প্যাকেজে সতর্কতামূলক বার্তা আসে।
