ગિટહબ ક્રિયાઓ માટે વ્યવહારુ સુરક્ષા સખ્તાઇ

મુખ્ય પૃષ્ઠ » પાયથોન » ગિટહબ ક્રિયાઓ માટે વ્યવહારુ સુરક્ષા સખ્તાઇ

GitHub Actions એ GitHub પર હોસ્ટ કરાયેલા રિપોઝીટરીઝ માટે ડી-ફેક્ટો CI/CD એન્જિન બની ગયું છે., યુનિટ ટેસ્ટથી લઈને ઉત્પાદન ડિપ્લોયમેન્ટ અને ઈન્ફ્રાસ્ટ્રક્ચર ફેરફારો સુધી બધું જ પાવરિંગ કરે છે. તે સુવિધા ગંભીર ટ્રેડ-ઓફ સાથે આવે છે: વર્કફ્લો ઘણીવાર વ્યાપક વિશેષાધિકારો સાથે ચાલે છે, શક્તિશાળી ટોકન્સ અને રહસ્યોને હેન્ડલ કરે છે, અને સીધા ઉત્પાદન સિસ્ટમો સુધી પહોંચી શકે છે. જો તમે ઇરાદાપૂર્વક તેમને સખત ન કરો, તો તમે અસરકારક રીતે દરેક ખોટી ગોઠવણી, નિર્ભરતા બગ અથવા ચેડા થયેલા એકાઉન્ટને તમારા પાઇપલાઇન્સ અને ક્લાઉડ એકાઉન્ટ્સમાં ઝડપી લેન આપી રહ્યા છો.

આ માર્ગદર્શિકા GitHub ક્રિયાઓને શરૂઆતથી અંત સુધી સુરક્ષિત કરવા માટે એક વ્યાપક, અભિપ્રાયિત ચેકલિસ્ટ પર ચાલે છે.: રહસ્યોને યોગ્ય રીતે કેવી રીતે હેન્ડલ કરવા, સ્ક્રિપ્ટ ઇન્જેક્શન ટાળવા, ટોકન્સ અને ટ્રિગર્સને લોક ડાઉન કરવા, તૃતીય-પક્ષ ક્રિયાઓનું મૂલ્યાંકન કેવી રીતે કરવું, દોડવીરોનું સંચાલન કરવું અને કોડ સ્કેનિંગ, OIDC, Dependabot અને ઓડિટ લોગ જેવી બિલ્ટ-ઇન સુરક્ષા સુવિધાઓનો લાભ કેવી રીતે લેવો. ધ્યેય એ છે કે છૂટાછવાયા શ્રેષ્ઠ પ્રથાઓ, તાજેતરની ઘટનાઓમાંથી મહેનતથી મેળવેલા પાઠ અને GitHub ના પોતાના સખ્તાઇ માર્ગદર્શનને એક જ, વ્યવહારુ સંદર્ભમાં લાવવાનો છે જે તમે વાસ્તવિક પ્રોજેક્ટ્સમાં લાગુ કરી શકો છો.

GitHub ક્રિયાઓની વાસ્તવિક જોખમ પ્રોફાઇલ

ઉચ્ચ સ્તરે, GitHub Actions વર્કફ્લો ફક્ત એક YAML ફાઇલ છે જે નીચે છે .github/workflows જે એક અથવા વધુ જોબ્સને વ્યાખ્યાયિત કરે છે, દરેકમાં પગલાંઓ હોય છે. પગલાં કાં તો શેલ આદેશો ચલાવી શકે છે અથવા GitHub અથવા સમુદાય દ્વારા પ્રકાશિત ફરીથી વાપરી શકાય તેવી ક્રિયાઓનો ઉપયોગ કરી શકે છે. વર્કફ્લો પુશ, પુલ વિનંતીઓ, ઇશ્યૂ પ્રવૃત્તિ, સમયપત્રક અથવા મેન્યુઅલ ડિસ્પેચ જેવી ઘટનાઓ દ્વારા ટ્રિગર થાય છે.

સુરક્ષાના દૃષ્ટિકોણથી, તે વર્કફ્લો તમારી સોફ્ટવેર સપ્લાય ચેઇનની ટોચ પર બેસે છે.. તેઓ રિલીઝ આર્ટિફેક્ટ્સ બનાવે છે અને સહી કરે છે, ડોકર છબીઓને આગળ ધપાવે છે, ક્લાઉડ વાતાવરણમાં જમાવટ કરે છે, માળખાગત સુવિધાઓ પૂરી પાડે છે, સ્થળાંતર ચલાવે છે અને ઘણું બધું કરે છે. જો કોઈ હુમલાખોર કોડ, ગોઠવણી અથવા પર્યાવરણને નિયંત્રિત કરી શકે છે જેમાં વિશેષાધિકૃત વર્કફ્લો ચાલે છે, તો તેઓ ઘણીવાર:

• બેકડોર દ્વારા સંકલિત કલાકૃતિઓ (બાઈનરી, કન્ટેનર, પેકેજો) જે તમે પછીથી ગ્રાહકોને મોકલો છો.
• શક્તિશાળી લાંબા સમય સુધી જીવતા પ્રતીકો અને રહસ્યો બહાર કાઢો મેમરી, લોગ, કેશ અથવા કલાકૃતિઓમાંથી.
• વિશેષાધિકૃત ક્લાઉડ ભૂમિકાઓનો દુરુપયોગ કરો CI ને વધારાની સેવાઓ જમાવવા, નેટવર્કિંગ બદલવા અથવા ડેટા એક્સેસ કરવાની મંજૂરી આપવામાં આવી છે.
• પોઈઝન ડાઉનસ્ટ્રીમ પ્રોજેક્ટ્સ ઓપન-સોર્સ રિલીઝ પાઇપલાઇન્સ સાથે સમાધાન કરીને અને ટ્રોજનાઇઝ્ડ રિલીઝનું વિતરણ કરીને.

તાજેતરના વાસ્તવિક દુનિયાની ઘટનાઓએ દર્શાવેલ છે કે ગિટહબ એક્શન્સ હુમલાની સપાટી તરીકે કેટલું આકર્ષક છે.. હુમલાખોરોએ પ્રકાશિત પેકેજોમાં ક્રિપ્ટોમાઇનર્સ દાખલ કરવા માટે સંવેદનશીલ વર્કફ્લોનો દુરુપયોગ કર્યો છે, અને લોકપ્રિય tj-actions/changed-files કોઈનબેઝ સુધી પહોંચવાનો પ્રયાસ કરતા બહુ-તબક્કાના હુમલામાં કાર્યવાહીનું સમાધાન થયું. દૂષિત કોડ વર્કફ્લોમાંથી રહસ્યો કાઢે છે અને તેમને બિલ્ડ લોગમાં લખે છે, જેનાથી ફોલો-ઓન સપ્લાય ચેઇન સમાધાનનો સંભવિત કાસ્કેડ બને છે.

ધ્યાનમાં રાખવાનો મુખ્ય વિચાર એ છે કે મોટાભાગના GitHub Actions હુમલાઓ "સંભાવના × અસર" વિશે હોય છે.. તમે દૂષિત અથવા બગડેલ ઘટકો (તૃતીય-પક્ષ ક્રિયાઓ, અસુરક્ષિત દોડવીરો, જોખમી ટ્રિગર્સ) અપનાવવાની શક્યતા ઘટાડવા માંગો છો, અને તે જ સમયે જો કોઈ એક ઘટક સાથે ચેડા થાય છે તો બ્લાસ્ટ ત્રિજ્યાને નાટકીય રીતે મર્યાદિત કરવા માંગો છો.

GitHub ક્રિયાઓમાં રહસ્યો લોક કરવા

કોઈપણ CI/CD સિસ્ટમમાં રહસ્યો સામાન્ય રીતે સૌથી આકર્ષક લક્ષ્ય હોય છે.. GitHub Actions માં તે રીપોઝીટરી, ઓર્ગેનાઈઝેશન અથવા એન્વાયર્નમેન્ટ સિક્રેટ્સ તરીકે દેખાય છે, અને એડ-હોક વેલ્યુ તરીકે તમે આકસ્મિક રીતે રૂપરેખાંકનો, લોગ, કેશ અથવા આર્ટિફેક્ટ્સમાં ડમ્પ કરી શકો છો.

આંતરિક બનાવવાની પહેલી વસ્તુ એ એક્સેસ મોડેલ છે: રિપોઝીટરીમાં લખવાની ઍક્સેસ ધરાવનાર કોઈપણ વ્યક્તિ રિપોઝીટરી-સ્તરના બધા રહસ્યો અસરકારક રીતે વાંચી શકે છે.. તેઓ ફક્ત બિન-સુરક્ષિત શાખા પર અસ્તિત્વમાં રહેલા વર્કફ્લોને સુધારી શકે છે, લોગિંગ અથવા એક્સફિલ્ટ્રેશન કોડ દાખલ કરી શકે છે, અને રહસ્યો છાપવા અથવા લીક કરવા માટે તે વર્કફ્લો ચલાવી શકે છે. ગિટહબનું લોગમાં માસ્કિંગ એ શ્રેષ્ઠ પ્રયાસ સંરક્ષણ છે, અચૂક ગેરંટી નથી.

તે મોડેલ હેઠળ રહસ્યો ટકી રહેવા માટે, આ મૂળભૂત નિયમોનું પાલન કરો:

• ઓછામાં ઓછા વિશેષાધિકારનો સિદ્ધાંત લાગુ કરો: વર્કફ્લોમાં ઉપયોગમાં લેવાતા કોઈપણ ઓળખપત્રમાં ફક્ત એટલી જ પરવાનગીઓ હોવી જોઈએ જેટલી તેને સંપૂર્ણપણે જરૂરી છે. સામાન્ય હેતુના એડમિન ટોકન્સને વર્કફ્લો રહસ્યો તરીકે શેર કરવાનું ટાળો.
• સંવેદનશીલ મૂલ્યો માટે ભંડાર અથવા સંગઠન રહસ્યો કરતાં પર્યાવરણ રહસ્યોને પ્રાધાન્ય આપો. પર્યાવરણીય રહસ્યો ફક્ત તે નોકરીઓ માટે જ ઉપલબ્ધ છે જે તે પર્યાવરણની જાહેરાત કરે છે, અને તમે તેમને જરૂરી સમીક્ષકો અને શાખા પ્રતિબંધો જેવા વધારાના રક્ષણમાં લપેટી શકો છો.
• વર્કફ્લો YAML ફાઇલોમાં ક્યારેય સાદા ટેક્સ્ટમાં રહસ્યો સંગ્રહિત કરશો નહીં. અથવા રેપોમાં ચેક કરેલા કોડમાં. દરેક સંવેદનશીલ વસ્તુ GitHub Secrets મિકેનિઝમ અથવા બાહ્ય ગુપ્ત વ્યવસ્થાપકમાંથી પસાર થવી જોઈએ.
• સ્ટ્રક્ચર્ડ બ્લોબ્સ (JSON, YAML, XML) નો ઉપયોગ એક જ ગુપ્ત મૂલ્ય તરીકે ટાળો.. માસ્કિંગ મોટે ભાગે ચોક્કસ સ્ટ્રિંગ મેચિંગ પર આધાર રાખે છે; મલ્ટી-ફીલ્ડ બ્લોબ્સને વિશ્વસનીય રીતે સંપાદિત કરવા ખૂબ મુશ્કેલ છે. તેના બદલે, સંવેદનશીલ ડેટાને બહુવિધ સમર્પિત ગુપ્ત એન્ટ્રીઓમાં વિભાજીત કરો.
• બધા મેળવેલા રહસ્યોને સ્પષ્ટ રીતે રજીસ્ટર કરો. જો તમે કોઈ ગુપ્ત વસ્તુ (Base64, URL-encode, JWT signing, વગેરે) ને રૂપાંતરિત કરો છો અને તે પરિણામ ક્યારેય લોગમાં આવી શકે છે, તો રૂપાંતરિત મૂલ્યને તેના પોતાના ગુપ્ત તરીકે નોંધણી કરો જેથી GitHub તેને છુપાવવાનો પ્રયાસ કરી શકે.

પરિભ્રમણ અને સ્વચ્છતા પ્રારંભિક ગોઠવણી જેટલી જ મહત્વપૂર્ણ છે. સમયાંતરે સમીક્ષા કરો કે કયા રહસ્યો અસ્તિત્વમાં છે, કોને અને કોને ખરેખર તેમની જરૂર છે, અને જે જૂના છે તેને દૂર કરો અથવા ફેરવો. કોઈપણ શંકાસ્પદ સંપર્ક પછી (ઉદાહરણ તરીકે, લોગમાં છાપેલ ગુપ્ત, અથવા ચેડા કરાયેલ ક્રિયામાં ઉપયોગમાં લેવાયેલ), તાત્કાલિક અસરગ્રસ્ત લોગ કાઢી નાખો, ઓળખપત્રો રદ કરો અને નવા લોગ બનાવો.

સ્ક્રિપ્ટ ઇન્જેક્શન અને અસુરક્ષિત ઇન્ટરપોલેશન ટાળવું

GitHub Actions બગ્સના સૌથી સામાન્ય, છતાં સૂક્ષ્મ વર્ગોમાંનો એક એ અભિવ્યક્તિઓ દ્વારા સ્ક્રિપ્ટ ઇન્જેક્શન છે.. GitHub સમૃદ્ધ "સંદર્ભ" પૂરા પાડે છે જેમ કે github, env, secrets અને ઇવેન્ટ પેલોડ્સ, જેનો ઉપયોગ કરીને તમે વર્કફ્લોમાં ઉલ્લેખ કરો છો ${{ ... }} વાક્યરચના. તે અભિવ્યક્તિઓનું મૂલ્યાંકન GitHub દ્વારા કરવામાં આવે છે પહેલાં તમારું શેલ સ્ટેપ ચાલે છે.

જ્યારે તમે કોઈ અવિશ્વસનીય સંદર્ભને સીધા શેલ કમાન્ડમાં એમ્બેડ કરો છો, ત્યારે તમે કમાન્ડ ઇન્જેક્શનને આમંત્રણ આપો છો. ઉદાહરણ તરીકે, જો તમે કરો છો:

run: echo "new issue ${{ github.event.issue.title }} created"

અને હુમલાખોર મુદ્દાના શીર્ષકને નિયંત્રિત કરી શકે છે, તેઓ આ પ્રકારનું શીર્ષક સબમિટ કરી શકે છે $(id). પદાવલી મૂલ્યાંકન પછી પગલું બને છે:

echo "new issue $(id) created"

જે અમલમાં મૂકે છે id દોડવીર પર. શેલમાં ગમે તેટલી સંખ્યામાં અવતરણચિહ્નો બદલવાથી કે સરળ માન્યતા ઉમેરવાથી તમને આ પેટર્નથી વિશ્વસનીય રીતે બચાવી શકાશે નહીં.

GitHub જે સલામત પેટર્નની ભલામણ કરે છે તે મધ્યવર્તી પર્યાવરણ ચલનો ઉપયોગ કરવાનો છે.:

env:
TITLE: ${{ github.event.issue.title }}
run: |
echo "new issue \"$TITLE\" created"

અહીં સંભવિત પ્રતિકૂળ મૂલ્ય પર્યાવરણ ચલ તરીકે મેમરીમાં રહે છે., અને શેલ ફક્ત જુએ છે $TITLE, ગતિશીલ રીતે બનાવેલ કમાન્ડ લાઇન નથી. તમારે હજુ પણ સામાન્ય શેલ હાઇજીનની જરૂર છે (ચલોને અવતરણ કરવા, બિનજરૂરી eval ટાળવા, વગેરે), પરંતુ ખતરનાક ઇન્ટરપોલેશન પગલું દૂર કરવામાં આવ્યું છે.

જ્યારે પણ તમને એમ્બેડ કરવાની લાલચ થાય ${{ github.* }} અથવા અન્ય વપરાશકર્તા-નિયંત્રિત ડેટા સીધા run: અવરોધે છે, રોકે છે અને આગળ ધકેલે છે env: તેના બદલે. આ એક આદત તમારા વર્કફ્લોમાં સ્ક્રિપ્ટ-ઇન્જેક્શન સમસ્યાઓના એક આખા વર્ગને દૂર કરે છે.

પરવાનગીઓ અને ટોકન્સને સુરક્ષિત રીતે ગોઠવવા

આ GITHUB_TOKEN જો ડિફોલ્ટ રૂપે છોડી દેવામાં આવે તો GitHub દરેક વર્કફ્લો રનમાં જે ઇન્જેક્ટ કરે છે તે અતિ શક્તિશાળી છે. તે સામગ્રી વાંચી અને લખી શકે છે, પુલ વિનંતીઓ ખોલી અને અપડેટ કરી શકે છે, અને ઘણી રીતે રેપો સાથે ક્રિયાપ્રતિક્રિયા કરી શકે છે. ઐતિહાસિક રીતે, ઘણી સંસ્થાઓએ તેને જાણ્યા વિના વાંચન-લેખન માટે ડિફોલ્ટ કર્યું હતું.

તમારું પહેલું સખ્તાઇ પગલું ડિફોલ્ટ વર્કફ્લો ટોકન પરવાનગીઓને ફક્ત વાંચવા માટે સેટ કરવાનું હોવું જોઈએ. સંસ્થા અને/અથવા ભંડાર સ્તરે. ક્રિયાઓ રૂપરેખાંકનમાં આ માટે એક સમર્પિત સેટિંગ છે. ત્યાંથી, તમે પ્રતિ-વર્કફ્લો અથવા પ્રતિ-જોબના આધારે પસંદગીપૂર્વક વધારાની પરવાનગીઓ આપો છો, ઉદાહરણ તરીકે:

permissions:
contents: read
pull-requests: write

આ "ડિફોલ્ટ રૂપે નકારો, જ્યાં જરૂર હોય ત્યાં મંજૂરી આપો" મોડેલ હુમલાખોર ચેડા થયેલા વર્કફ્લો સાથે શું કરી શકે છે તે નાટકીય રીતે ઘટાડે છે.. તે લેખકોને કેચ-ઓલ ટોકન વારસામાં મેળવવાને બદલે તેમના કામ માટે ખરેખર કઈ ક્ષમતાઓની જરૂર છે તે વિશે વિચારવા માટે પણ મજબૂર કરે છે.

જો તમારી સંસ્થા 2023 ની શરૂઆત પહેલાં બનાવવામાં આવી હોય, તો તમારે આ ડિફોલ્ટ્સનું સ્પષ્ટપણે ઑડિટ કરવું જોઈએ. ઘણી જૂની સંસ્થાઓ પાસે હજુ પણ લખવા-સક્ષમ વર્કફ્લો ટોકન્સ છે કારણ કે તેઓ સુરક્ષિત ડિફોલ્ટ પહેલાના છે અને ક્યારેય ફેરફાર પસંદ કર્યો નથી.

ટોકન સ્કોપ ઉપરાંત, એવી સેટિંગ્સ સાથે ખૂબ સાવધ રહો જે GitHub Actions ને પુલ વિનંતીઓ મંજૂર કરવા અથવા બનાવવા દે છે.. રબર-સ્ટેમ્પ પીઆર માટે વર્કફ્લોને મંજૂરી આપવાથી તમને એવા રસ્તાઓનો દુરુપયોગ કરવા માટે ખુલે છે જ્યાં ચેડા કરાયેલી નોકરીઓ માનવ સમીક્ષા વિના દૂષિત કોડને મર્જ કરે છે. જ્યાં સુધી તમારી પાસે મજબૂત ઉપયોગ કેસ અને ચુસ્ત રેલિંગ ન હોય, ત્યાં સુધી તે સુવિધાને અક્ષમ રાખો.

તૃતીય-પક્ષ ક્રિયાઓ પસંદ કરવી અને પિન કરવી

તમે જે પણ બાહ્ય ક્રિયાનો ઉપયોગ કરો છો તે રિમોટ કોડનો એક ભાગ છે જે તમારા બાકીના કામ જેવા જ વિશેષાધિકારો સાથે ચાલે છે.. જો તે ક્રિયા દુર્ભાવનાપૂર્ણ બને, સમાધાન થાય, અથવા સંવેદનશીલ નિર્ભરતાઓ સાથે છોડી દેવામાં આવે, તો તે તમારી પાઇપલાઇનમાં એક તૈયાર પગથિયું બની જાય છે.

તૃતીય-પક્ષ ક્રિયાઓનો ઉપયોગ કરતી વખતે તમે સંરક્ષણના ઘણા સ્તરો લાગુ કરી શકો છો.:

• નાની, વિશ્વસનીય વ્હાઇટલિસ્ટથી શરૂઆત કરો. GitHub-જાળવાયેલી ક્રિયાઓ (જેમ કે actions/checkout, actions/setup-node) અને ચકાસાયેલ સર્જકો તરફથી માર્કેટપ્લેસ ક્રિયાઓ સામાન્ય રીતે રેન્ડમ રિપોઝ કરતાં વધુ સુરક્ષિત બેઝલાઇન હોય છે. ઘણી સંસ્થાઓ સંસ્થા સ્તરે "નિર્દિષ્ટ ક્રિયાઓ અને ફરીથી વાપરી શકાય તેવા વર્કફ્લોને મંજૂરી આપો" દ્વારા આને લાગુ કરે છે.
• લોકપ્રિય, સક્રિય રીતે જાળવવામાં આવેલી ક્રિયાઓની તરફેણ કરો. સંશોધન દર્શાવે છે કે ઘણી માર્કેટપ્લેસ ક્રિયાઓમાં ઓછા OpenSSF સ્કોરકાર્ડ સ્કોર્સ, સિંગલ જાળવણી કરનારાઓ અને ટૂંકા ગાળાના અથવા ખૂબ જ યુવાન માલિક ખાતા હોય છે. વ્યાપકપણે ઉપયોગમાં લેવાતી ક્રિયાઓ વધુ ચકાસણી અને ઝડપી સુધારાઓ એકત્રિત કરે છે.
• એક્શનના રેપોમાં મોટી સંખ્યામાં ખુલ્લા ડિપેન્ડાબોટ પીઆર માટે જુઓ.. તે ઘણીવાર એ સંકેત આપે છે કે જાળવણીકર્તા સુરક્ષા અપડેટ્સ લાગુ કરી રહ્યો નથી, જેના કારણે સંક્રમિત નબળાઈઓ અપ્રસ્તુત રહે છે.
• એક કરતાં વધુ જાળવણીકાર અને બિન-આર્કાઇવ્ડ, સક્રિય કોડબેઝ ધરાવતી ક્રિયાઓને પસંદ કરો. બજારમાં સેંકડો ક્રિયાઓ આર્કાઇવ કરવામાં આવે છે, જેનો અર્થ એ થાય કે કોઈ નવા સુધારાઓ અથવા સુસંગતતા અપડેટ્સ નથી અને સમય જતાં જોખમ વધતું જાય છે.

વર્ઝન પિનિંગ એ બીજો મહત્વપૂર્ણ વિષય છે. જો તમે ફક્ત ટેગ દ્વારા કોઈ ક્રિયાનો ઉલ્લેખ કરો છો, તો જેમ કે some-org/some-action@v2, તમે વિશ્વાસ કરી રહ્યા છો કે ટેગ ક્યારેય દૂષિત કોડમાં જશે નહીં. જો જાળવણી કરનાર એકાઉન્ટ અથવા રિપોઝીટરી સાથે ચેડા કરવામાં આવે તો ટૅગ્સને ફરીથી લક્ષ્ય બનાવી શકાય છે.

આજે સૌથી રક્ષણાત્મક અભિગમ એ છે કે સંપૂર્ણ કમિટ SHA પર પિન કરવું.:

uses: some-org/some-action@247835779184621ab13782ac328988703583285a

SHA પર પિન કરવાથી કોડ તમારા દ્રષ્ટિકોણથી અસરકારક રીતે અપરિવર્તનશીલ બને છે. (Git ઑબ્જેક્ટ્સ પર SHA-1 અથડામણના હુમલાથી ટૂંકું). ગેરલાભ એ છે કે જ્યારે તમે નવી સુવિધાઓ અથવા સુધારાઓ ઇચ્છો ત્યારે તમારે SHA અપડેટ કરવું આવશ્યક છે, અને જો તમે સાવચેત ન રહો તો વિવિધ વર્કફ્લો વિવિધ SHA માં ફેરવાઈ શકે છે.

તે પીડાને હળવી કરવા માટે, કેટલીક ટીમો તૃતીય-પક્ષ ક્રિયાના ઉપયોગને શેર કરેલ અથવા સંયુક્ત વર્કફ્લોમાં કેન્દ્રિત કરે છે. વ્યક્તિગત રિપોઝ તે શેર કરેલા વર્કફ્લોને ટેગ દ્વારા સંદર્ભિત કરે છે, જ્યારે શેર કરેલા વર્કફ્લો અંતર્ગત ક્રિયાઓને ચકાસાયેલ SHAs સાથે પિન કરે છે અને નિયંત્રિત કેડન્સ પર અપડેટ કરવામાં આવે છે, કેટલીકવાર ટૂલિંગ સાથે જે નવા SHAs માટે PR ખોલે છે.

તમે જે પણ વ્યૂહરચના પસંદ કરો, યાદ રાખો કે પિનિંગ એ કોઈ જાદુઈ ફાયરવોલ નથી.. કોઈ ક્રિયા રનટાઇમ પર ગતિશીલ રીતે કોડ મેળવી શકે છે (ઉદાહરણ તરીકે curl | bash પેટર્ન) અને તમારા પિનને બાયપાસ કરો. રહસ્યો અથવા લખવા-સક્ષમ ટોકન્સ સાથેની ક્રિયા પર વિશ્વાસ કરતા પહેલા તમારે હજુ પણ સ્પષ્ટ રીતે અસુરક્ષિત પેટર્ન માટે સ્રોતને સ્કિમ કરવાની જરૂર છે.

સુરક્ષિત કાર્યપ્રવાહ અને નોકરીઓ ડિઝાઇન કરવી

તમે વર્કફ્લો અને જોબ્સની રચના કેવી રીતે કરો છો તે સમાધાનના બ્લાસ્ટ રેડિયસને ખૂબ પ્રભાવિત કરે છે. એક સામાન્ય એન્ટિ-પેટર્ન એ એક વિશાળ કાર્ય છે જે કોડ, બિલ્ડ્સ, ટેસ્ટ, પેકેજો અને ડિપ્લોયની તપાસ કરે છે, આ બધું વ્યાપક પરવાનગીઓ અને ઉત્પાદન રહસ્યોની ઍક્સેસ સાથે.

કાર્યને અલગ અલગ કાર્યોમાં અને અલગ કાર્યપ્રવાહમાં વિભાજીત કરવાથી અલગતા અને સ્પષ્ટતા બંને મળે છે.. ઉદાહરણ તરીકે, તમારી પાસે હોઈ શકે છે:

• A બિલ્ડ અને ટેસ્ટ કાર્ય જે ન્યૂનતમ પરવાનગીઓ સાથે ચાલે છે અને કોઈ ડિપ્લોયમેન્ટ રહસ્યો નથી.
• A પેકેજ જોબ જે હસ્તાક્ષરિત કલાકૃતિઓનું ઉત્પાદન કરે છે પણ હજુ પણ ઉત્પાદન સાથે વાત કરતું નથી.
• A કાર્ય જમાવવું જે અન્ય પર આધાર રાખે છે અને પર્યાવરણીય રહસ્યો સુધી પહોંચવા અને વાદળની ભૂમિકાઓ ધારણ કરવાની મંજૂરી ધરાવતો એકમાત્ર વિકલ્પ છે.

GitHub-હોસ્ટેડ રનર્સ પર, વર્કફ્લોમાં દરેક જોબ નવા VM માં ચાલે છે., જે તમને નોકરીઓ વચ્ચે એકલતાનો એક અંશ આપે છે. તે કઠણ સેન્ડબોક્સની સમકક્ષ નથી, અને ત્યાં જાણીતા ક્રોસ-જોબ વેક્ટર્સ (જેમ કે શેર કરેલ શાખા કેશ) છે, પરંતુ નોકરીઓનું વિભાજન હજુ પણ હુમલાખોરોને વધુ સખત મહેનત કરવા દબાણ કરે છે અને અસંબંધિત પગલાંઓમાં રહસ્યોના આકસ્મિક લીકેજને ઘટાડે છે.

સંવેદનશીલ પગલાંઓને સુરક્ષા સાથે જોડવા માટે પર્યાવરણનો ઉપયોગ કરો. ડિપ્લોયમેન્ટ જોબ જાહેર કરી શકે છે:

environment: production

અને production પર્યાવરણને પછી ફક્ત સુરક્ષિત શાખામાંથી જમાવટ સ્વીકારવા માટે ગોઠવી શકાય છે, કદાચ ફરજિયાત મેન્યુઅલ મંજૂરીઓ સાથે. આને કડક શાખા સુરક્ષા નિયમો (જરૂરી સમીક્ષાઓ, કોઈ ઝડપી-આગળના દબાણો, જૂની મંજૂરી બરતરફી) સાથે જોડવાથી તમે ઉત્પાદન ફેરફારો માટે ચાર-આંખોના સિદ્ધાંતની નજીક પહોંચી શકો છો.

છેલ્લે, કલાકૃતિઓ, કેશ અને લોગથી સાવચેત રહો.. તે નોકરીઓ અને વર્કફ્લો વચ્ચે ડેટા શેર કરવાની અનુકૂળ રીતો છે, પરંતુ:

• રહસ્યોને કેશમાં ભેગા ન કરો, ખાસ કરીને જાણીતા ન હોય તેવા સ્થળો જેમ કે ~/.docker/config.json જેમાં સાદા ડોકર ઓળખપત્રો હોઈ શકે છે.
• રહસ્યો લોગ કરવાનું અથવા સમગ્ર સંદર્ભોને લોગમાં ડમ્પ કરવાનું ટાળો, કારણ કે આ માસ્કિંગને હરાવી શકે છે અથવા ડેરિવેટેડ મૂલ્યો જાહેર કરી શકે છે જે GitHub ને સંપાદિત કરવાનું ખબર નથી.
• યાદ રાખો કે રેપો વાંચવાની ઍક્સેસ ધરાવનાર કોઈપણ વ્યક્તિ સામાન્ય રીતે આર્ટિફેક્ટ્સ ડાઉનલોડ કરી શકે છે અને લોગ બ્રાઉઝ કરી શકે છે., જો તમે બહારના સહયોગીઓને ઍક્સેસ આપો તો તેનો સમાવેશ થાય છે.

OIDC અને અલ્પજીવી ક્લાઉડ ઓળખપત્રો

તમે કરી શકો તે સૌથી પ્રભાવશાળી ફેરફારોમાંનો એક એ છે કે લાંબા ગાળાના ક્લાઉડ પ્રદાતા ઓળખપત્રોને GitHub રહસ્યો તરીકે સંગ્રહિત કરવાનું સંપૂર્ણપણે બંધ કરો.. તેના બદલે, ચોક્કસ વર્કફ્લો ઓળખ સાથે જોડાયેલા ટૂંકા ગાળાના, સારી રીતે અવકાશિત ટોકન્સ મેળવવા માટે OpenID કનેક્ટ (OIDC) નો ઉપયોગ કરો.

ઉચ્ચ-સ્તરીય પ્રવાહ સરળ છે:

• તમારા ક્લાઉડ પ્રદાતા (AWS, Azure, GCP, વગેરે) ને GitHub ના OIDC પ્રદાતા પર વિશ્વાસ કરવા માટે ગોઠવેલ છે.
• તમે એક ઓળખ નીતિ વ્યાખ્યાયિત કરો છો જે કહે છે કે "ફક્ત આ સંસ્થા/રેપો/શાખા અથવા પર્યાવરણમાંથી ટોકન્સ સ્વીકારો".
• કોઈ કાર્ય દરમિયાન, GitHub OIDC ટોકનની વિનંતી કરી શકે છે અને તમારું કાર્યપ્રવાહ ક્લાઉડ-વિશિષ્ટ ક્રિયાનો ઉપયોગ કરે છે (ઉદાહરણ તરીકે aws-actions/configure-aws-credentials) તેને ટૂંકા ગાળાના રોલ અથવા સર્વિસ એકાઉન્ટ ટોકન માટે બદલવા માટે.

વિશ્વાસની સ્થિતિ એવી છે જ્યાં તમે ખૂબ જ બારીકાઈથી મેળવી શકો છો. AWS માટે, એક લાક્ષણિક નીતિમાં શામેલ હોઈ શકે છે:

"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:Org/Repo:ref:refs/heads/main"
}

તે ખાતરી કરે છે કે ફક્ત ચોક્કસ રેપો અને શાખામાંથી વર્કફ્લો જ ભૂમિકા ભજવી શકે છે. જો તમે વધુ કડક અવકાશ ઇચ્છતા હો, તો તમે ભૂમિકાને શાખાને બદલે ચોક્કસ વાતાવરણ સાથે જોડી શકો છો અને પછી તે વાતાવરણને ફક્ત ડિપ્લોય જોબ માટે જ જરૂરી બનાવી શકો છો. નોન-ડિપ્લોય જોબમાં સમાધાન કરાયેલ તૃતીય-પક્ષ કાર્યવાહીમાં OIDC કૉલ્સ ફક્ત નિષ્ફળ જશે.

OIDC નો ઉપયોગ કરવાથી ક્લાઉડમાં ઓછામાં ઓછા વિશેષાધિકાર ભૂમિકા નીતિઓની જરૂરિયાત દૂર થતી નથી., પરંતુ તે GitHub Secrets માં બેઠેલી સ્ટેટિક એક્સેસ કીને દૂર કરે છે, જ્યાં તે GitHub ની બહારથી ચોરી થઈ શકે છે અને અનિશ્ચિત સમય માટે ફરીથી ઉપયોગમાં લઈ શકાય છે.

શાખા સુરક્ષા, નિયમો અને પર્યાવરણ સાથે મળીને કામ કરે છે

GitHub Actions માં ઘણા ડરામણા હુમલાના રસ્તાઓ "હુમલાખોર સુરક્ષિત શાખામાં દૂષિત ફેરફારો દાખલ કરે છે" સુધી ઉકળે છે.. શાખા સુરક્ષા અને નિયમો ત્યાં તમારા મુખ્ય સંરક્ષણ છે.

જેવી શાખાઓ પર main or production, તમે સામાન્ય રીતે ઓછામાં ઓછું ઇચ્છો છો:

• મર્જ કરતા પહેલા પુલ વિનંતીની જરૂર છે - સીધા દબાણને મંજૂરી આપશો નહીં.
• ઓછામાં ઓછી એક (ઘણીવાર વધુ) મંજૂરી આપતી સમીક્ષાની જરૂર છે છેલ્લા ધક્કા મારનાર સિવાય બીજા કોઈ પાસેથી.
• જ્યારે નવી કમિટ ઉમેરવામાં આવે ત્યારે જૂની મંજૂરીઓ કાઢી નાખો - જેથી હુમલાખોરો સમીક્ષા પછી કોડમાં ઘૂસી ન શકે.
• તાજેતરના સમીક્ષાપાત્ર પુશની મંજૂરી જરૂરી છે - હુમલાખોરને બીજાના પીઆરને હાઇજેક કરવાથી, ખોટા કોડને આગળ ધપાવવાથી અને સ્વ-મંજૂરી આપતા અટકાવે છે.

પછી તમે આ સુરક્ષાઓને પર્યાવરણ સાથે જોડી શકો છો. ઉદાહરણ તરીકે, એ production પર્યાવરણ ફક્ત માંથી જમાવટ સ્વીકારી શકે છે main શાખા, અને કદાચ સમીક્ષકોના નાના સમૂહ પાસેથી મેન્યુઅલ મંજૂરીની પણ જરૂર પડે છે ("સ્વ-સમીક્ષા અટકાવો" સક્ષમ સાથે). આ રીતે, એકલ ચેડા કરાયેલ યોગદાનકર્તા ખાતું કોઈ બીજાની સ્પષ્ટ સંડોવણી વિના ઉત્પાદનમાં મનસ્વી કોડ મોકલી શકતું નથી.

પર્યાવરણીય નિયમોથી સાવચેત રહો જે જમાવટ પર આધાર રાખે છે. (ઉદાહરણ તરીકે, "ટેગ અપડેટ્સને મંજૂરી આપતા પહેલા ડિપ્લોયમેન્ટને સફળ થવાની જરૂર છે"). જો ખરાબ રીતે રચાયેલ હોય, તો તમે ગોળાકાર નિર્ભરતા અથવા સ્યુડો-નિયંત્રણો બનાવી શકો છો જેને સહયોગી વર્કફ્લોને સંપાદિત કરીને બાયપાસ કરી શકે છે. સૌથી સલામત પેટર્ન હજુ પણ છે: મજબૂત શાખા સુરક્ષા → ચુસ્ત રીતે સ્કોપ્ડ વાતાવરણ → તે વાતાવરણનો સ્પષ્ટ ઉપયોગ ફક્ત ન્યૂનતમ કાર્યોમાં જ જેને ખરેખર તેમની જરૂર હોય.

દોડવીરોનું સંચાલન: GitHub-હોસ્ટેડ વિરુદ્ધ સ્વ-હોસ્ટેડ

દોડવીરો એ મશીનો છે જે ખરેખર તમારા કાર્યપ્રવાહને ચલાવે છે.. GitHub-હોસ્ટેડ રનર્સ એ GitHub દ્વારા સંચાલિત ક્ષણિક VM છે; સ્વ-હોસ્ટેડ રનર્સ એ મશીનો અથવા કન્ટેનર છે જે તમે પ્રદાન કરો છો અને નિયંત્રિત કરો છો.

GitHub-હોસ્ટેડ રનર્સ સામાન્ય રીતે ડિફોલ્ટ રૂપે વધુ સુરક્ષિત હોય છે:

• તે ક્ષણિક છે અને દરેક કાર્ય માટે ફરીથી સેટ થાય છે., તેથી રન વચ્ચે કોઈ સતત સમાધાન નથી.
• GitHub પ્રમાણભૂત છબીઓ (ઉબુન્ટુ, વિન્ડોઝ, macOS) માટે SBOM પ્રકાશિત કરે છે., જે તમને પહેલાથી ઇન્સ્ટોલ કરેલા સોફ્ટવેરનું નબળાઈઓ માટે વિશ્લેષણ કરવાની મંજૂરી આપે છે.
• અમુક દૂષિત હોસ્ટ્સને બોક્સની બહાર બ્લોક કરવામાં આવ્યા છે. (ઉદાહરણ તરીકે જાણીતા ક્રિપ્ટોમાઇનિંગ પુલ) દ્વારા /etc/hosts રૂપરેખાંકન.

સ્વ-આયોજિત દોડવીરો શક્તિશાળી હોય છે પણ ખતરનાક હોય છે જો તમે તેમની સાથે પ્રોડક્શન સર્વર તરીકે વ્યવહાર ન કરો તો:

• જ્યાં સુધી તમે તેને જાતે ન બનાવો ત્યાં સુધી તે સામાન્ય રીતે ક્ષણિક નથી હોતા., તેથી કોઈપણ દૂષિત વર્કફ્લો સતતતા, બાજુની હિલચાલ અથવા ડેટા ચોરીનો પ્રયાસ કરી શકે છે.
• તેમની પાસે ઘણીવાર વ્યાપક નેટવર્ક ઍક્સેસ અને સ્થાનિક રહસ્યો હોય છે (SSH કી, ક્લાઉડ CLI, મેટાડેટા સેવાઓ), જે કોઈપણ સમાધાનનો દાવ વધારે છે.
• જાહેર ભંડારોએ લગભગ ક્યારેય સ્વ-હોસ્ટેડ રનર્સનો ઉપયોગ ન કરવો જોઈએ., કારણ કે કોઈપણ વ્યક્તિ પુલ રિક્વેસ્ટ ખોલી શકે છે જે તમારા ઇન્ફ્રાસ્ટ્રક્ચર પર કોડ એક્ઝિક્યુટ કરે છે.

જો તમારે સ્વ-આયોજિત દોડવીરો વાપરવા જ પડે, તો તેમને વિશ્વાસની સીમાઓ દ્વારા કોતરો.દોડવીર જૂથો અને પ્રતિબંધોનો ઉપયોગ કરો જેથી:

• જાહેર અને ખાનગી પ્રોજેક્ટ્સ ક્યારેય એક જ રનર પૂલ શેર કરતા નથી.
• ઉચ્ચ સંવેદનશીલતા રેપો (ઉદાહરણ તરીકે ઉત્પાદન ઇન્ફ્રા) પાસે પોતાના કડક રીતે નિયંત્રિત રનર્સ હોય છે.
• ફક્ત ચોક્કસ ભંડાર અથવા સંસ્થાઓ જ આપેલ જૂથને નોકરીઓ મોકલી શકે છે.

REST API દ્વારા પૂરા પાડવામાં આવેલા જસ્ટ-ઇન-ટાઇમ (JIT) રનર્સ સાથે તમે જોખમ વધુ ઘટાડી શકો છો.. આ દોડવીરો ગતિશીલ રીતે નોંધણી કરાવે છે, વધુમાં વધુ એક કાર્ય ચલાવે છે, અને પછી આપમેળે દૂર થઈ જાય છે. તમારે હજુ પણ ખાતરી કરવાની જરૂર છે કે અંતર્ગત યજમાન સાફ અથવા નાશ પામે છે, પરંતુ તે તે વિંડોને સાંકડી કરે છે જેમાં સમાધાન થયેલ કાર્ય પછીના કાર્યને અસર કરી શકે છે.

સ્વ-આયોજિત દોડવીરોને અન્ય કોઈપણ ઉત્પાદન પ્રણાલીની જેમ વર્તે છે: પ્રક્રિયા પ્રવૃત્તિનું નિરીક્ષણ કરવું, આઉટબાઉન્ડ નેટવર્ક પાથને લોક ડાઉન કરવું, OS અને ટૂલ્સને પેચ કરેલા રાખવા, અને ધારો કે કોઈપણ વપરાશકર્તા પાસે વર્કફ્લો ટ્રિગર કરવાની પરવાનગી હોય તો તે મશીન પર કોડ એક્ઝેક્યુશન અસરકારક રીતે થાય છે.

બિલ્ટ-ઇન સુરક્ષા સુવિધાઓ: કોડ સ્કેનિંગ, સ્કોરકાર્ડ્સ અને ડિપેન્ડાબોટ

GitHub ખાસ કરીને વર્કફ્લો અને નિર્ભરતાના જોખમને સપાટી પર લાવવાના હેતુથી ઘણી બધી પ્રથમ-વર્ગની સુવિધાઓ મોકલે છે., અને તે નાના સેટઅપ ખર્ચને યોગ્ય છે.

કોડ સ્કેનિંગ (ઉદાહરણ તરીકે CodeQL સાથે) હવે GitHub Actions વર્કફ્લોનું જાતે વિશ્લેષણ કરી શકે છે., ફક્ત તમારા એપ્લિકેશન સ્ત્રોત જ નહીં. "અતિશય રહસ્યો એક્સપોઝર" જેવા નિયમો એવા પેટર્ન શોધી શકે છે જ્યાં GitHub નક્કી કરી શકતું નથી કે કયા રહસ્યો જરૂરી છે (ઉદાહરણ તરીકે ગતિશીલ secrets[myKey] મેટ્રિક્સ બિલ્ડ્સમાં ઉપયોગ), જે તેને જોબ મેમરીમાં જરૂર કરતાં વધુ રહસ્યો લોડ કરવા તરફ દોરી જાય છે.

OpenSSF સ્કોરકાર્ડ્સ અને સ્કોરકાર્ડ્સ ક્રિયા તમારા ડિપેન્ડન્સીના સુરક્ષા પોશ્ચરને ગ્રેડ કરીને બીજું સ્તર ઉમેરે છે.. બજારમાં થતી ક્રિયાઓ માટે, સ્કોરકાર્ડ્સ અસુરક્ષિત સપ્લાય ચેઇન પ્રથાઓને ચિહ્નિત કરી શકે છે જેમ કે:

• ડિપેન્ડન્સીઝ પિન કરી રહ્યા નથી.
• ખૂટતી શાખા સુરક્ષા અથવા કોડ સમીક્ષા આવશ્યકતાઓ.
• સુરક્ષા નીતિ અથવા નબળાઈ પ્રતિભાવ પ્રક્રિયાઓનો અભાવ.

ડિપેન્ડબોટ અહીં બે ભૂમિકા ભજવે છે.:

• ડિપેન્ડબોટ ચેતવણીઓ GitHub એડવાઇઝરી ડેટાબેઝના આધારે, જ્યારે તમારી ક્રિયાઓ અથવા વર્કફ્લો પર નિર્ભરતા જાણીતી નબળાઈ ધરાવે છે ત્યારે તમને ચેતવણી આપે છે.
• ડિપેન્ડબોટ વર્ઝન અને સુરક્ષા અપડેટ્સ એક્શન વર્ઝનને બમ્પ કરવા અને નબળા રિલીઝને પેચ કરવા માટે આપમેળે PR ખોલી શકે છે.

વર્કફ્લો માટે ડિપેન્ડન્સી ગ્રાફ એ બીજી ઓછી કિંમતવાળી સુવિધા છે. GitHub તમારી વર્કફ્લો ફાઇલોને મેનિફેસ્ટ તરીકે ગણે છે અને તમને બતાવી શકે છે:

• તમે કઈ ક્રિયાઓ અને ફરીથી વાપરી શકાય તેવા વર્કફ્લો પર આધાર રાખો છો.
• કયા ખાતાઓ અથવા સંસ્થાઓ તેમની માલિકી ધરાવે છે.
• તમે કયા સંસ્કરણો અથવા SHAs પર પિન કર્યા છે.

આનાથી "આપણે આ સમાધાનકારી કાર્યવાહીનો ઉપયોગ ક્યાં કરી રહ્યા છીએ?" જેવા પ્રશ્નોના જવાબ આપવાનું સરળ બને છે. જ્યારે નવી સલાહો ઘટે છે, અને બલ્ક રિમેડિયેશનની યોજના બનાવવી.

દેખરેખ, ઓડિટિંગ અને શાસન

સુરક્ષા ફક્ત રૂપરેખાંકન પર જ સમાપ્ત થતી નથી; સમય જતાં શું થઈ રહ્યું છે તેની પણ તમારે દૃશ્યતા હોવી જરૂરી છે.. GitHub વપરાશકર્તા અને સંગઠન બંને સ્તરે ઓડિટ લોગ અને સુરક્ષા લોગ પૂરા પાડે છે.

ક્રિયાઓના દૃષ્ટિકોણથી, ટ્રેક કરવા યોગ્ય ઘણી બાબતો છે:

• રહસ્યો સંબંધિત ઘટનાઓ, જેમ કે org.update_actions_secret અથવા ભંડાર ગુપ્ત ફેરફારો. આ સંવેદનશીલ ઓળખપત્રોની રચના, અપડેટ અથવા કાઢી નાખવાનો સંકેત આપે છે.
• વર્કફ્લો અને નિયમ સમૂહમાં ફેરફાર: કોણે સુરક્ષા નિયમોમાં ફેરફાર કર્યા, કોણે ડિપ્લોયમેન્ટ વર્કફ્લોમાં ફેરફાર કર્યા, કોણે પર્યાવરણ સુરક્ષામાં ફેરફાર કર્યા.
• નવી અથવા સંશોધિત માર્કેટપ્લેસ ક્રિયાઓ અને GitHub એપ્લિકેશનો org માં ઇન્સ્ટોલ કરેલ, ખાસ કરીને જેને બ્રોડ રિપોઝીટરી અથવા org સ્કોપ્સ આપવામાં આવ્યા છે.

તમે OpenSSF માંથી Allstar જેવી નીતિ-અમલીકરણ એપ્લિકેશનો સાથે GitHub ના પોતાના નિયંત્રણોને પૂરક બનાવી શકો છો., જે સતત તપાસ કરે છે કે રિપોઝીટરીઝ તમારી સંસ્થાના સુરક્ષા આધારરેખા (શાખા સુરક્ષા, કોડ સ્કેનિંગ સક્ષમ, જરૂરી સમીક્ષાઓ, વગેરે) નું પાલન કરે છે.

"ચાલી રહેલા વર્કફ્લો" બાજુએ, એવા દાખલાઓ પર નજર રાખો જે દુરુપયોગ સૂચવી શકે છે: જોબ રનટાઇમમાં અસામાન્ય વધારો, દોડવીરો તરફથી અણધાર્યો આઉટબાઉન્ડ ટ્રાફિક, અથવા રહસ્યો અથવા OIDC ટોકન્સને હેન્ડલ કરતા પગલાંઓમાં વારંવાર નિષ્ફળ જતી નોકરીઓ. આ હંમેશા દૂષિત નથી, પરંતુ તે તપાસ શરૂ કરવા માટે સારી જગ્યાઓ છે.

આ બધાને એકસાથે મૂકવાનો અર્થ એ છે કે તમારા મુખ્ય ઉત્પાદન સપાટીના ભાગ રૂપે GitHub ક્રિયાઓનો વિચાર કરવો, ફક્ત "ગ્લુ સ્ક્રિપ્ટ્સ" જ નહીં. કાળજીપૂર્વક સ્કોપ કરેલા રહસ્યો અને ટોકન્સ, કડક શાખા અને પર્યાવરણીય સુરક્ષા, તૃતીય-પક્ષ ક્રિયાઓનો રૂઢિચુસ્ત ઉપયોગ, કઠણ દોડવીરો અને CodeQL, સ્કોરકાર્ડ્સ અને ડિપેન્ડાબોટ જેવા સાધનો સાથે સતત દેખરેખ સાથે, તમે તમારા સંગઠનને CI/CD અને સપ્લાય ચેઇન હુમલાઓના વધતા વર્ગ સામે લડવાની તક આપો છો જે સ્પષ્ટપણે GitHub વર્કફ્લોને લક્ષ્ય બનાવે છે.