שיטת שמונת השלבים לעבודה נכונה הוגנצ ובטוחה עם קוד-פתוח בארגון OSSAP = Open Source Software Adoption Process

1. ‫הטמעה וניהול‬
‫נכון ובטוח‬
‫של קוד פתוח בארגון‬
‫גיל קיני‬

2. Security – Reliability – Quality
‫חדשנות ואיכות בפיתוח תוכנה‬

3. ‫מי אני? ולמה אני פה?‬
‫‪ ‬גיל קיני‬
‫‪ ‬טריניטי תוכנה ומעבר‬
‫‪ ‬אמינות ואבטחה מעל הכול‬
‫‪ ‬אז מה יהיה לנו ...‬

4. OSS is Good for Business

5. ‫קוד פתוח – טוב לכולם‬
‫‪ ‬מגמה עולה בארגונים לשימוש בקוד פתוח ומצד שלישי‬
‫‪ ‬ניהול רישיונות תוכנה כחלק מתהליכי איכות בפיתוח‬
‫‪ ‬התפתחות תהליכי ניהול איכות להכלת כל או חלק‬
‫מהצעדים הבאים ...‬

6. ?‫מהיכן מגיע הקוד שלכם‬
Commercia
l
Own
Open Firm’s
Source Code base
Do we know what
is in our software?
Organization
Load Build
End Product
Outsource
Company
© Copyright 2008 Protecode Inc. Proprietary
6

7. ‫גישות לניהול רישיונות‬
Most effective when applied early in development life cycle

8. ?‫למה דווקא פתרונות בגישה מונעת‬
Economics of IP Management
 Early detection is cost-effective
 No delays, no resource wastage, no higher management involved
 Fixing problems is costly
 Project delays, Resource costs & frustration
 Automated Prevention, integrated into development environment
© Copyright 2009 Protecode Inc. Proprietary
8

9. ‫תהליך שמונת השלבים של ‪OSSAP‬‬
‫‪ OSSAP = Open Source Software Adoption Process‬‬
‫‪ ‬מבוסס על מחקר רוחב של תהליכים ארגוניים כיום ועל הניסיון‬
‫המעשי של מומחי חברת פרוטקוד בשנים האחרונות. חלק‬
‫מהניסיון הזה נרכש תוך כדי ביצוע שירותי בקרת קניין רוחני ‪(IP‬‬
‫)‪Audit‬עבור מספר רב של ארגונים וחברות טכנולוגיות, כחלק‬
‫מתהליכי בדיקת נאותות )‪ (Due Diligence‬על סף פעילות רכישה,‬
‫ולעיתים של מוצר הכולל תוכנה לפני שחרור לשוק או ללקוח‬

10. ‫שמונת השלבים – גרסה מקוצרת‬
‫1. הגדרת מדיניות שימוש ברישיונות‬
‫2. הגדרת תהליך אישור מראש לתוכנה‬
‫3. ניתוח מצב הרישיונות הקיימים‬
‫4. ניתוח קוד ממקור חיצוני‬
‫5. ניתוח והערכה תקופתיים‬
‫6. ניתוח בזמן-אמת, בזמן מסירת קוד לשרת ניהול גרסאות‬
‫7. ניתוח בזמן אמת, ברמת עמדת העבודה של המפתח‬
‫8. ניתוח התוכנה לפני שחרור הגרסה‬

11. ‫תהליך הטמעת קוד-פתוח‬

12. ‫1. הגדרת מדיניות שימוש ברישיונות‬
‫‪( ‬חובה) בשלב ראשון על הארגון להגדיר בצורה מסודרת ומרכזית‬
‫‪o‬‬
‫‪o‬‬
‫‪o‬‬
‫‪o‬‬
‫תנאי רישיון מקובלים עליו‬
‫תנאים אינם מתאימים‬
‫ספקים מורשים‬
‫מוצרי תוכנה או חבילות תוכנה הארגון מאשר לשימוש‬
‫‪ ‬המדיניות תגדיר‬
‫‪ o‬תהליך לבקשה וקבלת אישור עבור חבילות תוכנה‬
‫‪ o‬נקודות בקרה של התוכנה בשלבי הפיתוח השונים‬
‫‪ o‬מה יש לבצע כאשר מתגלה הפרה של המדיניות‬
‫‪ ‬הגדרת "דיגיטלית" / ממוחשבת של המדיניות מאפשרת קישור‬
‫לכלים אוטומטיים לניהול הרישיונות אשר עשויים להיות מופעלים‬
‫כחלק מהתהליך הכולל‬

13. ‫2. הגדרת תהליך אישור-מראש לתוכנה‬
‫‪( ‬רשות) בשלב זה מגדירים ומטמיעים תהליך לקבלת אישור‬
‫לשימוש בחבילת תוכנה חיצונית‬
‫‪ o‬מבטיח שימוש עבור סט מוגבל ומבוקר היטב של חבילות שעברו ניתוח‬
‫ואשר תנאי השימוש מובנים היטב עבור גרסה ספציפית‬
‫‪ ‬תהליך זה כולל את השלבים הבאים:‬
‫‪o‬‬
‫‪o‬‬
‫‪o‬‬
‫‪o‬‬
‫המפתח מבקש אישור לשימוש בחבילת התוכנה החיצונית. הבקשה צריכה‬
‫להכיל כמה שיותר פרטים על החבילה (מקור, גרסה, אופן השימוש וכו')‬
‫הבקשה נרשמת ומתוייגת במאגר רלוונטי באופן שמאפשר מעקב‬
‫לאחר רישום הבקשה – בחינה ע"י גורם רלוונטי (ועדת אישורים) בארגון‬
‫הבקשה מאושרת או נדחית והמפתח מקבל הודעה על כך‬

14. ‫3. ניתוח מצב הרישיונות הקיימים‬
‫‪( ‬חובה) ניתוח הפורטפוליו הקיים בארגון אל מול‬
‫המדיניות המוגדרת בשלב הראשון‬
‫‪ ‬מטרות הבדיקה‬
‫‪ o‬וידוא שלא נעשה שימוש בתוכנה חיצונית שלא בהתאם‬
‫לתנאים המוגדרים ברישיון השימוש‬
‫‪ o‬או לבצע תיקונים במקרים שבהם התגלתה אי התאמה בין‬
‫תנאי הרישיון לשימוש בפועל‬

15. ‫4. ניתוח קוד ממקור חיצוני‬
‫‪( ‬חובה) ניתוח ובקרת רישיונות של כל קוד ו/או חבילת‬
‫תוכנה שמקורם מחוץ לארגון‬
‫‪ ‬הארגון הוא זה שנושא באחריות עבור המוצר המוגמר‬
‫הכולל גם חבילות תוכנה מצד שלישי ולכן עליו לבצע‬
‫ניתוח של כל‬
‫‪o‬‬
‫‪o‬‬
‫‪o‬‬
‫‪o‬‬
‫‪o‬‬
‫תוכנה שסופקה ע"י צד שלישי‬
‫תוכנת צד שלישי הכוללת תוכנה שסופקה ע"י קבלן או מיקור-חוץ‬
‫תוכנה שהארגון בוחן לשם ביצוע החלטת רכישה‬
‫תוכנה שנרכשת מספק חיצוני‬
‫ואף תוכנות קוד פתוח‬

16. ‫5. ניתוח והערכה תקופתיים‬
‫‪( ‬רשות) סקירה של כלל הקוד בתדירות קבועה מראש בכדי לבחון‬
‫את השינויים שבוצעו בתוכנה‬
‫‪ ‬בד"כ סקירה זו נעשית אחת לשבוע או אחת לחודש‬
‫‪ o‬יש להימנע מביצוע סקירה חד פעמית לפני הוצאת גרסה או בהתאם‬
‫לבקשת לקוח בלבד‬
‫‪ o‬משום שעלות תיקון התוכנה בשלבים אלו גבוהה באופן משמעותי ביחס‬
‫לתיקונים שמתבצעים תוך כדי העבודה השוטפת‬
‫‪ ‬ניתן לדלג על שלב זה אך ורק-אם בארגון מתבצעות סקירות‬
‫אוטומטיות בשלבי מסירת הקוד לשרת )‪ (Library Check-in‬ו/או‬
‫בזמן אמת בסביבות הפיתוח‬
‫‪ ‬ההמלצה היא להשאיר שלב זה בכל מקרה כמעגל בקרה נוסף‬

17. ‫6. ניתוח בזמן מסירת קוד לשרת ‪SCM‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫(רשות) כל קובץ חדש או שעבר שינויים נבדק לפני הכנסתו‬
‫למערכת ניהול הקוד )‪(check-in‬‬
‫בכך מבטיחים שקוד חדש שנכנס למערכת, מאובחן ונבדקים סוגי‬
‫הרישיונות שהוא כולל‬
‫במהלך הבדיקה נעשית השוואה מהירה בין הרישיונות בהם נעשה‬
‫שימוש ובין ספריית הרישיונות המאושרים לשימוש בהתאם‬
‫למדיניות החברה‬
‫חוסר התאמה מדווח לגורם הרלוונטי בארגון לשם בדיקה ומתן‬
‫הנחיות בהתאם‬

18. ‫7. ניתוח ברמת עמדת העבודה של המפתח‬
‫‪( ‬רשות) בדיקה קצרה ומהירה אשר מתבצעת באופן אוטומטי‬
‫ושקוף (ברקע), בעמדת העבודה של המפתח, תוך כדי פיתוח‬
‫‪ ‬הניתוח נותן מענה מיידי למפתח האם החבילה שבה עשה שימוש‬
‫באותו רגע מאושרת לשימוש בהתאם למדיניות החברה או לא‬
‫‪ ‬היזון חוזר מיידי למפתח המאפשר‬
‫‪ o‬תיקון מהיר וקל של הבעיה הפוטנציאלית‬
‫‪ o‬לחילופין הוספת הערה ע"י המפתח תוך המשך עבודה (אין פגיעה בשטף‬
‫תהליך הפיתוח). הערה זו נרשמת בלוג ומפוקחת ע"י מנהל הפרויקט ו/או‬
‫לאחראי על הקניין הרוחני‬

19. ‫8. ניתוח התוכנה לפני שחרור גרסה‬
‫‪( ‬חובה) צעד זה הכרחי ומטרתו להבטיח שקיימת הבנה‬
‫מלאה של תכולת המוצר והמחויבויות הקשורות אליו, לפני‬
‫הוצאתו / שיחרורו לשוק וחשיפה ללקוחות‬
‫‪ ‬שלב זה כולל ניתוח של הקוד הנצרך בפועל כחלק‬
‫מתהליך בניית התוכנה מיפוי הרישיונות ומשמעות‬
‫השימוש בהם‬
‫‪ ‬שלב זה צריך להוות חלק‬
‫‪ o‬מתהליך בקרת האיכות‬
‫‪ o‬ומרשימת התנאים לשחרור גרסה )‪(release check-list‬‬

20. ‫נקודות עיקריות‬
‫‪ ‬הגדרת וגיבוש מדיניות‬
‫‪ ‬אוטומציה מקסימאלית בכדי להבטיח‬
‫‪o‬‬
‫‪o‬‬
‫‪o‬‬
‫‪o‬‬
‫יעילות‬
‫דיוק‬
‫כיסוי מלא‬
‫עמידה במדיניות‬

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

22. ‫תהליך הטמעת קוד-פתוח‬

24. Protecode Solution Portfolio

Complete Portfolio
o


Advanced, Easy-to-adopt Solution
Workflow for license management
o
o
o

Intelligent: Scanned files will not be reanalyzed unless they are modified
Seamless interworking
Intuitive, fast
Real-time and on-demand analysis
o

Full implementation of Open Source Software
Adoption Process (OSSAP)
Unique in industry
Choice of
o
o
Global IP Signatures (GIPS) reference database
On-premises Enterprise IP Signature (EIPS)
database
24

25. ‫חדשנות ואיכות בפיתוח תוכנה‬
Klocwork
– analyze your code to find
security issues & bugs
Metaforic
– protect your code against Tampering,
Reverse-Engineering & Code-Lifting
Codenomicon – intelligent fuzzing of protocols for
security & robustness
PlasticSCM
– the most advanced and flexible
SCM & ALM solutions

26. ‫בואו נדבר ...‬
‫תודה !‬
‫גיל קיני‬
‫‪Gil @ Trinity.co.il‬‬