1. शुरू करने से पहले
CodeMender की मदद से सीआई (CI)/सीडी (CD) पाइपलाइन को सुरक्षित करने के लिए, कोडलैब में आपका स्वागत है.
आज के समय में सॉफ़्टवेयर डिलीवरी के लिए, CodeQL जैसे स्टैटिक ऐनलिसिस टूल ज़रूरी हैं. इनसे सिंटैक्स के जाने-पहचाने पैटर्न का पता लगाया जा सकता है. हालांकि, ये टूल अक्सर कारोबारी नियम में छिपी हुई बारीकियों का पता नहीं लगा पाते. साथ ही, ये ग़ैर-ज़रूरी और बिना पुष्टि वाली चेतावनियां जनरेट करते हैं.
CodeMender (सीएलआई एक्ज़ीक्यूटेबल: cm), आपकी सीआई/सीडी पाइपलाइन को बेहतर बनाता है. यह मौजूदा एसएएसटी टूल के साथ काम करता है. इसके लिए, यह Google के Gemini की मदद से काम करने वाले सिक्योरिटी रीज़निंग एजेंट को डिप्लॉय करता है, ताकि:
कारोबारी नियमों में मौजूद जटिल गड़बड़ियों का पता लगाना: ऐप्लिकेशन के कॉन्टेक्स्ट और आर्किटेक्चरल डेटा फ़्लो के बारे में जानकारी देना. यह जानकारी, स्टैटिक पैटर्न के नियमों से अलग होती है.
सेल्फ़-एक्सप्लॉइट की पुष्टि करने की सुविधा की मदद से, फ़ॉल्स पॉज़िटिव की संख्या को काफ़ी कम करें: डेवलपर को सूचना देने से पहले, सैंडबॉक्स किए गए एनवायरमेंट में एक्सप्लॉइट की संभावना को डाइनैमिक तरीके से साबित करें.
पुष्टि की गई समस्याओं को अपने-आप ठीक करना: कोड पैच को सिंथेसाइज़ करना, रिग्रेशन को रोकने के लिए टेस्ट सुइट की मदद से पुष्टि करना, और समीक्षा के लिए तैयार पुल रिक्वेस्ट सबमिट करना.
इस कोडलैब में, आपको GitHub Actions और बिना कुंजी वाले Google Cloud Workload Identity Federation (WIF) का इस्तेमाल करके, CodeMender को OWASP Juice Shop रिपॉज़िटरी में इंटिग्रेट करने का तरीका बताया जाएगा.
ज़रूरी शर्तें
- सुझाव: CodeMender के कॉन्सेप्ट की बुनियादी जानकारी होनी चाहिए. इसके बारे में CodeMender की मदद से अपने ऐप्लिकेशन को सुरक्षित करें में बताया गया है
- GitHub Actions के वर्कफ़्लो, ट्रिगर, और YAML सिंटैक्स की बुनियादी जानकारी
- Git कमांड और पुल रिक्वेस्ट की समीक्षा करने वाले वर्कफ़्लो की बुनियादी जानकारी
- Google Cloud IAM के कॉन्सेप्ट (सेवा खाते, भूमिकाएं, और एपीआई) की बुनियादी जानकारी
- वेब ऐप्लिकेशन में आम तौर पर होने वाली कमियों की जानकारी होना. जैसे, एसक्यूएल इंजेक्शन और एक्सएसएस
आपको क्या सीखने को मिलेगा
- Workload Identity Federation (WIF) की मदद से, GitHub Actions और Google Cloud के बीच बिना पासकोड के पुष्टि करने की ज़ीरो-ट्रस्ट सुविधा को कॉन्फ़िगर करने का तरीका
- CodeMender और
gemini-3.8-flashका इस्तेमाल करके, कमियां पता लगाने वाला ऑटोमेटेड वर्कफ़्लो बनाने का तरीका - OASIS SARIF v2.1.0 और नेटिव GitHub Actions Job Summaries का इस्तेमाल करके, सुरक्षा से जुड़ी ऐसी रिपोर्ट पब्लिश करने का तरीका जिन पर कार्रवाई की जा सके
- अपने-आप समस्या ठीक करने वाला वर्कफ़्लो बनाने का तरीका. इससे, टेस्ट करके पुष्टि किए गए कोड पैच जनरेट होते हैं और मैन्युअल तरीके से समीक्षा करने के लिए पुल का अनुरोध खुलता है
- तेज़ और लगातार सुरक्षा के लिए, ऑटोमेटेड क्वालिटी हार्ड गेट (
--fail-on) और पाइपलाइन कैश मेमोरी को लागू करने का तरीका
आपको इन चीज़ों की ज़रूरत होगी
- बिलिंग की सुविधा वाला Google क्लाउड प्रोजेक्ट और प्रोजेक्ट के मालिक/एडिटर की अनुमतियां
- एक GitHub खाता, जिसके पास रिपॉज़िटरी बनाने, सीक्रेट कॉन्फ़िगर करने, और कार्रवाइयां मैनेज करने की अनुमतियां हों. GitHub सीएलआई का इस्तेमाल करके, तीसरे चरण में OWASP Juice Shop GitHub रिपॉज़िटरी को फ़ोर्क किया जाता है.
2. CodeMender के सीआई/सीडी आर्किटेक्चर को समझना
आज के एंटरप्राइज़ DevSecOps में, एआई की मदद से काम करने वाली सुरक्षा, सिर्फ़ मैन्युअल डेस्कटॉप टूल नहीं हो सकती. इसे ऑटोमेटेड गेटकीपर (असुरक्षित पुल रिक्वेस्ट को ब्लॉक करना) और ऑटोनॉमस को-डेवलपर (पुष्टि किए गए पैच को सीधे Git में भेजना) के तौर पर काम करना चाहिए.
इसके लिए, आपको Dual-Workflow Architecture लागू करना होगा. यह Google Cloud Workload Identity Federation (WIF) और Gemini Enterprise के रीज़निंग मॉडल की मदद से काम करता है.
ड्यूअल-वर्कफ़्लो आर्किटेक्चर
सुरक्षा से जुड़ी समस्याओं का पता लगाने और उन्हें ठीक करने के लिए, एक ही स्क्रिप्ट का इस्तेमाल करने के बजाय, पाइपलाइन सुरक्षा को दो अलग-अलग वर्कफ़्लो में बांटती है:
वर्कफ़्लो | प्राइमरी ट्रिगर | मुख्य ज़िम्मेदारी | क्वालिटी हार्ड गेट |
1. कमियां पता लगाने वाला स्कैनर( | पुल रिक्वेस्ट, मेन पुश, वीकली क्रॉन, मैन्युअल डिस्पैच | • पीआर पर तेज़ी से डिफ़्रेंशियल एएसटी स्कैन (~15 सेकंड) करता है, पुश ( | पीआर मर्ज को ब्लॉक करता है, अगर नई गंभीर या बहुत गंभीर कमज़ोरियों का पता चलता है ( |
2. ऑटोनॉमस रेमेडिएटर( | मैन्युअल ट्रिगर ( | • स्कैन आर्टफ़ैक्ट ( | पीआर खोलने से पहले, यह पक्का करता है कि प्रोडक्शन डिफ़ में कोई गड़बड़ी न हो |
एंटरप्राइज़ डिज़ाइन के तीन मुख्य सिद्धांत
आने वाले सेक्शन में इन वर्कफ़्लो को बनाते समय, इन तीन बुनियादी आर्किटेक्चरल पिलर को ध्यान में रखें:
🔑 ज़ीरो-ट्रस्ट कीलेस ऑथेंटिकेशन और प्रीफ़्लाइट वैलिडेशन:
GitHub Secrets में, Google Cloud सेवा खाते की लंबे समय तक इस्तेमाल की जाने वाली कोई भी JSON कुंजी सेव नहीं की जाती है. रनर, एक छोटा ओआईडीसी टोकन जनरेट करता है. इसे Google Cloud STS के ज़रिए, एक घंटे के लिए मान्य क्रेडेंशियल से बदला जाता है. इसके बाद, Git चेकआउट पर persist-credentials: false सेट करता है. साथ ही, मॉडल कोटा इस्तेमाल करने से पहले, क्रेडेंशियल, नेटवर्क रीचेबिलिटी, और आईएएम अनुमतियों की पुष्टि करने के लिए cm health --strict चलाता है.
⚡ अडैप्टिव स्कैन रूटिंग और लेगसी शोर को दबाना:
हर पुल रिक्वेस्ट पर पूरी रिपॉज़िटरी का ऑडिट करने में समय लगता है. इसलिए, CodeMender हर सीआई इवेंट को सबसे सही स्कैन मोड पर भेजता है: पुल रिक्वेस्ट, बदली गई फ़ाइलों और 1-हॉप कॉलर पर डिफ़्रेंशियल एएसटी विश्लेषण (--diff="origin/$BASE_REF") को ट्रिगर करती हैं. इसमें 15 सेकंड से कम समय लगता है; मुख्य-शाखा पुश, सिंगल-सेशन क्विक बेसलाइन स्कैन (--quick) चलाते हैं; और हर हफ़्ते के शेड्यूल, एक साथ कई फ़ाइलों के डीप ऑडिट (डिफ़ॉल्ट cm find .) चलाते हैं. पीआर से अछूती, पहले से मौजूद कोड बेस की कमज़ोरियों को [LEGACY / UNTOUCHED] के तौर पर लेबल किया जाता है; वे विज़िबिलिटी के लिए SARIF रिपोर्ट में दिखती हैं, लेकिन पीआर मर्ज गेट को ब्लॉक नहीं करती हैं और ऑटोफ़िक्स को ट्रिगर नहीं करती हैं.
सुरक्षा से जुड़ी समस्याओं का पता लगाने की क्षमता: यह क्षमता, सुरक्षा से जुड़ी समस्याओं का पता लगाने के साथ-साथ, उन्हें हल करने में भी मदद करती है.
अगर --fail-on, असुरक्षित पीआर को ब्लॉक करने के लिए कोड 1 के साथ बंद हो जाता है, तो भी steps.scan.outputs.completed == 'true' और hashFiles('results.sarif') != '' की मदद से रिपोर्ट एक्सपोर्ट करने और SARIF अपलोड करने के चरणों को सुरक्षित रखा जा सकता है. इससे यह गारंटी मिलती है कि OASIS SARIF चेतावनियां और जॉब की खास जानकारी अब भी पब्लिश होगी. साथ ही, अगर कोई रन रद्द हो जाता है या सेटअप या क्षमता से जुड़ी गड़बड़ी (10–60) की वजह से बंद हो जाता है, तो एक्सपोर्ट और अपलोड करने की प्रोसेस को आसानी से छोड़ा जा सकता है.
3. Cloud Shell में टारगेट रिपॉज़िटरी की पुष्टि करना और उसे तैयार करना
बिना पासकोड के पुष्टि करने की सुविधा सेट अप करने और ऑटोमेटेड सिक्योरिटी पाइपलाइन चलाने के लिए, आपके पास एक ऐसी GitHub रिपॉज़िटरी होनी चाहिए जिसे ऐक्सेस किया जा सके. इस कोडलैब में, OWASP जूस शॉप का इस्तेमाल किया जाता है. यह Node.js वेब ऐप्लिकेशन है, जिसे जान-बूझकर असुरक्षित बनाया गया है. इसका इस्तेमाल, सुरक्षा से जुड़े प्रयोग करने के लिए किया जाता है.
GitHub से पुष्टि करने, उपयोगकर्ता की जानकारी अपने-आप कैप्चर करने, और रिपॉज़िटरी को एक आसान फ़्लो में तैयार करने के लिए, आपको GitHub सीएलआई (gh) का इस्तेमाल करना होगा. यह Google Cloud Shell में पहले से इंस्टॉल होता है.
पहला चरण: Cloud Shell खोलना और GitHub सीएलआई की पुष्टि करना
Google Cloud Console खोलें और Cloud Shell चालू करें. इसके लिए, सबसे ऊपर मौजूद नेविगेशन बार में आइकॉन >_ पर क्लिक करें.
Git क्रेडेंशियल मैनेजमेंट को कॉन्फ़िगर करने के लिए, GitHub CLI (gh) की पुष्टि करें:
gh auth login --hostname github.com --git-protocol https --web
स्क्रीन पर दिए गए निर्देशों का पालन करें:
Cloud Shell में प्रिंट किए गए आठ वर्णों वाले वन-टाइम कोड को कॉपी करें. उदाहरण के लिए, 1234-ABCD.
अपने ब्राउज़र में https://github.com/login/device खोलने के लिए, Enter दबाएं.
कोड चिपकाएं और GitHub को अनुमति दें पर क्लिक करें.
दूसरा चरण: वैरिएबल को डाइनैमिक तौर पर एक्सपोर्ट करना और OWASP जूस शॉप को फ़ोर्क करना
Cloud Shell में ये कमांड चलाएं, ताकि आपके GitHub उपयोगकर्ता नाम को अपने-आप कैप्चर किया जा सके और रिपॉज़िटरी को तैयार किया जा सके:
# 1. Automatically capture your GitHub username (customize GITHUB_REPO if desired)
export GITHUB_ORG=$(gh api user -q .login)
export GITHUB_REPO="${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_ORG:+${GITHUB_ORG}/${GITHUB_REPO}}"
echo "Authenticated as: ${GITHUB_REPOSITORY}"
# 2. Fork on GitHub server using GITHUB_REPO as the fork name
gh repo fork juice-shop/juice-shop --fork-name "${GITHUB_REPO}" --default-branch-only --clone=false 2>/dev/null || true
# 3. Shallow clone your fork (downloads only ~15 MB in 3-5 seconds, skipping heavy upstream git history)
[ -d ~/"${GITHUB_REPO}" ] || git clone --depth=1 "https://github.com/${GITHUB_REPOSITORY}.git" ~/"${GITHUB_REPO}" || \
(sleep 2 && git clone --depth=1 "https://github.com/${GITHUB_REPOSITORY}.git" ~/"${GITHUB_REPO}")
cd ~/"${GITHUB_REPO}"
# 4. Confirm you are in the repository directory
git status
4. gcloud के ज़रिए Google Cloud Workload Identity Federation को कॉन्फ़िगर करना
इस चरण में, Google Cloud Shell में gcloud सीएलआई का इस्तेमाल करके, ज़रूरी एपीआई चालू किए जाएंगे. साथ ही, एक खास सीआई/सीडी सेवा खाता बनाया जाएगा, Workload Identity पूल सेट अप किया जाएगा, और आपके GitHub डेटाबेस (${GITHUB_REPOSITORY}) के साथ ओआईडीसी ट्रस्ट सेट अप किया जाएगा.
पहला चरण: Google Cloud के एनवायरमेंट वैरिएबल सेट करना
अपने Cloud Shell टर्मिनल (क्लोन किए गए रिपॉज़िटरी फ़ोल्डर में) में, अपने चालू Google Cloud प्रोजेक्ट आईडी को कैप्चर करें. साथ ही, GitHub रिपॉज़िटरी वैरिएबल की पुष्टि करें और डब्ल्यूआईएफ़ संसाधन के नाम तय करें:
# Capture active Google Cloud Project ID and verify GitHub repository
export PROJECT_ID=$(gcloud config get-value project)
export GITHUB_USER=$(gh api user -q ".login")
export GITHUB_REPO="${GITHUB_REPO:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*/##; s#\.git$##')}"
export GITHUB_REPO="${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_USER:+${GITHUB_USER}/${GITHUB_REPO}}"
# Define WIF and Service Account resource names
export WORKLOAD_IDENTITY_POOL="codemender-github-pool"
export WORKLOAD_IDENTITY_PROVIDER="codemender-github-provider"
export SERVICE_ACCOUNT_NAME="codemender-ci-runner"
if [ -z "${PROJECT_ID}" ] || [ -z "${GITHUB_REPOSITORY}" ]; then
echo "ERROR: PROJECT_ID ('${PROJECT_ID}') or GITHUB_REPOSITORY ('${GITHUB_REPOSITORY}') is empty. Check 'gcloud config get-value project' and 'gh auth status'."
else
echo "Project ID: ${PROJECT_ID}"
echo "GitHub Repository: ${GITHUB_REPOSITORY}"
fi
दूसरा चरण: ज़रूरी Google Cloud API चालू करना
IAM API, Security Token Service API, IAM Credentials API, Agent Platform API, और Resource Manager API को चालू करें:
gcloud services enable \
iam.googleapis.com \
iamcredentials.googleapis.com \
sts.googleapis.com \
aiplatform.googleapis.com \
cloudresourcemanager.googleapis.com \
--project=${PROJECT_ID}
तीसरा चरण: सीआई/सीडी के लिए एक सेवा खाता बनाना
सीआई/सीडी पाइपलाइन को चलाने के लिए, कम से कम अनुमतियों वाला Google Cloud सेवा खाता बनाएं. अगर ऐसा खाता पहले से मौजूद है, तो उसे सुरक्षित तरीके से फिर से इस्तेमाल करें:
export SERVICE_ACCOUNT_EMAIL="${SERVICE_ACCOUNT_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"
gcloud iam service-accounts describe "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}" >/dev/null 2>&1 || \
gcloud iam service-accounts create "${SERVICE_ACCOUNT_NAME}" \
--display-name="CodeMender CI/CD Pipeline Runner" \
--project="${PROJECT_ID}"
echo "Service Account Email: ${SERVICE_ACCOUNT_EMAIL}"
चौथा चरण: Agent Platform को IAM की अनुमतियां देना
सेवा खाते को roles/aiplatform.user (एजेंट प्लैटफ़ॉर्म उपयोगकर्ता) की भूमिका असाइन करें, ताकि वह Gemini Enterprise एजेंट प्लैटफ़ॉर्म के साथ कम्यूनिकेट कर सके:
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
--role="roles/aiplatform.user"
पांचवां चरण: Workload Identity Pool बनाना
GitHub Actions की पहचान की पुष्टि करने के लिए, Workload Identity Pool बनाएं. इसके अलावा, अगर यह आपके प्रोजेक्ट में पहले से मौजूद है, तो इसे अपने-आप वापस लाएं और चालू करें:
POOL_STATE=$(gcloud iam workload-identity-pools list \
--location="global" \
--show-deleted \
--project="${PROJECT_ID}" \
--filter="name ~ /${WORKLOAD_IDENTITY_POOL}$" \
--format="value(state)")
if [ -z "${POOL_STATE}" ]; then
gcloud iam workload-identity-pools create "${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--display-name="CodeMender GitHub Pool" \
--project="${PROJECT_ID}"
else
[ "${POOL_STATE}" = "DELETED" ] && gcloud iam workload-identity-pools undelete "${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--project="${PROJECT_ID}"
gcloud iam workload-identity-pools update "${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--no-disabled \
--project="${PROJECT_ID}"
fi
छठा चरण: GitHub OIDC की मदद से, Workload Identity Provider बनाना
पूल में ओआईडीसी प्रोवाइडर बनाएं या उसे अपडेट करें. साथ ही, जारी करने वाले के यूआरएल https://token.actions.githubusercontent.com को बाइंड करें और GitHub टोकन के दावे को Google एसटीएस एट्रिब्यूट से मैप करें:
PROVIDER_STATE=$(gcloud iam workload-identity-pools providers list \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--show-deleted \
--project="${PROJECT_ID}" \
--filter="name ~ /${WORKLOAD_IDENTITY_PROVIDER}$" \
--format="value(state)")
if [ -z "${GITHUB_REPOSITORY}" ]; then
echo "ERROR: GITHUB_REPOSITORY is empty. Re-run Step 1 before configuring the OIDC provider."
elif [ -z "${PROVIDER_STATE}" ]; then
gcloud iam workload-identity-pools providers create-oidc "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--display-name="CodeMender GitHub Provider" \
--issuer-uri="https://token.actions.githubusercontent.com" \
--attribute-mapping="google.subject=assertion.sub,attribute.actor=assertion.actor,attribute.repository=assertion.repository,attribute.repository_owner=assertion.repository_owner" \
--attribute-condition="assertion.repository == '${GITHUB_REPOSITORY}'" \
--project="${PROJECT_ID}"
else
[ "${PROVIDER_STATE}" = "DELETED" ] && gcloud iam workload-identity-pools providers undelete "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--project="${PROJECT_ID}"
gcloud iam workload-identity-pools providers update-oidc "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--issuer-uri="https://token.actions.githubusercontent.com" \
--attribute-mapping="google.subject=assertion.sub,attribute.actor=assertion.actor,attribute.repository=assertion.repository,attribute.repository_owner=assertion.repository_owner" \
--attribute-condition="assertion.repository == '${GITHUB_REPOSITORY}'" \
--no-disabled \
--project="${PROJECT_ID}"
fi
सातवां चरण: GitHub रिपॉज़िटरी को सेवा खाते के तौर पर काम करने की अनुमति देना
roles/iam.workloadIdentityUser भूमिका को बाइंड करें, ताकि आपकी रिपॉज़िटरी से जनरेट होने वाले टोकन, सीआई रनर सेवा खाते के तौर पर काम कर सकें. साथ ही, नीति की बाइंडिंग की पुष्टि करें:
# Retrieve the canonical Workload Identity Pool resource ID
export POOL_ID=$(gcloud iam workload-identity-pools describe "${WORKLOAD_IDENTITY_POOL}" \
--project="${PROJECT_ID}" \
--location="global" \
--format="value(name)")
if [ -z "${POOL_ID}" ] || [ -z "${GITHUB_REPOSITORY}" ]; then
echo "ERROR: POOL_ID ('${POOL_ID}') or GITHUB_REPOSITORY ('${GITHUB_REPOSITORY}') is empty. Re-run Step 1 and Step 5."
else
# Bind Workload Identity User role to the principalSet of your repository
gcloud iam service-accounts add-iam-policy-binding "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}" \
--role="roles/iam.workloadIdentityUser" \
--member="principalSet://iam.googleapis.com/${POOL_ID}/attribute.repository/${GITHUB_REPOSITORY}"
# Verify the principalSet binding on the Service Account
gcloud iam service-accounts get-iam-policy "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}"
fi
आठवां चरण: GitHub सीक्रेट के लिए कॉन्फ़िगरेशन वैल्यू हासिल करना
अपने Workload Identity प्रोवाइडर का पूरा संसाधन नाम वापस पाएं. साथ ही, अगले चरण में अपने-आप रजिस्ट्रेशन होने के लिए, इसे एनवायरमेंट वैरिएबल में सेव करें:
# Retrieve full Workload Identity Provider name
export WORKLOAD_PROVIDER_NAME=$(gcloud iam workload-identity-pools providers describe ${WORKLOAD_IDENTITY_PROVIDER} \
--workload-identity-pool=${WORKLOAD_IDENTITY_POOL} \
--location="global" \
--project=${PROJECT_ID} \
--format="value(name)")
echo "=========================================================="
echo "WIF CONFIGURATION READY:"
echo "=========================================================="
echo "GCP_WORKLOAD_IDENTITY_PROVIDER: ${WORKLOAD_PROVIDER_NAME}"
echo "GCP_SERVICE_ACCOUNT: ${SERVICE_ACCOUNT_EMAIL}"
echo "=========================================================="
5. GitHub रिपॉज़िटरी के सीक्रेट और वर्कफ़्लो की अनुमतियां कॉन्फ़िगर करना
Google Cloud WIF को सेट अप करने के बाद, आपको GitHub रिपॉज़िटरी सीक्रेट को कॉन्फ़िगर करना होगा. साथ ही, सुरक्षा से जुड़ी समस्याओं का अपने-आप पता लगाने और उन्हें ठीक करने के लिए, पुल के अनुरोधों को ज़रूरी वर्कफ़्लो अनुमतियां देनी होंगी.
GitHub सीएलआई (gh) का इस्तेमाल करके, Cloud Shell से सीधे तौर पर इन सेटिंग को कॉन्फ़िगर किया जा सकता है. इससे, संसाधनों के लंबे नामों को मैन्युअल तरीके से कॉपी-पेस्ट करने की ज़रूरत नहीं पड़ती.
पहला चरण: GitHub सीएलआई का इस्तेमाल करके, रिपॉज़िटरी के सीक्रेट सेट करना
अपने Cloud Shell टर्मिनल में, ये कमांड चलाएं. इससे, ऐक्टिव एनवायरमेंट वैरिएबल का इस्तेमाल करके, रिपॉज़िटरी के दो ज़रूरी सीक्रेट सुरक्षित तरीके से सेट किए जा सकेंगे:
# 1. Set the Workload Identity Provider resource name
gh secret set GCP_WORKLOAD_IDENTITY_PROVIDER \
--body "${WORKLOAD_PROVIDER_NAME}" \
--repo "${GITHUB_REPOSITORY}"
# 2. Set the CI/CD Service Account email
gh secret set GCP_SERVICE_ACCOUNT \
--body "${SERVICE_ACCOUNT_EMAIL}" \
--repo "${GITHUB_REPOSITORY}"
# 3. Verify the secrets are registered
gh secret list --repo "${GITHUB_REPOSITORY}"
दूसरा चरण: अपने-आप होने वाले पीआर के लिए, वर्कफ़्लो की अनुमतियां देना
डिफ़ॉल्ट रूप से, GitHub Actions वर्कफ़्लो सिर्फ़ रीड-ओनली अनुमतियों के साथ चलते हैं. साथ ही, ये पुल के अनुरोध नहीं बना सकते. नौवें चरण में, CodeMender अपने-आप पुल रिक्वेस्ट जनरेट करेगा और सबमिट करेगा. इन पुल रिक्वेस्ट में, कोड में मौजूद गड़बड़ियों को ठीक करने के लिए ज़रूरी बदलाव शामिल होंगे.
GitHub API के ज़रिए, सीधे तौर पर फ़ाइल या एंट्री में बदलाव करने की अनुमतियां दें और पुल का अनुरोध करने की सुविधा चालू करें:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_REPOSITORY:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*github\.com[:/]##; s#\.git$##')}"
gh api \
--method PUT \
-H "Accept: application/vnd.github+json" \
/repos/${GITHUB_REPOSITORY}/actions/permissions/workflow \
-f default_workflow_permissions="write" \
-F can_approve_pull_request_reviews=true
तीसरा चरण: Juice Shop के इनहेरिट किए गए अपस्ट्रीम वर्कफ़्लो बंद करना
OWASP जूस शॉप को फ़ोर्क करने पर, 16 से ज़्यादा अपस्ट्रीम सीआई वर्कफ़्लो (जैसे, PR Compliance Check, CI/CD Pipeline, और CodeQL Scan) के साथ-साथ अपस्ट्रीम योगदान देने वाले पीआर टेंप्लेट भी शामिल होते हैं. यह टेंप्लेट, master को टारगेट करने वाले पीआर को अपने-आप बंद कर देता है. GitHub CLI का इस्तेमाल करके, CodeMender के अलावा अन्य सभी वर्कफ़्लो बंद करें. साथ ही, अपस्ट्रीम फ़ाइलों को स्थानीय तौर पर हटाएं, ताकि आपका फ़ोर्क सिर्फ़ CodeMender वर्कफ़्लो चलाए:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_REPOSITORY:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*github\.com[:/]##; s#\.git$##')}"
# 1. Disable all inherited non-CodeMender workflows in GitHub Actions (and CodeQL default setup if active)
for WF_ID in $(gh workflow list --all --limit 100 --repo "${GITHUB_REPOSITORY}" --json id,path \
-q '.[] | select((.path | startswith(".github/workflows/")) and (.path | test("codemender-") | not)) | .id'); do
gh workflow disable "${WF_ID}" --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
done
gh api -X PATCH "/repos/${GITHUB_REPOSITORY}/code-scanning/default-setup" \
-f state=not-configured >/dev/null 2>&1 || true
# 2. Remove upstream workflow files and PR template from the local workspace
for f in .github/workflows/*; do
case "$f" in *codemender-*) ;; *) rm -f "$f" ;; esac
done
rm -f .github/PULL_REQUEST_TEMPLATE.md
6. SARIF की मदद से, कमियां पता लगाने वाला ऑटोमेटेड वर्कफ़्लो बनाना
इस चरण में, आपको लगातार सुरक्षा स्कैनिंग करने वाला मुख्य वर्कफ़्लो (.github/workflows/codemender-scan.yml) बनाना होगा. यह वर्कफ़्लो, ब्रांच पुश पर बेसलाइन स्कैन, पुल रिक्वेस्ट पर डिफ़्रेंशियल गेट, और GitHub कोड स्कैनिंग में SARIF एक्सपोर्ट को चलाता है.
पहला चरण: CodeMender का स्कैनिंग वर्कफ़्लो डाउनलोड करना
codemender-scan.yml को स्टार्टर रिपॉज़िटरी से .github/workflows/ में डाउनलोड करें:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
mkdir -p .github/workflows
curl -fsSL https://raw.githubusercontent.com/edwardc-gcp/codemender-github-actions/main/.github/workflows/codemender-scan.yml \
-o .github/workflows/codemender-scan.yml
दूसरा चरण: कमिट करना, पुश करना, और सीआई स्कैनिंग को ट्रिगर करना
वर्कफ़्लो में किए गए बदलावों को कमिट करें और उन्हें सीधे अपनी रिपॉज़िटरी की प्राइमरी ब्रांच (Juice Shop के लिए master या main) में पुश करें:
# Stage workflow changes, commit, and push to primary branch
git add -A .github
git commit -m "ci: add CodeMender SARIF security scanning workflow"
git push origin $(git branch --show-current)
अपने ब्राउज़र में:
फ़ोर्क की गई GitHub रिपॉज़िटरी पर जाएं: https://github.com/YOUR_GITHUB_USER/juice-shop (उदाहरण के लिए, https://github.com/octocat/juice-shop).
सबसे ऊपर मौजूद नेविगेशन बार में, कार्रवाइयां टैब पर क्लिक करें.
बाईं ओर मौजूद साइडबार में, Workflows में जाकर, CodeMender Security Scan & SARIF Export को चुनें.
वर्कफ़्लो को ट्रिगर करें या उसे पूरा होने की प्रक्रिया देखें:
अपने-आप ट्रिगर होना: अगर आपके पुश से ट्रिगर होने वाला कोई ऑटोमैटिक रन लिस्ट में मौजूद है, तो लाइव एक्ज़ीक्यूशन को मॉनिटर करने के लिए सीधे उस पर क्लिक करें.
मांग पर मैन्युअल ट्रिगर (workflow_dispatch): अगर अब तक कोई रन शुरू नहीं हुआ है, तो दाईं ओर मौजूद Run workflow ▾ बटन पर क्लिक करें. पक्का करें कि Branch: master चुना गया हो. deep_scan चेकबॉक्स से सही का निशान हटा दें, ताकि तेज़ी से स्कैन करने वाला --quick बेसलाइन स्कैन चले. इसके बाद, हरे रंग के Run workflow बटन पर क्लिक करें.
एक्ज़ीक्यूट हो रहे रन पर क्लिक करें और Autonomous Code Vulnerability Scan को चुनें. इससे आपको रीयल-टाइम में वर्कफ़्लो को स्पिन अप होते हुए देखने को मिलेगा.
codemender-scan.yml में: इवेंट के हिसाब से स्कैन रूटिंग
जब --quick बेसलाइन स्कैन क्लाउड में चलता है (करीब 3 से 5 मिनट), तब देखें कि codemender-scan.yml (लाइन 118 से 155), हर GitHub इवेंट को रनर के अंदर उसके स्कैन मोड पर कैसे रूट करता है:
# Excerpt from .github/workflows/codemender-scan.yml
if [ "${{ github.event_name }}" = "pull_request" ]; then
cm find . \
--diff="origin/${{ github.base_ref }}" \
--diff-workers=16 \
--fail-on="CRITICAL,HIGH" \
--sandbox=false --yes --bypass-warning || status=$?
elif [ "${{ github.event_name }}" = "schedule" ] || [ "${{ github.event.inputs.deep_scan }}" = "true" ]; then
cm find . \
--deep-workers=8 \
--sandbox=false --yes --bypass-warning || status=$?
else
cm find . \
--quick \
--sandbox=false --yes --bypass-warning || status=$?
fi
Hardened Runner Setup ( लाइन 27–117): यह सेटअप, मॉडल के कोटे का इस्तेमाल करने से पहले, बाहरी फ़ोर्क और dependabot[bot] पीआर को स्किप करता है. साथ ही, persist-credentials: false के साथ चेक आउट करता है, ~/.local/bin/cm और ~/.codemender/state.db को कैश मेमोरी में सेव करता है, और cm health --strict को चलाता है.
हेडलेस सैंडबॉक्स बाउंड्री (--sandbox=false --yes --bypass-warning): यह Linux यूज़र-नेमस्पेस आइसोलेशन को बंद कर देता है. यह आइसोलेशन, बिना खास अधिकार वाले GitHub Actions कंटेनर में सीमित होता है. हालांकि, यह वर्कस्पेस पाथ बाउंड्री (project_paths) और command_policy.yaml को लागू रखता है.
एग्ज़िट-कोड गार्डेड एसएआरआईएफ़ और आर्टफ़ैक्ट एक्सपोर्ट ( लाइन 147–194): steps.scan.outputs.completed=true को तब सेट करता है, जब cm find, 0 (क्लीन) या 1 (--fail-on थ्रेशोल्ड पूरा हो गया) के साथ एग्ज़िट करता है. इससे यह पक्का होता है कि --fail-on के किसी पीआर को ब्लॉक करने पर भी, SARIF रिपोर्ट (cm report -f sarif, जिसमें सीवीएसएस के गंभीरता स्कोर शामिल हैं), $GITHUB_STEP_SUMMARY टेबल (cm report -f md), और codemender-findings.json आर्टफ़ैक्ट पब्लिश होते रहें. साथ ही, सेटअप या क्षमता से जुड़ी गड़बड़ियों (10–60) की वजह से एक्सपोर्ट न होने पर, खाली SARIF फ़ाइलें मौजूदा चेतावनियों को बंद न करें.
7. GitHub कोड स्कैनिंग से जुड़ी चेतावनियां और सुरक्षा डैशबोर्ड देखना
बेसलाइन पुश वर्कफ़्लो पूरा होने के बाद, GitHub अपलोड की गई SARIF फ़ाइल को प्रोसेस करता है. साथ ही, कार्रवाइयों के चलने की खास जानकारी और डेटाबेस के सुरक्षा टैब, दोनों को भरता है.
पहला चरण: GitHub Actions पर नेटिव जॉब की खास जानकारी देखना
हर वर्कफ़्लो रन, GitHub Actions रन की खास जानकारी में सीधे तौर पर मार्कडाउन की खास जानकारी वाली टेबल (cm report -f md) जोड़ता है:
अपनी GitHub रिपॉज़िटरी में, Actions टैब पर क्लिक करें.
पूरा हो चुका CodeMender Security Scan & SARIF Export रन चुनें. SARIF फ़ाइंडिंग पब्लिश होने के बाद, बेसलाइन ब्रांच पुश ऑडिट के पूरा होने पर हरे रंग का ✅ सही का निशान दिखता है.
नतीजों की जानकारी देखने के लिए, नीचे की ओर स्क्रोल करके 🛡️ CodeMender Security Scan Summary सेक्शन पर जाएं:
🔒 CodeMender की सुरक्षा रिपोर्ट
खास जानकारी
कुल समस्याएं: 28
गंभीरता | गिनती |
🔴 गंभीर | 6 |
🟠 ज़्यादा | 16 |
🟡 मीडियम | 6 |
स्टेटस | गिनती |
🔴 खुला है | 28 |
नतीजे
आईडी | गंभीरता | कॉन्फ़िडेंस | स्टेटस | ठीक करें | फ़ाइल | Title |
| 🔴 गंभीर | 100% | खोलें | — |
| उपयोगकर्ता की प्रोफ़ाइल में सर्वर-साइड कोड इंजेक्शन के ज़रिए रिमोट कोड एक्ज़ीक्यूशन |
| 🔴 गंभीर | 100% | खोलें | — |
| उपयोगकर्ता की पुष्टि करने के रूट में एसक्यूएल इंजेक्शन |
| 🔴 गंभीर | 100% | खोलें | — |
| Remote Code Execution via Sandbox Escape in B2B Order Processing |
दूसरा चरण: कोड स्कैनिंग के लिए बनाए गए डैशबोर्ड को एक्सप्लोर करना
अपनी GitHub रिपॉज़िटरी के सबसे ऊपर मौजूद नेविगेशन बार में, सुरक्षा और क्वालिटी (या सुरक्षा) टैब पर क्लिक करें.
बाईं ओर मौजूद साइडबार में, Findings में जाकर, Code scanning को चुनें.
अगर एक से ज़्यादा टूल चालू हैं, तो टूल को CodeMender (is:open branch:master tool:CodeMender) पर फ़िल्टर करें. इससे, नेटिव सीवीएसएस गंभीरता बैज के साथ मैप की गई चेतावनियों की जांच की जा सकेगी:
गंभीरता का बैज | कमज़ोरी की हेडलाइन | जगह की जानकारी का पता चला | Branch |
🔴 गंभीर | उपयोगकर्ता की प्रोफ़ाइल में सर्वर-साइड कोड इंजेक्शन के ज़रिए रिमोट कोड एक्ज़ीक्यूशन |
|
|
🔴 गंभीर | उपयोगकर्ता की पुष्टि करने के रूट में एसक्यूएल इंजेक्शन |
|
|
🔴 गंभीर | Remote Code Execution via Sandbox Escape in B2B Order Processing |
|
|
उपयोगकर्ता की पुष्टि करने के रूट में एसक्यूएल इंजेक्शन (routes/login.ts:34) पर क्लिक करें. इससे, Gemini की मदद से जनरेट किए गए, नुकसान पहुंचाने वाले डेटाफ़्लो और असल वजह के विश्लेषण की समीक्षा की जा सकेगी.
8. डिफ़रेंशियल स्कैनिंग की मदद से, असुरक्षित पुल अनुरोध को ब्लॉक करना
आपके बेसलाइन स्कैन से, OWASP जूस शॉप में पहले से मौजूद 28 कमज़ोरियों का पता चला. अगर परंपरागत स्टैटिक ऐनालाइज़र का इस्तेमाल किया जाता, तो ये 28 लेगसी गड़बड़ियां, आने वाले समय में किए जाने वाले हर पुल का अनुरोध को तब तक फ़ेल करती रहतीं, जब तक कि सभी गड़बड़ियों को ठीक नहीं कर लिया जाता. इस वजह से, टीमों को मर्ज ब्लॉक करने की सुविधा बंद करनी पड़ती.
अब आपको CodeMender के पीआर डिफ़रेंशियल एएसटी गेट (--diff + --fail-on="CRITICAL,HIGH") को टेस्ट करना होगा: एक ऐसा पुल अनुरोध खोलें जिसमें कोई नई सुरक्षा जोखिम मौजूद हो. इसके बाद, देखें कि CodeMender किस तरह डेल्टा को अलग करता है, करीब 15 से 25 सेकंड में मर्ज को ब्लॉक करता है, और गड़बड़ी वाली लाइनों को एनोटेट करता है.
पहला चरण: कमांड इंजेक्शन की गड़बड़ी वाला पुल अनुरोध खोलना
Cloud Shell (क्लोन किए गए रिपॉज़िटरी फ़ाइल फ़ोल्डर में) में, एक फ़ीचर ब्रांच बनाएं. साथ ही, ओएस कमांड इंजेक्शन की जोखिम वाली जानकारी वाला एक नया एक्सप्रेस रूट जोड़ें. इसके बाद, अपने फ़ोर्क के लिए पुल का अनुरोध खोलें:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_REPOSITORY:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*github\.com[:/]##; s#\.git$##')}"
PRIMARY_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD | sed 's@^origin/@@')
# Reset any previous demo PR/branch so this step can be re-run cleanly
gh pr close feat/diagnostics --repo "${GITHUB_REPOSITORY}" --delete-branch 2>/dev/null || true
git checkout "${PRIMARY_BRANCH}"
git checkout -B feat/diagnostics
# Introduce an Express endpoint vulnerable to OS Command Injection (CWE-78)
cat << 'EOF' > routes/diagnostics.ts
import { execSync } from 'node:child_process'
import { type Request, type Response } from 'express'
export function systemDiagnostics () {
return (req: Request, res: Response) => {
const host = String(req.query.host ?? '127.0.0.1')
const output = execSync(`ping -c 1 ${host}`).toString()
res.status(200).json({ status: 'ok', output })
}
}
EOF
git add routes/diagnostics.ts
git commit -m "feat: add network diagnostics endpoint"
git push -f -u origin feat/diagnostics
gh pr create \
--repo "${GITHUB_REPOSITORY}" \
--base "${PRIMARY_BRANCH}" \
--head feat/diagnostics \
--title "feat: add network diagnostics endpoint" \
--body "Adds a ping diagnostics handler."
दूसरा चरण: डिफ़रेंशियल मर्ज गेट और इनलाइन पीआर एनोटेशन की पुष्टि करना
टर्मिनल आउटपुट के आखिर में प्रिंट किया गया पुल रिक्वेस्ट यूआरएल खोलें.
पुल रिक्वेस्ट के बातचीत वाले पेज पर सबसे नीचे मौजूद, जांच बॉक्स तक स्क्रोल करें और कोड में मौजूद कमियों का अपने-आप पता लगाने की सुविधा देखें:
डेल्टा स्पीड: रिपॉज़िटरी में मौजूद सभी 680 से ज़्यादा फ़ाइलों को स्कैन करने के बजाय (~3 से 5 मिनट), cm find . --diff="origin/${PRIMARY_BRANCH}" सिर्फ़ routes/diagnostics.ts (और किसी भी 1-हॉप कॉलर) का विश्लेषण करता है. इससे स्कैन ~15 से 25 सेकंड में पूरा हो जाता है.
लेगसी डेब्ट आइसोलेशन और मर्ज ब्लॉकिंग: Juice Shop की 28 लेगसी कमज़ोरियों में से कोई भी कमज़ोरी, जांच में फ़ेल नहीं होती. सिर्फ़ नई CRITICAL कमांड इंजेक्शन की वजह से --fail-on="CRITICAL,HIGH" ट्रिगर होता है. साथ ही, पीआर मर्ज को ब्लॉक करने के लिए, स्टेटस कोड 1 (लाल ❌) के साथ बाहर निकलता है!
पुल रिक्वेस्ट के सबसे ऊपर मौजूद, Files changed टैब पर क्लिक करें:
वर्कफ़्लो का एग्ज़िट-कोड गार्ड (steps.scan.outputs.completed == 'true') अब भी results.sarif को एक्सपोर्ट और अपलोड करता है. ऐसा तब होता है, जब --fail-on, कोड 1 के साथ एग्ज़िट करता है. GitHub कोड स्कैनिंग, routes/diagnostics.ts में execSync के ठीक नीचे, इनलाइन CodeMender — गंभीर सुरक्षा एनोटेशन रेंडर करता है!
तीसरा चरण: टेस्ट पीआर को मिटाना और प्राइमरी ब्रांच पर वापस जाना
अपने Cloud Shell वर्कस्पेस को वापस प्राइमरी ब्रांच पर स्विच करें और अपने-आप ठीक होने की प्रोसेस शुरू करने से पहले, असुरक्षित टेस्ट पुल का अनुरोध बंद करें:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_REPOSITORY:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*github\.com[:/]##; s#\.git$##')}"
PRIMARY_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD | sed 's@^origin/@@')
git checkout "${PRIMARY_BRANCH}"
gh pr close feat/diagnostics --repo "${GITHUB_REPOSITORY}" --delete-branch
git branch -D feat/diagnostics 2>/dev/null || true
9. समस्याओं को अपने-आप ठीक करने और पीआर को अपने-आप मर्ज करने वाला वर्कफ़्लो बनाना
अब पुल रिक्वेस्ट गेट, कोड बेस में नई कमियों को आने से रोकता है. इसलिए, आपको ऑटोनॉमस रेमेडिएशन (.github/workflows/codemender-remediate.yml) को डिप्लॉय करना होगा, ताकि मौजूदा कमियों को ठीक किया जा सके और समीक्षा के लिए तैयार पुल रिक्वेस्ट को खोला जा सके.
पहला चरण: समस्या हल करने वाले वर्कफ़्लो की फ़ाइल डाउनलोड करना
CodeMender, रिपॉज़िटरी की विज़िबिलिटी के आधार पर, समस्या को ठीक करने के लिए दो टेंप्लेट उपलब्ध कराता है:
सार्वजनिक / ओपन-सोर्स रिपॉज़िटरी (codemender-remediate.yml): ज़िम्मेदारी के साथ जानकारी ज़ाहिर करने का मोड—यह GitHub कोड स्कैनिंग के एसएआरआईएफ़ अलर्ट से लिंक करता है. इसमें, नुकसान पहुंचाने वाले रॉ एक्सप्लॉइट वेक्टर को सार्वजनिक तौर पर ज़ाहिर नहीं किया जाता.
निजी / एंटरप्राइज़ रिपॉज़िटरी (codemender-remediate-private-repo.yml): इंटरनल ऑडिट एविडेंस मोड—यह मोड, पुष्टि करने वाले आर्टफ़ैक्ट (PLAN.md, REPORT.md, exploit.sh) को छोटा किए जा सकने वाले पीआर सेक्शन में एम्बेड करता है. साथ ही, उन्हें Git कमिट से बाहर रखता है.
अपनी रिपॉज़िटरी में, सार्वजनिक तौर पर सुरक्षित समस्या हल करने वाला वर्कफ़्लो डाउनलोड करें:
mkdir -p .github/workflows
curl -fsSL https://raw.githubusercontent.com/edwardc-gcp/codemender-github-actions/main/.github/workflows/codemender-remediate.yml \
-o .github/workflows/codemender-remediate.yml
दूसरा चरण: समस्या को ठीक करने के लिए, अपने-आप काम करने वाले वर्कफ़्लो को लागू करना और ट्रिगर करना
समस्या हल करने वाले वर्कफ़्लो को अपनी मुख्य ब्रांच में कमिट और पुश करें:
git add .github/workflows/codemender-remediate.yml
git commit -m "ci: add CodeMender autonomous remediation workflow"
git push origin $(git branch --show-current)
अपने ब्राउज़र में, GitHub रिपॉज़िटरी के Actions टैब पर जाएं.
बाईं ओर मौजूद साइडबार में, वर्कफ़्लो में जाकर, CodeMender Autonomous Security Remediation & Auto-PR को चुनें.
दाईं ओर मौजूद, हरे रंग के Run workflow ड्रॉपडाउन पर क्लिक करें:
Use workflow from: पक्का करें कि डिफ़ॉल्ट ब्रांच (master) चुनी गई हो.
Specific Finding ID or prefix to fix: सातवें चरण में नोट किए गए routes/login.ts के लिए, आठ वर्णों वाला प्रीफ़िक्स डालें. उदाहरण के लिए, cd47b38a. इसे खाली छोड़ने पर, बैच रेमेडिएशन की प्रोसेस, गंभीर और ज़्यादा गंभीर कैटगरी वाली सभी खुली हुई समस्याओं पर लागू होती है. इसमें करीब 10 से 15 मिनट लगते हैं. किसी एक आईडी को टारगेट करने पर, यह प्रोसेस करीब 45 से 60 सेकंड में पूरी हो जाती है.
पॉपओवर में मौजूद हरे रंग के Run workflow बटन पर क्लिक करें और एक्ज़ीक्यूट हो रहे रन को खोलें.
codemender-remediate.yml के अंदर: अपने-आप पैच सिंथेसिस
जब CodeMender क्लाउड में पैच को सिंथेसाइज़ कर रहा हो (इसमें करीब 30 से 45 सेकंड लगते हैं), तब देखें कि codemender-remediate.yml (लाइन 111 से 184), रनर के अंदर समस्या को ठीक करने की प्रोसेस को कैसे मैनेज करता है:
ज़ीरो-स्कैन रिज़्यूम (cm report import): यह स्कैन वर्कफ़्लो से codemender-findings.json आर्टफ़ैक्ट को डाउनलोड करता है और उसे फ़ाइल फ़ोल्डर (cm report import -f codemender-findings.json) में इंपोर्ट करता है. अगर कोई आर्टफ़ैक्ट मौजूद नहीं है, तो यह cm find . --quick पर वापस चला जाता है.
हेडलेस पैच सिंथेसिस (cm fix): यह project_paths को $GITHUB_WORKSPACE पर पिन करता है. साथ ही, इंटरैक्टिव हैंग को रोकने के लिए < /dev/null को पाइप करता है. इसके अलावा, बैच लूप के दौरान --no-reset को पास करता है, ताकि नतीजों में कुल सुधारों को सुरक्षित रखा जा सके:
# Executed inside the GitHub Actions runner (codemender-remediate.yml)
cm fix "${SPECIFIC_TARGET}" --sandbox=false --yes --bypass-warning < /dev/null
Clean Production Commits ( lines 155–252): peter-evans/create-pull-request@v8 के ब्रांच (codemender/auto-remediation-${{ github.run_id }}) खोलने से पहले, .git/info/exclude के ज़रिए .cm_project, .exploit/, और अस्थायी फ़ाइलों को हटाता है. इससे सिर्फ़ प्रोडक्शन कोड में किए गए बदलावों को कमिट किया जाता है:
--- a/routes/login.ts
+++ b/routes/login.ts
@@ -28,8 +28,8 @@ module.exports = function login () {
- models.sequelize.query(`SELECT * FROM Users WHERE email = '${req.body.email || ''}' AND password = '${security.hash(req.body.password || '')}' AND deletedAt IS NULL`, { model: models.User })
+ models.sequelize.query('SELECT * FROM Users WHERE email = :email AND password = :password AND deletedAt IS NULL', {
+ replacements: { email: req.body.email || '', password: security.hash(req.body.password || '') },
+ model: models.User
+ })
तीसरा चरण: GitHub पर खोले गए नए पुल अनुरोध की समीक्षा करना
अपनी रिपॉज़िटरी में पुल रिक्वेस्ट टैब पर जाएं और नई पुल रिक्वेस्ट (उदाहरण के लिए, 🛡️ [CodeMender] Fix: SQL Injection in User Authentication Route) खोलें.
Files changed पर क्लिक करके पुष्टि करें कि सिर्फ़ routes/login.ts में बदलाव किया गया है. साथ ही, इसमें रनटाइम का कोई भी इंटरनल मेटाडेटा शामिल नहीं है.
पीआर के ब्यौरे की समीक्षा करें. यह ब्यौरा, सीधे तौर पर GitHub कोड स्कैनिंग (एसएआरआईएफ़) की सूचना से लिंक होता है. इससे मेंटेनर को साइन-ऑफ़ करने में मदद मिलती है.
10. एज केस और निजी डेटाबेस से जुड़ी समस्याएं हल करना
GitHub Advanced Security (GHAS) के बिना निजी रिपॉज़िटरी
सार्वजनिक GitHub रिपॉज़िटरी को GitHub कोड स्कैनिंग एसएआरआईएफ़ इंजेक्शन की सुविधा मुफ़्त में और अनलिमिटेड मिलती है. हालाँकि, अगर इस वर्कफ़्लो को किसी ऐसी निजी एंटरप्राइज़ रिपॉज़िटरी में डिप्लॉय किया जाता है जिसके पास GitHub Advanced Security (GHAS) का कोई चालू लाइसेंस नहीं है, तो upload-sarif चरण पूरा नहीं हो पाएगा. साथ ही, आपको यह गड़बड़ी दिखेगी:
HTTP 403: Advanced Security must be enabled for this repository to use code scanning.
समस्या का हल: स्टैंडअलोन इंटरैक्टिव एचटीएमएल रिपोर्ट फ़ॉलबैक
CodeMender में पहले से मौजूद एचटीएमएल रिपोर्ट जनरेटर (cm report -f html), एक अलग और इंटरैक्टिव सुरक्षा डैशबोर्ड बनाता है. इसमें गंभीरता की मेट्रिक वाले कार्ड, लाइन नंबर के साथ सिंटैक्स-हाइलाइट किए गए कोड स्निपेट, और इनलाइन पैच डिफ़ व्यूअर शामिल होता है. इसके लिए, किसी बाहरी वेब डिपेंडेंसी की ज़रूरत नहीं होती.
GHAS लाइसेंस के बिना निजी डेटाबेस का इस्तेमाल करने के लिए, .github/workflows/codemender-scan.yml को अपडेट करें. इससे SARIF अपलोड करने के बजाय, एचटीएमएल रिपोर्ट आर्टफ़ैक्ट को संग्रहित किया जा सकेगा:
स्टैंडअलोन एचटीएमएल रिपोर्ट जनरेट करना: Export Security Reports & Publish Job Summary चरण में, cm report -f html > codemender-audit-report.html का इस्तेमाल करके, Markdown की खास जानकारी के साथ-साथ एचटीएमएल डैशबोर्ड एक्सपोर्ट करें.
रिपोर्ट को वर्कफ़्लो आर्टफ़ैक्ट के तौर पर संग्रहित करें: Upload SARIF Report to GitHub Code Scanning (github/codeql-action/upload-sarif@v4) चरण को actions/upload-artifact@v4 से बदलें. इसे codemender-audit-report.html को अपलोड करने के लिए कॉन्फ़िगर किया गया हो (उदाहरण के लिए, आर्टफ़ैक्ट के नाम codemender-security-report के तहत).
किसी भी ब्राउज़र में स्थानीय तौर पर जांच करना: GitHub Actions वर्कफ़्लो के रन की खास जानकारी वाले पेज से सीधे codemender-security-report.zip डाउनलोड करें. इसके बाद, उसे एक्सट्रैक्ट करें और विज़ुअल ट्रायज के लिए किसी भी वेब ब्राउज़र में codemender-audit-report.html खोलें.
निजी रिपॉज़िटरी में मौजूद सुरक्षा से जुड़ी समस्याओं को अपने-आप ठीक करने की सुविधा, जिसमें ऑडिट के सबूत भी शामिल हैं
निजी कॉर्पोरेट रिपॉज़िटरी में, इंजीनियरिंग और सुरक्षा टीमों को असल वजह के विश्लेषण, एक्सप्लॉइट के सिद्धांत के प्रमाण, और समस्या को ठीक करने के प्लान की पूरी जानकारी चाहिए होती है. इसके लिए, उन्हें बाहरी टूल के डैशबोर्ड की ज़रूरत नहीं होती. हालांकि, रिपॉज़िटरी ब्रांच में एक्सप्लॉइट स्क्रिप्ट (exploit.sh) या इंटरनल मार्कडाउन फ़ाइलें (PLAN.md, LOG.md) कमिट करने से, Git का इतिहास खराब हो जाता है. साथ ही, अन्य सुरक्षा स्कैनर से गलत चेतावनियां मिल सकती हैं.
इस समस्या को हल करने के लिए, प्राइवेट रिपॉज़िटरी को ठीक करने का वर्कफ़्लो (codemender-remediate-private-repo.yml) डिप्लॉय करें:
curl -fsSL https://raw.githubusercontent.com/edwardc-gcp/codemender-github-actions/main/.github/workflows/codemender-remediate-private-repo.yml \
-o .github/workflows/codemender-remediate.yml
git add .github/workflows/codemender-remediate.yml
git commit -m "ci: switch to private repository remediation workflow with embedded audit evidence"
git push origin $(git branch --show-current)
निजी रिपॉज़िटरी में मौजूद समस्याओं को ठीक करने की सुविधा कैसे काम करती है
डाइनैमिक पीओसी वेरिफिकेशन (cm verify): यह समस्या को ठीक करने का तरीका जनरेट करने से पहले, काम करने वाले एक्सप्लॉइट को सिंथेसाइज़ और टेस्ट करता है. इससे यह पुष्टि की जाती है कि एक्सप्लॉइट का इस्तेमाल किया जा सकता है या नहीं. अगर पुष्टि करने पर, किसी ऐसी समस्या को DISMISSED के तौर पर मार्क किया जाता है जिसका इस्तेमाल नहीं किया जा सकता, तो cm fix को अपने-आप स्किप कर दिया जाता है.
Embedded PR Audit Collapsibles: यह REPORT.md, PLAN.md, और exploit.sh को /tmp/codemender-evidence/ में एक्सट्रैक्ट करता है. साथ ही, उन्हें सीधे पुल रिक्वेस्ट के ब्यौरे में <details open> कोलैप्सिबल ब्लॉक में फ़ॉर्मैट करता है, ताकि समीक्षा करने वाला व्यक्ति एक क्लिक में उनकी जांच कर सके.
आर्टफ़ैक्ट को संग्रहित करना: actions/upload-artifact@v4 की मदद से, सबूत वाले पूरे फ़ोल्डर को संग्रहित करता है.
प्रिस्टीन गिट कमिट: यह सभी रनटाइम मेटाडेटा और .exploit डायरेक्ट्री को हटा देता है, ताकि पुल रिक्वेस्ट गिट कमिट में सिर्फ़ प्रोडक्शन कोड में किए गए बदलाव शामिल हों.
Workload Identity Federation (WIF) से जुड़ी समस्या हल करने की चेकलिस्ट
डिफ़ॉल्ट रूप से, google-github-actions/auth@v2 सेटअप के दौरान एक लोकल फ़ेडरेटेड क्रेडेंशियल कॉन्फ़िगरेशन फ़ाइल लिखता है. साथ ही, असल OAuth 2.0 टोकन एक्सचेंज तब होता है, जब cm health --strict या cm find शुरू होता है. HTTP 400 या HTTP 403 की पुष्टि करने से जुड़ी गड़बड़ियों का पता लगाने के लिए, यहां दी गई चेकलिस्ट का इस्तेमाल करें:
गड़बड़ी का लक्षण | सामान्य असल वजह | पुष्टि करना और समस्या को ठीक करना |
HTTP 403 ( | सेवा खाते में | पुष्टि करें कि |
एचटीटीपी 400 ( | OIDC | चौथे चरण (पहले और छठे चरण) को फिर से चलाएं. साथ ही, पक्का करें कि |
एचटीटीपी 400 (टोकन एक्सचेंज पर | ओआईडीसी प्रोवाइडर पर, | पुष्टि करें कि |
सेटअप के तुरंत बाद, कुछ समय के लिए एचटीटीपी 403 गड़बड़ी दिखना | नई बाइंडिंग पर, ग्लोबल आईएएम और Workload Identity Federation को लागू होने में एक से पांच मिनट लग सकते हैं. | एक से दो मिनट इंतज़ार करें. इसके बाद, GitHub Actions में पूरे न हो पाए जॉब फिर से चलाएं पर क्लिक करें. |
Cloud Shell में अपने सीआई/सीडी सेवा खाते पर, लाइव Workload Identity बाइंडिंग की जांच करने के लिए, यह कमांड चलाएं:
gcloud iam service-accounts get-iam-policy "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}" \
--flatten="bindings[].members" \
--filter="bindings.role=roles/iam.workloadIdentityUser"
पुष्टि करें कि आउटपुट, roles/iam.workloadIdentityUser को principalSet://iam.googleapis.com/<POOL_ID>/attribute.repository/<GITHUB_USER>/<GITHUB_REPO> से बाइंड करता है:
--- bindings: members: principalSet://iam.googleapis.com/.../attribute.repository/<OWNER>/<REPO> role: roles/iam.workloadIdentityUser
सीआई/सीडी प्रीफ़्लाइट और सीएलआई एग्ज़िट कोड से जुड़ी समस्या हल करना
CodeMender के कमांड (cm health --strict, cm find, cm verify, और cm fix), डिटरमिनिस्टिक एग्ज़िट कोड दिखाते हैं. इससे सीआई/सीडी पाइपलाइन, सेटअप या सेवा से जुड़ी गड़बड़ियों और सुरक्षा से जुड़ी समस्याओं के बीच तुरंत अंतर कर पाती हैं:
एग्ज़िट कोड | कैटगरी | आम तौर पर होने वाली समस्याओं की असल वजह और उन्हें ठीक करने का तरीका |
| पुष्टि हो गई | परफ़ॉर्मेंस की जांच पूरी हो गई है या स्कैन पूरा हो गया है और कोई गड़बड़ी नहीं मिली है. |
| गहनों के कॉम्पोनेंट / सामान्य |
|
|
| WIF OAuth/एडीसी टोकन एक्सचेंज नहीं किया जा सका ( |
|
|
|
|
| रनर, |
|
| टारगेट प्रोजेक्ट पर सेवा खाते में |
|
| प्रीफ़्लाइट |
|
| एजेंट ने एक साथ कई टास्क पर काम करने की सीमा पूरी कर ली है. कुछ देर बाद, वर्कफ़्लो को फिर से चलाएं. |
रनटाइम से जुड़ी अन्य गड़बड़ियों के लिए, CodeMender सीआई (CI)/सीडी (CD) से जुड़ी समस्या हल करने की आधिकारिक गाइड देखें. जैसे, Git diff बेस ब्रांच रिज़ॉल्यूशन (fetch-depth: 0), संसाधन के लागू होने में होने वाली देरी या GitHub Actions में पुल का अनुरोध करने की अनुमतियां.
11. संसाधन मिटाना
अपने Google Cloud और GitHub एनवायरमेंट में, संसाधनों के लगातार इस्तेमाल को रोकने या टेस्ट कॉन्फ़िगरेशन को हटाने के लिए, यह तरीका अपनाएं.
पहला चरण: GitHub रिपॉज़िटरी के सीक्रेट हटाना और gh CLI के ज़रिए वर्कफ़्लो बंद करना
रिपॉज़िटरी के ऐक्शन सीक्रेट को पूरी तरह से मिटाने और CodeMender के वर्कफ़्लो बंद करने के लिए, GitHub CLI (gh) का इस्तेमाल करें:
# Delete the repository Actions secrets
gh secret delete GCP_WORKLOAD_IDENTITY_PROVIDER --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
gh secret delete GCP_SERVICE_ACCOUNT --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
# Disable the CodeMender workflows to prevent unwanted automatic triggers
gh workflow disable codemender-scan.yml --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
gh workflow disable codemender-remediate.yml --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
दूसरा चरण: Google Cloud Workload Identity Federation के संसाधनों को बंद करना या मिटाना
टोकन एक्सचेंज न करने पर, Workload Identity पूल, प्रोवाइडर, और सेवा खातों के लिए कोई शुल्क नहीं लिया जाता. अपने वर्कफ़्लो के हिसाब से क्लीनअप मोड चुनें:
पहला विकल्प — ऐक्सेस रोकना (अगर आपको इस प्रोजेक्ट में फिर से चलाने का प्लान है, तो हमारा सुझाव है कि आप यह विकल्प चुनें): इससे ओआईडीसी टोकन एक्सचेंज की सुविधा तुरंत बंद हो जाती है. इसके लिए, Google Cloud IAM की 30 दिनों तक सॉफ़्ट-डिलीट की गई जानकारी को सेव रखने की सुविधा या सेवा खाते uniqueId के लागू होने में लगने वाले समय को ट्रिगर नहीं किया जाता:
gcloud iam workload-identity-pools providers update-oidc "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--disabled \
--project="${PROJECT_ID}"
दूसरा विकल्प — पूरी तरह से मिटाना: इससे डब्ल्यूआईएफ़ प्रोवाइडर, पूल (30 दिनों तक DELETED स्थिति में रखा जाता है), और खास सेवा खाता मिट जाता है:
# Delete Workload Identity Provider
gcloud iam workload-identity-pools providers delete "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--project="${PROJECT_ID}" \
--quiet
# Delete Workload Identity Pool
gcloud iam workload-identity-pools delete "${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--project="${PROJECT_ID}" \
--quiet
# Delete CI/CD Service Account
gcloud iam service-accounts delete "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}" \
--quiet
12. बधाई हो
बधाई हो! आपने CodeMender की मदद से अपनी सीआई/सीडी पाइपलाइन को सुरक्षित करें कोडलैब पूरा कर लिया है!
आपने Google Cloud Workload Identity Federation, CodeMender, और GitHub Actions का इस्तेमाल करके, प्रोडक्शन-ग्रेड और ज़ीरो-ट्रस्ट DevSecOps पाइपलाइन को डिज़ाइन, बिल्ड, और ऑटोमेट कर लिया है.
आपने क्या-क्या कवर किया है
ज़ीरो-ट्रस्ट कीलेस ऑथेंटिकेशन: वर्कलोड आइडेंटिटी फ़ेडरेशन (WIF) के ज़रिए, कुछ समय के लिए मान्य GitHub ओआईडीसी टोकन को Google Cloud IAM से बाइंड करके, सेवा खाते की जोखिम भरी और लंबे समय तक मान्य रहने वाली JSON कुंजियों को हटा दिया गया है.
पीआर डिफ़रेंशियल एएसटी स्कैनिंग और लेगसी शोर को दबाना: बदली गई फ़ाइलों और डिपेंडेंसी (--diff="origin/$BASE_REF") के लिए, स्कोप के हिसाब से लगातार स्कैनिंग की सुविधा. साथ ही, लेगसी टेक्निकल डेट ([LEGACY / UNTOUCHED]) को अलग किया गया, ताकि डेवलपर के फ़ीडबैक लूप को 15 सेकंड से कम समय में पूरा किया जा सके.
अलग-अलग फ़ॉर्मैट में रिपोर्टिंग और नेटिव जॉब की खास जानकारी: GitHub कोड स्कैनिंग को एक ही जगह से मैनेज करने के लिए, OASIS SARIF v2.1.0 को नेटिव Markdown (cm report -f md >> $GITHUB_STEP_SUMMARY) के साथ इंटिग्रेट किया गया है. इससे सीआई वर्कफ़्लो के रन पेजों पर, एक्ज़ीक्यूटिव को तुरंत जानकारी दिखती है.
निगरानी में काम करने वाले एआई मॉडल की मदद से, समस्याओं को अपने-आप ठीक करना: हम सिर्फ़ सूचनाएं भेजने तक सीमित नहीं रहे, बल्कि समस्याओं को अपने-आप ठीक करने वाली पाइपलाइन भी बनाईं. ये पाइपलाइन, कोड पैच के सुझाव अपने-आप जनरेट करती हैं, रिग्रेशन टेस्ट सुइट की मदद से उनकी पुष्टि करती हैं, और समीक्षा के लिए पुल का अनुरोध खोलती हैं. इन अनुरोध में ऑडिट आर्टफ़ैक्ट भी शामिल होते हैं, ताकि इंजीनियर उन्हें मंज़ूरी दे सकें.
ऑटोमेटेड क्वालिटी हार्ड गेट: ब्रांच की सुरक्षा और मर्ज गेटिंग (--fail-on) को सख्ती से लागू किया गया है, ताकि प्रोडक्शन में खतरनाक कमियों को पहुंचने से रोका जा सके.
आर्टफ़ैक्ट-ड्रिवन स्टेट ट्रांसफ़र और वर्कस्पेस आइसोलेशन: cm report import का इस्तेमाल करके, सीआई जॉब के बीच नतीजों को आसानी से ट्रांसफ़र किया गया. साथ ही, .git/info/exclude का इस्तेमाल करके, Git के इतिहास को सुरक्षित रखा गया और क्रेडेंशियल लीक होने से रोका गया.
डेवलपर की सोच में बदलाव
DevSecOps का पारंपरिक तरीका | CodeMender Autonomous CI/CD Pipeline |
पैसिव अलर्ट डंपिंग: स्कैनर, रॉ टर्मिनल लॉग या गड़बड़ियों की स्टैटिक सूचियां प्रिंट करते हैं. इससे, गड़बड़ियों को ठीक करने की पूरी ज़िम्मेदारी डेवलपर पर आ जाती है. | ऐक्टिव को-डेवलपर: यह पुष्टि किए गए कोड पैच को सिंथेसाइज़ करता है और मर्ज करने के लिए तैयार पुल रिक्वेस्ट खोलता है, ताकि इंजीनियर उन्हें साइन-ऑफ़ कर सकें. |
गलत पॉज़िटिव की ज़्यादा संख्या: स्टैटिक एएसटी ह्यूरिस्टिक, बिना किसी सबूत के हज़ारों संभावित कमज़ोरियों को फ़्लैग करते हैं. | दो चरणों में एक्सप्लॉइट की पुष्टि: डाइनैमिक सैंडबॉक्स टेस्ट जनरेशन ( |
सीक्रेट स्टोरेज से जुड़ा जोखिम: सीआई सीक्रेट में सेव की गई सेवा खाते की लंबे समय तक इस्तेमाल होने वाली JSON कुंजियों के लीक होने और क्रेडेंशियल के गलत इस्तेमाल का खतरा रहता है. | ज़ीरो-ट्रस्ट डब्ल्यूआईएफ़: ज़रूरत पड़ने पर, Google Cloud STS के साथ शेयर किए गए कुछ समय के लिए मान्य ओआईडीसी टोकन की मदद से, बिना पासकोड के पुष्टि करने की सुविधा. |
मोनोलिथिक रीस्कैन: हर कमिट, पूरी रिपॉज़िटरी के ऑडिट को ट्रिगर करता है. इससे सीआई वर्कफ़्लो में देरी होती है और महंगे टोकन बर्बाद होते हैं. | इवेंट के हिसाब से एएसटी रूटिंग: पुल रिक्वेस्ट, 15 सेकंड के डिफ़्रेंशियल एएसटी स्कैन ( |
रिपॉज़िटरी का इतिहास खराब होना: नुकसान पहुंचाने वाली अस्थायी स्क्रिप्ट और हमले के लॉग, सीधे रिपॉज़िटरी की ब्रांच में कमिट किए जाते हैं. | एंटरप्राइज़ वर्कस्पेस हाइजीन: पीआर के ब्यौरे और वर्कफ़्लो आर्टफ़ैक्ट में, हमले के सबूत को साफ़ तौर पर एम्बेड किया गया है. इससे कोड कमिट को सुरक्षित रखा जा सकता है. |
अगले चरण
🚀 CodeMender के बारे में सीखना जारी रखें:
पहला पार्ट: CodeMender की मदद से अपने ऐप्लिकेशन को सुरक्षित करें — रिपॉज़िटरी में मौजूद जोखिमों का अपने-आप पता लगाने, पीओसी एक्सप्लॉइट की पुष्टि करने, और लोकल पैच सिंथेसिस की सुविधा को इस्तेमाल करने का तरीका जानें.
लोकल तौर पर शिफ़्ट लेफ़्ट और सर्वरलेस क्लाउड-नेटिव सीआई/सीडी: Google Cloud Build (cloudbuild.yaml) और लोकल Git प्री-कमिट हुक (cm find . --diff --staged) के लिए, सीआई/सीडी की आधिकारिक गाइड में दिए गए रेफ़रंस इंप्लिमेंटेशन देखें.
📖 दस्तावेज़ और संसाधन एक्सप्लोर करें:
Google Cloud CodeMender को सीआई/सीडी के साथ इंटिग्रेट करने के बारे में आधिकारिक गाइड
Google Cloud CodeMender का आधिकारिक दस्तावेज़
CodeMender GitHub Actions Starter Template Repository
Google Cloud Workload Identity Federation से जुड़ा दस्तावेज़
💡 अपनी रिपॉज़िटरी पर लागू करना:
स्टार्टर वर्कफ़्लो को फ़ोर्क करें और CodeMender की मदद से अपने संगठन की Python, Go, Java, Rust, और Node.js रिपॉज़िटरी को सुरक्षित करें!