Code Security Tools: Best-of-Breed vs Best-of-Suite

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

הדילמה הזו קיימת גם בעולם כלי ה- Code Security שצמודים לפיתוח ואפליקציות,
ונוגעת לאנשי הפיתוח, אנשי ה- Security / AppSec , אנשי ה- IT  ומי שמתחזק את הכלים האלו.

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

אז איך כדאי לבחור ולהכריע?

אשתף מנסיוני וממה שאני רואה משיחות עם לקוחות ואנשי AppSec "בשטח".

ראשית, כדי להמחיש צדדים לכאן ולכאן, אדגים זאת מתחום יומיומי שכולנו מכירים (ואז נחזור לעניין כלי ה- security).

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

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

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

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

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

ואיך זה קשור לעניין כלי Code / App Security ?

אותו הדבר כאשר רוכשים כלי פיתוח (או כלי עזר לתהליכי פיתוח) –

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

מנסיוני (בעבודה מול לקוחות רבים) בבחירת כלי ALM / DevOps / DevSecOps ראיתי שיש נושאים מסויימים שעבורם אפשר לקחת פלטורפמה אחת ולהתפשר, ויש כאלה שרצוי שלא להתפשר – וזה נכון בפרט להיבטי אבטחת קוד.

ארכז כאן כמה נקודות חשובות המסבירות מדוע בנושא זה של Code Security עדיף לא להתפשר – חלקן גם נאמר לי ע"י אחרים (ומהווה סוג של "חכמת המונים"):

1. בתחום הסקיוריטי עדיף לא להתפשר, כי עלולים להיות חשופים לסיכונים רבים, ולשלם על זה ביוקר בדיעבד – אם יתגלה שיש פירצה או וקטור זיהוי/הגנה שנמצא רק במוצר שהוא הכי טוב ולא בפלטפורמה / סוויטה שקנינו. 
   זה פשוט מסוכן מדי, ועלות הנזק עלולה להיות גבוהה פי כמה מהחסכון או הנוחות הראשונית.
   
2. עדיף גם לא להתפשר אם הפתרון המוצע לא יהיה נוח למפתחים (שהם משתמשי הקצה) – כי זה ישפיע לרעה על העבודה שלהם ועל הביצועים שלהם (והעלות שלהם, כידוע, מאוד יקרה, ומוכפלת בכמות המפתחים שיש בארגון)
   
3. חשוב לזכור שמערכת כזו תלווה אתכם שנים – בין 3 ל- 5 שנים לפחות (בממוצע),
   ויהיה קשה לסגת מהחלטה לא טובה או להחליף את הפלטפורמה (משיקולי עלויות ועוד) – לכן כדאי לשקול בכובד ראש.
   
4. יצרני פלטפורמה / Suite נוטים להזניח לאחר זמן-מה איזורים מסויימים במוצר ולא לספר על זה (הכוונה לאיזורים שהפכו פחות רווחיים או פחות אסטרטגים עבורם).
   זה יכול להיות פתח ל- vulnerabilities חדשים שלא יתגלו (כי היצרן לא עדכן את האיזור המסויים הזה בפלטפורמה)
   
5. אסכם במילותיו של לקוח, שאמר – "אני מחפש את היצרן שיתן לי את הפתרון הכי טוב בתחום שלו – ואני יודע שהוא גם יתאמץ תמיד להיות ב- TOP של איזור זה ולשפר את זה תמידית, בכדי לשמור על עליונותו"

ומה לגבי החיבור בין הכלים השונים?

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

• חיבור לתהליכי CI/CD אפשרי ורצוי היום בקלות דרך כל כלי CI מודרני
  (לדוגמא Jenkins, GitLab CI, GitHub actions), וממילא העבודה הזו תצטרך להעשות גם אם בוחרים פלטפורמה.
• ניתן גם לשאוב נתונים מכל הכלים המודרנים ולרכז הכל בכלי BI או כלי איסוף מידע
  (למשל Splunk, New Relic, Grafana, ,PowerBI ,  Elastic + Kibana ועוד)

אנו בחברת ALM-Toolbox מציעים מגוון כלים ופתרונות, ושואפים להציע ללקוחותינו את הכלים הטובים ביותר בשוק לסוגם בהתאם לצרכים ולתקציב. בין הכלים שאנו מציעים:
SonarQube ל- code security ולסריקת קוד (SAST ) ;
Fossa ל- SCA  ;
AppScan  ל- DAST , IAST ו- API Security .
הצע הפתרונות המלא שלנו לפיתוח קוד מאובטח נמצא כאן.