אבי קרנס, מנכ”לית ActiveState – סדרת ראיונות

אבי קרנס היא מנכ”לית ActiveState ובעלת ניסיון של יותר מ-25 שנים בבנייה והרחבה של ארגוני תוכנה אנטרפרייז. היא שירתה בעבר כסמנכ”לית טכנולוגיה של Puppet, שם סייעה להוביל מהפכה אסטרטגית שהסתיימה ברכישת החברה על ידי Perforce Software. בתחילת הקריירה שלה, היא הייתה מנכ”לית קרן Cloud Foundry, והובילה את הצמיחה של אחד מהאקוסיסטמים הגדולים ביותר של פלטפורמת ענן קוד פתוח. אבי מכהנת כיום כחברה בדירקטוריון של Akka (לשעבר Lightbend). היא ידועה בעזרתה לחברות לתרגם שינויים משמעותיים בענן, קוד פתוח ו-AI לאסטרטגיית מוצר וצמיחת אנטרפרייז ברורה.

ActiveState היא חברת תוכנה קנדית שנוסדה ב-1997, המספקת כלים ופלטפורמות אנטרפרייז לבנייה, ניהול ואבטחה של תוכנה קוד פתוח. ההצעה המרכזית שלה, פלטפורמת ActiveState, עוזרת לצוותים של פיתוח, DevOps ואבטחה לאוטומציה של ניהול תלויות, גילוי ותיקון פגיעויות, ויצירת סביבות פיתוח בטוחות וניתנות לשחזור במספר שפות תכנות כמו Python, Perl ו-Tcl. באמצעות מתן רכיבים של קוד פתוח מוכן ומאומת, ואינטגרציה שלהם לתוך תהליכים קיימים, ActiveState מטרתה להפחית סיכוני אבטחה בשרשרת האספקה של תוכנה, תוך שיפרות פרודוקטיביות של מפתחים ואיצון אספקת יישומים.

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

המשותף לאורך הקריירה שלי היה פעולה בנקודת החיתוך בין קהילה ותשתית ברגעים שבהם התעשייה עושה החלטות שירכבו לשנים. Cloud Foundry היה הרגע הזה עבור יישומים יישומי ענן. Puppet היה הרגע הזה עבור ניהול קונפיגורציה ושלבים הראשונים של מה שאנו קוראים היום DevSecOps. ActiveState הוא הרגע הזה עבור ממשל קוד פתוח.

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

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

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

ActiveState מעמידה עצמה כשכבה קריטית באבטחת שרשרת האספקה של תוכנה בתקופה שבה AI מאיץ יצירת קוד. כיצד AI משנה באופן מהותי את פרופיל הסיכון של תוכנה קוד פתוח?

פיתוח מסייע AI שובר הנחה בסיסית שכל השרשרת של כלים לממשל קוד פתוח נבנתה עליה: שמפתח בחר במכוון לכלול תלות.

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

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

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

זה מגיע לדירקטוריון בגלל שהסביבה הרגולטורית השתנתה את המבנה של אחריות. חוק העמידות הסייברית של האיחוד האירופי, דרישות הגילוי של SEC, הנחיות “Secure by Design” של CISA: מסגרות אלה משנות את השאלה מ”האם הייתה לך סורק?” ל”האם אתה יכול להוכיח שהתוכנה שלך הייתה בטוחה בנקודת המוצא?” אלו הן שאלות שונות, ורוב הארגונים לא יכולים לענות על השנייה.

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

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

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

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

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

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

הנהגת ארגונים דרך גלים טכנולוגיים רבים. כיצד המעבר הנוכחי המונע על ידי AI השווה למעברים קודמים כמו ענן ו-DevOps במונחים של מהירות ושיבוש?

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

מה ששונה במעבר הנוכחי הוא המהירות והבלתי נראות. אימוץ ענן היה נראה. ידעת כאשר הארגון שלך היגר עומסי עבודה מ- on prem לענן. DevOps היה נראה: ארגונים היו מארגנים מחדש צוותים, משנים צינורות פריסה, וכותבים מחדש תהליכים. כלים לפיתוח AI מאומצים על ידי מפתח באופן פרטי, קריאת כלי באופן פרטי, והסיכון מצטבר בבסיס הקוד לפני שרוב הארגונים רשמו שהוחלטה החלטת ממשל.

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

חברות רבות מתקשות להפוך אימוץ קוד פתוח למודל עסקי בר קיימא. מה מפריד בין חברות שמצליחות לאלו שנכשלות?

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

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

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

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

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

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