CERT-In (צוות תגובת החירום הממוחשבים ההודי), תחת פיקודו של MeitY (משרד האלקטרוניקה וטכנולוגיית המידע), הרחיב בהתמדה את תפקידו כרשות הלאומית לאבטחת סייבר מאז ייעודו במסגרת חוק תיקון טכנולוגיית המידע משנת 2008.
בשנת 2024, פרסמה CERT-In את ההנחיות הייעודיות הראשונות שלה בנושא SBOM ( Software רשימת חומרים), המגדיר אלמנטים מינימליים, פורמטים ודרישות יישום.
רק שנה לאחר מכן, ביולי 2025, גרסה 2.0 הרחיבה משמעותית את ההיקף, והרחיבה את הכיסוי ל-SBOM, QBOM, CBOM, AIBOM ו-HBOM, ובכך ביססה עוד יותר את שרשראות האספקה של תוכנה מאובטחות כאסטרטגיית חוסן לאומית מרכזית.
עבור מנהלי מערכות מידע (CIO) ומנהלי מערכות מידע (CISO), הנחיות אלו נושאות השלכות תפעוליות, פיננסיות ורגולטוריות. ארגונים חייבים להיות מוכנים להדגים נהלי SBOM מוכנים לביקורת, להתאים ספקים ושותפים לדרישות התאימות, ולאמץ אוטומציה לניהול SBOM בקנה מידה גדול.
מאמר זה מספק מפת דרכים שלב אחר שלב להשגת תאימות להנחיות CERT-In SBOM, המכסה את ההיקף, הסטנדרטים הטכניים, בחירת הספקים ושיטות עבודה מומלצות עבור חברות הודיות וארגונים גלובליים הפועלים בהודו.
- הנחיות CERT-In SBOM: היקף, תחולה ודרישות עיקריות
- אֵיך OPSWAT SBOM מסייע בדרישות CERT-In
- יישור Software רכיבים עם תאימות CERT-In SBOM
- פורמטים ותקנים טכניים מקובלים של SBOM תחת CERT-In
- כיצד להעריך ולבחור ספקי תאימות SBOM
- שיטות עבודה מומלצות ליישום SBOM חלק
- אוטומציה, ציות והגנה: ה- OPSWAT גישה לניהול SBOM
- MetaDefender Software Supply Chain™
- שאלות נפוצות
- שיקולים ספציפיים למגזר: מוסדות פיננסיים, Supply Chain ותשתיות קריטיות
- מה הלאה? היערכות להנחיות Cert-In SBOM היא חיונית
הנחיות CERT-In SBOM: היקף, תחולה ודרישות עיקריות
מה זה CERT-In ומדוע הוא פרסם הנחיות SBOM?
CERT-In היא סוכנות הסייבר הלאומית של הודו. הנחיות ה-SBOM שלה נועדו לחזק את אבטחת שרשרת האספקה, לשפר את הנראות של רכיבי תוכנה ולהבטיח תגובות מהירות וסטנדרטיות לפגיעויות.
מה זה CERT-In ומדוע הוא פרסם הנחיות SBOM?
תאימות חלה על ממשלה, מגזר ציבורי, שירותים חיוניים ויצואני תוכנה, כמו גם על מפתחים, אינטגרטורים ומשווקים לאורך מחזור חיי התוכנה.
Core אלמנטים של SBOM לפי הנחיות CERT-In
על פי ההנחיות, SBOM חייבים לכלול נתונים כגון:
- שם הרכיב, גרסה, ספק ורישיון
- תלויות ומוצא
- פגיעויות וסטטוס תיקון
- תאריכי סוף חיים, הגבלות שימוש וקריטיות
- מזהים ייחודיים, סכומי בדיקה ופרטי מחבר
על ידי דרישת האלמנטים המינימליים הללו, CERT-In מבטיח ש-SBOMs יהיו ניתנים לפעולה, קריאים על ידי מכונה ומוכנים לביקורת.
אֵיך OPSWAT SBOM מסייע בדרישות CERT-In
OPSWAT SBOM מסייע באוטומציה ואיסוף שדות נתונים של CERT-In SBOM, כדי לספק נראות ושקיפות בתחומים העיקריים, החל מפרטי רכיבי תוכנה, שקיפות וסיכונים, ועד רישוי ושימוש.
Software פרטי רכיב
- שם רכיב: שם רכיב התוכנה או הספרייה.
- גרסת רכיב: מספר גרסה או מזהה של הרכיב.
- ספק רכיבים: ישות המספקת את הרכיב (ספק, צד שלישי או קוד פתוח).
- מקור הרכיב: מקור הרכיב (קנייני, קוד פתוח או צד שלישי).
- מזהה ייחודי: קוד מובחן למעקב אחר הרכיב בין גרסאות ובעלות.
- מחבר נתוני SBOM: ישות האחראית על יצירת ערך ה-SBOM.
- חותמת זמן: תאריך ושעה בה נרשמה רשומת ה-SBOM.
Software שקיפות וסיכונים
- תלויות ברכיבים: רכיבים או ספריות אחרים שעליהם מסתמך הרכיב הזה.
- פגיעויות: בעיות אבטחה ידועות הקשורות לרכיב, עם חומרה והפניות ל-CVE.
- סטטוס תיקון: זמינות עדכון או תיקון נוכחיים עבור פגיעויות.
- סכומי בדיקה או גיבוב (Hash): ערכים קריפטוגרפיים לאימות שלמות הקובץ.
- מאפיין הניתן להרצה: האם ניתן להפעיל את הרכיב.
- מאפיין ארכיון: האם הרכיב ארוז כקובץ ארכיון.
- תאריך יציאה: התאריך בו הרכיב יצא לראשונה.
רישוי ושימוש
- רישיון רכיב: סוג הרישיון ותנאי השימוש ברכיב.
- הגבלות שימוש: מגבלות חוקיות או רגולטוריות על השימוש ברכיבים.
יישור Software רכיבים עם תאימות CERT-In SBOM
השגת תאימות לתקן CERT-In היא מסע מדורג הדורש תיאום בין צוותי פיתוח, אבטחה, תפעול ותאימות. לכל בעל עניין תפקיד ביצירה, תחזוקה ושיתוף של SBOMs בנקודות שונות במחזור חיי התוכנה.
הטבלה שלהלן, המכילה תוכן ודוגמאות מההנחיות הטכניות של CERT-In, ממחישה כיצד תחומי האחריות של SBOM תואמים לרכיבי תוכנה נפוצים:
| רְכִיב/ Software | דוּגמָה | רמת SBOM | מחבר SBOM | מַדוּעַ? |
|---|---|---|---|---|
| יישום ראשי | אפליקציית מנתח נתונים | SBOM ברמת היישום | נוצר על ידי צוות פיתוח המוצר | SBOM מלא המסופק עם הבקשה ללקוח או לרגולטור |
| מַפְתֵחַ Software רכיב [מסד נתונים, מסגרת] | פוסטגר-SQL | SBOM ברמה העליונה | פותח באופן פנימי אם הספק לא סיפק SBOM | מבטיח מעקב אחר רכיבים קריטיים |
| פלטפורמה/תוכנה [למשל, שרת אינטרנט, סביבת זמן ריצה] | אפאצ'י טומקט Server | משלוח SBOM | מסופק על ידי הפלטפורמה/הספק | משותף בעת הרכש; משלב רכיבים המסופקים על ידי הספק |
| ספריות/ערכות SDK של צד שלישי | ערכת פיתוח תוכנה של Postfix ו-Twilio | SBOM טרנזיטיבי | נוצר על ידי ספק במעלה הזרם או באופן פנימי אם לא זמין | מכסה תלויות עקיפות ושירותים חיצוניים |
לאחר הגדרת תפקידים ואחריות, ארגונים יכולים לעבור לשלבים המעשיים של תאימות. מפת דרכים מדורגת מסייעת לבנות בגרות בקרב אנשים, תהליכים וטכנולוגיה.
1. ביצוע הערכת מוכנות וניתוח פערים
זהה נהלים נוכחיים עבור מלאי תוכנה, מעקב אחר פגיעויות ו-SBOM המסופקים על ידי ספקים. מיפוי אלה מול שדות הנתונים והפורמטים הנדרשים של CERT-In.
2. בניית מדיניות ומבנה ממשל פנימי של SBOM
הגדירו תפקידים ברורים עבור צוותי מפתחים, תפעול IT, רכש, אבטחה ותאימות. ממשל מבטיח ש-SBOMs נוצרים, מתוחזקים ומשותפים באופן עקבי ברחבי הארגון.
3. בחירה ויישום של כלי יצירת SBOM
אוטומציה היא קריטית. כלים חייבים:
- צור SBOMs עבור כל מהדורה, תיקון או עדכון חדשים
- שילוב עם צינורות DevOps, מאגרי מקורות ורישום מכולות
- פלט בפורמטים CycloneDX ו-SPDX לצורך יישור רגולטורי
4. שילוב זרימות עבודה של SBOM ב-SDLC וברכש
הטמעת יצירת SBOM בכל שלב ב-SDLC:
- SBOM עיצובי: רכיבים מתוכננים
- מקור SBOM: תלויות פיתוח
- בניית SBOM: במהלך קומפילציה
- ניתוח SBOM: בדיקה לאחר בנייה
- SBOM פרוס: סביבה מותקנת
- SBOM בזמן ריצה: ניטור רכיבים פעילים
חוזי רכש צריכים לחייב אספקת SBOM מכל הספקים.
5. שמירה על מוכנות מתמשכת לציות ולביקורת
קבע עדכוני SBOM שוטפים, שלב עם ייעוץ לגבי פגיעויות כמו VEX (Vulnerability Exploitability eXchange) ו-CSAF, והבטח אחסון ושיתוף מאובטחים באמצעות הצפנה, HTTPS וחתימות דיגיטליות.
רוצים ללמוד כיצד למנף SBOM עבור אסטרטגיית האבטחה שלכם?
פורמטים ותקנים טכניים מקובלים של SBOM תחת CERT-In
CycloneDX ו-SPDX: הסטנדרטים המקובלים
CERT-In מזהה את CycloneDX ו-SPDX כפורמטים העיקריים הניתנים לקריאה על ידי מכונה עבור אוטומציה של SBOM.
- CycloneDX: קל משקל, ממוקד אבטחה, מותאם לניהול פגיעויות
- SPDX: ממוקד רישיון, מאומץ באופן נרחב לתיעוד תאימות
כיצד להעריך ולבחור ספקי או פתרונות תאימות CERT-In SBOM
בחירת הספק או הפתרון הנכון היא קריטית הן לתאימות והן ליעילות תפעולית.
קריטריונים מרכזיים להערכת ספקי תאימות CERT-In SBOM
- תמיכה ב-SPDX וב-CycloneDX
- אינטגרציה עם צינורות DevOps וזרימות עבודה של CI/CD
- יכולת לייצר מספר רמות SBOM (תכנון, בנייה, פריסה, זמן ריצה)
- דיווח מוכן לביקורת ומנגנוני שיתוף מאובטחים
שאלות לשאול ספקים פוטנציאליים בנוגע ליישור CERT-In
בחירת השותפים הנכונים היא קריטית לא פחות מבניית תהליכי SBOM פנימיים. מנהלי מערכות מידע ומנהלי רכש צריכים לכלול התאמה ל-CERT-In כחלק מרשימות ה-RFP ובדיקת הנאותות שלהם. שאלות מפתח שיש לשאול כוללות:
- האם אתם מספקים SBOMs בפורמטים שאושרו על ידי CERT-In (SPDX, CycloneDX)?
- באיזו תדירות עדכון ה-SBOMs שלכם - רק בשחרור, או באופן רציף?
- איזו אוטומציה אתם מציעים ליצירת SBOM, אימות ושיתוף מאובטח?
- כיצד אוכפים הפצת SBOM מאובטחת (למשל, הצפנה, RBAC, חתימות דיגיטליות)?
- האם הפתרון שלכם משתלב עם צינורות DevOps, מסדי נתונים של פגיעויות וייעוץ CERT-In?
- כיצד אתם תומכים בביקורות תאימות ובדיווח רגולטורי שוטף?
שאילת שאלות אלו מראש מסייעת להבטיח שספקים לא רק עומדים בתקנות על הנייר, אלא גם מסוגלים לקיים שיטות עבודה של SBOM התואמות את ההנחיות המתפתחות של CERT-In.
רשימת בדיקה לבחירת ספקים וקליטתם
- תומך בשדות ובפורמטים הנדרשים של CERT-In
- אוטומציה של יצירה, מעקב ועדכונים
- מספק בקרות גישה מבוססות תפקידים ושיתוף מאובטח
- אימוץ מוכח בתעשיות מוסדרות
שיטות עבודה מומלצות ליישום SBOM חלק
אסטרטגיות מוכחות עבור ארגונים גדולים
- התחילו עם זרימות עבודה בסיסיות והרחיבו את הבגרות לאורך זמן
- חובת מסירת SBOM בכל חוזי הרכש
- אימוץ גישת shift-left על ידי שילוב יצירת SBOM מוקדם ב-SDLC
- הכשרת צוות בנוגע למודעות ל-SBOM ולדרישות רגולטוריות
טעויות נפוצות וכיצד להימנע מהן
אפילו יוזמות SBOM בעלות כוונות טובות עלולות להיכשל אם ארגונים ניגשים אליהן בצורה שטחית. CERT-In מדגישה כי SBOM חייבים להיות מדויקים, מקיפים ומתעדכנים באופן שוטף. הנה כמה מהמכשולים הנפוצים ביותר וכיצד להימנע מהם:
| טעות נפוצה | הֶסבֵּר | איך להימנע מזה |
|---|---|---|
| התייחסות ל-SBOM כאל דוח סטטי | ארגונים רבים יוצרים SBOM בעת השחרור ואינם מעדכנים אותו כלל. דבר זה משאיר אותם עיוורים לפגיעויות שהוצגו על ידי תיקונים, עדכונים או תלויות חדשות. | התייחסו ל-SBOM כאל מלאי חי. בצע עדכונים אוטומטיים דרך צינור ה-CI/CD שלכם כך שכל גרסה או גרסה חדשה תרענן את נתוני ה-SBOM. |
| אי הכללת תלויות טרנזיטיביות | התעלמות מרכיבים עקיפים, כגון ספריות קוד פתוח הנמשכות על ידי תלויות אחרות, יוצרת נקודות עיוורות מסוכנות שתוקפים מנצלים. | השתמש בכלי יצירת SBOM אוטומטיים שממפים באופן רקורסיבי את כל התלות הישירות והטרנזיטיביות, ומבטיחים כיסוי מלא לכל אורך שרשרת האספקה של התוכנה שלך. |
| הסתמכות על יצירה ידנית ללא אוטומציה | קומפילציה ידנית של SBOM גוזלת זמן, מועדת לטעויות ואינה בת קיימא בקנה מידה ארגוני. היא גם מגדילה את הסיכון לפורמטים לא עקביים. | שלב אוטומציה וסטנדרטיזציה. אימץ כלים שמייצרים SBOMs בפורמטים שאושרו על ידי CERT-In כמו SPDX ו-CycloneDX, ואכוף אימות לפני השחרור. |
על ידי הימנעות מטעויות אלו והטמעת פרקטיקות SBOM בתהליכי עבודה יומיומיים של פיתוח, ארגונים יכולים להפוך את הציות לתקנות ליתרון אסטרטגי, להפחית סיכונים תוך עמידה בדרישות CERT-In.
הכנה לביקורות
תחזוקת מאגרי SBOM מלאים, תיעוד של נוהלי ממשל והתאמתם לתבניות ביקורת של CERT-In.
היערכות לעתיד מפני שינויים רגולטוריים
מפת הדרכים של CERT-In כבר מרמזת על דרישות BOM רחבות יותר (חומרה, בינה מלאכותית וענן). ארגונים המאמצים כלים גמישים וניתנים להרחבה יהיו בעמדה הטובה ביותר להסתגל.
אוטומציה, ציות והגנה: ה- OPSWAT גישה לניהול SBOM
OPSWAT SBOM
OPSWAT SBOM מעצים מפתחים על ידי אספקת מלאי מדויק של רכיבי תוכנה בקוד המקור ובקונטיינרים. הישארו צעד אחד קדימה מול תוקפים, חשפו איומים וזיהו פגיעויות מבלי לפגוע במהירות הפיתוח.
SBOM עבור Software חבילות וחפצים
מאפשר לצוותי פיתוח תוכנה לזהות, לתעדף ולטפל בפגיעויות אבטחה ובבעיות רישוי של תלויות קוד פתוח.
SBOM עבור Software חבילות וחפצים
מאפשר לצוותי פיתוח תוכנה לזהות, לתעדף ולטפל בפגיעויות אבטחה ובבעיות רישוי של תלויות קוד פתוח.
SBOM עבור Container תמונות
ניתוח תמונות של מכולות ויצירת SBOM עבור שם החבילה, פרטי הגרסה ופגיעויות אפשריות.
MetaDefender Software Supply Chain ™
עברו מעבר לתאימות SBOM וטפלו במתקפות שרשרת אספקה מתקדמות ומתפתחות של תוכנה.
OPSWAT Supply Chain Software MetaDefender מספקת נראות מורחבת והגנה איתנה מפני סיכוני שרשרת האספקה. בעזרת טכנולוגיות זיהוי ומניעת איומים מבוססות אמון אפס, מחזור חיי פיתוח התוכנה (SDLC) שלך מוגן מפני תוכנות זדוניות ופגיעויות, מחזק את אבטחת היישומים ואת עמידה בתאימות.
זיהוי תוכנות זדוניות בקוד
השילוב של יותר מ-30 מנועי אנטי-וירוס מגביר את שיעורי הזיהוי ומונע ביעילות מתוכנות זדוניות להדביק תחנות עבודה, קונטיינרים או קוד מקור.
זיהוי סודות מקודדים
DLPTM פרואקטיבי מזהה אישורים כגון סיסמאות, סודות, טוקנים, API מפתחות, או מידע רגיש אחר שנותר בקוד המקור.
Secure מכולות נגד Supply Chain התקפות
הערך והערך כל תוכנה זדונית, פגיעויות או סיכונים פוטנציאליים אחרים הקיימים מתחת לכל שכבה של תמונת מכולה.
אינטגרציות פשוטות
בין אם הצוות שלכם משתמש במאגרי קוד מקור, רישומי מכולות, שירותים בינאריים או שילוב של כלים, MetaDefender Software Supply Chain מספק אינטגרציות מקוריות עם פלטפורמות פופולריות לאבטחה ברחבי SDLC שלך.
שאלות נפוצות
אילו עונשים חלים על אי עמידה בהנחיות CERT-In SBOM?
ביקורות רגולטוריות ומגבלות אפשריות על חוזים עם ממשלה ושירותים חיוניים. אי עמידה בהנחיות CERT-In SBOM עלולה להותיר ארגונים פגיעים לדליפות נתונים, מה שעלול להוביל לקנסות גבוהים.
באיזו תדירות יש לעדכן את SBOMs?
בכל מהדורה חדשה, עדכון, תיקון או שינוי ספק.
האם ניתן לכלול רכיבים בקוד פתוח ורכיבים של צד שלישי?
כן. שקיפות מלאה בכל התלויות - ישירות וטרנזיטיביות - היא חובה.
האם עסקים קטנים יותר פטורים?
סטארט-אפים מחוץ למגזרים מוסדרים עשויים לקבל הקלה מוגבלת, אך אימוץ מומלץ מאוד.
כיצד CERT-In מתיישב עם סטנדרטים גלובליים?
הגישה של הודו משקפת מסגרות בינלאומיות כמו NIST וחוק חוסן הסייבר של האיחוד האירופי , ומבטיחה תאימות חוצת גבולות.
כיצד יש לטפל בגילוי פגיעויות?
באמצעות התראות VEX ו-CSAF, בשילוב עם התראות CERT-In ומערכות SBOM פנימיות.
איזה תפקיד ממלאת אוטומציה?
אוטומציה מאפשרת תאימות רציפה, מפחיתה טעויות אנוש ומבטיחה מדרגיות בסביבות IT היברידיות.
שיקולים ספציפיים למגזר: מוסדות פיננסיים, Supply Chain ותשתיות קריטיות
המגזר הפיננסי
בנקים ו-NBFCs חייבים להתאים את נוהלי SBOM למנדטי אבטחת הסייבר של הבנק המרכזי של אוסטרליה (RBI), עם דרישות ביקורת מחמירות יותר לטיפול במידע רגיש.
Supply Chain
ספקים חייבים לספק SBOMs כחלק מחוזים. ארגונים צריכים לתחזק מלאי SBOM פנימי וחיצוני לשקיפות וניהול סיכונים.
תשתית קריטית
מגזרים כמו תקשורת, ביטחון ואנרגיה מתמודדים עם חפיפות רגולטוריות. שיטות SBOM חייבות להשתלב עם מסגרות רחבות יותר לחוסן המערכת ולביטחון הלאומי.
מה הלאה? היערכות להנחיות Cert-In SBOM היא חיונית
הנחיות CERT-In SBOM מסמנות נקודת מפנה עבור ארגונים הודיים. מה שהחל כהתמקדות צרה ב-SBOMs התרחב כעת למסגרת מקיפה לנראות שרשרת אספקה וניהול סיכונים של תוכנה.
OPSWAT טכנולוגיית SBOM הולכת מעבר לתאימות, מטמיעה נראות של שרשרת האספקה ברחבי ה-SDLC ומשלבת אבטחה רב-שכבתית עם מאגרי קוד, רישומי מכולות וצינורות DevOps.
גלה כיצד OPSWAT יכול לעזור לארגון שלך לפשט את תאימות CERT-In SBOM ולאבטח את שרשרת האספקה של התוכנה שלך.
