দীর্ঘমেয়াদী Android নিরাপত্তার জন্য প্রস্তুতকারকের নির্দেশিকা

এই নির্দেশিকাটি অ্যান্ড্রয়েড কম্প্যাটিবিলিটি টেস্ট স্যুট (CTS) দ্বারা মূল্যায়িত নিরাপত্তা প্যাচ প্রয়োগের জন্য গুগলের প্রস্তাবিত সর্বোত্তম পদ্ধতি বর্ণনা করে। এটি অ্যান্ড্রয়েড-সামঞ্জস্যপূর্ণ OEM সরঞ্জাম প্রস্তুতকারকদের জন্য তৈরি, যেগুলো তিন বছরের বেশি সময় ধরে সমর্থিত হবে, যেমন যানবাহন, টিভি, সেট-টপ বক্স এবং গৃহস্থালী সরঞ্জাম। এই নির্দেশিকাটি সাধারণ ব্যবহারকারীদের (উদাহরণস্বরূপ, গাড়ির মালিক) জন্য নয়

স্বীকৃতি এবং দাবিত্যাগ

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

প্রতিক্রিয়া

এই নির্দেশিকাটি সম্পূর্ণ নয়; এতে আরও সংশোধনের পরিকল্পনা রয়েছে। আপনার মতামত manufacturers-guide-android@googlegroups.com-এ জমা দিন।

শব্দকোষ

মেয়াদ সংজ্ঞা
এসিসি অ্যান্ড্রয়েড সামঞ্জস্যতা প্রতিশ্রুতি। পূর্বে অ্যান্ড্রয়েড অ্যান্টি-ফ্র্যাগমেন্টেশন চুক্তি (AFA) নামে পরিচিত ছিল।
এওএসপি অ্যান্ড্রয়েড ওপেন সোর্স প্রকল্প
এএসবি অ্যান্ড্রয়েড নিরাপত্তা বুলেটিন
বিএসপি বোর্ড সাপোর্ট প্যাকেজ
সিডিডি সামঞ্জস্য সংজ্ঞা নথি
সিটিএস সামঞ্জস্য পরীক্ষা স্যুট
ফোটা ওভার দ্য এয়ার ফার্মওয়্যার
জিপিএস গ্লোবাল পজিশনিং সিস্টেম
মিশ্র মোটর শিল্প সফটওয়্যার নির্ভরযোগ্যতা সমিতি
NIST জাতীয় মান ও প্রযুক্তি ইনস্টিটিউট
ওবিডি অন-বোর্ড ডায়াগনস্টিকস ( OBD-II কার্যক্ষমতা এবং মানকীকরণ উভয় ক্ষেত্রেই OBD-I এর একটি উন্নত সংস্করণ )
OEM মূল সরঞ্জাম প্রস্তুতকারক
ওএস অপারেটিং সিস্টেম
SEI সফটওয়্যার ইঞ্জিনিয়ারিং ইনস্টিটিউট
SoC সিস্টেম অন চিপ
এসওপি উৎপাদনের শুরু
এসপিএল নিরাপত্তা প্যাচ স্তর
TPMS টায়ার-চাপ পর্যবেক্ষণ ব্যবস্থা

অ্যান্ড্রয়েড ওএস সম্পর্কে

অ্যান্ড্রয়েড হলো একটি ওপেন সোর্স, লিনাক্স-ভিত্তিক পূর্ণাঙ্গ সফটওয়্যার স্ট্যাক, যা বিভিন্ন ধরনের ডিভাইস এবং ফর্ম ফ্যাক্টরের জন্য ডিজাইন করা হয়েছে। ২০০৮ সালে প্রথম প্রকাশের পর থেকে, অ্যান্ড্রয়েড সবচেয়ে জনপ্রিয় অপারেটিং সিস্টেম (OS) হয়ে উঠেছে, যা বিশ্বব্যাপী ১.৪ বিলিয়নেরও বেশি ডিভাইসে ব্যবহৃত হয় (২০১৬)। মার্চ ২০১৭ পর্যন্ত, এই ডিভাইসগুলোর প্রায় ৬৭% অ্যান্ড্রয়েড ৫.০ (ললিপপ) বা তার পরবর্তী সংস্করণ ব্যবহার করে (আরও সাম্প্রতিক পরিসংখ্যান অ্যান্ড্রয়েড ড্যাশবোর্ডে পাওয়া যাবে)। যদিও অধিকাংশ ডিভাইসই মোবাইল ফোন এবং ট্যাবলেট, স্মার্টওয়াচ, টিভি এবং গাড়ির ইন-ভেহিকেল ইনফোটেইনমেন্ট (IVI) ডিভাইসেও অ্যান্ড্রয়েডের ব্যবহার বাড়ছে।

গুগল প্লে স্টোরে উপলব্ধ অ্যান্ড্রয়েড অ্যাপের সংখ্যা ২২ লক্ষ ছাড়িয়ে গেছে (২০১৬)। অ্যান্ড্রয়েড অ্যাপ ডেভেলপমেন্ট অ্যান্ড্রয়েড কম্প্যাটিবিলিটি প্রোগ্রাম দ্বারা সমর্থিত, যা কম্প্যাটিবিলিটি ডেফিনিশন ডকুমেন্ট (CDD)- এর মাধ্যমে কিছু প্রয়োজনীয়তা নির্ধারণ করে এবং কম্প্যাটিবিলিটি টেস্ট স্যুট (CTS)- এর মাধ্যমে টেস্টিং টুল সরবরাহ করে। অ্যান্ড্রয়েড কম্প্যাটিবিলিটি প্রোগ্রাম নিশ্চিত করে যে, যেকোনো অ্যান্ড্রয়েড অ্যাপ এমন যেকোনো অ্যান্ড্রয়েড-কম্প্যাটিবল ডিভাইসে চলতে পারবে, যে ডিভাইসটিতে অ্যাপটির জন্য প্রয়োজনীয় ফিচারগুলো রয়েছে।

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

সংযুক্ত যানবাহন সম্পর্কে (প্রামাণিক দীর্ঘস্থায়ী পণ্য)

১৯২০-এর দশকে এএম রেডিও চালু হওয়ার সাথে সাথে যানবাহনগুলো সংযুক্ত হতে শুরু করে। এরপর থেকে, নিয়ন্ত্রক সংস্থা এবং গাড়ি নির্মাতারা ডায়াগনস্টিকস ও সার্ভিসিং সহজ করতে (যেমন, OBD-II পোর্ট), নিরাপত্তা বাড়াতে (যেমন, TPMS) এবং জ্বালানি সাশ্রয়ের লক্ষ্যমাত্রা পূরণের জন্য ইলেকট্রনিক্সের দিকে ঝুঁকে পড়ায় বাহ্যিক ভৌত এবং বেতার সংযোগের সংখ্যা বাড়তে শুরু করে। সংযোগের পরবর্তী ধাপে চালকের সুবিধার জন্য রিমোট কীলেস এন্ট্রি, টেলিম্যাটিক্স সিস্টেম এবং ব্লুটুথ, ওয়াই-ফাই ও স্মার্টফোন প্রজেকশনের মতো উন্নত ইনফোটেইনমেন্ট ফিচার চালু হয়। বর্তমানে, সমন্বিত সেন্সর এবং সংযোগ ব্যবস্থা (যেমন, GPS) নিরাপত্তা এবং আধা-স্বয়ংক্রিয় ড্রাইভিং সিস্টেমকে সহায়তা করে।

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

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

দীর্ঘমেয়াদী নিরাপত্তা নিশ্চিত করুন

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

  • কমন ভালনারেবিলিটিজ অ্যান্ড এক্সপোজারস (CVE) ডাটাবেসের সাথে নিয়মিতভাবে পণ্যটির মূল্যায়ন করা।
  • পণ্য-সম্পর্কিত নিরাপত্তা ত্রুটি বিষয়ে তথ্য সংগ্রহ।
  • নিরাপত্তা পরীক্ষা।
  • সক্রিয়ভাবে অ্যান্ড্রয়েড নিরাপত্তা বুলেটিনগুলো বিশ্লেষণ করা হচ্ছে।

উদাহরণস্বরূপ ওএস এবং নিরাপত্তা প্যাচ আপডেট (অ্যান্ড্রয়েড চালিত আইভিআই-এর ক্ষেত্রে):

চিত্র ১. গাড়ির জীবনকাল জুড়ে প্রধান ওএস এবং নিরাপত্তা আপডেট প্রদানের একটি নমুনা।

# ধাপ কার্যকলাপ

উন্নয়ন শাখা প্রস্তুতকারক অ্যান্ড্রয়েডের একটি সংস্করণ (অ্যান্ড্রয়েড এক্স) নির্বাচন করে। এই উদাহরণে, প্রাথমিক উৎপাদন শুরুর (এসওপি) দুই বছর আগে থেকেই গাড়িতে যা কিছু সরবরাহ করা হবে, তার ভিত্তি হয়ে ওঠে "অ্যান্ড্রয়েড এক্স"।
প্রাথমিক লঞ্চ পণ্যে প্রথম ওএস সংস্করণ হিসেবে অ্যান্ড্রয়েড এক্স আসার কয়েক মাস আগে, অ্যান্ড্রয়েড সিকিউরিটি বুলেটিন (ASB) এবং প্রস্তুতকারকের কাছে মূল্যবান বলে বিবেচিত অন্যান্য উৎস থেকে নিরাপত্তা আপডেট সংগ্রহ করা হয়। y2 হলো অ্যান্ড্রয়েডের সংস্করণ X-এর জন্য দ্বিতীয় সিকিউরিটি বুলেটিন, যা প্রস্তুতকারক অ্যান্ড্রয়েড এক্স-এ প্রয়োগ (ব্যাকপোর্ট) করে। এই আপডেটটি পণ্যের সাথে অন্তর্ভুক্ত করা হয় এবং অ্যান্ড্রয়েড এক্স.y2-এর মাধ্যমে শূন্য বছর থেকে উৎপাদনের সময় গণনা শুরু হয়।

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

সম্পূর্ণ ওএস আপডেট এসওপি-পরবর্তী সময়ে, প্রস্তুতকারক অ্যান্ড্রয়েড X+2 ওএস আপডেট প্রকাশ করে, যা প্রাথমিক পণ্যে ব্যবহৃত সংস্করণ (অ্যান্ড্রয়েড X0) থেকে দুটি অ্যান্ড্রয়েড রিলিজ পরের সংস্করণ। এপিআই লেভেলের (শিপমেন্টের তারিখ অনুযায়ী) জন্য এএসবি নিরাপত্তা আপডেটগুলো উপলব্ধ থাকে, তাই আপডেটটি এসওপি-এর প্রায় ১.২৫ বছর পর X+2.y0 হিসেবে প্রকাশিত হয়। এই ওএস আপডেটটি ফিল্ডে থাকা পণ্যগুলোর সাথে সামঞ্জস্যপূর্ণ হতেও পারে বা নাও হতে পারে। যদি এটি সামঞ্জস্যপূর্ণ হয়, তবে মোতায়েন করা যানবাহনগুলো আপডেট করার জন্য একটি পরিকল্পনা তৈরি করা যেতে পারে।

অন্য কোনো ব্যবসায়িক চুক্তি না থাকলে, সম্পূর্ণ ওএস আপডেট করার সিদ্ধান্ত পুরোপুরি প্রস্তুতকারকের বিবেচনার উপর নির্ভর করে।

নিরাপত্তা আপডেট গাড়িটির উৎপাদনকালের দুই বছর পর, প্রস্তুতকারক অ্যান্ড্রয়েড X+2 ওএস-এ প্যাচ প্রয়োগ করে। এই সিদ্ধান্তটি প্রস্তুতকারকের ঝুঁকি মূল্যায়নের উপর ভিত্তি করে নেওয়া হয়। প্রস্তুতকারক এই আপডেটের ভিত্তি হিসেবে X+2 রিলিজের জন্য তৃতীয় ASB নিরাপত্তা আপডেটটি বেছে নেয়। যে পণ্যগুলো এই নিরাপত্তা আপডেট পেয়েছে, সেগুলো এখন (X+2.y3) ওএস + অ্যান্ড্রয়েড নিরাপত্তা প্যাচ লেভেলে রয়েছে।

যদিও নির্মাতারা যেকোনো স্বতন্ত্র ASB থেকে পৃথক নিরাপত্তা প্যাচ নির্বাচন করতে পারেন, তবে বুলেটিনটির সাথে যুক্ত অ্যান্ড্রয়েড নিরাপত্তা প্যাচ লেভেল (SPL) (উদাহরণস্বরূপ, 2017-02-05) ব্যবহার করার জন্য তাদের অবশ্যই বুলেটিনটিতে থাকা সমস্ত প্রয়োজনীয় সমস্যা সমাধান করতে হবে। সমর্থিত পণ্যটির জন্য ব্যাকপোর্ট এবং নিরাপত্তা রিলিজ সম্পাদন করা নির্মাতার দায়িত্ব।

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

এই উদাহরণে, হার্ডওয়্যারের সীমাবদ্ধতার কারণে, X+4 হলো অ্যান্ড্রয়েডের সর্বশেষ প্রধান সংস্করণ যা এই পণ্যটির জন্য সরবরাহ করা হবে, যদিও গাড়িটির ৬ বছরেরও বেশি প্রত্যাশিত আয়ুষ্কালের জন্য এখনও নিরাপত্তা সহায়তার প্রয়োজন রয়েছে।

নিরাপত্তা আপডেট ধাপ ৪ (নিরাপত্তা আপডেট)-এর পুনরাবৃত্তি। প্রস্তুতকারকের দায়িত্ব হলো অ্যান্ড্রয়েডের অনেক পরবর্তী সংস্করণ (X+6) থেকে ASB নিরাপত্তা আপডেটগুলো নিয়ে সেগুলোর কিছু বা সমস্ত আপডেট অ্যান্ড্রয়েড X+4-এ পোর্ট করা। আপডেটগুলোকে একত্রিত করা, সমন্বিত করা এবং সম্পাদন করা (অথবা কোনো তৃতীয় পক্ষের সাথে চুক্তি করা) প্রস্তুতকারকের দায়িত্ব। এছাড়াও, প্রস্তুতকারকের সচেতন থাকা উচিত যে অ্যান্ড্রয়েডের যে সংস্করণগুলো এখন আর সমর্থিত নয়, সেগুলোর নিরাপত্তা সংক্রান্ত সমস্যাগুলো ASB-এর আওতায় পড়ে না।
নিরাপত্তা আপডেট গাড়িটির উৎপাদন চক্রের আট বছর, ধাপ ৫ (সম্পূর্ণ ওএস আপডেট)-এর সর্বশেষ ওএস আপডেটের পর চারটি অ্যান্ড্রয়েড রিলিজ এবং অ্যান্ড্রয়েড এক্স নির্দিষ্ট করার পর দশ বছর অতিবাহিত হওয়ায়, এপিআই লেভেলের পাবলিক রিলিজের পর থেকে তিন বছরের বেশি পুরোনো সংস্করণগুলোর জন্য নিরাপত্তা প্যাচ সংকলন ও ব্যাকপোর্ট করার সম্পূর্ণ দায়িত্ব প্রস্তুতকারকের ওপর বর্তায়।

নিরাপত্তার সর্বোত্তম অনুশীলন

নিরাপত্তা লঙ্ঘন আরও কঠিন করার জন্য, গুগল ‘ইমপ্লিমেন্টিং সিকিউরিটি’তে বর্ণিত নিরাপত্তা ও সফটওয়্যার ইঞ্জিনিয়ারিংয়ের জন্য সাধারণভাবে স্বীকৃত সর্বোত্তম অনুশীলনগুলো ব্যবহারের সুপারিশ করে এবং প্রয়োগ করে।

নিরাপত্তা নির্দেশিকা

নিরাপত্তার জন্য প্রস্তাবিত অনুশীলনগুলোর মধ্যে রয়েছে:

  • বাহ্যিক লাইব্রেরি এবং ওপেন সোর্স উপাদানগুলোর সর্বশেষ সংস্করণ ব্যবহার করুন।
  • অপারেটিং সিস্টেমের রিলিজ সংস্করণগুলিতে অনাকাঙ্ক্ষিত ডিবাগ কার্যকারিতা অন্তর্ভুক্ত করবেন না।
  • অপ্রয়োজনীয় কার্যকারিতা অপসারণ করুন (অপ্রয়োজনীয় আক্রমণের ক্ষেত্র কমাতে)।
  • সর্বনিম্ন বিশেষাধিকার নীতি এবং অ্যান্ড্রয়েড অ্যাপ ডেভেলপমেন্টের অন্যান্য সর্বোত্তম অনুশীলন ব্যবহার করুন।

সফটওয়্যার উন্নয়ন নির্দেশিকা

সিস্টেমের জীবনচক্রের জন্য নিরাপদ সফটওয়্যার উন্নয়নের সুপারিশকৃত অনুশীলনগুলোর মধ্যে রয়েছে:

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

নিরাপত্তা ব্যাকপোর্ট নীতি

গুগল বর্তমানে API লেভেল পাবলিক রিলিজের তারিখ থেকে তিন (3) বছরের জন্য আবিষ্কৃত এবং রিপোর্ট করা নিরাপত্তা দুর্বলতার নিরাপত্তা ব্যাকপোর্টের জন্য সক্রিয় সমর্থন প্রদান করে। সক্রিয় সমর্থনের মধ্যে নিম্নলিখিতগুলি অন্তর্ভুক্ত রয়েছে:

  1. দুর্বলতা সংক্রান্ত প্রতিবেদন গ্রহণ ও তদন্ত করুন।
  2. নিরাপত্তা আপডেট তৈরি, পরীক্ষা এবং প্রকাশ করুন।
  3. নিয়মিত নিরাপত্তা আপডেট এবং নিরাপত্তা বুলেটিনের বিস্তারিত তথ্য সরবরাহ করুন।
  4. প্রতিষ্ঠিত নির্দেশিকা অনুযায়ী তীব্রতা মূল্যায়ন করুন।

এপিআই লেভেল সর্বজনীনভাবে প্রকাশের তারিখের তিন বছর পর, গুগল নিম্নলিখিত নির্দেশিকাগুলো অনুসরণের পরামর্শ দেয়:

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

অতিরিক্ত তথ্যসূত্র

নিরাপদ কোডিং এবং সফটওয়্যার উন্নয়ন পদ্ধতি সংক্রান্ত নির্দেশাবলীর জন্য নিম্নলিখিত বিষয়গুলো দেখুন:

গুগল নিম্নলিখিত প্রস্তাবিত পদ্ধতিগুলো ব্যবহারে উৎসাহিত করে।

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

প্রস্তাবিত নির্দেশিকাগুলো হলো:

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

দ্রষ্টব্য: গুগল অ্যান্ড্রয়েড সিকিউরিটি বুলেটিনে ডিভাইসের ধরন বা শিল্প-নির্দিষ্ট বিজ্ঞপ্তি দেওয়ার বিষয়টি বিবেচনা করেছে। তবে, যেহেতু গুগল কোনো নির্দিষ্ট ডিভাইসের (গাড়ি, টিভি, পরিধানযোগ্য ডিভাইস, ফোন, ইত্যাদি) কার্নেল, ড্রাইভার বা চিপসেট সম্পর্কে জানে না, তাই কোনো নির্দিষ্ট নিরাপত্তা সমস্যাকে ডিভাইসের ধরন দিয়ে চিহ্নিত করার কোনো সুনির্দিষ্ট উপায় গুগলের কাছে নেই।

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

  • ড্রাইভার, কার্নেল এবং প্রোটোকল আপডেটগুলো বাস্তবায়নের জন্য একটি পরিকল্পনা তৈরি করুন।
  • মোতায়েনকৃত যানবাহনগুলিতে হালনাগাদ তথ্য প্রদানের জন্য শিল্প-উপযোগী একটি পদ্ধতি ব্যবহার করুন।

সামঞ্জস্য সংজ্ঞা নথি (CDD)

কম্প্যাটিবিলিটি ডেফিনিশন ডকুমেন্ট (CDD)-এ একটি ডিভাইসকে অ্যান্ড্রয়েড-কম্প্যাটিবল হিসেবে গণ্য করার জন্য প্রয়োজনীয় শর্তাবলী বর্ণনা করা থাকে। CDD সর্বজনীন এবং সকলের জন্য উপলব্ধ; আপনি source.android.com থেকে অ্যান্ড্রয়েড ১.৬ থেকে শুরু করে সর্বশেষ সংস্করণ পর্যন্ত CDD ডাউনলোড করতে পারেন।

একটি পণ্যের জন্য এই প্রয়োজনীয়তাগুলো পূরণ করতে নিম্নলিখিত মৌলিক পদক্ষেপগুলো অনুসরণ করতে হয়:

  1. অংশীদার গুগলের সাথে অ্যান্ড্রয়েড সামঞ্জস্যতা প্রতিশ্রুতি (ACC) চুক্তিতে স্বাক্ষর করে। এরপর একজন প্রযুক্তিগত সমাধান পরামর্শদাতাকে (TSC) পথপ্রদর্শক হিসেবে নিযুক্ত করা হয়।
  2. পার্টনার পণ্যটির অ্যান্ড্রয়েড ওএস সংস্করণের জন্য সিডিডি পর্যালোচনা সম্পন্ন করে।
  3. পার্টনার নিম্নে বর্ণিত CTS প্রক্রিয়াটি পরিচালনা করে এবং ফলাফল জমা দেয়, যতক্ষণ না পর্যন্ত তা অ্যান্ড্রয়েড সামঞ্জস্যের জন্য গ্রহণযোগ্য হয়।

সামঞ্জস্য পরীক্ষা স্যুট (CTS)

কম্প্যাটিবিলিটি টেস্ট স্যুট (CTS) টেস্টিং টুলটি যাচাই করে যে, কোনো প্রোডাক্ট ইমপ্লিমেন্টেশন অ্যান্ড্রয়েড-কম্প্যাটিবল কিনা এবং এতে সর্বশেষ সিকিউরিটি প্যাচগুলো অন্তর্ভুক্ত আছে কিনা। CTS পাবলিক, ওপেন সোর্স এবং সকলের জন্য উপলব্ধ; আপনি source.android.com থেকে অ্যান্ড্রয়েড ১.৬ থেকে শুরু করে সর্বশেষ সংস্করণ পর্যন্ত CTS ডাউনলোড করতে পারেন।

সর্বসাধারণের জন্য প্রকাশিত অ্যান্ড্রয়েড সফটওয়্যারের প্রতিটি বিল্ড (ফ্যাক্টরি-ইনস্টল এবং ফিল্ড-আপডেট ইমেজ) অবশ্যই CTS ফলাফলের মাধ্যমে অ্যান্ড্রয়েড সামঞ্জস্যতা প্রমাণ করবে। উদাহরণস্বরূপ, যদি ডিভাইসটি অ্যান্ড্রয়েড ৭.১-এ চলে, তবে একটি রিলিজ-ইন্টেন্ট বিল্ড ইমেজ তৈরি ও পরীক্ষা করার সময় CDD ৭.১ এবং CTS ৭.১-এর সর্বশেষ সংশ্লিষ্ট সংস্করণকে রেফারেন্স হিসেবে ব্যবহার করতে হবে। নির্মাতাদের সমস্যা শনাক্ত ও সমাধান করার জন্য শুরুতেই এবং ঘন ঘন CTS ব্যবহার করতে জোরালোভাবে উৎসাহিত করা হয়।

দ্রষ্টব্য: যেসব অংশীদার গুগল মোবাইল সার্ভিসেস (জিএমএস) -এর মতো অন্যান্য চুক্তি স্বাক্ষর করেন, তাদের অন্যান্য শর্ত পূরণ করতে হতে পারে।

CTS ওয়ার্কফ্লো

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

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

CTS পাস করুন

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

  1. প্রস্তুতকারক গুগলকে প্রস্তাবিত CTS প্যাচ, প্যাচের বৈধতা যাচাই এবং যুক্তি প্রমাণের জন্য তথ্যসূত্র প্রদান করে।
  2. গুগল জমা দেওয়া তথ্য যাচাই করে এবং তা গৃহীত হলে, প্রাসঙ্গিক CTS পরীক্ষাগুলো আপডেট করে, যাতে ডিভাইসটি CTS-এর পরবর্তী সংস্করণে উত্তীর্ণ হতে পারে।

নিরাপত্তা প্যাচ প্রয়োগ করার পর যদি কোনো CTS টেস্ট হঠাৎ ব্যর্থ হয়, তবে প্রস্তুতকারককে অবশ্যই প্যাচটি এমনভাবে সংশোধন করতে হবে যাতে এটি সামঞ্জস্যতা নষ্ট না করে, অথবা টেস্টটি যে ভুল তা দেখাতে হবে এবং এর জন্য একটি সমাধান প্রদান করতে হবে (যেমনটি উপরে বর্ণনা করা হয়েছে)।

টেস্ট ফিক্স পর্যালোচনার জন্য CTS খোলা রয়েছে। উদাহরণস্বরূপ, Android 4.4-এর জন্য ফিক্স গ্রহণ করা অব্যাহত আছে (দেখুন https://android-review.googlesource.com/c/platform/cts/+/273371 )।

প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী (FAQs)

অ্যান্ড্রয়েডের কোনো নির্দিষ্ট সংস্করণে নিরাপত্তা আপডেট প্রয়োগ করার দায়িত্বে কে থাকেন?

উ: সরাসরি ডিভাইস সরবরাহকারী প্রস্তুতকারকই দায়ী। এই সংস্থাটি গুগল নয় , যারা AOSP-তে নিরাপত্তা আপডেট প্রকাশ করে, কোনো নির্দিষ্ট ডিভাইসের (যেমন যানবাহন) জন্য নয়।

গুগল অ্যান্ড্রয়েডে নিরাপত্তা সংক্রান্ত সমস্যাগুলো কীভাবে সামাল দেয়?

এ: গুগল ক্রমাগত বিভিন্ন সমস্যা তদন্ত করে এবং সম্ভাব্য সমাধান তৈরি করে, যা গুগল তার নিয়মিত নিরাপত্তা আপডেট প্রক্রিয়ার অংশ হিসেবে সমস্ত সমর্থিত এপিআই লেভেলের জন্য উপলব্ধ করে। ২০১৫ সালের আগস্ট থেকে, গুগল source.android.com- এ নিয়মিতভাবে বুলেটিন এবং আপডেটের লিঙ্ক প্রকাশ করে আসছে; গুগল প্রধান ওএস রিলিজের অংশ হিসেবেও নিরাপত্তা আপডেট প্রকাশ করে। নিরাপত্তা ব্যাকপোর্ট নীতিও দেখুন।

প্রশ্ন: যদি কোনো প্রস্তুতকারক একটি ASB থেকে সমস্ত AOSP প্যাচ অন্তর্ভুক্ত করে, কিন্তু একই বুলেটিনে উল্লিখিত BSP বিক্রেতার প্যাচগুলি অন্তর্ভুক্ত না করে, তাহলে কি সে এখনও নিরাপত্তা স্তর বাড়াতে পারে (উদাহরণস্বরূপ, প্ল্যাটফর্ম/বিল্ডে সংশ্লিষ্ট প্যাচটি প্রয়োগ করে) ?

একটি অ্যান্ড্রয়েড সিকিউরিটি প্যাচ লেভেল (SPL) ঘোষণা করার জন্য, একজন নির্মাতাকে অবশ্যই অ্যান্ড্রয়েড সিকিউরিটি বুলেটিনে ( পূর্ববর্তী বুলেটিনগুলো সহ ) প্রকাশিত এবং একটি নির্দিষ্ট অ্যান্ড্রয়েড SPL-এর সাথে ম্যাপ করা সমস্ত প্রয়োজনীয় সমস্যা সমাধান করতে হবে। উদাহরণস্বরূপ, মার্চ ২০১৭ সিকিউরিটি বুলেটিন (২০১৭-০৩-০১ SPL) ব্যবহারকারী একজন নির্মাতা সেই SPL-এর জন্য মার্চ ২০১৭ বুলেটিনে নথিভুক্ত সমস্ত প্রয়োজনীয় সমস্যা এবং পূর্ববর্তী সমস্ত অ্যান্ড্রয়েড সিকিউরিটি বুলেটিনের ডিভাইস-নির্দিষ্ট আপডেট সহ সমস্ত পূর্ববর্তী আপডেটগুলো সমাধান করেছেন, যার মধ্যে ২০১৭-০২-০৫ SPL-এর সাথে সম্পর্কিত ডিভাইস-নির্দিষ্ট আপডেটগুলোও অন্তর্ভুক্ত।

প্রশ্ন: যখন প্রস্তুতকারক BSP বিক্রেতার দেওয়া নিরাপত্তা আপডেটের সাথে একমত হয় না অথবা যখন ASB দ্বারা বাধ্যতামূলক নিরাপত্তা আপডেট বিক্রেতারা প্রদান করে না, তখন কী হয়?

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

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

যদিও আমরা একটি ASB-এর সমস্ত সমস্যার সমাধান নিশ্চিত করতে সকল SoC পার্টনারদের সাথে কাজ করি, আমরা প্রস্তুতকারকদেরকে একটি ডিভাইসের জীবনচক্রের জন্য তাদের SoC ভেন্ডরদের সাথে একটি সার্ভিসিং চুক্তি করার পরামর্শ দিই। SoC-গুলো প্রত্যাশার চেয়ে আগেই কোনো চিপসেটের সার্ভিসিং বন্ধ করে দিতে পারে, তাই ডিভাইসের চিপসেট নির্বাচনের আগেই চুক্তি স্থাপন করা ডিভাইস লঞ্চ প্রক্রিয়ার একটি গুরুত্বপূর্ণ অংশ।

অবশেষে, এমন ক্ষেত্রে যেখানে একটি ASB-তে নথিভুক্ত কোনো সমস্যার সমাধান সরাসরি সংগ্রহ করা বা স্বাধীনভাবে তৈরি করা অসম্ভব, সেখানে একজন নির্মাতা পূর্ববর্তী অ্যান্ড্রয়েড SPL বজায় রাখতে পারেন এবং তারপরেও বিল্ডে নতুন উপলব্ধ সমাধানগুলো যোগ করতে পারেন। তবে, এই অভ্যাসটি শেষ পর্যন্ত বিল্ড সার্টিফিকেশনের ক্ষেত্রে সমস্যা তৈরি করবে (কারণ অ্যান্ড্রয়েড নিশ্চিত করে যে সার্টিফাইড ডিভাইসগুলোতে সর্বশেষ নিরাপত্তা প্যাচ লেভেল উপলব্ধ থাকে)। এই অভ্যাসটি এড়াতে গুগল আগে থেকেই আপনার SoC-এর সাথে কাজ করার পরামর্শ দেয়।

প্রশ্ন: যদি প্রস্তুতকারক নির্ধারণ করে যে কোনো ASB আইটেম তাদের পণ্যের জন্য প্রযোজ্য নয়, তাহলেও কি Google-এর অন্যান্য শর্ত পূরণ করতে বা CTS পাস করার জন্য আইটেমটি প্রয়োগ বা প্যাচ করার প্রয়োজন আছে?

অ্যান্ড্রয়েড সিকিউরিটি প্যাচ লেভেল (SPL) ঘোষণা করার জন্য আমাদের কোনো প্যাচ গ্রহণের প্রয়োজন হয় না; তবে আমাদের প্রয়োজন হয় যে, নির্মাতা এই মর্মে প্রত্যয়ন করুক যে তাদের বিল্ডটি উক্ত সমস্যার জন্য ঝুঁকিপূর্ণ নয়।

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

এটি একজন প্রস্তুতকারকের থেকে মৌলিকভাবে ভিন্ন, যেমন তিনি শুধু গুরুত্বপূর্ণ প্যাচগুলো ঠিক করতে চান, কিন্তু অন্যান্য প্রযোজ্য প্যাচগুলো গ্রহণ করতে চান না যেগুলো নিরাপত্তা পরীক্ষায় ব্যর্থতার কারণ হতে পারে। এই ক্ষেত্রে ধরে নেওয়া হয় যে SPL পূরণ করা হয়নি।