CI/CD pipeline security: SaaS deployment hardening checklist
Least-privilege tokens, trusted actions, isolated runners, protected releases, short-lived deployment identity और build evidence के साथ SaaS CI/CD workflows सुरक्षित करें।
इस मार्गदर्शिका में
CI/CD pipeline security क्यों जरूरी है?
CI/CD pipeline code को tested artifacts में बदलती है और उन्हें publish या deploy कर सकती है। Pipeline को source code, signing keys, cloud accounts और production तक पहुँच हो सकती है, इसलिए compromised workflow का असर एक application server से बड़ा हो सकता है। Build और deployment system को production infrastructure की तरह संभालें: identities और trust boundaries map करें, हर job का अधिकार घटाएँ और release रास्ते को verify करने योग्य बनाएँ।
Workflow triggers, identities और release boundaries map करें
Repositories, workflow events, third-party actions, runners, artifact registries, environments और cloud roles की सूची बनाएँ। चिन्हित करें कि कौन-से triggers fork या untrusted contributor का code चला सकते हैं और कौन-सी jobs production credentials पढ़ या release लिख सकती हैं। हर deployment workflow का owner तय करें और बेकार triggers तथा permissions हटाएँ।
हर workflow के token permissions न्यूनतम रखें
हर job के लिए केवल जरूरी repository permissions घोषित करें और जहाँ संभव हो default token को read-only रखें। Build, test, publish और deploy jobs अलग करें ताकि pull-request test को production write access न मिले। Platform समर्थन करे तो environment secrets पर reviewer approval और branch या tag restrictions लगाएँ।
Third-party build components pin और review करें
हर action या plugin का source और permissions review करें। GitHub Actions में जहाँ व्यावहारिक हो third-party action को verified full commit SHA पर pin करें, controlled update process रखें और कौन-सी actions चल सकती हैं सीमित करें। Version tag update में आसान है लेकिन अलग code पर जा सकता है, इसलिए यह बदल सकने वाला trust decision है।
| Workflow / trigger | Code पर भरोसे का स्तर | Token permissions | Secrets / environment | Reviewer और release प्रमाण |
|---|---|---|---|---|
| Pull request checks | ||||
| Release build | ||||
| Production deploy |
SaaS team builds और deployment credentials को कैसे अलग रखे?
Untrusted contribution workflows को privileged secrets से अलग रखें
Fork-controlled code को privileged event context में न चलाएँ जहाँ repository secrets या write tokens उपलब्ध हों। विशेष रूप से, untrusted pull request को checkout और execute करने के लिए `pull_request_target` का उपयोग न करें। Review और test jobs को protected deployment jobs से अलग रखें और boundary के पार केवल reviewed artifacts भेजें।
संवेदनशील builds के लिए disposable runners अपनाएँ
Production credentials या signed artifacts संभालने वाली jobs में साफ, कम अवधि के runners को प्राथमिकता दें। Self-hosted runners में jobs के बीच isolation, सीमित network access, patching और cleanup योजना जरूरी है; persistent worker attacker-controlled files या processes अगली build तक ले जा सकता है। सामान्य build step को container-engine socket या व्यापक host credentials न दें।
जहाँ उपलब्ध हो लंबे समय की cloud keys की जगह workload identity लें
OIDC trust relationship के जरिए deployment, trusted workflow identity को short-lived cloud credential में बदल सकती है। इस trust को repository, branch या protected environment claims से बाँधें और केवल जरूरी deployment role दें। Provider की exact claim mapping verify करें; broad trust rule किसी अन्य workflow को role दिला सकती है।
Release को traceable और recoverable कैसे बनाएँ?
एक बार build करके वही artifact आगे बढ़ाएँ
Reviewed commit से versioned artifact बनाएँ, उसका digest record करें और वही artifact test से production तक promote करें। हर environment में अलग build करने पर यह साबित करना कठिन होता है कि जाँची गई चीज़ ही deploy हुई। Source commit, dependency inventory, build identity और release approval को आपस में जोड़ें।
Provenance और artifact integrity checks जोड़ें
जहाँ समर्थन हो, source और build process बताने वाला build provenance या attestation बनाएँ और release से पहले उसे verify करें। Production artifacts को publish या replace कौन कर सकता है सीमित करें और अनपेक्षित release पर alert रखें। Provenance traceability बढ़ाती है, पर source code harmless या build system uncompromised होने का प्रमाण नहीं।
Workflow बदलाव monitor करें और credential containment का अभ्यास करें
Workflow files, runner settings, environment protections, token permissions और release policies में बदलाव record करें। असामान्य secret access, unexpected deployment identity use और artifact replacement पर alert दें। Runner या action compromised होने के संदेह पर workflow रोकने, cloud identity revoke करने और release फिर build करने का अभ्यास करें।
CI/CD pipeline security के सवाल
क्या pull-request workflow deployment secrets पढ़ सकती है?
उसे इसकी जरूरत नहीं होनी चाहिए। Untrusted code को कम-से-कम read-only permissions और बिना production secrets के चलाएँ। Deployment को अलग protected workflow या environment में रखें जो केवल reviewed code और trusted artifacts स्वीकार करे।
क्या pinned action अपने-आप सुरक्षित हो जाती है?
नहीं। Full commit SHA पर pin करने से referenced code बदल नहीं सकता, फिर भी source, permissions, maintenance और behavior review करना जरूरी है। Security fixes छूटें नहीं, इसलिए reviewed प्रक्रिया से pins update करें।
क्या OIDC deployment risk खत्म कर देता है?
नहीं। OIDC लंबे समय तक रहने वाली cloud key को short-lived credential से बदल सकता है, लेकिन trust policy और role का scope फिर भी सीमित होना चाहिए। Compromised trusted workflow को role जितना अधिकार देगा, उतना access मिल सकता है।
क्या CI pipeline green होने से release सुरक्षित साबित होती है?
नहीं। Automated checks कुछ चुनी स्थितियाँ जाँचते हैं और design flaws, compromised dependencies या build-system compromise छोड़ सकते हैं। CI checks के साथ threat modeling, code review, dependency controls, artifact verification, production monitoring और incident response रखें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .