הטמעת DevSecOps ב-CI/CD

הטמעת פרקטיקות DevSecOps בצנרת CI/CD

פגיעויות אבטחה שהתגלו בסביבת ייצור עולות לחברות פי 30 יותר מאשר אם היו מתגלות בשלב הפיתוח. ובכל זאת, רוב הצוותים חושבים על אבטחה רק רגע לפני השחרור—או לאחר תקרית. אנו משלבים בדיקות אבטחה ישירות לתוך זרימת העבודה הפיתוחית: pre-commit hooks, צנרת CI/CD, ופריסות Kubernetes. המומחים שלנו מיישמים DevSecOps כבר למעלה מ-7 שנים ביותר מ-50 פרויקטים, ומפחיתים תקריות אבטחה בשלב מוקדם ב-80% בהשוואה לבדיקות חדירה ידניות (לפי NIST).

למה "פשוט להתקין Trivy" לא מספיק

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

וקטור 1 – קוד יישום

כלי SAST כמו SonarQube, Semgrep ו-CodeQL מזהים תבניות פגיעות: הזרקת SQL, אישורים מוטמעים בקוד, deserialization לא בטוח.

וקטור 2 – תלויות

כלי SCA (ניתוח הרכב תוכנה) כמו Dependabot, Snyk ו-OWASP Dependency-Check מנתחים תלויות npm, pip ו-Maven עבור CVEs ידועים.

וקטור 3 – קונטיינרים

Trivy ו-Grype סורקים תמונות Docker, כולל חבילות מערכת הפעלה ותלויות טרנזיטיביות.

וקטור 4 – תשתית כקוד (IaC)

Checkov, tfsec ו-KICS בודקים Terraform, מניפסטים של Kubernetes ו-Helm charts עבור דליים פתוחים של S3, הרשאות IAM מוגזמות, חוסר הצפנה במנוחה.

וקטור 5 – סודות בקוד

gitleaks ו-truffleHog מוצאים מפתחות API, טוקנים ומפתחות פרטיים שהוטמעו בטעות.

וקטור 6 – זמן ריצה

Falco מזהה התנהגות חשודה בקונטיינרים רצים: exec בלתי צפוי, שינוי של /etc/passwd, תעבורה יוצאת מתהליכים חריגים.

כיצד אנו מטפלים בתוצאות חיוביות שגויות

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

עבור כל פטור אנו מתעדים:

• מזהה ייחודי (CVE או מזהה כלל)
• נימוק (למה לא רלוונטי או לא ניתן לתיקון)
• תאריך בדיקה (בדרך כלל +3 או +6 חודשים)
• האדם שקיבל את ההחלטה

# semgrep inline suppression с обоснованием
password = get_password()  # nosemgrep: python.lang.security.audit.hardcoded-password
# Exemption: password читается из env var, а не захардкожен. Проверено актуально.

ארכיטקטורת צנרת DevSecOps

אנו מפיצים בדיקות בין שלבים לפי מהירות וקריטיות: Pre-commit (שניות):

---
# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks
  - repo: https://github.com/antonbabenko/pre-commit-terraform
    rev: v1.86.0
    hooks:
      - id: terraform_tfsec
      - id: terraform_checkov

CI/CD – שלב אבטחה (מקבילי, דקות):

---
# .gitlab-ci.yml
stages: [build, security, test, deploy]

.security-base:
  stage: security
  needs: [build]

sast:
  extends: .security-base
  image: returntocorp/semgrep
  script:
    - semgrep --config=auto --error --json --output=semgrep.json src/
  artifacts:
    reports:
      sast: semgrep.json

container-scan:
  extends: .security-base
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 1 --ignore-unfixed --severity CRITICAL --format sarif --output trivy.sarif $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  artifacts:
    reports:
      container_scanning: trivy.sarif

iac-scan:
  extends: .security-base
  image: bridgecrew/checkov:latest
  script:
    - checkov -d terraform/ --output junitxml --output-file-path checkov.xml --soft-fail-on MEDIUM
  artifacts:
    reports:
      junit: checkov.xml

dependency-scan:
  extends: .security-base
  script:
    - npm audit --audit-level=high # или pip-audit, safety
---

כל שלבי האבטחה רצים במקביל—ללא הוספת זמן רציף לצנרת.

מדיניות תגובה לממצאים

כלים ללא מדיניות ברורה יוצרים רעש. אנו מסכימים על כך מראש:

המדיניות חייבת להיות מתועדת וידועה לכולם—אחרת כל MR חסום מפתיע מפתחים. תיקון פגיעות בשלב הפיתוח עולה פי 30 פחות מאשר בייצור (לפי NIST).

למה ניטור זמן ריצה חשוב

לאחר הפריסה, Falco פועל כמערכת זיהוי חדירות למארח (HIDS) עבור Kubernetes:

---
# Пример кастомного Falco rule -
rule: Unexpected Network Connection from App Container
desc: Детектирует неожиданные исходящие соединения из app-контейнеров
condition: >
  outbound and container.image.repository = "myorg/myapp" and not fd.rip in (allowed_ips)
output: >
  Unexpected outbound connection (user=%user.name command=%proc.cmdline connection=%fd.name container=%container.name image=%container.image.repository)
priority: WARNING
tags: [network, myapp]
---

Falco משתלב עם Falcosidekick לשליחת אירועים ל-Slack, PagerDuty, Elasticsearch.

תהליך היישום

אנו אף פעם לא פורסים הכל בבת אחת. סדר עדיפויות:

1. שבוע 1–2: gitleaks pre-commit + Trivy ב-CI (החזר השקעה מהיר ביותר)
2. שבוע 3–4: SAST (Semgrep עם ערכת כללים בסיסית) + סריקת תלויות
3. חודש 2: סריקת IaC + מדיניות טיפול בממצאים
4. חודש 3: External Secrets Operator לניהול סודות + חתימת תמונות
5. חודש 4+: זיהוי זמן ריצה עם Falco + מדיניות OPA/Kyverno

כל שלב מתחיל במצב ביקורת—איסוף baseline, תיקון בעיות קיימות, ולאחר מכן הפעלת חסימה.

השפעה בעולם האמיתי

בפרויקט אחד עבור לקוח fintech, הפחתנו את מספר הממצאים הקריטיים לאבטחה מ-47 ל-2 בתוך השבועיים הראשונים של הסריקה. לקוח אחר קיצץ את זמן התגובה הממוצע לתקרית מ-8 שעות ל-15 דקות לאחר שילוב Falco עם התראות אוטומטיות.

מה אתה מקבל

• ביקורת של מצב CI/CD והתשתית הנוכחיים
• הגדרה של כל הכלים המתוארים (gitleaks, Trivy, Semgrep, Checkov, Falco)
• אינטגרציה לתוך הצנרת שלך (GitLab CI, GitHub Actions, או Jenkins)
• מדיניות אבטחה עבור כל סוג ממצא
• תיעוד על תהליך טיפול בפטורים
• הכשרת צוות בפרקטיקות DevSecOps (2 סדנאות)
• חודש אחד של תמיכה לאחר היישום

ציר זמן

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