قرن ۱۹ میلادی، نویسنده سرشناس دانمارکی، در کنار داستان‌های به ظاهر ساده‌ای مثل دختر کبریت‌فروش یا جوجه‌اردک زشت، داستان لباس جدید پادشاه رو نوشت که احتمالا اکثر ما یا کتابش رو در کودکی خوندیم، یا کارتونش رو تماشا کردیم.
فکر می‌کنم بد نباشه جامعه مهندسی نرم‌افزار، گاهی جلو آیینه بایسته و ببینه که چقدر لُخت است! توی قصه «پادشاه لخت»، مشکل فقط یک پادشاه ساده‌لوح نبود. مسئله، یک اکوسیستم کامل بود:
- خیاط‌های دروغین
- درباریان تأییدکننده
- جمعیتی که جرئت پرسیدن نداشت
و فقط یک کودک بود که گفت: چیزی تنش نیست!
اگر بخوایم صادق باشیم، ما هم در اکوسیستم نرم‌افزار، کم از اون دربار نداریم. و چقدر برای مناسب ظاهر شدن، نیاز به یادگیری و تلاش مضاعف داریم. خیاط‌های دروغین امروز همیشه شیادهای بیرونی نیستن.
گاهی در لباس لیدر فنی ظاهر می‌شن که بدون threat model و بدون طراحی امنیتی، سیستم رو «production-ready» اعلام می‌کنن.
گاهی در قامت تیم محصول که زمان تحویل را بالاتر از امنیت و کیفیت می‌نشونن.
گاهی در نقش مدیر که بودجه آموزش، معماری، یا امنیت رو هزینه اضافی می‌دونن.
و گاهی هم در قامت مهندس باتجربه‌ای که سال‌هاست چیز جدیدی یاد نگرفته ولی همچنان با اعتمادبه‌نفس حرف می‌زنه.
و درباریان؟
ما وقتی بدون خوندن دقیق PR رو تأیید می‌کنیم.
وقتی postmortem واقعی نمی‌نویسیم.
وقتی ضعف امنیتی رو می‌دونیم ولی می‌گیم “بعداً درستش می‌کنیم”.
وقتی outage رو «اتفاق طبیعی» جا می‌زنیم.
مسئله این نیست که هک شدیم یا نشدیم. کند یا ناپایدار هستیم یا نه!
مسئله اینه که آیا اصول مهندسی رو جدی گرفته‌ایم یا نه.
من قبلاً دو اپیزود درباره تولید امن نرم‌افزار ساختم. درباره: SSDLC, STRIDE, Shift-left, SAST, DAST, IAST, RASP, SCA
در مورد بدهی فنی هم یه ویدیو کوتاه
اما سؤال جدی اینه:
چند تیم واقعاً این‌ها رو در عمل اجرا می‌کنند، نه فقط در رزومه؟
اگر بخواهیم جلوی آینه بایستیم، شاید بهتر باشد به جای شعار، این چک‌لیست رو از خودمون بپرسیم:
آیا ما این‌ها رو داریم؟
- اصول Security by Design، نه Security after Incident
- مفاهیم Threat Modeling مستند
- ساختار Secure SDLC واقعی، نه اسلاید پاورپوینت
- مکانیزم‌های observability جدی
- ساختار Data Governance مشخص
- طبقه‌بندی داده و سیاست retention
- مدیریت دسترسی مبتنی بر اصل Least Privilege یا زیروتراست
- اصول Software Composition Analysis و مدیریت dependency
- ساختار Incident response plan تمرین‌شده
و...
اگر این‌ها نیست، ما فقط امیدواریم، مهندسی نمی‌کنیم.
روز مهندس شاید بیشتر از اونکه تبریک بخواد، احتیاج به صداقت داره.
صداقت با خودمون.
شاید وقتش باشه به جای تبریک‌های شاعرانه، هرکدوم‌مون یک ضعف مهندسی رو در تیممون جدی اصلاح کنیم. (جلو آینه بایستیم و لخت بودنمون رو ببینیم!)
لباس، با آرزو دوخته نمی‌شه.
با استاندارد، تمرین و مسئولیت‌پذیری دوخته می‌شه.
منظورم از اکوسیستم، فقط گروه خاصی نیست که ربطش بدیم به وقایع سیاسی و اجتماعی کنونی و بگیم اونا که از ما نیستن یا رفتنی‌اند و بعدش درستش می‌شه و از خودمون صلب مسئولیت کنیم.
از استارتاپ‌های متعدد خصوصی که هک شدن، تا بانک و سازمانی که با هک شدن داده‌هاش نابود شد و از روی پیامک‌ها موجودی مردم رو بازسازی! کردن! تا نرم‌افزار دانشگاه تا... همه و همه گواهی بر لُختی جامعه نرم افزاریه!