এনপিএম সিকিউরিটি অডিটিং এবং সাপ্লাই-চেইন আক্রমণের জন্য গভীর নির্দেশিকা

হোম » পাইথন » এনপিএম সিকিউরিটি অডিটিং এবং সাপ্লাই-চেইন আক্রমণের জন্য গভীর নির্দেশিকা

আজ যদি আপনি Node.js অথবা TypeScript দিয়ে কিছু তৈরি করেন, তাহলে আপনি npm নির্ভরতার এক বিশাল স্তূপের উপরে দাঁড়িয়ে আছেন যা আপনি লেখেননি এবং সম্ভবত কখনও সম্পূর্ণরূপে পড়তেও পারবেন না। এটি দ্রুত ফিচার সরবরাহের জন্য অবিশ্বাস্যভাবে সুবিধাজনক, তবে এটি সরবরাহ শৃঙ্খলের হুমকি, শংসাপত্র চুরি এবং আপনার অ্যাপস বা CI/CD পাইপলাইনে সূক্ষ্ম ব্যাকডোর দিয়ে প্রবেশের জন্য একটি বিশাল আক্রমণের পৃষ্ঠও খুলে দেয়।

আধুনিক এনপিএম নিরাপত্তা এখন আর কেবল "আমার প্যাকেজগুলিতে কি পরিচিত সিভিই আছে?" সম্পর্কে নয় - এটি সম্পর্কে রক্ষণাবেক্ষণকারী অ্যাকাউন্ট হাইজ্যাক করে এমন ফিশিং প্রচারণার বিরুদ্ধে প্রতিরক্ষা করা, সংক্রামিত সংস্করণগুলি স্বয়ংক্রিয়ভাবে প্রকাশ করে এমন কীট এবং ক্ষতিকারক লাইব্রেরি যা কোনও বিকাশকারীর home ডিরেক্টরি অথবা ক্লাউড শংসাপত্র চুরি করুন। এই নির্দেশিকায় আমরা কীভাবে আনপ্যাক করব তা আনপ্যাক করব এনপিএম নিরাপত্তা নিরীক্ষা কাজ করে, কীভাবে আপনার কর্মপ্রবাহকে শক্ত করা যায় যেমন সরঞ্জামগুলি দিয়ে npm audit, Dependabot, SAST/SCA স্ক্যানার এবং CI/CD চেক, এবং "এই ছোট্ট লাইব্রেরিটি ম্যালওয়্যার হতে পারে" এই আশঙ্কায় একজন ডেভেলপার হিসেবে আপনি বাস্তবসম্মতভাবে কী করতে পারেন।

কেন npm নির্ভরতা নিরাপত্তা এত বড় বিষয়?

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

দুর্বল বা পরিত্যক্ত নির্ভরতা ক্লাসিক নিরাপত্তা সমস্যাগুলির দিকে পরিচালিত করতে পারে যেমন ইনজেকশন আক্রমণ, পরিষেবা অস্বীকার (DoS), বিশেষাধিকার বৃদ্ধি অথবা ডেটা এক্সফিল্ট্রেশন। এমনকি একটি নিম্ন-স্তরের ইউটিলিটিতে একটি ছোট বাগ - একটি HTTP ক্লায়েন্ট, একটি রঙ পার্সার, একটি YAML লোডার - যখন এটি জনপ্রিয় ফ্রেমওয়ার্ক এবং সরঞ্জামগুলির নীচে থাকে তখন ব্যাপক প্রভাব ফেলতে পারে।

ঐতিহ্যবাহী দুর্বলতার বাইরে, বাস্তুতন্ত্রকে এখন সরাসরি দূষিত আচরণ মোকাবেলা করতে হবে: গোপন তথ্য চুরি করার জন্য ইচ্ছাকৃতভাবে তৈরি করা প্যাকেজগুলি, ক্রিপ্টোমাইনিং কোড ইনজেক্ট করা অথবা CI/CD পাইপলাইনের সাথে আপস করা। এগুলো তাত্ত্বিক ঝুঁকি নয়; বাস্তব জগতের একাধিক ঘটনায় দেখা গেছে যে আক্রমণকারীরা রক্ষণাবেক্ষণকারী অ্যাকাউন্টের পিছনে ছুটছে এবং তারপর বিশ্বস্ত প্যাকেজগুলিকে অস্ত্র হিসেবে ব্যবহার করছে।

নির্ভরতা নিরীক্ষিত এবং হালনাগাদ রাখা অতএব, এটি স্বাস্থ্যবিধি মেনে চলার জন্য উপযুক্ত কাজ নয়, বরং যেকোনো গুরুতর Node.js বা TypeScript প্রকল্প বজায় রাখার একটি মূল অংশ। নিয়মিত নিরাপত্তা অডিট, স্বয়ংক্রিয় এবং ম্যানুয়াল উভয়ই, তৃতীয় পক্ষের কোড থেকে ঝুঁকি গ্রহণযোগ্য পর্যায়ে রাখার একমাত্র উপায়।

এনপিএম অডিট এবং এটি আসলে কী পরীক্ষা করে তা বোঝা

npm audit হল অন্তর্নির্মিত কমান্ড যা আপনার প্রকল্পের নির্ভরতা ট্রিকে পরিচিত দুর্বলতার ডাটাবেসের বিরুদ্ধে স্ক্যান করে এবং একটি নিরাপত্তা প্রতিবেদন তৈরি করে। যখন আপনি এটি আপনার প্রকল্পের রুটে চালান, তখন npm আপনার package.json এবং লক ফাইল, সম্পূর্ণ নির্ভরতা গ্রাফ তৈরি করে এবং প্রতিটি সংস্করণকে পরামর্শের সাথে মেলায়।

নিরীক্ষা প্রতিবেদনে উভয়ই অন্তর্ভুক্ত রয়েছে প্রত্যক্ষ এবং পরোক্ষ নির্ভরতা (আপনার নিজের তালিকাভুক্ত প্যাকেজ এবং নির্ভরতার নির্ভরতা)। প্রতিটি সমস্যার জন্য, এটি প্রভাবিত প্যাকেজ, দুর্বলতার সারসংক্ষেপ, এর তীব্রতা (নিম্ন, মাঝারি, উচ্চ, সমালোচনামূলক) এবং সমাধান ধারণকারী সংস্করণ পরিসর তালিকাভুক্ত করে।

কর্মপ্রবাহের দৃষ্টিকোণ থেকে, npm audit ইন্টারেক্টিভভাবে ব্যবহার করা যেতে পারে ডেভেলপারদের দ্বারা এবং CI/CD পাইপলাইনে অ-ইন্টারেক্টিভভাবে। পাইপলাইনে আপনি এমনকি বিল্ডটি ব্যর্থ করতে পারেন যদি দুর্বলতাগুলি একটি নির্দিষ্ট তীব্রতার সীমার উপরে থাকে যেমন ফ্ল্যাগ ব্যবহার করে --audit-level.

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

কীভাবে npm অডিট চালাবেন এবং ফলাফল ব্যাখ্যা করবেন

একটি মৌলিক নিরাপত্তা নিরীক্ষা সম্পাদন করতে, আপনার প্রকল্পের রুটে একটি টার্মিনাল খুলুন (যেখানে package.json বাঁচে) এবং দৌড়ায় npm audit. একটি সংক্ষিপ্ত নির্ভরতা বিশ্লেষণের পর, npm সমস্যাগুলির একটি সারণী আউটপুট করবে, তীব্রতা অনুসারে গোষ্ঠীভুক্ত, এবং প্রস্তাবিত প্রতিকার পদক্ষেপ যেমন একটি প্যাচড সংস্করণে আপগ্রেড করা।

অডিট আউটপুটে সাধারণত প্যাকেজের নাম, ইনস্টল করা সংস্করণ, দুর্বলতার বিবরণ এবং তীব্রতা (নিম্ন, মাঝারি, উচ্চ, গুরুতর), এবং নির্ভরতা ট্রিতে প্যাকেজটি কোথায় ব্যবহৃত হচ্ছে তা দেখানো পাথ এবং একটি প্রস্তাবিত স্থির সংস্করণ বা পরিসর। এটিকে একটি অগ্রাধিকারপ্রাপ্ত করণীয় তালিকার মতো বিবেচনা করুন: critical এবং high দিয়ে শুরু করুন, তারপর নীচের দিকে কাজ করুন।

যদি আপনি ফলাফলগুলি অন্য টুলে প্রবেশ করতে চান বা পরে সংরক্ষণ করতে চান, তাহলে আপনি JSON আউটপুট চাইতে পারেন npm audit --json। কাস্টম ড্যাশবোর্ড, টিকিটিং সিস্টেম বা নিরাপত্তা অর্কেস্ট্রেশন প্ল্যাটফর্মের সাথে একীভূত করার সময় এটি বিশেষভাবে কার্যকর।

CI/CD পাইপলাইনে, অনেক দল পাইপলাইনটি চালানোর জন্য কনফিগার করে npm audit --json নির্ভরতা ইনস্টল করার পরপরই, ফলাফল বিশ্লেষণ করুন এবং নির্বাচিত তীব্রতার চেয়ে বেশি কোনও দুর্বলতা উপস্থিত থাকলে বিল্ডটি ব্যর্থ করুন। বহিরাগত সাহায্যকারীরা পছন্দ করেন audit-ci আপনার জন্য এই যুক্তিটি মোড়ানো এবং থ্রেশহোল্ড অতিক্রম করলে বিল্ড ভাঙার সুবিধাজনক বিকল্প প্রদান করতে পারে।

npm অডিট ফিক্সের মাধ্যমে দুর্বলতাগুলি ঠিক করা

একদা npm audit পতাকা সমস্যা, আপনার প্রতিরক্ষার প্রথম লাইন হল npm audit fix, যা স্বয়ংক্রিয়ভাবে দুর্বল নির্ভরতাগুলিকে নিকটতম নিরাপদ সংস্করণে আপগ্রেড করার চেষ্টা করে। হুডের নীচে এটি পুনর্লিখন করে package-lock.json (এবং package.json (যেখানে প্রযোজ্য) সামঞ্জস্যপূর্ণ সংস্করণ পরিসরের মধ্যে প্যাকেজগুলিকে বাম্প করতে।

এই স্বয়ংক্রিয় প্রতিকার অনেক কম এবং মাঝারি সমস্যার জন্য ভালো কাজ করে, এমনকি কিছু উচ্চতর তীব্রতার ক্ষেত্রেও যেখানে সমাধানটি সামান্য বা প্যাচ রিলিজ। এটি একটি দ্রুত জয় যা প্রায়শই ন্যূনতম মানব প্রচেষ্টার মাধ্যমে আপনার ব্যাকলগের একটি বড় অংশ পরিষ্কার করে।

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

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

ফাইল লক, npm ci এবং ডিটারমিনিস্টিক ইনস্টল

সার্জারির package-lock.json ফাইল (বা yarn.lock/pnpm-lock.yaml অন্যান্য পরিচালকদের জন্য) নিরাপত্তার জন্য অত্যন্ত গুরুত্বপূর্ণ কারণ এটি আপনার প্রকল্পে ব্যবহৃত প্রতিটি নির্ভরতার সঠিক সংস্করণগুলিকে পিন করে। এটি ছাড়া, প্রতিটি npm install সামান্য ভিন্ন সামঞ্জস্যপূর্ণ সংস্করণ তৈরি করতে পারে, যার ফলে বিল্ডগুলি অ-নির্ধারণী এবং নিরীক্ষণ করা কঠিন হয়ে পড়ে।

আপনার সম্পাদনা করা এড়ানো উচিত package-lock.json হাতে হাতে এবং পরিবর্তে npm কে নির্ভরতা যোগ, অপসারণ বা আপডেট করার সময় এটি পরিচালনা করতে দিন। কোড কমিট করার সময়, সর্বদা উভয়ই অন্তর্ভুক্ত করুন package.json এবং লক ফাইলটি যাতে সবাই - এবং আপনার CI/CD - একই সংস্করণ ইনস্টল করে।

স্বয়ংক্রিয় পরিবেশে, পছন্দ করুন npm ci শেষ npm install কারণ npm ci লক ফাইলটিকে একটি কঠোর চুক্তি হিসেবে ব্যবহার করে এবং ঘোষিত নির্ভরতার সাথে মেলে না গেলে এটি চালানোর অনুমতি দেয় না। এটি দ্রুত এবং সম্পূর্ণরূপে পুনরুৎপাদনযোগ্য ইনস্টলেশন প্রদান করে, যা আপনি CI তে ঠিক তাই চান।

সাপ্লাই-চেইন নিরাপত্তার দৃষ্টিকোণ থেকে, ইনস্টলগুলি লক করা এবং পুনরুৎপাদন করার অর্থ হল আপনি ঠিক জানেন যে কোনও নির্দিষ্ট বিল্ডের জন্য কোন সংস্করণগুলি ব্যবহার করা হয়েছিল, যা আপনার পাইপলাইনে কোনও ক্ষতিকারক রিলিজ টানা হয়েছে কিনা তা তদন্ত করার সময় গুরুত্বপূর্ণ। প্রয়োজনে, আপনি ঐতিহাসিক লক ফাইল ব্যবহার করে বিল্ডগুলি পুনরায় খেলতে পারেন যাতে দেখা যায় যে কোনও দুর্বল বা ব্যাকডোরড সংস্করণ চলছে কিনা।

Dependabot, Renovate এবং npm টুলিং ব্যবহার করে স্বয়ংক্রিয় আপডেট করা

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

উদাহরণস্বরূপ, GitHub-এর Dependabot একটি মাধ্যমে কনফিগার করা হয়েছে .github/dependabot.yml কোন ইকোসিস্টেমগুলি পর্যবেক্ষণ করতে হবে, ফ্রিকোয়েন্সি আপডেট করতে হবে এবং শাখাগুলিকে লক্ষ্য করতে হবে তা নির্দিষ্ট করে এমন ফাইল। যখন এটি একটি দুর্বল বা পুরানো npm প্যাকেজ সনাক্ত করে, তখন এটি একটি PR আপডেটিং তৈরি করে package.json এবং package-lock.json, প্রায়শই পরামর্শের লিঙ্ক সহ।

সঙ্গে জোটবদ্ধ npm audit, আপনি একটি চমৎকার প্রতিক্রিয়া লুপ পাবেন: অডিট সমস্যাগুলি সনাক্ত করে, এবং Dependabot (অথবা Renovate) ক্রমাগত সেগুলি সংশোধন করার জন্য আপগ্রেড প্রস্তাব করে। আপনার কাজ হল প্রতিটি সংস্করণের বাম্প হাতে হাতে খুঁজে বের করার পরিবর্তে এই পুল অনুরোধগুলি পর্যালোচনা এবং পরীক্ষা করা।

অটোমেশনের বাইরে, npm নিজেই সহায়ক কমান্ড প্রদান করে যেমন npm outdated নতুন সংস্করণ সহ প্যাকেজ তালিকাভুক্ত করতে এবং npm update অনুমোদিত সংস্করণ পরিসরের মধ্যে আপগ্রেড করতে। নিয়মিত ব্যবহার করলে, এগুলি আপনার অনেক পিছিয়ে পড়ার এবং একসাথে বেশ কয়েকটি প্রধান সংস্করণ থেকে লাফ দেওয়ার সম্ভাবনা কমায়।

CI/CD পাইপলাইনে নিরাপত্তা পরীক্ষা চালানো

একটি নিরাপদ npm সেটআপ আপনার ল্যাপটপের মধ্যেই সীমাবদ্ধ থাকে না; আপনার CI/CD পাইপলাইনগুলিকে সুরক্ষা পরীক্ষাও প্রয়োগ করতে হবে যাতে দুর্বল বা ক্ষতিকারক কোড উৎপাদনে পৌঁছাতে না পারে। প্রতিটি পর্যায়ে - উৎস, নির্মাণ, পরীক্ষা, স্থাপন - প্রাসঙ্গিক নিয়ন্ত্রণ থাকা উচিত।

দৌড়ানো সাধারণ ব্যাপার। npm audit বিল্ড বা প্রাক-স্থাপনার পর্যায়ে স্বয়ংক্রিয়ভাবে, প্রায়শই --json মনিটরিং টুলের সাথে সহজ ইন্টিগ্রেশনের জন্য ফ্ল্যাগ করুন। যদি স্ক্যানটি আপনার ঝুঁকির সীমার উপরে দুর্বলতা সনাক্ত করে, তাহলে পাইপলাইনটি ব্যর্থ হতে পারে এবং রিলিজ ব্লক করতে পারে।

উন্নত সরঞ্জাম যেমন স্নিক উচ্চ বা জটিল সমস্যা পাওয়া গেলে নির্ভরতা স্ক্যান করে এবং ব্যর্থ বিল্ডগুলি CI/CD-তে নিরাপত্তা গেটকিপার হিসেবে কাজ করতে পারে। SonarQube বা SonarCloud-এর মতো মানসম্পন্ন বিশ্লেষকের সাথে এগুলি একত্রিত করলে আপনি কোডের গুণমান, নিরাপত্তা ঝুঁকি এবং প্রযুক্তিগত ঋণের একটি বিস্তৃত চিত্র পাবেন।

ডেভেলপমেন্টের সময়, ESLint এর মতো স্ট্যাটিক বিশ্লেষণ সরঞ্জামগুলির সাথে প্লাগইন যেমন eslint-plugin-security এবং eslint-plugin-node আপনার নিজস্ব কোডের শুরুতেই অনিরাপদ প্যাটার্ন ধরতে সাহায্য করে। এটি নির্ভরতা স্ক্যানিংকে পরিপূরক করে, যা আপনার ব্যবসায়িক যুক্তির পরিবর্তে তৃতীয় পক্ষের উপাদানগুলিতে ফোকাস করে।

npm অডিটের বাইরে CI/CD পাইপলাইন শক্ত করা

স্বয়ংক্রিয় স্ক্যানগুলি শক্তিশালী, কিন্তু একটি নিরাপদ পাইপলাইনের জন্য শক্তিশালী গোপন ব্যবস্থাপনা, শক্তিশালী অ্যাক্সেস নিয়ন্ত্রণ এবং ভাল সংগ্রহস্থলের স্বাস্থ্যবিধিও প্রয়োজন। ভুলভাবে কনফিগার করা গোপন তথ্য বা অতিরিক্ত অনুমতিমূলক ভূমিকা একটি ছোটখাটো লঙ্ঘনকে একটি সম্পূর্ণ বিস্ফোরিত ঘটনায় পরিণত করতে পারে।

নিবেদিতপ্রাণ গোপন ব্যবস্থাপক ব্যবহার করুন যেমন হাশিকর্প ভল্ট অথবা AWS সিক্রেটস ম্যানেজার ব্যবহার করে কনফিগারেশন ফাইল বা এনভায়রনমেন্ট ভেরিয়েবলে টোকেন বা কী এম্বেড করা যাবে না, সোর্স কন্ট্রোলে চেক করা হবে। এটি আক্রমণকারী, এমনকি একজন কৌতূহলী অবদানকারীর, আপনার রেপোতে সংবেদনশীল ডেটাতে হোঁচট খাওয়ার সম্ভাবনা হ্রাস করে।

GitHub, npm এবং আপনার ব্যবহৃত যেকোনো CI/CD প্ল্যাটফর্মের জন্য ন্যূনতম সুবিধার নীতি সহ ভূমিকা-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ (RBAC) অত্যন্ত গুরুত্বপূর্ণ। ডেভেলপার এবং পরিষেবা অ্যাকাউন্টগুলির কেবলমাত্র প্রয়োজনীয় অনুমতি থাকা উচিত - এর বেশি কিছু নয়।

প্রি-কমিট হুক এবং সিক্রেট-স্ক্যানিং টুলগুলি প্রথমেই আপনার রিপোজিটরিতে API কী, টোকেন বা পাসওয়ার্ড প্রবেশ করা বন্ধ করতে পারে। স্ট্রাকচার্ড GitOps ওয়ার্কফ্লো এবং সুরক্ষিত শাখাগুলির সাথে মিলিত হয়ে, তারা একটি স্পষ্ট অডিট ট্রেইল প্রদান করে এবং অপর্যালোচিত পরিবর্তনগুলি একত্রিত হওয়ার ঝুঁকি কমায়।

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

বাস্তব-বিশ্বের এনপিএম সরবরাহ-শৃঙ্খল আক্রমণ এবং তারা আমাদের কী শেখায়

গত কয়েক বছরে, npm বেশ কয়েকটি হাই-প্রোফাইল সাপ্লাই-চেইন ঘটনা প্রত্যক্ষ করেছে যেখানে আক্রমণকারীরা পৃথক অ্যাপ্লিকেশনের পরিবর্তে রক্ষণাবেক্ষণকারী বা প্যাকেজগুলিকে লক্ষ্যবস্তু করেছে। এই আক্রমণগুলি তুলে ধরে যে কীভাবে একটি একক হ্যাকড অ্যাকাউন্ট লক্ষ লক্ষ ডাউনস্ট্রিম ইনস্টলে প্রভাব ফেলতে পারে।

একটি প্রচারণায়, একজন সুপরিচিত npm রক্ষণাবেক্ষণকারী একটি ডোমেন থেকে সাবধানে তৈরি একটি ফিশিং ইমেল পেয়েছিলেন যা অফিসিয়াল npm সাইট থেকে প্রায় আলাদা করা যাচ্ছিল না। বার্তাটিতে হুমকি দেওয়া হয়েছিল যে যদি দ্বি-ফ্যাক্টর প্রমাণীকরণ "আপডেট" না করা হয় তাহলে অ্যাকাউন্টটি লক করে দেওয়া হবে, যা ভুক্তভোগীকে একটি জাল লগইন পৃষ্ঠায় প্রলুব্ধ করে যা শংসাপত্র ধারণ করে।

আক্রমণকারী যখন রক্ষণাবেক্ষণকারীর npm অ্যাকাউন্টের নিয়ন্ত্রণ পেয়ে যায়, তখন তারা ১৮টি অত্যন্ত জনপ্রিয় প্যাকেজের ক্ষতিকারক সংস্করণ পুশ করে যার সাপ্তাহিক ডাউনলোডের সংখ্যা কোটি কোটি। যেহেতু এই প্যাকেজগুলি জাভাস্ক্রিপ্ট ইকোসিস্টেমের নির্ভরতা গ্রাফে গভীরভাবে এম্বেড করা ছিল, তাই সম্ভাব্য বিস্ফোরণ ব্যাসার্ধ ছিল বিশাল।

ইনজেক্ট করা কোডটি ক্রিপ্টোকারেন্সি এবং ওয়েব3 কার্যকলাপের লক্ষ্যে একটি ব্রাউজার-সাইড ইন্টারসেপ্টরের মতো আচরণ করেছিল: এটি ব্রাউজার API গুলিকে সংযুক্ত করেছিল যেমন fetch, XMLHttpRequest এবং ওয়ালেট ইন্টারফেস যেমন window.ethereum অথবা সোলানা ওয়ালেট এপিআই। এটি নেটওয়ার্ক প্রতিক্রিয়া এবং লেনদেনের পেলোড স্ক্যান করে ক্রিপ্টো ঠিকানা বা স্থানান্তরের মতো দেখতে যেকোনো কিছুর জন্য।

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

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

সেই ব্রাউজার-ইন্টারসেপ্টর ঘটনার দিকনির্দেশনা

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

একটি পুঙ্খানুপুঙ্খ পরিদর্শন package.json এবং package-lock.json (অথবা yarn.lock) আপনার প্রকল্পে কখনও ক্ষতিকারক সংস্করণ প্রবেশ করেছে কিনা তা যাচাই করার জন্য অপরিহার্য। এখানেই ডিটারমিনিস্টিক ইনস্টল এবং সংস্করণ-পিন করা লক ফাইল ফরেনসিক কাজকে অনেক বেশি পরিচালনাযোগ্য করে তোলে।

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

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

বাণিজ্যিক SCA এবং SBOM টুলিং ব্যবহারকারী প্রতিষ্ঠানগুলি প্রায়শই প্যাকেজের নাম এবং সংস্করণ অনুসারে তাদের ইনভেন্টরিগুলি অনুসন্ধান করতে পারে যাতে কোনও ক্ষতিগ্রস্ত লাইব্রেরির উপর নির্ভরশীল সমস্ত সিস্টেম এবং অ্যাপ্লিকেশন সনাক্ত করা যায়। সরবরাহ-শৃঙ্খলের ঘটনা ঘটলে এই দৃশ্যমানতা প্রতিক্রিয়ার সময়কে নাটকীয়ভাবে হ্রাস করে।

শাই-হুলুদ কীট: স্ব-প্রতিলিপি তৈরিকারী এনপিএম ম্যালওয়্যার

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

ম্যালওয়্যারটি সংবেদনশীল শংসাপত্রের জন্য পরিবেশ স্ক্যান করেছে, যার মধ্যে রয়েছে .npmrc AWS, GCP এবং Azure-এর জন্য npm টোকেন, GitHub ব্যক্তিগত অ্যাক্সেস টোকেন, SSH কী এবং ক্লাউড প্রোভাইডার API কী সহ ফাইল। যা কিছু পাওয়া গেছে তা বের করে ফেলা হয়েছে আক্রমণকারী দ্বারা নিয়ন্ত্রিত অবকাঠামোতে।

চুরি করা npm টোকেন ব্যবহার করে, ওয়ার্মটি আপোসকৃত রক্ষণাবেক্ষণকারী হিসেবে প্রমাণিত হয়, তাদের মালিকানাধীন অন্যান্য প্যাকেজগুলি গণনা করে, এর পেলোড ইনজেক্ট করে এবং তারপর নতুন ক্ষতিকারক সংস্করণ প্রকাশ করে। এই অটোমেশনের ফলে আক্রমণকারী প্রতিটি প্যাকেজ ম্যানুয়ালি স্পর্শ না করেই এটি দ্রুত ফ্যান আউট হয়ে যায়।

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

নিরাপত্তা গবেষকরা (অদ্ভুত মন্তব্য এবং এমনকি ইমোজি সহ) স্পষ্ট লক্ষণগুলি লক্ষ্য করেছেন যা ইঙ্গিত দেয় যে ক্ষতিকারক ব্যাশ স্ক্রিপ্টগুলির কিছু অংশ বৃহৎ ভাষা মডেলগুলির সাহায্যে তৈরি করা হয়েছিল। আক্রমণ সরঞ্জাম তৈরির গতি বাড়ানোর জন্য জেনারেটিভ এআই কীভাবে অপব্যবহার করা যেতে পারে তার এটি একটি স্পষ্ট উদাহরণ।

শাই-হুলুদ ২.০: পূর্ব-ইনস্টল অন্তর্ঘাত এবং ধ্বংসাত্মক ফলব্যাক

পরবর্তী একটি তরঙ্গ, যাকে Shai-Hulud 2.0 বলা হয়, ইনস্টলেশন পরবর্তী পর্যায়ের পরিবর্তে প্রি-ইনস্টলেশন পর্যায়ে কার্যকর করার কৌশল পরিবর্তন করে, যার ফলে ডেভেলপার মেশিন এবং CI/CD সার্ভারগুলিতে এর প্রসার ব্যাপকভাবে বৃদ্ধি পায়। প্রি-ইনস্টল স্ক্রিপ্টগুলি জীবনচক্রের আরও আগে চলে এবং আরও সিস্টেমে ট্রিগার করতে পারে।

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

পেলোডটি সহায়ক বান ইনস্টলার স্ক্রিপ্টের মতো ছদ্মবেশে ছিল যেমন setup_bun.js এবং একটি বিশাল, ভারীভাবে অস্পষ্ট bun_environment.js ৯ মেগাবাইটের বেশি আকারের ফাইল। মনোযোগ আকর্ষণ এড়াতে, মূল লজিকটি একটি ব্যাকগ্রাউন্ড প্রক্রিয়ায় প্রবেশ করানো হয়েছিল যাতে মূল ইনস্টলটি স্বাভাবিকভাবে শেষ হয়।

এই প্রচারণার মাধ্যমে সংগৃহীত শংসাপত্র এবং গোপনীয়তা আবার GitHub-এ প্রেরণ করা হয়েছিল, এবার "Sha1‑Hulud: The Second Coming" নামে বর্ণিত সংগ্রহস্থলগুলিতে, এবং ম্যালওয়্যারটি GitHub Actions ওয়ার্কফ্লো তৈরি করে স্থায়িত্ব অর্জনের চেষ্টা করেছিল যেমন discussion.yaml। ঐ কর্মপ্রবাহগুলি সংক্রামিত মেশিনগুলিকে স্ব-হোস্টেড রানার হিসাবে নিবন্ধিত করেছিল, আক্রমণকারীদের কেবল আলোচনা শুরু করে ইচ্ছামত কমান্ড ট্রিগার করার সুযোগ দিয়েছিল।

সামগ্রিক পরিধি ছিল বিশাল, যা হাজার হাজার রিপোজিটরি এবং শত শত GitHub অ্যাকাউন্ট জুড়ে 25 এরও বেশি ক্ষতিকারক রিপো স্পর্শ করেছে, যার মধ্যে জনপ্রিয় লাইব্রেরিগুলিও রয়েছে যেমন @ctrl/tinycolor লক্ষ লক্ষ সাপ্তাহিক ডাউনলোড সহ। যেহেতু লক্ষ্যটিতে ক্লাউড প্ল্যাটফর্মগুলির জন্য শংসাপত্র চুরি অন্তর্ভুক্ত ছিল, তাই এর প্রভাব ডেটা চুরি এবং র‍্যানসমওয়্যার থেকে শুরু করে ক্রিপ্টোমাইনিং এবং ব্যাপক পরিষেবা ব্যাহত হতে পারে।

এনপিএম সরবরাহ শৃঙ্খল কৃমির বিরুদ্ধে তাৎক্ষণিক প্রতিরক্ষামূলক পদক্ষেপ

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

সমস্ত প্রকল্প জুড়ে একটি সম্পূর্ণ নির্ভরতা নিরীক্ষা অপরিহার্য, যেমন সরঞ্জাম ব্যবহার করে npm audit, SBOM ইনভেন্টরি বা বাণিজ্যিক SCA প্ল্যাটফর্মগুলি প্রভাবিত প্যাকেজের নাম এবং সংস্করণগুলির যেকোনো ব্যবহার সনাক্ত করতে। ফাইলগুলি লক করুন (package-lock.json, yarn.lock) আসলে কী ইনস্টল করা হয়েছিল তার আসল সত্যতা প্রদান করুন।

ডেভেলপারদের তাদের GitHub অ্যাকাউন্টগুলি অদ্ভুত পাবলিক রিপোজিটরি (বিশেষ করে Shai-Hulud-এর নামে নামকরণ করা হয়েছে), সন্দেহজনক কমিট বা GitHub Actions ওয়ার্কফ্লোতে অপ্রত্যাশিত পরিবর্তনের জন্য পরীক্ষা করা উচিত যা অননুমোদিত রানারদের নিবন্ধিত করতে পারে। যেকোনো অসঙ্গতি আপোষের লক্ষণ হিসাবে বিবেচনা করা উচিত।

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

উন্নত হুমকি-শিকার প্ল্যাটফর্ম ব্যবহারকারী প্রতিষ্ঠানগুলি নির্দিষ্ট ব্যক্তিদের কাছে কল করার মতো পরিচিত সূচকগুলি অনুসন্ধান করার জন্য কাস্টম কোয়েরিগুলিও ব্যবহার করতে পারে webhook.site URL, ফাইলের উপস্থিতি যেমন shai-hulud-workflow.yml অথবা সন্দেহজনকভাবে বড় bun_environment.js ডেভেলপার মেশিনে লেখা ফাইল। টেলিমেট্রি থেকে প্রাথমিক সনাক্তকরণ নাটকীয়ভাবে থাকার সময় কমাতে পারে।

বিক্রেতারা কীভাবে সাড়া দিচ্ছেন: সনাক্তকরণ এবং প্রতিরোধ ক্ষমতা

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

উন্নত স্যান্ডবক্সিং এবং ম্যালওয়্যার বিশ্লেষণ পরিষেবাগুলি শাই-হুলুদ প্রচারাভিযানে ব্যবহৃত জাভাস্ক্রিপ্ট পেলোডগুলিকে ফ্ল্যাগ করতে পারে। যখন এই সরঞ্জামগুলি সন্দেহজনক পোস্ট-ইনস্টল বা প্রি-ইনস্টল স্ক্রিপ্টগুলি শংসাপত্র আবিষ্কার বা ফাইল ধ্বংস করার চেষ্টা করে, তখন তারা সতর্কতা জারি করে বা কার্যকরকরণকে ব্লক করে।

উন্নত হুমকি প্রতিরোধ এবং URL ফিল্টারিং সহ পরবর্তী প্রজন্মের ফায়ারওয়ালগুলি ফিশিং বা এক্সফিল্ট্রেশনে ব্যবহৃত ক্ষতিকারক ডোমেনগুলিতে অ্যাক্সেস ব্লক করে সাহায্য করতে পারে - উদাহরণস্বরূপ, জাল npm সমর্থন ডোমেন বা নির্দিষ্ট webhook.site ম্যালওয়্যারে হার্ড-কোডেড এন্ডপয়েন্ট। এই URL গুলিকে ক্ষতিকারক হিসেবে শ্রেণীবদ্ধ করলে পেলোড চুরি করা ডেটা সফলভাবে পাঠাতে বাধা দেয়.

এন্ডপয়েন্ট ডিটেকশন এবং রেসপন্স (EDR/XDR) এজেন্টরা প্রক্রিয়া আচরণ, স্ক্রিপ্ট এক্সিকিউশন, অস্বাভাবিক ফাইল তৈরি (যেমন জায়ান্ট) পর্যবেক্ষণ করে অবদান রাখে। bun_environment.js ফাইল) এবং সন্দেহজনক কমান্ড লাইন। আচরণগত নিয়মের উপর ভিত্তি করে তারা পরিচিত হ্যাশ এবং পূর্বে অদেখা উভয় রূপই বন্ধ করতে পারে।

ক্লাউড-নেটিভ অ্যাপ্লিকেশন সিকিউরিটি প্ল্যাটফর্মগুলি ক্রমবর্ধমানভাবে সরবরাহ-চেইন-কেন্দ্রিক বৈশিষ্ট্যগুলি যুক্ত করছে যেমন রিয়েল-টাইম SBOM দৃশ্যমানতা, ওপেন-সোর্স উপাদানগুলির জন্য ঝুঁকি স্কোরিং এবং CI/CD ভুল কনফিগারেশন চেক (অনুপস্থিত লক ফাইল, অনিরাপদ) npm install ব্যবহার, পিন করা কমিট হ্যাশ ছাড়াই গিট-ভিত্তিক নির্ভরতা, আক্রমণ পৃষ্ঠকে প্রসারিত করে অব্যবহৃত নির্ভরতা)। এই নিয়ন্ত্রণগুলি দূষিত বা অযাচিত প্যাকেজ সংস্করণগুলির জন্য উৎপাদন বিল্ডগুলিতে স্লিপ করা কঠিন করে তোলে।

ক্ষতিকারক npm প্যাকেজ সম্পর্কে চিন্তিত ডেভেলপারদের জন্য ব্যবহারিক অভ্যাস

আপনি যদি JS/TS-এ নতুন হন এবং প্রতিবার npm প্যাকেজ ইনস্টল করার সময় অস্বস্তি বোধ করেন, তাহলে আপনি একা নন - তবে আপনার উৎপাদনশীলতা স্থবির না করে ঝুঁকি কমাতে আপনি কিছু নির্দিষ্ট অভ্যাস অবলম্বন করতে পারেন। এগুলোকে ব্যক্তিগত নিরাপত্তা চেকলিস্ট হিসেবে ভাবুন।

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

ছোট বা অস্পষ্ট প্যাকেজগুলির জন্য (বিশেষ করে যেগুলি প্রায় কোনও ডাউনলোড নেই), সেগুলি আরও নিবিড়ভাবে পরীক্ষা করুন: npm পৃষ্ঠা, রিপোজিটরি লিঙ্ক, শেষ প্রকাশের তারিখ এবং রক্ষণাবেক্ষণকারী স্পষ্টভাবে সনাক্তযোগ্য কিনা তা পরীক্ষা করুন। npm প্যাকেজটি যদি এমন কোনও GitHub রেপোর সাথে লিঙ্ক করে যেখানে আসলে প্রকাশিত কোড নেই বা যা এখনও কোনও সম্পর্কহীন আপস্ট্রিমের দিকে নির্দেশ করে তবে সতর্ক থাকুন।

যেখানে সম্ভব, কেবল সোর্স রিপোজিটরি নয়, প্রকাশিত প্যাকেজ টারবলটিও পরীক্ষা করুন, কারণ আক্রমণকারীরা GitHub-এ প্রদর্শিত বিল্ডের চেয়ে npm-এ ভিন্ন বিল্ড পাঠাতে পারে। যেমন সরঞ্জাম npm pack ম্যানুয়াল পর্যালোচনার সাথে মিলিত হলে (কোডটি ট্রান্সপাইল বা মিনিফাই করা হলেও) অদ্ভুত ইনস্টল স্ক্রিপ্ট, অস্পষ্ট ব্লব বা অপ্রত্যাশিত নেটওয়ার্ক কলের মতো স্পষ্ট লাল পতাকা প্রকাশ করতে পারে।

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

অগ্নি-ড্রিলের পরিবর্তে এনপিএম নিরাপত্তাকে একটি রুটিন করুন: দৌড় npm audit নিয়মিতভাবে, অব্যবহৃত নির্ভরতা পরিষ্কার করুন, আপনার লক ফাইলগুলিকে প্রতিশ্রুতিবদ্ধ রাখুন এবং আপনার CI/CD-তে SCA/SAST চেকগুলি একীভূত করুন। শক্তিশালী অ্যাকাউন্ট হাইজিন এবং গোপন ব্যবস্থাপনার সাথে মিলিত হয়ে, এই অনুশীলনগুলি আপনাকে অরক্ষিত করে না, তবে একটি এলোমেলো npm ইনস্টল আপনার সিস্টেমগুলিকে নীরবে আপস করার সম্ভাবনাকে উল্লেখযোগ্যভাবে হ্রাস করে।