4.2 অ্যাপ্লিকেশন নিরাপত্তা

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

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

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

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

আরও দেখুন: অধ্যায় 4.1 (নিরাপত্তার ভিত্তি, হুমকি মডেলিং ও নিরাপদ উন্নয়ন জীবনচক্র), অধ্যায় 10.3 (ওপেন-সোর্স সরবরাহ শৃঙ্খল ও লাইসেন্সিং), এবং অধ্যায় 10.2 (SBOM, ঝুঁকি ও নিশ্চয়তা)।

মূল নীতিসমূহ

• ইনপুটে কখনো বিশ্বাস করবেন না। আস্থা সীমানা পেরোনো সব ডেটা যাচাই না হওয়া পর্যন্ত বৈরী গণ্য করুন।
• নিরাপদ ডিফল্ট। নিরাপদ পথ সহজ পথ হওয়া উচিত; অনিরাপদ আচরণে সচেতন, দৃশ্যমান পরিশ্রম লাগা উচিত।
• বন্ধ অবস্থায় ব্যর্থ হোন। একটি নিরাপত্তা পরীক্ষা সম্পূর্ণ হতে না পারলে অ্যাক্সেস অনুমতি দেওয়ার বদলে প্রত্যাখ্যান করুন।
• অ্যাপ স্তরে গভীর প্রতিরক্ষা। যাচাই, এনকোডিং, প্যারামিটারাইজেশন ও ফ্রেমওয়ার্ক সুরক্ষা মেলান; একটির ওপর নির্ভর করবেন না।
• পরিচয় ও টোকেনের জন্য ন্যূনতম বিশেষাধিকার। ক্রেডেনশিয়াল সংকীর্ণভাবে সীমিত করুন এবং দ্রুত মেয়াদ শেষ করুন।
• আপনার নির্ভরতাই আপনার কোড। তৃতীয়-পক্ষ ও ওপেন-সোর্স উপাদানসহ আপনি যা পাঠান তার সবকিছুর নিরাপত্তার জন্য আপনি দায়ী।
• উদ্ভাবনের বদলে মান। নিজের নিরাপত্তা নিয়ন্ত্রণ উদ্ভাবনের বদলে OWASP (Open Worldwide Application Security Project) ASVS-এর মতো যাচাইকৃত কাঠামো ব্যবহার করুন।

সুপারিশ

OWASP Top 10 জানুন ও প্রতিরক্ষা করুন, ASVS দিয়ে যাচাই করুন

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

একটি কঠোর, পরীক্ষাযোগ্য মানের জন্য OWASP Application Security Verification Standard (ASVS) গ্রহণ করুন। ASVS তিন স্তরের নিশ্চয়তায় নিরাপত্তা প্রয়োজন সংজ্ঞায়িত করে, আপনাকে নকশা ও পরীক্ষা করার সুনির্দিষ্ট, নিরীক্ষণযোগ্য নিয়ন্ত্রণ দেয়। প্রতিটি অ্যাপ্লিকেশনের ঝুঁকির সঙ্গে মেলে এমন স্তর বাছুন এবং তার বিপরীতে যাচাই করুন।

ইনপুট যাচাই করুন ও আউটপুট এনকোড করুন

ইনজেকশন ত্রুটি সবচেয়ে ক্ষতিকরগুলোর মধ্যে থাকে ঠিক কারণ সেগুলো ঢোকানো এত সহজ। স্তরিত নিয়ন্ত্রণ দিয়ে প্রতিরক্ষা করুন:

• কঠোর অনুমোদন-তালিকার (প্রত্যাশিত ধরন, দৈর্ঘ্য, ফরম্যাট, পরিসর) বিপরীতে ইনপুট যাচাই করুন। যেখানে পারেন স্যানিটাইজ করার বদলে প্রত্যাখ্যান করুন।
• সব ডেটাবেস অ্যাক্সেসের জন্য প্যারামিটারাইজড কোয়েরি ও প্রস্তুত বিবৃতি ব্যবহার করুন; স্ট্রিং সংযোজন করে কখনো SQL গড়বেন না। নিরাপদ কোয়েরি বিল্ডার এবং ORM (অবজেক্ট-রিলেশনাল ম্যাপার) সঠিকভাবে ব্যবহার করুন।
• আউটপুট প্রসঙ্গ অনুযায়ী এনকোড করুন। HTML, HTML অ্যাট্রিবিউট, JavaScript, URL ও CSS প্রত্যেকের ভিন্ন এনকোডিং লাগে। ফ্রেমওয়ার্কের স্বয়ংক্রিয়-এস্কেপিংয়ের ওপর ভর করুন এবং তার সীমা বুঝুন।
• আউটপুট এনকোডিংয়ের সঙ্গে দ্বিতীয় স্তর হিসেবে শক্তিশালী Content Security Policy দিয়ে ক্রস-সাইট স্ক্রিপ্টিং (XSS) প্রতিরোধ করুন।
• অবিশ্বস্ত ডেটা দিয়ে শেল না চালিয়ে এবং যুক্তি-মুক্ত বা স্যান্ডবক্সড টেমপ্লেট ব্যবহার করে কমান্ড ও টেমপ্লেট ইনজেকশন প্রতিরোধ করুন।

প্রমাণীকরণ ও অনুমোদন সঠিক করুন

প্রমাণীকরণ প্রমাণ করে একজন ব্যবহারকারী কে। অনুমোদন ঠিক করে তিনি কী করতে পারেন। দুটিই প্রায়ই ব্যর্থ হয়, তাই সঠিক করুন।

• প্রতিষ্ঠিত প্রোটোকল পছন্দ করুন: ডেলিগেটেড অনুমোদনের জন্য OAuth 2.0 এবং প্রমাণীকরণের জন্য OpenID Connect (OIDC)। এগুলো স্ক্র্যাচ থেকে গড়বেন না।
• বিশেষত বিশেষাধিকারপ্রাপ্ত ও প্রশাসনিক অ্যাক্সেসের জন্য বহু-ফ্যাক্টর প্রমাণীকরণ (MFA) প্রয়োগ করুন।
• পাসওয়ার্ড কেবল আধুনিক, ধীর, মেমরি-কঠিন অ্যালগরিদম (Argon2 বা bcrypt-এর মতো) ব্যবহার করে সল্টেড হ্যাশ হিসেবে সংরক্ষণ করুন। প্লেইনটেক্সট ক্রেডেনশিয়াল কখনো সংরক্ষণ বা লগ করবেন না।
• সেশন সাবধানে সামলান: ক্রিপ্টোগ্রাফিকভাবে শক্তিশালী টোকেন তৈরি করুন, secure ও HttpOnly কুকি ফ্ল্যাগ ঠিক করুন, বিশেষাধিকার পরিবর্তনে ঘোরান, এবং অলস সেশনের মেয়াদ শেষ করুন।
• প্রতিটি অনুরোধের জন্য সার্ভারে অনুমোদন প্রয়োগ করুন, প্রমাণীকৃত প্রধান নির্দিষ্ট সম্পদের মালিক বা সেটিতে অ্যাক্সেসযোগ্য কি না পরীক্ষা করে। ভাঙা অবজেক্ট-স্তরের অনুমোদন (একটি ID বদলে অন্য ব্যবহারকারীর রেকর্ড অ্যাক্সেস) সবচেয়ে সাধারণ ও গুরুতর API ত্রুটির একটি।
• যেখানে ব্যবহারিক সেখানে অনুমোদন যুক্তি কেন্দ্রীভূত করুন যাতে নীতি সামঞ্জস্যপূর্ণ ও নিরীক্ষণযোগ্য হয়।

গোপন তথ্য পরিচালনা করুন ও কী ঘোরান

সোর্স কোডে হার্ডকোড করা গোপন তথ্য ভাঙনের চিরস্থায়ী কারণ। গোপন তথ্য ব্যবস্থাপনা ঘিরে শৃঙ্খলাবদ্ধ অভ্যাস গড়ুন:

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

সফটওয়্যার সরবরাহ শৃঙ্খল সুরক্ষিত করুন

আধুনিক অ্যাপ্লিকেশন বেশিরভাগ তৃতীয়-পক্ষ উপাদান থেকে জোড়া লাগানো, যা সরবরাহ শৃঙ্খলকে প্রাথমিক আক্রমণ-পৃষ্ঠ করে।

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

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

সিদ্ধান্ত	সুবিধা	অসুবিধা
পরিচয় প্রদানকারী (OIDC) কিনুন/গ্রহণ করুন	যুদ্ধ-পরীক্ষিত, ইনবিল্ট MFA, সুরক্ষিত করার কম কোড	বিক্রেতা নির্ভরতা, ইন্টিগ্রেশন পরিশ্রম, খরচ
কাস্টম auth গড়ুন	পূর্ণ নিয়ন্ত্রণ, বাইরের নির্ভরতা নেই	ভুল করা অত্যন্ত সহজ, উচ্চ রক্ষণাবেক্ষণ
কঠোর অনুমোদন-তালিকা যাচাই	পুরো দুর্বলতা শ্রেণি আটকায়	বৈধ প্রান্তিক কেস ভাঙতে পারে, বেশি অগ্রিম কাজ
স্বল্পস্থায়ী ক্রেডেনশিয়াল	ছোট ভাঙন জানালা, স্বয়ংক্রিয় প্রত্যাহার	শক্তিশালী ইস্যু অবকাঠামো লাগে
আক্রমণাত্মক নির্ভরতা হালনাগাদ	কম জানা দুর্বলতা	আলোড়ন, সম্ভাব্য ভাঙনকারী পরিবর্তন, টেস্ট বোঝা
SBOM + স্বাক্ষর + উৎস-প্রমাণ	দ্রুত ঘটনা সাড়া, যাচাইযোগ্য আস্থা	টুলিং ও প্রক্রিয়া বিনিয়োগ, সংস্কৃতি পরিবর্তন

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

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

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

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

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

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

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

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

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

স্টার্টআপ। দুই বা তিনজন ইঞ্জিনিয়ার ও কোনো নিরাপত্তা বিশেষজ্ঞ ছাড়া আপনার লিভারেজ হলো নিরাপত্তা গড়ার বদলে উত্তরাধিকার পাওয়া: একটি ম্যানেজড OIDC পরিচয় প্রদানকারী গ্রহণ করুন, এমন ফ্রেমওয়ার্কের ওপর ভর করুন যার ORM ডিফল্টে কোয়েরি প্যারামিটারাইজ করে, এবং গোপন তথ্য আপনার প্ল্যাটফর্মের সিক্রেট ম্যানেজারে রাখুন, একজন সতীর্থ দুর্ঘটনাবশত কমিট করতে পারে এমন .env ফাইলে নয়। প্যাচ পুল রিকোয়েস্ট খোলা স্বয়ংক্রিয় নির্ভরতা স্ক্যানিং চালু করুন, এবং আপাতত তা যথেষ্ট গণ্য করুন। কাস্টম auth বা ক্রিপ্টো গড়বেন না, কারণ একটি ইনজেক্ট করা কোয়েরি বা একটি ফাঁস হওয়া কী কোম্পানির গ্রাহক পাওয়ার আগেই তা শেষ করতে পারে।

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

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

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

উদাহরণ

স্টার্টআপ। তিনজন ইঞ্জিনিয়ারের একটি SaaS দল নিজস্ব লগইন গড়া এড়িয়ে প্রথম দিন থেকে একটি ম্যানেজড OIDC প্রদানকারী গ্রহণ করে, ভুল করার সামর্থ্য নেই এমন নিরাপত্তা-জটিল কোড না লিখে MFA ও নিরাপদ পাসওয়ার্ড রিসেট পায়। তারা ফ্রেমওয়ার্কের ORM-এর ওপর ভর করে যাতে কোয়েরি ডিফল্টে প্যারামিটারাইজড, গোপন তথ্য একজন সতীর্থ দুর্ঘটনাবশত কমিট করতে পারে এমন .env ফাইলের বদলে প্ল্যাটফর্মের সিক্রেট ম্যানেজারে রাখে, এবং একটি লাইব্রেরি প্যাচ করতে হলে পুল রিকোয়েস্ট খোলা স্বয়ংক্রিয় নির্ভরতা স্ক্যানিং চালু করে। এর কিছুই দলকে ধীর করে না, এবং এর মানে একটি ফাঁস হওয়া কী বা একটি ইনজেক্ট করা কোয়েরি কোম্পানির গ্রাহক পাওয়ার আগেই তা শেষ করে না।

এন্টারপ্রাইজ। কোটি কোটি ক্রেতাকে সেবা দেওয়া একটি খুচরা প্ল্যাটফর্ম একটি একক পরিচয় প্রদানকারীর মাধ্যমে OIDC-তে প্রমাণীকরণ প্রমিত করে, কর্মীদের জন্য MFA এবং উচ্চ-মূল্যের অ্যাকাউন্ট পরিবর্তনের জন্য স্টেপ-আপ প্রমাণীকরণ প্রয়োগ করে। সব ডেটাবেস অ্যাক্সেস একটি ORM-এর মাধ্যমে যায় যা কোয়েরি প্যারামিটারাইজ করতে কনফিগার করা, এবং একটি Content Security Policy আউটপুট এনকোডিংয়ের ব্যাকআপ দেয়। একটি জনপ্রিয় লগিং লাইব্রেরিতে ব্যাপকভাবে প্রচারিত দুর্বলতার পর কোম্পানির SBOM তাকে ঘণ্টার মধ্যে প্রভাবিত প্রতিটি সার্ভিস শনাক্ত করতে এবং দুই দিনে প্যাচ করতে দেয়, যখন তালিকাবিহীন প্রতিযোগীরা সপ্তাহ খুঁজে কাটায়।

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

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

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

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

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

• নিজের ক্রিপ্টো বা auth ঘুরিয়ে বানানো। প্রায় সবসময় সূক্ষ্ম, শোষণযোগ্য ত্রুটি তৈরি করে।
• কেবল ক্লায়েন্ট-সাইড যাচাই। তুচ্ছভাবে এড়ানো যায়; সার্ভারকে সবকিছু পুনরায় যাচাই করতে হবে।
• ব্লকলিস্ট স্যানিটাইজেশন। ভালো অক্ষর অনুমোদন-তালিকাভুক্ত করার বদলে “খারাপ” অক্ষর ছাঁটার চেষ্টা; আক্রমণকারীরা ফাঁক খুঁজে পায়।
• সোর্স বা পরিবেশ ফাইলে গোপন তথ্য। ক্রেডেনশিয়াল ফাঁসের একক সবচেয়ে সাধারণ কারণ।
• অবজেক্ট অ্যাক্সেসে অনুমোদন উপেক্ষা। ধরে নেওয়া একজন প্রমাণীকৃত ব্যবহারকারী যে অবজেক্টের ID অনুমান করতে পারে তার যেকোনোটিতে অ্যাক্সেস করতে পারে।
• সেট-করে-ভুলে-যাও নির্ভরতা। ভাঙন বাধ্য না করা পর্যন্ত তৃতীয়-পক্ষ উপাদান কখনো হালনাগাদ না করা।
• Top 10-কে শেষ রেখা গণ্য করা। এটি একটি মেঝে, ব্যাপক মান নয়; গভীরতার জন্য ASVS ব্যবহার করুন।
• সংবেদনশীল ডেটা লগ করা। লগে পাসওয়ার্ড, টোকেন ও PII (ব্যক্তিগতভাবে শনাক্তযোগ্য তথ্য) ঘটার অপেক্ষায় থাকা ভাঙন।

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

স্তর ১: সূচনা। অ্যাপ্লিকেশন নিরাপত্তা পৃথক ডেভেলপারের জ্ঞানের ওপর নির্ভর করে এবং কেবল ঘটনার পরে সাড়া দেয়। কোনো প্রমিত নিয়ন্ত্রণ নেই। গোপন তথ্য সোর্সে বসে। নির্ভরতা কদাচিৎ হালনাগাদ হয়। প্রমাণীকরণ কাস্টম ও অ্যাড হক, এবং ইনজেকশন বা ভাঙা-অ্যাক্সেস-নিয়ন্ত্রণ ত্রুটি প্রক্রিয়ার বদলে ভাগ্যে পাওয়া যায়।

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

স্তর ৩: মানসম্মতকরণ। নিয়ন্ত্রণ নথিবদ্ধ এবং প্রতিষ্ঠান জুড়ে প্রয়োগ করা। ASVS-ভিত্তিক প্রয়োজন ঝুঁকি স্তর অনুযায়ী ঠিক করা, প্যারামিটারাইজড কোয়েরি ও আউটপুট এনকোডিং নিয়ম, এবং MFA সহ একটি কেন্দ্রীয় পরিচয় প্রদানকারী বাধ্যতামূলক। গোপন তথ্য পরিচালিত ও স্বয়ংক্রিয়ভাবে স্ক্যান করা, SBOM তৈরি হয়, এবং প্রতিটি পাইপলাইনে নির্ভরতা স্ক্যানিং চলে।

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

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

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

1. অনেক সার্ভিস জুড়ে সামঞ্জস্যপূর্ণ ও রক্ষণযোগ্য উভয় হতে অনুমোদন যুক্তি কোথায় বাস করা উচিত?
2. এক্সপোজার ও আলোড়নের বিনিময় বিবেচনায় আপনার নির্ভরতা কত আক্রমণাত্মকভাবে হালনাগাদ করা উচিত?
3. আপনার পোর্টফোলিওর প্রতিটি শ্রেণির অ্যাপ্লিকেশনের জন্য কোন ASVS স্তর উপযুক্ত?
4. ভঙ্গুর ইস্যু অবকাঠামো না বানিয়ে আপনি কীভাবে দীর্ঘস্থায়ী গোপন তথ্য দূর করবেন?
5. প্রতিটি আর্টিফ্যাক্টের জন্য SBOM ও উৎস-প্রমাণ তৈরি ও ভোগ করতে আপনার প্রতিষ্ঠানের কী লাগবে?
6. সরবরাহের চাপে নিরাপদ ডিফল্ট বন্ধ হওয়া আপনি কীভাবে ঠেকান?

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

• OWASP Top 10 অপরিহার্য জ্ঞান; ASVS পরীক্ষাযোগ্য মান দেয়।
• ইনজেকশন ও XSS পরাজিত করতে ইনপুট যাচাই, প্যারামিটারাইজেশন ও আউটপুট এনকোডিং স্তরে স্তরে রাখুন।
• যাচাইকৃত প্রোটোকল (OAuth 2.0, OIDC) ব্যবহার করুন এবং MFA প্রয়োগ করুন; auth কখনো স্ক্র্যাচ থেকে গড়বেন না।
• প্রতিটি অনুরোধ ও প্রতিটি অবজেক্টের জন্য সার্ভারে অনুমোদন প্রয়োগ করুন।
• গোপন তথ্য সোর্সের বাইরে রাখুন, কেন্দ্রীয়ভাবে পরিচালনা করুন, এবং স্বল্পস্থায়ী ক্রেডেনশিয়ালে ঘোরান।
• সরবরাহ শৃঙ্খল একটি প্রাথমিক আক্রমণ-পৃষ্ঠ; SBOM, SCA, স্বাক্ষর ও উৎস-প্রমাণ (SLSA) ব্যবহার করুন।
• স্বয়ংক্রিয়, পুনর্ব্যবহারযোগ্য নিয়ন্ত্রণ প্রতি সার্ভিসের প্রান্তিক খরচে পুরো বহর রক্ষা করে।

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

• OWASP, Top 10 Web Application Security Risks
• OWASP, Application Security Verification Standard (ASVS)
• OWASP, Cheat Sheet Series (ইনপুট যাচাই, প্রমাণীকরণ, অনুমোদন, গোপন তথ্য ব্যবস্থাপনা)
• Dafydd Stuttard ও Marcus Pinto, The Web Application Hacker’s Handbook
• Aaron Parecki, OAuth 2.0 Simplified
• National Institute of Standards and Technology, SP 800-63: Digital Identity Guidelines
• Cloud Native Computing Foundation ও OpenSSF, SLSA framework এবং Supply-chain Security guidance