আপনি যখন npm i -s চালান তখন আসলে কী ঘটে
আপনি যখন টাইপ করুন npm i -sআপনি শুধু একটি ডিপেন্ডেন্সি ইনস্টল করার চেয়েও বেশি কিছু করছেন; আপনি আপনার প্রোজেক্টের সাপ্লাই চেইন পরিবর্তন করছেন। সার্জারির -s পতাকা মানে সংক্ষিপ্ত রূপ -সংরক্ষণnpm i -s অথবা npm install –save চালালে একটি প্যাকেজ ইনস্টল হয় এবং তা রেকর্ড হয়ে যায়। নির্ভরতা আপনার বিভাগ package.jsonসেই মুহূর্ত থেকে, যে পরিবেশে চলে npm ইনস্টল করুন সেই একই ডিপেন্ডেন্সিটি ডাউনলোড করবে।
উদাহরণ:
# Adds express to dependencies npm i -s express এটা সুবিধাজনক, কিন্তু এটি স্থায়ীও বটে। যদি প্যাকেজের উৎস যাচাই করা না হয়, অথবা যদি ডিপেন্ডেন্সি ট্রি-তে অবিশ্বস্ত প্যাকেজ অন্তর্ভুক্ত থাকে, তাহলে আপনি কার্যকরভাবে একটি সম্ভাব্য আক্রমণের পথকে স্থায়ী করে ফেলেন, যা প্রতিটি বিল্ড, প্রতিটি এনভায়রনমেন্ট এবং প্রতিটি ডেভেলপার মেশিনের মধ্য দিয়ে প্রবাহিত হয়। যাচাই না করা প্যাকেজগুলিতে থাকতে পারে:
- লুকানো নেটওয়ার্ক কলব্যাক
- ডেটা এক্সফিলট্রেশন কোড
- ইনস্টলেশন-পরবর্তী স্ক্রিপ্ট যা স্বয়ংক্রিয়ভাবে চলে
`npm i -s` কমান্ডটি নিজে থেকে বিপজ্জনক নয়, কিন্তু এটি কী এবং কোথা থেকে ইনস্টল করে, তা এমন ক্ষতিকর npm প্যাকেজগুলোর প্রবেশের পথ খুলে দিতে পারে যা নীরবে আপনার প্রোজেক্টের ক্ষতি করে।
আক্রমণকারীরা কীভাবে ক্ষতিকারক প্যাকেজ সরবরাহ করতে npm-কে কাজে লাগায়
আক্রমণকারীরা npm পছন্দ করে, কারণ এটি আধুনিক অ্যাপ্লিকেশন ডেভেলপমেন্টের কেন্দ্রবিন্দুতে রয়েছে। যখনই কোনো ডেভেলপার `npm install –save` কমান্ডটি চালান, তখনই নিরাপত্তা লঙ্ঘনের একটি সুযোগ তৈরি হয়, যদি ডিপেন্ডেন্সি সোর্সগুলো সতর্কতার সাথে যাচাই করা না হয়।
সাধারণ আক্রমণের মাধ্যম
- টাইপস্কোটিং: আক্রমণকারীরা জনপ্রিয় প্যাকেজগুলোর নামের অনুরূপ নাম ব্যবহার করে প্যাকেজ প্রকাশ করে। উদাহরণ: ইনস্টল করা প্রকাশ করা পরিবর্তে প্রকাশ করা npm i -s এর মাধ্যমে, অতিরিক্ত “s” অক্ষরটি একটি ট্রোজান প্যাকেজ লোড করে।
- নির্ভরশীলতার বিভ্রান্তি: একটি ব্যক্তিগত নির্ভরতা যেমন @internal/api-client একই নামের কোনো পাবলিক এনপিএম প্যাকেজের কারণে এটি আড়ালে পড়ে যেতে পারে।
কোনো ডেভেলপার যখন npm i -s @internal/api-client কমান্ডটি চালান, তখন এর পরিবর্তে ক্ষতিকর পাবলিক ভার্সনটি ইনস্টল হয়ে যায়। - আপোসকৃত রক্ষণাবেক্ষণকারী: আক্রমণকারীরা বৈধ অ্যাকাউন্ট হাইজ্যাক করে অথবা বিশ্বস্ত প্রজেক্টে ক্ষতিকারক কোড প্রবেশ করিয়ে দেয়, যার ফলে একটি পরিচিত ডিপেন্ডেন্সি সংক্রমণের বাহকে পরিণত হয়।
ক্ষতিকারক ইনজেকশনের উদাহরণ:
❌ ক্ষতিকর ডিপেন্ডেন্সি স্নিপেটের উদাহরণ
postinstall: node exfiltrate-secrets.jsএমনকি বড় বড় প্রতিষ্ঠানগুলোও ছড়িয়ে পড়া npm ক্ষতিকারক প্যাকেজের শিকার হয়েছে। standard npm install –save কমান্ড। আক্রমণকারীরা ট্রাস্ট চেইনের সুযোগ নেয় এবং ক্রেডেনশিয়াল বা ডেটা ফাঁস হতে শুরু না করা পর্যন্ত ডেভেলপাররা তা খুব কমই খেয়াল করেন।
ইনস্টল স্ক্রিপ্ট এবং পোস্ট-ইনস্টলের নীরব হুমকি Hooks – npm i -s
এনপিএম ইকোসিস্টেম প্যাকেজগুলিকে লাইফসাইকেল স্ক্রিপ্ট চালানোর অনুমতি দেয়, যেমন ইনস্টল or পোস্টইনস্টল স্বয়ংক্রিয়ভাবে। এটি বাইনারি তৈরির জন্য উপযোগী, কিন্তু এটি অপব্যবহারের একটি খোলা সুযোগও বটে। যখন আপনি npm i -s অথবা npm install –save চালান, npm কোনো নিশ্চিতকরণ না চেয়েই স্বয়ংক্রিয়ভাবে এই স্ক্রিপ্টগুলো কার্যকর করে। ক্ষতিকারক নির্ভরতা এই আচরণটি ব্যবহার করতে পারেন:
- সিস্টেম কমান্ড চালু করুন
- স্থানীয় পরিবেশে ব্যাকডোর তৈরি করুন
- SSH কী, টোকেন বা এনভায়রনমেন্ট ভেরিয়েবল চুরি করুন
উদাহরণ (অক্ষতিকর নয় কিন্তু ঝুঁকিপূর্ণ আচরণ):
"scripts": { "postinstall": "node ./scripts/setup.js" } If setup.js যদি আপস্ট্রিম থেকে এটি প্রতিস্থাপন বা পরিবর্তন করা হয়, তাহলে আপনার সিস্টেম ইনস্টলেশনের সময় নীরবে আক্রমণকারী-নিয়ন্ত্রিত কোড চালাতে পারে। In CI/CD pipelines, যেখানে npm i -s বিল্ড চলাকালীন এটি স্বয়ংক্রিয়ভাবে চলে বলে এই ঝুঁকি আরও বেড়ে যায়। একটিমাত্র npm ক্ষতিকারক প্যাকেজ বিল্ড এজেন্টকে ক্ষতিগ্রস্ত করতে, এনভায়রনমেন্টের গোপনীয় তথ্য পাচার করতে, অথবা ডিপ্লয়মেন্ট আর্টিফ্যাক্টসে হস্তক্ষেপ করতে পারে।
npm i -s এর সাথে কেন ম্যানুয়াল প্যাকেজ রিভিউ যথেষ্ট নয়
ডেভেলপাররা প্রায়শই বিশ্বাস করেন যে একটি পরীক্ষা করা package.json ফাইল দেখা বা কোনো রিপোজিটরির README পড়া নিরাপত্তা নিশ্চিত করে। আসলে তা করে না। একটিমাত্র 'npm install –save' কমান্ডের মাধ্যমে কয়েক ডজন, এমনকি কখনও কখনও শত শত, ট্রানজিটিভ ডিপেন্ডেন্সি ইনস্টল হয়ে যেতে পারে। এগুলোর প্রত্যেকটি আপনার টপ-লেভেল ডিপেন্ডেন্সিতে দৃশ্যমান না হয়েই বিভিন্ন দুর্বলতা বা ক্ষতিকারক কোড যুক্ত করতে পারে।
বাস্তব-জগতের সমস্যা: নির্ভরশীলতার বিস্তার
২০টি সরাসরি নির্ভরতাযুক্ত একটি প্রকল্পে সহজেই ৫০০টিরও বেশি পরোক্ষ নির্ভরতা তৈরি হতে পারে। এগুলো হাতে-কলমে পর্যালোচনা করা অসম্ভব। আক্রমণকারীরা এই জটিলতার সুযোগ নিয়ে npm-এর ক্ষতিকারক প্যাকেজগুলোকে সিস্টেম ট্রি-র গভীরে লুকিয়ে রাখে।
নিরাপদ নির্ভরতা ব্যবহারের জন্য সংক্ষিপ্ত চেকলিস্ট
- ব্যবহার npm অডিট এবং এনপিএম এলএস লুকানো নির্ভরতা শনাক্ত করতে।
- npm i -s চালানোর আগে প্যাকেজের লেখক এবং সর্বশেষ আপডেটের তারিখ পর্যালোচনা করুন।
- যাচাইবিহীন ইউআরএল বা গিট রিপো থেকে ইনস্টল করা থেকে বিরত থাকুন।
- সন্দেহজনক স্ক্রিপ্টগুলির জন্য পরীক্ষা করুন (ইনস্টল, প্রস্তুত করা, পোস্টইনস্টল) মধ্যে package.json.
- লক সংস্করণ ব্যবহার করে প্যাকেজ-lock.json এবং স্বাক্ষর যাচাইকরণ সক্ষম করুন।
ম্যানুয়াল পর্যালোচনা একটি সূচনা মাত্র, কিন্তু প্রকৃত সুরক্ষার জন্য স্বয়ংক্রিয়করণ অপরিহার্য।
নির্ভরতা স্ক্যানিং এবং নীতি নিয়ন্ত্রণ একীভূত করা CI/CD
আধুনিক ডেভসেকওপস pipelines প্রতিটি 'npm i -s' কমান্ডকে npm-এর ক্ষতিকর প্যাকেজ প্রবেশের একটি সম্ভাব্য পথ হিসেবে বিবেচনা করতে হবে। ডিপেন্ডেন্সি স্ক্যানিং ঐচ্ছিক নয়; এটি আপনার বিল্ড হাইজিনের একটি অংশ।
অটোমেশন কৌশল
- স্থির নির্ভরতা স্ক্যানিং: বিল্ড পর্যায়ের আগে পরিচিত ক্ষতিকারক বা ঝুঁকিপূর্ণ প্যাকেজ আছে কিনা তা পরীক্ষা করতে স্বয়ংক্রিয় স্ক্যানার ব্যবহার করুন।
- স্বাক্ষর যাচাইকরণ: হ্যাশ তুলনা অথবা স্বাক্ষরিত মেটাডেটার মাধ্যমে প্যাকেজের অখণ্ডতা যাচাই করুন।
- নীতি প্রয়োগ: যাচাইবিহীন উৎস থেকে ইনস্টলেশন প্রতিরোধ করুন।
উদাহরণ pipeline কনফিগারেশন:
security-scan: script: - xygeni scan --dependencies --npm --detect-malicious - xygeni enforce --policy supplychain.yaml এটিকে আপনার মধ্যে একীভূত করা CI/CD প্রতিটি npm install –save কমান্ডের বৈধতা যাচাই করা নিশ্চিত করা হয়। যে কোনো প্যাকেজ যা নীতিমালা মেনে চলে না, স্বাক্ষরবিহীন, অজানা বা ঝুঁকিপূর্ণ, তা স্বয়ংক্রিয়ভাবে ব্লক হয়ে যায়। এটি শুধু বিল্ড সিস্টেমকেই সুরক্ষিত রাখে না, বরং প্রোডাকশন এনভায়রনমেন্টে পরবর্তী পর্যায়ের দূষণও প্রতিরোধ করে।
একটি বিশ্বস্ত সাপ্লাই চেইন গড়ে তোলা: এনপিএম থেকে প্রোডাকশন পর্যন্ত
নিরাপত্তা শুধু ইনস্টলের সময়েই শেষ হয়ে যায় না। প্রতিটি npm i -s কমান্ড আপনার সফটওয়্যার সাপ্লাই চেইনে অবদান রাখে, এবং যদি এটি যাচাই করা না হয়, তবে তা একটি ঝুঁকি।
শুরু থেকে শেষ পর্যন্ত আস্থা তৈরি করতে:
- জেনারেট করুন SBOMs (সফটওয়্যার বিল অফ মেটেরিয়ালস)প্রতিটি প্যাকেজের সংস্করণ ও উৎস ট্র্যাক করুন।
- স্বাক্ষরিত অনুমতিপত্র ব্যবহার করুন: প্রামাণিকতা নিশ্চিত করতে প্যাকেজে স্বাক্ষর করা বা স্বাক্ষর যাচাই করার পদ্ধতি গ্রহণ করুন।
- প্রতিটি পর্যায়ে যাচাই করুন: শুধু CI-তেই নয়, বরং ডেপ্লয়মেন্ট এবং রানটাইমের সময়েও ইন্টিগ্রিটি চেক প্রয়োগ করুন।
- বিচ্ছিন্ন নির্মাণ: অননুমোদিত নেটওয়ার্ক বা ফাইল অ্যাক্সেস রোধ করতে স্যান্ডবক্সে ইনস্টলেশন চালান।
এপিআই পরিবেশের জন্য নিরাপদ কুকি কনফিগারেশনের উদাহরণ, যা প্রায়শই সংক্রামিত ডিপেন্ডেন্সির মাধ্যমে প্রকাশ পায়:
সুরক্ষিত সংস্করণটি ডাউনলোড, যাচাই এবং তারপর কার্যকর করুন।
# ✅ Secure cookie setup Set-Cookie: sessionid=abc123; HttpOnly; Secure; SameSite=Strict এই ব্যবস্থাগুলো, স্বয়ংক্রিয় ডিপেন্ডেন্সি স্ক্যানিংয়ের সাথে মিলিত হয়ে, আপনার সাপ্লাই চেইনে ছড়িয়ে পড়ার আগেই npm-এর ক্ষতিকর প্যাকেজগুলোকে নিষ্ক্রিয় করতে পারে।
উপসংহার: আপনার এনপিএম ইনস্টলগুলো সুরক্ষিত করুন, তার আগেই যেন তারা আপনাকে সুরক্ষিত করে ফেলে।
প্রতিটি npm i -s বা npm install –save কমান্ড শুধু কার্যকারিতাই যোগ করে না, এটি বিশ্বাসও তৈরি করে। আর যাচাই ছাড়া বিশ্বাস একটি ঝুঁকি।
আপনার সফটওয়্যার সরবরাহ শৃঙ্খল সুরক্ষিত রাখতে:
- নির্ভরতা যাচাইকরণ স্বয়ংক্রিয় করুন
- স্বাক্ষর এবং অখণ্ডতা যাচাইকরণ বাধ্যতামূলক করুন
- npm-এর ক্ষতিকর প্যাকেজগুলির জন্য ক্রমাগত স্ক্যান করুন।
- আপনার প্রাথমিক পর্যায়েই যাচাইবিহীন উৎসগুলো ব্লক করুন। CI/CD
জাইজেনি এটি DevSecOps টিমকে ক্ষতিকর npm ডিপেন্ডেন্সি শনাক্ত ও ব্লক করতে, প্যাকেজ পলিসি প্রয়োগ করতে এবং বিল্ড ইন্টিগ্রিটি নিরীক্ষণ করতে সাহায্য করে, যা নিশ্চিত করে যে আপনি যা ইনস্টল করছেন, তা-ই আপনি চালাতে চান।
কারণ সরবরাহ শৃঙ্খল সুরক্ষায়, প্রতিরোধ কোনো নির্মাণ ধাপ নয়; এটিই ভিত্তি।
