Pipeline Poisoning: সফটওয়্যার রিলিজ পাইপলাইনে ক্ষতিকর কোড ইনজেক্ট করার সাইবার ঝুঁকি!

Pipeline Poisoning হলো এমন একটি আক্রমণ যেখানে আক্রমণকারী সফটওয়্যার Build, Test বা Deploy পাইপলাইনের কোনো একটি ধাপে ক্ষতিকর পরিবর্তন প্রবেশ করায়। ফলাফল হলো—যে আউটপুট আর্টিফ্যাক্ট (Binary, Container Image, Package) উৎপাদিত হয় তা ক্ষতিকর কোড বহন করে, অথচ Source Code পরিদর্শনে কোনো সমস্যা ধরা পড়ে না। Git Repository সম্পূর্ণ পরিষ্কার থাকতে পারে কিন্তু চূড়ান্ত আর্টিফ্যাক্ট সংক্রমিত—এটিই Pipeline Poisoning-কে এতো বিপজ্জনক করে।

OWASP তাদের CI/CD Security Top 10-এ এই শ্রেণীর আক্রমণকে "Poisoned Pipeline Execution (PPE)" নামে চিহ্নিত করেছে। SLSA (Supply-chain Levels for Software Artifacts) ফ্রেমওয়ার্কে Build Integrity-কে সাপ্লাই চেইন নিরাপত্তার মৌলিক স্তম্ভ হিসেবে বিবেচনা করা হয়েছে। Pipeline Poisoning শুধু এক ধরনের আক্রমণ নয়—এটি একটি বিস্তৃত শ্রেণী যার অধীনে Direct PPE, Indirect PPE এবং Public PPE-এর মতো বিভিন্ন উপ-প্রকার রয়েছে।

Direct Poisoned Pipeline Execution বা D-PPE আক্রমণে আক্রমণকারী সরাসরি পাইপলাইন কনফিগারেশন ফাইল (Jenkinsfile, .gitlab-ci.yml, .github/workflows/*.yml) পরিবর্তন করেন। যদি কেউ একটি Pull Request-এ পাইপলাইন কনফিগারেশন পরিবর্তন করে এবং সেই PR স্বয়ংক্রিয়ভাবে CI চালায়, তাহলে আক্রমণকারীর কোড পাইপলাইন রানারের প্রসঙ্গে চলে। এটি বিশেষভাবে বিপজ্জনক কারণ পাইপলাইন রানারের সাধারণত অনেক বেশি অধিকার থাকে—Secret-এ অ্যাক্সেস, ডেপ্লয়মেন্ট অনুমতি, সাইনিং কী, এবং অন্যান্য সংবেদনশীল সম্পদ।

Indirect Poisoned Pipeline Execution বা I-PPE আক্রমণে আক্রমণকারী সরাসরি পাইপলাইন কনফিগ পরিবর্তন না করে পাইপলাইন যেসব ফাইল ব্যবহার করে—যেমন Build স্ক্রিপ্ট, Makefile, package.json, requirements.txt, build.gradle, Dockerfile—সেগুলো পরিবর্তন করেন। এই ফাইলগুলো রিভিউ ছাড়াই সাধারণত পাইপলাইনে কার্যকর হয়। উদাহরণস্বরূপ, package.json-এর postinstall স্ক্রিপ্টে একটি ক্ষতিকর কমান্ড যোগ করলে npm install চলাকালীন সেই কমান্ড পাইপলাইন রানারের প্রসঙ্গে চলবে।

Public PPE-তে আক্রমণকারী Open Source প্রকল্পের Pull Request মেকানিজম কাজে লাগান। অনেক প্রকল্পে Fork থেকে আসা PR-এ স্বয়ংক্রিয়ভাবে CI চলে—এমনকি প্রথমবার অবদানকারীর জন্যও। আক্রমণকারী একটি ক্ষতিকর PR জমা দিয়ে CI পরিবেশে কোড এক্সিকিউশন অর্জন করতে পারেন, যেখানে প্রকল্পের Secret (PyPI টোকেন, Docker Hub শংসাপত্র, GitHub PAT) সংরক্ষিত থাকে।

Dependency Confusion এবং Typosquatting Pipeline Poisoning-এর সাথে ঘনিষ্ঠভাবে সম্পর্কিত। Alex Birsan ২০২১ সালে প্রমাণ করেছিলেন কীভাবে অভ্যন্তরীণ প্যাকেজ নামের সাথে মিলিয়ে পাবলিক রেজিস্ট্রিতে (npm, PyPI) প্যাকেজ আপলোড করলে অনেক CI/CD সিস্টেম অভ্যন্তরীণ প্যাকেজের পরিবর্তে পাবলিক ভার্সন ডাউনলোড করে। এই কৌশলে তিনি Apple, Microsoft, Tesla-সহ ৩৫টি বড় কোম্পানির সিস্টেমে কোড এক্সিকিউশন অর্জন করেছিলেন।

GitHub Actions-এ pull_request_target ট্রিগার ঐতিহাসিকভাবে অনেক প্রকল্পে অপব্যবহৃত হয়েছে। সাধারণ pull_request ইভেন্টে workflow Fork-এর কোডের প্রসঙ্গে চলে এবং Secret-এ অ্যাক্সেস থাকে না। কিন্তু pull_request_target-এ workflow Base Repository-র প্রসঙ্গে চলে এবং সম্পূর্ণ Secret-এ অ্যাক্সেস থাকে। যদি workflow PR-এর কোড checkout করে এবং তা execute করে, তাহলে আক্রমণকারী Secret চুরি করতে পারেন।

Self-hosted Runner-এর নিরাপত্তা আরেকটি গুরুতর ক্ষেত্র। GitHub Actions-এর Self-hosted Runner যদি Public Repository-তে সংযুক্ত থাকে এবং Fork PR-এ স্বয়ংক্রিয়ভাবে চলতে দেওয়া হয়, তাহলে আক্রমণকারী Runner Machine-এ কোড এক্সিকিউশন অর্জন করতে পারেন। Runner সাধারণত কোম্পানির অভ্যন্তরীণ নেটওয়ার্কে থাকে—এটি Lateral Movement-এর সুযোগ সৃষ্টি করে।

Jenkins-এ Pipeline Script (Jenkinsfile) সাধারণ Groovy কোড হিসেবে কার্যকর হয়। যদি Multibranch Pipeline বা Pull Request Builder Plugin কনফিগার করা থাকে Branch বা PR থেকে Jenkinsfile পড়ার জন্য, তাহলে আক্রমণকারী Jenkinsfile-এ ক্ষতিকর Groovy কোড লিখে Master Node-এ সম্পূর্ণ অ্যাক্সেস পেতে পারেন। Jenkins Script Console-এ অ্যাক্সেস মানে Domain-wide Compromise।

GitLab CI/CD-তে .gitlab-ci.yml-এ include নির্দেশনার মাধ্যমে অন্য প্রকল্প থেকে কনফিগ অন্তর্ভুক্ত করা হলে সেই উৎস প্রকল্পের নিরাপত্তা গুরুত্বপূর্ণ। যদি কেউ অন্তর্ভুক্ত প্রকল্পে অ্যাক্সেস পায়, সে সমস্ত নির্ভরশীল প্রকল্পে কোড এক্সিকিউশন অর্জন করে।

SolarWinds SUNBURST আক্রমণ (২০২০) Pipeline Poisoning-এর সবচেয়ে বিখ্যাত উদাহরণ। আক্রমণকারীরা SolarWinds-এর Orion সফটওয়্যারের Build পরিবেশে অনুপ্রবেশ করে এবং Build প্রক্রিয়ায় SUNSPOT নামক একটি ক্ষতিকর প্রোগ্রাম স্থাপন করে। এটি Build চলাকালীন Source Code-এর একটি নির্দিষ্ট ফাইল (InventoryManager.cs) ক্ষণিকের জন্য প্রতিস্থাপন করে SUNBURST Backdoor অন্তর্ভুক্ত করতো, তারপর মূল ফাইল পুনরুদ্ধার করতো। ফলাফল—Source Code Repository সম্পূর্ণ পরিষ্কার দেখাতো, কিন্তু Compiled Binary সংক্রমিত। এই আক্রমণে ১৮,০০০-এর বেশি গ্রাহক প্রভাবিত হন—US ট্রেজারি, Microsoft, FireEye, এবং অসংখ্য সরকারি সংস্থা সহ।

Codecov Bash Uploader (২০২১) ব্রিচে আক্রমণকারীরা Codecov-এর Docker Image তৈরি প্রক্রিয়ায় অনুপ্রবেশ করে Bash Uploader স্ক্রিপ্ট পরিবর্তন করে। ফলাফল—হাজার হাজার ক্লায়েন্টের CI/CD পাইপলাইন থেকে Environment Variable (যেখানে API Key, Token সংরক্ষিত) আক্রমণকারীর সার্ভারে পাঠানো হতো। Hashicorp, Rapid7-সহ অনেক বড় কোম্পানি ক্ষতিগ্রস্ত হয়।

3CX Supply Chain Attack (২০২৩) ছিল একটি Cascading Supply Chain Attack-এর উদাহরণ। উত্তর কোরিয়া-যুক্ত Lazarus Group প্রথমে Trading Technologies-এর X_Trader সফটওয়্যার সংক্রমিত করে, যা একজন 3CX কর্মচারী তার কোম্পানি ডিভাইসে ইনস্টল করেন। সেখান থেকে আক্রমণকারীরা 3CX-এর Build পরিবেশে প্রবেশ করে এবং 3CXDesktopApp-এর সাইন করা Installer-এ Backdoor অন্তর্ভুক্ত করে। বৈধ ডিজিটাল স্বাক্ষর থাকার কারণে অধিকাংশ নিরাপত্তা টুল এটি বৈধ হিসেবে গ্রহণ করেছিল।

PyTorch Dependency Confusion (২০২২-এ) আরেকটি গুরুত্বপূর্ণ ঘটনা। আক্রমণকারীরা PyPI-তে "torchtriton" নামে একটি ক্ষতিকর প্যাকেজ আপলোড করে—যা PyTorch-এর nightly build-এর একটি অভ্যন্তরীণ নির্ভরতার সাথে নাম মিলে যায়। ফলাফল—হাজার হাজার ডেভেলপার অজান্তে ক্ষতিকর প্যাকেজ ডাউনলোড করেন যা SSH Key এবং অন্যান্য সংবেদনশীল ফাইল চুরি করতো।

একটি সাধারণ Pipeline Poisoning আক্রমণ কয়েকটি ধাপে অগ্রসর হয়। প্রথমে Reconnaissance—আক্রমণকারী লক্ষ্য প্রকল্পের GitHub/GitLab প্রোফাইল, পাইপলাইন কনফিগারেশন, ব্যবহৃত নির্ভরতা এবং Open Source অবদানকারীদের তালিকা পরীক্ষা করেন। তারপর Initial Access—এটি বিভিন্নভাবে হতে পারে: একজন ডেভেলপারের ব্যক্তিগত শংসাপত্র Phishing-এর মাধ্যমে চুরি, একজন রক্ষণাবেক্ষণকারীকে Social Engineering করা (যেমন XZ Utils-এ "Jia Tan"-এর ক্ষেত্রে), অথবা একটি Public PR-এর মাধ্যমে CI-তে কোড এক্সিকিউশন।

Initial Access পাওয়ার পর আক্রমণকারী Persistence স্থাপন করেন। এটি হতে পারে একটি Backdoored GitHub Actions Workflow, একটি ক্ষতিকর Pre-commit Hook, অথবা Build স্ক্রিপ্টে একটি সূক্ষ্ম পরিবর্তন। আক্রমণকারীর লক্ষ্য হলো সনাক্তযোগ্যতা এড়িয়ে দীর্ঘমেয়াদে অ্যাক্সেস বজায় রাখা।

পরবর্তী পর্যায় হলো Privilege Escalation এবং Lateral Movement। CI Runner-এ অ্যাক্সেস থেকে সাধারণত Cloud Provider Credential (AWS IAM Role, GCP Service Account) চুরি করা যায়, যা সম্পূর্ণ Cloud Infrastructure-এ প্রসারিত হয়। সবশেষে Objective Execution—সাধারণ আউটপুট আর্টিফ্যাক্ট (Binary, Container, Package) এ Backdoor অন্তর্ভুক্ত করে গ্রাহকদের কাছে পৌঁছানো।

Pipeline Poisoning প্রতিরোধে সবচেয়ে মৌলিক নীতি হলো Build Integrity নিশ্চিত করা। SLSA Framework-এর Level 3 বা তদূর্ধ্ব অর্জনের লক্ষ্য রাখুন। এতে Hermetic Build (বিচ্ছিন্ন এবং পুনরুৎপাদনযোগ্য Build পরিবেশ), Provenance Generation (প্রতিটি আর্টিফ্যাক্টের সম্পূর্ণ Build ইতিহাস), এবং Two-person Review (সমস্ত পাইপলাইন পরিবর্তনে দ্বৈত অনুমোদন) অন্তর্ভুক্ত।

Pull Request নিরাপত্তায় কঠোর নিয়ন্ত্রণ প্রতিষ্ঠা করুন। GitHub Actions-এ pull_request_target ব্যবহার এড়িয়ে চলুন, অথবা Permission কঠোরভাবে সীমাবদ্ধ রাখুন। Fork-এর PR-এ CI চালানোর আগে Maintainer অনুমোদন বাধ্যতামূলক করুন—GitHub-এর "Require approval for first-time contributors" সেটিং চালু রাখুন। Self-hosted Runner কখনো Public Repository-তে ব্যবহার করবেন না।

Secret Management আধুনিকীকরণ করুন। Long-lived Secret-এর পরিবর্তে OIDC ভিত্তিক Short-lived Credential ব্যবহার করুন। GitHub Actions, GitLab CI, এবং অধিকাংশ আধুনিক CI প্ল্যাটফর্ম এখন AWS, GCP, Azure-এর সাথে OIDC ফেডারেশন সমর্থন করে। প্রতিটি Job-এর জন্য পৃথক Credential ইস্যু করা হয় যা কয়েক মিনিট পরে স্বয়ংক্রিয়ভাবে অবৈধ হয়ে যায়।

নির্ভরতা ব্যবস্থাপনায় Dependency Pinning, Hash Verification (npm-এর package-lock.json, Python-এর pip hash-checking mode), এবং Private Registry ব্যবহার করুন। অভ্যন্তরীণ প্যাকেজের জন্য সবসময় Scoped Names (যেমন @company/package) ব্যবহার করুন এবং সংশ্লিষ্ট Scope পাবলিক রেজিস্ট্রিতে রিজার্ভ করুন। Software Bill of Materials (SBOM) তৈরি এবং সংরক্ষণ করুন—CycloneDX বা SPDX ফরম্যাটে।

Code Signing এবং Artifact Verification বাধ্যতামূলক করুন। Sigstore প্রকল্প (Cosign, Fulcio, Rekor) ব্যবহার করে Container Image এবং অন্যান্য আর্টিফ্যাক্টে স্বাক্ষর করুন। Deployment-এর সময় স্বাক্ষর যাচাই বাধ্যতামূলক করুন—Kyverno বা OPA Gatekeeper-এর মতো Policy Engine ব্যবহার করে। In-toto attestation দ্বারা Build Provenance যাচাই করুন।

পাইপলাইন পরিবেশকে Least Privilege নীতিতে কনফিগার করুন। প্রতিটি Job-কে শুধুমাত্র প্রয়োজনীয় Permission প্রদান করুন। GitHub Actions-এ permissions কীওয়ার্ড ব্যবহার করে GITHUB_TOKEN-এর Scope সীমাবদ্ধ রাখুন। Runner Image নিয়মিত আপডেট করুন এবং অপ্রয়োজনীয় টুল সরিয়ে ফেলুন। নেটওয়ার্ক পর্যায়ে CI Runner থেকে শুধুমাত্র Allowlist করা গন্তব্যে যোগাযোগের অনুমতি দিন।

পর্যবেক্ষণ এবং সনাক্তকরণে CI/CD Audit Log কেন্দ্রীয়ভাবে সংগ্রহ এবং বিশ্লেষণ করুন। অস্বাভাবিক Build আচরণ (অপ্রত্যাশিত নেটওয়ার্ক সংযোগ, নতুন Outbound IP, অপ্রত্যাশিত প্রক্রিয়া) সনাক্ত করতে Runtime Monitoring (Falco, Tracee) ব্যবহার করুন। নিয়মিত Threat Hunting পরিচালনা করুন এবং StepSecurity বা Legit Security-এর মতো বিশেষায়িত CI/CD Security টুল বিবেচনা করুন।