למה הגדרת Checkmarx לא מסירה את הרעש ומעכבת את הבנייה
הגדרת Checkmarx נראית לעתים קרובות כמשימה של ערב אחד: להוסיף שלב לבנייה, להגדיר הרשאות, להמתין לדוח הראשון. הבעיה מתחילה בהרצה השנייה, כשבתוצאות צפות עשרות אלפי ממצאים, שמתוכם פגיעויות אמיתיות הן בודדות. הסורק עובד פורמלית, אבל הצוות מפסיק לפתוח את הדוחות שלו, כי לקרוא אותם לוקח יותר זמן מאשר לתקן.
את עיקר השורות מייצרות התראות שווא של הסורק על מעטפות שנכתבו ידנית, נתוני בדיקה, קוד שנוצר אוטומטית ומודולים מיושנים שגם כך עתידים להיכתב מחדש. בלי כיול חוקים וחריגים, הרעש בדוחות גדל מהר יותר מאשר נסגרים הפגמים, ולהפריד ממצא קריטי מאשפה הופך יקר יותר מזמן מהנדס עם כל מהדורה.
הסיבה השנייה — מקום הבדיקה בבנייה. כשניתוח סטטי נמצא בשלב האחרון, הוא לא חוסם דבר: הקוד כבר נבנה, הארטיפקט פורסם, והמפתח רואה את הדוח שעה לאחר שליחת השינויים ולא מקשר אותו לקומיט שלו.
סף איכות הקוד גם הוא או לא מוגדר, או נקבע באקראי. אז הבנייה נופלת על הממצא השולי הראשון, זמן הבנייה גדל בכל הרצה, והצוות לומד לעקוף את הבדיקה במקום לקרוא אותה.
אנחנו מפרקים איך זה נסגר: היכן לצמצם את היקף הניתוח, אילו חוקים להשתיק ואילו להפוך לחוסמים, ואיך לשלב את הבדיקה כך שתעזור ולא תפריע.
מה משתנה אחרי אינטגרציה נכונה: רעש, מהירות, כיסוי
בדיקת קוד ב-Checkmarx בלי כיול חוקים נותנת מבול ממצאים, שחלק ניכר מהם שגויים: התראות על נתוני בדיקה, קוד שנוצר אוטומטית ותבניות סתומות. אנחנו מכיילים מערכי חוקים לפי הסטאק בפועל של הפרויקט ומוציאים את הרעש לחריגים עם נימוק, במקום לכבות את הבדיקות לגמרי. שיעור התראות השווא יורד פי כמה, ופירוק ממצאים מתור של שבוע הופך למשימה של כמה שעות.
את המהירות נותנת לא עוצמת החומרה, אלא מקום הבדיקה בתהליך. במקום ריצה לילית על כל המאגר, אנחנו מכיילים בדיקה אינקרמנטלית של קבצים שהשתנו בכל בקשת מיזוג — משוב על שורת קוד חדשה מגיע בתוך דקות, כשהמחבר עדיין מחזיק את ההקשר בראש. סריקה מלאה נשארת כרשת ביטחון לפני שחרור, ולא כדרך היחידה לגלות משהו.
הכיסוי גדל בזכות רישום אוטומטי של מאגרים וענפים חדשים: שירות שהוקם אתמול נכנס לבדיקה בלי בקשה נפרדת. שערי איכות בצינור לא מעבירים מיזוג בלי סריקה מוצלחת — זה סוגר סוג פגיעויות שבעבר עבר ליד רק מפני שאיש לא חיבר את הפרויקט.
סוגי פגיעויות מתחילים להיראות בשלמותם: הזרקות, עבודה לא בטוחה עם קבצים ופרטי גישה, בעיות בתלויות — הכל מרוכז לדוח אחד לפי חומרה. פירוק הממצאים נעשה לפי עדיפות — קודם מה שבאמת מנוצל לרעה — ותבניות חוזרות הופכות לחוק עם דוגמת תיקון מוכנה לצוות.
מצבי סריקה: מלא, אינקרמנטלי, לפי לוח זמנים
מצב הבדיקה נבחר לא לפי «עוצמה», אלא לפי היכן שצריך את התוצאה — לפני קומיט, בבנייה או לפי שינויים מצטברים. להלן חלופות אמיתיות שבין הצוות בוחר בעת הגדרת Checkmarx.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| סריקה מלאה | ריצה ראשונית, מהדורה גדולה, החלפת מערך חוקים | איטית במאגרים גדולים, מיותרת לתיקון בקובץ אחד |
| ניתוח אינקרמנטלי | עבודה יומיומית, בדיקת שינויים בענף | רואה רק קוד שנגעו בו — פגמים ותיקים לא ייכנסו לדוח |
| בדיקה לפי לוח זמנים | ריצה לילית של פרופיל מלא, ענפי מהדורה | התוצאה מגיעה באיחור ולא חוסמת קומיט דחוף |
| מעגל מקומי | בדיקה לפני שליחה למאגר, סינון שגיאות גסות | מערך חוקים מצומצם, הסביבה שונה מסביבת הבנייה |
| בדיקה בענן בבנייה | שלב חוסם בצינור, פרופיל אחיד לכל הענפים | תלוי בזמינות השירות ובתור המשימות |
המצבים לא מחליפים זה את זה, אלא מתחברים: מעגל מקומי וניתוח אינקרמנטלי נותנים משוב מהיר, ריצה לילית לפי לוח זמנים סוגרת חוב מצטבר, ובדיקה בענן מחזיקה פרופיל חוקים אחיד ולא מעבירה ממצא קריטי הלאה מהבנייה.
תנאי להשוואה — פרופיל חוקים זהה וקו בסיס משותף בכל המצבים, אחרת הדוחות סותרים זה את זה והערות שנסגרו מקומית צפות מחדש. ספי זמן וחוקי חסימה נבחרים כך שריצה אינקרמנטלית תיכנס לדקות, והמלאה לא תתחרה על משאבים עם הבנייה.
איך עוברת הגדרת Checkmarx: שלבי העבודה
הגדרת Checkmarx היא לא פריסה של סורק, אלא רצף של עבודות הנדסיות: ממיפוי החוקים הקיימים ועד מסירת נוהל פירוק ממצאים לצוות. הסדר כאן עקרוני — אם מיד מפעילים פרופיל מלא, שטף ההתראות יחסום את צינור הבנייה, והמפתחים יפסיקו לפתוח דוחות. כל שלב הבא נשען על תוצאה מוסכמת של השלב הקודם.
- ביקורת חוקים קיימים. בודקים אילו פרופילים מופעלים, אילו ממצאים באמת נסגרו ואילו התעלמו מהם בשקט, והיכן הסריקה בכלל לא רצה.
- פרויקט פיילוט. לוקחים שירות או מאגר אחד, מריצים פרופיל מלא ורושמים את משך הסריקה, נפח הדוח ושיעור ההתראות שהצוות מכיר כמשמעותיות.
- אינטגרציה בצינור הבנייה. מפרידים מצבים: מערך חוקים קצר לבקשת מיזוג, מלא — לבנייה לילית. קובעים סף חומרה שבו הבנייה נעצרת.
- קו בסיס לממצאים. לקוד ישן רושמים את הרשימה הנוכחית כ-baseline: הוא לא חוסם את הבנייה, אבל נשאר גלוי ומצטמצם בהדרגה. ממצאים חדשים נכנסים תחת הסף הכללי.
- כיול חוקים. מסירים רעש: מוציאים קבצי בדיקה וקבצים שנוצרו אוטומטית, מתקנים שאילתות שנותנות התראות שווא בסטאק שלנו, מאחדים כפילויות.
- קבלת חוקים והעברת נוהל. ריצה על מערך מסומן שבו ידוע מראש היכן יש פגיעות והיכן אין: מחשבים שיעור התראות נכונות ורעש שיורי. לפי התוצאות קובעים למי מגיעים ממצאים, תוך כמה זמן מפרקים אותם ומי מאשר חריגים.
מה הלקוח מקבל לידיים: פרופילים, חוקים, נהלים
בסיום הלקוח מקבל לא דוח סריקה, אלא מערך קונפיגורציות שחי במאגר לצד הקוד ומועבר בין פרויקטים. פרופילים וחוקים מנוהלים בגרסאות יחד עם השירות — התוצאה משוחזרת בכל ענף, ולא תלויה במי שהריץ את הבדיקה ידנית.
- פרופילי סריקה לכל סוג שירות: אפליקציית ווב, ממשק ציבורי, ספרייה פנימית — עם מערך שאילתות משלו וסף התראה משלו, כדי שהמערך המלא לא ירוץ בכל קומיט.
- קובצי חריגים עם נימוק: לכל שאילתה שהושתקה מצוינים נתיב, קטגוריה וסיבה. חריג בלי הערה לא עובר אישור ולא נכנס לענף.
- נוהל פירוק ממצאים: רמות חומרה, זמני סגירה לכל רמה, סדר אישור התראת שווא עם ציון מי ובאיזה בסיס אישר אותה.
- תפקידי גישה: מפתח רואה ממצאים של השירות שלו, האחראי על אבטחה — סיכום לפי פרויקט, שינויים בפרופילים וחריגים נעשים רק דרך אישור.
- תיעוד בדיקות: מה בדיוק נסרק, אילו חריגים פעילים כעת, מי אישר אותם, היכן לראות היסטוריית שינויים בהגדרות.
- צ'ק-ליסט לחיבור שירות חדש — כדי שההרחבה לא תפר את הספים ולא תפתח גישה לנתונים מיותרים.
הגדרת Checkmarx נמסרת יחד עם הארטיפקטים האלה והדרכה קצרה לצוות: המהנדסים מתקנים פרופילים בעצמם, מוסיפים חריגים וקוראים דוחות, בלי לפנות אלינו על כל ממצא.
מקרה בוחן: הפחתנו רעש והאצנו בדיקות בצינור הבנייה
צוות מוצר עם כמה עשרות מאגרים הפעיל Checkmarx כברירת מחדל: מערך חוקים מלא, כל הענפים, בדיקה על כל שינוי. אחרי חודש אף אחד כבר לא פתח דוח של כמה אלפי ממצאים במלואו — המפתחים פירקו את המובן מאליו, והשאר הצטבר ברשימה כללית. הבדיקה נמשכה כל כך הרבה זמן שהפסיקו לשים אותה כשלב חוסם בבנייה.
מה שינינו
פירקנו את הממצאים המצטברים לפי נתונים היסטוריים וחילקנו את החוקים לשלוש קבוצות: מדויקים (נכנסים לחסימה), כאלה שדורשים פירוק ידני ורועשים. את הרועשים הוצאנו מהפרופיל הראשי למערך נדחה, ולאחרים העלינו את סף הביטחון והוספנו חריגים לקוד שנוצר אוטומטית ולתיקיות בדיקות. את הסריקה העברנו לשינויים בענף, וריצה מלאה נשארה רק לענפי מהדורה.
מה קרה
| מדד | לפני | אחרי |
|---|---|---|
| שיעור התראות שווא | כ-60% | מתחת ל-15% |
| זמן בדיקת שינוי | עשרות דקות | דקות בודדות |
| ממצאים באיחור | גדלו בכל ספרינט | הצטמצמו פי כמה |
המפתח שוב רואה רשימה קצרה שבה כמעט כל שורה דורשת פעולה, ולכן הפירוק הפסיק להידחות. השלב החוסם חזר לצינור הבנייה, ולענפי מהדורה נשמר פרופיל מלא — אפשר לחזור למערך החוקים הקודם בתיקון של פרופיל אחד, בלי לבנות מחדש את האינטגרציה.
במה ניתוח קוד שונה מבדיקת תלויות וסודות
שלוש הבדיקות האלה לעיתים קרובות שמות באותה שורה, למרות שכל אחת רואה שכבה אחרת של האפליקציה. ניתוח קוד מפרק את מה שאנחנו כתבנו בעצמנו, בדיקת תלויות — קוד זר שמחובר, ואיתור סודות — מחרוזות שאסור שיהיו במאגר.
ניתוח קוד עונה על השאלה «האם יש חור בלוגיקה שלנו». המנתח בונה זרימת נתונים מנקודת כניסה ועד פעולה מסוכנת ומראה מקומות שבהם קלט משתמש מגיע לשאילתה, לקובץ או לפקודת מערכת בלי בדיקה.
כאן גם פועל Checkmarx: עיקר המאמץ הולך לכיול חוקים וחריגים, אחרת הדוח טובע בהתראות על קוד בדיקה וקוד שנוצר אוטומטית.
בדיקת תלויות פותרת משימה אחרת: משווה מניפסטים וגרסאות ספריות נעולות מול מאגרי פגיעויות ידועות ומראה את השרשרת שדרכה רכיב פגיע נכנס לבנייה. התוצאה כאן היא לא «קוד רע», אלא רשימת עדכונים: התיקון לוקח דקות, אבל דורש בדיקת תאימות והרצה חוזרת של בדיקות.
איתור סודות עובד לפי לוגיקה שלישית: תבניות של מפתחות וטוקנים, אנטרופיה חריגה של מחרוזות, מעבר נפרד על היסטוריית הקומיטים. הוא תופס את מה שאי אפשר לסגור בתיקון קוד — מפתח שנחשף צריך לבטל ולהחליף, ואת העקבות בהיסטוריה לשכתב.
השיטות לא מחליפות זו את זו, אלא מכסות סוגי סיכון שונים, ולכן הבחירה מתחילה ממה שכרגע לא מכוסה. סדר ההטמעה בדרך כלל כזה: קודם סודות — תוצאה מהירה עם מינימום התראות שווא, אחר כך תלויות, ואז ניתוח קוד עם חשיפה הדרגתית של חוקים.
ספקות נפוצים בעת שילוב סורק בצינור הבנייה
לפני תחילת האינטגרציה צוותים שואלים את אותו מערך שאלות: האם הסורק יאט את הבנייה, איך יתנהגו החוקים אחרי עדכון, מי אחראי לממצאים שנויים במחלוקת. להלן התשובות שאנחנו נותנים בפירוק משימה לפי Checkmarx.
הסורק יאט את הבנייה, והתחילו לעקוף אותה?
בודקים רק קבצים שהשתנו, וניתוח מלא עובר ללוח זמנים מחוץ לשעות העבודה הפעילות. את הבנייה חוסם רק ממצא חדש בחומרה גבוהה, ואת עלויות הנלוות מחזיקים בתוך כמה אחוזים מזמן הבנייה.
עדכון חוקים יפיל קוד שכבר התקבל?
חוקים חדשים מפעילים במצב תצפית ומשווים לקו הבסיס הנעול — מהדורות לא נופלות מכך שמערך הבדיקות התרחב. ספים וחריגים נבחנים מחדש בכל עדכון.
מי מחליט שממצא שנוי במחלוקת?
בעל הקוד: הממצא או מתוקן, או עובר לחריג עם נימוק ומועד בחינה מחדש. כיול שאילתות וחוקי סימון מסיר את עיקר התראות השווא — נשארות בודדות למהדורה.
יש לנו כמה צוותים — המדיניות משותפת או לכל אחד משלו?
סף החומרה המינימלי אחיד לכולם, אחרת סיכומים בין צוותים לא ניתנים להשוואה. פרופילי חוקים נעשים לפי הסטאק והבגרות, וממצאים מחולקים לפי אחראים על תיקייה.
קוד ישן עם אלפי ממצאים — להפעיל בדיקה מיד?
כן, אבל בלי חסימה: את המצב הנוכחי רושמים כנקודת ייחוס. את החוב מפרקים בגלים במודולים שממילא מתקנים — ממצאים חדשים לא מצטברים.
נדון במשימה ונחזור עם הערכה ותוכנית עבודה
לדון בהערכה בלי נתונים על המעגל — זה לנקוב במספרים באקראי. היקף העבודה כיול ניתוח סטטי תלוי במספר הפרויקטים, באופן שבו הסריקה משולבת בבנייה, ובכמה חוקים באמת משתמשים. לכן הצעד הראשון הוא פירוק המשימה, ולא הערכה לפי העין.
מה צריך מכם ולמה נחזור:
- מכם — מפת המעגל: רשימת המאגרים והענפים שלפיהם מתבצעת הבנייה, והנקודות שבהן הסריקה כבר משולבת.
- מכם — הגדרות נוכחיות: אילו מערכי חוקים ומדיניות מופעלים, מה הושתק ידנית והיכן הוגדרו חריגים.
- מכם — דוח אמיתי אחד: ייצוא של הריצה האחרונה בפרויקט הגדול ביותר — ממנו רואים את שיעור הרעש והמקומות הבעייתיים.
- מאיתנו — תוכנית הטמעה: שלבים, סדר חיבור פרויקטים, נקודות בקרה ואחראים משני הצדדים.
- מאיתנו — חוקים לסינון רעש: רשימת חריגים מוסכמת, הסף שבו הבנייה נעצרת, והסדר לבחינה מחדש שלו.
- מאיתנו — סכמת תמיכה: איך מפרקים התראות חדשות אחרי ההפעלה, מי מעדכן חוקים ומה נכנס לדוח להנהלה.
תארו את המשימה בשתיים-שלוש פסקאות — אילו פרויקטים, במה נבנים, מה כבר מוגדר מ-Checkmarx. אחרי אבחון המעגל נחזור עם הערכת עבודה ותוכנית הטמעה לפי שלבים, עם ציון מה נעשה בכוחות עצמנו והיכן צריך גישה או החלטה מצדכם.