הגדרת יצירת Software Bill of Materials (SBOM)

SBOM: היכן נשבר מעקב התלויות בתהליך הבנייה

הבנייה עוברת בירוק, האימג' נשלח לרג'יסטרי, והריליס יוצא לפרודקשן. כעבור מספר ימים מגיעה התראה על פגיעוּת בתלות טרנזיטיבית — ואין במה לשחזר את ההרכב המדויק של אותה הפצה: המניפסטים נדרסו על ידי הבנייה הבאה, קובץ נעילת הגרסאות לא נכנס לארטיפקט, והגרסאות נמשכו לפי טווח. השאלה »האם יש אצלנו רכיב פגיע דווקא בגרסה הזו?« נשארת בלי תשובה.

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

השורש הוא ש-SBOM נולד לא במקום שבו הוא צריך להיוולד. הוא נוצר בשלב נפרד בדיעבד, לפי קובץ התלויות ומחוץ להקשר הבנייה: לרשימה נכנסות תלויות ישירות, אבל לא מה שבאמת נכנס לשכבות האימג' — חבילות טרנזיטיביות של מנהל המערכת, ספריות ספק שהועתקו לארטיפקט.

בלי עיגון למזהה בלתי-משתנה של האימג', המסמך מתאר »בערך את הבנייה הזו« ולא הפצה קונקרטית, ומעקב הרכיבים מפסיק להיות ניתן לאימות.

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

התועלת המעשית של יצירת SBOM באופן סדיר

יצירה סדירה של SBOM הופכת את רשימת התלויות מפיסת נייר חד-פעמית לזרם נתונים. המחולל Anchore Syft מופעל בצינור הבנייה בכל בנייה של הענף הראשי, קורא את עץ התלויות מהמניפסטים של מנהלי החבילות וממערכת הקבצים של האימג', ומאחסן את התוצאה כמסמך בפורמט CycloneDX לצד הארטיפקט עצמו.

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

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

ניתוח האירוע מתקצר משעות של תיאום »איפה זה בכלל בשימוש« לדקות: מיד רואים מה לתקן ומה אפשר לא לגעת בו.

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

בקרת התלויות נשענת על השוואה בין שני SBOM-ים: ההפרש מראה מה באמת השתנה בעת עדכון בסיס האימג' או גרסת הספרייה. תלויות טרנזיטיביות שלא נלקחו בחשבון, שנמשכות פנימה כמה רמות, מפסיקות להיות הפתעה — סוג הכשל »אחרי הריליס התברר שהגיע משהו מיותר« יוצא מהפרקטיקה.

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

דרכים ליצירת ההרכב: השוואת גישות

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

פורמטי תיאור ההרכב — CycloneDX או SPDX — נבחרים בנפרד מהשיטה: חשובה התאימות למערכות שיקראו את הנתונים הללו.

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

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

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

כיצד אנו מגדירים יצירת SBOM: שלבי העבודה

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

1. אינבנטריזציה של רכיבים. עוברים על המאגרים, מתעדים שפות, מנהלי תלויות, קיומן של ספריות טרנזיטיביות וספריות ספק, ורכיבים בתוך האימג'ים. בפלט — רשימת שירותים עם ציון היכן היצירה מכסה הכול אוטומטית והיכן נדרשת השלמה ידנית.
2. סכמת הזרימות. קובעים באיזה רגע נוצר המסמך — בזמן בניית הארטיפקט או בזמן הוצאת האימג', היכן הוא נשמר וכיצד הוא נקשר לבנייה קונקרטית, כך שלפי מספר הריליס אפשר למצוא בדיוק את הרשימה שלו.
3. הטמעה בבנייה. היצירה הופכת לשלב בצינור: אם המסמך לא נוצר, הבנייה נעצרת. כך הרשימה מפסיקה להיות ארטיפקט אופציונלי שעושים »כשמבקשים«.
4. הגדרת כללים. בוחרים פורמט — SPDX או CycloneDX, קובעים את הרכב השדות, את עומק פירוק התלויות ואת ההתנהגות עבור רכיבים בלי מטא-נתונים: מסמנים במפורש, ולא מוחקים בשקט.
5. בדיקת התוצאה. משווים את ההרכב מהמסמך לתוכן בפועל של הארטיפקט, בודקים גרסאות, רישיונות וכפילויות. פערים הם או שגיאה של המחולל, או עקבות של עריכות ידניות בבנייה.
6. מסירת התיעוד. מוסרים את הסכמה, תיאור הכללים, הנחיות למפתח ואת סדר העדכון בעת שינוי תלויות, כדי שההגדרה לא תיפרד מהבנייה בפועל כבר בשינוי הגדול הראשון.

הרכב ההפצה: קונפיגורציות, סכמות ונוהלים

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

מה בדיוק אנו מוסרים:

• קונפיגורציות של קו הבנייה — משימות ותבניות שלבים שבהם מופעלת יצירת הרשימה, עם הסברים לכל פרמטר.
• סכמות תהליכים — המסלול משינוי קוד ועד פרסום SBOM: נקודות בנייה, בדיקה ומסירת ארטיפקט, עם תפקידים ואחראים.
• מדיניות בקרת הרכב — כללים לעצירת הבנייה כאשר קיים רכיב עם פגיעוּת ידועה או רישיון אסור.
• מדיניות גישה — מטריצת הרשאות לרשימות, הגדרת חתימות ואימות מהימנות הארטיפקטים.
• תבניות דוחות — ייצוא בפורמטים תקניים לתיאור הרכב (SPDX, CycloneDX) עם מסננים לפי חומרה.
• הנחיות לצוות — כיצד להוציא ריליס, לבטל כלל ולנתח פער בהרכב.
• נוהל עדכון — תדירות הבחינה מחדש של הרשימה האסורה וסדר הפעולות בעת שינוי תלויות.

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

מקרה בוחן: כיצד התקצר ניתוח האירועים לאחר ההטמעה

מה היה לפני האוטומציה

אירוע של פגיעוּת בספרייה טרנזיטיבית נותח ידנית: המהנדס הרים יומני בנייה, השווה מניפסטים של תלויות וקבצי נעילת גרסאות בכל שירות. על קביעת הרשימה המלאה של הרכיבים הנגועים הולכו בין 4 ל-6 שעות, ובחלק מהבניות התמונה נותרה חלקית — היה צריך לבנות מחדש שירותים »ליתר ביטחון«. כשמדובר בעשרות מאגרים, זה נמתח ליום עבודה שלם ועיכב את הוצאת התיקון.

מה שינו

את יצירת ה-SBOM הפעילו ישירות בשלב הבנייה: מסמך הרכב הרכיבים נוצר אוטומטית ונקשר למזהה בלתי-משתנה של האימג', ולא לשם התג.

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

בנפרד סגרו את סוגיית איכות הנתונים: אימג' נחשב להוצאה רק אם קיים SBOM, ולכן שיעור הבניות עם מסמך הרכב הגיע ל-100%.

מדדים אחרי

זמן הזיהוי של הרכיבים הנגועים התקצר מ-4–6 שעות ל-15–25 דקות, וזו רשימה מלאה ולא מדגם של כמה שירותים. מספר הבניות מחדש »ליתר ביטחון« ירד כמעט לאפס: רואים באילו אימג'ים הרכיב קיים ובאילו לא. ניתוח האירוע כבר אינו תלוי במי מהמהנדסים שזוכר את ההיסטוריה של מאגר מסוים.

במה נבדל דוח חד-פעמי על ההרכב מיצירה סדירה של SBOM?

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

העדכניות היא הפער המרכזי. הצילום עונה על השאלה »מה היה במערכת ברגע הביקורת«, ואחרי כמה ריליסים מאבד קשר עם המציאות: נשארות בו תלויות שהוסרו וחסרות החדשות. כשמגיעה התראה על פגיעוּת, צריך להבין תוך דקות אילו גרסאות פעילות מכילות אותה — לפי צילום זה דורש מעבר חדש.

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

הסכמה העובדת היא לשלב: ביקורת חד-פעמית למערכות מורשות שכבר פועלות ואינן נבנות מחדש, ויצירה סדירה — לכל מה שיוצא מכאן והלאה. כללי החתימה והאחסון של SBOM הופכים בדיקה כזו לניתנת לשחזור, במקום להיות תלויה במי ומתי נזכר לאסוף דוח.

ספקות טכניים: שאלות נפוצות בנוגע להטמעה

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

מה עם רכיבים שהותקנו ביד?

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

כיצד לוודא שהרשימה מלאה?

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

כבר יש סורק ואחסון — לוותר עליהם?

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

נדון במשימה: מה לשלוח לצורך הערכה ותוכנית

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

מה לתאר לפי סעיפים:

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

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