לחברות שמובילות באבטחת יישומים יש אנשי אבטחה שרוצים ומסוגלים להנהיג

שילוב גורמים בעולמות של dev, ops ואבטחת מידע, יוצר חלון הזדמנויות להטמעת אבטחת המידע לתוך מחזור פיתוח התוכנה (SDLC), באופן שיביא לשינוי משמעותי. עם זאת, צוותי אבטחת המידע הם אלה שצריכים להוביל את משימת ה-DevSecOps, אחרת השינוי לא יצלח.

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

שינוי פרדיגמה? תעזבו אותי עם הבאזוורדס

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

המעבר לפיתוח אג'ילי היה שינוי תהליך שהביא לעליית ה-DevOps כשינוי תרבותי נלווה. כאשר צוותי DevOps הפכו ליותר ויותר מושרשים בתרבות הארגונית, הם התחילו לבנות ערוצים של אינטגרציה רציפה והרצה רציפה (CI/CD) כדרך לביצוע אוטומציה של תהליכים במטרה להאיץ פיתוח, עדכון והרצה של תוכנה.

זה מביא אותנו פחות או יותר להווה. מאחר שערוצי CI/CD כבר בנויים ועובדים אוטומטית, קשה להתעלם מההזדמנות ש-DevOps מייצר לחדשנות באבטחה. כל הרעיון של DevOpsו-CI/CD הוא לשחרר קוד טוב יותר ומהר יותר. כאשר רוב החברות פועלות בסביבה עסקית רווית פרצות אבטחה, הונאות, התקפות סייבר וכשלי אבטחת סייבר אחרים, מה ההיגיון ביצירת קוד עם פחות באגים, אם הוא עמוס בפרצות אבטחה ונהלי אבטחה גרועים? התשובה היא שאין הרבה היגיון בכך – ומכאן צמיחת ה-DevSecOps.

DevSecOps: העתקת האבטחה "שמאלה"

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

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

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

באופן אירוני, יש מומחי אבטחה שמאמינים כי החסמים הגדולים ביותר ל-DevSecOps הם אנשי האבטחה אשר "מעולם לא עבדו בפיתוח תוכנה ולא מבינים כיצד צוות פיתוח מספק תוכנה". בעוד זו רק נקודת מבט אחת, שמעתי אותה יותר מפעם אחת לאורך הקריירה שלי כמפתח. כמי שעבד שנים עם רגל אחת בעולם ה-App Dev והרגל השנייה באבטחה, אני מודע היטב לכמה כדאי יהיה ליצור קרקע משותפת שהיא כה דרושה בין dev ,ops ואבטחה.

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