🔵 عنوان مقاله
Cl0p Ransomware Lists NHS UK as Victim, Days After Washington Post Breach (3 minute read)
🟢 خلاصه مقاله:
**کل0p روز ۱۱ نوامبر نام NHS UK را به فهرست قربانیان خود اضافه کرد؛ چند روز پس از ادعای نفوذ به The Washington Post. بنا بر گزارش، هر دو رویداد با سوءاستفاده از CVE-2025-61882 (آسیبپذیری RCE با امتیاز CVSS 9.8) در Oracle E-Business Suite نسخههای 12.2.3 تا 12.2.14 مرتبطاند. بهرهبرداری از این نقص از اوت 2025 آغاز شد؛ پس از انتشار کد PoC توسط Scattered Lapsus$ Hunters در ۳ اکتبر سرعت حملات بالا رفت و Oracle در ۴ اکتبر وصله اضطراری ارائه کرد. گفته میشود Cl0p و FIN11 سپس کمپینهای هماهنگی علیه نمونههای در معرض اینترنت اجرا کردند. برای کاهش ریسک: نصب فوری وصلهها، محدودسازی دسترسی اینترنتی، پایش لاگها و نشانههای نفوذ از اوت 2025، و چرخش اعتبارنامهها توصیه میشود.
#Ransomware #Cl0p #CVE2025_61882 #OracleEBS #NHS #Cybersecurity #DataBreach #FIN11
🟣لینک مقاله:
https://hackread.com/cl0p-ransomware-nhs-uk-washington-post-breach/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Cl0p Ransomware Lists NHS UK as Victim, Days After Washington Post Breach (3 minute read)
🟢 خلاصه مقاله:
**کل0p روز ۱۱ نوامبر نام NHS UK را به فهرست قربانیان خود اضافه کرد؛ چند روز پس از ادعای نفوذ به The Washington Post. بنا بر گزارش، هر دو رویداد با سوءاستفاده از CVE-2025-61882 (آسیبپذیری RCE با امتیاز CVSS 9.8) در Oracle E-Business Suite نسخههای 12.2.3 تا 12.2.14 مرتبطاند. بهرهبرداری از این نقص از اوت 2025 آغاز شد؛ پس از انتشار کد PoC توسط Scattered Lapsus$ Hunters در ۳ اکتبر سرعت حملات بالا رفت و Oracle در ۴ اکتبر وصله اضطراری ارائه کرد. گفته میشود Cl0p و FIN11 سپس کمپینهای هماهنگی علیه نمونههای در معرض اینترنت اجرا کردند. برای کاهش ریسک: نصب فوری وصلهها، محدودسازی دسترسی اینترنتی، پایش لاگها و نشانههای نفوذ از اوت 2025، و چرخش اعتبارنامهها توصیه میشود.
#Ransomware #Cl0p #CVE2025_61882 #OracleEBS #NHS #Cybersecurity #DataBreach #FIN11
🟣لینک مقاله:
https://hackread.com/cl0p-ransomware-nhs-uk-washington-post-breach/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Hackread
Cl0p Ransomware Lists NHS UK as Victim, Days After Washington Post Breach
Follow us on Bluesky, Twitter (X), Mastodon and Facebook at @Hackread
خبر جالب و البته شوکه کننده؟!!! شرکت Anthropic گزارش داده که تونسته جلوی اولین حمله بزرگ جاسوسی سایبری که به صورت خودکار توسط هوش مصنوعی مدیریت شده رو بگیره. این دیگه شوخی نیست، واقعاً داریم وارد فاز جدیدی از تهدیدات سایبری میشیم!
جزئیات ماجرا:
مامور AI (Agentic AI): این حمله دیگه صرفاً استفاده از AI برای "مشاوره دادن" به هکرها نبود. مهاجمان از قابلیتهای "عاملیت" (Agentic) هوش مصنوعی استفاده کردن. یعنی AI مثل یک "مامور" عمل کرده و 80 تا 90 درصد کارهای حمله، از شناسایی هدف تا نوشتن کدهای مخرب و استخراج اطلاعات، رو بدون دخالت زیاد انسان پیش برده. هکرها فقط در ۴-۶ نقطه کلیدی برای تصمیمگیری وارد عمل شدن.
سرعت غیرقابل تصور: Anthropic میگه این سیستم AI تونسته هزاران درخواست، و اغلب چندین درخواست در ثانیه، ایجاد کنه! سرعتی که برای هیچ تیم انسانی از هکرها قابل دستیابی نیست. AI رسماً سرعت حملات سایبری رو به فاز موشکی برده.
سوءاستفاده از Claude: گروه مهاجم (که Anthropic با اطمینان بالا میگه یک گروه تحت حمایت دولت چین بوده) با "جِیلبریک" کردن و فریب دادن ابزار Claude Code (کد نویس هوش مصنوعی Anthropic) اون رو وادار به عملیات خرابکارانه کرده. اونا با ترفندهایی مثل شکستن کارها به بخشهای کوچک و وانمود کردن به اینکه AI داره برای یک شرکت امنیتی قانونی کار میکنه، از سد حفاظتی کلاود گذشتن.
اهداف مهم: حدود ۳۰ هدف جهانی، شامل شرکتهای بزرگ تکنولوژی، مالی، تولید مواد شیمیایی و سازمانهای دولتی مورد حمله قرار گرفتن.
نتیجهگیری و پیام مهم:
این ماجرا زنگ خطریه که نشون میده موانع انجام حملات سایبری پیچیده، به طرز چشمگیری کاهش پیدا کرده و گروههای کمتجربهتر هم حالا میتونن حملات بزرگ اجرا کنن.
اما خبر خوب اینجاست که Anthropic تاکید میکنه: همون هوش مصنوعیای که میتونه حمله کنه، میتونه بهترین خط دفاع هم باشه! باید یاد بگیریم چطور از AI برای تشخیص تهدیدات، ارزیابی آسیبپذیریها و پاسخ به حوادث (Cyber Defense) استفاده کنیم.
باید این اطلاعات رو جدی بگیریم و امنیت سایبری رو با سرعت AI بهروز کنیم. حتماً متن کامل گزارش رو بخونید تا ببینید چقدر اوضاع جدیه.
Link:
https://www.anthropic.com/news/disrupting-AI-espionage
<Mehdi Allahyari/>
جزئیات ماجرا:
مامور AI (Agentic AI): این حمله دیگه صرفاً استفاده از AI برای "مشاوره دادن" به هکرها نبود. مهاجمان از قابلیتهای "عاملیت" (Agentic) هوش مصنوعی استفاده کردن. یعنی AI مثل یک "مامور" عمل کرده و 80 تا 90 درصد کارهای حمله، از شناسایی هدف تا نوشتن کدهای مخرب و استخراج اطلاعات، رو بدون دخالت زیاد انسان پیش برده. هکرها فقط در ۴-۶ نقطه کلیدی برای تصمیمگیری وارد عمل شدن.
سرعت غیرقابل تصور: Anthropic میگه این سیستم AI تونسته هزاران درخواست، و اغلب چندین درخواست در ثانیه، ایجاد کنه! سرعتی که برای هیچ تیم انسانی از هکرها قابل دستیابی نیست. AI رسماً سرعت حملات سایبری رو به فاز موشکی برده.
سوءاستفاده از Claude: گروه مهاجم (که Anthropic با اطمینان بالا میگه یک گروه تحت حمایت دولت چین بوده) با "جِیلبریک" کردن و فریب دادن ابزار Claude Code (کد نویس هوش مصنوعی Anthropic) اون رو وادار به عملیات خرابکارانه کرده. اونا با ترفندهایی مثل شکستن کارها به بخشهای کوچک و وانمود کردن به اینکه AI داره برای یک شرکت امنیتی قانونی کار میکنه، از سد حفاظتی کلاود گذشتن.
اهداف مهم: حدود ۳۰ هدف جهانی، شامل شرکتهای بزرگ تکنولوژی، مالی، تولید مواد شیمیایی و سازمانهای دولتی مورد حمله قرار گرفتن.
نتیجهگیری و پیام مهم:
این ماجرا زنگ خطریه که نشون میده موانع انجام حملات سایبری پیچیده، به طرز چشمگیری کاهش پیدا کرده و گروههای کمتجربهتر هم حالا میتونن حملات بزرگ اجرا کنن.
اما خبر خوب اینجاست که Anthropic تاکید میکنه: همون هوش مصنوعیای که میتونه حمله کنه، میتونه بهترین خط دفاع هم باشه! باید یاد بگیریم چطور از AI برای تشخیص تهدیدات، ارزیابی آسیبپذیریها و پاسخ به حوادث (Cyber Defense) استفاده کنیم.
باید این اطلاعات رو جدی بگیریم و امنیت سایبری رو با سرعت AI بهروز کنیم. حتماً متن کامل گزارش رو بخونید تا ببینید چقدر اوضاع جدیه.
Link:
https://www.anthropic.com/news/disrupting-AI-espionage
<Mehdi Allahyari/>
Anthropic
Disrupting the first reported AI-orchestrated cyber espionage campaign
A report describing an a highly sophisticated AI-led cyberattack
👍1
یک رپو دیگه برای علاقه مندان به تجربه امنیت و باگبانتی و Ai ابزار جذاب HackGPT Enterprise یه ابزار حرفهای و پیشرفته برای تست نفوذه که با هوش مصنوعی و یادگیری ماشین کار میکنه
با HackGPT میتونید آسیبپذیریهای سیستمها رو پیدا کنید، گزارشهای کامل و دقیق بگیرید و حتی از چارچوبهای امنیتی مثل OWASP، NIST و ISO27001 پیروی کنید.
این ابزار با معماری میکروسرویسها و پشتیبانی از Docker و Kubernetes، مقیاسپذیری بالایی داره و میتونید روی ابرهای مختلف مثل AWS، Azure و GCP استقرارش بدید.
https://github.com/yashab-cyber/HackGpt/
| <POURYA/>
با HackGPT میتونید آسیبپذیریهای سیستمها رو پیدا کنید، گزارشهای کامل و دقیق بگیرید و حتی از چارچوبهای امنیتی مثل OWASP، NIST و ISO27001 پیروی کنید.
این ابزار با معماری میکروسرویسها و پشتیبانی از Docker و Kubernetes، مقیاسپذیری بالایی داره و میتونید روی ابرهای مختلف مثل AWS، Azure و GCP استقرارش بدید.
https://github.com/yashab-cyber/HackGpt/
| <POURYA/>
GitHub
GitHub - yashab-cyber/HackGpt: HackGPT Enterprise is a production-ready, cloud-native AI-powered penetration testing platform designed…
HackGPT Enterprise is a production-ready, cloud-native AI-powered penetration testing platform designed for enterprise security teams. It combines advanced AI, machine learning, microservices archi...
👍1
🔵 عنوان مقاله
Sherlock (GitHub Repo)
🟢 خلاصه مقاله:
Sherlock یک ابزار متنباز در GitHub برای OSINT است که با جستوجوی خودکار username در صدها شبکه اجتماعی، حسابهای مرتبط را شناسایی میکند. این ابزار از خط فرمان اجرا میشود، برای تحقیق، پایش برند، شناسایی جعل هویت و راستیآزمایی مفید است و نتایج را بهصورت یک گزارش قابل استفاده ارائه میدهد. با این حال بهدلیل تفاوت رفتار پلتفرمها ممکن است خطا رخ دهد؛ بنابراین باید نتایج را اعتبارسنجی کرد و ابزار را مسئولانه و مطابق قوانین و شرایط استفاده هر سرویس به کار گرفت.
#OSINT #Sherlock #GitHub #OpenSource #SocialMedia #Username #Recon #CyberSecurity
🟣لینک مقاله:
https://github.com/sherlock-project/sherlock?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Sherlock (GitHub Repo)
🟢 خلاصه مقاله:
Sherlock یک ابزار متنباز در GitHub برای OSINT است که با جستوجوی خودکار username در صدها شبکه اجتماعی، حسابهای مرتبط را شناسایی میکند. این ابزار از خط فرمان اجرا میشود، برای تحقیق، پایش برند، شناسایی جعل هویت و راستیآزمایی مفید است و نتایج را بهصورت یک گزارش قابل استفاده ارائه میدهد. با این حال بهدلیل تفاوت رفتار پلتفرمها ممکن است خطا رخ دهد؛ بنابراین باید نتایج را اعتبارسنجی کرد و ابزار را مسئولانه و مطابق قوانین و شرایط استفاده هر سرویس به کار گرفت.
#OSINT #Sherlock #GitHub #OpenSource #SocialMedia #Username #Recon #CyberSecurity
🟣لینک مقاله:
https://github.com/sherlock-project/sherlock?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
GitHub
GitHub - sherlock-project/sherlock: Hunt down social media accounts by username across social networks
Hunt down social media accounts by username across social networks - sherlock-project/sherlock
🔵 عنوان مقاله
Ad and PR Giant Dentsu Says Hackers Stole Merkle Data (3 minute read)
🟢 خلاصه مقاله:
شرکت ژاپنی Dentsu اعلام کرد زیرمجموعهاش Merkle دچار نفوذ داده شده که اطلاعات حساس مشتریان، تأمینکنندگان و کارکنان را افشا کرده است. این رویداد پس از مشاهده فعالیت غیرعادی در شبکه Merkle شناسایی شد و برای مهار آن برخی سیستمها موقتاً از مدار خارج شدند. بررسی برای تعیین دامنه و نوع دادههای افشاشده ادامه دارد و احتمال اختلال موقت در سرویسها و افزایش ریسک فیشینگ و سوءاستفاده از اطلاعات برای ذینفعان وجود دارد.
#حمله_سایبری #نفوذ_داده #امنیت_اطلاعات #نشت_اطلاعات #Dentsu #Merkle #تبلیغات_دیجیتال #حریم_خصوصی
🟣لینک مقاله:
https://www.securityweek.com/ad-and-pr-giant-dentsu-says-hackers-stole-merkle-data/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Ad and PR Giant Dentsu Says Hackers Stole Merkle Data (3 minute read)
🟢 خلاصه مقاله:
شرکت ژاپنی Dentsu اعلام کرد زیرمجموعهاش Merkle دچار نفوذ داده شده که اطلاعات حساس مشتریان، تأمینکنندگان و کارکنان را افشا کرده است. این رویداد پس از مشاهده فعالیت غیرعادی در شبکه Merkle شناسایی شد و برای مهار آن برخی سیستمها موقتاً از مدار خارج شدند. بررسی برای تعیین دامنه و نوع دادههای افشاشده ادامه دارد و احتمال اختلال موقت در سرویسها و افزایش ریسک فیشینگ و سوءاستفاده از اطلاعات برای ذینفعان وجود دارد.
#حمله_سایبری #نفوذ_داده #امنیت_اطلاعات #نشت_اطلاعات #Dentsu #Merkle #تبلیغات_دیجیتال #حریم_خصوصی
🟣لینک مقاله:
https://www.securityweek.com/ad-and-pr-giant-dentsu-says-hackers-stole-merkle-data/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
SecurityWeek
Ad and PR Giant Dentsu Says Hackers Stole Merkle Data
Japan’s Dentsu has disclosed a Merkle data breach impacting clients, suppliers, and employees.
👍1
🔵 عنوان مقاله
Architecture Tests
🟢 خلاصه مقاله:
** تاراس Kizlo در ادامهٔ مجموعهٔ خود دربارهٔ سطوح تست، سراغ موضوع کمتر مطرحشدهای رفته است: تستهای معماری. او توضیح میدهد که این تستها مجموعهای از قواعد اجراییاند که مرزهای معماری، وابستگیهای مجاز، نبود حلقههای وابستگی و قواعد نامگذاری/لایهبندی را بررسی میکنند تا از فرسایش تدریجی طراحی جلوگیری شود. مقاله نشان میدهد چگونه میتوان این قواعد را کنار تستهای معمول و در CI/CD اجرا کرد و با ابزارهایی مثل ArchUnit یا NetArchTest آنها را به شکستپذیر کردن بیلد گره زد. توصیههای عملی شامل شروع از چند قانون پرتأثیر، پرهیز از قواعد شکننده، همگامسازی با تصمیمهای معماری و بهروزرسانی مداوم تستهاست. نتیجهٔ نهایی: تستهای معماری قصد طراحی را به قراردادهای قابل اجرا تبدیل میکنند و بهعنوان گاردریلهای ماندگار، ساختار سالم کد را حفظ میکنند.
#ArchitectureTests #SoftwareArchitecture #SoftwareTesting #CleanArchitecture #CI/CD #ArchUnit #NetArchTest #CodeQuality
🟣لینک مقاله:
https://cur.at/WG4foAM?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Architecture Tests
🟢 خلاصه مقاله:
** تاراس Kizlo در ادامهٔ مجموعهٔ خود دربارهٔ سطوح تست، سراغ موضوع کمتر مطرحشدهای رفته است: تستهای معماری. او توضیح میدهد که این تستها مجموعهای از قواعد اجراییاند که مرزهای معماری، وابستگیهای مجاز، نبود حلقههای وابستگی و قواعد نامگذاری/لایهبندی را بررسی میکنند تا از فرسایش تدریجی طراحی جلوگیری شود. مقاله نشان میدهد چگونه میتوان این قواعد را کنار تستهای معمول و در CI/CD اجرا کرد و با ابزارهایی مثل ArchUnit یا NetArchTest آنها را به شکستپذیر کردن بیلد گره زد. توصیههای عملی شامل شروع از چند قانون پرتأثیر، پرهیز از قواعد شکننده، همگامسازی با تصمیمهای معماری و بهروزرسانی مداوم تستهاست. نتیجهٔ نهایی: تستهای معماری قصد طراحی را به قراردادهای قابل اجرا تبدیل میکنند و بهعنوان گاردریلهای ماندگار، ساختار سالم کد را حفظ میکنند.
#ArchitectureTests #SoftwareArchitecture #SoftwareTesting #CleanArchitecture #CI/CD #ArchUnit #NetArchTest #CodeQuality
🟣لینک مقاله:
https://cur.at/WG4foAM?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Architecture Tests
Architecture tests are an essential part of maintaining a healthy architecture. First time hearing? No worries, we will explore what those…
به اون کاری که امروز کردی نگو "ریفکتور" (Refactor). اگه تست نداره، اون فقط یه "گندکاریِ تمیزه".
این فقط یه جملهی قشنگ نیست؛ این یه زخمه که من هنوز یادمه.
اوایل کارم، میخواستم قهرمان باشم. ️ تو یه پروژهی لگسی، یه "God Function" هزار خطی پیدا کردم و گفتم: "من اینو تمیز میکنم!"
نشستم و تیکهتیکهاش کردم. ۵۰ تا تابع کوچولوی تر و تمیز. اصل DRY رو پیاده کردم. ظاهر کد عالی شد. "تمیز" و "حرفهای". احساس غرور میکردم.
مشکل چی بود؟ اون کد اصلی لعنتی، یه دونه هم تست خودکار نداشت.
اونجا بود که فاجعه اتفاق افتاد. کاری که من انجام دادم، "ریفکتور" نبود؛ "تغییر دادنِ کورکورانه" بود.
اون کد "تمیز" من، چند تا باگ جدید و پنهان داشت. چرا؟ چون اون "کد اسپاگتی" زشت، پر از منطقهای تجاری پنهان و وابستگیهای زمانی بود که فقط تو همون حالت کار میکرد.
من "بدهی فنی" رو پرداخت نکردم؛ من یه بدهی کمبهره (مثل تکرار کد که فهمیدنش ساده بود) رو برداشتم و با یه بدهی پربهره (مثل یه "انتزاع اشتباه" که حالا دیباگ کردنش غیرممکنه) عوض کردم.
این "تلهی کد تمیز"ئه. مهمترین تعریفی که تو این صنعت باید بلد باشیم مال مایکل فدرز (Michael Feathers) ئه: "کد لگسی، کدیه که تست نداره." همین.
تو یه سیستم لگسی، قانون اول "تمیز کن" نیست. قانون اول اینه: "اول امنش کن." برو "تستهای مشخصهیابی" (Characterization Tests) بنویس تا رفتار فعلیِ سیستم (با همهی باگهاش) رو قفل کنی. وقتی اون تور ایمنی رو ساختی، اونوقت حق داری که شروع به تمیزکاری کنی.
<Hossein Moradi/>
این فقط یه جملهی قشنگ نیست؛ این یه زخمه که من هنوز یادمه.
اوایل کارم، میخواستم قهرمان باشم. ️ تو یه پروژهی لگسی، یه "God Function" هزار خطی پیدا کردم و گفتم: "من اینو تمیز میکنم!"
نشستم و تیکهتیکهاش کردم. ۵۰ تا تابع کوچولوی تر و تمیز. اصل DRY رو پیاده کردم. ظاهر کد عالی شد. "تمیز" و "حرفهای". احساس غرور میکردم.
مشکل چی بود؟ اون کد اصلی لعنتی، یه دونه هم تست خودکار نداشت.
اونجا بود که فاجعه اتفاق افتاد. کاری که من انجام دادم، "ریفکتور" نبود؛ "تغییر دادنِ کورکورانه" بود.
اون کد "تمیز" من، چند تا باگ جدید و پنهان داشت. چرا؟ چون اون "کد اسپاگتی" زشت، پر از منطقهای تجاری پنهان و وابستگیهای زمانی بود که فقط تو همون حالت کار میکرد.
من "بدهی فنی" رو پرداخت نکردم؛ من یه بدهی کمبهره (مثل تکرار کد که فهمیدنش ساده بود) رو برداشتم و با یه بدهی پربهره (مثل یه "انتزاع اشتباه" که حالا دیباگ کردنش غیرممکنه) عوض کردم.
این "تلهی کد تمیز"ئه. مهمترین تعریفی که تو این صنعت باید بلد باشیم مال مایکل فدرز (Michael Feathers) ئه: "کد لگسی، کدیه که تست نداره." همین.
تو یه سیستم لگسی، قانون اول "تمیز کن" نیست. قانون اول اینه: "اول امنش کن." برو "تستهای مشخصهیابی" (Characterization Tests) بنویس تا رفتار فعلیِ سیستم (با همهی باگهاش) رو قفل کنی. وقتی اون تور ایمنی رو ساختی، اونوقت حق داری که شروع به تمیزکاری کنی.
<Hossein Moradi/>
❤1👍1
🔵 عنوان مقاله
Understanding Playwright Agents
🟢 خلاصه مقاله:
**عرضه اخیر Playwright Agents یک گام مهم در خودکارسازی آزمونهای مرورگری است: بهجای نوشتن تکتک گامها، هدف را توصیف میکنید و عاملها با برنامهریزی، اجرا و پایش تکرارشونده، مسیر رسیدن به آن هدف را در مرورگرهای واقعی پیدا میکنند. این رویکرد با تکیه بر نقاط قوت Playwright—پوشش چندمرورگری، ابزارهای رهگیری و انتخابگرهای پایدار—زمان ساخت تست را کاهش میدهد و نگهداری را آسانتر میکند. معماری هسته شامل سه بخش برنامهریز، اجراکننده و ناظر است که با ترکیب منطق قطعی و استدلال مدلمحور تلاش میکند هم انعطافپذیر باشد و هم قابلیت بازپخش و مشاهدهپذیری را حفظ کند. Sławomir Radzymiński در یک بررسی عمیق، نحوه کار داخلی این عاملها، الگوی حلقه تصمیمگیری، ساخت مدل از DOM و مثالهای عملی (ورود، پرداخت، و پایدارسازی سناریوهای شکننده) را توضیح میدهد و در کنار آن، محدودیتها و بهترینروشها را نیز بیان میکند: تعریف هدف شفاف، استفاده از data-testid پایدار، محدود کردن عمق اکتشاف، و پینکردن محیط در CI. مسیر پیشنهادی پذیرش نیز استفاده از Agent برای اکتشاف و تولید تستهای اولیه و سپس تثبیت آنها به اسکریپتهای قطعی Playwright است.
#Playwright #PlaywrightAgents #E2ETesting #BrowserAutomation #TestAutomation #LLM #QA #DevTools
🟣لینک مقاله:
https://cur.at/NqUSz5D?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Understanding Playwright Agents
🟢 خلاصه مقاله:
**عرضه اخیر Playwright Agents یک گام مهم در خودکارسازی آزمونهای مرورگری است: بهجای نوشتن تکتک گامها، هدف را توصیف میکنید و عاملها با برنامهریزی، اجرا و پایش تکرارشونده، مسیر رسیدن به آن هدف را در مرورگرهای واقعی پیدا میکنند. این رویکرد با تکیه بر نقاط قوت Playwright—پوشش چندمرورگری، ابزارهای رهگیری و انتخابگرهای پایدار—زمان ساخت تست را کاهش میدهد و نگهداری را آسانتر میکند. معماری هسته شامل سه بخش برنامهریز، اجراکننده و ناظر است که با ترکیب منطق قطعی و استدلال مدلمحور تلاش میکند هم انعطافپذیر باشد و هم قابلیت بازپخش و مشاهدهپذیری را حفظ کند. Sławomir Radzymiński در یک بررسی عمیق، نحوه کار داخلی این عاملها، الگوی حلقه تصمیمگیری، ساخت مدل از DOM و مثالهای عملی (ورود، پرداخت، و پایدارسازی سناریوهای شکننده) را توضیح میدهد و در کنار آن، محدودیتها و بهترینروشها را نیز بیان میکند: تعریف هدف شفاف، استفاده از data-testid پایدار، محدود کردن عمق اکتشاف، و پینکردن محیط در CI. مسیر پیشنهادی پذیرش نیز استفاده از Agent برای اکتشاف و تولید تستهای اولیه و سپس تثبیت آنها به اسکریپتهای قطعی Playwright است.
#Playwright #PlaywrightAgents #E2ETesting #BrowserAutomation #TestAutomation #LLM #QA #DevTools
🟣لینک مقاله:
https://cur.at/NqUSz5D?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Awesome Testing
Understanding Playwright Agents
A deep dive into Playwright Agents and the Model Context Protocol (MCP) — how Microsoft’s latest AI-powered Playwright release automates test planning, script generation, and self-healing browser tests across Chrome, Firefox, and WebKit.
Forwarded from Gopher Job
A Data Structure Algorithms Low Level Design and High Level Design collection of resources.
مجموعهای از منابع برای طراحی low level و high level توی مصاحبههای الگوریتمی و برنامهنویسی
#DSA #LLD #HLD #Algorithm #Interview #Leetcode #Question
https://github.com/arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
مجموعهای از منابع برای طراحی low level و high level توی مصاحبههای الگوریتمی و برنامهنویسی
#DSA #LLD #HLD #Algorithm #Interview #Leetcode #Question
https://github.com/arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
GitHub
GitHub - arpit20adlakha/Data-Structure-Algorithms-LLD-HLD: A Data Structure Algorithms Low Level Design and High Level Design collection…
A Data Structure Algorithms Low Level Design and High Level Design collection of resources. - arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
👍1
🔵 عنوان مقاله
Improved BRICKSTORM YARA Rules (GitHub Repo)
🟢 خلاصه مقاله:
بهروزرسانی تازهای از سوی Florian Roth بر پایه گزارش Google درباره بدافزار BRICKSTORM منتشر شده که مجموعه قوانین YARA را در یک مخزن GitHub بهطور شفافتر، سریعتر و قابل اتکاتر میکند. او با حذف regexهای غیرضروری، کاهش خطای مثبت و بهبود کارایی اسکن را هدف گرفته و با شفافسازی encoding رشتهها و توالیهای بایتی، از رفتار یکسان قوانین در حالتهای مختلف اطمینان داده است. همچنین با سادهسازی و یکپارچهسازی قواعد، نگهداشت و فهم آنها آسانتر شده است. افزودهشدن metadata شامل ارجاع به گزارش Google، اطلاعات نویسنده و نسخه، شفافیت و قابلیت پیگیری را افزایش میدهد و استقرار و بهبود مستمر قوانین را برای تیمهای دفاعی سادهتر میکند.
#YARA #BRICKSTORM #MalwareDetection #ThreatIntel #Google #FlorianRoth #CyberSecurity #GitHub
🟣لینک مقاله:
https://github.com/Neo23x0/signature-base/blob/master/yara/apt_cn_brickstorm_sep25.yar?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Improved BRICKSTORM YARA Rules (GitHub Repo)
🟢 خلاصه مقاله:
بهروزرسانی تازهای از سوی Florian Roth بر پایه گزارش Google درباره بدافزار BRICKSTORM منتشر شده که مجموعه قوانین YARA را در یک مخزن GitHub بهطور شفافتر، سریعتر و قابل اتکاتر میکند. او با حذف regexهای غیرضروری، کاهش خطای مثبت و بهبود کارایی اسکن را هدف گرفته و با شفافسازی encoding رشتهها و توالیهای بایتی، از رفتار یکسان قوانین در حالتهای مختلف اطمینان داده است. همچنین با سادهسازی و یکپارچهسازی قواعد، نگهداشت و فهم آنها آسانتر شده است. افزودهشدن metadata شامل ارجاع به گزارش Google، اطلاعات نویسنده و نسخه، شفافیت و قابلیت پیگیری را افزایش میدهد و استقرار و بهبود مستمر قوانین را برای تیمهای دفاعی سادهتر میکند.
#YARA #BRICKSTORM #MalwareDetection #ThreatIntel #Google #FlorianRoth #CyberSecurity #GitHub
🟣لینک مقاله:
https://github.com/Neo23x0/signature-base/blob/master/yara/apt_cn_brickstorm_sep25.yar?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
GitHub
signature-base/yara/apt_cn_brickstorm_sep25.yar at master · Neo23x0/signature-base
YARA signature and IOC database for my scanners and tools - Neo23x0/signature-base
🔵 عنوان مقاله
Debugging Mobile Web Apps Shouldn't Be This Hard, So I Built a Logger
🟢 خلاصه مقاله:
بهگفتهی Nishant Bhandari، دیباگ اپلیکیشنهای وب موبایل بیش از حد دشوار شده است؛ ابزارهای دسکتاپ و ریموت همیشه شرایط واقعی دستگاه را نشان نمیدهند. او برای سادهسازی این روند، ابزار متنباز interactive-logger را معرفی میکند؛ ابزاری سبک که با افزودن یک قطعه کوچک، لاگها و خطاها را همانجا روی دستگاه و بهصورت لحظهای نمایش میدهد تا بازتولید و اشتراکگذاری باگها سریعتر و دقیقتر انجام شود. تمرکز این راهکار روی سادگی و کارکرد در سناریوهای رایج وب موبایل (مانند PWA و WebView) و بدون وابستگی به فریمورک است.
#MobileWeb #Debugging #DevTools #OpenSource #Logging #WebDev #JavaScript #Frontend
🟣لینک مقاله:
https://cur.at/vp45Wp0?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Debugging Mobile Web Apps Shouldn't Be This Hard, So I Built a Logger
🟢 خلاصه مقاله:
بهگفتهی Nishant Bhandari، دیباگ اپلیکیشنهای وب موبایل بیش از حد دشوار شده است؛ ابزارهای دسکتاپ و ریموت همیشه شرایط واقعی دستگاه را نشان نمیدهند. او برای سادهسازی این روند، ابزار متنباز interactive-logger را معرفی میکند؛ ابزاری سبک که با افزودن یک قطعه کوچک، لاگها و خطاها را همانجا روی دستگاه و بهصورت لحظهای نمایش میدهد تا بازتولید و اشتراکگذاری باگها سریعتر و دقیقتر انجام شود. تمرکز این راهکار روی سادگی و کارکرد در سناریوهای رایج وب موبایل (مانند PWA و WebView) و بدون وابستگی به فریمورک است.
#MobileWeb #Debugging #DevTools #OpenSource #Logging #WebDev #JavaScript #Frontend
🟣لینک مقاله:
https://cur.at/vp45Wp0?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Debugging Mobile Web Apps Shouldn’t Be This Hard — So I Built a Logger
The Nightmare Scenario
🔵 عنوان مقاله
Google Sues to Disrupt Chinese SMS Phishing Triad (2 minute read)
🟢 خلاصه مقاله:
Google در دادگاه Southern District of New York علیه ۲۵ نفر مرتبط با ابزار چینی Lighthouse شکایت کرده است؛ ابزاری از نوع phishing-as-a-service که با پیامکهای جعلی به نام USPS، اپراتورهای عوارض جادهای، پلتفرمهای تجارت الکترونیک و مؤسسات مالی، بیش از یک میلیون قربانی را در ۱۲۰ کشور هدف قرار داده است. این شبکه با هدایت کاربران به وبسایتهای موبایلی جعلی، دادههای کارت پرداخت را جمعآوری میکند و سپس با سوءاستفاده از فرایندهای ثبتنام قانونی Apple Pay و Google Pay، از طریق فریب کاربران برای ارائه کدهای یکبارمصرف، کارتهای سرقتشده را به کیفپولهای موبایلی متصل میسازد. هدف شکایت، مختلکردن زیرساخت این عملیات و بازدارندگی از الگوهای مشابه در مقیاس جهانی است.
#Cybersecurity #Phishing #SMSPhishing #Google #ApplePay #GooglePay #PhaaS #Fraud
🟣لینک مقاله:
https://krebsonsecurity.com/2025/11/google-sues-to-disrupt-chinese-sms-phishing-triad/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Google Sues to Disrupt Chinese SMS Phishing Triad (2 minute read)
🟢 خلاصه مقاله:
Google در دادگاه Southern District of New York علیه ۲۵ نفر مرتبط با ابزار چینی Lighthouse شکایت کرده است؛ ابزاری از نوع phishing-as-a-service که با پیامکهای جعلی به نام USPS، اپراتورهای عوارض جادهای، پلتفرمهای تجارت الکترونیک و مؤسسات مالی، بیش از یک میلیون قربانی را در ۱۲۰ کشور هدف قرار داده است. این شبکه با هدایت کاربران به وبسایتهای موبایلی جعلی، دادههای کارت پرداخت را جمعآوری میکند و سپس با سوءاستفاده از فرایندهای ثبتنام قانونی Apple Pay و Google Pay، از طریق فریب کاربران برای ارائه کدهای یکبارمصرف، کارتهای سرقتشده را به کیفپولهای موبایلی متصل میسازد. هدف شکایت، مختلکردن زیرساخت این عملیات و بازدارندگی از الگوهای مشابه در مقیاس جهانی است.
#Cybersecurity #Phishing #SMSPhishing #Google #ApplePay #GooglePay #PhaaS #Fraud
🟣لینک مقاله:
https://krebsonsecurity.com/2025/11/google-sues-to-disrupt-chinese-sms-phishing-triad/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Krebs on Security
Google Sues to Disrupt Chinese SMS Phishing Triad
Google is suing more than two dozen unnamed individuals allegedly involved in peddling a popular China-based mobile phishing service that helps scammers impersonate hundreds of trusted brands, blast out text message lures, and convert phished payment card…
🔵 عنوان مقاله
Vulnerability in Dolby Decoder Can Allow Zero-Click Attacks (2 minute read)
🟢 خلاصه مقاله:
پژوهشگران Google's Project Zero یک آسیبپذیری ناشی از buffer overflow را در Dolby's Unified Decoder پیدا کردهاند؛ مولفهای که در Android برای decode کردن محلی تمام پیامها و پیوستهای صوتی بهکار میرود. این نقص میتواند به remote code execution منجر شود و بهدلیل اجرای خودکار فرآیند decode در مسیر رسانهای سیستم، امکان حملات zero-click را فراهم میکند؛ بدون اینکه کاربر کاری انجام دهد. از آنجا که بسیاری از اپها در Android برای پردازشهای پسزمینه (مثل پیشنمایش یا استخراج اطلاعات صوتی) به همین decoder تکیه میکنند، سطح حمله گسترده است. توصیه میشود بهمحض انتشار، بهروزرسانیهای امنیتی Android و سازندگان دستگاه اعمال شود و از سختسازی مسیرهای رسانهای، sandboxing و شیوههای ایمن حافظه استفاده شود.
#Android #Security #Vulnerability #ZeroClick #RCE #Dolby #ProjectZero #Cybersecurity
🟣لینک مقاله:
https://www.securityweek.com/vulnerability-in-dolby-decoder-can-allow-zero-click-attacks/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Vulnerability in Dolby Decoder Can Allow Zero-Click Attacks (2 minute read)
🟢 خلاصه مقاله:
پژوهشگران Google's Project Zero یک آسیبپذیری ناشی از buffer overflow را در Dolby's Unified Decoder پیدا کردهاند؛ مولفهای که در Android برای decode کردن محلی تمام پیامها و پیوستهای صوتی بهکار میرود. این نقص میتواند به remote code execution منجر شود و بهدلیل اجرای خودکار فرآیند decode در مسیر رسانهای سیستم، امکان حملات zero-click را فراهم میکند؛ بدون اینکه کاربر کاری انجام دهد. از آنجا که بسیاری از اپها در Android برای پردازشهای پسزمینه (مثل پیشنمایش یا استخراج اطلاعات صوتی) به همین decoder تکیه میکنند، سطح حمله گسترده است. توصیه میشود بهمحض انتشار، بهروزرسانیهای امنیتی Android و سازندگان دستگاه اعمال شود و از سختسازی مسیرهای رسانهای، sandboxing و شیوههای ایمن حافظه استفاده شود.
#Android #Security #Vulnerability #ZeroClick #RCE #Dolby #ProjectZero #Cybersecurity
🟣لینک مقاله:
https://www.securityweek.com/vulnerability-in-dolby-decoder-can-allow-zero-click-attacks/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
SecurityWeek
Vulnerability in Dolby Decoder Can Allow Zero-Click Attacks
On Android, the out-of-bounds write issue can be triggered during the processing of media files without user interaction.
👍1
🔵 عنوان مقاله
How I Automated Test Scope Analysis with a CLI Tool
🟢 خلاصه مقاله:
** Josphine Job روند ساخت یک ابزار CLI با Node.js را توضیح میدهد که با استفاده از GitHub API تغییرات کد را بهسرعت تحلیل میکند و پیشنهادهای هوشمند برای محدودهٔ تست ارائه میدهد. این ابزار با دریافت اطلاعات PR و commitها، فایلهای تغییرکرده را بررسی و وابستگیها را تحلیل میکند و سپس با لایهٔ هوش مصنوعی، سناریوهای تست اولویتدار (از واحد تا یکپارچه) پیشنهاد میدهد. خروجی میتواند در ترمینال، بهصورت Markdown/JSON، یا بهعنوان کامنت CI روی PR نمایش داده شود. ملاحظاتی مانند کشکردن، رعایت حریم خصوصی، و fallback آفلاین در نظر گرفته شده و هدف، کوتاهکردن چرخهٔ بازخورد و افزایش پوشش و اعتماد به تغییرات کد است.
#TestAutomation #CLI #NodeJS #GitHubAPI #AIinTesting #DevTools #CICD #SoftwareQuality
🟣لینک مقاله:
https://cur.at/SDG4cgz?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
How I Automated Test Scope Analysis with a CLI Tool
🟢 خلاصه مقاله:
** Josphine Job روند ساخت یک ابزار CLI با Node.js را توضیح میدهد که با استفاده از GitHub API تغییرات کد را بهسرعت تحلیل میکند و پیشنهادهای هوشمند برای محدودهٔ تست ارائه میدهد. این ابزار با دریافت اطلاعات PR و commitها، فایلهای تغییرکرده را بررسی و وابستگیها را تحلیل میکند و سپس با لایهٔ هوش مصنوعی، سناریوهای تست اولویتدار (از واحد تا یکپارچه) پیشنهاد میدهد. خروجی میتواند در ترمینال، بهصورت Markdown/JSON، یا بهعنوان کامنت CI روی PR نمایش داده شود. ملاحظاتی مانند کشکردن، رعایت حریم خصوصی، و fallback آفلاین در نظر گرفته شده و هدف، کوتاهکردن چرخهٔ بازخورد و افزایش پوشش و اعتماد به تغییرات کد است.
#TestAutomation #CLI #NodeJS #GitHubAPI #AIinTesting #DevTools #CICD #SoftwareQuality
🟣لینک مقاله:
https://cur.at/SDG4cgz?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
How I Automated Test Scope Analysis with a CLI Tool
A Node.js tool that uses GitHub APIs to instantly analyze code changes, and generate AI-powered test recommendations
Forwarded from Linux Labdon
کاهش هزینه سیستمهای هوش مصنوعی با Semantic Caching
با رشد مدلهای زبانی بزرگ و پیشرفته، هزینه و زمان پاسخدهی هم به شدت افزایش پیدا کرده. مدلهایی مثل GPT-5 یا Claude برای کارهای پیچیده فوقالعادهاند، ولی استفاده از اونها هم پرهزینه و هم کند محسوب میشه. از طرف دیگه، AI Agentها واقعاً «توکنخور» هستن؛ یعنی برای انجام یک کار معمولاً چندین مرحله طی میکنن: تحقیق، برنامهریزی، عمل و بازتاب و تکرار. همین باعث میشه چندین بار با مدل تماس بگیرن و در نتیجه هزینه و تأخیر افزایش پیدا کنه و متنهای طولانیتر تولید بشه. برای مثال، یه بنچمارک اخیر از TheAgentCompany در ۲۰۲۵ نشون داده اجرای کامل یک Agent گاهی تا ۶.۸ دلار هزینه داره.
یکی از مشکلات اصلی در دنیای واقعی، تکراری بودن سوالهاست، مخصوصاً توی پشتیبانی مشتری. کاربران دائماً سوالهای مشابهی میپرسن: مثل «چطور پولم رو پس بگیرم؟» یا «شرایط بازگشت وجه چیه؟» و Agent مجبور میشه هر بار پاسخ رو از صفر تولید کنه. نتیجهش افزایش هزینه، طولانی شدن زمان پاسخ و فشار بیشتر روی سیستمهای RAG و زیرساختهاست.
در نگاه اول، ممکنه فکر کنیم کش کلاسیک کفایت میکنه. ایدهی کش ساده اینه که اگر یک سوال قبلاً پاسخ داده شده، دوباره سراغ مدل نریم. ولی مشکل اینجاست که کش سنتی دنبال Exact Match یا تطابق دقیق متنه. سوالهایی که از نظر معنی یکی هستن ولی عبارتهاشون فرق میکنه، مثل: «میخوام پولم رو پس بگیرم»، «چطور میتونم درخواست بازگشت وجه بدم؟» و «سیاست بازگشت پولتون چیه؟»، همه Cache Miss میشن و کش عملاً استفاده نمیشه.
اینجاست که Semantic Caching وارد میشه. به جای تطابق کلمهبهکلمه، کش به معنی و مفهوم جمله نگاه میکنه. مزیت اصلیش اینه که Recall و Hit Rate بالاتره و احتمال استفاده از کش و صرفهجویی خیلی بیشتر میشه. البته چالشش هم اینه که گاهی ممکنه جواب بیربط بده یا همون «False Positive» رخ بده.
روش کار Semantic Caching ساده است ولی هوشمندانه: ابتدا سوال کاربر به Embedding یا بردار عددی تبدیل میشه. بعد با بردارهای موجود در کش با Semantic Search مقایسه میشه. اگر فاصله معنایی کم باشه، پاسخ از کش برگردونده میشه؛ در غیر این صورت به RAG یا LLM میریم. در نهایت سوال و پاسخ جدید هم ذخیره میشه تا دفعه بعدی قابل استفاده باشه.
پیادهسازی Semantic Caching با چالشهایی همراهه؛ مثل دقت (Accuracy) که آیا کش جواب درست میده، کارایی (Performance) و میزان Cache Hit، سرعت سرویسدهی، آپدیتپذیری کش و اینکه آیا میتونیم کش رو گرم، تازهسازی یا پاکسازی کنیم. همچنین مشاهدهپذیری (Observability) مهمه تا بتونیم hit rate، latency، صرفهجویی هزینه و کیفیت کش رو بسنجیم.
معیارهای اصلی سنجش کش شامل Cache Hit Rate هست که نشون میده چند درصد درخواستها از کش پاسخ داده میشن و Precision/Recall/F1 Score که کیفیت و دقت پاسخها رو مشخص میکنه. برای بهبود دقت و کارایی کش هم میتونیم Threshold فاصله رو تنظیم کنیم، Reranker اضافه کنیم مثل Cross-encoder یا LLM-as-a-judge، از Fuzzy Matching برای تایپوها استفاده کنیم و فیلترهای اضافی مثل تشخیص پرسشهای زمانمحور (Temporal) یا تشخیص کد (Python، Java و…) اعمال کنیم تا سوالات اشتباه وارد کش نشن.
یه مثال واقعی از این تکنولوژی پروژه waLLMartCache در Walmart هست. اونها با نوآوریهایی مثل Load Balancer برای توزیع کش روی چند Node و Dual-tiered Storage که L1 = Vector DB و L2 = In-memory Cache مثل Redis هست، هم سرعت و هم دقت رو بالا بردن. Multi-tenancy هم باعث شده چند تیم یا اپلیکیشن از یک زیرساخت مشترک استفاده کنن. Decision Engine هم شامل تشخیص کد و زمانه و اگر سوال مناسب کش نباشه مستقیماً به LLM یا RAG میره. نتیجهش رسیدن به دقت نزدیک ۹۰٪ بوده.
<Reza Jafari/>
👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
با رشد مدلهای زبانی بزرگ و پیشرفته، هزینه و زمان پاسخدهی هم به شدت افزایش پیدا کرده. مدلهایی مثل GPT-5 یا Claude برای کارهای پیچیده فوقالعادهاند، ولی استفاده از اونها هم پرهزینه و هم کند محسوب میشه. از طرف دیگه، AI Agentها واقعاً «توکنخور» هستن؛ یعنی برای انجام یک کار معمولاً چندین مرحله طی میکنن: تحقیق، برنامهریزی، عمل و بازتاب و تکرار. همین باعث میشه چندین بار با مدل تماس بگیرن و در نتیجه هزینه و تأخیر افزایش پیدا کنه و متنهای طولانیتر تولید بشه. برای مثال، یه بنچمارک اخیر از TheAgentCompany در ۲۰۲۵ نشون داده اجرای کامل یک Agent گاهی تا ۶.۸ دلار هزینه داره.
یکی از مشکلات اصلی در دنیای واقعی، تکراری بودن سوالهاست، مخصوصاً توی پشتیبانی مشتری. کاربران دائماً سوالهای مشابهی میپرسن: مثل «چطور پولم رو پس بگیرم؟» یا «شرایط بازگشت وجه چیه؟» و Agent مجبور میشه هر بار پاسخ رو از صفر تولید کنه. نتیجهش افزایش هزینه، طولانی شدن زمان پاسخ و فشار بیشتر روی سیستمهای RAG و زیرساختهاست.
در نگاه اول، ممکنه فکر کنیم کش کلاسیک کفایت میکنه. ایدهی کش ساده اینه که اگر یک سوال قبلاً پاسخ داده شده، دوباره سراغ مدل نریم. ولی مشکل اینجاست که کش سنتی دنبال Exact Match یا تطابق دقیق متنه. سوالهایی که از نظر معنی یکی هستن ولی عبارتهاشون فرق میکنه، مثل: «میخوام پولم رو پس بگیرم»، «چطور میتونم درخواست بازگشت وجه بدم؟» و «سیاست بازگشت پولتون چیه؟»، همه Cache Miss میشن و کش عملاً استفاده نمیشه.
اینجاست که Semantic Caching وارد میشه. به جای تطابق کلمهبهکلمه، کش به معنی و مفهوم جمله نگاه میکنه. مزیت اصلیش اینه که Recall و Hit Rate بالاتره و احتمال استفاده از کش و صرفهجویی خیلی بیشتر میشه. البته چالشش هم اینه که گاهی ممکنه جواب بیربط بده یا همون «False Positive» رخ بده.
روش کار Semantic Caching ساده است ولی هوشمندانه: ابتدا سوال کاربر به Embedding یا بردار عددی تبدیل میشه. بعد با بردارهای موجود در کش با Semantic Search مقایسه میشه. اگر فاصله معنایی کم باشه، پاسخ از کش برگردونده میشه؛ در غیر این صورت به RAG یا LLM میریم. در نهایت سوال و پاسخ جدید هم ذخیره میشه تا دفعه بعدی قابل استفاده باشه.
پیادهسازی Semantic Caching با چالشهایی همراهه؛ مثل دقت (Accuracy) که آیا کش جواب درست میده، کارایی (Performance) و میزان Cache Hit، سرعت سرویسدهی، آپدیتپذیری کش و اینکه آیا میتونیم کش رو گرم، تازهسازی یا پاکسازی کنیم. همچنین مشاهدهپذیری (Observability) مهمه تا بتونیم hit rate، latency، صرفهجویی هزینه و کیفیت کش رو بسنجیم.
معیارهای اصلی سنجش کش شامل Cache Hit Rate هست که نشون میده چند درصد درخواستها از کش پاسخ داده میشن و Precision/Recall/F1 Score که کیفیت و دقت پاسخها رو مشخص میکنه. برای بهبود دقت و کارایی کش هم میتونیم Threshold فاصله رو تنظیم کنیم، Reranker اضافه کنیم مثل Cross-encoder یا LLM-as-a-judge، از Fuzzy Matching برای تایپوها استفاده کنیم و فیلترهای اضافی مثل تشخیص پرسشهای زمانمحور (Temporal) یا تشخیص کد (Python، Java و…) اعمال کنیم تا سوالات اشتباه وارد کش نشن.
یه مثال واقعی از این تکنولوژی پروژه waLLMartCache در Walmart هست. اونها با نوآوریهایی مثل Load Balancer برای توزیع کش روی چند Node و Dual-tiered Storage که L1 = Vector DB و L2 = In-memory Cache مثل Redis هست، هم سرعت و هم دقت رو بالا بردن. Multi-tenancy هم باعث شده چند تیم یا اپلیکیشن از یک زیرساخت مشترک استفاده کنن. Decision Engine هم شامل تشخیص کد و زمانه و اگر سوال مناسب کش نباشه مستقیماً به LLM یا RAG میره. نتیجهش رسیدن به دقت نزدیک ۹۰٪ بوده.
<Reza Jafari/>
👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
❤2
🔵 عنوان مقاله
Seriously Testing LLMs
🟢 خلاصه مقاله:
این مقاله به این میپردازد که برای آزمون جدی LLMs چه نیاز است. نویسنده با تکیه بر مجموعهای از آزمایشها، نشان میدهد چرا اتکا به دمو یا امتیازهای سطحی کافی نیست و چگونه رفتار مدل با تغییر متن راهنما، زمینه و زمان تغییر میکند. James Bach در این مسیر روش LARC را معرفی میکند؛ رویکردی ساختیافته و اکتشافی برای برنامهریزی، اجرای آزمونها و تفسیر نتایج که بر طراحی موارد تنشی و خصمانه، مشاهده نظاممند و بهبود تکرارشونده تأکید دارد تا الگوهای خطا و محدودیتهای قابلیت اعتماد آشکار شوند. مقاله توضیح میدهد که چرا آزمون جامع دشوار و پرهزینه است: خروجیهای غیرقطعی، نبود داور قطعی برای «درستی»، حساسیت به Prompt و زمینه، بهروزرسانیهای مدل که بازتولیدپذیری را میشکنند، محدودیت معیارهای کمی، و نیاز به ابزار، داده، محاسبات و داوری انسانی. در نهایت پیشنهاد میشود آزمون LLM را یک کار تحقیقاتی-حرفهای ببینیم: اهداف و ریسکها را روشن کنیم، دادههای متنوع و خصمانه بسازیم، ثبت و رهگیری کامل انجام دهیم، و با اجرای تکرارشونده روش LARC میان عمق و وسعت، خودکارسازی و قضاوت کارشناسی، و هزینه و کفایت تصمیمگیری کنیم.
#LLMs #SoftwareTesting #AIQuality #Evaluation #PromptEngineering #Reliability #JamesBach #MachineLearning
🟣لینک مقاله:
https://cur.at/OfLtyHW?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Seriously Testing LLMs
🟢 خلاصه مقاله:
این مقاله به این میپردازد که برای آزمون جدی LLMs چه نیاز است. نویسنده با تکیه بر مجموعهای از آزمایشها، نشان میدهد چرا اتکا به دمو یا امتیازهای سطحی کافی نیست و چگونه رفتار مدل با تغییر متن راهنما، زمینه و زمان تغییر میکند. James Bach در این مسیر روش LARC را معرفی میکند؛ رویکردی ساختیافته و اکتشافی برای برنامهریزی، اجرای آزمونها و تفسیر نتایج که بر طراحی موارد تنشی و خصمانه، مشاهده نظاممند و بهبود تکرارشونده تأکید دارد تا الگوهای خطا و محدودیتهای قابلیت اعتماد آشکار شوند. مقاله توضیح میدهد که چرا آزمون جامع دشوار و پرهزینه است: خروجیهای غیرقطعی، نبود داور قطعی برای «درستی»، حساسیت به Prompt و زمینه، بهروزرسانیهای مدل که بازتولیدپذیری را میشکنند، محدودیت معیارهای کمی، و نیاز به ابزار، داده، محاسبات و داوری انسانی. در نهایت پیشنهاد میشود آزمون LLM را یک کار تحقیقاتی-حرفهای ببینیم: اهداف و ریسکها را روشن کنیم، دادههای متنوع و خصمانه بسازیم، ثبت و رهگیری کامل انجام دهیم، و با اجرای تکرارشونده روش LARC میان عمق و وسعت، خودکارسازی و قضاوت کارشناسی، و هزینه و کفایت تصمیمگیری کنیم.
#LLMs #SoftwareTesting #AIQuality #Evaluation #PromptEngineering #Reliability #JamesBach #MachineLearning
🟣لینک مقاله:
https://cur.at/OfLtyHW?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Satisfice, Inc.
Seriously Testing LLMs - Satisfice, Inc.
Michael and I are getting a lot of interest about how we apply Rapid Software Testing methodology both to test AI and to use AI in testing. We've developed various answers to such questions in recent years. But now that the book is done (and almost out!)…
👍1
🔵 عنوان مقاله
Spotter (GitHub Repo)
🟢 خلاصه مقاله:
Spotter یک اسکنر امنیتی متنباز در GitHub است که با تکیه بر قوانین مبتنی بر CEL، تنظیمات ناایمن و خطاهای پیکربندی را در خوشههای Kubernetes شناسایی میکند. این ابزار میتواند انواع منابع Kubernetes را بررسی کند، قواعد سفارشیسازیشده را برای استانداردهای داخلی پشتیبانی کند و هم روی خوشههای اجراشده و هم پیش از استقرار (در CI/CD یا GitOps) به کار رود. رویکرد policy-as-code آن، کشف سریع و قابلاقدام مسائل امنیتی و اجرای یکپارچه سیاستها را ممکن میسازد؛ هرچند جایگزین لایههای دیگر مانند پایش در زمان اجرا یا اسکن تصاویر نیست و مکمل آنهاست.
#Kubernetes #Security #CEL #DevSecOps #CloudNative #OpenSource #PolicyAsCode #SecurityScanning
🟣لینک مقاله:
https://github.com/madhuakula/spotter?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Spotter (GitHub Repo)
🟢 خلاصه مقاله:
Spotter یک اسکنر امنیتی متنباز در GitHub است که با تکیه بر قوانین مبتنی بر CEL، تنظیمات ناایمن و خطاهای پیکربندی را در خوشههای Kubernetes شناسایی میکند. این ابزار میتواند انواع منابع Kubernetes را بررسی کند، قواعد سفارشیسازیشده را برای استانداردهای داخلی پشتیبانی کند و هم روی خوشههای اجراشده و هم پیش از استقرار (در CI/CD یا GitOps) به کار رود. رویکرد policy-as-code آن، کشف سریع و قابلاقدام مسائل امنیتی و اجرای یکپارچه سیاستها را ممکن میسازد؛ هرچند جایگزین لایههای دیگر مانند پایش در زمان اجرا یا اسکن تصاویر نیست و مکمل آنهاست.
#Kubernetes #Security #CEL #DevSecOps #CloudNative #OpenSource #PolicyAsCode #SecurityScanning
🟣لینک مقاله:
https://github.com/madhuakula/spotter?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
GitHub
GitHub - madhuakula/spotter: Spotter is a comprehensive Kubernetes security scanner that uses CEL-based rules to identify security…
Spotter is a comprehensive Kubernetes security scanner that uses CEL-based rules to identify security vulnerabilities, misconfigurations, and compliance violations across your Kubernetes clusters, ...
🔵 عنوان مقاله
AI in Testing: Hype or Real Progress?
🟢 خلاصه مقاله:
این یادداشت با نگاهی عملگرایانه، دیدگاه Arik Aharoni را درباره نقش واقعی هوش مصنوعی در تست نرمافزار شرح میدهد: او نشان میدهد کجاها AI ارزش ملموس ایجاد کرده و کجاها همچنان اغراق میشود. بهگفته او، AI در تولید اولیه تستها از نیازمندیها، پیشنهاد موارد مرزی، کاهش شکنندگی تستهای UI، شناسایی تستهای flaky، خوشهبندی خطاها، اولویتبندی ریسکمحور و ساخت دادههای آزمایشی مفید است؛ همچنین در بررسیهای بصری و دسترسپذیری میتواند رگرسیونهای ظریف را آشکار کند.
در مقابل، خطاهای مدلهای زبانی، عدم درک عمیق دامنه، محدودیتهای امنیت و حریم خصوصی، و دشواری ارزیابی کیفیت تستهای تولیدی، مانع اعتماد کامل میشوند. «عاملهای» خودمختار تست بدون نظارت انسانی هنوز پایدار نیستند و AI جایگزین طراحی آگاه از معماری، تحلیل ریسک و تأیید انسانی نمیشود.
جمعبندی Aharoni این است: پیشروی واقعی اما تدریجی است. با اجرای آزمایشی کوچک، معیارهای روشن (مانند نرخ کشف عیب و پایداری تست) و جریانهای human-in-the-loop، میتوان از AI در حوزههایی با سیگنال قوی—مثل نگهداشت و تریاژ شکستها—بهره برد؛ AI باید مکمل مهارت تیمهای QA و مهندسی باشد، نه جایگزین آن.
#AIinTesting #SoftwareTesting #QA #TestAutomation #QualityEngineering #LLM #DevOps #TestStrategy
🟣لینک مقاله:
https://cur.at/6kIevSo?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
AI in Testing: Hype or Real Progress?
🟢 خلاصه مقاله:
این یادداشت با نگاهی عملگرایانه، دیدگاه Arik Aharoni را درباره نقش واقعی هوش مصنوعی در تست نرمافزار شرح میدهد: او نشان میدهد کجاها AI ارزش ملموس ایجاد کرده و کجاها همچنان اغراق میشود. بهگفته او، AI در تولید اولیه تستها از نیازمندیها، پیشنهاد موارد مرزی، کاهش شکنندگی تستهای UI، شناسایی تستهای flaky، خوشهبندی خطاها، اولویتبندی ریسکمحور و ساخت دادههای آزمایشی مفید است؛ همچنین در بررسیهای بصری و دسترسپذیری میتواند رگرسیونهای ظریف را آشکار کند.
در مقابل، خطاهای مدلهای زبانی، عدم درک عمیق دامنه، محدودیتهای امنیت و حریم خصوصی، و دشواری ارزیابی کیفیت تستهای تولیدی، مانع اعتماد کامل میشوند. «عاملهای» خودمختار تست بدون نظارت انسانی هنوز پایدار نیستند و AI جایگزین طراحی آگاه از معماری، تحلیل ریسک و تأیید انسانی نمیشود.
جمعبندی Aharoni این است: پیشروی واقعی اما تدریجی است. با اجرای آزمایشی کوچک، معیارهای روشن (مانند نرخ کشف عیب و پایداری تست) و جریانهای human-in-the-loop، میتوان از AI در حوزههایی با سیگنال قوی—مثل نگهداشت و تریاژ شکستها—بهره برد؛ AI باید مکمل مهارت تیمهای QA و مهندسی باشد، نه جایگزین آن.
#AIinTesting #SoftwareTesting #QA #TestAutomation #QualityEngineering #LLM #DevOps #TestStrategy
🟣لینک مقاله:
https://cur.at/6kIevSo?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Software Test Management | Testuff | SaaS Test Management
AI in Testing: Hype or Real Progress? | Software Test Management | Testuff
Discover how AI is reshaping software testing, from self-healing automation to predictive quality insights, and what it means for the future of QA.
وقتی غولها هم زمین میخورند!
قطعی گسترده اخیر سرویسهای کلادفلر (Cloudflare) که ناشی از یک تغییر پیکربندی (Configuration Change) بود، یک واقعیت قاطع را به ما یادآوری کرد: قابلیت اطمینان ۱۰۰ درصدی یک توهم است.
موفقیت در دنیای فناوری، در طراحی برای شکست (Design for Failure) و توانایی بازگشت سریع و شفاف است.
۴ درس عملیاتی حیاتی برای افزایش پایداری سیستم (Resilience)
این واقعه، یک مطالعه موردی ارزشمند برای هر سازمان در حال رشدی است که بر روی سیستمهای توزیعشده (Distributed Systems) کار میکند:
۱. کاهش دامنه خطا (Blast Radius Reduction)
چالش: انتشار سریع یک خطای پیکربندی در کل شبکه.
استراتژی: پیادهسازی سختگیرانه انتشار تدریجی (Canary Deployments) و تقسیمبندی منطقی شبکه (Segmentation).
نکته کاربردی: مطمئن شوید که خطاهای پیکربندی در یک "منطقه کوچک" محبوس شده و پیش از گسترش به تمام نقاط، آزمایش شوند. فرآیندهای انتشار خود را مجدداً بررسی کنید.
۲. اهمیت شفافیت و ارتباطات بحران (Crisis Comms)
چالش: بیاعتمادی مشتریان در زمان سکوت.
استراتژی: از یک کانال ارتباطی ثانویه و کاملاً ایزوله (مانند یک صفحه وضعیت روی زیرساخت متفاوت) استفاده کنید.
نکته کاربردی: صداقت فنی را در اولویت قرار دهید. بهروزرسانیهای مکرر و فنی، حتی اگر کوتاه باشند ("ما هنوز در حال بررسی هستیم")، اعتماد را حفظ میکنند.
۳. مقاومت در برابر شکستهای آبشاری (Cascading Failures)
چالش: تبدیل یک مشکل کوچک به یک بحران گسترده.
استراتژی: حذف وابستگیهای متقابل (Decoupling) بین سرویسهای حیاتی. اطمینان حاصل کنید که شکست یک سرویس فرعی، سرویس اصلی را از کار نیندازد.
نکته کاربردی: پیادهسازی مدارهای قطع کننده (Circuit Breakers) در کد، که در صورت شکست یک سرویس وابسته، درخواست را دور زده یا پاسخ از پیش تعیین شده (Failover) ارائه دهند.
۴. یادگیری پس از واقعه (Blameless Post-Mortem)
چالش: تکرار مشکلات بدون تحلیل عمیق.
استراتژی: بلافاصله یک تحلیل بدون سرزنش (Blameless Post-Mortem) آغاز کنید.
نکته کاربردی: تمرکز بر درک دلایل ریشهای و بهبود فرآیندها، نه پیدا کردن مقصر. انتشار سریع و عمیق گزارش فنی (مانند کاری که کلادفلر انجام داد)، به بازگرداندن اعتماد و آموزش جامعه فنی کمک میکند.
اقدام کلیدی برای رهبران
این رویداد را به عنوان یک هشدار (Wake-Up Call) ببینید. آیا استراتژیهای انتشار و طرحهای ارتباطی شما میتوانند در برابر یک خطای غیرمنتظره داخلی مقاومت کنند؟
"در دسترس بودن ۱۰۰ درصدی یک رؤیاست، بازگشت سریع و شفافیت ۱۰۰ درصدی یک تعهد است."
<Alireza DavoodiNia/>
قطعی گسترده اخیر سرویسهای کلادفلر (Cloudflare) که ناشی از یک تغییر پیکربندی (Configuration Change) بود، یک واقعیت قاطع را به ما یادآوری کرد: قابلیت اطمینان ۱۰۰ درصدی یک توهم است.
موفقیت در دنیای فناوری، در طراحی برای شکست (Design for Failure) و توانایی بازگشت سریع و شفاف است.
۴ درس عملیاتی حیاتی برای افزایش پایداری سیستم (Resilience)
این واقعه، یک مطالعه موردی ارزشمند برای هر سازمان در حال رشدی است که بر روی سیستمهای توزیعشده (Distributed Systems) کار میکند:
۱. کاهش دامنه خطا (Blast Radius Reduction)
چالش: انتشار سریع یک خطای پیکربندی در کل شبکه.
استراتژی: پیادهسازی سختگیرانه انتشار تدریجی (Canary Deployments) و تقسیمبندی منطقی شبکه (Segmentation).
نکته کاربردی: مطمئن شوید که خطاهای پیکربندی در یک "منطقه کوچک" محبوس شده و پیش از گسترش به تمام نقاط، آزمایش شوند. فرآیندهای انتشار خود را مجدداً بررسی کنید.
۲. اهمیت شفافیت و ارتباطات بحران (Crisis Comms)
چالش: بیاعتمادی مشتریان در زمان سکوت.
استراتژی: از یک کانال ارتباطی ثانویه و کاملاً ایزوله (مانند یک صفحه وضعیت روی زیرساخت متفاوت) استفاده کنید.
نکته کاربردی: صداقت فنی را در اولویت قرار دهید. بهروزرسانیهای مکرر و فنی، حتی اگر کوتاه باشند ("ما هنوز در حال بررسی هستیم")، اعتماد را حفظ میکنند.
۳. مقاومت در برابر شکستهای آبشاری (Cascading Failures)
چالش: تبدیل یک مشکل کوچک به یک بحران گسترده.
استراتژی: حذف وابستگیهای متقابل (Decoupling) بین سرویسهای حیاتی. اطمینان حاصل کنید که شکست یک سرویس فرعی، سرویس اصلی را از کار نیندازد.
نکته کاربردی: پیادهسازی مدارهای قطع کننده (Circuit Breakers) در کد، که در صورت شکست یک سرویس وابسته، درخواست را دور زده یا پاسخ از پیش تعیین شده (Failover) ارائه دهند.
۴. یادگیری پس از واقعه (Blameless Post-Mortem)
چالش: تکرار مشکلات بدون تحلیل عمیق.
استراتژی: بلافاصله یک تحلیل بدون سرزنش (Blameless Post-Mortem) آغاز کنید.
نکته کاربردی: تمرکز بر درک دلایل ریشهای و بهبود فرآیندها، نه پیدا کردن مقصر. انتشار سریع و عمیق گزارش فنی (مانند کاری که کلادفلر انجام داد)، به بازگرداندن اعتماد و آموزش جامعه فنی کمک میکند.
اقدام کلیدی برای رهبران
این رویداد را به عنوان یک هشدار (Wake-Up Call) ببینید. آیا استراتژیهای انتشار و طرحهای ارتباطی شما میتوانند در برابر یک خطای غیرمنتظره داخلی مقاومت کنند؟
"در دسترس بودن ۱۰۰ درصدی یک رؤیاست، بازگشت سریع و شفافیت ۱۰۰ درصدی یک تعهد است."
<Alireza DavoodiNia/>
🔵 عنوان مقاله
The New QA Mindset: Testing AI and LLMs
🟢 خلاصه مقاله:
تست محصولات مبتنی بر AI و بهویژه LLMs با نرمافزارهای کلاسیک فرق اساسی دارد: خروجیها قطعی نیستند و به داده، پرامپت و زمینه وابستهاند. در نتیجه بهجای «صحت دقیق»، باید کیفیت رفتاری، آستانهها و شواهد آماری را سنجید. این رویکرد مستلزم تعریف معیارهای روشن، ساخت دیتاستهای ارزیابی باکیفیت، اتکا به human-in-the-loop برای برچسبگذاری و تفسیر موارد مرزی، و پوشش سناریوهای متنوع و حتی مخرب (مانند prompt injection) است. جنبههای ایمنی، سوگیری، توهینآمیز بودن، حریم خصوصی و جلوگیری از hallucination به معیارهای پذیرش تبدیل میشوند. علاوه بر ارزیابی آفلاین، باید آزمایشهای آنلاین، مانیتورینگ مستمر، فیدبکلوپ و طبقهبندی خطا برای اولویتبندی اصلاحات وجود داشته باشد. توصیه کلیدی Vladimir Josifoski این است که داده، پرامپت و سیاستها را بهعنوان مصنوعات قابلتست در نظر بگیرید، از ارزیابی آماری و پیوسته بهره ببرید، و هرجا لازم است قضاوت انسانی را وارد کنید تا کیفیت واقعی تضمین شود.
#AI #LLMs #QA #AITesting #QualityAssurance #MachineLearning #PromptEngineering
🟣لینک مقاله:
https://cur.at/8mbcLve?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
The New QA Mindset: Testing AI and LLMs
🟢 خلاصه مقاله:
تست محصولات مبتنی بر AI و بهویژه LLMs با نرمافزارهای کلاسیک فرق اساسی دارد: خروجیها قطعی نیستند و به داده، پرامپت و زمینه وابستهاند. در نتیجه بهجای «صحت دقیق»، باید کیفیت رفتاری، آستانهها و شواهد آماری را سنجید. این رویکرد مستلزم تعریف معیارهای روشن، ساخت دیتاستهای ارزیابی باکیفیت، اتکا به human-in-the-loop برای برچسبگذاری و تفسیر موارد مرزی، و پوشش سناریوهای متنوع و حتی مخرب (مانند prompt injection) است. جنبههای ایمنی، سوگیری، توهینآمیز بودن، حریم خصوصی و جلوگیری از hallucination به معیارهای پذیرش تبدیل میشوند. علاوه بر ارزیابی آفلاین، باید آزمایشهای آنلاین، مانیتورینگ مستمر، فیدبکلوپ و طبقهبندی خطا برای اولویتبندی اصلاحات وجود داشته باشد. توصیه کلیدی Vladimir Josifoski این است که داده، پرامپت و سیاستها را بهعنوان مصنوعات قابلتست در نظر بگیرید، از ارزیابی آماری و پیوسته بهره ببرید، و هرجا لازم است قضاوت انسانی را وارد کنید تا کیفیت واقعی تضمین شود.
#AI #LLMs #QA #AITesting #QualityAssurance #MachineLearning #PromptEngineering
🟣لینک مقاله:
https://cur.at/8mbcLve?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
QAlogy
The New QA Mindset: Testing AI and LLMs - QAlogy
For years, QA engineers have tested deterministic systems — applications that behave predictably when given specific inputs. But with the rise of AI-driven apps and large language models (LLMs), the rules have changed. The systems we’re testing today are…