מסגרת Secure OPSWAT: מחויבות לחוסן ולאבטחה רב-שכבתית

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בהתאם למדיניות ניהול 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 .

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

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

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

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

תהליך העברה לדרגים גבוהים יותר במקרה של הפרות Secure : כל הפרה של מדיניות זו מטופלת באופן פנימי, החל ממחלקת תפעול מחקר ופיתוח (R&D Operations) ועד למנהל המוצר הראשי (CPO), לפי הצורך.

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

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

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

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

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