VPS پر open-kritt کو محفوظ طریقے سے self-host کریں

VPS پر self-host open-kritt کیوں چلائیں، اپنے laptop پر کیوں نہیں

open-kritt کو ایسے server پر self-host کریں جسے آپ ختم کرکے دوبارہ بنا سکیں۔ یہ tool اپنے analysis agents کو disposable job containers کے اندر root کے طور پر چلاتا ہے، ہر agent کو آپ کے code کی writable copy اور براہِ راست internet access دیتا ہے، اور host کا Docker socket اپنی engine service میں mount کرتا ہے۔ کسی job کے لیے مخصوص server پر یہ ایک قابلِ قبول سمجھوتا ہے۔ لیکن اس machine پر یہ خطرناک ہے جہاں آپ کی SSH keys موجود ہوں۔

Default setup کی چار خصوصیات اس مشورے کی بنیاد ہیں، اور یہ چاروں project کی اپنی README اور compose file سے آتی ہیں۔

Agents کو طاقتور ہونا ضروری سمجھا گیا ہے۔ README کے مطابق tool-enabled agents disposable job containers کے اندر root کے طور پر چلتے ہیں۔ انہیں repository کی writable copies اور براہِ راست internet access حاصل ہوتا ہے، تاکہ وہ tools install کر سکیں، targets compile کر سکیں، tests چلا سکیں، اور proof of concept تیار کر سکیں۔ Scan صرف files پڑھنے والا linter نہیں ہے۔ یہ arbitrary code execution ہے جس کی آپ نے درخواست کی ہے۔ Internet access دونوں سمتوں میں خطرہ پیدا کرتا ہے: target پر تحقیق کے دوران agent جو کچھ fetch کرتا ہے، وہ untrusted text کے طور پر اس کے prompt میں شامل ہو جاتا ہے۔ یہی exposure اس وقت بھی ہوتا ہے جب آپ agent کو اس کی اپنی web search استعمال کرنے دیتے ہیں۔

Engine کے پاس Docker socket ہوتا ہے۔ docker-compose.yml host کا Docker socket engine service میں mount کرتا ہے، کیونکہ engine ہر job کے لیے ایک scan container بناتا اور چلاتا ہے۔ جو بھی process اس socket تک پہنچ سکتا ہے، وہ ایسا container شروع کر سکتا ہے جو host filesystem کو mount کرے۔ اس لیے جو host اسے چلا رہا ہو، اس پر engine عملاً root کے اختیارات رکھتا ہے۔

Login screen موجود نہیں ہے۔ Backend میں application authentication شامل نہیں ہے۔ Port تک رسائی آپ کے findings اور provider credit تک رسائی کے برابر ہے۔

جس code کو آپ scan کرتے ہیں، وہ اکثر آپ کا اپنا نہیں ہوتا۔ Agents کو third-party repository کی طرف بھیجنے کا مطلب ہے کہ اس repository کا build آپ کی machine پر root کے طور پر اور network access کے ساتھ چلایا جائے۔

اگر آپ نے coding agents کو disposable VM میں رکھنے کی وجہ پڑھ لی ہے، تو یہ وہی threat model ہے، لیکن زیادہ شدید صورت میں۔ open-kritt کے لیے ایسا VPS مختص کریں جس پر کوئی اور چیز نہ چل رہی ہو، اور اس VPS کو root کے بجائے الگ least-privilege user account سے operate کریں۔

open-kritt اصل میں کیا کرتا ہے

open-kritt (اس repository کا نام Kritt-ai/open-kritt ہے اور یہ AGPL-3.0 کے تحت licensed ہے) vulnerability research کو چھوٹے tasks میں تقسیم کرتا ہے، پھر یہ tasks متعدد AI agents پر بیک وقت چلاتا ہے، اور حاصل ہونے والے نتائج سے duplicate entries ختم کرکے انہیں rank کرتا ہے۔ آپ focused prompts کی chain کے طور پر workflow define کرتے ہیں، اور ہر step کو پچھلے steps سے structured context ملتا ہے۔ Scan target remote یا local git repository ہوتی ہے۔ Analysis engine Codex یا Claude Code ہوتا ہے۔ Candidate ملنے کے بعد optional post-scripts اسے validate کرنے یا proof of concept تیار کرنے کی کوشش کر سکتے ہیں۔

آخر میں آپ کو candidates کی ranked list ملتی ہے۔ اسے report نہیں بلکہ triage queue سمجھیں۔

شروع کرنے سے پہلے درکار چیزیں

• Ubuntu 24.04، Debian 12 یا Rocky Linux 9 چلانے والا VPS۔ انسٹالیشن دستاویزات x86_64 اور ARM64 پر ان distributions کو tested distributions کے طور پر درج کرتی ہیں۔
• Compose plugin کے ساتھ Docker Engine۔
• Host پر Node.js 20 یا اس کے بعد کا ورژن، کیونکہ ./kritt CLI container کے اندر نہیں بلکہ host پر چلتا ہے۔
• ایک model provider: Codex login، یا OPENAI_API_KEY، CODEX_API_KEY، ANTHROPIC_API_KEY یا OPENROUTER_API_KEY۔
• GITHUB_TOKEN صرف اس صورت میں درکار ہے جب آپ private repositories کو scan کرنے کا ارادہ رکھتے ہوں۔ فراہم کردہ .env.example میں یہ بات واضح طور پر درج ہے: صرف GitHub token سے scans نہیں چلائے جا سکتے۔

پہلے Docker اور Node 20 انسٹال کریں

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER

نئی group membership نافذ کرنے کے لیے log out کرکے دوبارہ log in کریں، پھر تصدیق کریں کہ Compose plugin موجود ہے۔

docker compose version

version string ظاہر کرتی ہے کہ Compose بطور plugin انسٹال ہے۔ docker: 'compose' is not a docker command کا مطلب ہے کہ اس کے بجائے آپ کے پاس پرانا standalone docker-compose binary موجود ہے، اور open-kritt docker compose کو استعمال کرتا ہے۔ docker group کی membership host پر root کے مساوی اختیار دیتی ہے، اس لیے اس میں صرف وہ account شامل کریں جو open-kritt چلاتا ہے۔ اس setup کی تفصیلی وضاحت کے لیے VPS پر Docker چلانا دیکھیں۔

Ubuntu 24.04 اپنی repository میں Node 18 فراہم کرتا ہے، جبکہ CLI، 20 سے کم کسی بھی version پر بند ہو جاتی ہے۔ NodeSource استعمال کریں۔

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs
node -v

node -v کو v20. یا اس سے زیادہ دکھانا چاہیے۔ Rocky Linux 9 پر اس کے مساوی کمانڈ sudo dnf module enable nodejs:20 -y ہے، جس کے بعد sudo dnf install -y nodejs چلائیں۔

open-kritt کو clone کریں اور tagged release کو pin کریں

git clone https://github.com/Kritt-ai/open-kritt
cd open-kritt
git fetch --tags
git tag --list
git checkout v1.3.0

main آپ کے ساتھ آگے بڑھتا ہے۔ Tag ایسا نہیں کرتا۔ August 2026 تک تازہ ترین tag v1.3.0 ہے، جو 4 August 2026 کو شائع ہوا تھا، جبکہ git tag --list clone کے دن موجود حالت دکھاتا ہے۔ کسی tag کو checkout کرنے سے repository detached HEAD state میں چلی جاتی ہے۔ یہاں یہ درست ہے، کیونکہ آپ اس clone کو pinned deployment کے طور پر استعمال کر رہے ہیں، ایسی branch کے طور پر نہیں جس میں آپ commit کریں گے۔ بعد میں upgrade کرنے کے لیے release notes پڑھیں، پھر git fetch --tags چلائیں، نیا tag checkout کریں، اور دوبارہ ./kritt start چلائیں، کیونکہ start images کو دوبارہ build کرتا ہے۔

sudo کے ساتھ ./kritt نہ چلائیں۔ دستاویزات میں اس بارے میں واضح ہدایت موجود ہے۔ CLI، .data/ کے تحت project-local credential directories manage کرتا ہے۔ اس لیے root کے طور پر چلانے سے یہ directories root کی ملکیت بن جاتی ہیں، اور اگلا عام run ان میں write نہیں کر سکتا۔

./kritt setup کے ذریعے model access configure کریں

./kritt setup

یہ command موجود نہ ہونے کی صورت میں .env.example سے .env بناتی ہے، ہر credential کی status دکھاتی ہے، اور آپ کو انہیں set یا unset کرنے دیتی ہے۔ یہ values کبھی terminal پر واپس ظاہر نہیں کرتی۔ .env اور engine credential file دونوں mode 0600 کے ساتھ لکھی جاتی ہیں۔

اگر آپ یہ کام دستی طور پر کرنا چاہیں:

cp .env.example .env
chmod 600 .env
mkdir -p .data/codex
chmod 700 .data/codex

اس کے بعد provider key کو .env میں درج کریں اور file کو 0600 پر رکھیں۔ دونوں طریقوں میں provider credential اس server پر موجود رہتی ہے، اس لیے یہ ایک اور وجہ ہے کہ اس machine پر کوئی دوسری چیز نہیں رکھنی چاہیے۔ صرف اسی project کے لیے ایک key بنائیں، تاکہ بعد میں اسے revoke کرنے سے آپ کی ضروری چیزیں متاثر نہ ہوں۔ secrets کو AI agents کی پہنچ سے دور رکھنا میں اس وسیع تر طریقۂ کار کی وضاحت ہے۔

پہلے scan سے پہلے provider کے اخراجات کی حد مقرر کریں

open-kritt متعدد کام بیک وقت چلانے کے لیے بنایا گیا ہے، اور اسی وجہ سے لاگت آتی ہے۔ v1.3.0 میں .env.example کی default values محتاط رکھی گئی ہیں: ENGINE_WORKER_COUNT=2، جسے file میں چھوٹی 2-vCPU machine کے لیے محتاط default بتایا گیا ہے، اور ENGINE_MAX_CONCURRENT_SCANS=1۔ ان کے علاوہ ENGINE_WORKERS_PER_ACCOUNT=15 ہے، یعنی ایک provider account پر بیک وقت چلنے والی root model calls کی زیادہ سے زیادہ تعداد، اور ENGINE_CODEX_MAX_SUBAGENTS_PER_SESSION=5 بھی ہے، کیونکہ Codex session زیادہ سے زیادہ پانچ child agents چلا سکتا ہے۔ بڑی VPS پر workers کی تعداد بڑھانے سے بیک وقت چلنے والی model calls بھی اسی تناسب سے بڑھتی ہیں۔

Repository میں آپ کے اخراجات کی کوئی حد مقرر نہیں ہے۔ .env.example میں budget setting موجود نہیں ہے۔ Engine کی اپنی stop conditions، worker limits اور ENGINE_HARNESS_TIMEOUT_SECONDS ہیں، جو ہر harness run کے لیے default طور پر 7200 seconds ہے۔ اس لیے زیادہ سے زیادہ خرچ کی حد provider کے console میں مقرر ہونی چاہیے۔ اپنے provider console میں پہلے scan سے پہلے hard monthly limit مقرر کریں، بعد میں نہیں۔ VPS پر AI agent کے اخراجات کو کنٹرول کرنا ہر provider کی settings کا طریقہ بیان کرتا ہے۔

مقامی سطح پر بھی ایک روک موجود ہے۔ ENGINE_WORKER_COUNT=0 مقرر کرنے سے نئے jobs اٹھانا رک جاتا ہے، اور stack چلنے کے بعد Settings screen میں worker کی یہی values تبدیل کی جا سکتی ہیں۔

یہ guide ہر scan کی قیمت نہیں بتاتی، کیونکہ لاگت repository کے حجم، آپ کے بنائے ہوئے workflow اور اس کے پیچھے استعمال ہونے والے model پر منحصر ہے۔ ایک چھوٹی repository پر ایک scan چلائیں، پھر اسے کسی بڑی repository پر چلانے سے پہلے اپنے provider کا usage page دیکھیں۔

اسٹیک شروع کریں اور اس کی صحت کی جانچ کریں

./kritt start

یہ .env اور کم از کم ایک credential کی جانچ کرتا ہے، پھر docker compose up --build چلاتا ہے۔ پہلی build سست ہوتی ہے، کیونکہ یہ frontend، backend، engine، executor view اور database images بناتی ہے۔ یہ foreground میں بھی چلتی ہے، اس لیے SSH session بند کرنے سے stack رک جاتا ہے۔ اسے tmux کے اندر شروع کریں، یا پہلی build کامیاب ہونے کے بعد اسے detached mode میں شروع کریں۔ ان دونوں طریقوں سے reboot کے بعد stack خودکار طور پر بحال نہیں ہوتا۔ اگر box restart ہونے کے بعد stack دوبارہ شروع کرنا ہو تو reboots کے دوران self-hosted agent کو چلتا رکھنا میں دیا گیا systemd unit pattern براہ راست استعمال کیا جا سکتا ہے۔

docker compose up -d --build
docker compose ps

docker compose ps میں open-kritt-frontend، open-kritt-backend، open-kritt-engine، open-kritt-executor-view اور open-kritt-db دکھائی دینے چاہییں۔ پھر جانچیں کہ backend خود server پر جواب دے رہا ہے۔

curl -s http://127.0.0.1:3002/api/health

JSON response کا مطلب ہے کہ backend چل رہا ہے۔ Failed to connect to 127.0.0.1 port 3002: Connection refused کا مطلب ہے کہ backend دستیاب نہیں، اور docker compose logs backend وجہ بتائے گا۔ repository directory سے docker compose down کے ذریعے سب کچھ روک دیں۔

ایک اختیاری اضافی قدم: docker compose exec backend npm run seed demo data load کرتا ہے۔ اس سے کسی حقیقی scan پر رقم خرچ کرنے سے پہلے interface دیکھنے کا آسان طریقہ مل جاتا ہے۔

SSH tunnel کے ذریعے port 5173 پر UI تک رسائی حاصل کریں

compose file میں ہر service بطور default 127.0.0.1 پر bind ہوتی ہے: frontend port 5173 پر، backend port 3002 پر، executor view port 8090 پر، اور Postgres port 5432 پر۔ ان bindings کو تبدیل نہ کریں۔ اپنی مشین سے SSH کے ذریعے port forward کریں۔

ssh -N -L 5173:127.0.0.1:5173 you@your-server-ip

جب یہ command چل رہی ہو تو اپنے local browser میں http://localhost:5173 کھولیں۔ -N کا مطلب ہے کہ connection port forward کو برقرار رکھتا ہے اور کوئی shell نہیں کھولتا۔ جب executor view بھی درکار ہو تو اسی command میں دوسرا -L 8090:127.0.0.1:8090 شامل کریں۔

FRONTEND_BIND_ADDRESS=0.0.0.0 متعین کرکے tunnel چھوڑ دینے کا خیال آ سکتا ہے۔ ایسا نہ کریں۔ backend میں login screen موجود نہیں ہے، اس لیے جو بھی اس page تک پہنچ سکے وہ scans شروع کر سکتا ہے اور آپ کے provider کا credit خرچ کر سکتا ہے۔ اس کے علاوہ ایک اور مسئلہ بھی ہے: published container port کو ufw کی default policy لاگو ہونے سے پہلے handle کیا جاتا ہے، اس لیے ufw deny 5173 rule بظاہر درست نظر آتا ہے لیکن کچھ block نہیں کرتا۔ ufw کو bypass کرنے والے Docker ports میں وہ rule chain دکھائی گئی ہے جس کی وجہ سے ایسا ہوتا ہے۔

VPS کا سائز مقرر کرنا

ENGINE_MIN_FREE_STORAGE_GB کی default قدر 20 ہے، اور جب free storage اس سے کم ہو جائے تو engine نیا per-job scan container شروع نہیں کرتا۔ Built images، checkout cache، Postgres data اور job workspaces سب ایک ہی disk پر موجود ہوتے ہیں، اس لیے 20 GB VPS پر scan کبھی شروع نہیں ہوتا۔ 40 GB کو کم از کم حد سمجھیں، اور اگر آپ بڑی repositories scan کرتے ہیں تو اس سے زیادہ storage فراہم کریں۔

Memory کا حساب سادہ ہے۔ ENGINE_MEMORY_RESERVE_GB=2 engine، database، API اور قلیل مدتی اضافی کام کے لیے memory محفوظ رکھتا ہے، جبکہ ہر scan runner کے لیے ENGINE_SCAN_RUNNER_MEMORY_MB=1536 کی reservation اور hard cap مقرر ہے۔ اس لیے دو workers کو دوسرے کام شروع ہونے سے پہلے تقریباً 5 GB درکار ہوتے ہیں۔ Engine صرف اتنے runners چلاتا ہے جو باقی budget میں سما سکیں۔ اس طرح چھوٹے server پر scans fail ہونے کے بجائے queue میں چلے جاتے ہیں۔ یہ out-of-memory killer کے ذریعے عمل ختم ہونے سے کہیں بہتر failure mode ہے۔

دو prune settings کی default قدر true ہے: ENGINE_AUTO_PRUNE_DOCKER_BUILD_CACHE اور ENGINE_AUTO_PRUNE_UNUSED_DOCKER_IMAGES۔ Task مکمل ہونے کے بعد engine غیر ضروری build cache، غیر استعمال شدہ images اور stopped scan containers حذف کر دیتا ہے۔ Running container کے ذریعے referenced images، bind mounts، database data، credentials اور volumes محفوظ رہتے ہیں۔ Host کو share نہ کرنے کی یہ ایک اور وجہ ہے، کیونکہ ایسا pruner چل رہا ہوتا ہے جسے آپ نے configure نہیں کیا، اور وہ اسی Docker daemon پر کام کر رہا ہوتا ہے۔

مقامی repository کو افشا کیے بغیر scan کرنا

LOCAL_REPOS_PATH کی default قدر ./local_repos ہے، اور اسے backend اور engine containers میں /local_repos پر bind-mount کیا جاتا ہے۔ اس لیے host پر اس فولڈر میں رکھی گئی repository فوراً containers کے اندر دکھائی دیتی ہے۔ working tree کے بجائے تازہ clone استعمال کریں۔ job container کے اندر اسے writable copy ملتی ہے، اس کے اندر root اکاؤنٹ ہوتا ہے، اور اسے outbound internet access حاصل ہوتا ہے۔ اس کا مطلب ہے کہ اس copy میں موجود کوئی بھی چیز تبدیل کی جا سکتی ہے یا box سے باہر بھیجی جا سکتی ہے۔ کسی project کو copy کرنے سے پہلے .env فائلیں اور private keys ہٹا دیں۔

آپ کو کیا ملتا ہے، اور کیا نہیں ملتا

آپ کو درجہ بند ممکنہ findings ملتی ہیں۔ آپ کو تصدیق شدہ vulnerabilities نہیں ملتیں۔ Ranking اور de-duplication آپ کی triage queue کی ترتیب طے کرتے ہیں۔ یہ ثابت نہیں کرتے کہ کوئی entry حقیقی ہے۔ Post-scripts validation کی کوشش کر سکتی ہیں اور proof of concept تیار کر سکتی ہیں۔ یہ tool کی طرف سے دستیاب سب سے مضبوط signal ہے۔ لیکن ناکام ہونے والی post-script اس بات کا ثبوت نہیں کہ finding غلط ہے۔ پھر بھی ایک شخص ہر ممکنہ finding کا جائزہ لیتا ہے۔

یہ guide اس بارے میں کوئی دعویٰ نہیں کرتی کہ open-kritt کتنے حقیقی bugs تلاش کرتا ہے، کیونکہ ہم نے اس کی پیمائش نہیں کی۔ جو شخص آپ کے codebase کے لیے detection rate بتاتا ہے، اس نے اسے آپ کے codebase پر نہیں چلایا۔ پہلے کسی ایسے repository کو scan کریں جسے آپ اچھی طرح جانتے ہوں۔ جن findings کا آپ خود فیصلہ کر سکتے ہیں، وہ دستیاب سب سے کم خرچ calibration ہیں۔

یہاں authorization زیادہ تر self-hosted tools کے مقابلے میں زیادہ اہم ہے۔ Agents code کو compile اور execute کرتے ہیں اور network تک رسائی حاصل کرتے ہیں، اس لیے proof-of-concept کا مرحلہ live systems کو متاثر کر سکتا ہے۔ اسے صرف ایسے code پر چلائیں جس کے آپ مالک ہوں یا جس کی testing کے لیے آپ سے معاہدہ کیا گیا ہو۔ کچھ بھی چلانے سے پہلے target scope تحریر کر لیں۔ اگر آپ ANTHROPIC_API_KEY configure کرتے ہیں اور Claude Code engine استعمال کرتے ہیں، تو VPS پر Claude Code محفوظ طریقے سے چلانے کی sandboxing عادات ان agents پر بھی لاگو ہوتی ہیں۔

FAQ

open-kritt کو اپنا VPS کیوں درکار ہے؟

کیونکہ اس کے analysis agents قابلِ تلف containers کے اندر root کے طور پر چلتے ہیں، جہاں آپ کے code کی writable copies اور براہِ راست internet access موجود ہوتی ہے۔ مزید یہ کہ engine service host کا Docker socket mount کرتی ہے تاکہ ہر job کے لیے ایک container شروع کر سکے۔ جو بھی process اس socket تک پہنچ جائے، وہ ایسا container شروع کر سکتا ہے جو host filesystem کو mount کرے۔ اس لیے پوری stack کو اپنے host پر root کے مساوی سمجھنا چاہیے۔ Dedicated VPS پر یہ قابلِ قبول سمجھوتا ہے، اور box کو دوبارہ build کرنے میں آپ کا کوئی نقصان نہیں ہوتا۔ اپنے روزمرہ workstation پر اس سے آپ کی SSH keys اور browser profiles اسی trust boundary میں آ جاتی ہیں جس میں وہ code شامل ہے جسے آپ scan کر رہے ہیں۔

کیا میں SSH tunnel استعمال کرنے کے بجائے port 5173 expose کر سکتا ہوں؟

آپ کو ایسا نہیں کرنا چاہیے۔ Backend application authentication کے بغیر ship ہوتا ہے، اس لیے internet اور آپ کے findings اور provider credit کے درمیان صرف یہی port رکاوٹ رہ جاتا ہے۔ اسی وجہ سے compose file ہر service کو 127.0.0.1 پر bind کرتی ہے۔ اس کے بجائے ssh -N -L 5173:127.0.0.1:5173 you@your-server-ip چلائیں اور مقامی طور پر http://localhost:5173 کھولیں۔ ufw rule اس کا متبادل نہیں، کیونکہ published Docker port کو ufw کی default policy لاگو ہونے سے پہلے handle کیا جاتا ہے۔

میں open-kritt کو اپنی مقررہ حد سے زیادہ خرچ کرنے سے کیسے روکوں؟

پہلے scan سے پہلے اپنے model provider کے console میں hard limit مقرر کریں، کیونکہ open-kritt کی اپنی کوئی budget setting نہیں ہے۔ پہلی چند runs کے لیے shipped concurrency defaults، ENGINE_WORKER_COUNT=2 اور ENGINE_MAX_CONCURRENT_SCANS=1، برقرار رکھیں۔ یہ بھی یاد رکھیں کہ ایک provider account بطور default بیک وقت 15 concurrent root model calls کی اجازت دیتا ہے، جبکہ Codex session بیک وقت پانچ child agents چلا سکتی ہے۔ ENGINE_WORKER_COUNT=0 نئے jobs کے pickup کو روک دیتا ہے اور مقامی طور پر سب سے تیز stop ہے۔

مجھے کون سا version checkout کرنا چاہیے؟

Tag، کبھی بھی main نہیں۔ git fetch --tags کے بعد git tag --list چلانے سے دستیاب versions نظر آتے ہیں، اور 4 August 2026 کو published v1.3.0، اس تحریر کے وقت جدید ترین version ہے۔ Pinning کا مطلب ہے کہ کئی ماہ بعد rebuild کرنے پر وہی stack تیار ہوگی۔ اس سے upgrade ایک ایسا فیصلہ بن جاتا ہے جو آپ release notes پڑھنے کے بعد کرتے ہیں، نہ کہ مختلف دن cloning کرنے کا ضمنی نتیجہ۔

Scan کبھی شروع نہیں ہوتا۔ مجھے کیا check کرنا چاہیے؟

سب سے پہلے free disk space check کریں، کیونکہ free storage ENGINE_MIN_FREE_STORAGE_GB سے کم ہونے پر engine فی job scan container شروع نہیں کرے گا۔ اس کی default value 20 GB ہے۔ پھر check کریں کہ ENGINE_WORKER_COUNT، 0 نہ ہو، کیونکہ یہ value نئے jobs کے pickup کو روک دیتی ہے۔ اس کے بعد ./kritt setup چلا کر تصدیق کریں کہ model credential واقعی configured ہے، کیونکہ صرف GITHUB_TOKEN ہونے سے scans نہیں چل سکتے۔ docker compose logs engine یہ وجہ بتاتا ہے کہ job کیوں skip کیا گیا۔