Snyk או Semgrep: פחות התראות שווא חסכו 898 דקות בדיקה בניסוי

אם עומס האימות של התראות על ספריות פגיעות הוא השיקול המרכזי, Semgrep מציגה יתרון בניסוי הזה: בנצ׳מרק ה־SCA של Doyensec העריך 148 דקות לבדיקת ממצאי Semgrep לעומת 1,046 דקות לממצאי Snyk, פער של 898 דקות שנבע בעיקר מפחות ממצאים שנדחו בבדיקה. זהו חישוב על בסיס זמן אימות ממוצע ומספר התוצאות במדגם, ולא חיסכון שנמדד בצוות במשך שנת עבודה.

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

מה יצר את פער זמן הבדיקה

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

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

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

מדוע אי אפשר להכליל את תוצאת הניסוי

הבדיקה השתמשה במאגרי קוד פתוחים ב־GitHub שנכתבו ב־Java, ב־JavaScript, ב־Python וב־Ruby. מתוך מאגר מועמדים, החוקרים בחרו תחילה פגיעויות בתלויות ישירות לפי תוצאות ניתוח הנגישות של Semgrep: חלקן סווגו כנגישות מתוך קוד היישום, ובאחרות נמצאה הספרייה הפגיעה בלי נתיב שימוש פגיע. רק לאחר הבחירה נסרקו אותם מאגרים גם ב־Snyk וב־Dependabot. פגיעות ש־Semgrep לא העלתה בשלב הסינון הראשוני יכלה להישאר מחוץ למדגם.

גם התצורות שהושוו חשובות. עבור Semgrep נכללו בבחינה כללי נגישות בלבד, ולא כל קטגוריות ההתראה של Supply Chain. ב־Snyk הופעלה אפשרות לבדיקת נגישות, אך תיעוד היכולת שצוטט בדוח הגביל אותה אז ל־Java בתנאי שילוב מסוימים; ממצאים בשפות האחרות הסתמכו בעיקר על התאמת שם הספרייה והגרסה. הפער שנמדד משקף אפוא גם את היקף ניתוח הנגישות בתצורות שנבדקו.

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

כמה יעלה הרישוי לצוות של 5, 10 או 50 תורמים

מחירון Snyk מציג מסלול Free הכולל SAST ו־SCA, ומסלול Team לצוותים של עד 10 מפתחים שמתחיל ב־25 דולר לחודש. בהכפלה ל־12 חודשים, נקודת הפתיחה המפורסמת של Team היא 300 דולר בשנה לצוות של 5 או 10; הדף אינו מציג מחיר סופי לפי מספר המושבים בכל גודל צוות. במסלול Free מופיעה מגבלה של 5 פרויקטים, לעומת 100 ב־Team, וגם מכסות בדיקה שונות. צוות של 50 אינו מתאים ל־Team.

במסלול Enterprise של Snyk התשלום מבוסס על קרדיטים ופעילות, ולא על מחיר Team מוכפל במספר העובדים. מחירון הקרדיטים מציג דולר לקרדיט וקרדיט אחד ליום לכל תורם פעיל עבור Code או Open Source, בנפרד. כדוגמה חשבונית בלבד, אם כל 50 התורמים פעילים בכל יום במשך 365 ימים, אחת משתי היכולות תצרוך קרדיטים בערך נקוב של 18,250 דולר בשנה, ושתיהן יחד 36,500 דולר. זו אינה הצעת מחיר: היקף הפעילות, תנאי החוזה ויכולות נוספות משנים את החשבון בפועל.

מחירון Semgrep כולל Code ו־Supply Chain בחינם עד 10 תורמים ו־10 מאגרים. ב־Teams מחיר הפתיחה הוא 30 דולר לתורם לחודש עבור Code או עבור Supply Chain, וכל מוצר מתומחר בנפרד; Secrets מוצע ב־15 דולר לתורם לחודש. לצוות שעומד בתנאי החינם, עלות Code ו־Supply Chain היא אפס. בתעריף Teams המפורסם, העלות המחושבת למוצר אחד היא 1,800 דולר בשנה ל־5 תורמים, 3,600 דולר ל־10 ו־18,000 דולר ל־50. רכישת Code ו־Supply Chain יחד מכפילה את הסכומים האלה, לפני תנאים מסחריים פרטניים.

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

כיסוי SAST, SCA וסודות הוא שלוש החלטות שונות

ב־SAST נבדק הקוד שהארגון עצמו כותב. השוואה מועילה כאן עוסקת בשפות ובמסגרות העבודה של הצוות, בכללים הרלוונטיים להן ובאיכות הממצאים בבקשות שינוי. הבנצ׳מרק שתואר למעלה בחן תלויות קוד פתוח, ולכן אינו נותן שיעור התראות שווא עבור Snyk Code או Semgrep Code.

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

סריקת סודות מחפשת חשיפה של מפתחות, אסימונים ופרטי גישה, ולכן יש לבחון את זמינותה בנפרד. Semgrep מציעה את Secrets כמוצר בתשלום, ואילו Snyk מציגה Secrets במחירון הקרדיטים הארגוני ולא ברשימת היכולות של Free ו־Team. לצוות שזקוק לכל שלוש המשימות, מחיר של SAST ו־SCA לבדם אינו מייצג את עלות החבילה הדרושה לו.

מה קורה לקוד במהלך הסריקה

בסריקה מקומית או בסריקה שמתבצעת במלואה בסביבת CI באמצעות Semgrep, קוד המקור נשאר באותה סביבה, בעוד שנתוני הריצה נשלחים לשירות. במסלול Managed Scans השירות משכפל את המאגר בתחילת הסריקה ומשמיד את העותק בסופה. הפעלה של יכולות AI מסוימות יכולה להעביר לעיבוד חלק מקובץ שבו נמצא ממצא. ההבדל בין דרכי ההפעלה חשוב לארגון שמגביל העברת קוד, גם כאשר הוא משתמש באותו מוצר.

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

איזו בחירה מתאימה לצוות

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

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

קראו גם:

• Cloudflare Workers או AWS Lambda: חמש דקות ריצה משנות את הבחירה
• Printful או Printify: חיסכון של 18% עלול לקנות פחות עקביות
• GitHub או Bitbucket: 50 דקות CI בחינם משנות את הבחירה