আপনি কি পরবর্তী টার্গেট?

জরুরি প্রয়োজনে সরকারি পোর্টালে ঢুকে সাইট অচল পাওয়া, ব্যাংক অ্যাকাউন্টে অস্বাভাবিক লেনদেন দেখা কিংবা হাসপাতালের ডেটাবেজ থেকে ব্যক্তিগত চিকিৎসার তথ্য বাইরে চলে যাওয়া—শুনতে কল্পনার মতো লাগলেও সফটওয়্যারের নিরাপত্তা দুর্বলতায় এমন ঝুঁকি এখন খুবই বাস্তব।

আমরা সচরাচর সফটওয়্যারের বাহ্যিক সৌন্দর্য, গতি বা নতুন ফিচার নিয়েই মেতে থাকি; অথচ আড়ালে পড়ে থাকে সবচেয়ে জরুরি বিষয়—‘নিরাপত্তা’। ২০২৬ সালের অক্টোবরে বিশ্বের বহুল ব্যবহৃত দুই প্রযুক্তি PHP ও Node.js-এ গুরুতর নিরাপত্তা ত্রুটি ধরা পড়া এবং বাংলাদেশের BGD e-GOV CIRT-এর সাম্প্রতিক সতর্কবার্তাগুলো আমাদের নতুন করে ভাবতে বাধ্য করছে। আমরা কি এসব সতর্কবার্তাকে গুরুত্ব দিচ্ছি, নাকি বড় কোনো বিপর্যয়ের অপেক্ষায় আছি?

বাংলাদেশের সফটওয়্যার নিরাপত্তা: আমরা কি বড় বিপর্যয়ের অপেক্ষায়?

জন্মনিবন্ধন, ভূমিসেবা, কর প্রদান থেকে শুরু করে ব্যাংকিং, হাসপাতাল ও পোশাকশিল্প—বাংলাদেশে এখন সব ক্ষেত্রেই ওয়েব অ্যাপ্লিকেশন, ইআরপি (ERP), এপিআই (API) ও ডেটাবেজের ব্যবহার অপরিহার্য। কিন্তু নির্ভরতা বাড়লেও নিরাপত্তা কি ততটা এগিয়েছে?

২০২৬ সালে প্রকাশিত Tech Global Institute-এর Breached and Unanswered প্রতিবেদনের তথ্য অনুযায়ী, ২০২৩ সালের জানুয়ারি থেকে ২০২৬ সালের মে পর্যন্ত দেশে অন্তত ৬৮টি তথ্যফাঁসের (৩৬টি সরকারি ও ৩২টি বেসরকারি) ঘটনা নথিভুক্ত হয়েছে, যেখানে এনআইডি ও পাসপোর্টের মতো সংবেদনশীল তথ্যও উন্মুক্ত হয়েছে। এটি সরকারি পূর্ণাঙ্গ হিসাব না হলেও ঝুঁকির মাত্রা বোঝাতে যথেষ্ট। এর মধ্যেই ২৫ অক্টোবর ২০২৬-এ BGD e-GOV CIRT জানায়, দেশের বেশ কিছু সরকারি-বেসরকারি প্রতিষ্ঠানে এখনও মেয়াদোত্তীর্ণ ও ঝুঁকিপূর্ণ PHP সংস্করণ চলছে এবং আগে জানানো সত্ত্বেও অনেকে তা সংশোধনের নিশ্চয়তা দেয়নি। মনে রাখতে হবে, একটি অনিরাপদ সিস্টেম বা API কেবল সেই প্রতিষ্ঠানকেই ডোবায় না, নাগরিক সেবা ও সংযুক্ত অন্যান্য সিস্টেমকেও বিপদে ফেলে। (সূত্র: Tech Global Institute — Breached and Unanswered; BGD e-GOV CIRT — Unresolved PHP Security Exposures, 25 Oct 2026)

PHP ও Node.js-এর সংকট: Go ও Rust কি ভবিষ্যতের বিকল্প?

২০২৬ সালের ২১ অক্টোবর PHP কর্তৃপক্ষ দুটি মারাত্মক ত্রুটির (Out-of-Memory সংক্রান্ত CVE-2026-109618 এবং মেমরি রেফারেন্স সংক্রান্ত CVE-2026-109619) কারণে তাদের 8.5.12, 8.4.27, 8.3.36 ও 8.2.35 সংস্করণে জরুরি প্যাচ প্রকাশ করে। বিশেষ করে Apache-এর mod_php-তে মূল অ্যাপ্লিকেশনের কোড চালুর আগেই হ্যাকাররা লগইন ছাড়া কোড চালাতে (RCE) পারে। ২৭ অক্টোবর CIRT আরও একটি শর্তসাপেক্ষ ঝুঁকির (CVE-2026-115560) কথা জানায়। একইভাবে ২১ অক্টোবর Node.js-ও তাদের 22.x, 24.x ও 26.x সংস্করণে Brotli Decompression-এর মেমরি ত্রুটি এবং DNS, TLS ও HTTP সমস্যার জরুরি আপডেট দেয়। (সূত্র: PHP & Node.js Security Releases, Oct 2026; BGD e-GOV CIRT)

এর মানে এই নয় যে PHP বা Node.js ব্যবহার করলেই সফটওয়্যার অনিরাপদ। নিয়মিত আপডেট ও সঠিক কনফিগারেশনে এগুলো যথেষ্ট কার্যকর। তবে নতুন প্রজেক্টের ক্ষেত্রে Go এবং Rust এখন দারুণ বিকল্প। সার্ভার, API ও Concurrency-এর জন্য Go যেমন সহজ এবং govulncheck-এর মাধ্যমে ডিপেনডেন্সি নিরাপদ রাখে, তেমনি Rust তার Ownership ও Borrowing ব্যবস্থার মাধ্যমে Compile করার সময়ই মেমরি-সংক্রান্ত ভুল ধরে ফেলে। ২০২৫ সালের নভেম্বরে গুগলের Android Security Team জানায়, অ্যান্ড্রয়েডে C/C++-এর বদলে Rust ব্যবহারে মেমরি-সংক্রান্ত ত্রুটির হার উল্লেখযোগ্যভাবে কমেছে। তবে চালু থাকা পুরোনো PHP বা Node.js সিস্টেম ভেঙে রাতারাতি Go বা Rust-এ লেখা ব্যয়বহুল ও ঝুঁকিপূর্ণ; তাই পুরোনো সিস্টেমে নিয়মিত আপডেট এবং নতুন প্রকল্পে প্রয়োজন বুঝে Go বা Rust বেছে নেওয়াই বুদ্ধিমানের কাজ। (সূত্র: Go Security Docs; Google Security Blog — Rust in Android, Nov 2025)

সরকারি বনাম বেসরকারি সফটওয়্যার: নিরাপত্তার ঘাটতি কোথায়, দায় কার?

আমাদের দেশে সরকারি সফটওয়্যার চলে দরপত্র, নির্দিষ্ট বাজেট ও মেয়াদের ছকে; আর বেসরকারি খাতে থাকে দ্রুত নতুন ফিচার আনা ও খরচ কমানোর চাপ। দুই খাতের বাস্তবতা আলাদা হলেও নিরাপত্তার ঘাটতিটা একই জায়গায়।

ধরুন, একটি সরকারি পোর্টাল চালু হলো এবং মানুষ সেবাও পাচ্ছে। কিন্তু তিন বছর পর সেটির Framework বা Database Server-এর সিকিউরিটি আপডেট কে দেবে? চুক্তিতে তা স্পষ্ট না থাকলে দায়িত্ব নিয়ে জটিলতা তৈরি হয়। আবার বেসরকারি প্রতিষ্ঠানে তাড়াহুড়ো করে ফিচার আনতে গিয়ে অনেক সময় পর্যাপ্ত Security Testing ছাড়াই কোড Production Server-এ তুলে দেওয়া হয়।

অনেকে বাইরের ভেন্ডর দিয়ে সফটওয়্যার বানিয়েই ভাবেন দায়িত্ব শেষ। অথচ ভেন্ডরের সঙ্গে চুক্তি শেষ হলেও যে প্রতিষ্ঠান জনগণের তথ্য নিচ্ছে, নিরাপত্তার চূড়ান্ত দায় তারই। তাই চুক্তিতেই স্পষ্ট থাকতে হবে—আপডেট কে দেবে, ত্রুটি ধরা পড়লে কত দ্রুত ব্যবস্থা নেওয়া হবে এবং তথ্যফাঁস হলে তদন্ত কীভাবে হবে। প্রতিটি গুরুত্বপূর্ণ সফটওয়্যারের জন্য তাই সুনির্দিষ্ট ‘Security Ownership’ বা দায়িত্বশীল দল থাকা জরুরি।

সফটওয়্যার ডেলিভারি মানেই দায়িত্ব শেষ নয়: অদৃশ্য ঝুঁকি কোথায়?

পাঁচ বছর আগের একটি ওয়েবসাইট বাইরে থেকে দিব্যি সচল মনে হলেও এর ভেতরের পুরোনো Runtime, CMS Plugin, JavaScript Package কিংবা থার্ড-পার্টি লাইব্রেরিতে ভয়াবহ দুর্বলতা লুকিয়ে থাকতে পারে। আধুনিক সফটওয়্যার অসংখ্য বাহ্যিক ডিপেনডেন্সির ওপর নির্ভরশীল হওয়ায় নিজের লেখা কোড নিখুঁত হলেও অন্য কম্পোনেন্ট দিয়ে আক্রমণ হতে পারে—যা OWASP Top 10:2025-এ Software Supply Chain Failures, Broken Access Control ও Security Misconfiguration হিসেবে চিহ্নিত।

এই নীরব ঝুঁকি এড়াতে সফটওয়্যারের সব উপাদানের তালিকা বা SBOM (Software Bill of Materials) রাখা, নিয়মিত Patch Management ও স্বাধীন Security Assessment করা, পরিবর্তনের আগে Testing ও Rollback ব্যবস্থা রাখা এবং নিয়মিত Backup ও Incident Response অনুশীলন করা অপরিহার্য। যুক্তরাষ্ট্রের NIST-এর Secure Software Development Framework (SSDF, SP 800-218)-এও সফটওয়্যারের পুরো জীবনচক্রে এভাবে নিরাপত্তা বজায় রাখার তাগিদ দেওয়া হয়েছে।

ইউরোপের অভিজ্ঞতা: বাংলাদেশ কী শিখতে পারে?

সফটওয়্যার নিরাপত্তাকে নীতিমালার বাঁধনে কীভাবে আনতে হয়, তার বড় উদাহরণ ইউরোপ:

• এস্তোনিয়া: তাদের সরকারি তথ্যব্যবস্থার মূল ভিত্তি X-tee নামের Data Exchange Layer। সব তথ্য এক জায়গায় রাখার চেয়ে বিভিন্ন সরকারি ডেটাবেজের মধ্যকার যোগাযোগকে Authentication, Encryption, Digital Signature ও Logging দিয়ে নিরাপদ রাখাই এর মূল নীতি। (সূত্র: Estonian Information System Authority)

• জার্মানি: দেশটির কেন্দ্রীয় সংস্থা BSI-এর তৈরি IT-Grundschutz (Standard 200-2) কাঠামো মেনে সরকারি তথ্যব্যবস্থার ঝুঁকি মূল্যায়ন ও নিরাপত্তা নিয়ন্ত্রণ পরিচালিত হয়। অর্থাৎ প্রতিটি প্রজেক্টে আলাদা নিয়ম না বানিয়ে যেন একটি জাতীয় মানদণ্ড অনুসরণ করা হয়।

• ফ্রান্স: ফরাসি সাইবার নিরাপত্তা সংস্থা ANSSI-এর RGS (Référentiel Général de Sécurité) কাঠামোর আওতায় প্রযোজ্য সরকারি তথ্যব্যবস্থার নিরাপত্তাঝুঁকি বিশ্লেষণ এবং আনুষ্ঠানিক Security Approval (Homologation) গ্রহণের বিধান রয়েছে। এর মাধ্যমে সংশ্লিষ্ট সিস্টেমের ঝুঁকি মূল্যায়ন ও প্রয়োজনীয় নিরাপত্তা ব্যবস্থা নিশ্চিত করার প্রক্রিয়া প্রতিষ্ঠিত হয়। বাংলাদেশের সংবেদনশীল নাগরিক সেবার ক্ষেত্রেও এ ধরনের ঝুঁকিভিত্তিক নিরাপত্তা অনুমোদনব্যবস্থা অনুকরণীয় হতে পারে।

• যুক্তরাজ্য: ২০২৬ সালের জানুয়ারিতে প্রকাশিত ব্রিটিশ সরকারের Government Cyber Action Plan-এ পুরোনো প্রযুক্তির ঝুঁকি মোকাবিলা ও কেন্দ্রীয় সমন্বয়ের জন্য Government Cyber Unit গঠনের কথা বলা হয়েছে। তাদের Secure-by-Design নীতি পরিকল্পনা থেকে অবসর পর্যন্ত প্রতিটি ধাপে নিরাপত্তা নিশ্চিত করে।

• ইউরোপীয় ইউনিয়ন: ইইউ-এর NIS2 Directive গুরুত্বপূর্ণ খাতে ঝুঁকি ব্যবস্থাপনা ও Incident Reporting বাধ্যতামূলক করেছে। আর Cyber Resilience Act (CRA) ডিজিটাল পণ্য নির্মাতাদের ওপর আপডেট ও ত্রুটি ব্যবস্থাপনার আইনি দায় চাপিয়েছে, যার রিপোর্টিং বিধান ১১ সেপ্টেম্বর ২০২৬ থেকে চালু হয়েছে এবং মূল বিধান ১১ ডিসেম্বর ২০২৭ থেকে কার্যকর হবে। (সূত্র: European Commission)

এখান থেকে আমরা শিখতে পারি যে নিরাপত্তা শুধু কারিগরি বিষয় নয়, এটি একটি নিয়মিত ও জবাবদিহিমূলক প্রক্রিয়া।

Government Bug Bounty Program: বাংলাদেশেও কেন নয়?

দেশের কোনো স্বাধীন Security Researcher যদি সরকারি ওয়েবসাইটে গুরুতর ত্রুটি খুঁজে পান, তবে তিনি কোথায় জানাবেন? উল্টো আইনি ঝামেলায় পড়বেন না তো? এই ভয়ের কারণেই অনেকে মুখ খোলেন না। অথচ সরকারি উদ্যোগে Bug Bounty Program চালু করলে গবেষকেরা নির্দিষ্ট নিয়মের আওতায় বৈধভাবে ত্রুটি খুঁজে দেওয়ার সুযোগ ও আর্থিক পুরস্কার পান।

বিশ্বজুড়ে এর বেশ কিছু উদাহরণ রয়েছে। ২০১৬ সালে মার্কিন প্রতিরক্ষা দপ্তরের Hack the Pentagon পাইলট কর্মসূচিতে ১,৪০০-এর বেশি নিরাপত্তা গবেষক নিবন্ধন করেন এবং অংশগ্রহণের আমন্ত্রণ পান। তাঁদের মধ্যে ২৫০-এর বেশি গবেষক অন্তত একটি করে নিরাপত্তা ত্রুটির রিপোর্ট জমা দেন। কর্মসূচির আওতায় পাঁচটি উন্মুক্ত সরকারি ওয়েবসাইট পরীক্ষা করে জমা দেওয়া রিপোর্টগুলোর মধ্যে ১৩৮টি স্বতন্ত্র ও বৈধ নিরাপত্তা ত্রুটি শনাক্ত করা হয়।

বাংলাদেশেও শুরুতে নির্বাচিত কিছু পোর্টাল নিয়ে পরীক্ষামূলক বাগ বাউন্টি ও National Vulnerability Disclosure Programme (VDP) চালু করা যায়। তবে এর জন্য পরীক্ষার পরিধি (Scope), রিপোর্টের নিয়ম এবং সৎ গবেষকদের জন্য সুস্পষ্ট আইনি সুরক্ষা নিশ্চিত করতে হবে। এতে সরকারি সিস্টেমও নিরাপদ হবে, দেশের তরুণ সাইবার পেশাজীবীদের দক্ষতাও বাড়বে।

এআই-এর যুগে আগাম সতর্কতা, ভবিষ্যতের নিরাপত্তা ও বাংলাদেশের করণীয়

ভবিষ্যতের সাইবার নিরাপত্তা আর ‘আক্রমণ হওয়ার পর ব্যবস্থা নেওয়া’র ওপর দাঁড়িয়ে থাকবে না। এখন সময় Proactive Early Warning এবং AI-Based Security Screening-এর। নতুন কোনো Vulnerability প্রকাশ পাওয়ামাত্রই স্বয়ংক্রিয়ভাবে সোর্স কোড, সার্ভার লগ, API ও নেটওয়ার্ক বিশ্লেষণ করে ঝুঁকিপূর্ণ প্রতিষ্ঠানকে আগাম সতর্কবার্তা পাঠানো সম্ভব। BGD e-GOV CIRT-এর বিদ্যমান থ্রেট ইন্টেলিজেন্স কার্যক্রমের সঙ্গে কেন্দ্রীয় স্বয়ংক্রিয় স্ক্রিনিং এবং প্রতিষ্ঠানভিত্তিক ‘Risk Dashboard’ যুক্ত করা গেলে কোন দপ্তর ঝুঁকিতে আছে এবং তারা প্যাচ দিয়েছে কি না, তা সহজেই তদারকি করা যাবে।

পাশাপাশি আধুনিক অ্যাপ্লিকেশন সিকিউরিটির নিয়মও বদলে যাচ্ছে। এখন কেবল অ্যান্টিভাইরাস বা ফায়ারওয়াল যথেষ্ট নয়; শুরু থেকেই Secure-by-Design, অভ্যন্তরীণ নেটওয়ার্কেও কাউকে অন্ধভাবে বিশ্বাস না করার Zero Trust নীতি, কোডিং ও অপারেশনের প্রতিটি ধাপে DevSecOps এবং বছরে একবার অডিটের বদলে Continuous Security Validation অপরিহার্য হয়ে উঠেছে।

তবে এখানে AI-এর উভয় দিকই মাথায় রাখতে হবে। একদিকে AI যেমন ত্রুটি খুঁজতে সাহায্য করে, অন্যদিকে AI কখনও ভুল সংকেত দিতে পারে বা বিজনেস লজিকের সূক্ষ্ম গলদ মিস করতে পারে। আবার AI Coding Assistant বা Autonomous Agent দিয়ে দ্রুত কোড লেখার ফলে ভুল কনফিগারেশন, অনিরাপদ ডিপেনডেন্সি বা গোপন তথ্য প্রকাশের নতুন ঝুঁকি তৈরি হচ্ছে। তাই NIST-এর নির্দেশিকা এবং OWASP-এর Secure Coding with AI নীতিমালা মেনে স্বয়ংক্রিয় টুল, Fuzzing ও Static Analysis-এর পাশাপাশি অভিজ্ঞ প্রকৌশলীর মাধ্যমে Manual Code Review ও Penetration Testing নিশ্চিত করতে হবে।

পরবর্তী সাইবার বিপর্যয়ের আগেই বাংলাদেশের যা করা প্রয়োজন:

• সফটওয়্যারের তালিকা ও মালিকানা: সরকারি-বেসরকারি প্রতিটি প্রতিষ্ঠানের ব্যবহৃত সফটওয়্যার, সার্ভার ও থার্ড-পার্টি সেবার পূর্ণাঙ্গ তালিকা তৈরি এবং সুনির্দিষ্ট মালিকানা (Ownership) নির্ধারণ করা।
• চুক্তিতে নিরাপত্তা শর্ত: সফটওয়্যার কেনা বা তৈরির চুক্তিতেই Security Testing, দীর্ঘমেয়াদি আপডেট ও Incident Response-এর শর্ত যুক্ত করা।
• ঝুঁকিভিত্তিক অডিট: সাধারণ ওয়েবসাইট আর কোটি নাগরিকের সংবেদনশীল ডেটাবেজকে এক পাল্লায় না মেপে ঝুঁকির মাত্রা অনুযায়ী নিয়মিত অডিট করা।
• আগাম সতর্কতা ও বাগ বাউন্টি: জাতীয় পর্যায়ে স্বয়ংক্রিয় Early Warning জোরদার করা এবং আইনি সুরক্ষাসহ সরকারি Bug Bounty ও Vulnerability Disclosure প্রোগ্রাম চালু করা।
• বিচক্ষণ প্রযুক্তি নির্বাচন ও দক্ষতা বৃদ্ধি: নতুন প্রকল্পে প্রয়োজন অনুযায়ী Go বা Rust বিবেচনা করা এবং বিদ্যমান সিস্টেমে নিয়মিত প্যাচ দেওয়া। একই সঙ্গে কেবল সিকিউরিটি টিম নয়, সাধারণ ডেভেলপার ও প্রজেক্ট ম্যানেজারদেরও নিরাপত্তার মৌলিক প্রশিক্ষণ দেওয়া।
• জবাবদিহি নিশ্চিত করা: দুর্বলতা শনাক্ত হওয়ার পরও কোনো প্রতিষ্ঠান ব্যবস্থা না নিলে জবাবদিহির ব্যবস্থা রাখা - কারণ ঝুঁকি সম্পর্কে না জানা এবং জেনেও চুপ থাকা দুটোই সমান বিপজ্জনক।

শেষ কথা

কৃত্রিম বুদ্ধিমত্তার যুগে সফটওয়্যার তৈরি করা সহজ হয়ে গেছে, কিন্তু সেটিকে নিরাপদ রাখার দায়িত্ব বেড়েছে বহুগুণ। বাংলাদেশের জন্য এখন সবচেয়ে জরুরি কাজ হুট করে নতুন প্রোগ্রামিং ভাষা বা দামি টুল কেনা নয়, বরং কাজের সংস্কৃতি বদলানো। সফটওয়্যার চালুর আগে সেটি কতটা নিরাপদ, চালুর পর কে দেখভাল করবে এবং নতুন ঝুঁকি এলে কত দ্রুত ব্যবস্থা নেওয়া হবে- এই তিনটি প্রশ্নের উত্তর নিশ্চিত করতে পারলেই কেবল আমরা সাইবার আক্রমণের আগে নিজেদের ঘর সামলাতে পারব। আর সেই পরিবর্তন শুরু করার সেরা সময় এখনই।

[সম্পাদকীয় নোট]

দেশে ডিজিটাল রূপান্তরের অগ্রযাত্রায় সফটওয়্যারের বহুমাত্রিক বিকাশ ঘটলেও ‘সিকিউর-বাই-ডিজাইন’ (Secure-by-Design) সংস্কৃতি গড়ে না ওঠায় নাগরিকের ব্যক্তিগত ডেটা ও জাতীয় সেবাগুলো যে ক্রমেই অরক্ষিত হয়ে পড়ছে, আলোচ্য নিবন্ধে তার একটি সুনির্দিষ্ট কারিগরি ও নীতিগত বিশ্লেষণ ফুটে উঠেছে। বিশেষ করে সাম্প্রতিক পিএইচপি ও নোড জেএস ত্রুটির প্রেক্ষাপটে গো বা রাস্টের মতো আধুনিক মেমোরি-নিরাপদ ভাষার প্রায়োগিক মূল্যায়ন, সরবরাহ শৃঙ্খল (SBOM) অডিট এবং স্বাধীন গবেষকদের কাজে লাগাতে ‘গভর্নমেন্ট বাগ বাউন্টি’ চালুর প্রস্তাবনাটি অত্যন্ত সময়োপযোগী। দেশের সফটওয়্যার প্রকৌশলী, প্রযুক্তি উদ্যোক্তা ও নীতিনির্ধারকদের মধ্যে দীর্ঘমেয়াদি সাইবার রেজিলিয়েন্স নিশ্চিতের স্বার্থে নিবন্ধটি সম্পাদকীয় প্রমিতকরণসহ প্রকাশ করা হলো।