ساخت AI Security Reviewer روی VPS؛ بررسی خودکار Pull Request و پیدا کردن آسیب‌پذیری کد قبل از انتشار

وقتی سرعت توسعه نرم‌افزار بالا می‌رود، یک مشکل مهم هم جدی‌تر می‌شود: کد جدید قبل از Merge شدن چه مقدار ریسک امنیتی دارد؟ بررسی دستی Pull Request همیشه زمان کافی ندارد و ابزارهای سنتی هم ممکن است بخشی از منطق برنامه را درک نکنند.

در این آموزش، یک AI Security Reviewer را روی سرور مجازی راه‌اندازی می‌کنیم تا Pull Requestها را بررسی کند، بخش‌های مشکوک کد را پیدا کند، مشکلات امنیتی را توضیح دهد و در کنار بررسی مبتنی بر مدل زبانی، وابستگی‌های آسیب‌پذیر و Secretهای احتمالی را نیز بررسی کند.

AI Security Reviewer دقیقاً چه کاری انجام می‌دهد؟

یک Security Reviewer خودکار را می‌توان به‌عنوان یک لایه بررسی بین توسعه‌دهنده و Merge در نظر گرفت. به‌جای اینکه منتظر بمانیم یک توسعه‌دهنده تمام فایل‌های تغییرکرده را دستی بخواند، سیستم تغییرات Pull Request را دریافت می‌کند و آن‌ها را از چند زاویه بررسی می‌کند.

نکته مهم این است که AI نباید جایگزین تست امنیتی قطعی و بازبینی انسانی تلقی شود. بهترین معماری، ترکیب تحلیل مدل زبانی با اسکن‌های deterministic، تست، SAST، dependency scanning و بررسی انسانی است.

چرا VPS برای ساخت Security Reviewer مناسب است؟

اگر چند پروژه نرم‌افزاری دارید، اجرای Reviewer روی لپ‌تاپ توسعه‌دهنده باعث می‌شود فرآیند بررسی به دستگاه خاصی وابسته باشد. VPS می‌تواند یک نقطه مرکزی برای Webhook، Dashboard، پردازش Pull Request و نگهداری Index پروژه‌ها ایجاد کند.

برای پروژه‌های کوچک می‌توان از منابع کمتر شروع کرد. اگر Repository بزرگ است و Indexing زیادی انجام می‌شود، RAM و سرعت دیسک اهمیت بیشتری پیدا می‌کنند. خود Mira نیز اشاره می‌کند که بخش Indexing می‌تواند مصرف RAM را افزایش دهد و برای محیط‌های جدی‌تر استفاده از PostgreSQL را توصیه می‌کند.

انتخاب ابزار: چرا Mira را در این آموزش استفاده می‌کنیم؟

برای این آموزش از Mira استفاده می‌کنیم؛ یک پروژه متن‌باز و قابل استقرار روی زیرساخت شخصی که Pull Request و Merge Request را بررسی می‌کند و قابلیت‌هایی مانند Index کردن Repository، بررسی امنیتی، بررسی آسیب‌پذیری وابستگی‌ها و تعریف Ruleهای سفارشی را در اختیار می‌گذارد.

Mira در مستندات فعلی خود اعلام می‌کند که بررسی امنیتی اختصاصی برای مواردی مانند Injection، XSS، Auth Bypass، CSRF، SSRF و Deserialization ناامن دارد. همچنین Secret scanning روی خطوط اضافه‌شده و بررسی وابستگی‌های جدید یا ارتقایافته با OSV را انجام می‌دهد.

برای مطالعه مستندات رسمی می‌توانید به مستندات رسمی Mira و مخزن GitHub پروژه Mira مراجعه کنید.

معماری نهایی AI Security Reviewer

معماری پیشنهادی ساده است. GitHub یا GitLab تغییر جدید را اعلام می‌کند، Webhook درخواست را به VPS می‌فرستد و Mira تغییرات را برای تحلیل آماده می‌کند.

حداقل منابع پیشنهادی برای VPS

این اعداد را به‌عنوان نقطه شروع در نظر بگیرید، نه الزام ثابت. اندازه Repository، تعداد Pull Requestها، تعداد فایل‌های Index شده و مدل انتخابی می‌تواند نیاز واقعی را تغییر دهد.

مرحله اول؛ نصب Docker روی VPS

برای اجرای Mira، Docker مسیر ساده‌ای است. ابتدا سیستم را به‌روزرسانی کنید:

sudo apt update && sudo apt upgrade -y
curl -fsSL https://get.docker.com | sudo sh
sudo systemctl enable --now docker
docker --version

اگر از Ubuntu Server استفاده می‌کنید، بهتر است قبل از اجرای سرویس، ساعت سیستم، DNS، فایروال و دسترسی SSH را نیز بررسی کنید.

مرحله دوم؛ ساخت مسیر اختصاصی برای Mira

sudo mkdir -p /opt/mira
sudo mkdir -p /opt/mira/data
sudo mkdir -p /opt/mira/secrets
sudo chmod 700 /opt/mira/secrets
cd /opt/mira

دلیل جداکردن Secretها از فایل‌های معمولی این است که کلید GitHub App و کلید مدل زبانی نباید داخل Repository یا فایل تنظیمات عمومی پروژه قرار بگیرند.

مرحله سوم؛ ساخت GitHub App برای Reviewer

در GitHub باید یک App برای Mira ایجاد کنید. مستندات رسمی پروژه برای Pull Request، Contents، Issues و Metadata سطح دسترسی مشخصی پیشنهاد می‌کند و Webhook نیز باید به آدرس سرویس شما متصل شود.

بعد از ساخت App، یک فایل Private Key با پسوند PEM دریافت می‌کنید. این فایل را در اختیار هیچ Repository عمومی قرار ندهید.

مرحله چهارم؛ ساخت Secret برای Webhook

برای Webhook یک مقدار تصادفی و طولانی بسازید:

openssl rand -hex 32

خروجی را نگه دارید؛ این مقدار باید در تنظیمات GitHub App و متغیر MIRA_WEBHOOK_SECRET یکسان باشد.

مرحله پنجم؛ ساخت فایل محیطی Mira

فایل Secretها را ایجاد کنید:

sudo nano /opt/mira/mira.env

ساختار کلی فایل می‌تواند شبیه نمونه زیر باشد:

MIRA_GITHUB_APP_ID=YOUR_APP_ID
MIRA_GITHUB_PRIVATE_KEY=@/etc/mira/private-key.pem
MIRA_WEBHOOK_SECRET=YOUR_RANDOM_WEBHOOK_SECRET
OPENROUTER_API_KEY=YOUR_OPENROUTER_KEY
MIRA_MODEL=anthropic/claude-sonnet-4-6
ADMIN_PASSWORD=CHANGE_THIS_PASSWORD
MIRA_DASHBOARD_URL=https://security.example.com

مرحله ششم؛ قرار دادن Private Key در مسیر امن

sudo cp private-key.pem /opt/mira/secrets/private-key.pem
sudo chmod 600 /opt/mira/secrets/private-key.pem

اگر فایل Private Key را در اختیار دیگری قرار داده‌اید، آن را به‌عنوان یک Credential حساس در نظر بگیرید و در صورت نیاز آن را باطل و کلید جدید تولید کنید.

مرحله هفتم؛ اجرای Mira با Docker

تصویر رسمی Mira از GitHub Container Registry ارائه می‌شود. برای یک استقرار اولیه می‌توانید کانتینر را به شکل زیر اجرا کنید:

docker run -d \
  --name mira \
  --restart unless-stopped \
  --pull=always \
  -p 8000:8000 \
  --env-file /opt/mira/mira.env \
  -v /opt/mira/secrets/private-key.pem:/etc/mira/private-key.pem:ro \
  -v /opt/mira/data:/data/indexes \
  ghcr.io/miracodeai/mira:latest

در محیط Production بهتر است نسخه مشخص Image را Pin کنید و صرفاً به Tag متحرک latest وابسته نباشید. این کار باعث می‌شود زمان به‌روزرسانی نسخه را خودتان کنترل کنید.

مرحله هشتم؛ بررسی وضعیت سرویس

docker ps
docker logs --tail 100 mira
curl http://127.0.0.1:8000/health

اگر سرویس سالم باشد، Endpoint سلامت Mira باید پاسخ موفقیت‌آمیز برگرداند. این Endpoint برای Health Check در محیط‌های Production نیز کاربرد دارد.

مرحله نهم؛ اتصال دامنه و HTTPS

برای Webhook عمومی بهتر است Mira را مستقیماً با IP و پورت خام منتشر نکنید. یک دامنه مانند security.example.com تعریف کنید و Reverse Proxy مانند Nginx یا Caddy را جلوی آن قرار دهید.

مرحله دهم؛ تنظیم Webhook در GitHub

بعد از آماده‌شدن دامنه، آدرس Webhook را به شکل زیر در GitHub App قرار دهید:

https://security.example.com/github/webhook

پس از نصب App روی Repository، Mira می‌تواند Repository را مشاهده و Index کند و Pull Requestهای جدید را برای بررسی دریافت کند.

AI Security Reviewer چگونه یک آسیب‌پذیری را پیدا می‌کند؟

فرض کنید توسعه‌دهنده کدی نوشته که مقدار دریافت‌شده از کاربر را مستقیماً در Query قرار می‌دهد:

const id = req.query.id;
const query = "SELECT * FROM users WHERE id = " + id;

یک Reviewer امنیتی باید متوجه شود که داده کنترل‌شده توسط کاربر وارد Query شده است. گزارش خوب فقط نباید بگوید «این کد ناامن است». باید توضیح دهد داده از کجا آمده، در کجا وارد Sink شده و چه الگوی امن‌تری باید استفاده شود.

نسخه بهتر می‌تواند از Parameterized Query استفاده کند:

const id = req.query.id;
const query = "SELECT * FROM users WHERE id = ?";
const result = await db.query(query, [id]);

چه آسیب‌پذیری‌هایی را قبل از Merge بررسی کنیم؟

چطور False Positive را کاهش دهیم؟

اگر Security Reviewer برای هر مورد کوچک هشدار بدهد، تیم توسعه بعد از مدتی هشدارها را نادیده می‌گیرد. بنابراین کیفیت Reviewer فقط به تعداد آسیب‌پذیری‌های پیدا‌شده وابسته نیست؛ نسبت هشدارهای قابل اقدام به هشدارهای بی‌ارزش هم اهمیت دارد.

یک Rule امنیتی سفارشی برای پروژه تعریف کنیم

یکی از قابلیت‌های مهم سیستم‌های جدید AI Review این است که می‌توانید استانداردهای داخلی تیم را به Reviewer منتقل کنید. برای مثال می‌توانید قانونی تعریف کنید که هر Endpoint جدید باید Authentication مشخص داشته باشد.

Security rule:
Every new API endpoint must explicitly verify authentication
and authorization before accessing tenant-owned resources.

Flag the PR if:
- authentication is missing
- authorization depends only on a client-provided ID
- tenant isolation is not enforced

این نوع Ruleها برای تیم‌هایی که استاندارد امنیتی مشخص دارند بسیار کاربردی است؛ چون Reviewer فقط یک چک‌لیست عمومی نیست و می‌تواند با معماری پروژه هماهنگ شود.

ترکیب AI Reviewer با SAST؛ چرا فقط به LLM تکیه نکنیم؟

یک معماری حرفه‌ای بهتر است چند لایه داشته باشد. مدل زبانی برای درک Context و منطق برنامه مفید است، درحالی‌که ابزارهای SAST می‌توانند Ruleهای قطعی و قابل تکرار را اجرا کنند.

برای مثال Semgrep امکان اجرای اسکن روی Pull Request را فراهم می‌کند و مستندات رسمی آن Diff-aware scanning و PR comments را توضیح می‌دهد.

بررسی امنیتی وابستگی‌ها قبل از Merge

گاهی خود کدی که توسعه‌دهنده نوشته مشکل ندارد، اما یک Package جدید آسیب‌پذیر است. بنابراین Pull Request باید از نظر Dependency نیز بررسی شود.

Mira در قابلیت‌های فعلی خود بررسی Packageهای اضافه یا ارتقایافته را با OSV انجام می‌دهد و برای آسیب‌پذیری‌های شناخته‌شده اطلاعاتی مانند شدت و نسخه اصلاح‌شده را ارائه می‌کند.

این بخش یک تفاوت مهم با Code Review معمولی ایجاد می‌کند: Reviewer فقط نمی‌پرسد «کد جدید چه کاری انجام می‌دهد؟» بلکه می‌پرسد «آیا وابستگی جدیدی که وارد پروژه شده، ریسک شناخته‌شده دارد؟»

باکس پیشنهادی برای تیم‌های توسعه

چگونه Reviewer را وارد فرآیند Merge کنیم؟

هدف نهایی این نیست که یک Dashboard دیگر روی VPS داشته باشیم. هدف این است که بررسی امنیتی وارد Workflow واقعی تیم شود.

به این ترتیب Security Review از یک کار دستی و پراکنده به یک مرحله قابل تکرار در چرخه توسعه تبدیل می‌شود.

امنیت خود VPS را فراموش نکنید

ساخت Security Reviewer روی یک VPS، خودش یک سرویس حساس ایجاد می‌کند. این سرور به Repositoryها، Webhookها و احتمالاً Credentialهای سرویس مدل دسترسی دارد. بنابراین محافظت از خود Reviewer به اندازه بررسی کد اهمیت دارد.

یک تست واقعی برای AI Security Reviewer

بعد از اتصال Repository، یک Pull Request آزمایشی ایجاد کنید. عمداً یک آسیب‌پذیری واقعی را وارد Production نکنید؛ بهتر است یک Repository آزمایشی با کد ساختگی داشته باشید.

git checkout -b security-review-test
git add .
git commit -m "test security reviewer"
git push origin security-review-test

سپس Pull Request را باز کنید و ببینید Reviewer چه مواردی را گزارش می‌کند. در تست اولیه سه موضوع را بررسی کنید: دقت Finding، توضیح مشکل و کیفیت پیشنهاد اصلاح.

اگر AI یک مشکل را اشتباه تشخیص داد چه کنیم؟

False Positive اجتناب‌ناپذیر است. اگر یک Finding اشتباه بود، نباید صرفاً آن را نادیده بگیرید. علت خطا را بررسی کنید و در صورت امکان Rule یا Context پروژه را اصلاح کنید.

هدف این است که Reviewer با گذشت زمان با معماری و استانداردهای تیم هماهنگ‌تر شود. در سیستم‌هایی مانند Mira حتی مکانیزم‌هایی برای استفاده از بازخوردهای Reviewهای انسانی و ساخت Ruleهای آموخته‌شده وجود دارد.

آیا AI Security Reviewer جایگزین متخصص امنیت می‌شود؟

خیر. AI Security Reviewer یک لایه اتوماسیون است. ارزش اصلی آن در پیدا کردن سریع‌تر الگوهای مشکوک، کاهش کارهای تکراری و ارائه بازخورد در همان مرحله Pull Request است.

برای سیستم‌های حساس، بهتر است Findings مهم با تست امنیتی، تست نفوذ، تحلیل SAST/SCA و بررسی متخصص امنیت ترکیب شوند. مخصوصاً در مواردی که مدل درباره Business Logic یا سطح دسترسی تصمیم‌گیری می‌کند، تأیید انسانی همچنان اهمیت دارد.

مقایسه معماری ساده و معماری حرفه‌ای

رفع مشکل اگر Mira اجرا نشد

اگر بعد از اجرای Docker داشبورد بالا نمی‌آید، ابتدا وضعیت Container و Logها را بررسی کنید:

docker ps -a
docker logs --tail 200 mira
docker inspect mira
curl http://127.0.0.1:8000/health

جمع‌بندی؛ ساخت یک لایه امنیتی قبل از انتشار کد