עדכוני אבטחה ומשאבים

צוות האבטחה של Android אחראי לניהול נקודות חולשה באבטחה שזוהו בפלטפורמת Android וברבות מהאפליקציות המרכזיות של Android שכלולות בחבילה של מכשירי Android.

צוות האבטחה של Android מאתר נקודות חולשה באבטחה באמצעות מחקר פנימי, וגם מגיב לבאגים שדווחו על ידי צדדים שלישיים. מקורות של באגים חיצוניים כוללים בעיות שדוּוחו באמצעות הטופס לדיווח על נקודות חולשה, מחקר אקדמי שפורסם או שפורסם מראש, מנהלי פרויקטים של קוד פתוח ב-upstream, התראות מהשותפים שלנו בתחום ייצור המכשירים ובעיות שפורסמו באופן ציבורי בבלוגים או ברשתות חברתיות.

דיווח על בעיות אבטחה

כל מפתח, משתמש ב-Android או חוקר אבטחה יכול לדווח לצוות האבטחה של Android על בעיות אבטחה פוטנציאליות באמצעות הטופס לדיווח על נקודות חולשה.

באגים שמסומנים כבעיות אבטחה לא גלויים לכולם, אבל יכול להיות שהם יוצגו בסופו של דבר אחרי שהבעיה תהיה מוערכת או תיפתר. אם אתם מתכננים לשלוח תיקון או בדיקה של חבילת בדיקות התאימות (CTS) כדי לפתור בעיית אבטחה, עליכם לצרף את התיקון או את הבדיקה לדוח הבאג ולחכות לתגובה לפני העלאת הקוד ל-AOSP.

מיון באגים

המשימה הראשונה בטיפול בנקודת חולשה באבטחה היא לזהות את חומרת הבאג ואת הרכיב ב-Android שנפגע. רמת החומרה קובעת את סדר העדיפויות של הבעיה, והרכיב קובע מי יטפל בבאג, למי תישלח הודעה ואיך התיקון יופעל למשתמשים.

סוגי הקשר

בטבלה הזו מפורטות ההגדרות של הקשרי האבטחה של החומרה והתוכנה. ההקשר יכול להיות מוגדר לפי רמת הרגישות של הנתונים שהוא מעבד בדרך כלל או לפי האזור שבו הוא פועל. לא כל הקשרי האבטחה רלוונטיים לכל המערכות. הטבלה ממוינת מההרשאות המינימליות להרשאות המקסימליות.

סוג ההקשר הגדרת טיפוס
הקשר מוגבל סביבת הפעלה מוגבלת שבה ניתנות רק ההרשאות המינימליות ביותר.

לדוגמה, אפליקציות מהימנות שמעבדות נתונים לא מהימנים בסביבת חול.
הקשר ללא הרשאות סביבת הפעלה רגילה שקוד ללא הרשאות מצפה לה.

לדוגמה, אפליקציית Android שפועלת בדומיין SELinux עם המאפיין untrusted_app_all.
הקשר בעל ההרשאות סביבת הפעלה בעלת הרשאות, שעשויה להיות לה גישה להרשאות מורחבות, מטפלת במספר פרטים אישיים מזהים של משתמשים ו/או שומרת על תקינות המערכת.

לדוגמה, אפליקציה ל-Android עם יכולות שתהיינה אסורות על ידי הדומיין untrusted_app של SELinux או עם גישה להרשאות privileged|signature.
ליבה של מערכת הפעלה פונקציונליות ש:
  • הוא חלק מהליבת המערכת
  • פועלים באותו הקשר של המעבד כמו הליבה (לדוגמה, מנהלי התקנים)
  • יש לו גישה ישירה לזיכרון הליבה (לדוגמה, רכיבי חומרה במכשיר)
  • יש לו יכולת לטעון סקריפטים לרכיב ליבה (למשל, eBPF)
  • הוא אחד משירותי המשתמש הבודדים שנחשבים מקבילים לליבה (כמו apexd,‏ bpfloader,‏ init,‏ ueventd ו-vold).
Trusted Hardware Base‏ (THB) רכיבי חומרה נפרדים, בדרך כלל ב-SoC, שמספקים פונקציונליות קריטית לתרחישי השימוש המרכזיים של המכשיר (כמו בסיסים סלולריים, מעבדי DSP, מעבדי GPU ומעבדי ML).
שרשרת של תוכנת אתחול רכיב שמגדיר את המכשיר בזמן האתחול ואז מעביר את השליטה למערכת ההפעלה Android.
סביבת מחשוב אמינה (TEE) רכיב שתוכנן להגנה מפני ליבה עוינת של מערכת הפעלה (לדוגמה, TrustZone ומכונות וירטואליות, כמו pKVM, שמגינות על מכונות וירטואליות מפני ליבה של מערכת הפעלה).
Secure Enclave או Secure Element‏ (SE) רכיב חומרה אופציונלי שמיועד להגנה מפני כל הרכיבים האחרים במכשיר ומפני התקפה פיזית, כפי שמוגדר במאמר מבוא לרכיבי Secure Element.

כולל את הצ'יפ Titan-M שנמצא במכשירי Android מסוימים.

מידת החומרה

חומרת הבאג בדרך כלל משקפת את הנזק הפוטנציאלי שעלול לקרות אם ינצלו את הבאג. הקריטריונים הבאים יעזרו לכם לקבוע את מידת החומרה.

Rating ההשלכות של ניצול מוצלח
קריטי
  • ביצוע קוד אקראי ב-TEE או ב-SE
  • עקיפת מנגנוני תוכנה שנועדו למנוע תקלה ברכיבי תוכנה או חומרה שקשורים לבטיחות (לדוגמה, הגנות תרמיות)
  • גישה מרחוק לפרטי כניסה רגישים המשמשים לאימות שירות מרחוק (למשל, סיסמאות לחשבונות או אסימוני בעלות)
  • הרצת קוד שרירותי מרחוק בהקשר של תדר הבסיס הסלולרי ללא אינטראקציה של המשתמש (לדוגמה, ניצול באג בשירות הרדיו הסלולרי)
  • ביצוע קוד שרירותי מרחוק בהקשר בעל הרשאות, בשרשרת של מנהל האתחול, ב-THB או בליבה של מערכת ההפעלה
  • עקיפה מרחוק של דרישות האינטראקציה של המשתמש בהתקנת חבילה או התנהגות מקבילה
  • עקיפת מרחוק של דרישות האינטראקציה של המשתמש בהגדרות הליבה של המפתחים, האבטחה או הפרטיות
  • מניעת שירות מתמשכת מרחוק (קבועה, דורשת מחיקת כל נתוני מערכת ההפעלה או איפוס להגדרות המקוריות)
  • עקיפה מרחוק של הפעלה מאובטחת
  • גישה לא מורשית לנתונים שמאובטחים על ידי ה-SE, כולל גישה שמופעל על ידי מפתחות חלשים ב-SE.
גבוהה
  • עקיפה מלאה של תכונת אבטחה מרכזית (למשל, SELinux,‏ FBE או seccomp)
  • עקיפה כללית של הגנה לעומק או טכנולוגיה לצמצום נקודות חולשה בשרשרת של מנהל האתחול, ב-TEE או ב-SE
  • דרך עקיפה כללית להגנה של מערכת ההפעלה, שמאפשרת לחשוף את תוכן הזיכרון או הקבצים מעבר לגבולות האפליקציה, המשתמש או הפרופיל
  • התקפות על SE שמובילות לשדרוג לאחור להטמעה פחות מאובטחת
  • מעבר מתוכנת קושחת חשופה להתקפה שניתנת לגישה מרחוק (לדוגמה, תדר בסיס, מעבד תקשורת (CP)) לליבה של מעבד האפליקציות (AP) או לעקיפת מנגנונים שנועדו לבודד את קושחת הברזל החשופה להתקפה מליבה של מעבד האפליקציות
  • עקיפת ההגנה על המכשיר, ההגנה מפני איפוס להגדרות המקוריות או ההגבלות של הספק
  • עקיפת הדרישות של אינטראקציה עם משתמשים שמאובטחות על ידי ה-TEE
  • נקודת חולשה קריפטוגרפית שמאפשרת התקפות על פרוטוקולים מקצה לקצה, כולל התקפות על אבטחת שכבת התעבורה (TLS) ועל Bluetooth‏ (BT).
  • גישה מקומית לפרטי כניסה רגישים המשמשים לאימות שירות מרוחק (לדוגמה, סיסמאות לחשבונות או אסימוני בעלות)
  • ביצוע קוד שרירותי מקומי בהקשר בעל הרשאות, בשרשרת של מנהל האתחול, ב-THB או בליבה של מערכת ההפעלה
  • עקיפה מקומית של הפעלה מאובטחת
  • מעקף מסך הנעילה
  • עקיפה מקומית של דרישות האינטראקציה עם המשתמש בהגדרות הליבה של הפיתוח, האבטחה או הפרטיות
  • עקיפה מקומית של דרישות האינטראקציה של המשתמש בהתקנת חבילה או התנהגות מקבילה
  • התקפת מניעת שירות (DoS) מקומית מתמשכת (קבועה, שמחייבת מחיקת כל מערכת ההפעלה או איפוס להגדרות המקוריות)
  • גישה מרחוק לנתונים מוגנים (כלומר נתונים שמוגבלים להקשר בעל הרשאות)
  • הרצה מרחוק של קוד אקראי בהקשר ללא הרשאות
  • מניעת גישה מרחוק לשירות סלולרי או ל-Wi-Fi ללא אינטראקציה עם המשתמש (למשל, קריסת שירות הרדיו הסלולרי באמצעות חבילה בפורמט שגוי)
  • עקיפה מרחוק של דרישות האינטראקציה עם המשתמש (גישה לפונקציונליות או לנתונים שצריכה להיות להם הרשאה או התחלה על ידי המשתמש)
  • מניעת גישה ממוקדת לשירותי חירום
  • העברת מידע רגיש באמצעות פרוטוקול רשת לא מאובטח (לדוגמה, HTTP ו-Bluetooth ללא הצפנה) כשמבקש הבקשה מצפה להעברה מאובטחת. לתשומת ליבכם: הכלל הזה לא חל על הצפנת Wi-Fi (כמו WEP).
  • גישה לא מורשית לנתונים שמאובטחים על ידי ה-TEE, כולל גישה שמופעל באמצעות מפתחות חלשים ב-TEE
בינונית
  • עקיפה כללית של הגנה לעומק או של טכנולוגיה לצמצום נקודות חולשה בתרחישים של ניצול לרעה, בהקשר בעל הרשאות, ב-THB או בליבה של מערכת ההפעלה
  • דרך עקיפה כללית להגנות של מערכת ההפעלה שמגלות את מצב התהליך או את המטא-נתונים מעבר לגבולות האפליקציה, המשתמש או הפרופיל
  • עקיפה של הצפנה או אימות של Wi-Fi
  • נקודת חולשה קריפטוגרפית בפרימיטיבים קריפטוגרפיים רגילים שמאפשרת דליפת טקסט ללא הצפנה (לא פרימיטיבים שמשמשים ב-TLS)
  • גישה מקומית לנתונים מוגנים (כלומר, נתונים שמוגבלים להקשר בעל הרשאות)
  • ביצוע קוד שרירותי מקומי בהקשר ללא הרשאות
  • עקיפה מקומית של דרישות האינטראקציה עם המשתמש (גישה לפונקציונליות או לנתונים שבדרך כלל דורשים יזום או הרשאה מהמשתמש)
  • גישה מרחוק לנתונים לא מוגנים (כלומר, נתונים שכל אפליקציה שמותקנת באופן מקומי יכולה לגשת אליהם)
  • ביצוע קוד אקראי מרחוק בהקשר מוגבל
  • התקפת מניעת שירות (DoS) זמנית מרחוק במכשיר (התנתקות או הפעלה מחדש מרחוק)
נמוכה
  • עקיפה כללית של הגנה לעומק ברמת המשתמש או טכנולוגיה לצמצום נקודות חולשה בהקשר ללא הרשאות
  • עקיפה של הרשאה רגילה ברמת הגנה
  • נקודת חולשה קריפטוגרפית בשימוש לא סטנדרטי
  • עקיפה כללית של תכונות ההתאמה האישית במכשיר, כמו Voice Match או Face Match
  • מסמכים שגויים שעלולים להוביל לנקודת חולשה באבטחה
  • הרצה מקומית של קוד אקראי בהקשר מוגבל
  • טקסט שהוגדר על ידי המערכת שכולל תיאור מטעה שיוצר ציפייה מוטעית לאבטחה
השפעה זניחה על האבטחה (NSI)
  • נקודת חולשה שההשפעה שלה פחתה בעקבות שינוי אחד או יותר של גורם שינוי הדירוג או שינויים בארכיטקטורה שספציפיים לגרסה, כך שהחומרה בפועל היא נמוכה מ'נמוכה', למרות שיכול להיות שבעיית הקוד הבסיסית עדיין קיימת
  • כל נקודת חולשה שדורשת מערכת קבצים בפורמט שגוי, אם מערכת הקבצים הזו תמיד מאומצת או מוצפנת לפני השימוש.
  • התקפת מניעת שירות (DoS) זמנית מקומית, למשל במקרים שבהם אפשר לפתור את התנאי על ידי הפעלה מחדש של המכשיר או הסרה של האפליקציה שהפעילה את הבעיה.

משתני שיעור

לרוב קל לזהות את מידת החומרה של נקודות החולשה באבטחה, אבל הדירוגים עשויים להשתנות בהתאם לנסיבות.

סיבה אפקט
כדי לבצע את ההתקפה, צריך להריץ אותה בהקשר בעל הרשאות (לא רלוונטי ל-TEE, ל-SE ול-hypervisors כמו pKVM) מידת חומרה 1-
פרטים ספציפיים לנקודת החולשה מגבילים את ההשפעה של הבעיה מידת חומרה 1-
עקיפה של אימות ביומטרי שדורשת מידע ביומטרי ישירות מהבעלים של המכשיר מידת חומרה -1
הגדרות של מהדר או פלטפורמה מצמצמות נקודת חולשה בקוד המקור רמת חומרה בינונית אם נקודת החולשה הבסיסית היא בינונית או גבוהה יותר
נדרשת גישה פיזית לחלקים הפנימיים של המכשיר, והיא עדיין אפשרית אם המכשיר כבוי או שלא בוטלה הנעילה שלו מאז שהופעל. מידת חומרה -1
נדרשת גישה פיזית לחלקים הפנימיים של המכשיר בזמן שהוא מופעל ונעילה שלו בעבר מידת חומרה 2-‎
התקפה מקומית שמחייבת לבטל את הנעילה של שרשרת תוכנת האתחול לא גבוהה מ'נמוכה'
התקפה מקומית שמחייבת שהמכשיר יהיה מופעל כרגע במצב פיתוח או שהגדרות קבועות של מצב פיתוח יהיו מופעלות בו (ולא באג במצב הפיתוח עצמו). לא גבוהה מ'נמוכה'
אם אין דומיין SELinux שיכול לבצע את הפעולה במסגרת SEPolicy ש-Google מספקת השפעה זניחה על האבטחה

מקומי לעומת קרוב לעומת רחוק

וקטור התקפה מרחוק מציין שאפשר לנצל את הבאג בלי להתקין אפליקציה או בלי גישה פיזית למכשיר. הבעיות האלה כוללות באגים שיכולים להתרחש בזמן גלישה לדף אינטרנט, קריאת אימייל, קבלת הודעת SMS או חיבור לרשת עוינת.

וקטור התקפה קרוב נחשב להתקפה מרחוק. אלה כוללים באגים שאפשר לנצל רק על ידי תוקף שנמצא פיזית ליד מכשיר היעד. לדוגמה, באג שדורש שליחת חבילות Wi-Fi או Bluetooth בפורמט שגוי. אנחנו מתייחסים להתקפות מבוססות-NFC ולהתקפות Ultra-wideband (UWB) כהתקפות קרובות, ולכן מרחוק.

כדי לבצע התקפות מקומיות, לתוקף צריכה להיות גישה מוקדמת לקורבן. לדוגמה היפותטית של תוכנה בלבד, יכול להיות שזה יקרה דרך אפליקציה זדונית שהקורבן התקין, או אפליקציה ללא התקנה שהקורבן נתן לה הרשאה לפעול.

מכשירים שמותאמים בהצלחה (כמו מכשירי Bluetooth נלווים) נחשבים למכשירים מקומיים. אנחנו מבדילים בין מכשיר מותאם לבין מכשיר שמשתתף בתהליך ההתאמה.

  • באגים שגורמים לפגיעה ביכולת של המשתמש לזהות את המכשיר השני שאליו הוא מתאים את המכשיר שלו (כלומר אימות) נחשבים לבאגים בקרבת המכשיר ולכן הם באגים מרוחקים.
  • באגים שמתרחשים במהלך תהליך ההתאמה, אבל לפני שהתקבלה הסכמת המשתמש (כלומר ההרשאה), נחשבים לבעיות קרובה ולכן רחוקות.
  • באגים שמתרחשים אחרי שהמשתמשים הביעו הסכמה נחשבים לבעיות מקומיות, גם אם התאמת המכשירים נכשלת בסופו של דבר.

וקטורי התקפה פיזיים נחשבים כמקומיים. אלה כוללים באגים שאפשר לנצל רק על ידי תוקף שיש לו גישה פיזית למכשיר, למשל באג במסך הנעילה או באג שדורש חיבור של כבל USB. מכיוון שמקובל שהמכשירים לא יהיו נעולים כשהם מחוברים ל-USB, ההתקפות שדורשות חיבור USB הן ברמת חומרה זהה, גם אם המכשיר לא נעול וגם אם כן.

אבטחת רשתות

מערכת Android מניחה שכל הרשתות עוינות ויכולות להחדיר התקפות או לצותת לתנועה. אבטחת שכבת הקישור (למשל, הצפנת Wi-Fi) מאבטחת את התקשורת בין מכשיר לנקודת הגישה שאליה הוא מחובר, אבל היא לא עושה דבר לאבטחת הקישורים הנותרים בשרשרת בין המכשיר לבין השרתים שאיתם הוא מתקשר.

לעומת זאת, בדרך כלל פרוטוקול HTTPS מגן על כל התקשורת מקצה לקצה, על ידי הצפנת הנתונים במקור שלהם, ולאחר מכן פענוח ואימות שלהם רק אחרי שהם מגיעים ליעד הסופי. לכן, נקודות חולשה שמסכנות את אבטחת הרשת בשכבת הקישור נחשבות פחות חמורות מנקודות חולשה ב-HTTPS/TLS: הצפנת Wi-Fi בלבד לא מספיקה לרוב התקשורת באינטרנט.

אימות ביומטרי

אימות ביומטרי הוא תחום מאתגר, וגם המערכות הטובות ביותר יכולות להטעות על ידי התאמה חלקית (ראו Android Developers Blog: שיפורים במסך הנעילה ובאימות ב-Android 11). דירוגי החומרה האלה מבדילים בין שתי קטגוריות של התקפות, והם נועדו לשקף את הסיכון בפועל למשתמש הקצה.

סוג ההתקפות הראשון מאפשר לעקוף את האימות הביומטרי באופן כללי, בלי נתונים ביומטריים באיכות גבוהה מהבעלים. לדוגמה, תוקף יכול להניח חתיכת מסטיק על חיישן טביעות האצבע, והוא נותן גישה למכשיר על סמך שאריות שנשארו על החיישן. זוהי התקפה פשוטה שאפשר לבצע בכל מכשיר שרגיש לכך. לא נדרש ידע כלשהו לגבי הבעלים של המכשיר. מכיוון שהיא ניתנת להכללה ויכולה להשפיע על מספר גדול יותר של משתמשים, ההתקפה הזו מקבלת את דירוג החומרה המלא (לדוגמה, 'גבוהה' לפריצה למסך הנעילה).

הסוג השני של התקפות כולל בדרך כלל כלי להתקפת הצגה (זיוף) שמבוסס על הבעלים של המכשיר. לפעמים קל יחסית להשיג את המידע הביומטרי הזה (לדוגמה, אם תמונת הפרופיל של מישהו ברשתות החברתיות מספיקה כדי לשטות באימות ביומטרי, מעקף ביומטרי יקבל את דירוג החומרה המלא). אבל אם תוקף יצטרך לקבל נתונים ביומטריים ישירות מבעלי המכשיר (לדוגמה, סריקת אינפרה-אדום של הפנים שלו), זוהי מחסום משמעותי מספיק כדי להגביל את מספר האנשים שמושפעים מההתקפה, ולכן הערך של המאפיין יתעדכן ב-1.

SYSTEM_ALERT_WINDOW ותקיפת tapjacking

מידע על המדיניות שלנו בנושא SYSTEM_ALERT_WINDOW ועל פריצה מסוג tapjacking זמין בקטע Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen בדף Bugs with no security impact ב-BugHunter University.

אבטחה למספר משתמשים ב-Android Automotive OS

ב- Android Automotive OS נעשה שימוש במודל אבטחה עם כמה משתמשים, שונה מהגורמים האחרים. כל משתמש ב-Android מיועד לשימוש של אדם פיזי אחר. לדוגמה, אפשר להקצות משתמש אורח זמני לחבר ששואל את הרכב מבעליו. כדי להתאים לתרחישי שימוש כאלה, למשתמשים יש כברירת מחדל גישה לרכיבים הנדרשים לשימוש ברכב, כמו הגדרות Wi-Fi ורשת סלולרית.

הרכיב המושפע

צוות הפיתוח שאחראי לתיקון הבאג תלוי ברכיב שבו נמצא הבאג. יכול להיות שמדובר ברכיב ליבה של פלטפורמת Android, בדרייבר ליבה שסופק על ידי יצרן ציוד מקורי (OEM) או באחת מהאפליקציות שמותקנות מראש במכשירי Pixel.

צוות מהנדסי Android מתקן באגים בקוד AOSP. באגים ברמה נמוכה, באגים ברכיבים מסוימים או באגים שכבר ידועים לכולם עשויים להיפתר ישירות בהסתעפות הראשית של AOSP שזמינה לכולם. אחרת, הם נפתרים קודם במאגרים הפנימיים שלנו.

הרכיב הזה גם משפיע על האופן שבו משתמשים מקבלים עדכונים. כדי לתקן באג במסגרת או בליבה, צריך לעדכן את הקושחה באוויר (OTA), וכל יצרן ציוד מקורי צריך לדחוף את העדכון. באג באפליקציה או בספרייה שפורסמו ב-Google Play (למשל, Gmail,‏ Google Play Services או WebView) יכול להישלח למשתמשים ב-Android כעדכון מ-Google Play.

שליחת הודעה לשותפים

כשנקבע תיקון לנקודת חולשה באבטחה ב-AOSP בעדכון אבטחה של Android, אנחנו מודיעים לשותפי Android על פרטי הבעיה ומספקים תיקונים. רשימת הגרסאות הנתמכות בהעברה לאחור משתנה בכל גרסה חדשה של Android. יש לפנות ליצרן המכשיר כדי לקבל את רשימת המכשירים הנתמכים.

פרסום קוד ב-AOSP

אם באג האבטחה נמצא ברכיב של AOSP, התיקון מועבר אל AOSP אחרי שהעדכון OTA משוחרר למשתמשים. אפשר לשלוח תיקונים לבעיות ברמה נמוכה ישירות להסתעפות הראשית של AOSP, לפני שהתיקון יהיה זמין למכשירים באמצעות עדכון OTA.

קבלת עדכונים ל-Android

בדרך כלל, עדכונים למערכת Android מועברים למכשירים באמצעות חבילות עדכון OTA. העדכונים האלה עשויים להגיע מיצרן הציוד המקורי (OEM) שיצר את המכשיר או מהספק שמספק את השירות למכשיר. עדכוני המכשירים של Google Pixel מגיעים מצוות Google Pixel אחרי שעוברים תהליך בדיקה של אישור טכני (TA) על ידי הספק. Google גם מפרסמת תמונות מקור של Pixel שאפשר להעביר למכשירים.

עדכון שירותי Google

בנוסף לספק תיקונים לבאגים באבטחה, צוות האבטחה של Android בודק באגים באבטחה כדי לקבוע אם יש דרכים אחרות להגן על המשתמשים. לדוגמה, Google Play סורקת את כל האפליקציות ומסירה כל אפליקציה שמנסה לנצל באג אבטחה. במכשירים עם Google Play Services, יכול להיות שגם אפליקציות שהותקנו ממקורות אחרים ולא מ-Google Play יעברו את התהליך של אימות האפליקציות כדי להזהיר את המשתמשים לגבי אפליקציות שעלולות להזיק.

מקורות מידע נוספים

מידע למפתחי אפליקציות ל-Android: https://developer.android.com

מידע על אבטחה זמין באתרים של Android Open Source ו-Developers. מקומות טובים להתחיל בהם:

דוחות

לפעמים צוות האבטחה של Android מפרסם דוחות או מאמרים מקצועיים. לפרטים נוספים, ראו דוחות אבטחה.