Application Security

מהו SBOM?

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

מהו SBOM (רשימת חומרים של תוכנה)?

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

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

מדוע SBOM חשוב באבטחת סייבר

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

SBOM עוזר לצוות הפיתוח ל:

  • לזהות פגיעויות מוקדם יותר על ידי מיפוי רכיבים מושפעים
  • לשפר את ההתאמה לתקנים כמו NIST, ISO, או Executive Order 14028 בארה”ב
  • לשפר את אבטחת שרשרת האספקה על ידי הבטחת שקיפות בהרכב התוכנה
  • לבנות אמון עם לקוחות ושותפים על ידי הצגת הרכיבים הכלולים

מרכיבים מרכזיים של SBOM

SBOM נכון בדרך כלל כולל:

  • שם רכיב (למשל, lodash)
  • גרסה (למשל, 4.17.21)
  • מידע על רישיון (קוד פתוח או קנייני)
  • ספק (פרויקט או ספק שמתחזק אותו)
  • קשרים (כיצד רכיבים תלויים זה בזה)

דוגמה בפועל: פריצת Apache Struts (Equifax, 2017)

בשנת 2017 תוקף ניצל פגיעות קריטית במסגרת Apache Struts (CVE-2017-5638), אשר שימשה ביישומי האינטרנט של Equifax (סוכנות דיווח אשראי צרכנית רב-לאומית אמריקאית). התיקון לפגיעות זו היה זמין, אך Equifax לא הצליחה ליישם אותו בזמן.

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

אם היה קיים SBOM, Equifax הייתה יכולה במהירות:

  • לזהות שהיישומים שלהם משתמשים בגרסה הפגיעה של Apache Struts
  • לתעדף תיקון מיד עם גילוי הפגיעות
  • לצמצם את הזמן שהיה לתוקפים לנצל את החולשה

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

מונחים קשורים

Ready to validate what matters?

Ready to validate what matters?

Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.

Qualification

Check whether AI Swarm Pentest fits your environment.

Share the minimum context. We will review the scope and tell you the next commercial step.

Before submitting — verify you fit

Teams with fewer than 50 developers: start a 14-day Trial instead of booking a demo. Start a 14-day Trial →

0 / 280

No commitment. If you don't fit, we'll tell you.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorised target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)