Iron Laws کے ذریعے AI سے تیار کردہ کوڈ کا آڈٹ اور بہتری

آئرن لاز کیا ہے؟

آئرن لاز، جسے 오철칙 بھی کہا جاتا ہے، ایک جامد معائنہ جاتی ٹول ہے جو AI سے تیار کردہ پروجیکٹس میں عام طور پر پائے جانے والے سیکیورٹی اور قابلِ دیکھ بھال سے متعلق مسائل کی نشاندہی کرنے کے لیے بنایا گیا ہے۔ یہ انٹرپرائز اور عوامی شعبے کے سسٹم انٹیگریشن آڈٹس سے حاصل شدہ اسباق لاگو کرتا ہے اور پھر ہر دریافت کی آسان زبان میں وضاحت کرتا ہے۔

یہ ٹول صرف یہ نہیں دیکھتا کہ ایپلیکیشن چلتی ہے یا نہیں۔ یہ ہارڈ کوڈ کیے گئے راز، غیر محفوظ ان پٹ ہینڈلنگ، نگل لیے جانے والے استثناؤں، غیر مستند انتظامی APIs، Supabase یا Firebase کے غائب رسائی کنٹرولز، commit کی گئی .env فائلوں، نقل شدہ فنکشنز، چکر دار انحصارات، اور ٹائپ سیفٹی کو نظرانداز کرنے جیسے مسائل کی جانچ کرتا ہے۔

آئرن لاز ایسے منظم مرمتی निर्देशات بھی تیار کرتا ہے جنہیں AI کوڈنگ اسسٹنٹ میں پیسٹ کیا جا سکتا ہے۔ اس سے ایک قابلِ تکرار ورک فلو بنتا ہے:

AI کے ساتھ بنائیں → iron-laws check → iron-laws fix-prompt
→ AI سے دریافت شدہ مسائل درست کروائیں → دوبارہ check چلائیں

آئرن لاز ڈیولپمنٹ کے دوران جائزے کا معاون ٹول ہے، کوئی سرکاری سرٹیفیکیشن پروڈکٹ یا اس بات کا ثبوت نہیں کہ ایپلیکیشن محفوظ ہے۔ اسے ٹیسٹس، کوڈ ریویو اور دیگر سیکیورٹی ٹولز کے ساتھ استعمال کریں۔

اہم خصوصیات

سیکیورٹی اور معیار کا معائنہ

اس پروجیکٹ میں کئی شعبوں پر محیط 90 قواعد شامل ہیں:

• حوالہ جاتی قواعد: حوالہ دی گئی کوریائی وزارتِ داخلہ و تحفظ کی سافٹ ویئر ڈیولپمنٹ سیکیورٹی گائیڈ کے نفاذی مرحلے کے تمام 49 آئٹمز کی کوریج، جن میں انجیکشن، XSS، SSRF، XXE، کمزور خفیہ کاری، سرٹیفکیٹ کی توثیق کو غیر فعال کرنا، غیر محفوظ ڈی سیریلائزیشن، ایرر ہینڈلنگ اور میموری سیفٹی شامل ہیں۔
• AI کوڈ کی اصلاحات: ہارڈ کوڈ شدہ کنفیگریشن، رازوں کی متبادل قدریں، فرنٹ اینڈ میں رازوں کا افشا، غیر محفوظ CORS، غائب رسائی قواعد، خطرناک Docker یا CI سیٹنگز، انحصار کے ناموں میں ٹائپنگ کی غلطیاں، ورژن کے بغیر انحصارات، حساس لاگنگ، IDOR اور کوکی کے اوصاف۔
• آرکیٹیکچر کی جانچ: حد سے زیادہ بڑے فنکشنز اور فائلیں، تہوں کے نامناسب انحصارات، ریکویسٹ ہینڈلرز سے براہِ راست ڈیٹابیس تک رسائی، چکر دار انحصارات، نقل شدہ فنکشنز، بار بار دہرائے گئے اسٹرنگ مستقلات اور غائب ٹیسٹس۔
• ٹائپ سیفٹی کی جانچ: TypeScript کا any اور @ts-ignore، Python کا type: ignore اور casts، Java کی raw types، C# کا dynamic، اور دیگر معاون زبانوں میں ٹائپ سسٹم کو نظرانداز کرنے کے طریقے۔

قابلِ فہم دریافتیں اور مرمتی رہنمائی

ہر دریافت میں مسئلے کی وضاحت، اس کے خطرناک ہونے کی وجہ، اور اسے درست کرنے کا طریقہ شامل ہوتا ہے۔ جہاں کوئی قاعدہ شائع شدہ گائیڈ کے آئٹم سے متعلق ہو، وہاں رپورٹ میں اس آئٹم کا نمبر اور اس کی CWE میپنگ شامل ہوتی ہے۔ پروجیکٹ کے مخصوص معیار کے قواعد کو بیرونی تقاضوں کے بجائے واضح طور پر آئرن لاز کے قواعد کے طور پر نشان زد کیا جاتا ہے۔

AI کے لیے تیار اصلاحی پرامپٹس

fix-prompt کمانڈ دریافتوں کو شدت کے لحاظ سے منظم کرتی ہے اور انہیں AI کوڈنگ ٹول کے لیے ہدایات میں تبدیل کرتی ہے۔ پرامپٹ ان اصولوں کو بھی تقویت دیتا ہے کہ ایررز کو نگلا نہ جائے، رازوں کو سورس کوڈ میں نہ رکھا جائے، ٹائپ چیکنگ کو نظرانداز نہ کیا جائے، اور نقل شدہ نفاذات نہ بنائے جائیں۔

مقامی پارسنگ

ضروری پارسرز پیکیج میں شامل ہیں، اس لیے انسٹالیشن کے بعد نیٹ ورک رسائی کے بغیر معائنے چلائے جا سکتے ہیں۔

زبان اور فائل سپورٹ

سپورٹ کی گہرائی زبان اور فائل کی قسم کے لحاظ سے مختلف ہوتی ہے:

• وسیع سپورٹ: Python، JavaScript، TypeScript، Java اور C# کو نحوی تجزیہ، ان پٹ ٹریکنگ اور قواعد کی سب سے وسیع کوریج حاصل ہے۔
• بنیادی سپورٹ: Go اور PHP کو نحوی تجزیہ اور انجیکشن، ایرر ہینڈلنگ اور خفیہ کاری کی اہم جانچ حاصل ہے۔
• محدود سپورٹ: Rust اور C/C++ میں ایرر ہینڈلنگ، میموری کے استعمال، فارمیٹ اسٹرنگز، APIs اور ٹائپ بائی پاسز کی جانچ شامل ہے۔
• کنفیگریشن اور تعریف کی فائلیں: SQL، YAML، JSON، .env، Dockerfile، Compose، GitHub Actions، MyBatis XML اور HTML ٹیمپلیٹس میں متعلقہ راز، رسائی کنٹرول، تعیناتی اور escaping کے مسائل کا معائنہ کیا جاتا ہے۔

فنکشنز کے اندر آئرن لاز برانچز، لوپس اور استثناؤں کے ذریعے فلو کا تجزیہ کرتا ہے۔ یہ ایک ہی فائل میں موجود معاون فنکشن کالز کو زیادہ سے زیادہ چار سطحوں تک فالو کرتا ہے۔ Python میں درآمدات کے ذریعے تجرباتی کراس فائل ٹریکنگ بھی موجود ہے، جو تجزیاتی حدود کے تابع ہے۔ دیگر زبانوں میں کراس فائل فلو چھوٹ سکتے ہیں یا جائزے کی ضرورت کے طور پر رپورٹ ہو سکتے ہیں۔

انسٹالیشن

آئرن لاز کے لیے Python 3.12 یا اس کے بعد کا ورژن درکار ہے۔ uv کے ذریعے اسے اسٹینڈ الون ٹول کے طور پر انسٹال کرنا تجویز کردہ طریقہ ہے:

uv tool install git+https://github.com/JinHo-von-Choi/iron-laws.git

آپ اسے pip کے ذریعے بھی انسٹال کر سکتے ہیں:

pip install git+https://github.com/JinHo-von-Choi/iron-laws.git

انسٹالیشن کے بعد، شامل قواعد کی فہرست دکھا کر تصدیق کریں کہ کمانڈ دستیاب ہے:

iron-laws rules

زبان اور قاعدے کے لحاظ سے نفاذ اور توثیق کی صورتحال دیکھنے کے لیے چلائیں:

iron-laws support

یہ فرق اہم ہے کیونکہ پارسر کی موجودگی کا لازمی مطلب یہ نہیں کہ اس زبان کے لیے ہر قاعدے کی توثیق ہو چکی ہے۔

اپنا پہلا معائنہ چلائیں

موجودہ پروجیکٹ اسکین کریں

پروجیکٹ ڈائریکٹری میں ٹرمینل کھولیں اور چلائیں:

iron-laws check .

بطورِ ڈیفالٹ، جب کمانڈ کو HIGH شدت یا اس سے زیادہ کی کوئی دریافت ملتی ہے تو یہ ناکام ہو جاتی ہے۔ ایگزٹ کوڈز یہ ہیں:

• 0: منتخب شدہ شدت پالیسی کے تحت معائنہ کامیاب رہا۔
• 1: کم از کم ایک دریافت نے مقررہ ناکامی کی شدت کو پورا کیا یا اس سے تجاوز کیا۔
• 2: ان پٹ یا کنفیگریشن غلط تھی، کوئی فائل معائنہ نہیں کی گئی، یا قواعد کی خرابیوں یا فائل پڑھنے میں ناکامی جیسے مسائل کے باعث معائنہ مکمل نہیں ہو سکا۔

نامکمل معائنہ تصدیق شدہ گریڈ یا کامیابی کا نتیجہ حاصل نہیں کرتا۔ اس کی وجوہات diagnostics کے تحت درج کی جاتی ہیں۔ خالی ہدف کو بھی کامیاب اسکین نہیں سمجھا جاتا، جب تک کہ --allow-empty واضح طور پر فراہم نہ کیا جائے۔

انفرادی اصول کو سمجھیں

جب آپ کو کسی اصول کی عام فہم وضاحت درکار ہو تو explain استعمال کریں:

iron-laws explain IL-501

آپ یہ بھی دیکھ سکتے ہیں کہ حوالہ دی گئی 49 نفاذی اشیا میں سے کون سی شامل ہیں:

iron-laws coverage

رپورٹ تیار کریں

حوالہ دی گئی تمام 49 اشیا کی معائنہ حیثیت پر مشتمل Markdown رپورٹ بنانے کے لیے چلائیں:

iron-laws audit . --format markdown -o report.md

GitHub Code Scanning یا کسی دوسرے موافق نظام کے لیے SARIF فائل بنانے کے لیے استعمال کریں:

iron-laws audit . --format sarif -o iron-laws.sarif

AI کوڈنگ معاون کے لیے ہدایات تیار کریں

نتائج کا جائزہ لینے کے بعد، AI کے لیے تیار مرمتی پرامپٹ بنائیں:

iron-laws fix-prompt .

تیار کردہ ہدایات اپنے کوڈنگ معاون میں چسپاں کریں، تجویز کردہ تبدیلیوں کا جائزہ لیں، پھر دوبارہ معائنہ چلائیں:

iron-laws check .

fix-prompt کمانڈ نتائج موجود ہونے کے باوجود ایگزٹ کوڈ 0 واپس کرتی ہے کیونکہ اس کا مقصد ہدایات تیار کرنا ہے۔ اسے تعیناتی کے گیٹ کے طور پر استعمال نہ کریں۔ نفاذ کے لیے check یا audit استعمال کریں۔

شناخت شدہ خفیہ اقدار کو رپورٹس اور تیار کردہ پرامپٹس میں **** سے چھپا دیا جاتا ہے۔ تاہم، غیر شناخت شدہ راز خودکار طور پر نہیں چھپائے جا سکتے، اس لیے تیار کردہ متن کسی بیرونی AI سروس کو بھیجنے سے پہلے اس کا جائزہ لیں۔

پروجیکٹ کی پالیسیاں ترتیب دیں

ابتدائی تشکیل کی فائل بنانے کے لیے چلائیں:

iron-laws init

پروجیکٹ .iron-laws.yml استعمال کرتا ہے۔ ایک عام تشکیل یہ ہے:

fail_on: HIGH
excludes: [".git", "node_modules", "dist"]
disabled_rules: ["ARC-206"]
limits:
  max_function_lines: 80
  max_file_lines: 600
  max_parameters: 7
  max_nesting: 5
  duplicate_similarity: 0.9

fail_on ترتیب CRITICAL، HIGH، MEDIUM، یا LOW قبول کرتی ہے۔ مؤثر ترجیحی ترتیب کمانڈ لائن آپشن --fail-on، پھر تشکیل کی فائل، اور آخر میں طے شدہ قدر HIGH ہے۔ رپورٹس درج کرتی ہیں کہ فعال حد کس ذریعے سے فراہم ہوئی۔

بطور ڈیفالٹ، Iron Laws معائنہ کی جانے والی ڈائریکٹری میں موجود تشکیل استعمال کرتا ہے۔ کسی مخصوص فائل کا انتخاب کرنے کے لیے --config یا والدین کی ڈائریکٹریوں میں تلاش کرنے کے لیے --search-parents استعمال کریں۔ نامعلوم کلیدیں اور غلط ترتیبات خاموشی سے نظرانداز نہیں کی جاتیں؛ ان سے ایگزٹ کوڈ 2 پیدا ہوتا ہے۔

جان بوجھ کر کی گئی مستثنیات سنبھالیں

غلط مثبت نتیجے یا جان بوجھ کر کی گئی مستثنیٰ صورت کو صرف اسی وقت دبایا جا سکتا ہے جب دبانے کی ہدایت میں وجہ شامل ہو۔ وجہ کے بغیر تبصرہ نظرانداز کر دیا جاتا ہے۔

Python میں ایک نتیجہ دبانے کے لیے:

except ImportError:  # iron-laws: ignore[IL-301] Optional dependency disables this feature
    yaml = None

کسی پوری فائل کے لیے اصول دبانے کی خاطر پہلی 30 سطروں کے اندر ignore-file ہدایت رکھیں:

# iron-laws: ignore-file[IL-102] Pattern definitions intentionally identify weak algorithms

دبانے کی ہدایات میں میعاد ختم ہونے کی تاریخ شامل کی جا سکتی ہے:

# iron-laws: ignore[IL-101] until=2026-12-31 Temporary exception with documented reason

میعاد ختم ہونے کے بعد دبانے کی ہدایات لاگو نہیں رہتیں اور رپورٹس میں ظاہر ہوتی ہیں۔ Iron Laws غیر استعمال شدہ دبانے کی ہدایات اور نامعلوم اصولی IDs کے حوالوں کی بھی رپورٹ کرتا ہے۔

موجودہ پروجیکٹ میں Iron Laws اپنائیں

بیس لائن بنائیں

اگر کسی موجودہ ریپوزٹری میں پہلے سے منظور شدہ نتائج موجود ہوں تو انہیں منظور شدہ تکنیکی قرض کے طور پر درج کریں:

iron-laws baseline create .

پھر محفوظ شدہ بیس لائن کے مقابلے میں صرف نئے متعارف شدہ نتائج کا جائزہ لیں:

iron-laws check . --baseline .iron-laws-baseline.json

تبدیل شدہ فائلوں کا معائنہ کریں

ترمیم شدہ فائلوں پر مرکوز پل ریکویسٹ فیڈبیک کے لیے، مین برانچ کے مقابلے میں موازنہ کریں:

iron-laws check . --changed-since origin/main

README تجویز کرتا ہے کہ تبدیل شدہ فائلوں کے معائنے کو مکمل اور وقتاً فوقتاً کیے جانے والے اسکینز کے ساتھ استعمال کیا جائے تاکہ ریپوزٹری بھر کے مسائل نظرانداز نہ ہوں۔

جائزے کا فیڈبیک درج کریں

جن نتائج کے لیے جائزہ درکار ہو، انہیں درجہ بند کیا جا سکتا ہے اور جائزے کی لاگت مختص کی جا سکتی ہے:

iron-laws feedback add IL-501 src/a.py:3 --verdict false-positive --minutes 10

AI سے تیار کردہ پیچز کی تصدیق کریں

Iron Laws میں ایک جدید ورک فلو شامل ہے جو AI کی جانب سے کوڈ میں ترمیم کے بعد تصدیق شدہ اور غیر تصدیق شدہ امور کے شواہد محفوظ کرتا ہے۔

شواہد کے معاہدے کی جانچ کریں

شواہد کا معاہدہ مکمل اسکین اور مطلوبہ شواہد پیدا کرنے والے اسکین کے درمیان فرق واضح کرتا ہے:

iron-laws check . --contract .iron-laws-contract.yml

حل نہ کیے گئے ان پٹ ذرائع کو خودکار طور پر صاف نتائج میں تبدیل نہیں کیا جاتا۔ موجودہ شواہد-معاہدہ کوریج میں Python کمانڈ پر عمل درآمد، پاتھ تک رسائی، اور SQL بنانے کے خاندان شامل ہیں۔

پیچ کی تصدیقی رسید بنائیں

مجوزہ پیچ کا معائنہ کرنے اور تصدیقی رسید محفوظ کرنے کے لیے اس جیسی کمانڈ چلائیں:

iron-laws verify-patch . --patch fix.diff \
  --finding IL-504@app.py:6 \
  --runner docker \
  --image IMAGE_NAME \
  -o receipt.json

تصدیق کنندہ اسی پالیسی کے ذریعے اصل اور امیدوار ورژن کا موازنہ کرتا ہے۔ یہ مشتبہ تبدیلیوں کی الگ سے رپورٹ کرتا ہے، جیسے ٹیسٹس کا حذف ہونا، اضافی اسکیپس، نئے ignore تبصرے، یا کمزور کی گئی پالیسیاں۔ کسی وارننگ کا ختم ہو جانا بذاتِ خود درست اصلاح کا ثبوت نہیں سمجھا جاتا۔

ٹیسٹ صرف ایک عارضی الگ تھلگ ماحول میں، اسناد کے بغیر، چلائے جاتے ہیں۔ اگر تنہائی حاصل نہ ہو سکے تو Iron Laws میزبان پر خاموشی سے ٹیسٹ نہیں چلاتا؛ نتیجہ غیر متعین رہتا ہے۔

امتیازی ریگریشن ٹیسٹ تجویز کریں

آپ کسی دریافت کے لیے ممکنہ ریگریشن ٹیسٹ کی وضاحت تیار کر سکتے ہیں:

iron-laws regression propose . --finding IL-504@app.py -o spec.yml

مطلوبہ توثیقی طریقہ یہ جانچتا ہے کہ اصل کوڈ خرابی کی وجہ سے ناکام ہو، امیدوار کامیاب ہو، اور ایسا میوٹنٹ جس میں اصلاح واپس کر دی گئی ہو دوبارہ ناکام ہو۔ README میں اس سلسلے کو تین بار دہرانے کی وضاحت ہے۔ تیار کردہ ٹیسٹ کی تصدیق ہونے تک صرف ایک تجویز رہتا ہے۔

انسانی منظوری ریکارڈ کریں

منظوری کو اس کی وجہ کے ساتھ محفوظ کریں:

iron-laws approvals add . \
  --finding IL-504@app.py \
  --reason "Documented review reason" \
  --store approvals.jsonl

اسکین کے دوران درست منظوریوں کا اطلاق کریں:

iron-laws check . --approvals approvals.jsonl

منظوریاں صرف اس وقت تک درست رہتی ہیں جب تک ان کے مفروضے برقرار رہیں۔ کالرز، ڈیٹا فلو، سینیٹائزرز، رسائی کے دائرے یا اصول کے مفہوم میں تبدیلیاں دوبارہ جائزے کی ضرورت پیدا کر سکتی ہیں۔ نقل شدہ کمزور کوڈ کو موجودہ منظوری خودکار طور پر حاصل نہیں ہوتی۔

GitHub Actions کے ساتھ انضمام

درج ذیل ورک فلو Iron Laws انسٹال کرتا ہے، SARIF رپورٹ اپ لوڈ کرتا ہے، اور پھر زیادہ شدت والے تعیناتی گیٹ کو نافذ کرتا ہے:

name: Iron Laws
on: [push, pull_request]
jobs:
  audit:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/setup-uv@v3
      - run: uv tool install git+https://github.com/JinHo-von-Choi/iron-laws.git
      - run: iron-laws audit . --format sarif -o iron-laws.sarif || true
      - uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: iron-laws.sarif
      - run: iron-laws check . --fail-on HIGH

رپورٹ تیار کرنے والے مرحلے میں || true استعمال کیا گیا ہے تاکہ دریافتیں موجود ہونے کے باوجود SARIF فائل اپ لوڈ کی جا سکے۔ آخری check کمانڈ اصل کامیابی یا ناکامی کا گیٹ فراہم کرتی ہے۔

عملی حدود

• صاف نتیجے کا مطلب ہے کہ نافذ کردہ اصولوں اور معاون تجزیاتی دائرے میں کوئی مسئلہ نہیں ملا۔ اس سے یہ ثابت نہیں ہوتا کہ ایپلیکیشن کمزوریوں سے پاک ہے۔
• فائلوں کے درمیان ان پٹ ٹریکنگ Python کے لیے تجرباتی اور دیگر زبانوں کے لیے محدود ہے۔ کچھ فلو نظر انداز ہو سکتے ہیں یا دستی جائزے کی ضرورت کے طور پر رپورٹ ہو سکتے ہیں۔
• سینیٹائزرز صرف اسی سیاق کے لیے پہچانے جاتے ہیں جس کی وہ حفاظت کرتے ہیں، مثلاً HTML، SQL، شیل کمانڈز یا راستے۔
• README کے مطابق پیچ کی توثیق، ریگریشن ٹیسٹنگ اور منظوری کی ٹریکنگ کو ابھی تک آزادانہ جائزہ یا حقیقی دنیا کے پائلٹ سے نہیں گزارا گیا۔
• پروجیکٹ کے حوالے کردہ OWASP Benchmark نتائج کئی زمروں میں بہتری دکھاتے ہیں، لیکن غلط مثبت نتائج اب بھی موجود ہیں، جن میں محفوظ طور پر سینیٹائز کیے گئے SQL اور کمانڈ انجیکشن کے کیسز شامل ہیں۔
• پیکیج ریپوزٹری سے مشورہ کیے بغیر یہ ٹول ہر جعلی انحصار کی قابل اعتماد شناخت نہیں کر سکتا۔ اس کے بجائے یہ ایسے نام رپورٹ کرتا ہے جو مقبول پیکیجز سے مشابہ ہوں۔
• کمپریس شدہ اور تیار کردہ فائلیں چھوڑ دی جاتی ہیں، اور وجوہات skipped_files کے تحت ریکارڈ کی جاتی ہیں۔

مزید تفصیل کے لیے ریپوزٹری کی دستاویزات میں پیچ کی توثیق، درستگی کی پیمائش، زبان اور اصول کی معاونت، اور رپورٹ کے فارمیٹس دیکھیں۔

نتیجہ

Iron Laws، AI سے تیار کردہ سافٹ ویئر کا جائزہ لینے کا ایک منظم طریقہ فراہم کرتا ہے، اس سے پہلے کہ پوشیدہ سکیورٹی اور دیکھ بھال کے مسائل پروڈکشن واقعات بن جائیں۔ iron-laws check . سے آغاز کریں، وضاحتوں کا جائزہ لیں، اصلاحی پرامپٹ تیار کریں، AI کی تبدیلیوں کا جائزہ لیں، اور دوبارہ اسکین کریں۔ جیسے جیسے پروجیکٹ پختہ ہو، عمل کو قابل تکرار اور قابل آڈٹ بنانے کے لیے کنفیگریشن، بیس لائنز، SARIF رپورٹنگ، پیچ کی رسیدیں اور انسانی منظوریوں کا اضافہ کریں۔

یہ پروجیکٹ MIT License کے تحت دستیاب ہے۔ اس کے نتائج کو ٹیسٹنگ، دستی کوڈ جائزے اور وسیع تر سکیورٹی جائزے کا متبادل بنانے کے بجائے ان کی معاونت کرنی چاہیے۔