سیکیورٹی کے جائزے اس وقت سب سے زیادہ موثر ہوتے ہیں جب ڈویلپرز کو فیڈ بیک موصول ہوتا ہے جب کہ کوڈ ان کے ذہنوں میں ابھی بھی تازہ ہوتا ہے۔ بے نقاب اسناد اور غیر محفوظ نمونوں کو تلاش کرنے کے لیے پل کی درخواستوں، CI تعمیرات، یا دخول کے ٹیسٹ کا انتظار غیر ضروری دوبارہ کام کا سبب بنتا ہے۔
سیکیورٹی کو بائیں جانب منتقل کرنے کا ایک آسان طریقہ یہ ہے کہ سٹیٹک ایپلیکیشن سیکیورٹی ٹیسٹنگ (SAST) کو مقامی طور پر Git پری کمٹ ہک کے ذریعے چلایا جائے۔
اس گائیڈ میں، آپ DevSkim CLI انسٹال کریں گے اور اسے استعمال کریں گے۔ pre-commit لہذا، اسٹیجڈ فائلوں کو لنٹ کریں، ایک سرشار خفیہ اسکینر شامل کریں، جان بوجھ کر ناکامیوں کے ساتھ سیٹ اپ کو چیک کریں، اور CI پر وہی چیک نافذ کریں۔
ہم کیا احاطہ کریں گے:
ہمیں پہلے سے کمٹ سیکیورٹی اسکینوں کی ضرورت کیوں ہے؟
ایک پری کمٹ ہک خود بخود چلایا جاتا ہے اس سے پہلے کہ گٹ کمٹ بنائے۔ یہ ہارڈ کوڈ شدہ پاس ورڈز، ٹوکنز، کنکشن سٹرنگز، غیر محفوظ خفیہ کاری کے نمونوں، کمزور ان پٹ کی توثیق، خطرناک فائلوں یا عمل کو ہینڈل کرنے، اور دیگر زبان کے مخصوص سیکیورٹی اینٹی پیٹرن کو پکڑنے کے لیے مفید ہے۔
مقصد CI سیکیورٹی اسکیننگ یا دستی جائزہ کو تبدیل کرنا نہیں ہے۔ مقصد یہ ہے کہ ڈیولپرز کو جلد از جلد عملی لمحے میں فوری، قابل عمل تاثرات فراہم کریں۔
ایک صحت مند ماڈل ہو گا:
Developer workstation
-> Pre-commit security checks
-> Pull request review
-> CI/CD SAST and dependency scanning
-> Runtime monitoring and vulnerability management
DevSkim کیا ہے؟
DevSkim مائیکروسافٹ کی طرف سے بنایا گیا ایک سیکورٹی لنٹر ہے. IDE ایکسٹینشن اور کراس پلیٹ فارم CLI کے طور پر دستیاب ہے، یہ غیر محفوظ کوڈنگ پیٹرنز کو جھنڈا لگانے کے لیے قابل ترتیب اصول کا استعمال کرتا ہے۔
یہ ڈویلپرز کے لیے ایک گارڈریل کے طور پر اچھی طرح کام کرتا ہے کیونکہ یہ فائلوں کو تیزی سے اسکین کرتا ہے اور وضاحت کرتا ہے کہ پیٹرن کیوں خطرناک ہیں۔ قواعد خطرناک API کے استعمال، کمزور انکرپشن، غیر محفوظ ڈی سیریلائزیشن، کمزور TLS یا سرٹیفکیٹ کی توثیق، اور ممکنہ کمانڈ انجیکشن کے خطرات کا احاطہ کرتے ہیں۔
ان کا استعمال کرنے سے پہلے، ایک فرق اہم ہے. DevSkim ایک سیکورٹی لنٹر ہے، ایک خفیہ سکینر نہیں. یہ کچھ عام اسنادی اصولوں کو بنڈل کرتا ہے، لیکن یہ ریگولر ایکسپریشن پیٹرن ہیں جو ٹوکنز کی طرح لمبی اقدار کو نشانہ بناتے ہیں۔
ٹیمیں عام طور پر DevSkim کو ایک سرشار خفیہ دریافت کے آلے کے ساتھ جوڑتی ہیں جیسے Gitleaks، Discover-secrets، یا TruffleHog۔ Gitleaks اور دریافت راز دونوں سرکاری طور پر شائع ہوتے ہیں۔ pre-commit ہکس ہیں لہذا آپ آسانی سے کسی ایک کو اس ورک فلو میں ڈال سکتے ہیں۔ یہ گائیڈ Gitleaks کا استعمال کرتا ہے۔
جیسا کہ تمام سیکیورٹی اسکینرز کے ساتھ، نتائج کو سیاق و سباق کی ضرورت ہوتی ہے۔ ایک انتباہ خود بخود ایک خطرہ نہیں ہے، لیکن کوڈ کے نیچے کی طرف جانے سے پہلے اس کا جائزہ لینے کے قابل ہے۔
شرطیں
Git، Python 3، اور .NET SDKs کی ضرورت ہے، جن پر DevSkim کا CLI تقسیم کیا جاتا ہے۔
انسٹال کریں pre-commit:
pip install pre-commit
DevSkim CLI کو .NET گلوبل ٹول کے طور پر انسٹال کریں۔
dotnet tool install --global Microsoft.CST.DevSkim.CLI
اگر آپ .NET SDK کو انسٹال نہیں کرنا چاہتے ہیں تو، پلیٹ فارم کے لیے مخصوص بائنریز DevSkim کے ریلیز کے صفحہ پر دستیاب ہیں۔
ایک نئے ٹرمینل میں دونوں تنصیبات کی توثیق کریں اور اپ ڈیٹ کردہ مواد اٹھایا جائے گا۔ PATH:
pre-commit --version
devskim --version
ٹائپ کرتے وقت ان لائن فیڈ بیک حاصل کرنے کے لیے، DevSkim VS Code ایکسٹینشن بھی انسٹال کریں۔ CLI وہی ہے جسے گٹ ہکس استعمال کرتے ہیں۔
پری کمٹ کنفیگریشن بنائیں
DevSkim کا CLI بعد میں واحد ذریعہ راستہ اختیار کرتا ہے۔ -Iجبکہ pre-commit چلائی جا رہی کمانڈ میں تمام تیار فائل ناموں کو شامل کرتا ہے۔ گزرنا devskim analyze لہذا جیسے ہی ایک کمٹ ایک سے زیادہ فائلوں کو چھوتا ہے، اسے فوری طور پر ختم کردیا جاتا ہے۔
سب سے آسان حل ایک چھوٹا ریپر ہے جو ہر فائل کے نام پر ایک بار DevSkim کو کال کرتا ہے۔ بنانا scripts/run-devskim.py ذخیرہ سے:
import subprocess
import sys
exit_code = 0
for filename in sys.argv[1:]:
result = subprocess.run(["devskim", "analyze", "-I", filename])
exit_code = exit_code or result.returncode
sys.exit(exit_code)
ابھی بنائیں .pre-commit-config.yaml ذخیرہ کی جڑ سے:
repos:
- repo: local
hooks:
- id: devskim
name: DevSkim security lint
entry: python scripts/run-devskim.py
language: system
types_or: [python, javascript, typescript, json, yaml]
pass_filenames: true
- repo: https://github.com/gitleaks/gitleaks
rev: v8.30.1
hooks:
- id: gitleaks
پہلا ہک درج شدہ اقسام سے مماثل تیار فائلوں کے خلاف DevSkim چلاتا ہے۔ دوسرا خفیہ پتہ لگانے کے لیے Gitleaks کا اضافہ کرتا ہے، جسے DevSkim کو ہینڈل کرنے کے لیے ڈیزائن نہیں کیا گیا ہے۔
چیزوں کو آسان رکھنے اور ہر کمٹ پر پوری ریپوزٹری کو اسکین کرنے کے لیے، ریپر کو گرائیں اور اس کے بجائے ایک ہی جامد راستہ استعمال کریں۔
- id: devskim
name: DevSkim security lint
entry: devskim analyze -I .
language: system
pass_filenames: false
اس ورژن کے بارے میں استدلال کرنا آسان ہے، لیکن جیسے جیسے آپ کے ذخیرے میں اضافہ ہوتا ہے وہ آہستہ ہوتا جاتا ہے۔ اگر آپ کے پروجیکٹ کی اصل تاریخ ہے تو مرحلہ وار فائل کی بازیافت ایک بہتر ڈیفالٹ ہے۔
گٹ ہک انسٹال کریں۔
اسے اپنے ذخیرے کی جڑ سے ایک بار چلائیں:
pre-commit install
اب ہر git commit ترتیب شدہ چیک کو متحرک کرتا ہے۔
آپ اپنے پورے کوڈ بیس کے خلاف دستی طور پر ہکس چلا سکتے ہیں۔
pre-commit run --all-files
یہ خاص طور پر مفید ہے جب کسی موجودہ پروجیکٹ میں ٹولز کو متعارف کرایا جائے۔ ہم ابتدائی نتائج کے منتظر ہیں۔ پرانے ذخیروں میں اکثر ایسے نمونے ہوتے ہیں جو موجودہ حفاظتی معیارات کو پیش کرتے ہیں۔
جان بوجھ کر ناکامی کی وجہ سے ترتیبات کی تصدیق
ہک پر بھروسہ کرنے سے پہلے، آپ یہ یقینی بنانا چاہیں گے کہ یہ حقیقت میں کسی چیز کو روکتا ہے۔ نامی ایک فائل بنائیں insecure-example.js کمزور ہیشنگ کالز استعمال کرتے وقت:
const crypto = require("crypto");
const hash = crypto.createHash("md5").update("password").digest("hex");
تیاری کریں اور عزم کرنے کی کوشش کریں۔
git add insecure-example.js
git commit -m "Test security hooks"
عہد نامے کو مسترد کیا جائے۔ pre-commit فی ہک ایک سٹیٹس لائن پرنٹ کرتا ہے، پھر ناکام ہک کی ID، اس کا ایگزٹ کوڈ، اور اسکینر کے اپنے نتائج۔
DevSkim security lint....................................................Failed
- hook id: devskim
- exit code: 1
[DevSkim output listing the weak hash finding appears here]
DevSkim کے دریافت متن میں ورژن اور قواعد کے لحاظ سے قطعی شکل کے ساتھ اصول ID، شدت کا لیبل، فائل اور لائن شامل ہے۔ جو چیز اہم ہے وہ ایک غیر صفر ایگزٹ کوڈ اور بلاک شدہ کمٹ ہے۔
اگر کوئی ہک غیر متوقع طور پر گزر جاتا ہے، تو مسئلہ کا تعین کرنے کے لیے براہ راست اسکین چلائیں۔
devskim analyze -I insecure-example.js
اگر نتیجہ کی اطلاع دی جاتی ہے لیکن ہک نہیں ہے، تو مسئلہ ہے .pre-commit-config.yaml DevSkim نہیں.
مثال: ہارڈ کوڈ شدہ راز کو حاصل کرنا
راز وہ ہیں جہاں لنٹرز اور خفیہ سکینر فرق کرتے ہیں۔ DevSkim کے عمومی اسناد کے اصول باقاعدہ اظہار پر مبنی ہیں اور ٹوکنز کی طرح لمبی اقدار کو ہدف بناتے ہیں، لہذا ایک پڑھنے کے قابل پلیس ہولڈر سٹرنگ عام طور پر ان میں سے گزرتی ہے۔ ایک قدر جو اصل کلید کی طرح نظر آتی ہے ایک زیادہ حقیقت پسندانہ امتحان ہے۔
const apiKey = "4f2a9c1e7b6d3a8f0c5e9b2d7a41c6";
تبدیلیاں تیار کریں اور ہک چلائیں۔
git add config.js
pre-commit run
یہ بالکل وہی ہے جس کے لیے خفیہ سکینر بنائے جاتے ہیں۔ Gitleaks آپ کے اسناد کے مطابق اینٹروپی اور پیٹرن کی جانچ پڑتال کا اطلاق کرتا ہے، لہذا ہک سے اس طرح کی اقدار کو بلاک کرنے کی توقع ہے، اور اسٹیٹس لائن ناکامی اور غیر صفر ایگزٹ کوڈ کی اطلاع دے گی۔ یہاں، DevSkim کے نتائج کو اس کنٹرول کے بجائے بونس کے طور پر سمجھیں جس پر آپ انحصار کرتے ہیں۔ اس لیے دونوں ٹولز ساتھ ساتھ ہیں۔
حل یہ ہے کہ اقدار کو سورس کنٹرول سے باہر لے جایا جائے۔
const apiKey = process.env.PAYMENT_API_KEY;
اصل قدر کو ایک منظور شدہ خفیہ مینیجر جیسے Azure Key Vault، GitHub ایکشن سیکرٹس، یا کسی اور منظم پلیٹ فارم میں ذخیرہ کیا جانا چاہیے۔
یہ چھوٹی تبدیلی اہم ہے۔ آپ کے ارتکاب کے بعد کسی راز کو ہٹانا زیادہ مشکل ہے کیونکہ آپ کی Git کی تاریخ، نقلیں، CI لاگز، اور تعیناتی کے نظام میں پہلے سے ہی راز موجود ہو سکتا ہے۔
اس بات کی تصدیق کرنے کے بعد کہ دونوں ہکس توقع کے مطابق کام کرتے ہیں، ٹیسٹ فائل کو حذف کر دیں۔ اسکینر کو جانچنے کے لیے اپنی اصلی اسناد کا استعمال نہ کریں۔
ہک کو تیز اور مرکوز رکھیں
ڈویلپرز سست ہکس کو نظرانداز کرتے ہیں۔ ایک اچھی مقامی سیکیورٹی تلاش کو تیزی سے مکمل کرنا چاہیے اور اعلیٰ اعتماد کے نتائج پر توجہ مرکوز کرنی چاہیے۔
صرف مقامی طور پر ترتیب دی گئی یا تبدیل شدہ فائلوں کو اسکین کرکے شروع کریں، پھر اپنے CI کے مزید وسیع اسکینز کا شیڈول بنائیں۔ سب سے پہلے انتہائی شدت کے نتائج کو مسدود کریں، جیسے بے نقاب راز یا حساس، غیر محفوظ APIs کا استعمال۔ کم اعتماد کے نتائج کو نظرثانی کے لیے رپورٹ کیا جا سکتا ہے جب کہ ٹیم شور مچانے والے قوانین اور دستاویزات کو جائز دبانے کو ایڈجسٹ کرتی ہے۔
غلط مثبت ہینڈلنگ
جامد تجزیہ میں غلط مثبت کی توقع کی جاتی ہے۔ اسکینر کو مکمل طور پر غیر فعال کرنا ایک غلط جواب ہوگا۔ چیک کریں کہ آیا نتائج فائدہ مند ہیں اور اگر کوئی حقیقی خطرہ ہے تو انہیں ٹھیک کریں۔ جب مستثنیات کی تصدیق کی جاتی ہے تو، تنگ پابندیاں استعمال کی جاتی ہیں اور وجوہات کو ریکارڈ کیا جاتا ہے اور ان کا باقاعدگی سے جائزہ لیا جاتا ہے۔
وسیع اخراج سے بچیں، جیسے کہ پوری ڈائریکٹریز کو چھوڑنا، جب تک کہ کوئی واضح تکنیکی وجہ نہ ہو۔ وسیع اخراج اندھا دھبے ہوتے ہیں۔
سی آئی میں سیکیورٹی چیک بھی شامل کریں۔
پری کمٹ ہکس ڈویلپر کے تاثرات کو بہتر بناتے ہیں، لیکن نافذ نہیں ہوتے ہیں۔ آپ یہ استعمال کرتے ہوئے ہک کو چھوڑ سکتے ہیں:
git commit --no-verify
اسی لیے سی آئی پر ایک جیسے یا مساوی سیکیورٹی چیک چلائے جائیں۔ ذیل میں ایک GitHub ایکشن ورک فلو ہے جو ہر پل کی درخواست کے لیے دونوں ٹولز چلاتا ہے۔ بطور محفوظ کریں۔ .github/workflows/security.yml:
name: Security Checks
on:
pull_request:
push:
branches: [main]
jobs:
scan:
runs-on: ubuntu-latest
permissions:
contents: read
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: actions/setup-dotnet@v4
with:
dotnet-version: "8.0.x"
- name: Install DevSkim
run: dotnet tool install --global Microsoft.CST.DevSkim.CLI
- name: Run DevSkim
run: devskim analyze -I . -f sarif -O devskim.sarif
- name: Upload DevSkim results
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: devskim.sarif
- name: Run Gitleaks
uses: gitleaks/gitleaks-action@v2
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
یہاں چند تفصیلات کا ذکر کرنا ضروری ہے۔ fetch-depth: 0 Gitleaks وہ مکمل تاریخ فراہم کرتا ہے جس کی آپ کو ماضی کے وعدوں کو تلاش کرنے کی ضرورت ہوتی ہے، نہ کہ صرف تجاویز۔ SARIF اپ لوڈز آپ کے ریپوزٹری کے سیکیورٹی ٹیب پر DevSkim کے نتائج بھیجتے ہیں، تاکہ آپ انہیں اپنے بلڈ لاگ میں دفن کیے بغیر GitHub پر ان کا جائزہ لے سکیں۔ مائیکروسافٹ ایک DevSkim ایکشن بھی شائع کرتا ہے اگر آپ خود CLI انسٹالیشن کا انتظام نہیں کرنا چاہتے ہیں۔
یہاں ہم تبدیل شدہ کوڈ پر تیز رفتار رائے کے لیے پری کمٹ کے لیے ریلیز پائپ لائن، SAST کے لیے ایک پل ریکوئسٹ پائپ لائن، خفیہ اسکیننگ اور انحصار کی جانچ، مکمل اسکیننگ اور رپورٹنگ کے لیے مین برانچ کی تعمیر، اور اہم نتائج کے لیے گیٹ کا استعمال کرتے ہیں۔ یہ پرتوں والا نقطہ نظر ڈویلپر کے تجربے اور حکمرانی کو متوازن کرتا ہے۔
عملی رول آؤٹ ٹپس
نئے قواعد کو نافذ کرنے سے پہلے ایک یا دو ذخیروں سے شروع کریں اور موجودہ نتائج کی بنیاد رکھیں۔ ابتدائی طور پر صرف اعلیٰ اعتماد، اعلیٰ اثر والے مسائل کو مسدود کریں، پھر اپنے نتائج اور اصلاحات کی مثالیں ڈیولپرز کے ساتھ شیئر کریں۔ بار بار چلنے والے نمونوں کا سراغ لگا کر محفوظ کوڈنگ کی تعلیم کی رہنمائی کریں، اور صرف دریافتوں پر توجہ مرکوز کرنے کے بجائے اپنانے اور نظر ثانی کے اوقات کی پیمائش کریں۔
مقصد ایک اور ٹول بنانا نہیں ہے جسے نظر انداز کیا جائے، بلکہ ڈیولپرز کو بطور ڈیفالٹ محفوظ انتخاب کرنے میں مدد کرنا ہے۔
حتمی خیالات
حفاظتی ٹولز سب سے زیادہ قیمتی ہوتے ہیں جب وہ اس وقت ظاہر ہوتے ہیں جب ڈویلپر کارروائی کر سکتے ہیں۔ پری کمٹ ہکس فوری طور پر محفوظ کوڈنگ فیڈ بیک فراہم کرتے ہیں، اور CI پروڈکشن سسٹم اور وسیع تر کوریج کے لیے درکار کوریج فراہم کرتا ہے۔
DevSkim Shift-Left سیکورٹی پریکٹسز بنانے والی ٹیموں کے لیے ایک مفید ہلکا پھلکا انٹری پوائنٹ ہے، اور جب ایک سرشار خفیہ سکینر کے ساتھ مل جاتا ہے، تو یہ لنٹرز کے ذریعے خالی ہونے والے خلا کو پُر کر سکتا ہے۔ چھوٹی شروعات کریں، قواعد کو ایڈجسٹ کریں، اسکینز کو تیز رکھیں، اور CI کی توثیق اور محفوظ کوڈنگ رہنما خطوط کے ساتھ اپنے ورک فلو کو سپورٹ کریں۔
اکثر بہترین حفاظتی کنٹرول وہ ہوتے ہیں جو پہلے جگہ پر مسائل پیدا ہونے سے روکتے ہیں۔