TechCamp Solutions

الـ Developer الشاطر مش هو اللي بيخلص الـ Tasks بسرعة.. الـ Developer الشاطر هو اللي عارف الكود اللي جوه الـ node_modules أو الـ NuGet بتاعه فيه إيه! 📦⚠️
​تلاقي الـ Project شغال زي الفل، وفجأة يجيلك طلب: "احنا محتاجين Feature بتعمل الحوار الفلاني".
وبدل ما نكتبها، بنستسهل ونعمل:
npm install package-x
​والـ Feature بتشتغل في دقيقتين، والكل بيبقى مبسوط بـ الـ Speed to market. 🚀
​بس الحقيقة؟ 🤔
إنت مش منزّل الـ Package دي لوحدها.. إنت نزلت معاها شجرة كاملة من مكتبات تانية مبنية على مكتبات تانية إنت متعرفش عنها حاجة!
​الـ Attackers مابقوش يضيعوا وقتهم في كسر الـ Firewall بتاع شركتك الكبيرة.. هما بيروحوا لـ Package صغيرة مفتوحة المصدر (Open Source) بيستخدمها ملايين الـ Developers، ويحقنوا جواها Malicious Code. 🕵️‍♂️
​أول ما تعمل Update أو Deploy.. الـ Malware بيبقى جوه السيرفر بتاعك، وبيبدأ يسرب بيانات عملائك والـ Environment Secrets للـ Attacker وهو حاطط رجل على رجل.
​🛠️ الحل إيه عشان مانعيشش في رعب؟
1️⃣ بلاش استسهال: لو الـ Feature بسيطة ومحتاجة كام سطر كود، اكتبها بنفسك بدل ما تعتمد على Package كاملة مجهولة.
2️⃣ فحص دوري (SCA): شغل أدوات الـ Software Composition Analysis في الـ Pipeline بتاعتك عشان تقفش أي ثغرات أو مكتبات مسمومة قبل ما تطلع Production.
​الـ Application Security مش مجرد قفل على الباب الخارجي.. الـ Security بيبدأ من الأدوات والمكتبات اللي إنت بتبني بيها بيتك من جوه. 🧱
​❓ سؤال للـ Developers:
إيه أكتر Package نزلتها في مشروعك وحسيت إنها "Black Box" إنت مش فاهم شغال إزاي؟ شاركوني تحت في الكومنتات. 👇
​

البوست ده هجومي شوية وموجه للشركات اللي فاكرة إن الـ Security عبارة عن تول بتطلع تقرير PDF.
​
​لو فاكر إن الـ Automated Vulnerability Scanners هتحميك.. فإنت بتشتري "وهم" برقم كبير! 💸❌

​شركات كتير بتدفع آلاف الدولارات في تولز تقيلة عشان تعمل Scan للمواقع والـ APIs بتاعتها، وأول ما التقرير يطلع "Zero Vulnerabilities" باللون الأخضر، الـ Management بتنام وتطمن.

​بس في الحقيقة، الـ Scanner ده أعمى قدام الـ Business Logic Flaws.. الحاجات اللي محتاجة مخ بشري يفكر فيها ويكسرها. 🧠

​الـ Scanner مستحيل يفهم السيناريو ده:
🛑 إنت عندك موقع تجارة إلكترونية.. المشتري دخل يشتري منتج تمنه 1000$، وفي الـ Request بتاع الدفع، غير الـ Quantity لـ (1-) والسعر الإجمالي بقى بالسالب.. السيرفر قبل الـ Request وشحن المنتج، ورجع فلوس لحساب العميل!
​الـ Scanner هيشوف الـ Request راجع بـ 200 OK وهيعديها كأنها فل الفل.. لكن الـ Hacker البشري هيخرب بيت الشركة في دقيقة.

​الأدوات ممتازة في صيد الثغرات التقليدية السريعة، بس الـ Pentesters الشاطرين عارفين إن الثغرات الحقيقية اللي بتعمل Data Breaches بتيجي من فهم الـ Flow وسوء إدارة الصلاحيات (Access Control).

​الـ Automation بيوفر وقت.. بس العقل البشري هو اللي بيحمي. 🛡️

​❓ شاركوني: إيه أغرب ثغرة Business Logic قفشتوها أو سمعتوا عنها والـ Scanners مكنتش شايفاها؟ 👇
​

فيه برضه تريند شغال في الـ Web Development.. 🖥️
​أول ما الـ Team يخلص الـ Features الكبيرة، وقبل الـ Release بكام يوم، تلاقي الـ Manager بيقول:
"يا جماعة احنا محتاجين نعمل Pentest على الـ Web App والـ APIs قبل ما نطلع لايف".

​وتتحول العملية لـ "Checklist" أو خانة عايزين نعلم عليها عشان نرضي الـ Management أو الـ Compliance.

​بس الحقيقة؟ 🤔
الـ Web Application Pentesting مش مجرد خطوة بتتعمل في آخر الـ Project.
​وإنك تجيب Pentester في آخر ٥ أيام، ده أشبه باللي بيبني عمارة ويفتكر يحط حديد تسليح بعد ما صب الخرسانة! 🧱

​الـ Web Apps مابقتش زي زمان؛ المواقع بقت معقدة، شاشات الـ Frontend بتكلم عشرات الـ APIs، والـ Business Logic بقى متشابك جداً.

​الـ Script Kiddie حافظ كام ثغرة من الـ OWASP Top 10 زي الـ SQL Injection أو الـ XSS، وبيعتمد على الـ Automated Scanners عشان تجيبهم.

​لكن الـ Web Pentester المحترف عارف إن الـ Scanners دي "عمياء" قدام الكوارث الحقيقية في الـ Production، زي:
​🛑 BOLA / IDOR: (تعديل الـ ID في الـ Request عشان تشوف بيانات مستخدم تاني).

​🛑 Mass Assignment: (تبعت Field زي is_admin: true في الـ Register request والسيرفر يقبله عمياني).

​🛑 Broken Rate Limiting: (تخطي حماية الـ API عشان تعمل Brute-force أو تستهلك الـ Resources).

​الأدوات مش هتفهم الـ Logic بتاع الـ Application بتاعك.. البني آدم هو اللي بيفهمه ويكسره. 🧠

​💡 المعضلة: الـ Pentest التقليدي بيعطّل الـ Agility
​في عصر الـ DevOps، الـ Teams بتعمل Deploy لكود جديد كذا مرة في اليوم أو الأسبوع.

​لو اعتمدت على الـ Pentest التقليدي: هتجيب شركة برة كل 6 شهور تعمل فحص. التقرير هيطلع فيه 50 ثغرة، الـ Developers هيكونوا نسوا اصلاً هما كتبوا الكود ده إزاي، وتعطيل الشغل يبدأ هنا.

​الحل؟ إننا ننقل الـ Security من فكرة "البوابة اللي بتعطلنا في الآخر" لـ فكرة "الـ Pipeline الشغالة معانا" = DevSecOps. 🔄
​🛠️ إزاي الـ Web Pentesting بيتكامل مع الـ DevSecOps Pipeline؟

​المهندس الشاطر بيقسم الـ Security Tests لـ مستويات جوه الـ CI/CD Pipeline، بناءً على السرعة والعمق (Shift Left Security):
​1️⃣ الـ Automated Automation (في كل Commit)
​الـ SAST & Secret Scanning: تولز بتفحص الكود وهو مكتوب للتأكد إن مفيش Password مكتوبة بالغلط.
​الـ SCA (Software Composition Analysis): فحص الـ dependencies للتأكد إن الـ Third-party packages مفيش فيها ثغرات معروفة.
(ودي حاجات سريعة بتشتغل في دقائق مع كل PR او Git Push).

​2️⃣ الـ Dynamic Automation (في الـ Staging/QA)
​الـ DAST: أول ما الكود يترفع على سيرفر الـ Staging، بتبدأ تولز تعمل Automated Scans سريعة على الـ Endpoints المفتوحة عشان تصيد الثغرات الظاهرة.

​3️⃣ الـ Human-Led Pentesting (الـ Continuous Pentesting)
بعد ما الـ Automation ينضف الكود من الثغرات العبيطة.. هنا يجي دور الـ Pentester البشري. 🎯

​بدل ما يضيع وقته في تدوير على نسخة قديمة من مكتبة معينة، هو بيدخل على سيستم "نضيف تقنياً"، ويبدأ يركز كل مجهوده وذكائه في الـ Business Logic Flaws والـ Chaining Vulnerabilities.

​📢 الخلاصة: الـ Security مش فرامل.. الـ Security حزام أمان
​الـ DevSecOps مش جاي يلغي الـ Pentester، وجاي يقول إن الـ Automation لوحده مش كفاية. هو جاي يوفر وقت الـ Pentester للحاجات المعقدة اللي محتاجة تفكير، ويضمن إن الثغرات الواضحة بتتصلح وهي لسه في الـ Development stage.

​المهندس الشاطر مش اللي بيصلح الثغرة بعد ما السيستم يتفضح.. المهندس الشاطر هو اللي بيبني Pipeline تمنع الثغرة من إنها تشوف الـ Production أصلاً.

​❓ سؤال للـ Developers والـ Security Engineers:
الـ Security عندكم في الشركات بيبدأ من أول الـ Design والـ Pipeline، ولا لسه "Checklist" بتتعمل قبل الـ Deploy بيومين؟ شاركوني تجاربكم في الكومنتات. 👇
​