npm update সঙ্গে সঙ্গে নেবেন না—cooldown-ই দেয় যাচাইয়ের সময়

npm প্রকল্পে সদ্য প্রকাশিত dependency সংস্করণ গ্রহণের আগে একটি নির্দিষ্ট অপেক্ষার সময় রাখুন। সেই নিয়ম সরাসরি ও পরোক্ষ dependency-তে প্রয়োগ করুন, বদলানো lockfile পরীক্ষা করুন এবং জরুরি নিরাপত্তা সংশোধনের জন্য অনুমোদিত ব্যতিক্রম রাখুন। শুরুতে তিন দিনের বিরতি একটি নীতির নমুনা; সব প্রকল্পের জন্য প্রমাণিত নিরাপদ মেয়াদ নয়।

এই cooldown-এর লাভ হলো প্রকাশের পর ক্ষতিকর সংস্করণ শনাক্ত বা রিপোর্ট করার জন্য কিছু সময় পাওয়া। Homebrew-এর নিরাপত্তা নির্দেশিকা npm ও pip-সংশ্লিষ্ট আপডেটে এই কারণে বিরতি দেওয়ার কথা বলে, আবার সব ধরনের package-এ নির্বিচার বিরতি জরুরি সংশোধন পৌঁছাতে দেরি করতে পারে বলেও সতর্ক করে। তাই নীতিতে অপেক্ষার মেয়াদের সঙ্গে অপেক্ষা ভাঙার শর্তও লিখতে হবে।

কোন ঝুঁকিতে বিরতি কাজে দেয়

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

npm-এর হুমকি নির্দেশিকা জানায়, npm সদৃশ নামের ক্ষতিকর package শনাক্ত করে প্রকাশ আটকাতে পারে, কিন্তু dependency confusion শনাক্ত করতে পারে না; ব্যক্তিগত package-এর জন্য scoped নাম ব্যবহারের পরামর্শও দেয়। বিদ্যমান package-এ ক্ষতিকর পরিবর্তন খোঁজার ব্যবস্থাও npm-এর আছে। Cooldown এসব ব্যবস্থার পাশে গ্রহণের সময় পিছিয়ে দেয়; এটি নিজে malware scanner নয়।

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

অপেক্ষার মেয়াদ ও পরিধি নির্ধারণ

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

নিয়মটি package.json-এ লেখা সরাসরি dependency-র পাশাপাশি নতুনভাবে নির্ধারিত পরোক্ষ dependency-তেও প্রযোজ্য করুন। একটি পরিচিত package আপডেটের প্রস্তাবে তার অধীন অন্য package-এর সংস্করণ বদলাতে পারে। শুধু ওপরের স্তরের নাম দেখলে সেই পরিবর্তন বাদ পড়ে যাবে; পর্যালোচনার বিষয় হলো প্রস্তাবিত dependency tree এবং তার package-lock.json পরিবর্তন।

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

npm কনফিগারেশন ও CI-তে প্রয়োগ

সমর্থিত npm সংস্করণে প্রকল্পের .npmrc ফাইলে min-release-age=3 রাখা এই নমুনা নীতি প্রয়োগের একটি উপায়। npm CLI v11-এর কনফিগারেশন নথি অনুযায়ী, min-release-age নির্ধারিত দিনের চেয়ে নতুন সংস্করণ বাদ দিয়ে dependency tree তৈরি করে; উপযুক্ত সংস্করণ না থাকলে কমান্ড ব্যর্থ হয়। ব্যবহৃত npm সংস্করণে সেটিংটি সমর্থিত এবং প্রকল্পের কনফিগারেশন কার্যকর কি না যাচাই করে তবেই এর ওপর নির্ভর করুন।

এই ফিল্টার নতুন tree নির্ধারণে সাহায্য করে, কিন্তু আগে তৈরি package-lock.json অনুমোদিত কি না, সেই সিদ্ধান্তের বিকল্প নয়। dependency বদলানো pull request-এ CI দিয়ে আগের ও প্রস্তাবিত lockfile তুলনা করুন। নতুন যুক্ত হওয়া প্রতিটি package–সংস্করণ জোড়ার প্রকাশকাল সংশ্লিষ্ট registry-র তথ্যের সঙ্গে মিলিয়ে দেখুন; অপেক্ষার সময় পূর্ণ না হলে পরিবর্তন আটকে দিন। কোন registry-র তথ্য দিয়ে সিদ্ধান্ত হয়েছে, সেটিও পরীক্ষার ফল থেকে বোঝা উচিত।

বয়স পরীক্ষা পেরোনোর পর প্রস্তাবিত lockfile থেকে npm ci চালিয়ে প্রকল্পের প্রাসঙ্গিক পরীক্ষা করুন। পর্যালোচকের জন্য পরিবর্তনের সারাংশে সরাসরি package, নতুন পরোক্ষ package, উৎস এবং install script-সংক্রান্ত পরিবর্তন আলাদা করে দেখান; প্রয়োজন হলে আসল lockfile diff খুলে মিলিয়ে নিন। আপডেট বটের pull request-ও একই CI শর্ত পার হবে। স্বয়ংক্রিয়ভাবে প্রস্তাব এসেছে বলে সংস্করণটি অনুমোদিত হয়ে যায় না।

জরুরি সংশোধনে ছাড়ের সীমা

প্রকল্পে প্রযোজ্য কোনো দুর্বলতার সংশোধন অপেক্ষার সময়ের মধ্যেই প্রকাশিত হলে বিলম্বের ক্ষতি নতুন সংস্করণ গ্রহণের ঝুঁকির চেয়ে বেশি হতে পারে। npm-এর বয়সসীমা npm audit fix-কে নতুন সংশোধিত সংস্করণ নিতে বাধা দিলে কমান্ড সতর্ক করে ব্যর্থ হতে পারে। তাই জরুরি ছাড়ের সিদ্ধান্ত security owner ও সংশ্লিষ্ট service owner-কে নিতে দিন; কোনো ব্যর্থ CI পরীক্ষা নীরবে উপেক্ষা করার নিয়ম রাখবেন না।

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

min-release-age-exclude[] package-এর নাম বা নামের ধরন ধরে বয়সসীমা থেকে ছাড় দেয়; একটি নাম স্থায়ীভাবে রেখে দিলে তার পরের সংস্করণও ছাড় পেতে পারে। তাই জরুরি patch-এর জন্য সাময়িক ছাড় ব্যবহার করে কাজ শেষে সেটি সরান। CI-র অনুমোদন রেকর্ডে নির্দিষ্ট সংস্করণ ও মেয়াদ রাখলে পরবর্তী প্রকাশ আগের সিদ্ধান্তের আড়ালে চলে যাওয়ার ঝুঁকি কমে। কেবল পরিচিত নাম বলেই তৃতীয় পক্ষের package-কে স্থায়ী allowlist-এ রাখবেন না।

দলের জন্য সংক্ষিপ্ত নীতির নমুনা

নিচের নমুনায় অপেক্ষা, মালিকানা ও ব্যতিক্রমের সিদ্ধান্ত এক জায়গায় আছে। প্রকল্পের ঝুঁকি এবং ব্যবহৃত npm সংস্করণ অনুযায়ী মেয়াদ ও দায়িত্ব বদলান।

• স্বাভাবিক নিয়ম: registry-তে প্রকাশের পর তিন দিন পূর্ণ না হওয়া নতুন dependency সংস্করণ গ্রহণ করা হবে না। সরাসরি ও পরোক্ষ—উভয় ধরনের নতুন সংস্করণ এই নিয়মের আওতায় থাকবে।
• প্রয়োগ: সমর্থিত npm সংস্করণে প্রকল্পের .npmrc-তে min-release-age=3 থাকবে। dependency বদলানো pull request-এ CI নতুন lockfile entry-র প্রকাশকাল পরীক্ষা করবে; অনুমোদিত lockfile দিয়ে npm ci ও প্রাসঙ্গিক পরীক্ষা চলবে।
• পর্যালোচনা: নির্ধারিত maintainer পরিবর্তিত package-এর নাম, সংস্করণ, registry, পরোক্ষ dependency ও install script-সংক্রান্ত পরিবর্তন দেখবেন। সন্দেহজনক পরিবর্তন security owner-এর কাছে যাবে।
• জরুরি ছাড়: প্রযোজ্য নিরাপত্তা সংশোধনের জন্য service owner ও security owner নির্দিষ্ট সংস্করণ অনুমোদন করবেন। কারণ, পরীক্ষার ফল, দায়িত্বশীল ব্যক্তি, ছাড়ের মেয়াদ ও সেটি প্রত্যাহারের শর্ত একই রেকর্ডে থাকবে।
• নিয়মিত ছাড়: নিজ দলের নিয়ন্ত্রিত package-এর প্রয়োজন হলে সংকীর্ণ allowlist রাখা যাবে। তার scope ও registry-র নিয়ন্ত্রণ নিশ্চিত করতে হবে; নামের ছাড় তার পরোক্ষ dependency-কে স্বয়ংক্রিয় ছাড় দেবে না।

এই নীতিতে cooldown একটি সিদ্ধান্ত নেওয়ার সময় তৈরি করে, নিরাপত্তার সনদ দেয় না। নিয়মিত আপডেট কেন অপেক্ষা করছে এবং জরুরি সংশোধন কার অনুমোদনে এগোবে—দুটিই lockfile পরীক্ষা ও সিদ্ধান্তের নথিতে স্পষ্ট থাকলে বিরতিটি দলের কাজে অর্থবহ হয়।

আরও পড়ুন:

• npm token চুরি হলেও package সরাসরি প্রকাশ নয়—stage-only পথের সীমাও আছে
• npm package-এ ১০টি trusted publisher—একটি মিললেই release অনুমোদিত
• Amazon Quick agent production-এ নেবেন? Prompt নয়, dataset-এই access কাটুন