HackCert
Advanced 11 min read May 25, 2026

Dependency Hijacking: আপনার অ্যাপ্লিকেশনের ওপেন সোর্স লাইব্রেরির নিরাপত্তা ঝুঁকি!

Open source dependency hijacking-এর বিভিন্ন কৌশল, বাস্তব ঘটনা এবং আপনার application protect করার advanced strategy।

Omar Faruq Hossain
Supply Chain Security Researcher
share
Dependency Hijacking: আপনার অ্যাপ্লিকেশনের ওপেন সোর্স লাইব্রেরির নিরাপত্তা ঝুঁকি!
Overview

আধুনিক সফটওয়্যার প্রকৃত অর্থেই একটি ককটেল। একটি সাধারণ web application-এ যে কোডটি আপনি লেখেন, সেটা মোট কোডের ১০ শতাংশের কম। বাকি ৯০ শতাংশ আসে open source library, framework, এবং transitive dependency থেকে। এই বিশাল ecosystem আপনাকে দ্রুত develop করতে সাহায্য করে, কিন্তু এর সাথেই আসে একটি বিশাল attack surface— যেখানে একজন আক্রমণকারী আপনার কোডের কোনো line স্পর্শ না করেও আপনার application compromise করতে পারে।

Dependency Hijacking হলো এই attack surface-এর গভীরে প্রবেশের কৌশল। এখানে আক্রমণকারী একটি existing, trusted open source package-এর নিয়ন্ত্রণ নিয়ে নেন এবং সেখানে malicious code inject করেন। যেহেতু এই package-এ ইতিমধ্যেই হাজার হাজার application নির্ভরশীল, একটি successful hijack লক্ষ লক্ষ end user-কে প্রভাবিত করতে পারে। এই নিবন্ধে আমরা advanced level-এ dependency hijacking-এর বিভিন্ন কৌশল, বাস্তব ঘটনা এবং সর্বাধুনিক প্রতিরক্ষা পদ্ধতি বিশ্লেষণ করব।

মূল ধারণা

Dependency Hijacking হলো এমন আক্রমণ, যেখানে আক্রমণকারী একটি বৈধ open source dependency-এর publishing rights বা codebase-এর নিয়ন্ত্রণ গ্রহণ করেন, এবং তারপর সেই package-এ malicious code inject করেন। Dependency Confusion থেকে এটি ভিন্ন— Dependency Confusion-এ একটি নতুন malicious package upload করা হয় বৈধ name-এ; Dependency Hijacking-এ existing বৈধ package-কেই কব্জা করা হয়।

এই আক্রমণ কয়েকটি প্রধান উপায়ে ঘটে। প্রথমত, Account Takeover— maintainer-এর npm, PyPI, বা GitHub account compromise করে। দ্বিতীয়ত, Social Engineering— legitimate-looking offer (যেমন "আমি এই project maintain করতে চাই, আপনি কি আমাকে publishing access দেবেন?")। তৃতীয়ত, Maintainer Burnout— overworked open source maintainer যারা একটি স্বেচ্ছাসেবক "co-maintainer"-কে সহজেই access দেন। চতুর্থত, Package Acquisition— আক্রমণকারী maintainer-কে money offer করে package কেনেন।

Transitive Dependency-এর সমস্যা এই হুমকিকে multiplier দিয়ে বাড়িয়ে দেয়। আপনি direct-ভাবে যে package install করেন, সেটা নিজেই অন্যান্য package-এর ওপর নির্ভরশীল— এবং সেগুলো আবার অন্য package-এর ওপর। একটি modern JavaScript project-এ প্রায়ই ১০০০-এর বেশি transitive dependency থাকে। যেকোনো একটি hijacked হলে সম্পূর্ণ application ঝুঁকিতে।

Software Bill of Materials বা SBOM— প্রতিটি deployed application-এ থাকা সমস্ত component-এর comprehensive inventory— এই হুমকি মোকাবেলার ভিত্তি। কিন্তু SBOM শুধু একটি list; এর মূল্য তৈরি হয় যখন এটি real-time threat intelligence-এর সাথে যুক্ত হয়।

প্রধান আক্রমণ কৌশল

Account Takeover সবচেয়ে সাধারণ vector। ২০১৮ সালের event-stream ঘটনায় একজন আক্রমণকারী legitimate-looking offer দিয়ে এই popular npm package-এর maintenance handover পেয়েছিলেন। কয়েক মাস swap-এর পর তিনি malicious code inject করেন যা Bitcoin wallet— Copay— থেকে private key চুরি করত। এই package-এর সপ্তাহে ২ মিলিয়ন download ছিল।

Credential Stuffing এবং Phishing-এর মাধ্যমে maintainer account compromise করা একটি প্রচলিত method। ২০২২ সালে npm-এ একটি phishing campaign maintainer-দের লক্ষ্য করেছিল— ভুয়া security alert email পাঠানো হয়েছিল যা npm login page-এ নিয়ে যেত, এবং তাদের credential চুরি করত।

Maintainer Trust Exploitation আরো subtle। একজন আক্রমণকারী মাসের পর মাস বৈধ contribution করেন একটি project-এ। তিনি maintainer-এর trust অর্জন করেন। তারপর তাকে co-maintainer status দেওয়া হলে তিনি subtle malicious change introduce করেন। এই কৌশল colors.js-এ ২০২২ সালে কিছুটা দেখা গিয়েছিল, যেখানে maintainer নিজেই infinite loop যোগ করে দিয়েছিলেন protest হিসেবে— কিন্তু এই same vector আক্রমণকারীরাও ব্যবহার করতে পারেন।

Typosquatting— legitimate package-এর সামান্য misspelled নামে malicious package upload— পরিচিত। কিন্তু এর evolution হলো Brandjacking— legitimate brand-এর প্রায় identical নামে package তৈরি (যেমন python3-dateutil বনাম legitimate python-dateutil)।

Compromised Build Infrastructure আরো advanced। আক্রমণকারীরা CI/CD পrocess-এ infiltrate করে— legitimate package-এর actual maintainer অজান্তেই malicious version publish করেন। SolarWinds Sunburst attack এই কৌশলের সবচেয়ে বিখ্যাত উদাহরণ।

Maintainer Acquisition— এক ধরনের নতুন প্রবণতা। নিরাপত্তা গবেষক Marak Squires-এর কথা মনে রাখা যেতে পারে, যিনি নিজের package "vandalize" করেছিলেন। কিন্তু একই কৌশল ব্যবহার করে আক্রমণকারী maintainer-কে অর্থের বিনিময়ে package "কিনে" নিতে পারেন। ২০২২ সালে এক report-এ দেখা যায়, কয়েকজন maintainer তাদের popular npm package $৫০-$১০০-এ বিক্রি করার offer পেয়েছিলেন।

বাস্তব ঘটনাবলী

event-stream ঘটনা (২০১৮): একজন user নাম Right9ctrl একটি pull request পাঠিয়ে দেখান যে তিনি project maintain করতে চান। মূল maintainer Dominic Tarr— যিনি project-এ আর interested ছিলেন না— তাকে publish rights দিয়ে দেন। নতুন maintainer তিনটি minor release করেন, যার শেষটিতে flatmap-stream নামে একটি নতুন dependency যোগ করেন। সেই dependency-তে obfuscated malicious code ছিল যা specifically Copay— একটি Bitcoin wallet— এ ব্যবহৃত হলে activate হতো এবং private key চুরি করতো। এই incident open source maintainer responsibility সম্পর্কে আলোচনা উসকে দিয়েছিল।

ua-parser-js (২০২১): সপ্তাহে ৮ মিলিয়ন download-এর এই popular package-এর maintainer-এর npm account compromise হয়েছিল। তিনটি malicious version publish হয়েছিল যা cryptocurrency miner এবং password stealer install করত। Maintainer দ্রুত response করে clean version release করেছিলেন, কিন্তু কয়েক ঘণ্টার ক্ষতি অপরিসীম।

coa এবং rc (২০২১): দুটি বহুল ব্যবহৃত npm package-এর maintainer-এর account hijack হয়েছিল। আক্রমণকারী এমন code inject করেছিলেন যা Windows machine-এ password stealer download করে। এই দুটি package সরাসরি ২০ মিলিয়ন+ weekly download করত, কিন্তু transitively এদের ব্যবহার আরো অনেক বেশি ছিল।

PHP xz-utils Backdoor (২০২৪): Linux ecosystem-এর জন্য সম্ভবত সবচেয়ে পরিশীলিত supply chain attack। একজন আক্রমণকারী— নাম "Jia Tan"— প্রায় তিন বছর ধরে xz-utils project-এ legitimate contribution করেন। ধীরে ধীরে তিনি maintainer trust অর্জন করেন এবং eventually co-maintainer হন। তারপর তিনি obfuscated build process-এর মধ্যে একটি backdoor inject করেন, যা SSH server-এর authentication bypass করতে পারত। Microsoft-এর Andres Freund accidentally এটি আবিষ্কার করেন যখন তিনি SSH login performance anomaly investigation করছিলেন। যদি এটি detected না হতো, প্রায় সমস্ত Linux system আক্রান্ত হতে পারত।

Solorigate/SUNBURST (২০২০): SolarWinds-এর Orion software-এর update mechanism-এ আক্রমণকারীরা malicious code inject করেছিল। প্রায় ১৮,০০০ কাস্টমার আক্রান্ত হয়েছিল, যার মধ্যে US Treasury, Pentagon এবং Fortune 500 প্রতিষ্ঠান ছিল। এটি package registry-এর মতো নয়, কিন্তু supply chain attack-এর model একই— legitimate update channel-এর মাধ্যমে malicious code।

প্রযুক্তিগত গভীরতা

Modern Dependency Hijacking-এর success-এর পেছনে কয়েকটি ecosystem-level dynamic কাজ করে। প্রথমত, Volunteer Maintainer Model। অধিকাংশ open source package volunteer-দের দ্বারা maintained, যারা limited time, resource এবং security expertise সহ কাজ করেন। তাদের 2FA setup, secure development practice, এবং threat modeling-এর সক্ষমতা সীমিত।

দ্বিতীয়ত, Trust Inheritance। যখন আপনি একটি package-কে trust করেন, আপনি transitively সেই package-এর সমস্ত dependency-কেও trust করেন। আপনি যদি দশ direct dependency ব্যবহার করেন, কিন্তু সেগুলোর সমষ্টিগত transitive tree-এ ৫০০ package থাকে, আপনি সেই ৫০০ package-এর সব maintainer-কে implicitly trust করছেন।

তৃতীয়ত, Automated Update Pipeline। Dependabot, Renovate, এবং অন্যান্য tool automated dependency update PR তৈরি করে। যদি review process strong না হয়, malicious update accidentally merged হয়ে যেতে পারে।

Malicious Code-এর obfuscation কৌশল advanced। Post-install script-এর মধ্যে base64 encoded payload, conditional execution (শুধু production environment-এ active), time bomb (specific date-এর পর activate), geofencing (নির্দিষ্ট country-তে), এবং environment fingerprinting (সরাসরি sandbox detection)— এসব ব্যবহার হয়। কিছু আক্রমণ এমন subtle যে শুধু কয়েক হাজার ব্যবহারকারীকে impact করে যারা specific criteria match করেন।

Payload-এর variety-ও বিশাল। Cryptocurrency wallet stealing (একটি জনপ্রিয় target যেহেতু financial gain তাৎক্ষণিক), credential harvesting (.npmrc, .aws/credentials, SSH keys), backdoor installation, cryptocurrency mining, এবং most concerning— targeted espionage যেখানে শুধু specific organization-কে infect করা হয়।

প্রতিরোধ ও প্রতিকার

Defense-in-depth approach এই হুমকির বিরুদ্ধে অপরিহার্য। প্রথম স্তর— Selection। নতুন dependency add করার আগে careful evaluation। Package-এর maintainer activity, security history, recent change pattern, এবং community trust— সব যাচাই করতে হবে। Sole-maintainer package, যেগুলোর শুধু একজন maintainer আছেন, তারা bus factor এবং hijacking risk-এর জন্য বেশি ঝুঁকিপূর্ণ।

দ্বিতীয় স্তর— Pinning এবং Verification। package-lock.json-এ exact version pin এবং integrity hash থাকতে হবে। npm ci ব্যবহার করুন npm install-এর পরিবর্তে production build-এ। Subresource Integrity বা SRI-এর মতো verification mechanism প্রয়োগ করুন।

তৃতীয় স্তর— Automated Scanning। Socket.dev, Snyk, GitHub Advanced Security, Sonatype Lifecycle— এই ধরনের tool real-time-এ suspicious package change শনাক্ত করতে পারে। Socket-এর বিশেষত্ব হলো এটি specifically supply chain attack-এর জন্য designed— নতুন install script, suspicious telemetry, এবং hidden behavior শনাক্ত করে।

চতুর্থ স্তর— SBOM Generation এবং Tracking। CycloneDX, SPDX-এর মতো format-এ প্রতিটি build-এর জন্য SBOM তৈরি করুন। এই SBOM-গুলো centralized inventory-এ রাখুন। যখন কোনো dependency-তে security issue প্রকাশিত হয়, এই inventory থেকে দ্রুত শনাক্ত করা যায় কোন application impacted।

পঞ্চম স্তর— Sigstore এবং Cosign। Modern signing infrastructure যা cryptographic provenance verification সম্ভব করে। npm-এ provenance attestation সুবিধা যোগ হয়েছে— maintainer build process-এর প্রমাণসহ package publish করতে পারেন। এটি SLSA-compliant build chain-এর ভিত্তি।

ষষ্ঠ স্তর— Update Discipline। সব update immediately accept করার পরিবর্তে cooldown period implementation করুন। কোনো new version publish হওয়ার ২৪-৪৮ ঘণ্টা পর্যন্ত অপেক্ষা করুন; এই সময়ের মধ্যে অনেক malicious update community-র দ্বারা শনাক্ত এবং unpublished হয়। npm-এ Wally, dependency-cruiser, এবং DeepSource-এর মতো tool এই pattern সমর্থন করে।

সপ্তম স্তর— Allowlist-based Package Manager। JFrog Curation, Artifactory-এর policy management, এবং Endor Labs-এর মতো commercial solution একটি curated dependency catalog maintain করে। শুধু approved package-ই allowed। নতুন package introduce করতে formal review process।

অষ্টম স্তর— Runtime Behavior Monitoring। Even যদি malicious code install হয়ে যায়, runtime monitoring এটাকে action নেওয়া থেকে আটকাতে পারে। Falco, Tracee, এবং eBPF-based tool unusual system call, network connection, এবং file access শনাক্ত করতে পারে।

Organizational এবং Process-level কৌশল

Open Source Program Office বা OSPO তৈরি করুন। বড় প্রতিষ্ঠানে এই dedicated team open source consumption-এর governance manage করে— কোন license acceptable, কোন package allowed, security review process, এবং upstream contribution strategy।

Tiered Risk Management approach নিন। Production code-এ ব্যবহৃত dependency-এর জন্য কঠোর review, internal tooling-এর জন্য moderate review, এবং experimental project-এর জন্য কম strict— এভাবে practical balance বজায় রাখা যায়।

Dependency Update Strategy-তে security update এবং feature update আলাদা করুন। Security update দ্রুত apply করতে হবে; feature update আগে carefully evaluate করতে হবে।

Internal Mirror এবং Caching Proxy ব্যবহার করুন। সমস্ত package public registry থেকে সরাসরি ফেচ করার পরিবর্তে centralized internal mirror-এর মাধ্যমে আসুক। এটি malicious update-এর rollback এবং forensic investigation সহজ করে।

Incident Response Playbook-এ supply chain compromise scenario রাখুন। কীভাবে দ্রুত শনাক্ত করব কোন application affected, কীভাবে rollback করব, কীভাবে blast radius determine করব, এবং কীভাবে customer notify করব— এসব pre-defined থাকতে হবে।

Threat Intelligence Subscription— Socket.dev, Snyk Intel, Sonatype OSS Index, এবং GitHub Security Advisory— এই sources থেকে real-time alert সংগ্রহ করুন। নতুন malicious package দ্রুত শনাক্ত করার জন্য এই intelligence অপরিহার্য।

ভবিষ্যৎ পরিদৃশ্য

Supply Chain Security এখন regulatory দিক থেকেও পরিপূর্ণ মনোযোগ পাচ্ছে। US Executive Order 14028 এবং পরবর্তী guidance-এ federal software supplier-দের জন্য SBOM বাধ্যতামূলক হয়েছে। EU-এর Cyber Resilience Act তৈরি commercial software-এর জন্য কঠোর supply chain requirement-এ মুখর। বাণিজ্যিক চাপ এবং regulatory pressure এই দিকে দ্রুত পরিবর্তন আনছে।

AI-driven analysis future-এ গুরুত্বপূর্ণ ভূমিকা পালন করবে। Large language model-গুলো এখন package code analyze করে suspicious pattern শনাক্ত করতে পারে— অনেক বেশি granular level-এ যা traditional rule-based scanner পারে না। Pattern-based detection-এর সাথে behavioral analysis মিলিয়ে আরো নির্ভুল threat hunting সম্ভব হবে।

Reproducible Build আরেকটি প্রতিশ্রুতিশীল দিক। যদি একই source code থেকে byte-for-byte identical binary তৈরি করা যায়, তাহলে published artifact-এ tampering শনাক্ত করা সহজ। Debian এবং Bazel-এর মতো ecosystem এই দিকে অগ্রসর।

Maintainer Funding এবং Sustainability— এটি একটি socio-technical সমস্যা। যতদিন critical open source infrastructure unpaid volunteer-দের কাছ থেকে আসে, ততদিন hijacking risk থাকবে। Open Source Pledge, Tidelift, এবং GitHub Sponsors-এর মতো initiative এই সমস্যার সমাধানে কাজ করছে।

Key Takeaways

Dependency Hijacking আধুনিক সফটওয়্যার নিরাপত্তার সবচেয়ে কঠিন challenge-এর একটি। এটি প্রযুক্তিগত সমস্যা যেমন, তেমনই সামাজিক এবং arrhythmically organizational সমস্যাও। কোনো একক tool বা practice এই হুমকি সম্পূর্ণভাবে মোকাবেলা করতে পারে না; প্রয়োজন একটি comprehensive supply chain security program যা প্রযুক্তিগত নিয়ন্ত্রণ, organizational discipline, এবং continuous vigilance-এর সমন্বয়ে গঠিত।

প্রতিটি dependency একটি trust relationship। প্রতিটি npm install, প্রতিটি pip install, প্রতিটি gem install— আপনি যাকে চিনেন না, এমন কারো লেখা কোডের ওপর নির্ভর করছেন। এই বাস্তবতা এড়িয়ে আধুনিক সফটওয়্যার develop করা সম্ভব নয়; কিন্তু এই বাস্তবতা সম্পর্কে সচেতন হয়ে, সঠিক process এবং tool প্রয়োগ করে, আমরা ঝুঁকিকে manageable level-এ রাখতে পারি। আগামী দশকের সাইবার নিরাপত্তার সবচেয়ে গুরুত্বপূর্ণ যুদ্ধ supply chain-এই হবে— এবং সেই যুদ্ধে জয়ী হওয়ার প্রস্তুতি আজই শুরু করতে হবে।

আপনার জ্ঞান যাচাই করতে প্রস্তুত? আজই HackCert-এ Dependency Hijacking MCQ Quiz-টি দিন!

Related articles

back to all articles