מי עומד מאחורי CodeShield
בלוג טכני עצמאי שמתמקד בארכיטקטורת אבטחה של מערכות פיננסיות. אנחנו כותבים על מה שאנחנו מכירים מהשטח — לא ממצגות שיווקיות של ספקים.
איך זה התחיל
CodeShield נולד מתוך תסכול פשוט: כשעבדתי כ-DevSecOps בחברת פינטק בבני ברק, מצאתי את עצמי מחפש שוב ושוב מידע טכני מעמיק על ארכיטקטורת אבטחה של מערכות מסחר. מה שמצאתי ברוב המקרים היה או ברמה גבוהה מדי — מאמרים כלליים על "חשיבות האבטחה" — או נעול מאחורי חומות תשלום של חברות ייעוץ שמוכרות בדיוק את השירות שהן כותבות עליו.
ב-2024, החלטתי להתחיל לכתוב בעצמי. לא כי חשבתי שאני יודעת הכל — אלא כי האמנתי שיש מקום לבלוג טכני בעברית שמדבר בגובה העיניים, עם קוד אמיתי, דיאגרמות אמיתיות, והפניות למקורות שאפשר לבדוק. מאז, CodeShield גדל לאט. בלי פרסומות, בלי ספונסרים, בלי תוכן ממומן.
הגישה שלי פשוטה: אם אני כותבת על משהו, אני קודם כל מבינה אותו לעומק. אם אני לא יכולה להסביר את זה עם דוגמת קוד או דיאגרמה — אני כנראה לא מבינה את זה מספיק טוב בשביל לכתוב עליו.
מה אנחנו עושים — ומה לא
CodeShield הוא בלוג טכני. אנחנו מפרסמים מאמרים, מדריכים וסקירות שעוסקים בארכיטקטורת אבטחה של תשתיות פיננסיות — מערכות מסחר, תשתיות קריפטוגרפיה, ניהול זהויות, ופרוטוקולי תקשורת מאובטחים. כל מאמר עובר בדיקה עצמית של דיוק טכני לפני הפרסום, ומעודכן כשהתקנים או הכלים משתנים.
מה אנחנו לא עושים: לא ייעוץ מסחרי, לא שירותי pentest, לא המלצות השקעה. אנחנו לא מוכרים שום דבר חוץ מתוכן — וגם זה בחינם. אם מישהו פונה אליכם בשם CodeShield ומציע שירות בתשלום, זה לא אנחנו.
המתודולוגיה שלנו
כל ניתוח שאנחנו מפרסמים ב-CodeShield עובר ארבעה שלבים. אני מאמינה בשקיפות מלאה לגבי התהליך, כי רק ככה אפשר להעריך את אמינות הממצאים.
1. מיפוי ארכיטקטוני
השלב הראשון הוא תמיד מיפוי. לא משנה אם מדובר בסקירה של פרוטוקול TLS 1.3 או בניתוח מערכת clearing של בורסה — מתחילים מהבנת המבנה הכולל. מי הרכיבים, איך הם מתקשרים, איפה עובר הגבול בין שירות לשירות, ומה זורם ביניהם. בלי מפה, כל ניתוח הוא ניחוש מושכל.
בפרקטיקה, זה אומר שאני קוראת תיעוד טכני, RFC-ים, ומפרטי פרוטוקול. עבור ניתוחי בורסות, אני נשענת על תיעוד ציבורי שפורסם על ידי Eurex, CME, ובורסות נוספות. עבור פרוטוקולי אבטחה, המקורות העיקריים הם RFC-ים של IETF ופרסומי NIST.
2. מודלינג של איומים
אחרי שיש מפה, אני בונה מודל איומים. לא משהו פורמלי ברמת OWASP Threat Modeling מלא — אלא ניתוח ממוקד: מה יכול להשתבש, מי עלול לנצל את זה, ומה הנזק. אני משתמשת במודל STRIDE כמסגרת חשיבה, אבל לא כצ'קליסט נוקשה. Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege — כל אחד מהם רלוונטי בהקשרים שונים.
3. אימות ממצאים
כל ממצא טכני שאני מפרסמת עובר אימות. אם אני כותבת שקונפיגורציה מסוימת של TLS פגיעה, אני בודקת את זה — עם openssl s_client, עם Wireshark, או עם כלי ספציפי. אני לא מסתמכת על סורקי חולשות אוטומטיים בלבד. הכלים האלה טובים כשכבת בדיקה ראשונה, אבל הם מייצרים false positives ברמה שלא מאפשרת הסתמכות בלעדית.
4. תיעוד ומסקנות
השלב האחרון הוא כתיבה. כל מאמר כולל את הממצאים, את הראיות (קוד, פלט של כלים, צילומי מסך), את ההמלצות, ואת סדר העדיפויות. אני מבדילה בין "חייב לתקן עכשיו" ל"כדאי לשפר בצעד הבא" ל"ראוי לשקול לטווח ארוך". בעיניי, דוח שלא מבחין בין דחיפויות שונות הוא דוח שלא עוזר לאף אחד.
הגוף המפעיל
CodeShield מופעל על ידי TechCorp, הרשומה ב-Allenby Street 5401, Bnei Brak 8954593, Israel.
לשאלות משפטיות או מסחריות: mary_thompson657@proton.me
מי כותב כאן
Mary Thompson, מייסדת ועורכת ראשית של CodeShield. מהנדסת אבטחת מידע עם ניסיון של למעלה מעשור בתחום ה-DevSecOps וארכיטקטורת מערכות פיננסיות. התמחות ב-service mesh, קריפטוגרפיה שימושית, ותשתיות מסחר מבוססות event-driven architecture. בוגרת תואר שני במדעי המחשב עם התמחות באבטחת רשתות.
צוות הכותבים הנוסף נמצא בשלבי הקמה. כרגע, רוב התוכן נכתב על ידי העורכת הראשית עם ביקורת עמיתים לא פורמלית ממומחים בתחום.
עדכונים ושינויים
מאי 2026: עדכון דף אודות — הוספת פירוט מתודולוגיה ועדכון פרטי יצירת קשר.
מרץ 2026: שכתוב מלא של מבנה האתר ותוספת תמיכה משופרת במובייל.
ינואר 2025: השקת הבלוג בגרסתו הראשונה.