למה VPN בקוד פתוח נדחה ברכש
סוקר שמתנגד לקוד פתוח מגן בדרך כלל על דרישה, לא על טעם ברישוי. שאלו איזו, ואז הפיקו את המסמך שעונה עליה.
דחיות שמזכירות קוד פתוח נוגעות לעיתים רחוקות ברישוי. הסוקר מגן בדרך כלל על דרישה: שמישהו מתחזק את המהדורה שהוטמעה, שניתן לזהות את הבנייה המותקנת, שהערכה מכסה את מה שמתחבר, או שניתן לשלול את החיבור. הדיון שמגיע אחר כך עונה בדרך כלל על שאלה שאיש לא שאל.
שאלו איזו דרישה חלה לפני שאתם מגנים על רישיון. התשובה קובעת איזה מסמך דרוש לכם.
התווית אינה הדרישה
קוד מקור קריא פירושו שניתן לבדוק את המימוש שפורסם. זה לא אומר שמישהו בדק אותו, שהבנייה בשער תואמת לזו שפורסמה, או שמתחזק חייב לפריסה שלכם תיקון. כל אחד מאלה הוא טענה נפרדת עם בעלים נפרד, וסוקר שזקוק לאחת מהן לא יסתפק באחרות. אמירת הטענה בקול רם מספיקה בדרך כלל כדי לשנות את השיחה.
הטעות ההפוכה נפוצה באותה מידה. רישיון מסחרי אינו מוכיח שהתמיכה מכסה את התכונה שאתם מסתמכים עליה, שהערכה בחנה את הרכיב שאתם פורסים, או שהספק ישלח תיקון בתוך חלון התחזוקה שלכם. רישוי מתאר תנאי הפצה, בעוד שהחלטות רכש עוסקות בהסתמכות. בכל מקרה, הרישיון הוא החלק הפחות אינפורמטיבי בתשובה.
הפרידו גם בין הלקוח לשירות. ביקורת של לקוח שולחני אינה אומרת דבר על תצורת השער של השותף, על ספק הזהות שלו או על האופן שבו המפעילים שלו מטפלים בהסרת חשבונות. כל ראיה שתאספו חייבת להתאים לגבול שמבקשים מהשותף לבטוח בו.
הפכו את החשש למסמך
בקשו מהמאשר לנסח את הדרישה במשפט אחד, ואז מנו את המסמך שיספק אותה. דווקא ההרגעה המעורפלת היא שהופכת את השיחות האלה לוויכוח על אידיאולוגיה.
| What the reviewer is protecting | Artifact that answers it | Who can sign it |
|---|---|---|
| The deployed release keeps getting fixes | Named maintainer, supported version list and the cadence for security releases | The operating team, with the maintainer's published policy attached |
| The build is the one that was reviewed | Package source, version string and the checksum or signature you verify at install | The team that builds or vendors the package |
| An assessment covers the right scope | Component and version assessed, findings raised, corrections made, retest date | Whoever performed the assessment |
| The access can be withdrawn | Identities granted, resources reachable, and the tested removal procedure | The service owner on the partner side |
NIST Secure Software Development Framework שימושי כאן מסיבה צרה אחת: הוא ממסגר שיחות רכש סביב אוצר מילים משותף של נהלים ותקשורת עם ספקים. זה תומך בבקשה לראיות מוגדרות במקום בוויכוח על תווית, וזה אינו הסמכה ש-VPN מסוים עובר.
שימו לב מה עושה העמודה האמצעית. כל שורה מבקשת מסמך שקיים או לא קיים, מה שהופך דעה לתוצר שמישהו יכול להפיק או לסרב לתת.
הפרידו בין הלקוח לשירות
חוזה תמיכה ליישומון לקוח אינו התחייבות לגבי השרת שאליו התעבורה שלכם מגיעה. לפני שאתם מציגים ראיות, סמנו אילו חלקים מהנתיב מפעיל השותף ואילו חלקים אתם מפעילים מטעמו. ערבוב של השניים מייצר חבילת מסמכים שנראית יסודית ואינה עונה על דבר.
אם הפריסה שלכם, ייתכן שהשותף צריך לבטוח רק בזהות ובכלל גישה, וזו בקשה קטנה בהרבה מאשר לבטוח בכל שרשרת אספקת התוכנה שלכם. אם הפריסה שלו, הלקוח שאתם מעדיפים עשוי להיות לא רלוונטי ותצורת השער הופכת לנושא. לברר באיזה מקרה אתם נמצאים לפני הפגישה השנייה חוסך סבב סקירה.
אחר כך בדקו את השאלות התפעוליות שבהן סקירות נכשלות בפועל: מי מסיר חשבון, באיזו מהירות, ואילו ראיות קיימות לאחר מכן. הערכה מתועדת היטב בלי נוהל הסרה היא עדיין ממצא פתוח.
סיימו בהחלטה, לא בוויכוח
סיימו את החליפין בתוצאה כתובה: הגרסה שהתקבלה, הבקרות הקשורות אליה, המפעילים הנקובים, הראיות שעוד חסרות והתאריך שבו הן נדרשות. כל דבר שלא נפתר צריך להירשם כתנאי במקום להיספג בהצהרת אישור כללית.
אם המדיניות נוקבת במוצר מאושר מסוים, השתמשו במסלול החריגה במקום לבנות הסדר מקביל שאיש לא אישר. טיעון טכני משכנע אינו מעניק הרשאה, ופריסה לא רשמית היא ממצא שמחכה להתגלות.
אם דרישה באמת לא ניתנת למילוי, עברו לחלופה המאושרת ואמרו למה. מטרת התרגיל היא לקבוע על מה הארגון יכול להסתמך, ו'לא' ברור הוא תוצאה טובה יותר מאישור שאיש לא יוכל להגן עליו לאחר מכן.