במדריך הזה מתוארות שיטות מומלצות של Google להחלת תיקוני אבטחה שנבדקים על ידי חבילת בדיקות התאימות של Android (CTS). התוכנית מיועדת ליצרנים של ציוד OEM שתואם ל-Android (יצרנים) שיקבל תמיכה למשך יותר משלוש שנים, כמו כלי רכב, טלוויזיות, ממירים ומכשירי חשמל ביתיים. המדריך הזה לא מיועד למשתמשי קצה (למשל, בעלי רכב).
אישורים וכתבי ויתור
המדריך הזה לא מחייב את Google או יצרנים אחרים מבחינה משפטית או חוזית, והוא לא מיועד להיות קבוצה של דרישות. המדריך הזה הוא כלי עזר שמסביר על שיטות מומלצות.
משוב
המדריך הזה לא מקיף את כל הנושאים, ויש לנו תוכניות לעדכן אותו בהמשך. אפשר לשלוח משוב לכתובת manufacturers-guide-android@googlegroups.com.
מילון מונחים
| מונח | הגדרה |
|---|---|
| ACC | התחייבות לתאימות ל-Android. נקרא בעבר Android Anti-Fragmentation Agreement (הסכם למניעת פיצול של Android) (AFA). |
| AOSP | פרויקט קוד פתוח של Android |
| ASB | חדשות האבטחה של Android |
| BSP | חבילת תמיכה של הלוח (BSP) |
| CDD | מסמך הגדרת תאימות (CDD) |
| CTS | חבילה לבדיקות תאימות (CTS) |
| FOTA | קושחה דרך האוויר |
| GPS | מערכת מיקום גלובלית |
| MISRA | Motor Industry Software Reliability Association |
| NIST | National Institute of Standards and Technology |
| OBD | אבחון מובנה (OBD-II הוא שיפור של OBD-I מבחינת היכולת והתקנון) |
| OEM (יצרן ציוד מקורי) | יצרן ציוד מקורי |
| מערכת הפעלה | מערכת הפעלה |
| SEI | Software Engineering Institute |
| SoC | מערכת על שבב (SoC) |
| SOP | תחילת הייצור |
| SPL | רמת תיקון האבטחה |
| TPMS | מערכת לניטור לחץ אוויר בצמיגים |
מידע על Android OS
Android הוא סטאק תוכנה מלא בקוד פתוח שמבוסס על Linux, ומיועד למגוון מכשירים וצורות. מאז ההשקה הראשונה שלו בשנת 2008, Android הפכה למערכת ההפעלה הפופולרית ביותר, והיא מפעילה יותר מ-1.4 מיליארד מכשירים ברחבי העולם (2016). בכ-67% מהמכשירים האלה פועלת מערכת Android 5.0 (Lollipop) או גרסה חדשה יותר, נכון למרץ 2017 (נתונים עדכניים יותר זמינים בלוח הבקרה של Android). רוב המכשירים הם טלפונים ניידים וטאבלטים, אבל השימוש ב-Android גדל בשעונים חכמים, בטלוויזיות ובמערכות מידע ובידור (IVI) ברכבים.
מספר האפליקציות ל-Android שזמינות בחנות Google Play הגיע ל2.2 מיליון (2016). פיתוח אפליקציות ל-Android נתמך על ידי תוכנית התאימות של Android, שמגדירה קבוצה של דרישות באמצעות מסמך הגדרת התאימות (CDD) ומספקת כלי בדיקה באמצעות חבילת הבדיקות לתאימות (CTS). תוכניות התאימות של Android מבטיחות שכל אפליקציית Android תוכל לפעול בכל מכשיר שתואם ל-Android ותומך בתכונות הנדרשות של האפליקציה.
Google מפרסמת באופן קבוע גרסאות חדשות של מערכת ההפעלה, עדכוני אבטחה של מערכת ההפעלה ומידע על נקודות חולשה שהתגלו. יצרנים צריכים לעיין בחדשות האבטחה של Android כדי לבדוק אם העדכונים האלה רלוונטיים למוצרים נתמכים של Android OS. לסקירה של מערכות האבטחה, התאימות וה-Build של Android, אפשר לעיין במאמרים הבאים:
- אבטחת מכשיר Android
- עדכוני אבטחה ומקורות מידע
- חבילה לבדיקות תאימות (CTS)
- שמות קוד, תגים ומספרי Build
מידע על רכבים מחוברים (מוצרים קנוניים לטווח ארוך)
התחילו לחבר רכבים עם הצגת רדיו AM בשנות ה-20. מאז, מספר החיבורים הפיזיים והאלחוטיים החיצוניים התחיל לגדול, כי רשויות רגולטוריות ויצרני רכב פנו לאלקטרוניקה כדי להקל על האבחון והשירות (למשל, יציאת OBD-II), לשפר את הבטיחות (למשל, TPMS) ולעמוד ביעדי צריכת הדלק. הגל הבא של הקישוריות הציג תכונות נוחות לנהג, כמו כניסה ללא מפתח בשליטה מרחוק, מערכות טלמטיקה ותכונות מתקדמות של מערכות מידע ובידור, כמו Bluetooth, Wi-Fi והקרנה של סמארטפון. כיום, חיישנים משולבים וקישוריות (לדוגמה, GPS) תומכים במערכות בטיחות ובמערכות נהיגה חצי-אוטונומיות.
ככל שמספר החיבורים לרכב גדל, כך גדל שטח ההתקפה הפוטנציאלי של הרכב. החיבורים מעלים חששות דומים לגבי אבטחת סייבר כמו אלה שקיימים לגבי מוצרי אלקטרוניקה לצרכן. עם זאת, בעוד שהפעלה מחדש, עדכוני תיקוני אבטחה יומיים והתנהגויות לא מוסברות הם הנורמה במוצרי אלקטרוניקה לצרכן, הם לא עקביים במוצרים עם מערכות קריטיות לבטיחות כמו כלי רכב.
היצרנים צריכים לנקוט גישה פרואקטיבית כדי להבטיח את המשך האבטחה והבטיחות של מוצר בשטח. בקיצור, היצרנים צריכים להיות מודעים לנקודות חולשה ידועות באבטחה של המוצר ולנקוט גישה מבוססת-סיכון כדי לטפל בהן.
שיפור האבטחה לטווח ארוך
לרכב מחובר יש בדרך כלל יחידת בקרה אלקטרונית (ECU) אחת או יותר, שכוללות רכיבי תוכנה רבים כמו מערכת הפעלה, ספריות, כלי עזר וכו'. היצרנים צריכים לעקוב אחרי רכיבים כאלה ולזהות פגיעויות ידועות שפורסמו באמצעות ניתוח יזום, כולל:
- הערכה קבועה של המוצר בהשוואה למאגר המידע של נקודות חולשה נפוצות (CVE).
- איסוף מודיעין לגבי פגמי אבטחה שקשורים למוצרים.
- בדיקות אבטחה.
- אנחנו מנתחים באופן פעיל את חדשות האבטחה של Android.
דוגמאות לעדכוני מערכת הפעלה ותיקוני אבטחה (מערכות IVI שמריצות Android):
איור 1. דוגמה לפריסת עדכון חשוב של מערכת ההפעלה ועדכון אבטחה במהלך חיי הרכב.
| # | שלב | פעילויות |
|---|---|---|
|
① |
Development Branch | היצרן בוחר גרסה של Android (Android X). בדוגמה הזו, 'Android X' הופך לבסיס של מה שיישלח ברכב שנתיים לפני תחילת הייצור (SOP). |
| ② | השקה ראשונית | כמה חודשים לפני שגרסה Android X הופכת לגרסת מערכת ההפעלה הראשונה שנשלחת במוצר, עדכוני האבטחה נלקחים מחדשות האבטחה ל-Android (ASB) וממקורות אחרים שהיצרן רואה בהם ערך. y2 = חדשות האבטחה השנייה לגרסה X של Android, שהיצרן יישם (ביצע backport) ב-Android X. העדכון הזה נשלח במוצר, והשעון של הייצור מתחיל לתקתק בשנה אפס עם Android X.y2.
בדוגמה הזו, היצרן החליט לא לשלוח את הגרסה השנתית העדכנית יותר של Android X+1. הסיבות לשליחת הגרסה האחרונה כוללות הוספת תכונות חדשות, טיפול בפגיעויות אבטחה חדשות ו/או שליחת שירותים של Google או של צד שלישי שנדרשת עבורם גרסת Android חדשה יותר. הסיבות לדחייה של משלוח עם הגרסה האחרונה הן חוסר הזמן שנדרש לתהליך הפיתוח וההשקה של הרכב כדי לשלב, לבדוק ולאמת את השינויים, כולל עמידה בכל הדרישות הרגולטוריות והאישורים. |
| ③ | עדכון מלא של מערכת ההפעלה | אחרי תאריך ה-SOP, היצרן מפרסם עדכון למערכת ההפעלה Android X+2, שהוא שני מהדורות של Android
אחרי הגרסה ששימשה למוצר הראשוני (Android X0). עדכוני האבטחה של ASB זמינים לרמת ה-API (נכון לתאריך השחרור), כך שהעדכון מתבצע כ-X+2.y0, בערך 1.25 שנים אחרי תאריך השחרור. יכול להיות שהעדכון הזה של מערכת ההפעלה תואם למוצרים בשטח, ויכול להיות שלא. אם כן,
אפשר ליצור תוכנית לעדכון כלי הרכב שהופעלו.
אלא אם קיימים הסכמים עסקיים אחרים, ההחלטה לבצע עדכון מלא של מערכת ההפעלה נתונה לשיקול דעתו של היצרן בלבד. |
| ④ | עדכון אבטחה | שנתיים אחרי תחילת הייצור של הרכב, היצרן מתקן את מערכת ההפעלה Android X+2. ההחלטה הזו מבוססת על הערכת הסיכונים של היצרן. היצרן
בוחר בעדכון האבטחה השלישי של ASB לגרסה X+2 כבסיס לעדכון. המוצרים
שמקבלים את עדכון האבטחה נמצאים עכשיו במערכת הפעלה (X+2.y3) + רמת תיקון האבטחה ב-Android.
יצרנים יכולים לבחור תיקוני אבטחה ספציפיים מכל ASB, אבל הם חייבים לתקן את כל הבעיות הנדרשות ב-ASB כדי להשתמש ברמת תיקון האבטחה (SPL) של Android שמשויכת ל-ASB (לדוגמה, 2017-02-05). האחריות לביצוע ה-backport ולפרסום עדכון האבטחה למוצר הנתמך היא של היצרן. |
| ⑤ | עדכון מלא של מערכת ההפעלה | חזרה על שלב 3 (עדכון מלא של מערכת ההפעלה). העדכון המלא השני של מערכת ההפעלה מעדכן את המוצר ל-Android X+4, שלוש שנים לאחר תחילת מחזור החיים של הייצור של הרכב. היצרן מאזן עכשיו בין דרישות החומרה החדשות של גרסת Android עדכנית לבין החומרה במוצר, והמשתמשים נהנים מגרסת Android OS מעודכנת. היצרן מפרסם עדכון ללא עדכוני אבטחה, ולכן המוצר נמצא עכשיו בגרסה (X+4.y0) של מערכת ההפעלה + רמת תיקון האבטחה ב-Android.
בדוגמה הזו, בגלל מגבלות חומרה, X+4 היא הגרסה העיקרית האחרונה של Android שתסופק למוצר הזה, למרות שתוחלת החיים הצפויה של הרכב היא 6 שנים ומעלה, ולכן נדרשת תמיכה באבטחה. |
| ⑥ | עדכון אבטחה | חוזרים על שלב 4 (עדכון אבטחה). היצרן צריך לקחת עדכוני אבטחה של ASB מגרסה הרבה יותר מאוחרת של Android (X+6) ולייבא חלק מהעדכונים האלה או את כולם בחזרה ל-Android X+4. באחריות היצרן למזג, לשלב ולבצע את העדכונים (או להתקשר עם צד שלישי). בנוסף, היצרן צריך לדעת שבעיות אבטחה בגרסאות של Android שכבר לא נתמכות לא מכוסות ב-ASB. |
| ⑦ | עדכון אבטחה | שמונה שנים אחרי תחילת מחזור החיים של הרכב, ארבע גרסאות של Android אחרי העדכון האחרון של מערכת ההפעלה בשלב 5 (עדכון מלא של מערכת ההפעלה), ועשר שנים אחרי שצוינה גרסה Android X, האחריות על אוסף תיקוני האבטחה והעברתם לגרסאות קודמות מוטלת כולה על היצרן עבור גרסאות שגילן יותר משלוש שנים ממועד הפרסום של רמת ה-API. |
שיטות מומלצות לאבטחה
כדי להקשות על פריצות לאבטחה, Google ממליצה להשתמש בשיטות מומלצות ומקובלות לאבטחה ולהנדסת תוכנה, וגם משתמשת בהן בעצמה, כמו שמתואר במאמר הטמעת אבטחה.
הנחיות בנושא אבטחה
שיטות מומלצות לאבטחה:
- להשתמש בגרסאות העדכניות ביותר של ספריות חיצוניות ורכיבי קוד פתוח.
- אין לכלול פונקציונליות פולשנית לניפוי באגים בגרסאות של מערכת ההפעלה שמופצות לציבור.
- הסרת פונקציונליות שלא נמצאת בשימוש (כדי לצמצם את שטח הפנים של ההתקפה).
- מומלץ להשתמש בעיקרון של הרשאות מינימליות ובשיטות מומלצות אחרות לפיתוח אפליקציות ל-Android.
הנחיות לפיתוח תוכנה
שיטות מומלצות לפיתוח תוכנה מאובטח לאורך מחזור החיים של המערכת:
- ביצוע מודלים של איומים כדי לדרג ולזהות נכסים, איומים ופתרונות אפשריים.
- ביצוע בדיקה של הארכיטקטורה או העיצוב כדי לוודא שהם מאובטחים ומוצלחים.
- כדאי לבצע בדיקות קוד באופן קבוע כדי לזהות דפוסים לא רצויים ובאגים בהקדם האפשרי.
- תכנון, הטמעה והרצה של בדיקות יחידה (unit testing) עם כיסוי קוד גבוה, כולל:
- בדיקות פונקציונליות (כולל תרחישי בדיקה שליליים)
- בדיקות רגרסיה רגילות (כדי לוודא שבאגים שתוקנו לא יחזרו)
- בדיקת Fuzzing (כחלק מחבילת בדיקות היחידה)
- אפשר להשתמש בכלים סטטיים לניתוח קוד מקור (scan-build, lint וכו') כדי לזהות בעיות פוטנציאליות.
- כדי לזהות בעיות פוטנציאליות במהלך פיתוח המערכת ולצמצם את הסיכון להן, כדאי להשתמש בכלים לניתוח דינמי של קוד המקור, כמו AddressSanitizer, UndefinedBehaviorSanitizer ו-FORTIFY_SOURCE (לרכיבים מקוריים).
- לגבש אסטרטגיה לניהול קוד המקור של התוכנה והגדרת הגרסה או הגרסה של התוכנה.
- לגבש אסטרטגיה לניהול תיקונים ליצירה ולפריסה של תיקוני תוכנה.
מדיניות בנושא העברה לאחור של תיקוני אבטחה
Google מספקת כרגע תמיכה פעילה בתיקוני אבטחה (backports) של פגיעויות אבטחה שמתגלות ומדווחות למשך שלוש (3) שנים ממועד הפרסום הפומבי של רמת ה-API. תמיכה פעילה כוללת את הפעולות הבאות:
- קבלת דוחות על נקודות חולשה וחקירתם.
- ליצור, לבדוק ולפרסם עדכוני אבטחה.
- לספק פרטים על עדכוני אבטחה ועל עלוני אבטחה באופן חוזר.
- צריך לבצע הערכת חומרה בהתאם להנחיות שנקבעו.
אחרי שלוש שנים מתאריך הפרסום של רמת ה-API, Google ממליצה לפעול לפי ההנחיות הבאות:
- כדי לקבל תמיכה בהעברת תיקונים (backport) לעדכוני אבטחה של מערכת הפעלה מלפני יותר משלוש שנים ממועד ההשקה של ה-API, צריך להשתמש בצד שלישי (כמו ספק SoC או ספק ליבה).
- להשתמש בצד שלישי כדי לבצע בדיקות קוד באמצעות ה-ASB שסופקו לציבור. אף על פי ש-ASB מזהה נקודות חולשה בגרסה שנתמכת כרגע, יצרן יכול להשתמש במידע שסופק כדי להשוות בין העדכונים שפורסמו לאחרונה לבין גרסאות קודמות. אפשר להשתמש בנתונים האלה כדי לבצע ניתוח השפעה, ואולי ליצור תיקונים דומים לגרסאות של מערכת ההפעלה שהן ישנות יותר משלוש שנים ממועד ההשקה של ה-API.
- כשמתאים, מעלים עדכוני אבטחה ל-Android Open Source Project (AOSP).
- היצרן צריך לתאם את הטיפול בעדכוני אבטחה לקוד ספציפי לספק (לדוגמה, קוד קנייני ספציפי למכשיר).
- היצרן צריך להצטרף לקבוצת ההודעות על תצוגה מקדימה של שותפים ב-Android Security Bulletin (נדרשת חתימה על הסכמים משפטיים כמו הסכם NDA למפתחים). הודעות לעיתונות צריכות לכלול:
- הודעות
- סיכום הבעיות לפי רמת התיקון, כולל CVE וחומרה
- פרטים על נקודת החולשה, אם רלוונטי
הפניות נוספות
הוראות בנושא קידוד מאובטח ושיטות מומלצות לפיתוח תוכנה מפורטות במקורות הבאים:
- Motor Industry Software Reliability Association (MISRA).
- כלים ושיטות של Software Engineering Institute (SEI).
- National Institute of Standards and Technology (NIST)
שיטות מומלצות לשימוש במוצרים
Google מעודדת שימוש בשיטות המומלצות הבאות.
הנחיות כלליות להשקה
באופן כללי, מומלץ להשיק כל מוצר מחובר עם הגרסה העדכנית ביותר של מערכת ההפעלה, ויצרן צריך לנסות להשתמש בגרסה העדכנית ביותר של מערכת ההפעלה לפני השקת המוצר. נעילת הגרסה נחוצה כדי לשמור על יציבות לפני בדיקה ואימות, אבל היצרן צריך לאזן בין יציבות המוצר שמתקבלת מגרסאות OS ישנות יותר לבין גרסאות OS חדשות יותר שיש בהן פחות נקודות חולשה ידועות באבטחה והגנות אבטחה משופרות.
ההנחיות המומלצות כוללות:
- בגלל זמני ההכנה הארוכים שמאפיינים את תהליך פיתוח הרכב, יכול להיות שיצרנים ישיקו עם גרסת מערכת הפעלה n-2 או גרסה ישנה יותר.
- שומרים על התאמה ל-Android Compatibility לכל גרסת Android OS שמופצת באמצעות קמפיין OTA (Over-the-Air).
- הטמעה של מוצר עם יכולת Android Firmware-over-the-air (FOTA) לעדכונים מהירים וידידותיים ללקוחות. מומלץ לבצע FOTA באמצעות שיטות מומלצות לאבטחה, כמו חתימה על קוד וחיבור TLS בין המוצר למשרד האחורי של ה-IT.
- שליחה של נקודות חולשה באבטחה ב-Android שזוהו באופן עצמאי לצוות האבטחה של Android.
הערה: Google שוקלת להוסיף לעדכוני האבטחה של Android הודעות ספציפיות לסוג המכשיר או לתעשייה. עם זאת, מכיוון ש-Google לא יודעת מהם ליבת המערכת, מנהלי ההתקנים או ערכות השבבים של מכשיר מסוים (רכב, טלוויזיה, מכשיר לביש, טלפון וכו'), אין ל-Google דרך דטרמיניסטית לסווג בעיית אבטחה מסוימת לפי סוג המכשיר.
הנחיות לגבי מחזור החיים של המוצר
היצרן צריך לעשות כל מאמץ להשתמש בגרסה האחרונה של מערכת ההפעלה או בעדכוני אבטחה לגרסה שבשימוש במהלך שיפורים במחזור חיי המוצר. אפשר לבצע עדכונים במהלך עדכוני מוצרים תקופתיים חוזרים, או כתיקוני באגים כדי לפתור בעיות שקשורות לאיכות או לבעיות אחרות. שיטות מומלצות:
- ליצור תוכנית לטיפול בעדכונים של מנהלי התקנים, ליבות ופרוטוקולים.
- משתמשים בשיטה שמתאימה לתעשייה כדי לספק עדכונים לרכבים שהוצבו.
מסמך הגדרת תאימות (CDD)
במסמך הגדרת התאימות (CDD) מפורטות הדרישות שמכשיר צריך לעמוד בהן כדי להיחשב כתואם ל-Android. מסמך ה-CDD הוא ציבורי וזמין לכולם. אפשר להוריד גרסאות של CDD מ-Android 1.6 ועד הגרסה האחרונה מכתובת source.android.com.
כדי לעמוד בדרישות האלה לגבי מוצר, צריך לבצע את השלבים הבסיסיים הבאים:
- השותף חותם על התחייבות התאימות ל-Android (ACC) עם Google. לאחר מכן, מוקצה לכם יועץ בנושא פתרונות טכניים (TSC) שידריך אתכם.
- השותף משלים את הבדיקה של CDD לגרסת מערכת ההפעלה של Android של המוצר.
- השותף מריץ את בדיקות ה-CTS (כפי שמתואר בהמשך) ושולח את התוצאות עד שהן עומדות בדרישות התאימות ל-Android.
חבילה לבדיקות תאימות (CTS)
כלי הבדיקה של חבילת בדיקות התאימות (CTS) מאמת שהטמעת המוצר תואמת ל-Android ושהתיקונים האחרונים לפגיעויות באבטחה כלולים בה. CTS הוא ציבורי, קוד פתוח וזמין לכולם. אפשר להוריד גרסאות של CTS מ-Android 1.6 ועד לגרסה האחרונה מ-source.android.com.
כל גרסה של תוכנת Android שמופצת לציבור (תמונות של התקנה במפעל ועדכון בשטח) צריכה להוכיח תאימות ל-Android באמצעות תוצאות CTS. לדוגמה, אם המכשיר מריץ Android 7.1, צריך להתייחס לגרסה התואמת האחרונה של CDD 7.1 ו-CTS 7.1 כשיוצרים ובודקים תמונה של build עם כוונת הפצה. מומלץ מאוד ליצרנים להשתמש ב-CTS מוקדם ובאופן תדיר כדי לזהות בעיות ולפתור אותן.
תהליך העבודה ב-CTS
תהליך העבודה של CTS כולל הגדרה של סביבת הבדיקה, הרצת בדיקות, פירוש התוצאות והבנת קוד המקור של CTS. ההנחיות הבאות מיועדות לעזור למשתמשים ב-CTS (למשל, מפתחים, יצרנים) להשתמש ב-CTS בצורה יעילה.
- הרצת בדיקות לעיתים קרובות. CTS הוא כלי אוטומטי שמשולב במערכת הבנייה. הפעלת CTS בתדירות גבוהה יכולה לעזור לכם למצוא פגמים במהירות ובשלב מוקדם כשמתרחשת ירידה באיכות התוכנה או רגרסיות.
- הורדה ובדיקה של קוד המקור של CTS. קוד המקור המלא של CTS הוא תוכנת קוד פתוח שכל אחד יכול להוריד ולהשתמש בה (אפשר לבנות ולהפעיל את קוד המקור שהורד). אם בדיקה נכשלת במכשיר, עיון בקטע הרלוונטי של קוד המקור יכול לעזור לכם לזהות את הסיבה לכך.
- הורדת ה-CTS העדכני בגרסאות חדשות של Android אפשר לעדכן את ה-CTS עם תיקוני באגים, שיפורים ובדיקות חדשות. חשוב לבדוק את ההורדות של CTS לעיתים קרובות ולעדכן את תוכנית ה-CTS לפי הצורך. היצרן ו-Google יגיעו להסכמה לגבי גרסת ה-CTS שצריך לעבור כדי להשיק את המוצר, כי בשלב מסוים צריך להקפיא את המוצר בזמן ש-CTS ממשיך להתעדכן.
עוברים את בדיקת ה-CTS
במוצר שתואם ל-Android, Google מוודאת שתוצאות הבדיקה של CTS ושל דוחות CTS Verifier של המכשיר מקובלות. באופן עקרוני, כל הבדיקות צריכות לעבור בהצלחה. עם זאת, אם הבדיקה נכשלת מסיבות אחרות מלבד אי-התאמה של המכשיר לדרישות התאימות של Android, Google תבדוק את המקרה. במהלך התהליך הזה:
- היצרן מספק ל-Google את התיקונים המוצעים ל-CTS, את אימותי התיקונים ואת ההצדקות כדי להוכיח את הטענה.
- Google בודקת את החומרים שנשלחו, ואם הם מתקבלים, היא מעדכנת את בדיקות ה-CTS הרלוונטיות כדי שהמכשיר יעבור את הבדיקות בגרסה הבאה של CTS.
אם בדיקת CTS נכשלת פתאום אחרי החלת תיקון אבטחה, היצרן צריך לשנות את התיקון כדי שלא יפגע בתאימות, או להראות שהבדיקה שגויה ולספק תיקון לבדיקה (כפי שמתואר למעלה).
מערכת ה-CTS נשארת פתוחה לביקורות על תיקונים של בדיקות. לדוגמה, Android 4.4 ממשיכה לקבל תיקונים (ראו https://android-review.googlesource.com/c/platform/cts/+/273371).
שאלות נפוצות
ש: מי אחראי להחלת עדכוני אבטחה על הטמעה ספציפית של Android?
תשובה: היצרן שאחראי על אספקת המכשיר ישירות. הגורם הזה אינו Google, שמפרסמת עדכוני אבטחה ב-AOSP ולא למכשיר ספציפי (כמו רכב).
ש: איך Google מטפלת בבעיות אבטחה ב-Android?
ת: Google בודקת בעיות באופן שוטף ומפתחת תיקונים פוטנציאליים, ש-Google מפרסמת לכל רמות ה-API הנתמכות כחלק מתהליך עדכון האבטחה הרגיל. מאז אוגוסט 2015, Google מפרסמת באופן קבוע הודעות וקישורים לעדכונים בכתובת source.android.com. בנוסף, Google מפרסמת עדכוני אבטחה כחלק מגרסאות OS ראשיות. אפשר לעיין גם ב מדיניות בנושא תיקוני אבטחה.
ש: אם יצרן שילב את כל התיקונים של AOSP מ-ASB אבל לא שילב תיקונים מספק BSP שמוזכר באותו עלון, האם הוא עדיין יכול להעלות את רמת האבטחה (לדוגמה, להחיל את התיקון המתאים על platform/build)?
ת: כדי להצהיר על רמת תיקוני אבטחה (SPL) של Android, יצרן צריך לטפל בכל הבעיות הנדרשות שפורסמו בחדשות האבטחה של Android (כולל חדשות קודמות) ולמפות אותן לרמת תיקוני אבטחה מסוימת של Android. לדוגמה, יצרן שמשתמש בחדשות האבטחה ממרץ 2017 (SPL 2017-03-01) טיפל בכל הבעיות הנדרשות שמתועדות בחדשות האבטחה ממרץ 2017 עבור ה-SPL הזה, ובכל העדכונים הקודמים, כולל עדכונים ספציפיים למכשיר לכל חדשות האבטחה הקודמות של Android, כולל העדכונים הספציפיים למכשיר שמשויכים ל-SPL 2017-02-05.
ש: מה קורה כשהיצרן לא מסכים לעדכוני אבטחה שסופקו על ידי ספק BSP, או כשספקים לא מספקים עדכוני אבטחה שנדרשים על ידי ASB?
תשובה: ב-ASB מתוארות נקודות חולשה באבטחה (שמפורטות ברשימה של CVE), ולרוב מסופקות בדיקות אבטחה תואמות. המטרה היא לוודא שלא ניתן לשחזר יותר את נקודות החולשה שמופיעות ברשימה במכשיר, ושהמכשיר יכול לעבור את בדיקות האבטחה שקשורות לכך. לכן, הבעיה לא קשורה לעדכון אבטחה שסופק על ידי Google או על ידי ספק צד שלישי, אלא לכך שהיצרן מאשר שהמכשיר לא פגיע לרשימת ה-CVE ב-ASB. היצרן יכול להשתמש בעדכוני האבטחה שסופקו, או להשתמש בשינוי אחר אם הוא מתאים יותר למכשיר שלו.
לדוגמה, נניח ש-Google מטפלת בפגיעות אבטחה ב-AOSP באמצעות שינוי בקוד שמאפשר לרכיב להמשיך לפעול באופן מלא ולעמוד בדרישות של CDD. אם היצרן קובע שהרכיב לא נדרש במכשיר או שהוא לא נדרש על ידי ה-CDD (או על ידי בדיקות אישור קשורות), היצרן יכול להסיר את הרכיב כדי לצמצם את הצורך בשירותים עתידיים ולצמצם את שטח הפנים להתקפה. למרות שהיצרן לא השתמש בעדכון האבטחה שסופק, הוא דאג שהמכשיר לא יהיה פגיע ל-CVE שמתועד בפרסום בנושא אבטחה. עם זאת, אם היצרן חורג מהעדכון המומלץ לאבטחה, הוא לוקח סיכון שהבעיה לא תיפתר בצורה נכונה, שייווצרו פגיעויות חדשות באבטחה או שהפונקציונליות של הגרסה הסופית תצומצם.
אנחנו עובדים עם כל שותפי ה-SoC כדי לוודא שיש תיקונים לכל הבעיות ב-ASB, אבל אנחנו ממליצים ליצרנים להשיג הסכם שירות עם ספקי ה-SoC שלהם למשך מחזור החיים של המכשיר. יכול להיות ש-SoC יפסיקו לתמוך בערכת שבבים מוקדם מהצפוי, ולכן חשוב להגיע להסכמים לפני שבוחרים את ערכת השבבים של המכשיר.
לבסוף, במקרים שבהם אי אפשר להשיג ישירות תיקון לבעיה שמתועדת ב-ASB או ליצור תיקון כזה באופן עצמאי, יצרן יכול לשמור על ה-SPL הקודם של Android ועדיין להוסיף את התיקונים החדשים שזמינים לגרסת ה-build. עם זאת, בסופו של דבר, השיטה הזו תוביל לבעיות באישור הבנייה (כי מערכת Android מוודאת שתיקוני האבטחה ברמה הכי עדכנית זמינים במכשירים מאושרים). Google ממליצה לעבוד עם ה-SoC מראש כדי להימנע מהשיטה הזו.
ש: אם היצרן קובע שפריט ASB לא רלוונטי למוצר שלו, האם עדיין צריך להחיל את הפריט או לתקן אותו כדי לעמוד בדרישות האחרות של Google או כדי לעבור את CTS?
תשובה: אנחנו לא דורשים להחיל תיקונים כדי להצהיר על רמת תיקון האבטחה (SPL) של Android. אנחנו כן דורשים שהיצרן יאשר שהגרסה שלו לא פגיעה לבעיה.
דוגמה אחת היא מצב שבו רכיב שמקבל תיקון לא קיים במערכת של היצרן, או שמסירים רכיב מהמערכת של היצרן כדי לפתור בעיה. במקרה כזה, יכול להיות שהמערכת תעמוד בדרישות בלי שהיצרן יצטרך להחיל תיקון.
זה שונה באופן מהותי מיצרן שרוצה, למשל, לתקן רק תיקונים קריטיים, ולא להחיל תיקונים רלוונטיים אחרים, מה שיגרום לכך שבדיקת האבטחה תיכשל. במקרה כזה, נניח שלא עמדתם בדרישות של מדיניות ה-SPL.