Dependency ও supply chain নিরাপত্তা: package থেকে অ্যাপ রক্ষা

আধুনিক অ্যাপ্লিকেশন বেশিরভাগই অন্যদের কোড। সাধারণ ওয়েব প্রজেক্ট সরাসরি ও পরোক্ষ (transitive) dependency দিয়ে শত বা হাজার package টানে। এটি শক্তিশালী, কিন্তু মানে আপনার নিরাপত্তা এমন কোডের ওপর নির্ভর করে যা আপনি লেখেননি এবং হয়তো কখনো পড়বেন না। Software supply chain আক্রমণ এই বিশ্বাসকে লক্ষ্য করে।

এটি প্রতিরক্ষামূলক নির্দেশিকা। এটি ঝুঁকি কমাতে এবং শান্তভাবে সাড়া দিতে সাহায্য করে।

Supply chain সমস্যা কীভাবে ঘটে

• ঝুঁকিপূর্ণ dependency: library-তে জানা নিরাপত্তা bug আছে যা আপনার অ্যাপকে প্রভাবিত করে। এটিই সবচেয়ে সাধারণ সমস্যা।
• ক্ষতিকর package: আক্রমণকারী ক্ষতিকর কোডসহ package প্রকাশ করে, প্রায়ই জনপ্রিয়গুলোর মতো নামে (typosquatting), বা এমন নামে যা ভেতরের প্রজেক্ট ভুলে টেনে আনতে পারে (dependency confusion)।
• আপস হওয়া maintainer বা অ্যাকাউন্ট: বৈধ package দখল হয়, বা maintainer-এর token চুরি হয় এবং খারাপ সংস্করণ প্রকাশিত হয়।
• পরিত্যক্ত package: অরক্ষণাবেক্ষিত কোড যা কখনো সংশোধন পায় না, বা নতুন অবিশ্বস্ত মালিকের হাতে চলে যায়।
• Install-সময়ে কোড চালানো: package install হওয়ার সময় script (যেমন postinstall) চালাতে পারে, যা developer মেশিন ও CI server-এ চলে।
• Build ও CI আপস: আক্রমণকারী কোড নয়, pipeline, CI-র secret বা build টুলকে লক্ষ্য করে।
• আপস হওয়া CDN বা script include: আপনার পেজে লোড হওয়া তৃতীয় পক্ষের script বদলায় বা ছিনতাই হয়।

অভ্যাস ১: কীসের ওপর নির্ভর করছেন জানুন

• ছোট dependency গাছ রাখুন। প্রতিটি package বাড়তি ঝুঁকি। যোগ করার আগে জিজ্ঞেস করুন: সত্যিই কি দরকার, এটি কি রক্ষণাবেক্ষিত, এবং নিজের কয়েক লাইন কোড কি কাজ চালাতে পারে?
• অনেক ব্যবহারকারী, সাম্প্রতিক release, পরিষ্কার repository ও দায়িত্বশীল নিরাপত্তা নীতিসহ সুপরিচিত, সক্রিয়ভাবে রক্ষণাবেক্ষিত package পছন্দ করুন।
• Typosquat এড়াতে install করার আগে package-এর নাম সাবধানে দেখুন। publisher, ডাউনলোড ইতিহাস ও repository লিংক দেখুন।
• নতুন dependency নিজে কী টানে তা পর্যালোচনা করুন।
• CycloneDX বা SPDX-এর মতো আদর্শ ফরম্যাটে SBOM (software bill of materials), আপনার software-এর উপাদান ও সংস্করণের তালিকা, বানান। নতুন দুর্বলতা ঘোষণা হলে "আমরা কি প্রভাবিত?" দ্রুত জানতে এটি সাহায্য করে।

অভ্যাস ২: lockfile ও পুনরুৎপাদনযোগ্য install

• Lockfile (package-lock.json, pnpm-lock.yaml, yarn.lock, poetry.lock, go.sum, Cargo.lock ইত্যাদি) commit করুন। এটি হুবহু সংস্করণ ও integrity hash রেকর্ড করে, ফলে সবাই একই কোড install করে।
• CI ও production build-এ সংস্করণ হালনাগাদ করে এমন কমান্ডের বদলে lockfile ও manifest না মিললে ব্যর্থ হওয়া কড়া install কমান্ড ব্যবহার করুন, যেমন npm ci।
• খুব শিথিল সংস্করণ পরিসর (*, latest) থেকে সাবধান, যা স্বয়ংক্রিয়ভাবে নতুন, অপর্যালোচিত কোড টেনে আনতে পারে।
• গুরুত্বপূর্ণ package-এ হুবহু সংস্করণ pin করা এবং ইচ্ছাকৃতভাবে হালনাগাদ করা ভাবুন।

অভ্যাস ৩: নিয়মিত scan ও হালনাগাদ

• CI-তে vulnerability scanner চালান: npm audit, pip-audit, govulncheck, GitHub Dependabot alert, বা OSV-Scanner, Trivy বা Snyk-এর মতো টুল। ফলাফলকে বিচারের ইনপুট ধরুন। প্রতিটি পাওয়া সমস্যা আপনার ব্যবহারে কাজে লাগানোর যোগ্য নয়, তবে গুরুতরগুলো উপেক্ষা করবেন না।
• স্বয়ংক্রিয় হালনাগাদ pull request (Dependabot বা Renovate) চালু করুন যাতে নিরাপত্তা সংশোধন দ্রুত আসে, তারপর পর্যালোচনা ও test করুন।
• ছোট ধাপে নিয়মিত হালনাগাদ করুন। বিশাল, বিরল upgrade ঝুঁকিপূর্ণ এবং পিছিয়ে যায়।
• অব্যবহৃত dependency সরান।
• সমর্থন শেষ হওয়া runtime ও framework ট্র্যাক করুন, কারণ অসমর্থিত সংস্করণ সংশোধন পায় না।

অভ্যাস ৪: খারাপ package কী করতে পারে তা কমান

• Install script সীমিত করুন। অনেক ecosystem যেসব package-এর দরকার নেই তাদের lifecycle script বন্ধ বা সীমিত করতে দেয় (যেমন npm-এ --ignore-scripts, বা কিছু package manager-এ allow-list)। আপনার build এখনো কাজ করে কি না পরীক্ষা করুন।
• দীর্ঘস্থায়ী secret ছাড়া বিচ্ছিন্ন পরিবেশে (container বা CI runner) build ও test চালান।
• CI job-কে least-privilege token দিন, সম্ভব হলে স্বল্পস্থায়ী, এবং fork থেকে আসা pull request build-এ production secret প্রকাশ এড়ান।
• ভেতরের package-এর জন্য private registry বা scope করা package নাম ব্যবহার করুন এবং package manager এমনভাবে কনফিগার করুন যাতে ভেতরের নাম সবসময় ভেতরের registry থেকে আসে (এটি dependency confusion ঠেকায়)।
• অ্যাপ root হিসেবে চালাবেন না এবং সাধারণ hardening প্রয়োগ করুন, যাতে আপস হওয়া dependency-র runtime-এ নাগাল কম থাকে।

অভ্যাস ৫: আপনার pipeline শক্তিশালী করুন

• তৃতীয় পক্ষের CI action ও image নির্দিষ্ট সংস্করণে, এবং সংবেদনশীল workflow-এ চলমান tag-এর বদলে অপরিবর্তনীয় commit hash বা digest-এ pin করুন।
• Main branch সুরক্ষিত করুন: pull request পর্যালোচনা ও পাস করা যাচাই বাধ্যতামূলক।
• Registry, source-control ও cloud অ্যাকাউন্টে two-factor authentication ব্যবহার করুন এবং দীর্ঘস্থায়ী publish token-এর বদলে trusted publishing বা স্বল্পস্থায়ী token পছন্দ করুন।
• নিজের package কে প্রকাশ করতে পারে সীমিত করুন, এবং build script ও CI configuration-এর বদল কোডের মতোই সাবধানে পর্যালোচনা করুন।
• Package প্রকাশের সময় signed commit ও signed release এবং আপনার platform-এর দেওয়া provenance সুবিধা (যেমন build provenance attestation) ভাবুন।

অভ্যাস ৬: front-end ও তৃতীয় পক্ষের script

• তৃতীয় পক্ষের script ন্যূনতম রাখুন। প্রতিটি আপনার পেজ পড়তে ও বদলাতে পারে।
• CDN থেকে লোড হওয়া script ও style-এ Subresource Integrity (SRI) ব্যবহার করুন, যাতে browser বদলে যাওয়া ফাইল প্রত্যাখ্যান করে: <script src="..." integrity="sha384-..." crossorigin="anonymous"></script>
• Script কোথা থেকে লোড হতে পারবে সীমিত করতে Content Security Policy ব্যবহার করুন।
• বাস্তবসম্মত হলে গুরুত্বপূর্ণ asset নিজে host করুন।

অভ্যাস ৭: সাড়া দিতে প্রস্তুত থাকুন

আপনার ব্যবহৃত package আপস বা ঝুঁকিপূর্ণ বলে জানা গেলে:

১. প্রকাশ যাচাই করুন: lockfile, SBOM বা scanner দিয়ে package ও সংস্করণ কোথায় আছে খুঁজুন। ২. নিরাপদ সংস্করণে হালনাগাদ বা pin করুন, বা package সরান। Maintainer-এর advisory অনুসরণ করুন। ৩. ক্ষতিকর সংস্করণ আপনার পরিবেশে (developer ল্যাপটপ, CI, server) চলে থাকতে পারে মনে হলে, সেখানে থাকা secret প্রকাশিত ধরুন: token, key ও পাসওয়ার্ড বদলান এবং অস্বাভাবিক কার্যকলাপের জন্য log দেখুন। ৪. পরিষ্কার অবস্থা থেকে আবার build ও redeploy করুন। ৫. এ থেকে শিখুন: অনুমতি কড়া করুন, script সীমিত করুন ও alert উন্নত করুন।

আপনার মূল ecosystem ও প্রজেক্টের নিরাপত্তা advisory-তে subscribe করুন।

দ্রুত checklist

• ছোট, পর্যালোচিত dependency তালিকা, সঠিক package নাম।
• Lockfile commit করা, CI-তে npm ci-ধাঁচের কড়া install।
• স্বয়ংক্রিয় scan ও হালনাগাদ pull request।
• Install script সীমিত, build বিচ্ছিন্ন, CI-তে দীর্ঘস্থায়ী secret নেই।
• ভেতরের package dependency confusion থেকে সুরক্ষিত।
• Pin করা CI action, branch protection, 2FA, least-privilege token।
• তৃতীয় পক্ষের script-এ SRI ও CSP।
• ঘটনা পরিকল্পনা: খুঁজুন, হালনাগাদ, বদলান, আবার build।

মূল কথা: প্রতিটি package-এর প্রতিটি লাইন audit করা যায় না, তাই নির্ভরতা কমান, সংস্করণ lock ও scan করুন, install ও build কী করতে পারে তা সীমিত করুন, pipeline শক্তিশালী করুন এবং secret বদলাতে ও দ্রুত হালনাগাদ করতে প্রস্তুত থাকুন।

---

ওয়েব নিরাপত্তা সিরিজ, পর্ব ৩ (অ্যাকাউন্ট ও প্রতিরক্ষা): 4 নম্বর (মোট 5)। আগের লেখা: নিরাপদ session ও cookie: HttpOnly, Secure, SameSite.