এটি একটি সিরিজের তৃতীয় পর্ব। নিবন্ধ সিরিজ সবচেয়ে প্রচলিত ধরনের সফ্টওয়্যার সাপ্লাই চেইন আক্রমণ সম্পর্কে: যেগুলো একটি পাবলিক রেজিস্ট্রির অপব্যবহার করে। ওপেন সোর্স সফটওয়্যার উপাদানসমূহ। পূর্ববর্তী পর্বে বিশ্লেষণ করার পর “ক্ষতিকর প্যাকেজের ব্যবচ্ছেদ: প্রবণতাগুলো কী কী?দুষ্কৃতকারীরা যেভাবে নতুন বা বিদ্যমান প্রকাশিত কম্পোনেন্টগুলোতে ক্ষতিকর কার্যকলাপ প্রবেশ করায়, তা মোকাবিলা করার জন্য আমরা প্রস্তুত। আমরা খতিয়ে দেখি যে, এই উপায়ে ছড়ানো ক্ষতিকর সফটওয়্যারকে কীভাবে সফলভাবে ব্লক করা যায়, অথবা ভুল পদ্ধতি অবলম্বনের কারণে কোনো সম্ভাব্য গুরুতর সাইবার ঘটনার সম্মুখীন হতে হয়।
অধিকাংশ নিরাপত্তা-সচেতন পেশাজীবীরই এই হুমকি মোকাবেলার উপায় সম্পর্কে ধারণা আছে। আমরা নিরাপত্তা ব্যবস্থাপকদের দ্বিধা ছাড়াই বলতে শুনেছি যে SCA টুলগুলো ইতিমধ্যেই আপনাকে বলে দেয় কখন কোনো প্যাকেজ ভার্সন ম্যালওয়্যারযুক্ত। অথবা সেগুলো সুপরিচিত, উচ্চ-পর্যালোচিত সফটওয়্যার কম্পোনেন্টের উপর নির্ভরশীল, যেখানে যেকোনো ম্যালওয়্যার দ্রুত শনাক্ত ও অপসারণ করা হবে। তারা স্বয়ংক্রিয়ভাবে দুর্বলতার সমাধান পাওয়ার জন্য ওপেন মাইনর/প্যাচ ভার্সন ব্যবহার করে, এবং ওপেন সোর্স নির্ভরতার ঝুঁকি কমানোর জন্য এটাই সঠিক ও প্রস্তাবিত উপায়, যা “তাড়াতাড়ি প্যাচ করুন, ঘন ঘন প্যাচ করুন" নীতি.
এই পর্বে আমরা পর্যালোচনা করব কেন এই ধারণাগুলো ভুল, এবং কীভাবে এই ধরনের ভ্রান্ত ধারণাগুলো এই আক্রমণ পদ্ধতির জনপ্রিয়তা বাড়াতে এবং সংস্থাগুলোর জন্য এক ভয়াবহ ঝুঁকি তৈরি করতে ভূমিকা রাখছে। সবশেষে আমরা আলোচনা করব, কোনটি কার্যকর এবং এর জন্য কী পরিমাণ প্রচেষ্টা ও সম্পদের প্রয়োজন।
সাধারণ ভুল ধারণা
সফটওয়্যার নিরাপত্তা নিয়ে আমাদের যাত্রাপথে আমরা আক্রমণের কৌশলগুলোর বিবর্তন এবং নিরাপত্তা-সচেতন ব্যক্তিদের কাছ থেকে আসা নানা ধরনের ধারণা দেখেছি। প্রতিষ্ঠানগুলো প্রায়শই বুঝতে পারে না যে এই হুমকির বিরুদ্ধে কী কাজ করে, তাই প্রথমে আমরা দেখব কী কাজ করে না, যা নিম্নলিখিত ভুল ধারণাগুলোর একটি সংক্ষিপ্ত তালিকায় তুলে ধরা হলো (এটি সম্পূর্ণ তালিকা নয়)।
ভুল ধারণা #1: SCA টুলগুলো ইতিমধ্যেই ক্ষতিকারক উপাদান সম্পর্কে রিপোর্ট করে।
প্রকৃতপক্ষে! কিন্তু ঘটনার পরে… যখন সম্ভবত অনেক দেরি হয়ে যায়, যদি উপাদানটি কোনো সফটওয়্যার বিল্ডে ব্যবহার করা হয়ে থাকে, এবং দুষ্কৃতকারীরা ইতিমধ্যেই কোনো ডেভেলপারের মধ্যে বা CI/CD হোস্ট। গোপনীয় তথ্য পাচার হয়ে থাকতে পারে, অতিরিক্ত ম্যালওয়্যার ডাউনলোড ও ইনস্টল হয়ে থাকতে পারে, এবং সম্ভবত প্রতিপক্ষ পার্শ্ববর্তী প্ল্যাটফর্মে স্থানান্তরিত হয়ে ইতোমধ্যে অন্যত্র প্রবেশাধিকার লাভ করেছে।
সফটওয়্যার গঠন বিশ্লেষণ (SCAসম্ভাব্য পরিচিত দুর্বলতাগুলো শনাক্ত করার জন্য টুলগুলো ডিজাইন করা হয়েছিল। আধুনিক টুলগুলো সিগন্যাল-নয়েজ রেশিও বাড়িয়ে দিয়ে, দুর্বলতাটি আসলেই অ্যাক্সেসযোগ্য বা এক্সপ্লয়টেবল কিনা তা নির্ধারণ করার ক্ষেত্রে দারুণ কাজ করে। কিন্তু নতুন ম্যালওয়্যারের বিরুদ্ধে এগুলো অকার্যকর। একটি ক্ষতিকারক কম্পোনেন্টকে একটি জিরো-ডে দুর্বলতা হিসেবে ভাবুন: শুধুমাত্র যখন এর ক্ষতিকারক আচরণ শনাক্ত করা হয়, তখনই কম্পোনেন্টটিকে হোল্ডিং রেজিস্ট্রিতে রিপোর্ট করা হয়, যা একটি নিরাপত্তা দলের পর্যালোচনার পর ক্ষতিকারক হিসেবে নিশ্চিত হয় এবং রেজিস্ট্রি থেকে সরিয়ে ফেলা হয়। [1].
সেই মুহূর্তে, বিশ্ব (সহ) SCAs) জানে যে কম্পোনেন্টটি (অথবা বিদ্যমান কোনো কম্পোনেন্টের কিছু সংস্করণ) ইনস্টল করা বা ব্যবহার করা ভালো কাজ নয়। কিন্তু এটি তখনই প্রযোজ্য যখন কম্পোনেন্টটি রেজিস্ট্রি থেকে পাওয়া যায় না।আমার থার্ড-পার্টি কম্পোনেন্টগুলোতে, বা এমনকি রেজিস্ট্রি দ্বারা ক্ষতিকারক হিসেবে চিহ্নিত কম্পোনেন্টগুলোতে দুর্বলতা আছে, এটা জানা ভালো, কিন্তু দুর্ভাগ্যবশত SCA অথবা প্রচলিত অডিট টুলগুলো এই ক্ষেত্রে সাহায্য করে না। না হলে SCAঅডিট টুল আপনার প্রতিষ্ঠানে কোনো কম্পোনেন্ট ব্যবহার হওয়ার আগেই তা ক্ষতিকর কিনা, তা আগে থেকেই জানতে পারে।.
মনে রাখবেন, ক্ষতিকারক ওপেন-সোর্স উপাদানগুলির বিরুদ্ধে যেকোনো সমাধানকে অবশ্যই সেগুলিকে সনাক্ত করতে হবে। অন-ফ্লাইরেজিস্ট্রিতে কম্পোনেন্টটি প্রকাশিত হওয়ার সময় থেকে আপনার প্রতিষ্ঠানে কম্পোনেন্টটি (সংস্করণটি) প্রথমবার ব্যবহৃত হওয়ার সময় পর্যন্ত। এবং এর মধ্যে ট্রানজিটিভ কম্পোনেন্টও অন্তর্ভুক্ত।
ভুল ধারণা #২: বিল্ড টাইমে ইনস্টলেশন স্ক্রিপ্ট নিয়ন্ত্রণ করলে ওপেন-সোর্স কম্পোনেন্টগুলোর ক্ষতিকর কার্যকলাপ প্রতিরোধ করা যায়
বিভিন্ন প্যাকেজ ম্যানেজার স্ক্রিপ্ট চালানোর সুবিধা প্রদান করে (যা কম্পোনেন্ট টারবলে অন্তর্ভুক্ত থাকে)। [2]), বিভিন্ন প্ল্যাটফর্মে প্রয়োজনীয় আইটেম কম্পাইল করা, কোড জেনারেট করা বা টেস্ট চালানোর মতো বৈধ কারণে এগুলো ব্যবহৃত হয়, এবং আমাদের সকলেরই জানা উচিত যে, যদি টারবলে ক্ষতিকারক স্ক্রিপ্ট অন্তর্ভুক্ত করা হয়, অথবা যদি আক্রমণকারী ভালো স্ক্রিপ্টটির পরিবর্তে একটি ক্ষতিকারক স্ক্রিপ্ট চালাতে সক্ষম হয়, তবে দুষ্কৃতকারীরা এর অপব্যবহার করতে পারে।
এই বিষয়টি জেনে, আমরা প্যাকেজ ম্যানেজারকে স্ক্রিপ্ট উপেক্ষা করার জন্য কনফিগার করতে পারি। উদাহরণস্বরূপ, NPM-এর ক্ষেত্রে স্ক্রিপ্টগুলি উপেক্ষা করুন ফ্ল্যাগ (অথবা একটি কনফিগারেশন প্রপার্টিতে) .npmrc ফাইলটি ইনস্টলেশনের সময় স্ক্রিপ্টগুলি এড়িয়ে যায়। এটি কিছু সমস্যা তৈরি করতে পারে কারণ অনেক ইকোসিস্টেমে স্ক্রিপ্ট চালানো একটি সাধারণ বিষয়: কিছু প্যাকেজ ম্যানেজার স্ক্রিপ্ট চালানো বন্ধ করার অনুমতিও দেয় না (ইঙ্গিত: প্রম্পট “কোন প্যাকেজ ম্যানেজারগুলো ইনস্টল স্ক্রিপ্ট চালানো বন্ধ করার অনুমতি দেয় না?আপনার প্রিয় এআই-তে)। কিন্তু এটি সাধারণভাবে সুরক্ষা দেয় না (আমাদের নিশ্চিত করতে হবে যে স্কিপ ডিসেবল কনফিগারেশনটি সর্বত্র রয়েছে)।
আর যখন ক্ষতিকর আচরণটি ইনস্টল স্ক্রিপ্টে না থেকে রানটাইমে কার্যকর হওয়া সফটওয়্যারে থাকে, তখন শুধু এই বিকল্পটি আমাদের সুরক্ষা দেয় না।
ভুল ধারণা #৩: ভার্সন পিনিং ক্ষতিকারক উপাদান ইনস্টল হওয়া থেকে বিরত রাখে
তাড়াতাড়ি এবং ঘন ঘন প্যাচিং করার মধ্যে একটি আপস রয়েছে উন্মুক্ত সংস্করণ (নিরাপত্তাজনিত ত্রুটি সংশোধনের জন্য নতুন আপডেট উপলব্ধ হলে প্যাকেজ ম্যানেজারকে স্বয়ংক্রিয়ভাবে ইনস্টল করার সুযোগ দেওয়া) এবং সংস্করণ পিনিং (একটি সফটওয়্যারের সমস্ত প্রত্যক্ষ এবং পরোক্ষ নির্ভরতা একটি নির্দিষ্ট সংস্করণে থাকা)। নিরাপত্তার নীতিগুলি অনমনীয় এবং কখনও কখনও পরস্পরবিরোধী, যেমনটা "তাড়াতাড়ি প্যাচ করো, ঘন ঘন প্যাচ করো" এবং এই নীতির ক্ষেত্রে ঘটে থাকে। আপগ্রেড করাকে হালকাভাবে নেওয়া উচিত নয়।কিছু প্যাকেজ ম্যানেজার প্রস্তাবিত পদ্ধতি হিসেবে সার্ভার রেঞ্জ ব্যবহার করে স্বয়ংক্রিয় আপডেট করে থাকে। আপনি যদি ক্ষতিকারক আপডেটগুলোও পেতে চান, তবে এটি খুবই ভালো! হ্যাঁ, যত দ্রুত সম্ভব দুর্বলতা দূরকারী নিরাপত্তা সমাধানগুলো পাওয়ার জন্য কম্পোনেন্টগুলো অবশ্যই আপডেট করতে হবে, কিন্তু... কখনোই প্যাকেজ ম্যানেজারকে এটি স্বয়ংক্রিয়ভাবে করতে দেবেন না।
ভুল ধারণা #৪: বিশ্বস্ত উপাদান ব্যবহার করা নিরাপদ। এর যেকোনো ক্ষতিকর সংস্করণ দ্রুত খুঁজে বের করে প্রকাশ করা হবে এবং সরিয়ে ফেলা হবে।
একটি কম্পোনেন্ট কেন বিশ্বস্ত? সম্ভবত কারণ এটি অত্যন্ত জনপ্রিয়, যেখানে বহু মানুষ এর দুর্বলতা খুঁজে বেড়ায়, রক্ষণাবেক্ষণের জন্য প্রচুর অবদানকারী রয়েছে এবং একাধিক মূল রক্ষণাবেক্ষণকারী আছেন যারা নিষ্ঠার সাথে সবকিছু পর্যালোচনা করেন। pull requestsবাস্তবতাটা সম্পূর্ণ ভিন্ন। কিছু অপরিহার্য উপাদান একজন মাত্র অবৈতনিক ডেভেলপার দ্বারা রক্ষণাবেক্ষণ করা হয়। বহুল ব্যবহৃত ফ্রেমওয়ার্কগুলোতে রয়েছে কয়েকজন নিয়মিত অবদানকারীদ্রুত হ্রাসমান সংখ্যার সাথে commitরক্ষণাবেক্ষণকারী প্রতি (জনপ্রিয় প্রকল্পগুলিতে এমন অনেক অবদানকারী থাকেন যারা মাঝে মাঝে কিছু কাজ করে যান) commit এবং আর কখনো ফিরে আসে না)। আর একজন মাত্র রক্ষণাবেক্ষণকারী রয়েছে এমন জনপ্রিয় প্রকল্পেরও অভাব নেই।
নিজেকে বলতে কল্পনা করুন ওহ, আমরা Spring Boot / Angular / React / PyTorch / অফিসিয়াল বেস ডকার ইমেজ ব্যবহার করছি, তাই আপনি যে ঝুঁকির কথা বলছেন তা বেশ কম। হয়তো এটা সত্যি, আমরা নিরাপত্তা পণ্য বিক্রেতারা সারাক্ষণ আতঙ্ক ছড়াই, এবং একটি বিতর্কিত ঝুঁকি প্রশমিত করার জন্য উন্নয়ন দলের কাজে হস্তক্ষেপ করাটা অর্থহীন। আপনি হয়তো (পরবর্তী বিভাগে) ঝুঁকি গ্রহণের অনুচ্ছেদে সরাসরি চলে যেতে চাইবেন এবং ভাববেন যে এতেই সব শেষ। দুর্ভাগ্যবশত, সবচেয়ে জনপ্রিয় উপাদানগুলোই দুষ্কৃতকারীদের লক্ষ্যবস্তু, এবং উদাহরণস্বরূপ, জনপ্রিয় পাইটর্চ লাইব্রেরি আক্রান্ত হয়েছিল অতীতে.
অবিলম্বে খুঁজে বের করা, প্রকাশ করা এবং অপসারণ করা হয়েছে। পাবলিক রেজিস্ট্রি থেকে একটি নতুন ক্ষতিকারক কম্পোনেন্ট অপসারণ করতে কয়েক দিন সময় লাগে। রেজিস্ট্রিগুলো ভালোর জন্যই কোনো কম্পোনেন্টের সংস্করণ অপসারণের ব্যাপারে সতর্ক থাকে। আমাদের অভিজ্ঞতা হলো, আমাদের পক্ষ থেকে রিপোর্ট করার পর রেজিস্ট্রি কর্তৃক ক্ষতিগ্রস্ত সংস্করণটি অপসারণ করতে গড়ে ৩৯ ঘণ্টা সময় লাগে, যা দেড় দিনেরও বেশি। এমন ক্ষতিকারক কম্পোনেন্টও আছে, যা আমাদের প্রাথমিক রিপোর্টের এক সপ্তাহ পরেও রেজিস্ট্রি থেকে অপসারিত হয়। এবং কিছু ক্ষেত্রে, কোনো ভুক্তভোগী বা কোনো ইনসিডেন্ট রেসপন্স কোম্পানি কম্পোনেন্টটি সম্পর্কিত কোনো ঘটনার রিপোর্ট করার পরেই কেবল কম্পোনেন্টটি অপসারণ করা হয়।
ক্ষতিকর উপাদানগুলোর বিরুদ্ধে কী কাজ করে না
যেকোনো অনির্দিষ্ট পন্থা শোচনীয়ভাবে ব্যর্থ হবে। এটা নিশ্চিত যে, আপনি এই হুমকির সাথে সম্পর্কিত ঝুঁকির জন্য কার্যকর প্রতিরোধমূলক ব্যবস্থা গ্রহণ করছেন না।
ঐতিহ্যগত SCA টুলগুলো আপনাকে পরিচিত ম্যালওয়্যার সম্পর্কে জানায়, কিন্তু এগুলোর সংস্পর্শে আসার সময়কাল অনেক দীর্ঘ। যদি না তারা সক্রিয়ভাবে ম্যালওয়্যার শনাক্ত করে এবং ক্ষতিকারক উপাদানগুলোকে কঠোরভাবে ব্লক করে, তবে এই হুমকির বিরুদ্ধে সেগুলো কাজ করে না।
ইনস্টলেশন স্ক্রিপ্ট নিষ্ক্রিয় করা সহায়ক হতে পারে, কিন্তু যেখানেই কোনো কম্পোনেন্ট ইনস্টল করার প্রয়োজন হবে, সেখানেই এটি প্রয়োগ করতে হবে। ভার্সন পিনিং-এর ক্ষেত্রেও একই কথা প্রযোজ্য, কারণ ভার্সনগুলোকে একটি নিরাপদ প্রাথমিক অবস্থা থেকে অনির্দিষ্টকালের জন্য পিন করে রাখা যায় না।
এটা ধরে নেওয়াটা অবাস্তব এবং ঝুঁকিপূর্ণ যে, জনপ্রিয় উপাদানগুলো যথেষ্ট মনোযোগ পায় এবং সাপ্লাই চেইন আক্রমণের সময় প্রায় তাৎক্ষণিক শনাক্তকরণের মাধ্যমে কোনো ক্ষতি এড়ানো সম্ভব না হওয়ায় সেগুলোতে অনাকাঙ্ক্ষিত আচরণ প্রবেশ করানো যায় না। আপনি তো আর ঝুঁকির মধ্যে থাকতে চান না, তাই না?
যদি আপনি এই পর্যায়ে থেমে যান তাহলে ঝুঁকি গ্রহণ আপনি শুধু এই একটি কাজই করতে পারেন: এটি একটি ডিcisআপনার থ্রেট মডেল/ঝুঁকি মূল্যায়নে যে বিষয়গুলো নথিভুক্ত করা প্রয়োজন, তার মধ্যে ঝুঁকি গ্রহণের যৌক্তিকতা এবং এর সম্ভাব্য পরিণতি অন্তর্ভুক্ত থাকবে। ব্যবস্থাপনা এবং অন্যান্য প্রাসঙ্গিক পক্ষের কাছে বিষয়টি জানিয়ে সচেতনতা বৃদ্ধি করুন। দৈবঘটনা আপনার সফটওয়্যারে কোনো ক্ষতিকারক উপাদান ইনস্টল বা অন্তর্ভুক্ত করার মাধ্যমে একটি আক্রমণের পরিকল্পনা করা যেতে পারে, কিন্তু এটি কঠিন কারণ আক্রমণকারীদের অনুসরণ করার জন্য অনেক পথ থাকে। একটি ক্ষতিকারক উপাদান ব্যবহারের উপর ভিত্তি করে হওয়া সাপ্লাই চেইন আক্রমণের বিস্তারিত বিবরণ ঘটনাটির প্রকাশ্য প্রকাশকে ব্যাপকভাবে পরিবর্তন করে দেবে, যা সম্ভবত আপনার সংস্থার নিয়ন্ত্রক কাঠামোর অধীনে বাধ্যতামূলক। আপনি আরও উল্লেখ করতে পারেন ক্ষতিপূরণমূলক নিয়ন্ত্রণ or স্থানান্তর ঝুঁকি যেমন বীমার মাধ্যমে।
তবে, এই হুমকি মোকাবেলার জন্য কিছু নিয়ন্ত্রণ ব্যবস্থা রয়েছে এবং আপনি যদি ঝুঁকি মেনে নিতে সন্তুষ্ট না হন, তবে সেগুলো বিবেচনা করা উচিত। অনুগ্রহ করে আরও পড়ুন।
ক্ষতিকর উপাদান ব্যবহার করে করা আক্রমণের বিরুদ্ধে কী কাজ করে
সলিড ভার্সন হ্যান্ডলিং
ম্যালওয়্যার দ্বারা আক্রান্ত না হয়ে দুর্বলতা দূর করার প্রয়োজনের মধ্যে ভারসাম্য বজায় রাখতে, নিয়ন্ত্রিত ও তথ্যভিত্তিক ভার্সন বাম্প সহ ভার্সন পিনিং করাই সর্বোত্তম পন্থা। কিন্তু ৩ নং ভুল ধারণাটি মনে রাখবেন: নতুন ভার্সন থেকে আসা ক্ষতিকারক কোড আটকাতে শুধুমাত্র ভার্সন পিনিং যথেষ্ট নয়, কারণ ভবিষ্যতে আপনাকে যেকোনো প্রত্যক্ষ বা পরোক্ষ নির্ভরশীলতার ভার্সনগুলো আপডেট করতে হবে। সেই মুহূর্তে আপনার কাছে এমন শক্তিশালী প্রমাণ প্রয়োজন হবে যে, পরিবর্তিত কোনো ভার্সনেই ম্যালওয়্যার নেই।
প্রথম দিকে সতর্কতা
ক্ষতিকারক উপাদানগুলির সমস্যার একটি সমাধান হলো আগাম সতর্কীকরণ ব্যবস্থা (এখানে যার নাম দেওয়া হয়েছে ম্যালওয়্যারের প্রাথমিক সতর্কতা অথবা MEW), যেখানে (নতুন বা বিদ্যমান কম্পোনেন্টের) প্রকাশিত নতুন সংস্করণগুলো একটি ডিটেকশন ইঞ্জিন দ্বারা বিশ্লেষণ করা হয়, যা যথেষ্ট প্রমাণ পেলে নতুন সংস্করণটিকে সম্ভাব্য ক্ষতিকারক হিসেবে শ্রেণীবদ্ধ করতে পারে।
এখানে অটোমেশন অপরিহার্য, কারণ বর্তমান প্রকাশের হারে সমস্ত নতুন কম্পোনেন্ট ম্যানুয়ালি পর্যালোচনা করা অসম্ভব। তাই ডিটেকশন ইঞ্জিনকে বিভিন্ন কৌশল একত্রিত করতে হবে, যার মধ্যে সম্ভবত স্ট্যাটিক, ডাইনামিক এবং ক্যাপাবিলিটি অ্যানালাইসিস, ব্যবহারকারীর খ্যাতি, এবং কম্পোনেন্টের মেটাডেটা ও টারবলের বিষয়বস্তুর মধ্যে, অথবা টারবল ও সেই সোর্স রিপোজিটরির মধ্যেকার অসামঞ্জস্য থেকে প্রাপ্ত প্রমাণ অন্তর্ভুক্ত থাকবে, যেখান থেকে কম্পোনেন্টটি এসেছে বলে মনে করা হয়।
সেখানে একটি অন্ধকার অঞ্চল প্রকাশের সময় এবং ইঞ্জিন যখন কম্পোনেন্টের বিষয়বস্তু বিশ্লেষণ করে, তার মধ্যবর্তী সময় কয়েক মিনিটের বেশি হওয়া উচিত নয়। এই পদ্ধতিটি পরিবর্তন করা যেতে পারে, যেমন—সফটওয়্যার বিল্ডে নতুন কম্পোনেন্ট ইনস্টল ও ব্যবহারের অনুমতি দেওয়ার আগে সেগুলোর বিশ্লেষণ শেষ হওয়া পর্যন্ত অপেক্ষা করা। pipelineঅথবা প্রয়োজনে চাহিদা অনুযায়ী সেগুলোকে বিশ্লেষণ করা যায়। একটি কম্পোনেন্ট তার নির্দিষ্ট ভার্সনে অপরিবর্তনীয় থাকে। [3]সুতরাং এটি কেবল একবারই বিশ্লেষণ করা প্রয়োজন।
সম্পূর্ণ স্বয়ংক্রিয়করণ সম্ভব নয়, এবং সম্ভাব্য ক্ষতিকারক উপাদানগুলোর জন্য একটি নিরাপত্তা পর্যালোচনা প্রয়োজন। ডিজিটাল সর্বরোগহর ঔষধের প্রবক্তাদের থেকে সাবধান থাকুনকোনো সন্দেহজনক কম্পোনেন্টে ম্যালওয়্যার আছে কি না, তা নিশ্চিত করার ক্ষেত্রে চূড়ান্ত সিদ্ধান্ত নেওয়ার মতো যথেষ্ট উন্নত নয় এআই এবং মেশিন লার্নিং। এটা ঠিক যে, সংগৃহীত কাঁচা প্রমাণ থেকে ইনপুট কম্পোনেন্টটিকে শ্রেণিবদ্ধ করার ক্ষেত্রে ডিটেকশন ইঞ্জিনে মেশিন লার্নিং একটি গুরুত্বপূর্ণ ভূমিকা পালন করে, কিন্তু কম্পোনেন্টটি "কোয়ারেন্টাইন" হয়ে গেলে, ক্ষতিকারক কম্পোনেন্ট বিষয়ে অভিজ্ঞ একটি নিরাপত্তা দলের ম্যানুয়াল পর্যালোচনার ওপরই চূড়ান্ত সিদ্ধান্ত নির্ভর করে। এটিই কোনো সম্ভাব্য ম্যালওয়্যারকে নিশ্চিত করে অথবা সেটিকে নিরাপদ হিসেবে পুনরায় শ্রেণিবদ্ধ করে। আর এই পুরো প্রক্রিয়াটি কয়েক ঘণ্টার মধ্যে সম্পন্ন হয়।
রেজিস্ট্রি ক্ষতিকারক সংস্করণ/উপাদান সম্পর্কে প্রতিবেদন দেয়; এরপর রেজিস্ট্রি তা নিশ্চিত করার জন্য পর্যালোচনা করে এবং সর্বসমক্ষে প্রকাশ ও রেজিস্ট্রি থেকে অপসারণের পদক্ষেপ নেয়। কিছু রেজিস্ট্রি একটি নিরাপত্তা হোল্ডিং প্যাকেজ রাখে। এখানে সময়সীমা হলো প্রকাশের পর থেকে অতিবাহিত দিন বা সপ্তাহ, যা হলো 'থাকার সময়'বা'এক্সপোজার উইন্ডোঅধিকাংশ ক্ষতিকারক উপাদানের জন্য।
কোনো কম্পোনেন্ট ভার্সন ক্ষতিকর কিনা তা জানা কি সম্ভব?
সুতরাং আগাম সতর্কতার জন্য, আমাদের এই প্রশ্নের একটি সন্তোষজনক উত্তর দিতে হবে: আমি কীভাবে জানব যে একটি লাইব্রেরি বা প্যাকেজ ক্ষতিকর (বা নয়)? ক্ষতিকর আচরণের যথেষ্ট প্রমাণ কীভাবে সংগ্রহ করা যায়? এটি সম্ভব, কিন্তু কঠিন, কারণ প্রতিপক্ষরা শনাক্তকরণ এড়াতে অনেক উদ্ভাবনী কৌশল ব্যবহার করে। বিভিন্ন পন্থা রয়েছে, যার প্রতিটিরই সুবিধা ও অসুবিধা আছে।
স্ট্যাটিক বিশ্লেষণ কম্পোনেন্টটি না চালিয়েই সমস্ত এক্সিকিউশন পাথ পরীক্ষা করা যায়, আক্রমণকারীদের ব্যবহৃত কৌশলগুলো যাচাই করা যায় এবং ডি-অবফাসকেশন বা ডিক্রিপ্ট করার মতো প্রিপ্রসেসিং কাজগুলো সম্পাদন করা যায়। যেহেতু আক্রমণকারীরা তাদের অপকর্ম লুকানোর চেষ্টা করে, তাই অবফাসকেশনের প্রচেষ্টাগুলো প্রকৃতপক্ষে ম্যালওয়্যারের প্রমাণ (কিন্তু মনে রাখবেন যে বৈধ কম্পোনেন্টগুলো মেধাস্বত্ব রক্ষার জন্য কোড অবফাসকেট করে, যা “ওপেন সোর্সশক্তিশালী ধোঁয়াশা সহ অত্যন্ত অত্যাধুনিক আক্রমণগুলির মধ্যে শুধুমাত্র একটি ক্ষুদ্র অংশের জন্য স্যান্ডবক্সিং প্রয়োজন, কিন্তু এই ধরনের শক্তিশালী ধোঁয়াশা ক্ষতিকর কার্যকলাপের একটি সুস্পষ্ট লক্ষণ। অনুগ্রহ করে মনে রাখবেন যে প্রচলিত SAST টুলগুলো অনিচ্ছাকৃত দুর্বলতার জন্য ডিজাইন করা হয়েছিল, ব্যাকডোরের মতো বিদ্বেষপূর্ণ উদ্দেশ্যের জন্য নয়।
গতিশীল বিশ্লেষণ কম্পোনেন্টটি চালায় এবং সাধারণত একটি স্যান্ডবক্সড পরিবেশ প্রদানের মাধ্যমে রানটাইমকে ইনস্ট্রুমেন্ট করে প্রতিক্রিয়া পরীক্ষা করে। নির্দিষ্ট পরিস্থিতিতে সক্রিয় হওয়া ক্ষতিকারক আচরণ অলক্ষিত থেকে যেতে পারে: অনুগ্রহ করে মনে রাখবেন যে ম্যালওয়্যার এড়ানোর কৌশল ব্যবহার করতে পারে, যেমন— ভার্চুয়ালাইজেশন/স্যান্ডবক্স ফাঁকি শুধুমাত্র নজরদারির বাইরে থাকলেই সক্রিয় হওয়া, এবং যেকোনো স্ট্যাটিক অ্যানালাইসিস ইঞ্জিনের জন্য এটি ক্ষতিকারক কার্যকলাপের একটি সুস্পষ্ট লক্ষণ।
সক্ষমতা বিশ্লেষণ কম্পোনেন্টটি কী করে তা বিবেচনা করা হয়: এটি কোথায় সংযোগ স্থাপন করে, কোন ফাইলগুলো অ্যাক্সেস করে, কোন কমান্ড বা প্রোগ্রাম চালানো হয়, টার্মিনাল বা ডিভাইসের ইনপুট/আউটপুট (I/O) সম্পাদিত হয়, অথবা কোন সিস্টেম কল আহ্বান করা হয়। আচরণের এই ফিঙ্গারপ্রিন্টিং (একটি বিদ্যমান কম্পোনেন্টের জন্য) বিভিন্ন সংস্করণের মধ্যে তুলনা করা যেতে পারে, ফলে যখন কোনো অপ্রত্যাশিত আচরণ শনাক্ত হয়, তখন সেই প্রমাণ নতুন সংস্করণে সম্ভাব্য ক্ষতিকারক কার্যকলাপ প্রবেশের বিষয়ে সন্দেহ জাগাতে পারে। এই পদ্ধতিটি সেই বাছাই পর্বগুলো অনুসরণ করে যা নিরাপত্তা বিশ্লেষকরা সম্ভাব্য ম্যালওয়্যারের সম্মুখীন হলে অনুসরণ করেন: একটি পরিদর্শন যা ব্যবহার করে স্ট্রিং অথবা অনুরূপ টুল। এই পদ্ধতিটি উদ্দীপক পরিস্থিতি নির্বিশেষে ক্ষতিকারক আচরণ শনাক্ত করে এবং সোর্স কোড উপলব্ধ না থাকলেও কাজ করে।
প্রসঙ্গ বিশ্লেষণ কম্পোনেন্টটি কীভাবে এবং কার দ্বারা প্রকাশিত হয়েছিল, সে সম্পর্কে তথ্য সংগ্রহ করে। দুষ্কৃতকারীদের প্রচারাভিযানে প্রায়শই এমন নতুন ব্যবহারকারী অ্যাকাউন্ট ব্যবহার করা হয়, যা কোনো কঠোর যাচাই-বাছাই প্রক্রিয়ার অধীন নয়। অতীতের কার্যকলাপ ট্র্যাক করলে অন্তর্নিহিত ব্যবহারকারী সম্পর্কে ধারণা পাওয়া যেতে পারে, বিশেষ করে সেইসব অস্বাভাবিকতার ক্ষেত্রে যা কোনো সম্ভাব্য নিরাপত্তা লঙ্ঘনের ইঙ্গিত দিতে পারে। সুনাম অর্জন করা খুব কঠিন, আর হারানোটা খুব সহজ! অতীতে কোনো কার্যকলাপ না থাকা ব্যবহারকারী নিরপেক্ষ, কিন্তু কর্মফল দুষ্কৃতকারীদের তাড়া করে ফেরে। হ্যাকটিভিস্ট, বা সাধারণ ব্যবহারকারী যাদের প্রকাশনার ক্রেডেনশিয়াল চুরি হয়ে গেছে, তাদের সাবধানে ট্র্যাক করা উচিত।
আরেকটি প্রাসঙ্গিক তথ্য হলো, কম্পোনেন্ট টারবলটি তৈরি করতে ব্যবহৃত সোর্স রিপোজিটরি এবং টারবলটির নিজস্ব বিষয়বস্তুর মধ্যে কোনো অমিল। এছাড়াও, ভালো অনুশীলনগুলো অনুসরণ করা, যেমন পাবলিক রেজিস্ট্রিতে প্রকাশিত কম্পোনেন্টের ভার্সনের সাথে মিলিয়ে সোর্স রিপোজিটরিতে ট্যাগ বা রিলিজ তৈরি করা। যখন কোনো নির্দিষ্ট সোর্স রিপোজিটরি... commit যদি কোনো কম্পোনেন্টকে রিলিজ হিসেবে ট্যাগ করা হয়, এবং তারপর হঠাৎ একটি ভার্সন তা অনুসরণ করতে ব্যর্থ হয়, তবে এটিই একটি জোরালো প্রমাণ যে কম্পোনেন্টটি দূষিত হতে পারে: দুষ্কৃতকারী হয়তো কম্পোনেন্টটি প্রকাশ করার জন্য ব্যবহৃত অ্যাকাউন্টটি হ্যাক করেছে, কিন্তু সোর্স কোড রিপোজিটরিতে তার লেখার অনুমতি নেই। এই নিয়মগুলো ব্যবহার করে নিয়মিতভাবে অনেক আক্রমণ শনাক্ত করা হয়: উদাহরণস্বরূপ, খাতা আক্রমণ এইভাবে সহজেই শনাক্ত করা যেতে পারে। সুতরাং, প্রেক্ষাপট বিশ্লেষণ প্রকাশনা প্রক্রিয়ার এই ধরনের অসঙ্গতিগুলো চিহ্নিত করে।
নির্ভরতা ফায়ারওয়ালিং
আরেকটি পদ্ধতি হলো আপনার সফটওয়্যারে ব্যবহৃত সমস্ত ডিপেন্ডেন্সি গ্রাফের জন্য কম্পোনেন্টগুলোর একটি বিস্তারিত হোয়াইটলিস্ট রাখা, যাতে যেকোনো বিল্ডে pipeline আপনার প্রতিষ্ঠানে শুধুমাত্র অনুমোদিত কম্পোনেন্ট সংস্করণগুলোই ইনস্টল এবং ব্যবহার করা যাবে।ফায়ারওয়ালএকটি অভ্যন্তরীণ রেজিস্ট্রি ব্যবহার করে এটি কার্যকর করা হয়, যেখানে অনুমোদিত কম্পোনেন্ট সংস্করণগুলির টারবলগুলি পরিবেশন করা হয় (ক্যাশ করা বা প্রক্সি করা)। অনুগ্রহ করে মনে রাখবেন যে, কোনো হোয়াইটলিস্টই কাজ করবে না যদি না আপনার কাছে যেকোনো নতুন সংস্করণকে যুক্তিসঙ্গতভাবে নিরাপদ হিসেবে শ্রেণীবদ্ধ করার প্রযুক্তি থাকে, যাতে সেটিকে হোয়াইটলিস্টে যুক্ত করা যায়।
অনুগ্রহ করে মনে রাখবেন যে, আগাম সতর্কীকরণ (নতুন সংস্করণ প্রকাশের পর যত তাড়াতাড়ি সম্ভব দ্রুত শনাক্তকরণ)-এর সাথে এমন একটি উপায়ও প্রয়োজন, যার মাধ্যমে বিল্ডকে প্রভাবিতকারী কম্পোনেন্টটিকে ব্লক করার জন্য সেই তথ্য সক্রিয়ভাবে ব্যবহার করা যায়। pipelineঅথবা ডেভেলপারদের মেশিন [4]আমরা এটাকে বলি “নির্ভরতা ফায়ারওয়ালিংস্বয়ংক্রিয় বিল্ডকে ক্ষতিকর প্যাকেজ থেকে রক্ষা করার জন্য একটি কোয়ারেন্টাইন ব্যবস্থা। অভ্যন্তরীণ প্যাকেজ এবং ইমেজ রেজিস্ট্রি প্রতিষ্ঠানকে বাইরের ক্ষতিকর প্রভাব থেকে সুরক্ষিত রাখতে ভালো, কিন্তু কোয়ারেন্টাইনকে কার্যকর করার জন্য যথেষ্ট জোরালো প্রমাণ থাকা প্রয়োজন।
রানটাইম স্যান্ডবক্সিং
প্রকাশনার সময় শনাক্তকরণের একটি বিকল্প পদ্ধতি হলো রানটাইমে এর আচরণ বিশ্লেষণ করা। এর মূল উদ্দেশ্য হলো সফটওয়্যারটির প্রত্যাশিত আচরণ পর্যবেক্ষণ করা এবং প্রাপ্ত যেকোনো অস্বাভাবিকতা শনাক্ত (বা ব্লক) করা। এই কার্যধারার সমস্যা হলো পর্যবেক্ষণ বা ব্লক করার জন্য রানটাইমকে ইনস্ট্রুমেন্ট করতে হয়, এবং এটি একটি সম্ভাবনাময় ধারণা যা ক্ষতিকর কম্পোনেন্টের উপদ্রবের বিরুদ্ধে সুরক্ষা ব্যবস্থার ভান্ডারে যুক্ত হবে।
একটি ব্যাপক কৌশল নির্ধারণ করা
প্রস্তাবিত কৌশলটিতে সফটওয়্যার উন্নয়ন প্রক্রিয়ার বিভিন্ন পদ্ধতির সমন্বয় প্রয়োজন, যার মধ্যে রয়েছে ভার্সন আপডেটের উপর নিয়ন্ত্রণ রেখে আগত ক্ষতিকারক উপাদানগুলোকে প্রতিরোধ করা। গুরুত্বপূর্ণ দুর্বলতাগুলোর সমাধান পেতে ভার্সন আপডেট করার মাধ্যমে স্বয়ংক্রিয় সংক্রমণ এড়াতে আমাদের অবশ্যই ভার্সন পিনিং ব্যবস্থা গ্রহণ করতে হবে; ভার্সন আপডেটের সময় প্রত্যক্ষ ও পরোক্ষ নির্ভরতাগুলোর দ্রুত ও কার্যকর মূল্যায়ন করতে হবে, যাতে সেগুলো ম্যালওয়্যার-আক্রান্ত নয় তার পর্যাপ্ত প্রমাণ থাকে। যেসব সফটওয়্যার বিল্ড পরিচিত ক্ষতিকারক উপাদানের উপর নির্ভরশীল, সেগুলোকে অবশ্যই ব্লক করতে হবে। এবং এই সবকিছুই অবশ্যই কার্যকর করতে হবে।
সম্ভব হলে ভার্সন পিনিং ব্যবহার করুন, কারণ এটি বিল্ডগুলোকে আরও পুনরুৎপাদনযোগ্য করে তোলে। নিয়ন্ত্রিত, ম্যানুয়ালি অনুমোদিত ভার্সন বাম্পের মাধ্যমে ভার্সন পিনিং, এবং সহায়ক প্রযুক্তির সাহায্যেআপডেটটি ম্যালওয়্যার নিয়ে আসে কিনা বা সফটওয়্যারটি নষ্ট করে দেয় কিনা তা মূল্যায়ন করা উচিত, এবং ম্যালওয়্যার সংক্রমণ এড়ানোর সাথে দুর্বলতাগুলি ঠিক করার জন্য আপডেট করার মধ্যে সামঞ্জস্য বিধান করা উচিত। টুলিং এখানে সাহায্য করতে পারে, (১) কোন দুর্বলতাগুলি সত্যিই গুরুত্বপূর্ণ (অ্যাক্সেসযোগ্য এবং এক্সপ্লয়টেবল, এবং আক্রমণকারীদের দ্বারা লক্ষ্যবস্তু হওয়ার উচ্চ ঝুঁকিযুক্ত) সেগুলিকে অগ্রাধিকার দিয়ে, (২) এমন টার্গেট সংস্করণ নির্বাচন করে যা বর্তমান কম্পোনেন্ট ব্যবহারের সাথে সামঞ্জস্যপূর্ণ এবং সফটওয়্যারটি নষ্ট করে না, (৩) এমন টার্গেট সংস্করণ বেছে নিয়ে যেগুলিতে ক্ষতিকারক আচরণ নেই, এবং (৪) ম্যানিফেস্ট ফাইলগুলিতে এমন পরিবর্তনের পরামর্শ দিয়ে যা দ্রুত অনুমোদিত হতে পারে, প্রত্যক্ষ এবং পরোক্ষ নির্ভরতাগুলির জন্য সংস্করণ আপডেটকে অত্যন্ত সহজ করে তোলে। ধাপ (৩)-এর জন্য ক্ষতিকারক কম্পোনেন্টগুলি সম্পর্কে তাদের প্রকাশের সময়ের যতটা সম্ভব কাছাকাছি সময়ে নির্দিষ্ট তথ্যের প্রয়োজন।
নির্ভরতা হালনাগাদ করার এই প্রক্রিয়াটি অবশ্যই হতে হবে জোরপূর্বক এবং ভেরিফাইড সব জায়গায়। প্রক্রিয়াটি অবশ্যই নথিভুক্ত করতে হবে এবং এতে জড়িত সকল পক্ষকে প্রশিক্ষণ দিতে হবে, কারণ প্রায়শই উন্নয়ন এবং সফটওয়্যার তৈরি/স্থাপনের কাজটি বাইরের কোনো সংস্থাকে দিয়ে করানো হয়। CI/CD pipelineসেই অনুযায়ী s পরিবর্তন করা উচিত, যাতে অটোমেশনের কারণে বিল্ডে কোনো ক্ষতিকর পরোক্ষ নির্ভরতা ঢুকে পড়তে না পারে: guardrails কোনো ডিপেন্ডেন্সিতে সম্ভাব্য ম্যালওয়্যারের যথেষ্ট প্রমাণ থাকলে বিল্ডটি ব্লক করে দেওয়াই হলো উত্তম পন্থা।
যদি আপনার প্রতিষ্ঠানে অনুমোদিত কম্পোনেন্ট সংস্করণগুলো সংরক্ষণের জন্য নিরাপত্তা প্রক্সি হিসেবে ব্যবহৃত কোনো অভ্যন্তরীণ রেজিস্ট্রি থাকে, তবে কোনো অনুরোধকৃত কম্পোনেন্টকে অনুমোদনের তালিকায় যুক্ত করার আগে সেটির সত্যতা যাচাইয়ের জন্য আপনাকে (অন্যান্য মানদণ্ডের পাশাপাশি) ক্ষতিকারক কম্পোনেন্ট সম্পর্কিত তথ্য সংগ্রহ করতে হবে।
নিরাপদে ওপেন-সোর্স সফটওয়্যার ব্যবহার করা সহজ নয়, এবং ম্যালওয়্যারের বিষয়টি অবশ্যই পুরোপুরি বিবেচনায় রাখতে হবে, পাশাপাশি দুর্বলতা মোকাবেলার ক্ষেত্রেও সমান প্রচেষ্টা চালাতে হবে।
একটি চূড়ান্ত নোট: উৎসের উৎপত্তিকম্পোনেন্টটি বিল্ড করার সময় তৈরি হওয়া সফটওয়্যার অ্যাটেস্টেশনের আকারে থাকা প্রমাণপত্রটি, আর্টিফ্যাক্টটিকে (কম্পোনেন্ট টারবল) তার উৎস এবং যে বিল্ড প্রসেস এটি তৈরি করেছে তার সাথে মিলিয়ে শনাক্ত করার প্রচেষ্টার আরেকটি গুরুত্বপূর্ণ অংশ। উল্লেখ্য যে, সোর্স স্ন্যাপশট ও বিল্ড এনভায়রনমেন্ট এবং সংশ্লিষ্ট সফটওয়্যার আর্টিফ্যাক্টের (যা বিশ্বস্ত বিল্ড সিস্টেম দ্বারা স্বাক্ষরিত) মধ্যে এই সংযোগটি সরাসরি এটা নিশ্চিত করে না যে কম্পোনেন্টটিতে কোনো ক্ষতিকর কার্যকলাপ নেই, কিন্তু এটি দুষ্কৃতকারীদের জন্য ম্যালওয়্যার প্রবেশ করানো কঠিন করে তোলে। এবং ওপেন সোর্স কম্পোনেন্ট ব্যবহারের জন্য প্রোভেনেন্স ভ্যালিডেশনকে একটি সাধারণ আবশ্যিক শর্তে পরিণত করতে অনেক সময় লাগবে, এবং শুধুমাত্র সম্প্রতি এনপিএম-এ যুক্ত করা হয়েছেসেই বিশ্বস্ত বিল্ড এবং ডিপ্লয় সিস্টেমগুলোকে টেম্পার-প্রুফ করা, অথবা বিল্ডের সময় যেকোনো ধরনের টেম্পারিং শনাক্ত করার ব্যবস্থা করা একটি ভিন্ন বিষয়, যা এই পোস্টের আওতার বাইরে।
আরও পড়া
পরবর্তী পর্ব ওপেন সোর্স ক্ষতিকারক প্যাকেজ: জাইজেনি পদ্ধতি Xygeni-তে আমরা যে কৌশল অনুসরণ করি তা উপস্থাপন করব আমাদের ম্যালওয়্যারের প্রাথমিক সতর্কতা (MEW) সিস্টেম। পাবলিক প্যাকেজ এবং ইমেজ রেজিস্ট্রিতে থাকা নতুন প্যাকেজ সংস্করণগুলো স্ক্যান করা হয় এবং স্ট্যাটিক, ডাইনামিক, ক্যাপাবিলিটি ও কনটেক্সচুয়াল বিশ্লেষণের সমন্বয়ে প্রমাণ সংগ্রহ করা হয়। এই প্রমাণ, ব্যবহারকারীর খ্যাতি এবং সোর্স কোড রিপোজিটরিতে পরিবর্তনের ইতিহাসের সাথে মিলিত হয়ে, একটি কম্পোনেন্টকে উচ্চ-ঝুঁকিপূর্ণ এবং সম্ভবত ক্ষতিকারক শ্রেণীতে সম্পূর্ণ স্বয়ংক্রিয়ভাবে শ্রেণীবদ্ধ করার সুযোগ করে দেয়। সিস্টেমটি প্যাকেজগুলো থেকে সংগৃহীত অতীতের প্রমাণ থেকে শেখে, যাতে ফলস পজিটিভের সংখ্যা সর্বনিম্ন পর্যায়ে নামিয়ে আনা যায়।
যখন কোনো ক্ষতিকর সংস্করণকে চিহ্নিত করা হয়, তখন সাবস্ক্রাইব করা সংস্থাগুলো তাদের প্রত্যক্ষ বা পরোক্ষভাবে ব্যবহৃত কম্পোনেন্টগুলোর জন্য একটি সতর্কীকরণ বিজ্ঞপ্তি পায়। এরপর আমাদের বিশ্লেষকরা একটি ম্যানুয়াল বিশ্লেষণ করেন, যা এই শ্রেণিবিন্যাসকে নিশ্চিত বা বাতিল করে। নিশ্চিত ম্যালওয়্যারের ক্ষেত্রে, পাবলিক রেজিস্ট্রিকে অবহিত করা হয়, যাতে তারা নিজস্ব বিশ্লেষণ করতে পারে এবং সাধারণত ক্ষতিকর সংস্করণটি সরিয়ে ফেলতে পারে অথবা অতিরিক্ত ব্যবস্থা নিতে পারে, যেমন—সংশ্লিষ্ট ব্যবহারকারীর অ্যাকাউন্টটি ব্লক বা অপসারণ করা।
আমরা ব্যাখ্যা করব কীভাবে আমরা ওপেন সোর্স ইকোসিস্টেমের NPM, PyPI, GitHub এবং অন্যান্য গুরুত্বপূর্ণ পরিকাঠামোকে সাহায্য করছি, যাতে প্রকাশিত একটি নতুন ক্ষতিকারক কম্পোনেন্ট ম্যালওয়্যার হিসেবে নিশ্চিত হয়ে রেজিস্ট্রি থেকে অপসারণ না হওয়া পর্যন্ত সক্রিয় থাকার সময়কাল কমানো যায়। এবং কীভাবে সংস্থাগুলো ওপেন সোর্স কম্পোনেন্ট-সংশ্লিষ্ট সফটওয়্যার সাপ্লাই চেইন আক্রমণের বিরুদ্ধে আরও উন্নত সুরক্ষা পেতে MEW সিস্টেম থেকে উপকৃত হতে পারে।
- [1] যাইহোক, কম্পোনেন্টটির ব্যবহারকারীদের পরীক্ষা করে দেখতে হবে যে কম্পোনেন্ট টারবলটি কোথাও ক্যাশ করা বা নিবন্ধিত আছে কিনা, যেমন কোনো অভ্যন্তরীণ রেজিস্ট্রি-তে, যাতে সমস্যাটি দূর হয়ে যায়।
- [2] প্যাকেজ করা কম্পোনেন্টটিতে একটি ম্যানিফেস্ট থাকে, যা একটি প্যাকেজিং ফরম্যাট অনুযায়ী এবং সাধারণত সংকুচিত আকারে এর বিষয়বস্তু ও মেটাডেটা, সোর্স বা কম্পাইল করা কোড, ইনস্টলেশন স্ক্রিপ্ট এবং টেস্ট স্যুটের মতো অতিরিক্ত আইটেমগুলো ঘোষণা করে। একে “কম্পোনেন্ট টারবল” বলা হয়।
- [3] এমনকি যদি কোনো ক্ষতিকারক ব্যক্তি রেজিস্ট্রিতেই কোনো ত্রুটির কারণে প্রকাশিত কোনো কম্পোনেন্ট পরিবর্তন করতে পারে, তবুও বিশ্লেষণ সম্পন্ন হওয়ার পর একটি সাধারণ ক্রিপ্টোগ্রাফিক ডাইজেস্টের মাধ্যমে টারবলটির যেকোনো পরিবর্তন শনাক্ত করা যায়।
- [4] মনে রাখবেন যে কিছু ক্ষতিকারক উপাদান ইনস্টলের সময় চালু হয়, তাই এটি সেইসব ডেভেলপার নোডকে প্রভাবিত করতে পারে যারা অজান্তেই কোনো ক্ষতিকারক উপাদানকে ব্যবহার করে “npm install X” কমান্ডটি চালায়।
