DevSecOps / Repository
secure-pipeline-blueprints
תבניות ו-blueprints מוכנים לייצור לבניית pipelines מאובטחים של CI/CD, המשלבים SAST, DAST, SCA, סריקת סודות ושערי אבטחה — ומאפשרים shift-left security אמיתי בזרימות העבודה המודרניות של פיתוח תוכנה.
צפה ב-GitHub ↗אודות הפרויקט
Secure Pipeline Blueprints מספקת ספרייה מקיפה של תבניות מוכנות לשימוש לבניית pipelines של CI/CD (Continuous Integration/Continuous Deployment) המשלבים אבטחה. בפיתוח תוכנה מודרני, pipelines של CI/CD מבצעים אוטומציה לתהליך הבנייה, הבדיקה והפריסה של קוד. פרויקט זה מרחיב את האוטומציה הזו כך שתכלול בדיקות אבטחה בכל שלב — פרקטיקה הידועה כ-'shift-left security' משום שהיא מזיזה את בדיקות האבטחה מוקדם יותר (שמאלה) במחזור החיים של הפיתוח. ספריית ה-blueprints מכסה את שלוש פלטפורמות ה-CI/CD הפופולריות ביותר: GitHub Actions, GitLab CI/CD ו-Jenkins. כל blueprint משלב ארבע קטגוריות חיוניות של בדיקות אבטחה: SAST (Static Application Security Testing) אשר מנתח קוד מקור לפגיעויות ללא הרצה; DAST (Dynamic Application Security Testing) אשר בודק יישומים פועלים לפגיעויות; SCA (Software Composition Analysis) אשר מזהה פגיעויות בספריות ותלויות מצד שלישי; ו-Secret Scanning אשר מזהה אישורים, מפתחות API וטוקנים שנשמרו בטעות. כל תבנית pipeline כוללת שערי אבטחה ניתנים להגדרה — נקודות בקרה שיכולות לחסום פריסה אם נמצאות פגיעויות קריטיות. ניתן לכוון שערים אלה לפי רמת חומרה (חסימה על critical/high, אזהרה על medium, התעלמות מ-low), לפי גיל הפגיעות (פגיעויות חדשות לעומת debt טכני קיים), ולפי רכיב (מחמיר יותר עבור שירותים הפונים ללקוחות, מקל יותר עבור כלים פנימיים). הפרויקט מספק גם תבניות דשבורד לאיגום תוצאות סריקת אבטחה לאורך pipelines מרובים, מעקב אחר מגמות ספירת פגיעויות לאורך זמן, והפקת דוחות אבטחה ברמת הנהלה לסקירת management.
למה זה חשוב
הגישה המסורתית של ביצוע בדיקות אבטחה רק בסוף מחזור הפיתוח — ממש לפני פריסה לייצור — פגומה מהיסוד. בשלב הזה, תיקון פגיעויות יקר (פי 10-100 מאשר איתורן במהלך הפיתוח), ולחץ לוחות זמנים לעיתים מביא לכך שפגיעויות מוכרות נפרסות בכל זאת. shift-left security מטפל בכך על ידי שילוב בדיקות אבטחה אוטומטיות בכל commit, pull request ופריסה. עם זאת, יישום shift-left security הוא מורכב לשמצה. צוותי אבטחה חייבים לשלב מספר כלים מתמחים, להגדיר אותם לכל שפת תכנות ו-framework, להתמודד עם false positives מבלי לשבש את פרודוקטיביות המפתחים, וליצור מדיניות ממשל המאזנת בין אבטחה למהירות אספקה. רוב הארגונים משקיעים חודשים בבנייה ובכוונון של ה-pipelines המאובטחים שלהם. ה-blueprints הללו מקצרים את המאמץ הזה מחודשים לימים באמצעות אספקת תבניות מוכחות בייצור ומתועדות היטב, שצוותי אבטחה יכולים להתאים לצרכים הספציפיים שלהם. הם מגלמים לקחים מיישום pipelines מאובטחים בעשרות ארגונים ומייצגים את שיטות העבודה המומלצות העדכניות ב-DevSecOps.
מדריך שלב-אחר-שלב
- בחרו את ה-blueprint המתאים לפלטפורמת ה-CI/CD שלכם (GitHub Actions, GitLab CI, או Jenkins). כל ספריית blueprint מכילה README עם דיאגרמות אדריכלות, תנאים מוקדמים והוראות אינטגרציה. עברו על האדריכלות כדי להבין כיצד כלי האבטחה מתוזמרים ב-pipeline.
- הגדירו את משתני הסביבה והאישורים הנדרשים. כל כלי אבטחה זקוק לתצורה משלו — מפתחות API לסורקים מסחריים, קבוצות כללים לכלים open-source ו-endpoints להתראות. אשף ההתקנה (setup.sh) יוביל אתכם דרך כל שלב תצורה באופן אינטראקטיבי.
- התאימו את שערי האבטחה בהתאם לנטיית הסיכון של הארגון שלכם. ערכו את הקובץ security-gates.yaml כדי להגדיר אילו רמות חומרה של פגיעויות יחסום הפריסה, אילו יפיקו אזהרות ואילו יירשמו בשקט. התחילו במדיניות מקלה והדקו אותה בהדרגה ככל שהצוות שלכם מתבגר.
- הריצו את ה-pipeline תחילה על מאגר בדיקה. עברו על תוצאות סריקת האבטחה, ודאו שהממצאים מדויקים (לא false positives), והתאימו את תצורות הכלים לפי הצורך. לאחר שתהיו מרוצים, פרסו את ה-pipeline למאגרי ייצור. השתמשו בתבנית הדשבורד המצורפת כדי לנטר מגמות אבטחה לאורך כל הפרויקטים שלכם.