CI/CD Security: সফটওয়্যার ডেভেলপমেন্ট পাইপলাইনে সাইবার নিরাপত্তা নিশ্চিতকরণ!

একটি সাধারণ CI/CD পাইপলাইনে কয়েকটি স্তর থাকে। প্রথম স্তরে রয়েছে Source Code Management—সাধারণত GitHub, GitLab, বা Bitbucket। ডেভেলপাররা এখানে কোড কমিট করেন। দ্বিতীয় স্তরে আসে Build System—Jenkins, GitHub Actions, GitLab CI, CircleCI, বা ArgoCD—যা স্বয়ংক্রিয়ভাবে কোড বিল্ড, টেস্ট এবং প্যাকেজ করে।

তৃতীয় স্তরে রয়েছে Artifact Repository—Nexus, JFrog Artifactory, GitHub Packages, বা Docker Hub—যেখানে বিল্ড আউটপুট সংরক্ষিত হয়। চতুর্থ স্তরে Deployment Engine—Kubernetes, AWS ECS, বা Terraform—প্রোডাকশন পরিবেশে অ্যাপ্লিকেশন স্থাপন করে। প্রতিটি স্তরেই বিশেষ নিরাপত্তা ঝুঁকি বিদ্যমান।

OWASP সাম্প্রতিক সময়ে CI/CD-নির্দিষ্ট দশটি প্রধান নিরাপত্তা ঝুঁকির তালিকা প্রকাশ করেছে। শীর্ষে রয়েছে Insufficient Flow Control Mechanisms—যেখানে পাইপলাইনে অপর্যাপ্ত অনুমোদন নিয়ন্ত্রণ থাকে। উদাহরণস্বরূপ, কোনো কোড রিভিউ ছাড়াই সরাসরি main শাখায় পুশ করতে পারা।

দ্বিতীয়টি Inadequate Identity and Access Management। CI/CD সিস্টেমে অতিরিক্ত প্রিভিলেজযুক্ত সার্ভিস অ্যাকাউন্ট, দীর্ঘস্থায়ী টোকেন, এবং পুরোনো ব্যবহারকারীর অ্যাক্সেস সাধারণ সমস্যা। তৃতীয়টি Dependency Chain Abuse—যেখানে আক্রমণকারী ম্যালিশিয়াস প্যাকেজ ইনজেক্ট করেন।

চতুর্থটি Poisoned Pipeline Execution (PPE)—যেখানে পাইপলাইন কনফিগারেশন ফাইল (যেমন .github/workflows/) পরিবর্তন করে নির্বিচার কোড এক্সিকিউট করা যায়। পঞ্চমটি Insufficient PBAC (Pipeline-Based Access Controls)—যেখানে পাইপলাইনের রানটাইম পরিবেশে অতিরিক্ত অনুমতি থাকে।

বাকি ঝুঁকির মধ্যে রয়েছে Insufficient Credential Hygiene, Insecure System Configuration, Ungoverned Usage of 3rd Party Services, Improper Artifact Integrity Validation, এবং Insufficient Logging and Visibility।

CI/CD নিরাপত্তার সবচেয়ে আলোচিত দিক হলো Software Supply Chain Attack। ২০২০ সালে SolarWinds Orion সফটওয়্যারের বিল্ড সিস্টেমে রাশিয়ান রাষ্ট্র-পৃষ্ঠপোষিত হ্যাকাররা অনুপ্রবেশ করে এবং প্রায় ১৮,০০০ গ্রাহকের কাছে দূষিত আপডেট বিতরণ করে। এই আক্রমণ মার্কিন সরকারের একাধিক সংস্থা, Microsoft, এবং অসংখ্য বড় কর্পোরেশনকে প্রভাবিত করে।

২০২১ সালে Codecov-এর Bash Uploader স্ক্রিপ্টে অননুমোদিত পরিবর্তন ঘটে, যা গ্রাহকদের CI/CD পরিবেশের পরিবেশ পরিবর্তনশীল (যেখানে সাধারণত গোপনীয় তথ্য থাকে) আক্রমণকারীদের সার্ভারে পাঠাচ্ছিল। ২০২৩ সালে 3CX-এর ডেস্কটপ অ্যাপ্লিকেশনে একটি ক্যাসকেডিং সাপ্লাই চেইন আক্রমণ ঘটে—প্রথমে একটি Trading Software কোম্পানি আপস হয়, যার সফটওয়্যার একজন 3CX ডেভেলপার ব্যবহার করতেন।

ওপেন সোর্স ইকোসিস্টেমেও আক্রমণ বাড়ছে। npm-এর event-stream, PyPI-র বিভিন্ন typosquatting প্যাকেজ, এবং সাম্প্রতিক xz-utils ব্যাকডোর—সবগুলোই দেখায় ওপেন সোর্স সাপ্লাই চেইন কতটা ভঙ্গুর।

CI/CD পাইপলাইনে সবচেয়ে সাধারণ ভুল হলো গোপনীয়তা ব্যবস্থাপনা। API key, ডাটাবেস পাসওয়ার্ড, ক্লাউড ক্রেডেনশিয়াল—এই সব কোডে হার্ডকোড করা বা পরিবেশ পরিবর্তনশীলে রাখা একটি বড় ঝুঁকি। GitHub পাবলিক রিপোজিটরিতে প্রতিদিন হাজার হাজার গোপনীয় তথ্য ভুলবশত কমিট হয়।

আধুনিক সমাধান হলো সঠিক Secret Management টুল ব্যবহার—HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager। CI/CD পাইপলাইন রানটাইমে এই ভল্ট থেকে গোপন তথ্য আনে এবং কখনো ডিস্কে সংরক্ষণ করে না।

আরও উন্নত পদ্ধতি হলো OIDC-ভিত্তিক ফেডারেটেড আইডেন্টিটি। GitHub Actions, GitLab, এবং অন্যান্য প্ল্যাটফর্ম এখন AWS, Azure, GCP-র সাথে OIDC ফেডারেশন সমর্থন করে—কোনো দীর্ঘস্থায়ী ক্রেডেনশিয়াল ছাড়াই ক্লাউডে অ্যাক্সেস পাওয়া যায়। প্রতিটি ওয়ার্কফ্লো রানে সংক্ষিপ্তকালীন টোকেন ইস্যু হয়।

গোপনীয়তা স্ক্যানিংয়ের জন্য GitLeaks, TruffleHog, এবং GitGuardian প্রতিটি কমিটে ফাঁস হওয়া গোপন তথ্য শনাক্ত করে। GitHub নিজেই Secret Scanning ফিচার প্রদান করে।

Google নেতৃত্বে তৈরি SLSA (Supply-chain Levels for Software Artifacts) একটি ফ্রেমওয়ার্ক যা সফটওয়্যার সরবরাহ চেইনের অখণ্ডতা নিশ্চিত করতে চারটি স্তর সংজ্ঞায়িত করে। SLSA Level 1-এ বিল্ড প্রক্রিয়া অটোমেটেড এবং Provenance তৈরি করতে হবে। SLSA Level 2-এ সোর্স ও বিল্ড প্ল্যাটফর্ম authenticated হতে হবে।

SLSA Level 3-এ বিল্ড পরিবেশ আইসোলেটেড এবং Provenance noncryptographically secure হতে হবে। SLSA Level 4-এ দুই-ব্যক্তির রিভিউ এবং hermetic, reproducible বিল্ড প্রয়োজন। অধিকাংশ প্রতিষ্ঠান এখন SLSA Level 2 বা 3-এ পৌঁছানোর চেষ্টা করছে।

Sigstore প্রকল্প এই কাজ সহজ করেছে—Cosign দিয়ে আর্টিফ্যাক্ট সাইন করা যায়, Rekor-এ Transparency Log সংরক্ষিত হয়, এবং Fulcio Keyless Signing সক্ষম করে। SBOM (Software Bill of Materials) তৈরি ও সংরক্ষণ সাপ্লাই চেইন স্বচ্ছতার জন্য অপরিহার্য।

আধুনিক DevSecOps অনুশীলনে CI/CD পাইপলাইনে একাধিক ধরনের সিকিউরিটি স্ক্যান অন্তর্ভুক্ত করা হয়। SAST (Static Application Security Testing) সোর্স কোড স্ক্যান করে দুর্বলতা শনাক্ত করে—Semgrep, SonarQube, Checkmarx, Snyk Code এই ক্যাটাগরিতে জনপ্রিয়।

DAST (Dynamic Application Security Testing) রানিং অ্যাপ্লিকেশনে আক্রমণ অনুকরণ করে—OWASP ZAP, Burp Suite Enterprise, Acunetix। SCA (Software Composition Analysis) থার্ড-পার্টি ডিপেন্ডেন্সির পরিচিত দুর্বলতা শনাক্ত করে—Snyk, Dependabot, Renovate।

Container Image স্ক্যানিংয়ের জন্য Trivy, Grype, Clair, এবং Anchore ব্যবহৃত হয়। Infrastructure as Code (IaC) স্ক্যানিংয়ের জন্য Checkov, tfsec, KICS, Terrascan—এগুলো Terraform, CloudFormation, Kubernetes মেনিফেস্টে নিরাপত্তা মিসকনফিগারেশন শনাক্ত করে।

প্রতিটি স্ক্যান পাইপলাইনের যথাযথ পর্যায়ে চালানো উচিত—SAST প্রথমে, SCA Build পর্যায়ে, Image Scan কন্টেইনার বিল্ডের পর, এবং DAST Staging-এ। Shift-Left নীতি অনুসরণ করে যত আগে সমস্যা শনাক্ত হবে, তত সস্তায় সমাধান সম্ভব।

CI/CD রানার নিজেই একটি গুরুত্বপূর্ণ আক্রমণ লক্ষ্য। GitHub Self-Hosted Runner, GitLab Shared Runner, Jenkins Agent—এই বিল্ড মেশিনে প্রায়শই উচ্চ-স্তরের ক্রেডেনশিয়াল ও সোর্স কোড অ্যাক্সেস থাকে। তাদের আপস হলে সম্পূর্ণ ডেভেলপমেন্ট পরিবেশ আপস হয়।

সর্বোত্তম অনুশীলন হলো Ephemeral Runners ব্যবহার—প্রতিটি জব একটি নতুন, ব্যবহারের পর ধ্বংসকৃত পরিবেশে চলে। GitHub Actions Runner Controller (ARC) Kubernetes-এ এই ক্ষমতা প্রদান করে।

বিল্ড পরিবেশে কঠোর নেটওয়ার্ক ফিল্টারিং প্রয়োগ করুন—রানার থেকে শুধু আবশ্যক এন্ডপয়েন্টে আউটবাউন্ড ট্রাফিকের অনুমতি দিন। এতে DNS-ভিত্তিক ডেটা এক্সফিল্ট্রেশন কঠিন হয়।

CI/CD নিরাপত্তার একটি সামগ্রিক পদ্ধতি গ্রহণ করুন। প্রথমত, Branch Protection Rules কঠোরভাবে প্রয়োগ করুন—main শাখায় সরাসরি পুশ নিষিদ্ধ, মার্জের আগে রিভিউ বাধ্যতামূলক, এবং সফল CI চেক প্রয়োজন। দ্বিতীয়ত, Signed Commit বাধ্যতামূলক করুন GPG বা SSH সাইনিংয়ের মাধ্যমে।

তৃতীয়ত, Workflow ফাইলের পরিবর্তনের জন্য বিশেষ অনুমোদন প্রক্রিয়া রাখুন—সাধারণ ডেভেলপার যেন .github/workflows/ বা .gitlab-ci.yml-এ পরিবর্তন আনতে না পারেন। চতুর্থত, Third-party Action-এর জন্য পরিবর্তনযোগ্য ট্যাগের পরিবর্তে SHA pinning ব্যবহার করুন—actions/checkout@v3 নয়, actions/checkout@a12345678...।

পঞ্চমত, সাপ্লাই চেইন ভেরিফিকেশনের জন্য Sigstore/Cosign একীভূত করুন এবং admission controller (Kyverno, OPA Gatekeeper) দিয়ে শুধু সাইনকৃত ইমেজ ডিপ্লয় হতে দিন। ষষ্ঠত, পাইপলাইন কর্মকাণ্ডের জন্য বিস্তৃত লগিং ও পর্যবেক্ষণ চালু করুন—অস্বাভাবিক বিল্ড, রাতের বেলা ডিপ্লয়মেন্ট, বা নতুন রানার থেকে কাজ সন্দেহজনক।

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