יום שבת, 1 בספטמבר 2018

349 WhiteSource

פודקאסט מספר 349 - אורי ורן מארחים בשלהי החופש הגדול את אסף סביץ’ לשיחה על WhiteSource וניהול השימוש בקוד פתוח.


  • רגע לפני - כנס רברסים 2018 מעבר לפינה (בימי עבודה בארץ זה קרוב לחד-ספרתי) -  8-9 באוקטובר, אוניברסיטת תל אביב. בואו.
  • אסף - בן 28, עובד ב WhiteSource כשנתיים וחצי (לפני כן שני סטארטאפים, אלביט).
  • ב - WhiteSource מתעסקים בכמה תחומים -
    • ראשית - One Stop Shop לעינייני קוד פתוח (Open Source) - על מנת לפשט עבור הלקוחות את השימוש בקוד פתוח.
      • 70-80% מהקוד שחברות מוציאות היום מבוסס על קוד פתוח, וכל תהליכי הבדיקות והאוטומציה מתבצעים על ה 20-30% הנותרים. זה עלול להיות בעייתי.
    • רן - המודלים המוכרים הם לדוגמא של RedHat, שמספקים שירותי תמיכה וערך מוסף לבסיס הקוד הפתוח (מודולים נוספים למשל); לרוב מדובר במוצר אחד ספציפי (או כמה), עבור ארגונים מאוד גדולים.
    • ב WhiteSource אולי לא יפתרו באגים ספציפיים בקוד הפתוח, אבל כן יכולים להתריע על סיכונים, על אי-הלימה עם מדיניות החברה, להנגיש מידע רלוונטי על הסכמי השימוש וגם על באגים ידועים בקוד הרלוונטי. 
      • הקהילה משתפת המון מידע מהמון מקורות, ויש צורך לעשות סדר ולהתאים את מה שרלוונטי - לאפשר מיקוד ביתרונות השימוש בקוד פתוח, ולהתעסק פחות בחסרונות.
    • זו יכולה להיות התרעה על פרצות אבטחה ידועות, אבל לפעמים גם פשוט לדעת שיצאה גרסה חדשה שיכולה להיות רלוונטית זה לא משהו שפשוט לשים לב אליו לב עבור הרבה מוצרים.
  • מאיפה הכל התחיל? 
    • שלושת היזמים של החברה התחילו בחברה שנקראת Eurekify (שנרכשה ע”י CA), וכחלק מתהליכי הרכישה ובדיקת הנאותות (Due Diligence) היו צריכים להסביר מאיפה הגיע כל דבר, כולל הקוד הפתוח. 
    • הם גילו שזה לא כל כך פשוט, ושאין פתרון קיים מספיק טוב (Black Duck הייתה קיימת, לא הרבה מעבר), והחליטו לפתוח חברה שתיתן מענה. שנה לאחר מכן הוקמה WhiteSource.
    • החברה גדלה, אסף הגיע לפני שנתיים כעובד ה -13, היום סדר גודל של כ-100 עובדים.
    • מתחרים - השימוש בקוד פתוח הולך וצובר תאוצה, עם בערך 7 חברות עיקריות בשוק - WhiteSource ו - Black Duck מובילות.
      • רן - כשהחברה קטנה, לא מאוד מסובך (יחסית) להבין באילו ספריות קוד פתוח נעשה שימוש. העניין מסתבך כשהחברה גדלה והמעקב הופך למורכב יותר - גם חלקים שנמצאים בקוד אבל לא משתמשים בהם בפועל, וגם חלקים שלא בההכרח שייכים לקוד הראשי (אנליסטים, תמיכה וכו’). 
      • החשיפה לקוד פתוח (והסיכון הנלווה אליה) הולכים וגדלים, ולרוב שמים לב לזה בכמה מקרים - הצעת רכישה, השקעה(וה - Due Diligence הנלווה אליה), או התקפה שמנצלת חולשה של אחר מרכיבי הקוד הפתוח.
      • בהרבה מקרים, חבילה אחת מביאה איתה הרבה דברים “בבטן” - לדוגמא: NPM (שהזכרנו ב Bumpers האחרון), כשאפשר להתקין חבילה אחת ולקבל איתה עוד מאות חבילות נלוות.
        • עוד מאות אלפי שורות קוד שהחברה לא באמת צריכה (לעיתים לא מודעת לקיומן) והגיעו “בחינם” - אבל מביאות איתן עוד “משקל” מסויים שצריך לדעת להעריך ולתכנן (ולהיערך מבחינת אבטחת מידע).
  • אז איך המוצר עובד?
    • ה - Use Case המרכזי הוא של כניסה בשלב ה - Build (אם כי אפשר בכל שלב): ל - WhiteSource יש עשרות Plug-Ins לכל שפה ו-Build Servers עיקריים. מוסיפים עוד שלב.
    • האם ה-Build של היום עומד בהגדרת החברה? האם נוסף סיכון כלשהו? זו עוד סיבה אפשרית לנפילה (WhiteSource Fail).
      • אם מצאנו נפילה ב-Build זה טוב (לא הגיע ללקוח), אבל עדיף למצוא קודם ולחסוך את העבודה שהושקעה --> כל מפתחת יכולה לסרוק ברגע שהיא הכניסה את הספריה, עוד טרם השימוש.
          • יש לחברה תוסף לכרום (Chrome) שמנגיש מידע על כל ספריה באופן כללי, כבר בשלב החיפוש והסריקה.
      • הבדיקה מתבצעת גם ברמת הרישיון עצמו (MIT אולי בסדר, GPL כבר עשוי להיות בעייתי להרבה לקוחות, וכו’)
      • עניין מדיניות הרשיון היא לא רק ברמה החוקית - יש אספקט של חשיפה (Vulnerability), התראות על גרסאות חדשות (לדוגמא: לא חייב להכשיל את ה-Build, אבל אני כן רוצה לדעת שיש גרסא חדשה) ועוד.
  • אז זה מה שהמוצר עושה - איך המוצר עובד?
      • יש צוות שעוסק ב - Research, ובודק מספר מאגרים ומעדכן כל הזמן. מעבר למידע עצמו, יש גם מנגנון של מתן פתרונות אפשריים למקרה הספציפי.
      • כיום בשלבי פיתוח מתקדמים של מוצר בשם Effective Usage Analysis (שם זמני) - מוצר שסורק את הקוד ברמת המפתח, ויודע להתריע במקרה שיש קשר ישר (עקבה, trace) לרגישות (Vulnerability) הספציפית. 
        • יכול להיות שהקוד כולל ספרייה בעייתית, אבל בקוד עצמו אין קריאה בפועל לספרייה.
      • בשפות סטטיות די מובן איך זה עובד. בשפות דינאמיות (Ruby, JavaScript, Python) זה נראה כמו אתגר יותר משמעותי.
        • עבור Java כבר יש פתרון, ב - JavaScript כבר קרובים מאוד. כמות השפות הנתמכות הולכת וגדלה, וזה אכן אתגר. 
        • מעבר לכך, העובדה שניתן להצביע על הקישור ישיר למקום ספציפי בקוד שעלול להיות בעייתי מאפשרת להפעיל שיקול דעת (בהינתן שיודעים איפה המקור).
        • רעיון לפיצ’ר נוסף - Run-time Analysis, שבודק האם יש קריאה בפועל (בזמן ריצה). סביר שתיהיה לזה עלות (ביצועים).
  • מי הם הלקוחות הטיפוסיים? 
      • לרוב חברות בינוניות-גדולות (לחברות קטנות כנראה יש עדיין צרות גדולות יותר)
      • חברה שיש לה הרבה מוצרים, הרבה מפתחים, הרבה פרוייקטים - והניהול הופך מאוד מורכב
      • קשר מול CTO או CISO שאחראים על הטמעת המוצר, ואז הוא נגיש לכל אחד בחברה.
  • האם יש יחסים כלשהם עם “יצרני” הקוד הפתוח?
    • כיום פחות, אולי בעתיד.
    • חשוב לשים לב שזה שקוד עולה ל-GitHub לא הופך אותו ל-Open Source - צריך שיהיה
      •  זמין לכולם (Publicly available)
      • חינם
      • תנאי שימוש מוגדרים
    • ברגע שהוגדרו התנאים, כולם חייבים לעמוד בהם - ראינו מקרים שזה לא קורה.
  • נניח שאני היום מפתח בחברה קטנה, שעדיין לא הגיעה לשלב שמצדיק השקעה במוצר כמו של WhiteSource - מה כן כדאי לי כבר לעשות?
    • אם אני כותב קוד ומשתמש בקוד פתוח (שכנראה טוב ממה שאני כותב בעצמי, ולו מכיוון שעבר הרבה יותר ידיים ועיניים) - חשוב לעקוב אחרי מה שאני משתמש בו, אילו ספריות באות יחד עם הספרייה הספציפית, מה הן התלויות, וכו’.
      • יש כלים חינמיים (דוגמא - NPM) שמאפשרים לייצר עץ-תלויות (Dependencies Tree) כולל רישיונות. זה אמנם לא מחקר מעמיק, אבל עדיין מאפשר את ההבנה הראשונית, ולפעמים (כמו עם NPM) כולל גם חשיפות (vulnerabilities) ידועות.
  • חזרה ל-WhiteSource
    • החברה מונה כ - 100 עובדים
    • הוקמה וגדלה בישראל, כיום ~70% בישראל ויש עוד סניפים, בעיקר במזרח ארה”ב - בוסטון וניו-יורק - אבל גם בחוף המערבי, באנגליה ועוד.
    • הפיתוח נעשה ברובו בישראל (כיום משרדים במגדלי בסר בגבול רמת-גן / בני ברק, מעבר קרוב למגדל השחר בתל אביב / גבעתיים).
    • האתגרים רק הולכים וגדלים.
    • החברה היום אחרי סבב השקעות שני (גיוס אחרון לפני כשנה)
      • 10~ מיליון דולר, 80% מקרן השקעות, 20% ממיקרוסופט
    • יש הרבה שיתופי פעולה עם מיקרוסופט, שמשקיעה הרבה בשנים האחרונות בקוד פתוח (ורכשה את GitHub)
    • הרבה חלקים מהמוצר הם קוד פתוח בפני עצמם.
  • עוד דבר לפני סיום - כיום ~7% מהספריות בעולם מוגדרות כרגישות (vulnerable)
    • כשמסתכלים רק על ה-100 המובילות, זה כבר עולה ל ~32%.
    • זה לא בהכרח מצביע על ספריות יותר פגיעות, אלא (גם) על זה שמחפשים בהן יותר.
    • צריך להיזהר :-)
הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

אין תגובות:

פרסום תגובה