כבלים צבעוניים מסועפים – המחשה לניתוח נתיבי קריאה בתלויות תוכנה
צילום: Antonio Avanti / Pexels

Dependabot בודקת אם הקוד באמת מגיע לחולשה

GitHub מוסיפה ל-Dependabot שכבת הקשר חדשה: לא רק האם קיימת תלות פגיעה, אלא האם הקוד של הארגון מגיע בפועל לפונקציה הפגיעה. יכולת Reachability Analysis נכנסה ל-Public Preview עבור JavaScript ו-TypeScript ומציגה לצד כל התראה נתיב קריאה אפשרי והערכת נגישות.

למה זה משנה?

צוותי פיתוח ואבטחה מקבלים לעיתים מאות התראות על חבילות פגיעות. חומרת ה-CVE לבדה אינה מספרת אם היישום משתמש בחלק הפגיע של הספרייה. התוצאה היא תור תיקונים גדול שבו התראות דחופות באמת עלולות להיבלע. הניתוח החדש נועד להוסיף סדר עדיפויות המבוסס על Call Graph של הקוד והתלויות.

GitHub מדגישה שהמדד אינו מחליף Severity, ציון EPSS, חשיפה לייצור או היכרות עם הארכיטקטורה. Reachability מראה שקיים נתיב קריאה; היא אינה מוכיחה שהחולשה ניתנת לניצול מבחוץ.

כיצד הניתוח עובד?

הסריקה רצה כ-Workflow מנוהל ב-GitHub Actions. נתונים אוצרו מראש כדי לזהות אילו פונקציות בחבילה מושפעות מכל Advisory. לאחר מכן CodeQL בונה גרף קריאות בין הקוד של הארגון לתלויות ומחפש מסלול שמגיע אל הפונקציה הפגיעה.

כל התראת Dependabot פתוחה מקבלת אחד מארבעה Verdicts:

  • Reachable: נמצא לפחות נתיב קריאה אחד מהיישום לפונקציה הפגיעה. זו התראה שראוי לקדם במהירות.
  • Potentially reachable: הניתוח לא הצליח לשלול גישה. GitHub ממליצה להתייחס אליה בדומה ל-Reachable.
  • Unreachable: הסריקה הסתיימה ולא מצאה נתיב. אפשר להוריד עדיפות, אך לא לסגור את ההתראה רק על בסיס התוצאה.
  • Reachability unavailable: לא התקבלה הכרעה, למשל עקב מגבלת תמיכה, כשל או Timeout. יש לבצע Triage רגיל.

מה נדרש כדי להשתמש ביכולת?

בשלב ה-Preview התמיכה מיועדת ל-GitHub Enterprise Cloud, לרבות סביבות עם Data Residency. היא זמינה ללא רישיון GitHub Advanced Security וללא חיוב בדקות GitHub Actions. הקוד צריך להיות JavaScript או TypeScript ולהכיל Lockfile של npm, Yarn או pnpm.

הסריקה משתמשת ב-GitHub-hosted runners בלבד; Self-hosted runners אינם נתמכים כעת. Repositories גדולים, Monorepos או פרויקטים עם Manifest files במספר תיקיות עלולים להגיע למגבלת שלוש שעות ולהחזיר תוצאה לא זמינה.

איך מפעילים?

  1. מוודאים ש-Dependabot alerts פעיל.
  2. מפעילים Reachability Analysis דרך Custom Security Configuration ברמת הארגון או הארגון העסקי, או דרך Settings > Advanced Security ב-Repository יחיד.
  3. ממתינים לסריקה הראשונה, שיכולה להימשך מכמה דקות עד כמה שעות.
  4. מסננים את רשימת ההתראות לפי Verdict ומתחילים ב-Reachable וב-Potentially reachable.
  5. משלבים את התוצאה בתהליכי SOC או AppSec באמצעות Dependabot Alerts REST API.

מה חשוב לא להסיק?

Verdict של Unreachable הוא תמונת מצב, לא תעודת ביטחון. שינוי בקוד יכול לפתוח נתיב חדש, והסריקה מתבצעת מחדש אחת ל-24 שעות כל עוד קיימות התראות פתוחות. גם Reachable אינו שווה בהכרח Exploitable: נדרשים תנאי קלט, הרשאות וחשיפה מתאימים. לכן נכון להשתמש בתוצאה כדי לתעדף, לא כדי למחוק התראות אוטומטית.

מקורות: GitHub Changelog, 28 באוקטובר 2026; GitHub Docs.

צילום: Antonio Avanti / Pexels. דף המקור. רישיון Pexels מאפשר שימוש באתר, בסושיאל ובחומר שיווקי.

דילוג לתוכן