פודקאסט מספר 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 כבר קרובים מאוד. כמות השפות הנתמכות הולכת וגדלה, וזה אכן אתגר. מעב