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

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

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

גוגל מסבירה את הסיבות שלה:

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

"מקובל שתוכנית תלויה במישרין או בעקיפין באלפי חבילות וספריות. לדוגמה, Kubernetes תלוי כעת בסביבות 1000 חבילות. קוד פתוח משתמש כנראה בתלות ולא בתוכנה קניינית ומגיע ממגוון רחב יותר של ספקים; מספר הגופים העצמאיים שאפשר לסמוך עליהם יכול להיות גדול מאוד. זה מקשה מאוד על הבנת השימוש בקוד פתוח במוצרים ואילו נקודות תורפה עשויות להיות רלוונטיות. אין גם שום אחריות שמה שנבנה יתאים לקוד המקור.

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

דע את נקודות התורפה של התוכנה שלך

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

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

הימנע מהוספת פגיעות חדשות

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

הנה, גוגל מציעה להתמקד בשני היבטים ספציפיים:

• הבן את הסיכונים כאשר מחליטים על תלות חדשה
• שפר תהליכי פיתוח תוכנה קריטיים

תיקון או הסרת נקודות תורפה

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

זה גם מזכיר: 

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

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

מקור: https://security.googleblog.com