2.18 নির্ভরতা ও সরবরাহ-শৃঙ্খল ব্যবস্থাপনা

পরিচিতি ও প্রেরণা

আপনার প্রকল্পের লকফাইল খুলে প্যাকেজ গুনুন। বেশিরভাগ দলের মতো হলে আপনার লেখা কোড এমন শত বা হাজার নির্ভরতার ওপর একটি পাতলা স্তর, যা আপনি লেখেননি, পুরোপুরি বোঝেন না এবং সহজে নিরীক্ষা করতে পারেন না। একটি আধুনিক ওয়েব সার্ভিস টেনে আনে একটি ফ্রেমওয়ার্ক, একটি ডেটাবেস ড্রাইভার, একটি লগিং লাইব্রেরি এবং একটি সিরিয়ালাইজেশন ফরম্যাট, আর এগুলোর প্রতিটি আরও টেনে আনে। ফল হলো, আপনার চলমান সফটওয়্যারের বেশিরভাগ, প্রায়ই বিপুল সংখ্যাগরিষ্ঠ অংশ এসেছে ইন্টারনেটের অপরিচিতদের কাছ থেকে। এটি ব্যর্থতা নয়। এটি সেই চুক্তি, যা একটি ছোট দলকে সপ্তাহে পাঠাতে দেয় যা একসময় বছর লাগত। মূল কথা হলো চুক্তিটি চোখ খুলে নেওয়া।

সেই ধার করা কোড ভালোভাবে সামলানো নিজের অধিকারে একটি প্রকৌশল শৃঙ্খলা, এবং এই অধ্যায় তার কারুকাজ নিয়ে: কীভাবে নির্ভরতা বাছেন, পিন করেন, হালনাগাদ করেন, বিল্ড পুনরুৎপাদন করেন এবং পুরো গ্রাফ বাড়লেও পাঠযোগ্য রাখেন। নিরাপত্তা হুমকির দিক, যেখানে আক্রমণকারী ইচ্ছাকৃতভাবে সেই গ্রাফ বিষাক্ত করে, অ্যাপ্লিকেশন নিরাপত্তা বিষয়ক অধ্যায় 4.2-এ পূর্ণ আলোচনা পায়। এখানকার উদ্বেগ প্রতিদিনের প্রকৌশল: সংস্করণ সীমা, লকফাইল, ট্রানজিটিভ দ্বন্দ্ব, হালনাগাদের ছন্দ এবং আপনার সফটওয়্যারে কী আছে তা জানা। এটি ঠিক করলে নিরাপত্তা অনেক সহজ হয়, কারণ যে সরবরাহ শৃঙ্খল দেখতে পান না তা রক্ষা করতে পারেন না।

বড় দল, বিশেষত এন্টারপ্রাইজ ও সরকারের জন্য, পরিসরের সঙ্গে ঝুঁকি বাড়ে। পাঁচশো রিপজিটরি যখন প্রত্যেকে নিজের লাইব্রেরি বাছে, তখন একই লগিং ফ্রেমওয়ার্কের পাঁচশো সামান্য ভিন্ন সংস্করণ, কেউ অনুমোদন না করা একটি লাইসেন্স, এবং গুরুতর দুর্বলতা এলে “আমরা কি প্রভাবিত?” প্রশ্নের উত্তরের কোনো উপায় থাকে না। এন্টারপ্রাইজ এর উত্তর দেয় অনুমোদিত লাইব্রেরি ও ভাগ করা রেজিস্ট্রি দিয়ে। সরকার ক্রমশ উত্তর দেয় আদেশ দিয়ে: যুক্তরাষ্ট্রের Executive Order 14028 তাদের কেনা সফটওয়্যারের ভিত্তিরেখায় একটি সফটওয়্যার বিল অব ম্যাটেরিয়ালস (SBOM) ও বিল্ড উৎস-প্রমাণ ঢুকিয়েছে। যেসব প্রতিষ্ঠান পরবর্তী নির্ভরতা সংকটে শান্ত থাকে, তারা এই কাজ প্রয়োজনের আগেই করেছে।

মূল নীতিসমূহ

• আপনার বেশিরভাগ সফটওয়্যার আপনার না-লেখা কোড; লেখেননি বলেও দায়িত্ব নিজের কাঁধে নিন।
• প্রতিটি নির্ভরতা সম্পদের মতোই স্থায়ী দায়; সেগুলো প্রতিক্রিয়াবশে নয়, সুচিন্তিতভাবে যোগ করুন।
• লকফাইলে সংস্করণ পিন করুন যাতে বিল্ড পুনরুৎপাদনযোগ্য ও নির্ধারিত হয়, “সেদিন যা সর্বশেষ ছিল” নয়।
• বিরল ভয়ংকর লাফে নয়, ছোট স্বয়ংক্রিয় ধাপে স্থির ছন্দে হালনাগাদ করুন।
• আপনার সফটওয়্যারে ঠিক কী আছে জানুন; যা গুনতে পারেন না তা নিরাপদ বা লাইসেন্স করতে পারেন না।
• সুবিধাজনক অনেকগুলোর চেয়ে কম, ভালো-রক্ষণাবেক্ষণ হওয়া নির্ভরতা পছন্দ করুন।
• প্যাকেজ কোথা থেকে আসে তা নিয়ন্ত্রণ করুন; অযাচাইকৃত রেজিস্ট্রি একটি খোলা দরজা।

সুপারিশ

সংস্করণ বুঝুন এবং তা সুচিন্তিতভাবে সীমাবদ্ধ করুন

আপনার ইকোসিস্টেম কীভাবে সংস্করণ প্রকাশ করে তা শিখুন, কারণ আপনার হালনাগাদ আচরণ সম্পূর্ণ তার ওপর চলে। বেশিরভাগ প্যাকেজ ম্যানেজার কোনো না কোনো রূপের সেমান্টিক ভার্সনিং (SemVer) ব্যবহার করে, যেখানে সংস্করণ পড়া হয় MAJOR.MINOR.PATCH হিসেবে: একটি প্যাচ বাম্প কেবল ত্রুটি সমাধানের প্রতিশ্রুতি দেয়, একটি মাইনর বাম্প পশ্চাৎ-সামঞ্জস্যপূর্ণ ফিচার যোগ করে, এবং একটি মেজর বাম্প ভাঙনকারী পরিবর্তনের সংকেত। আপনার নির্ভরতা ঘোষণা তখন একটি সীমা ঠিক করে, যেমন “4.x-এর সঙ্গে সামঞ্জস্যপূর্ণ” বা “অন্তত 2.3.0”, যা রিজলভারকে বলে সংস্করণ বাছার সময় সে কতদূর ঘুরতে পারে।

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

লকফাইল কমিট করুন এবং পুনরুৎপাদনযোগ্য বিল্ড দাবি করুন

একটি লকফাইল আপনার নির্ভরতা গ্রাফের প্রতিটি প্যাকেজের সঠিক সংস্করণ ও ক্রিপ্টোগ্রাফিক হ্যাশ লিপিবদ্ধ করে, সরাসরি ও ট্রানজিটিভ উভয়ই। এটি সংস্করণ নিয়ন্ত্রণে (অধ্যায় 2.6) কমিট করুন এবং আপনার সোর্সের প্রথম-শ্রেণির অংশ গণ্য করুন। এর কাজ আপনার বিল্ডকে একটি ফাংশন করা: একই ইনপুট প্রতিবার, প্রতিটি মেশিনে, এ বছর ও পরের বছর একই আউটপুট দেয়। এটি ছাড়া এক সপ্তাহ ব্যবধানে “ইনস্টল” চালানো দুজন ইঞ্জিনিয়ার ভিন্ন কোড পেতে পারেন, এবং প্রোডাকশনে দেখা দেওয়া একটি ত্রুটি তা বানানো ল্যাপটপে পুনরুৎপাদন করা অসম্ভব হতে পারে।

সত্যিকারের পুনরুৎপাদনযোগ্য বিল্ড লক্ষ্য করুন, যেখানে একটি নির্দিষ্ট কমিট সবসময় আচরণে অভিন্ন আর্টিফ্যাক্ট দেয়। কন্টিনিউয়াস ইন্টিগ্রেশনে (অধ্যায় 8.1) কঠোরভাবে লকফাইল থেকে ইনস্টল করুন এবং লকফাইল ও ম্যানিফেস্ট না মিললে বিল্ড ব্যর্থ করুন, নিঃশব্দে নতুন সংস্করণ রিজলভ না করে। লকফাইলের হ্যাশ দ্বৈত কাজ করে: তারা আচরণ পিন করে এবং হস্তক্ষেপ শনাক্ত করে, কারণ যে প্যাকেজের বিষয়বস্তু আর লিপিবদ্ধ হ্যাশের সঙ্গে মেলে না তা ইনস্টল হবে না। পুনরুৎপাদনযোগ্যতা সেই ভিত্তি, যার ওপর এই অধ্যায়ের বাকি সবকিছু দাঁড়ায়।

ট্রানজিটিভ নির্ভরতা ও ডায়মন্ড দ্বন্দ্ব ইচ্ছাকৃতভাবে সামলান

আপনার সরাসরি নির্ভরতা কেবল সেগুলো, যাদের আপনি নাম দিয়েছেন। তাদের নিচে রয়েছে ট্রানজিটিভ নির্ভরতার অনেক বড় গ্রাফ, আপনার প্যাকেজগুলো যাদের ওপর নির্ভর করে, এবং সেখানেই আপনার বেশিরভাগ ঝুঁকি ও চমক বাস করে। ক্লাসিক ব্যর্থতা হলো ডায়মন্ড নির্ভরতা: লাইব্রেরি A-র একটি ভাগ করা ইউটিলিটির সংস্করণ 1 দরকার, লাইব্রেরি B-র সংস্করণ 2, আর এখন রিজলভারকে একটি অসম্ভব অনুরোধ মেলাতে হয়। কিছু ইকোসিস্টেম একাধিক সংস্করণ সহাবস্থান দেয়, শান্তির জন্য ডিস্ক ও মেমরি খরচ করে; অন্যগুলো একক সংস্করণ চাপায় এবং দ্বন্দ্ব মেটানো আপনার ওপর ছাড়ে।

এই দ্বন্দ্ব পচতে দেওয়ার বদলে দৃশ্যমান করুন। পুরো নির্ভরতা বৃক্ষ ছাপাতে এবং কোনো প্যাকেজ কেন আছে ও কে তা টেনে এনেছে তা ব্যাখ্যা করতে আপনার টুলিং ব্যবহার করুন। দ্বন্দ্ব দেখা দিলে ইচ্ছাকৃতভাবে মেটান: পিছিয়ে থাকাটিকে আপগ্রেড করুন, একটি ওভাররাইড পিন করুন, বা যে নির্ভরতার দাবি মেটাতে পারেন না তা বাদ দিন। সময়ের সঙ্গে গ্রাফের বৃদ্ধি লক্ষ্য রাখুন, কারণ ট্রানজিটিভ নির্ভরতায় অনিয়ন্ত্রিত বিস্তার প্রযুক্তিগত ঋণের ধীর সঞ্চয়, যা শেষে অসমাধানযোগ্য আপগ্রেড বা পুনর্লিখন ছাড়া প্যাচ করা যায় না এমন দুর্বলতা হয়ে দেখা দেয়।

স্বয়ংক্রিয় পুল রিকোয়েস্টসহ স্থির ছন্দে হালনাগাদ করুন

সবচেয়ে ঝুঁকিপূর্ণ হালনাগাদ কৌশলটি সেটি, যাতে বেশিরভাগ দল দুর্ঘটনাবশত ভেসে যায়: কখনো হালনাগাদ নয়, তারপর একটি জটিল দুর্বলতা বাধ্য করলে জরুরি চাপে সবকিছু একসঙ্গে হালনাগাদ। তখন আপনি বছর পিছিয়ে, চেঞ্জলগ একটি দেয়াল, এবং আপগ্রেড নিয়মিত কাজ না হয়ে বহু-সপ্তাহের প্রকল্প। সমাধান ছন্দ। একটি স্বয়ংক্রিয় নির্ভরতা হালনাগাদকারী ধরুন (Dependabot ও Renovate টুল সাধারণ উদাহরণ) যা কোনো নির্ভরতার নতুন সংস্করণ এলেই চেঞ্জলগ ও আপনার টেস্ট ফলাফল সংযুক্ত করে একটি পুল রিকোয়েস্ট খোলে।

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

আপনার পদচিহ্ন ছোট রাখুন এবং গ্রহণের আগে মূল্যায়ন করুন

আপনার যোগ করা প্রতিটি নির্ভরতা একটি স্থায়ী প্রতিশ্রুতি: তার ত্রুটি, তার দুর্বলতা, তার লাইসেন্স, তার রক্ষণাবেক্ষণকারীর অব্যাহত আগ্রহ এবং তার নিজস্ব বাড়তে থাকা উপ-নির্ভরতার গ্রাফের প্রতি। সামলানোর সবচেয়ে সস্তা নির্ভরতা সেটি, যা আপনি যোগ করেননি। কোনো প্যাকেজ ধরার আগে জিজ্ঞেস করুন আপনার নিজের কয়েক ডজন লাইন কোড কি যথেষ্ট হবে, বিশেষত তুচ্ছ কার্যকারিতার জন্য। প্যাকেজ ইকোসিস্টেমের ইতিহাস সতর্কবার্তায় ভরা, যেখানে একটি ক্ষুদ্র, ব্যাপকভাবে-নির্ভর-করা প্যাকেজ সরানো বা ছিনতাই হয়ে অর্ধেক ইন্টারনেট ভেঙে দিয়েছে।

গ্রহণ করলে প্রার্থীকে সেই দীর্ঘমেয়াদি সম্পর্কের মতো মূল্যায়ন করুন যা সে আসলে। রক্ষণাবেক্ষণের স্বাস্থ্য দেখুন: সাম্প্রতিক কমিট, সাড়াদায়ী রক্ষণাবেক্ষণকারী, প্রকৃত রিলিজ ইতিহাস, এবং চাবি আছে এমন একাধিক ব্যক্তি। লাইসেন্স দেখুন এবং নিশ্চিত করুন তা আপনার অনুমোদিত তালিকায় (অধ্যায় 10.3)। এর নিরাপত্তা রেকর্ড, আকার ও নিজস্ব ট্রানজিটিভ পদচিহ্ন দেখুন, কারণ একটি ছোট ফিচারের জন্য একশো প্যাকেজ টেনে আনা পোষায় না। এই মানদণ্ড লিখে রাখুন, যাতে “এটি কি যোগ করব?” মেজাজ না হয়ে আপনার পুরো দলের সামঞ্জস্যপূর্ণভাবে প্রয়োগ করা একটি চেকলিস্ট হয়।

একটি SBOM তৈরি করুন এবং বিল্ড উৎস-প্রমাণ ধরে রাখুন

আপনার সফটওয়্যারে কী আছে আগে থেকে না জানলে “আমরা কি এই দুর্বলতায় প্রভাবিত?” প্রশ্নের দ্রুত উত্তর দিতে পারবেন না। SBOM হলো উত্তর: একটি বিল্ডের প্রতিটি উপাদানের যন্ত্রপাঠযোগ্য তালিকা, সংস্করণ ও লাইসেন্সসহ, SPDX বা CycloneDX-এর মতো প্রমিত ফরম্যাটে। আপনার বিল্ড পাইপলাইনের অংশ হিসেবে স্বয়ংক্রিয়ভাবে একটি তৈরি করুন, আর্টিফ্যাক্টের পাশে সংরক্ষণ করুন, এবং সেই আর্টিফ্যাক্ট যতদিন কোথাও চলে ততদিন রাখুন। পরবর্তী শিরোনামের দুর্বলতা এলে আপনার SBOM-এর বিরুদ্ধে একটি কোয়েরি এক সপ্তাহের উন্মত্ত grep-কে পাঁচ মিনিটের প্রতিবেদনে বদলে দেয়।

এক ধাপ এগিয়ে উৎস-প্রমাণ ধরে রাখুন: একটি আর্টিফ্যাক্ট কীভাবে, কোন সোর্স কমিট থেকে, কোন পাইপলাইনে বানানো হয়েছে তার স্বাক্ষরিত, হস্তক্ষেপ-প্রকাশক নথি। ওপেন-সোর্স সফটওয়্যার সম্প্রদায় ঠিক এর জন্য SLSA কাঠামো (Supply-chain Levels for Software Artifacts) একটি ধাপবদ্ধ মডেল হিসেবে গ্রহণ করেছে, যা “আমরা আমাদের বিল্ড বর্ণনা করতে পারি” থেকে “আমরা তা প্রমাণ করতে পারি, এবং প্রমাণ আপসকৃত বিল্ড সিস্টেমকেও প্রতিরোধ করে” পর্যন্ত যায়। সত্যায়ন ভোক্তাকে যাচাই করতে দেয় একটি আর্টিফ্যাক্ট সত্যিই আপনার পাইপলাইন থেকে এসেছে। সরকারি কাজে এটি ক্রমশ ঐচ্ছিক নয়; উৎস-প্রমাণ ও SBOM ক্রয়ের আদেশের ভেতরে বসে, তাই সামর্থ্য আগেভাগে গড়লে আপনি দরপত্রের যোগ্য থাকেন।

রেজিস্ট্রি, মিরর ও ভেন্ডরিং দিয়ে আপনার উৎস নিয়ন্ত্রণ করুন

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

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

ট্রেড-অফ: সুবিধা ও অসুবিধা

পদ্ধতি	সুবিধা	অসুবিধা
ঢিলা সংস্করণ পরিসর	স্বয়ংক্রিয় সমাধান; কম হাতের পরিশ্রম	অপর্যালোচিত কোড প্রোডাকশনে পৌঁছায়; লকফাইল ছাড়া অনির্ধারিত
কঠোর পিনিং ও লকফাইল	পুনরুৎপাদনযোগ্য, নিরীক্ষণযোগ্য বিল্ড	সুচিন্তিত হালনাগাদ কাজ লাগে; সমাধানে পিছিয়ে পড়তে পারে
আক্রমণাত্মক হালনাগাদ ছন্দ	ছোট, নিরাপদ ধাপ; সবসময় সর্বশেষের কাছাকাছি	নিরন্তর আলোড়ন; পর্যালোচকের স্থির মনোযোগ লাগে
বিরল, ব্যাচ করা বড় আপগ্রেড	দিনের পর দিন কম বিঘ্ন	ভয়ংকর, ঝুঁকিপূর্ণ, বাধ্য হলে ব্যয়বহুল
অনেক সুবিধাজনক নির্ভরতা	ফিচার দ্রুত বানানো যায়	বড় আক্রমণ-পৃষ্ঠ; ভারী রক্ষণাবেক্ষণ বোঝা
ন্যূনতম পদচিহ্ন ও ভেন্ডরিং	নিয়ন্ত্রণ, ছোট পৃষ্ঠ, আপস্ট্রিম ঝুঁকি নেই	আপনার মালিকানার কোড বেশি; হালনাগাদ নিজেই বইতে হয়
সরাসরি পাবলিক রেজিস্ট্রি	কোনো সেটআপ নেই	বিভ্রাট, ইয়ানক্, বিভ্রান্তি ও টাইপোস্কোয়াটিংয়ের ঝুঁকি
অভ্যন্তরীণ রেজিস্ট্রি ও মিরর	গতি, নীতি প্রয়োগ, নিরোধ	চালানো ও রক্ষণাবেক্ষণের অবকাঠামো

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

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

1. আপনার প্রকৃত হালনাগাদ ছন্দ কী, এবং বাধ্যতামূলক জরুরি আপগ্রেডে ঘণ্টা লাগবে নাকি সপ্তাহ? একটি জটিল দুর্বলতা বিষয়টি বাধ্য না করা পর্যন্ত বেশিরভাগ দল এর সৎ উত্তর দিতে পারে না। অধ্যায়টি স্থির, স্বয়ংক্রিয়, ছোট-ধাপের হালনাগাদকে নিরাপদ পথ এবং বিরল বিগ-ব্যাং আপগ্রেডকে বিপজ্জনক গণ্য করে, কারণ যে ফাঁক আপনি খোলা রাখেন, পরে চাপের মুখে সেটিই আপনাকে দৌড়ে পেরোতে হয়। প্রমাণ আনুন: আপনার কতগুলো নির্ভরতা এক মেজর সংস্করণের বেশি পিছিয়ে, এবং আপনার শেষ উল্লেখযোগ্য আপগ্রেডে আসলে কত সময় লেগেছিল। আলোচনা করুন আপনি স্বয়ংক্রিয় হালনাগাদকারী গ্রহণ করতে পারেন কি না, মানুষ যাতে মনোযোগ না হারায় সেজন্য কম-ঝুঁকির পরিবর্তন কীভাবে ব্যাচ করবেন, এবং স্বয়ংক্রিয়-মার্জ নিরাপদ হতে কোন টেস্টিং দরকার। উত্তর বদলে দেওয়া উচিত আপনি প্রকৌশল সময় কীভাবে বাজেট করেন, একটি বিরল সংকটকে নিয়মিত সাপ্তাহিক করে পরিণত করে। সৎ উত্তর “সপ্তাহ” হলে সেটি এখনই নাম দেওয়ার ঝুঁকি, ঘটনার মাঝখানে আবিষ্কারের নয়।

2. এখনই একটি সাধারণ লাইব্রেরিতে গুরুতর দুর্বলতা ঘোষিত হলে আপনি যে প্রতিটি আর্টিফ্যাক্ট চালান তার কতগুলো প্রভাবিত তা কত দ্রুত তালিকাভুক্ত করতে পারতেন? এই প্রশ্নের উত্তর দিতেই SBOM আছে, এবং আপনার উত্তরের গতি আপনার সরবরাহ-শৃঙ্খল পরিপক্বতার সরাসরি পরিমাপ। তালিকা ছাড়া আপনি রিপজিটরি grep করা ও দলের সাক্ষাৎকারে নেমে আসেন, যা ঘড়ি চলার সময় আপনার হাতে না থাকা দিন নেয়। সুনির্দিষ্ট সংকেত আনুন: আপনি কি প্রতি বিল্ডে একটি SBOM তৈরি করেন, তা কোথায় সংরক্ষিত, এবং আজ কি সবগুলো জুড়ে আসলে কোয়েরি করতে পারেন? আলোচনা করুন আপনি কেবল সরাসরি নয়, ট্রানজিটিভ গ্রাফও জানেন কি না, কারণ দুর্বল প্যাকেজ সাধারণত এমন একটি যার নাম আপনি কখনো দেননি। উত্তর ঠিক করে আপনার পরবর্তী ঘটনা একটি কোয়েরি নাকি অগ্নি-মহড়া, এবং দরকারের আগেই সামর্থ্য গড়া সার্থক। সরকারগুলো ঠিক এই কারণেই এখন এটি বাধ্যতামূলক করছে।

3. নতুন নির্ভরতা গ্রহণযোগ্য কি না তা কীভাবে ঠিক করেন, এবং সবাই কি একই মান প্রয়োগ করে? অধ্যায়টি যুক্তি দেয় প্রতিটি নির্ভরতা সুবিধার পাশাপাশি স্থায়ী দায়, এবং সামলানোর সবচেয়ে সস্তা নির্ভরতা সেটি, যা আপনি কখনো যোগ করেননি। তবু বেশিরভাগ দলে সিদ্ধান্তটি অদৃশ্য: একজন ইঞ্জিনিয়ারের একটি ফিচার দরকার, একটি প্যাকেজ খুঁজে পান, আর তার রক্ষণাবেক্ষণ, লাইসেন্স, নিরাপত্তা ইতিহাস বা পদচিহ্ন পর্যালোচনা ছাড়া দুপুরের খাবারের মধ্যে তা লকফাইলে। আপনার নিজের গ্রাফ থেকে এমন প্যাকেজের উদাহরণ আনুন যা গ্রহণ করার কথা কারও মনে নেই এবং আজ রক্ষা করতে পারবেন না। আলোচনা করুন একটি লিখিত মূল্যায়ন চেকলিস্ট ও অনুমোদিত-লাইব্রেরি তালিকা (অধ্যায় 10.3) সাহায্য করবে নাকি কেবল ঘর্ষণ যোগ করবে, এবং আপনার নিজে লেখার মতো তুচ্ছ সহায়ক ও নির্ভর করার যোগ্য প্রকৃত অবকাঠামোর মধ্যে রেখা কোথায়। উত্তর আকার দেয় আপনার দল দীর্ঘমেয়াদে একটি একটি ছোট সিদ্ধান্তে কতটা ওজন বইবে।

4. আপনি কি আপনার ট্রানজিটিভ নির্ভরতা সত্যিই শাসন করেন, নাকি কেবল যেগুলোর নাম দিয়েছেন? আপনার বেশিরভাগ ঝুঁকি এক স্তর নিচে বাস করে, আপনার প্যাকেজগুলো যা টেনে এনেছে সেখানে, এবং একটি ভাগ করা ইউটিলিটির অসামঞ্জস্যপূর্ণ সংস্করণ চাওয়া দুটি লাইব্রেরির ডায়মন্ড দ্বন্দ্ব সবচেয়ে খারাপ মুহূর্তে একটি আপগ্রেড আটকে দিতে পারে। বড় পরিসরে এটি গুরুত্বপূর্ণ কারণ একটিমাত্র অপ্যাচযোগ্য ট্রানজিটিভ প্যাকেজ শত শত রিপজিটরি জুড়ে একটি নিরাপত্তা সমাধান জমিয়ে দিতে পারে, এবং প্রতিদ্বন্দ্বী টান প্রকৃত: পুরো গ্রাফ তুলে ধরা ও পিন করা চলমান পরিশ্রম খরচ করে, আর তা উপেক্ষা সেই পরিশ্রম বিনিময় করে ঋণের ধীর সঞ্চয়ের সঙ্গে, যা অসমাধানযোগ্য আপগ্রেড হয়ে ওঠে। প্রমাণ আনুন: আপনার টুলিং কি পুরো বৃক্ষ ছাপাতে এবং কোনো প্যাকেজ কেন আছে ও কে তা টেনে এনেছে ব্যাখ্যা করতে পারে, এবং আজ আপনার সবচেয়ে সাধারণ লাইব্রেরির কতগুলো ভিন্ন সংস্করণ সহাবস্থান করে? এন্টারপ্রাইজ ও সরকারের জন্য যোগ করুন আপনার তালিকা ও নীতি ট্রানজিটিভ উপাদান পর্যন্ত আদৌ পৌঁছায় কি না, কারণ আপনার সফটওয়্যারে কী আছে জানার আদেশ অর্থহীন যদি অর্ধেক গ্রাফ আপনার কাছে অদৃশ্য। উত্তর বলে আপনার পরবর্তী বাধ্যতামূলক আপগ্রেড একটি নিয়মিত মার্জ নাকি বহু-দলের খননকাজ।

5. আপনার প্যাকেজ আসলে কোথা থেকে আসে, এবং আক্রমণকারীকে একটি ঢুকিয়ে দেওয়া থেকে কী ঠেকায়? সরাসরি পাবলিক ইন্টারনেট থেকে টানা প্রতিটি বিল্ড তার বিভ্রাট, তার ইয়ানক্ করা সংস্করণ এবং দুটি নির্দিষ্ট আক্রমণ উত্তরাধিকার পায়: নির্ভরতা বিভ্রান্তি, যেখানে একটি বিল্ড টুল আপনার ব্যক্তিগত প্যাকেজকে আড়াল করা একটি পাবলিক প্যাকেজ আনে, এবং টাইপোস্কোয়াটিং, যেখানে একটি ক্ষতিকর প্যাকেজ জনপ্রিয় নামের এক কি-স্ট্রোক দূরে বসে। বড় দলের জন্য এটি গুরুত্বপূর্ণ কারণ একটিমাত্র বিষাক্ত ফেচ কেউ লক্ষ্য করার আগে আপনার পুরো সম্পদ জুড়ে ছড়াতে পারে, এবং বিনিময় প্রকৃত: একটি অভ্যন্তরীণ রেজিস্ট্রি বা ক্যাশিং মিরর আপনাকে নীতি চোকপয়েন্ট ও আপস্ট্রিম থেকে নিরোধ দেয়, কিন্তু এটি এমন অবকাঠামো যা কাউকে চালাতে ও হালনাগাদ রাখতে হয়। সুনির্দিষ্ট সংকেত আনুন: অভ্যন্তরীণ প্যাকেজের নাম কি সুস্পষ্টভাবে স্কোপ করা ও অভ্যন্তরীণ উৎসে পিন করা, কোনো অনুমোদন-তালিকা আছে কি না, এবং কোনো নতুন রিলিজ ব্যবহারের আগে সংক্ষিপ্ত কোয়ারেন্টাইন পায় কি না? সরকারি ও নিয়ন্ত্রিত ক্রেতাদের জন্য এটি ক্রয়ের ক্রমবর্ধমান দাবি অনুমোদিত-সফটওয়্যার-তালিকা ও সরাসরি-ইন্টারনেট-নেই অবস্থানের সঙ্গে বাঁধুন, এবং সৎ থাকুন আপনার বর্তমান ব্যবস্থা আজ সেই মান পূরণ করত কি না।

6. আপনার আর্টিফ্যাক্ট কীভাবে বানানো হয়েছে তা কি আপনি আসলে পুনরুৎপাদন ও প্রমাণ করতে পারেন? ক্রিপ্টোগ্রাফিক হ্যাশসহ একটি কমিট করা লকফাইল আপনার বিল্ডকে ফাংশন করা উচিত, একই ইনপুট প্রতিটি মেশিনে এ বছর ও পরের বছর একই আউটপুট দেয়, আর উৎস-প্রমাণ যে কাউকে যাচাই করতে দেওয়া উচিত একটি আর্টিফ্যাক্ট সত্যিই আপনার পাইপলাইন ও সোর্স কমিট থেকে এসেছে। এটি গুরুত্বপূর্ণ কারণ অপুনরুৎপাদনযোগ্য বিল্ড একটি প্রোডাকশন ত্রুটিকে অসমাধানযোগ্য রহস্যে পরিণত করে এবং হস্তক্ষেপ ঘটেনি তা প্রমাণ করতে অক্ষম রাখে, এবং প্রতিদ্বন্দ্বী বিবেচনা পরিশ্রম বনাম নিশ্চয়তা: কঠোর লকফাইল ইনস্টল, স্বাক্ষরিত সত্যায়ন এবং SLSA-সংগত উৎস-প্রমাণ এমন সেটআপ ও শৃঙ্খলা খরচ করে, যা “শুধু সর্বশেষ ইনস্টল করো” প্রবাহ এড়ায়। প্রমাণ আনুন: লকফাইল ও ম্যানিফেস্ট না মিললে কন্টিনিউয়াস ইন্টিগ্রেশন কি ব্যর্থ হয়, আপনি কি প্রতি বিল্ডে একটি SBOM ও স্বাক্ষরিত উৎস-প্রমাণ নথি তৈরি ও সংরক্ষণ করেন, এবং কেউ কি কখনো একটি যাচাই করেছেন? এন্টারপ্রাইজ ও বিশেষত সরকারি কাজে উৎস-প্রমাণ ও SBOM ক্রমশ ক্রয়ের আদেশের ভেতরে বসে, তাই এখানে সৎ উত্তর ঠিক করে আপনি দরপত্রের যোগ্য থাকবেন নাকি বাদ পড়বেন।

খাতভেদে দৃষ্টিভঙ্গি

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

ছোট ব্যবসা। নির্ভরতা বিশেষজ্ঞ নেই আর বাজেট কম, তাই শৃঙ্খলা গড়ার বদলে কিনুন। আপনার হোস্টিং ও কোড প্ল্যাটফর্ম ইতিমধ্যে যে হালনাগাদ স্বয়ংক্রিয়তা দেয় তার ওপর নির্ভর করুন, পরিপক্ব লাইব্রেরির একটি ছোট সেট পছন্দ করুন যাতে আপগ্রেড সস্তা থাকে, এবং পাইপলাইনে একটি বিনামূল্যের SBOM জেনারেটর ব্যবহার করুন যাতে লোক না রেখেই “আমরা কি প্রভাবিত?” প্রশ্নের উত্তর দিতে পারেন। আপনার সীমিত মনোযোগ ব্যয় করুন লাইসেন্স যাচাই এবং এক ডজন লাইনে নিজে লিখতে পারার মতো তুচ্ছ প্যাকেজ গ্রহণ না করায়।

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

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

উদাহরণ

স্টার্টআপ। ছয়জনের একটি স্টার্টআপ একটি ফ্রেমওয়ার্ক, একটি পেমেন্ট লাইব্রেরি এবং তাদের কখনো পরিদর্শন না করা প্রায় নয়শো ট্রানজিটিভ প্যাকেজের ওপর একটি ওয়েব অ্যাপ্লিকেশন পাঠায়। তারা প্ল্যাটফর্ম দল রাখতে পারে না, তাই স্বয়ংক্রিয়তার ওপর ভর করে: প্রথম দিন থেকে কমিট করা লকফাইল, এমন একটি স্বয়ংক্রিয় হালনাগাদকারী যা প্যাচ রিলিজ ব্যাচ করে সবুজ টেস্টে মার্জ করে, এবং জমে ওঠা মেজর-সংস্করণ বাম্প পর্যালোচনার জন্য মাসে এক ঘণ্টা। নির্ভরতা যোগ করার তাদের এক-অনুচ্ছেদের নিয়ম বেশিরভাগ “বিরক্তিকর, ভালো-রক্ষণাবেক্ষণ হওয়া লাইব্রেরি পছন্দ করো, আর ক্ষুদ্রগুলো নিয়ে দুবার ভাবো।” একটি জনপ্রিয় প্যাকেজ আপস হলে তাদের কমিট করা লকফাইল হ্যাশের কারণে বিষাক্ত সংস্করণ ইনস্টলই হয়নি, এবং তারা ঘটনাটি বেঁচে নেওয়ার বদলে পড়েছে।

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

সরকার। একটি ফেডারেল সংস্থা Executive Order 14028-এ ফিরে যাওয়া উৎস-প্রমাণ ও SBOM প্রয়োজনের অধীনে সফটওয়্যার কেনে। বিক্রেতাদের প্রতিটি রিলিজের সঙ্গে যন্ত্রপাঠযোগ্য SBOM সরবরাহ করতে এবং SLSA কাঠামোর সঙ্গে সংগত বিল্ড উৎস-প্রমাণ দেখাতে হয়, যাতে সংস্থা যাচাই করতে পারে প্রতিটি আর্টিফ্যাক্ট দাবিকৃত সোর্স থেকে এসেছে। ভেতরে ডেভেলপাররা কেবল অনুমোদিত সফটওয়্যার তালিকা থেকে ইনস্টল করতে পারেন, পাবলিক ইন্টারনেটে সরাসরি পথবিহীন একটি অভ্যন্তরীণ মিরর থেকে সেবা-পাওয়া। দীর্ঘমেয়াদি সহায়তাযোগ্যতা পছন্দ চালায়: তারা স্থিতিশীল রক্ষণাবেক্ষণ ও স্পষ্ট লাইসেন্সসহ নির্ভরতা পছন্দ করে, কারণ একটি সিস্টেম পনেরো বছর চলতে পারে এবং পুরোটা সময় প্যাচযোগ্য থাকতে হবে। কোনো উপাদান জীবনাবসানে পৌঁছালে জরুরি অবস্থার বদলে পরিকল্পিত স্থানান্তর তা প্রতিস্থাপন করে।

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

নির্ভরতা শৃঙ্খলার প্রতিদান মূলত মাপা হয় না-ঘটা বিপর্যয়ে। একটি কমিট করা লকফাইল ও পুনরুৎপাদনযোগ্য বিল্ড গ্রহণে প্রায় কিছুই খরচ হয় না এবং “আমার মেশিনে চলে” ত্রুটির পুরো শ্রেণি ও অপুনরুৎপাদনযোগ্য প্রোডাকশন ত্রুটি দূর করে, যার প্রতিটি জ্যেষ্ঠ প্রকৌশল সময়ের দিনের পর দিন পুড়িয়ে দিতে পারে। একটি স্বয়ংক্রিয় হালনাগাদ ছন্দ মাঝেমধ্যের বহু-সপ্তাহের জরুরি আপগ্রেড, যে ধরন রোডম্যাপ থামায় ও দলকে ক্লান্ত করে, ছোট মার্জ করা পরিবর্তনের স্থির মৃদু গুঞ্জনে বদলে দেয়। বহু রিপজিটরির পোর্টফোলিও জুড়ে বিরল-ও-বিশাল থেকে ঘন-ও-ক্ষুদ্রে এই পরিবর্তন একটি প্রকৌশল প্রতিষ্ঠানের হাতে থাকা সর্বোচ্চ-লিভারেজ প্রক্রিয়া পরিবর্তনের একটি।

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

অ্যান্টি-প্যাটার্ন ও ফাঁদ

• লকফাইল নেই, বা কমিট করা নেই: বিল্ড প্রতিবার নতুন করে রিজলভ হয়, তাই কেউ নির্ভরযোগ্যভাবে পুনরুৎপাদন করতে পারে না কী পাঠানো বা কী ভেঙেছে।
• প্রোডাকশনে ভাসমান “latest”: সেই মিনিটে রেজিস্ট্রি যা দিয়েছে তাই আপনার রিলিজ, অপর্যালোচিত ও অনুসরণ-অযোগ্য।
• বাধ্য না হওয়া পর্যন্ত কখনো হালনাগাদ নয়: বছরের জমে-থাকা পিছিয়ে পড়া দুর্বলতার চাপে একটি ভয়ংকর, উচ্চ-ঝুঁকির জরুরি আপগ্রেডে ধসে পড়ে।
• আপডেট-বট ক্লান্তি: ব্যাচ না করা পুল রিকোয়েস্টের বন্যা দলকে সবগুলো, জরুরিগুলোসহ, উপেক্ষা করতে শেখায়।
• নির্ভরতার বিস্তার: তুচ্ছ ফিচারের জন্য প্রতিক্রিয়াবশে প্যাকেজ যোগ করে অরক্ষণযোগ্য গ্রাফ ও বিস্তৃত আক্রমণ-পৃষ্ঠ বাড়ানো।
• তালিকা নেই: SBOM ছাড়া “আমরা কি প্রভাবিত?” উত্তর দেওয়া মানে রিপজিটরি জুড়ে দিনের পর দিন হাতে প্রত্নতত্ত্ব।
• পাবলিক রেজিস্ট্রিকে অন্ধভাবে বিশ্বাস: সরাসরি টানা আপনাকে বিভ্রাট, ইয়ানক্ করা সংস্করণ, নির্ভরতা বিভ্রান্তি ও টাইপোস্কোয়াটিংয়ের মুখে ফেলে।
• ট্রানজিটিভ নির্ভরতা উপেক্ষা: কেবল নামকরা জিনিস শাসন করা, যখন বেশিরভাগ ঝুঁকি এক স্তর নিচে লুকিয়ে।
• অযাচাইকৃত লাইসেন্স: আপনি যেভাবে পাঠান তার সঙ্গে সংঘর্ষ করা লাইসেন্সের কোড টেনে আনা, যা ধরা পড়ে কেবল নিরীক্ষা বা অধিগ্রহণে।

পরিপক্বতা মডেল

• স্তর ১, সূচনা: মূল্যায়ন ছাড়াই নির্ভরতা অবাধে যোগ হয়। কোনো কমিট করা লকফাইল নেই, বিল্ড পুনরুৎপাদনযোগ্য নয়, হালনাগাদ কেবল বাধ্যতামূলক জরুরি অবস্থায়, এবং সফটওয়্যারে কী আছে কেউ তালিকাভুক্ত করতে পারে না।
• স্তর ২, বিকাশ: কিছু দল লকফাইল কমিট করে ও মোটামুটি পুনরুৎপাদনযোগ্য বিল্ড পায়, এবং সামান্য স্বয়ংক্রিয়তা হালনাগাদ পুল রিকোয়েস্ট খোলে, কিন্তু রিপজিটরি থেকে রিপজিটরিতে চর্চা অসঙ্গত। লাইসেন্স ও ট্রানজিটিভ ঝুঁকি সম্পর্কে সচেতনতা অনানুষ্ঠানিক, কোনো ভাগ করা নীতি, তালিকা বা প্যাকেজ কোথা থেকে আসে তার ওপর নিয়ন্ত্রণ নেই।
• স্তর ৩, মানসম্মতকরণ: চর্চা নথিবদ্ধ এবং সর্বত্র প্রয়োগ হয়। একটি স্বয়ংক্রিয় হালনাগাদকারী যুক্তিসঙ্গত ব্যাচিংসহ স্থির ছন্দে চলে, বিল্ড কঠোরভাবে লকফাইল থেকে ইনস্টল করে এবং লকফাইল ও ম্যানিফেস্ট না মিললে ব্যর্থ হয়, প্রতি বিল্ডে একটি SBOM তৈরি হয়, একটি অভ্যন্তরীণ রেজিস্ট্রি উৎস ও লাইসেন্স নীতি প্রয়োগ করে, এবং নতুন নির্ভরতা প্রতিটি দলের প্রয়োগ করা একটি লিখিত চেকলিস্টের বিপরীতে মূল্যায়িত হয়।
• স্তর ৪, ব্যবস্থাপনা: নির্ভরতা সম্পদ ভিত্তিরেখার বিপরীতে তথ্য দিয়ে মাপা ও নিয়ন্ত্রিত। আপনি সংস্করণ-পিছিয়ে-থাকা (কতগুলো নির্ভরতা এক মেজর সংস্করণের বেশি পিছিয়ে), সব আর্টিফ্যাক্ট জুড়ে একটি জটিল দুর্বলতা প্যাচের গড় সময়, স্বয়ংক্রিয়-হালনাগাদ মার্জ হার, পাঠানো বিল্ডের শতাংশ হিসেবে SBOM কভারেজ, এবং অমীমাংসিত ডায়মন্ড দ্বন্দ্ব ও নীতি ব্যতিক্রমের সংখ্যা অনুসরণ করেন। এই মেট্রিক রিলিজ গেট করে এবং আপনি কোথায় পরিশ্রম ব্যয় করবেন তা চালায়, তাই আপগ্রেড ও প্রতিকার সবচেয়ে জোরে চিৎকার করা ব্যক্তির দ্বারা নয়, প্রমাণ দিয়ে পরিচালিত হয়।
• স্তর ৫, সমন্বয়: নির্ভরতা ব্যবস্থাপনা নিরন্তর উন্নত ও প্রতিষ্ঠান জুড়ে একীভূত। বিল্ড উৎস-প্রমাণ ও সত্যায়ন ধরা ও যাচাই করা হয়, SBOM তাৎক্ষণিক দুর্বলতা-সাড়ার জন্য পুরো পোর্টফোলিও জুড়ে কোয়েরিযোগ্য, সমন্বিত আপগ্রেড বহু রিপজিটরি জুড়ে স্বয়ংক্রিয়ভাবে ছড়ায়, গোল্ডেন লাইব্রেরি বাছাই ও ইনার-সোর্স করা হয়, এবং ইকোসিস্টেম, হুমকি ও ক্রয়ের আদেশ সরলে পুরো ব্যবস্থা খাপ খায়।

আলোচনার ভাবনা

1. একটি ছোট ইউটিলিটি নিজে লেখা এবং তার জন্য নির্ভরতা নেওয়ার মধ্যে আপনার দলের সঠিক রেখা কোথায়?
2. আপনার সংস্করণ সীমা কতটা ঢিলা বা আঁটো হওয়া উচিত, এবং অ্যাপ্লিকেশন বনাম প্রকাশিত লাইব্রেরির জন্য উত্তর কি আলাদা?
3. কম-ঝুঁকির প্যাচ হালনাগাদ কি সবুজ টেস্টে স্বয়ংক্রিয়-মার্জ হওয়া উচিত, এবং তা নিরাপদ করতে আপনার টেস্ট স্যুটের কী দরকার?
4. আপনার প্রতিষ্ঠানের আকার ও ঝুঁকির ধরনের জন্য কি একটি অভ্যন্তরীণ রেজিস্ট্রি বা মিরর চালানোর পরিচালন খরচ সার্থক?
5. সর্বোচ্চ নিয়ন্ত্রণের জন্য কোন নির্ভরতা ভেন্ডর করবেন, আর কোনগুলো পাবলিক রেজিস্ট্রিতে রাখবেন, তা কীভাবে অগ্রাধিকার দেবেন?
6. এই ত্রৈমাসিক থেকে শুরু করে আপনার পাঠানো প্রতিটি আর্টিফ্যাক্টের জন্য একটি SBOM তৈরি ও আসলে ব্যবহার করতে কী লাগবে?

প্রধান শিক্ষা

• আপনার বেশিরভাগ সফটওয়্যার ধার করা কোড; তা ভালোভাবে সামলানো একটি মূল প্রকৌশল শৃঙ্খলা, পরবর্তী ভাবনা নয়।
• লকফাইল কমিট করুন এবং পুনরুৎপাদনযোগ্য, নির্ধারিত বিল্ড দাবি করুন যাতে একই ইনপুট সবসময় একই আউটপুট দেয়।
• বিরল, বাধ্যতামূলক, ভয়ংকর লাফের বদলে ছোট স্বয়ংক্রিয় ধাপে নিরন্তর হালনাগাদ করুন।
• একটি লিখিত মানদণ্ডের বিপরীতে সুচিন্তিতভাবে নির্ভরতা যোগ করুন; সামলানোর সবচেয়ে সস্তা সেটি, যা আপনি কখনো নেননি।
• একটি SBOM তৈরি করুন এবং উৎস-প্রমাণ ধরে রাখুন যাতে আপনি সবসময় জানেন আপনার সফটওয়্যারে কী আছে এবং তা কোথা থেকে এসেছে।
• বিভ্রান্তি, টাইপোস্কোয়াটিং ও আপস্ট্রিম ব্যর্থতার বিরুদ্ধে প্রতিরক্ষায় একটি অভ্যন্তরীণ রেজিস্ট্রি দিয়ে আপনার উৎস নিয়ন্ত্রণ করুন।

তথ্যসূত্র ও আরও পড়ার জন্য

• U.S. Executive Order 14028, Improving the Nation’s Cybersecurity (2021)
• National Institute of Standards and Technology (NIST), Secure Software Development Framework (SP 800-218)
• SLSA (Supply-chain Levels for Software Artifacts) framework specification, Open Source Security Foundation
• OWASP CycloneDX specification এবং SPDX specification, SBOM ফরম্যাটের জন্য
• Tom Preston-Werner, Semantic Versioning Specification (SemVer)
• The Reproducible Builds project documentation
• Nicole Forsgren, Jez Humble, Gene Kim, Accelerate: The Science of Lean Software and DevOps