OPSWAT של Secure מסגרת SDLC: מחויבות לחוסן וביטחון הגנה לעומק

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

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

OPSWAT של Secure מסגרת SDLC מגדירה מתודולוגיות מובנות ועקרונות אבטחה המנחים פיתוח תוכנה מאובטח. 

OPSWAT עוקב אחר האג'ייל Software מחזור חיי פיתוח. על מנת לעמוד באופן מלא בדרישות לקוחותינו, אימצנו את Secure מסגרת SDLC לדרישות הרגולטוריות ולתקנים הבינלאומיים. גישה זו מחזקת את מחויבותנו לשיפור מתמיד וחוסן בנוף אבטחת סייבר מתפתח.

OPSWAT של Secure מסגרת SDLC בנויה על NIST SP 800-218 SSDF ( Secure Software מסגרת הפיתוח), תוך הבטחת אבטחה מובנית, מדידה ויישום עקבי בכל שלבי תהליך פיתוח התוכנה.  

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

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

ככל שתקנות אבטחת הסייבר ממשיכות להתפתח, OPSWAT נשאר מחויב ליישר קו עם Secure מסגרת SDLC עם דרישות רגולטוריות גלובליות, החל מחוק חוסן הסייבר של האיחוד האירופי והנחיית NIS2. על ידי התאמה יזומה לתקנים מתפתחים, OPSWAT מבטיח ש Secure SDLC נשאר מקיף, תואם ועמיד בנוף רגולטורי מורכב יותר ויותר.

שמירה על אבטחת מידע איתנה היא קריטית הן לשלמות התפעולית והן לעמידה בתקנות. OPSWAT של Secure מסגרת SDLC משלבת את עקרונות ISMS (מערכת ניהול אבטחת מידע) של ISO 27001, ומבטיחה שבקרות אבטחה, אסטרטגיות ניהול סיכונים ואמצעי תאימות ישולבו בצורה חלקה בתפעול מוצרי הענן שלנו. 

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

ראה פרטים נוספים על תאימות והסמכות .

כדי להבטיח את הסטנדרטים הגבוהים ביותר של איכות תוכנה, OPSWAT של Secure מסגרת SDLC משולבת בתקן ISO 9001 (מערכת ניהול איכות). מערכת ה-QMS קובעת בקרות איכות מבוקרות עבור ניהול, ניהול שינויים ותהליכים חוצי-פונקציות, התומכת בהגדרה, תכנון, פיתוח, ייצור ותחזוקה של המוצרים והתמיכה, ומתרחבת מעבר למחקר ופיתוח לתחומים כגון מכירות, תמיכת לקוחות, טכנולוגיית מידע ומשאבי אנוש.  

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

ראה פרטים נוספים על תאימות והסמכות .

מודל הבשלות של אבטחת Software (SAMM) של OWASP הוא מסגרת מקיפה שנועדה לסייע לארגונים להעריך, לגבש וליישם אסטרטגיות אבטחת תוכנה יעילות במסגרת ה-SDLC הקיים שלהם.

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

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

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

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

ניהול בכיר - מנהל מוצר ראשי (CPO)

מנהל המוצר הראשי (CPO) אחראי על פיקוח אסטרטגי ואכיפה של Secure תוכנית SDLC בכל צוותי המוצר, כמו גם תוכניות מחקר ופיתוח (R&D) אחרות כגון תוכנית אבטחת איכות (QA) ותוכנית חוויית משתמש (UX), המבטיחות גישה מגובשת לפיתוח תוכנה מאובטח, איכותי וממוקד משתמש.

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

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

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

סדרי עדיפויות אסטרטגיים

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

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

OPSWAT מחויבת לשיפור מתמיד של Secure תוכנית SDLC באמצעות מדידת ביצועים מובנית, הערכות בגרות ועדכונים שוטפים כדי להבטיח יעילות אבטחה מתמשכת.  

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

כדי למדוד ביעילות את מצב אבטחת האפליקציה, OPSWAT מעריכה צוותים באמצעות מדדים מובנים. בגרות אבטחת המוצר מוערכת לכל צוות על סמך מסגרת SAMM, המספקת מדד כמותי להתקדמות האבטחה. בנוסף, מוצרים עוברים הערכת תאימות ASVS כדי להבטיח עמידה בדרישות אימות האבטחה. עמידה ב- Secure תהליך SDLC מנוטר ומוערך מקרוב, והשגת יעדי ה-KPI מבוססת על ראיות, מה שמבטיח שמצב האבטחה ושיפורי האבטחה ניתנים למדידה וניתנים ליישום. כל צוותי המוצר נדרשים לעמוד ביעדי בגרות אבטחה כחלק מהערכת הביצועים השנתית שלהם. 

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

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

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

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

ה Secure תהליך SDLC מפורט בסעיפים הבאים:

• Secure תכנון והערכת סיכונים
• Secure יישום, בנייה ופריסה
• בדיקות ואימות אבטחת יישומים
• Secure משחרר
• Secure תפעול ותחזוקה

ה Secure תהליך SDLC הוא תהליך ברמה גבוהה, צוותים יכולים ליישם אותו בצורה מותאמת אישית מורחבת, בתנאי שאבטחת התהליך תישמר באותה רמה מינימלית. סטייה מה- Secure יש לתעד ולאשר את תהליך SDLC.

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

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

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

אבטחה משולבת בכל שלב של מחזור חיי הפיתוח. באחריותם של מומחי האבטחה לזכור את הציפיות של Secure תהליך SDLC וייצוגם בצוותים שלהם. 

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

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

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

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

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

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

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

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

במהלך היישום Secure שיטות עבודה מומלצות לקידוד, Secure יש ליישם סקירת קוד וגילוי מוקדם של פגמי אבטחה. על הצוותים לדבוק בדרישות Supply Chain מדיניות אבטחה (כולל קליטת ספקים ונושאי תוכנה בקוד פתוח), מדיניות שימוש בבינה מלאכותית ומדיניות טיפול בדוגמאות תוכנות זדוניות. במהלך הבנייה והפריסה Secure נדרשות בנייה ופריסה עם שימוש מרכזי בצינור CI/CD והפרדת תפקידים.

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

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

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

ב- C++ , מומלץ לזהות ולטפל בשגיאות הקצאת זיכרון, למנוע גלישות מאגר באמצעות בדיקת גבולות ושימוש במצביעים חכמים כגון std::unique_ptr(), ולהימנע מפונקציות לא בטוחות כמו strcpy() ו-sprintf(). 

עבור Python , מפתחים צריכים להימנע משימוש בפונקציות כמו eval() או exec() כדי להפחית סיכוני הזרקת קוד, ולהעדיף פורמטים מאובטחים של סידור קוד כמו מודול json על פני pickle בעת עיבוד נתונים לא מהימנים.

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

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

כחלק מ- Secure בתהליך SDLC, השימוש בצינור CI/CD מרכזי ומתואם הוא חובה לאכיפת בניות מאובטחות ולמניעת התקפות שרשרת אספקה. יומני ביקורת, בנייה ופריסה נוצרים, נשמרים ונבדקים כפי שמוגדר במדיניות האבטחה של החברה. 

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

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

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

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

• סריקת סודות כדי למנוע חדירה של סודות ולהבטיח תכנון טוב ויישום מאובטח של טיפול בסודות.
• כלי SAST (בדיקות אבטחה סטטיות של יישומים) לגילוי פגיעויות (למשל הזרקת SQL, הצפות מאגר).
• SCA (ניתוח הרכב Software ) משמש לגילוי פגיעויות בקוד פתוח.
• DAST (בדיקות אבטחה דינמיות של יישומים) משמש לאיתור בעיות בזמן ריצה (למשל, פגמים בזיכרון) ובעיות סביבה

הכלים המוגדרים בסעיף "זיהוי מוקדם של בעיות אבטחה" הם חובה לשימוש בצינור CI/CD. יש לתקן את כל הפגיעויות שזוהו בעקבות בדיקת המוצר. Vulnerability Management מְדִינִיוּת.

מתודולוגיות בדיקות אבטחה אוטומטיות וידניות משמשות בהתאם לתוכנית אבטחת האיכות המבצעת את תוכנית בדיקות האבטחה.

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

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

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

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

בהתאם למדיניות ניהול SBOM, כל מהדורה כוללת Software Bill of Materials (SBOM) כדי לשמור על מעקב אחר מקור הרכיבים, לתמוך בשקיפות ובאבטחת שרשרת האספקה. כל קבצי השחרור הנדרשים מאוחסנים בארכיון מאובטח כדי להבטיח נגישות לטווח ארוך.

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

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

SBOM עבור מוצרים בודדים מסופק ללקוחותינו לפי דרישה. צרו קשר .

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

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

משאבים המסווגים בקטגוריית סיכון גבוה, ניתנים לגישה רק דרך נתיבי גישה מבוקרת (VPN). מכשירים מחוץ לרשת החברה נאלצים להשתמש בערוצים מאובטחים כדי לגשת למשאבי מו"פ.

אבטחת צינור ה-CI/CD עומדת בהנחיות אבטחה מחמירות כדי לצמצם איומים מתפתחים. מקור האיומים יכול להיות רכיבי תשתית מיושנים (כגון מערכות הפעלה, כלי ניתוח וכו'), גישות לא מורשות עקב בקרות הרשאות חלשות וסביבות מבודדות בצורה גרועה. שמירה על תשתית ה-CI/CD מעודכנת, נבדקת ביסודיות ובקרה הדוקה היא אבן יסוד ב-SDLC המאובטחת שלנו. 

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

אנו מיישמים מנגנוני אימות חזקים (אימות רב-גורמי - MFA) ובקרות הרשאה (בקרת גישה מבוססת תפקידים - RBAC). נערכות ביקורות של הרשאות מוגבלות ובדיקות גישה סדירות. 

הצינורות שלנו משלבים מספר כלי אוטומציה לניתוח ובדיקה, כולל בדיקות אבטחת יישומים סטטיות (SAST), Software ניתוח קומפוזיציה (SCA), בדיקות אבטחת יישומים דינמיות (DAST), סריקה סודית וסריקת תוכנות זדוניות. 

בפתרון חתימת הקוד המאובטח שלנו, אנו משתמשים Hardware מודולי אבטחה (HSM) להגנה על חומר המפתח מפני גישה לא מורשית וליצירת החתימה. פתרון החתימה הוא חלק מתשתית CI/CD, אך קיים סגמנטציה של הרשת. רק מחלקת פעולות המחקר והפיתוח מורשים לגשת ל-HSM לפרקי זמן קצרים. כל פעולת חתימה נרשמת וניתן לסקור אותה במהלך מעקב ביקורת. 

ערכת הכלים המשמשת לבנייה, קומפילציה או בדיקת התוכנה חייבת להיות בעלת מידע מקור ולהגיע ממקור מאומת. הכלים המשמשים בצינור CI/CD מוגבלים במספרם; רק הכלים הדרושים מותקנים. רק תוכנת LTS מותרת לשלבי קומפילציה ובנייה בצינור. בתפעול השירותים המרכזיים, מוגדרות תקופות תחזוקה שוטפות ותקופות סיבוב מפתחות. כלים שפותחו באופן פנימי נופלים תחת הקטגוריה... Secure תהליך SDLC.

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

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

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

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

תהליך הסלמה עבור Secure הפרות של SDLC: כל הפרה של מדיניות זו מטופלת באופן פנימי, החל מתפעול המחקר והפיתוח ומעבירה אותה למנהל המוצר הראשי (CPO) לפי הצורך.

ספקים המספקים רכיבים או שירותים עבור מוצרים הנמצאים במסגרת תקני ISO 27001, SOC2, NIST SSDF צפויים לעמוד בדרישות המפורטות להלן. Secure מסגרת SDLC. תאימות כפופה לביקורות אבטחה תקופתיות, הערכות של צד שלישי והתחייבויות של כל צד במסגרת חוזים שנחתמו. 

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

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

ספקי רכיבי צינור חייבים גם ליצור סביבות פיתוח התואמות לנהלים שלנו כמתואר ב- Secure סעיף סביבת פיתוח. בנוסף, תהליכי הפיתוח שלהם חייבים להיות תואמים ל OPSWAT של Secure תהליך SDLC. 

ספקי שירותים צפויים להשתמש בסביבות אמריקאיות המציעות רמת אבטחה דומה לזו של OPSWAT השירותים של. שלהם Secure SDLC חייב לכלול גם א Secure תוכנית SDLC ו-a Secure תהליך SDLC שמשקף OPSWAT הציפיות של.