ਜ਼ਾਇਗੇਨੀ ਲੋਗੋ ਚਿੱਟਾ
ਮੁਫ਼ਤ ਸ਼ੁਰੂ ਕਰੋ
ਇੱਕ ਡੈਮੋ ਬੁੱਕ ਕਰੋ

ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ? CI/CD pipelines?

ਵਿਸ਼ਾ - ਸੂਚੀ

ਪੜ੍ਹਨਯੋਗ ਪੋਸਟਾਂ

ਦਿਲਚਸਪੀ ਵਾਲੀਆਂ ਨਵੀਨਤਮ ਪੋਸਟਾਂ

ਨਿਰੰਤਰ ਏਕੀਕਰਨ ਅਤੇ ਨਿਰੰਤਰ ਡਿਲੀਵਰੀ (CI/CD) pipelines ਕਿਸੇ ਵੀ ਸਾਫਟਵੇਅਰ ਸੰਗਠਨ ਦੀ ਨੀਂਹ ਹਨ ਜੋ "ਆਧੁਨਿਕ" ਤਰੀਕੇ ਨਾਲ ਸਾਫਟਵੇਅਰ ਬਣਾਉਂਦਾ ਹੈ। ਆਟੋਮੇਸ਼ਨ ਬਹੁਤ ਸ਼ਕਤੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਪਰ ਜ਼ਿਆਦਾਤਰ ਡਿਵੈਲਪਰ ਇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਜ਼ਿੰਮੇਵਾਰੀ ਤੋਂ ਖੁੰਝ ਜਾਂਦੇ ਹਨ।

ਡਿਵੈਲਪਰ: ਹਾਂ, ਅਸੀਂ ਲੈਂਦੇ ਹਾਂ CI/CD ਸੁਰੱਖਿਆ ਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਅਤੇ ਕੋਡ ਮੇਨਟੇਨਰਾਂ 'ਤੇ ਮਜ਼ਬੂਤ ​​ਨਿਯੰਤਰਣ ਰੱਖੋ, ਸਮੀਖਿਆ ਕਰੋ commitਰਲੇਵੇਂ ਤੋਂ ਪਹਿਲਾਂ; ਨੌਕਰੀਆਂ ਅਤੇ pipelines ਦੀ ਦੇਖਭਾਲ ਸੀਨੀਅਰ ਸਟਾਫ ਦੁਆਰਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਉਹ ਇਸ ਗੱਲ ਦਾ ਧਿਆਨ ਰੱਖਦੇ ਹਨ ਕਿ ਭੇਦ ਲੀਕ ਨਾ ਹੋਣ pipelines. ਅਤੇ ਇਹ ਔਜ਼ਾਰ ਉਹਨਾਂ ਕਰਮਚਾਰੀਆਂ ਦੁਆਰਾ ਲਗਾਇਆ ਗਿਆ ਸੀ ਜੋ ਇਸ ਚੀਜ਼ ਨੂੰ ਜਾਣਦੇ ਹਨ। ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ?

ਪਿਆਰੇ ਡਿਵੈਲਪਰ, CI/CD ਸਿਸਟਮ ਗੁੰਝਲਦਾਰ ਹਨ। ਇਸਦੀ ਚੌੜੀ ਹਮਲੇ ਦੀ ਸਤ੍ਹਾ ਨੇ ਘਾਤਕ ਅਦਾਕਾਰਾਂ ਨੂੰ ਆਕਰਸ਼ਿਤ ਕੀਤਾ। ਸਾਵਧਾਨ ਰਹਿਣਾ ਬਿਹਤਰ ਹੈ ਅਤੇ ਕਦੇ ਵੀ ਜ਼ਿਆਦਾ ਆਤਮਵਿਸ਼ਵਾਸੀ ਨਾ ਬਣੋ।

ਡਿਫਾਲਟ ਕੌਂਫਿਗਰੇਸ਼ਨ ਕਈ ਵਾਰ ਰੱਖੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਹੈਕਰਾਂ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਦੋਸਤ ਬਣ ਜਾਂਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਗੰਭੀਰ ਖਾਮੀਆਂ ਮੌਜੂਦ ਹੋ ਸਕਦੀਆਂ ਹਨ CI/CD pipeline ਸਰੋਤ, ਸਿਸਟਮ ਦੀ ਸੰਰਚਨਾ ਵਿੱਚ, ਜਾਂ ਪ੍ਰਕਿਰਿਆ ਅਤੇ ਸੰਦਰਭ ਦੇ ਆਲੇ-ਦੁਆਲੇ pipeline ਅਤੇ ਇਹ ਕਿਵੇਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ।

ਇਸ ਪੋਸਟ ਵਿੱਚ ਅਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਬੁਰੇ ਅਦਾਕਾਰਾਂ ਦੀ ਜੁੱਤੀ ਵਿੱਚ ਪਾਵਾਂਗੇ। ਕਲਪਨਾ ਕਰੋ ਕਿ ਅਸੀਂ ਇਹਨਾਂ ਦੇ ਵਿਚਾਰਾਂ ਨੂੰ ਪੜ੍ਹ ਰਹੇ ਸੀ ਐਮ3ਐਮ3ਐਨ70 (ਯਾਦਗਾਰੀ ਮੋਰੀ?) ਅਤੇ ਦਲਦਲ ਦਾ ਗੁੱਸਾ ਕਿਤੇ ਡਾਰਕ ਵੈੱਬ ਵਿੱਚ, ਸ਼ਾਇਦ ਕਿਸੇ ਗੈਰ-ਪੱਛਮੀ ਭਾਸ਼ਾ ਵਿੱਚ, ਪਰ ਇਹ ਕਦੇ ਨਾ ਭੁੱਲੋ ਕਿ ਬੁਰਾਈ ਦੁਨੀਆ ਭਰ ਵਿੱਚ ਫੈਲੀ ਹੋਈ ਹੈ।

 

ਪੁਰਾਣੇ ਸਮੇਂ ਵਿੱਚ ਇਹ ਬਹੁਤ ਆਸਾਨ ਸੀ...

ਐਮ3ਐਮ3ਐਨ70: ਪੁਰਾਣੇ ਸਮੇਂ ਵਿੱਚ ਸਾਡਾ ਕਾਰੋਬਾਰ ਬਹੁਤ ਆਸਾਨ ਸੀ... ਜ਼ੀਰੋ-ਡੇਅ ਘੱਟ-ਲਟਕਦੇ ਫਲ ਸਨ, ਐਪਸ ਖੁੱਲ੍ਹੇ ਸਨ ਜਿਨ੍ਹਾਂ ਦਾ ਸ਼ੋਸ਼ਣ ਕਰਨਾ ਆਸਾਨ ਸੀ, ਅਤੇ ਅਸੀਂ ਇੱਕ ਪਲ ਵਿੱਚ ਪਾਸੇ ਵੱਲ ਵਧ ਸਕਦੇ ਸੀ।

ਦਲਦਲ ਦਾ ਗੁੱਸਾ: Fu#@Hell ! ਕੁਝ ਲੋਕ ਅਜੇ ਸੋਚ ਸਮਝ ਕੇ ਕੰਮ ਕਰ ਰਹੇ ਸਨ, ਪਰ ਹਾਲਾਤ ਬਦਲ ਗਏ। ਵੱਡੇ ਲੋਕਾਂ ਨੇ ਉਸ AppSec ਗੰਦਗੀ 'ਤੇ ਬਹੁਤ ਸਾਰਾ ਜ਼ੋਰ ਲਗਾਇਆ।

ਐਮ3ਐਮ3ਐਨ70: ਹਾਂ। ਪਰ ਨਵੇਂ ਮੂਰਖ ਵਿਕਾਸਕਰਤਾ ਹਨ। ਸਾਡੇ ਲਈ, ਇਹਨਾਂ ਲੋਕਾਂ ਦੁਆਰਾ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਔਜ਼ਾਰਾਂ ਲਈ ਜਾਣਾ ਸੌਖਾ ਹੋ ਗਿਆ ਹੈ। CI, ਖਾਸ ਕਰਕੇ, ਇੱਕ ਸੋਨੇ ਦੀ ਖਾਨ ਹੈ! ਕਲਾਉਡ ਐਕਸੈਸ ਟੋਕਨ, SCM ਪ੍ਰਮਾਣ ਪੱਤਰ, ਉਤਪਾਦਨ ਡੇਟਾਬੇਸ ਪਾਸਵਰਡ, SSH ਪ੍ਰਾਈਵੇਟ ਕੁੰਜੀਆਂ, ਹੋਰ CI ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਪ੍ਰਮਾਣ ਪੱਤਰ... ਬੋਰਿੰਗ ਵਿਕਾਸ ਚੀਜ਼ਾਂ ਤੋਂ ਅਸਲ ਮੀਟ ਵੱਲ ਜਾਣਾ ਕਾਫ਼ੀ ਮਾਮੂਲੀ ਸੀ।

ਇੱਕ ਨਾਲ ਸਾਫਟਵੇਅਰ ਬਣਾਉਣ, ਟੈਸਟ ਕਰਨ ਅਤੇ ਤੈਨਾਤ ਕਰਨ ਲਈ ਆਟੋਮੇਸ਼ਨ CI/CD ਟੂਲ ਨੂੰ ਅਕਸਰ ਕਦਮਾਂ ਵਿੱਚ ਕਮਾਂਡਾਂ ਤੱਕ ਰਾਜ਼ ਪਹੁੰਚਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਅਤੇ ਅਕਸਰ ਉਹ ਲੀਕ ਹੋ ਜਾਂਦੇ ਹਨ, ਜਿਸਦੇ ਬਦਨਾਮ ਨਤੀਜੇ ਨਿਕਲਦੇ ਹਨ।

Pipelineਲੋਕਾਂ ਨੂੰ ਅਜਿਹੇ ਰਾਜ਼ ਚਾਹੀਦੇ ਹਨ ਜੋ ਕਈ ਵਾਰ ਲੀਕ ਹੋ ਜਾਂਦੇ ਹਨ

M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.

ਸ਼ਾਇਦ ਚੰਗੇ ਪੁਰਾਣੇ ਸਮੇਂ ਨੂੰ ਗਿੱਟ ਇਤਿਹਾਸ ਵਿੱਚ ਲੱਭਣਾ ਸੀ ਇੱਕ .env ਫਾਈਲ (ਡਿਵੈਲਪਰ ਇਸਨੂੰ ਇਸ ਵਿੱਚ ਜੋੜਨਾ ਭੁੱਲ ਗਿਆ ਸੀ) .gitignore):

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUtn...
AWS_REGION=us-east-1
APP_FOLDER=...
S3BUCKET=...

ਜਿਸਨੂੰ GitHub ਵਰਕਫਲੋ ਵਿੱਚ ਵਰਤਿਆ ਗਿਆ ਸੀ .github/deploy.yaml ਜਿਸ ਵਿੱਚ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਸੀ:

jobs:
  build:
    name: Automated build and deployment into AWS
    runs-on: 	ubuntu-22.04
    steps:
      # Load environment from .env file
      - id: dotenv
        uses: falti/dotenv-action@v1.0.2
        
      - name: Configure AWS Credentials
        uses:
        with:
          args: --acl public-read --follow-symlinks --delete 
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $
      
      # ... build steps skipped ...
      
      -  name: Upload compiled code for deployment
         working-directory: $/packaged_app
         run: aws s3 cp my-app.zip s3://$ 
         
      - name: Deploy the app
        run: aws deploy create-deployment ...

M3M3N70: ਵਾਹ! ਉਹ aws ਕੁੰਜੀਆਂ ਕੰਮ ਕਰ ਰਹੀਆਂ ਸਨ! ਅਸੀਂ ਪਹਿਲਾਂ ਐਪ ਵਿੱਚ ਇੱਕ ਇਨੋਕੁਓਸ ਬਦਲਾਅ ਦੀ ਜਾਂਚ ਕੀਤੀ, ਫਿਰ ਸਟਿੰਗ ਸ਼ਾਮਲ ਕੀਤੀ ਕਿਉਂਕਿ ਉਹ ਲੋਕ ਅਣਜਾਣ ਜਾਪਦੇ ਸਨ। ਬਿੰਗੋ! ਕਿੰਨੀ ਮੁਹਿੰਮ ਹੈ...

ਇਸ ਬੁਰੇ ਐਕਟਰ ਨੇ ਸਿਰਫ਼ AWS ਕੁੰਜੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਮਾਲਵੇਅਰ ਨਾਲ ਇੱਕ ਸੋਧੀ ਹੋਈ ਐਪਲੀਕੇਸ਼ਨ ਅਪਲੋਡ ਕੀਤੀ ਅਤੇ ਫਿਰ ਅਜਿਹੇ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਨਾਲ ਡਿਪਲੋਏ ਕਮਾਂਡ ਚਲਾਈ। ਲੀਕ ਹੋਏ ਰਾਜ਼, ਇਸ ਵਿੱਚ ਮੌਜੂਦ ਜਾਣਕਾਰੀ ਦੇ ਨਾਲ pipeline. "ਕਿੰਨੀ ਵੱਡੀ ਮੁਹਿੰਮ!" ਸ਼ਾਇਦ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਮੀਮੈਂਟੋ ਨੇ ਗਰੀਬ ਪੀੜਤ 'ਤੇ ਕਹਿਰ ਢਾਹ ਦਿੱਤਾ।

ਮੀਮੈਂਟੋ ਸਾਨੂੰ ਇੱਥੇ ਜੋ ਦੱਸਦਾ ਹੈ ਉਹ ਇਹ ਹੈ ਕਿ ਇੱਕ ਵਾਰ ਗੁਪਤ ਲੀਕ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਜਿਵੇਂ ਕਿ ਉਦਾਹਰਣ ਵਿੱਚ AWS ਐਕਸੈਸ ਕੁੰਜੀਆਂ, ਤੁਹਾਨੂੰ ਗੁਪਤ ਨੂੰ ਰੱਦ ਕਰਨਾ ਪਵੇਗਾ (ਉਪਰੋਕਤ ਕੁੰਜੀਆਂ ਨੂੰ ਘੁੰਮਾਓ) ਤੁਰੰਤ. ਹਮੇਸ਼ਾ ਇੱਕ ਹੁੰਦਾ ਹੈ ਐਕਸਪੋਜ਼ਰ ਵਿੰਡੋ ਲੀਕ ਹੋਣ ਦੇ ਵਿਚਕਾਰ commit ਅਤੇ ਗੁਪਤ ਅਵੈਧਤਾ; ਗਿੱਟ ਇਤਿਹਾਸ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ ਔਖਾ ਹੈ (ਸਭ ਤੋਂ ਸਖ਼ਤ ਤਾਨਾਸ਼ਾਹੀ ਰਾਜ ਨੇ ਵੀ ਇਤਿਹਾਸ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਕੋਈ ਫਾਇਦਾ ਨਹੀਂ ਹੋਇਆ) ਅਤੇ ਸ਼ਾਇਦ ਬੇਅਸਰ (ਸਾਡੇ ਦੋਸਤਾਂ ਨੇ ਗੁਪਤ ਲੀਕ ਨਾਲ ਭੰਡਾਰ ਦੇ ਸਾਹਮਣੇ ਕਲੋਨ ਕੀਤਾ ਹੋਵੇਗਾ) commit). ਕੁੰਜੀਆਂ ਨੂੰ ਤੁਰੰਤ ਘੁੰਮਾਓ, ਅਤੇ ਐਕਸਪੋਜ਼ਰ ਵਿੰਡੋ ਦੌਰਾਨ ਨਿਸ਼ਾਨਾ ਬਣਾਏ ਖਾਤੇ ਲਈ ਗਤੀਵਿਧੀ ਲੌਗ ਪੜ੍ਹਦੇ ਹੋਏ ਪ੍ਰਾਰਥਨਾ ਕਰੋ!

ਸ਼ਾਇਦ ਸੰਗਠਨਾਂ ਨੂੰ ਚਾਹੀਦਾ ਹੈ ਵਿੱਚ ਲੰਬੇ ਸਮੇਂ ਦੇ ਰਾਜ਼ਾਂ ਦੀ ਵਰਤੋਂ 'ਤੇ ਪਾਬੰਦੀ CI/CD pipelines, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਅਸਥਾਈ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਨਾਲ ਬਦਲੋ। ਪਿਛਲੀ ਉਦਾਹਰਣ ਵਿੱਚ GitHub ਕਾਰਵਾਈਆਂ ਵਿੱਚ AWS ਕੁੰਜੀਆਂ ਦੇ ਨਾਲ, ਇੱਕ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸੁਰੱਖਿਅਤ ਹੈ ਓਪਨਆਈਡੀ ਕਨੈਕਟ (OIDC) ਪ੍ਰਦਾਤਾ ਕਾਰਵਾਈਆਂ ਲਈ ਲੋੜੀਂਦੇ ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ।

ਦਲਦਲ ਦਾ ਗੁੱਸਾ: ਤੁਸੀਂ ਬਹੁਤ ਖੁਸ਼ਕਿਸਮਤ ਸੀ! ਪੁਰਾਣੇ ਜ਼ਮਾਨੇ ਵਿੱਚ ਹਾਰਡਕੋਡ ਵਾਲੀਆਂ ਕੁੰਜੀਆਂ ਨਾਲ ਸਕ੍ਰਿਪਟਾਂ ਲੀਕ ਕਰਨਾ ਆਮ ਗੱਲ ਸੀ, ਜਨਤਕ ਤੌਰ 'ਤੇ ਪਹੁੰਚਯੋਗ S3 ਬਕੇਟਾਂ 'ਤੇ ਵੀ। ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਬਕੇਟ ਵਿੱਚ ਵਸਤੂਆਂ ਨੂੰ ਪਾਰ ਕਰਨ ਅਤੇ ਦਿਲਚਸਪ ਚੀਜ਼ਾਂ ਲੱਭਣ ਲਈ ਕੁਝ ਗ੍ਰੈਪਿੰਗ ਕਰਨ ਦੀ ਲੋੜ ਸੀ।

ਕਈ ਵਾਰ ਤੈਨਾਤੀ ਲਈ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਖੇਤਰ (ਇਸ ਉਦਾਹਰਣ ਵਿੱਚ ਇੱਕ AWS S3 ਬਾਲਟੀ) ਬਾਹਰੀ ਲੋਕਾਂ ਤੋਂ ਪੜ੍ਹਨ ਲਈ ਖੁੱਲ੍ਹਾ ਹੁੰਦਾ ਸੀ, ਇੱਕ ਸੰਰਚਨਾ ਨੁਕਸ ਦੇ ਕਾਰਨ (ਜੋ ਕਿ ਅਣਪਛਾਤਾ ਰਹਿ ਗਿਆ)। ਕੀ ਦਲਦਲ ਦਾ ਗੁੱਸਾ ਵਰਤਿਆ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਸੀ:

aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
  aws s3 cp s3://<bucket_name>/FNAME - | \
  grep '<regex_pattern>'"

ਇਹ ਬਾਲਟੀ ਸ਼ਾਇਦ ਇੱਕ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਟੈਂਪਲੇਟ ਵਿੱਚ ਬਣਾਈ ਗਈ ਸੀ ਜਿਸਨੂੰ ਸੁਰੱਖਿਆ ਖਾਮੀਆਂ ਲਈ ਆਪਣੇ ਆਪ ਸਕੈਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਟੂਲ ਡਿਫਾਲਟ ਕੌਂਫਿਗਰੇਸ਼ਨ ਸਾਡੇ ਲਈ ਇੱਕ ਖਿਡੌਣਾ ਸੀ।

ਠੋਸ ਉਦਾਹਰਣਾਂ ਦੇਣ ਲਈ, ਆਓ ਗੱਲ ਕਰੀਏ ਜੇਨਕਿੰਸ, ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ CI ਟੂਲਸ ਵਿੱਚੋਂ ਇੱਕ।

ਦਲਦਲ ਦਾ ਗੁੱਸਾ: ਕੀ ਤੁਹਾਨੂੰ ਯਾਦ ਹੈ ਕਿ ਜੇਨਕਿੰਸ ਵਿੱਚ "ਸੁਰੱਖਿਆ ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ" ਚੈੱਕਬਾਕਸ ਸੀ, ਅਤੇ ਕਿੰਨੀਆਂ ਸੰਸਥਾਵਾਂ ਨੇ ਸਹੂਲਤ ਲਈ ਇਸਨੂੰ ਕਿਰਿਆਸ਼ੀਲ ਨਾ ਕਰਨ ਦੀ ਚੋਣ ਕੀਤੀ? ਅਤੇ ਉਹ "ਕੋਈ ਵੀ ਕੁਝ ਵੀ ਕਰ ਸਕਦਾ ਹੈ।"ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਅਨੁਮਤੀ ਕੰਬੋਜ਼? ਅਤੇ ਉਹ ਪਰੇਸ਼ਾਨ ਕਰਨ ਵਾਲੇ ਜੇਨਕਿੰਸ ਪਲੱਗਇਨ, ਜਿਵੇਂ ਕਿ GitHub OAuth ਪਲੱਗਇਨ? ਜਿਸ ਵਿਅਕਤੀ ਨੇ ਇਸਨੂੰ ਕੌਂਫਿਗਰ ਕੀਤਾ, ਉਸਨੇ "Grant READ permissions to all Authenticated Users" ਅਤੇ "Use GitHub repository permissions" ਦੋਵਾਂ ਨੂੰ ਚੁਣਿਆ, ਜਿਸ ਨਾਲ ਸਾਨੂੰ ਉਹਨਾਂ ਦੇ ਸਾਰੇ ਪ੍ਰੋਜੈਕਟਾਂ ਤੱਕ ਪਹੁੰਚ ਮਿਲੀ।

(ਮੁਆਫ਼ੀ, ਜੇਨਕਿੰਸ, ਤੁਹਾਨੂੰ ਉਦਾਹਰਣ ਵਜੋਂ ਪੇਸ਼ ਕਰਨ ਲਈ 😉)

ਸੁਰੱਖਿਆ ਸਿਧਾਂਤਾਂ ਦੇ ਮਾਹਰ (ਆਦੀ ਵੀ) ਰਹੋ। ਇੱਕ ਹੈ ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਸਿਧਾਂਤ: ਨਿਯੰਤਰਣਾਂ ਨੂੰ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਸੈਟਿੰਗਾਂ 'ਤੇ ਡਿਫੌਲਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਸੁਰੱਖਿਆ ਨੂੰ ਇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ CI/CD ਟੂਲਸ ਅਤੇ pipelineਸ਼ੁਰੂ ਤੋਂ ਹੀ, ਨਾ ਕਿ ਬਾਅਦ ਵਿੱਚ ਸੋਚਿਆ ਗਿਆ। ਪਰ ਉਪਭੋਗਤਾ-ਮਿੱਤਰਤਾ ਅਤੇ ਸਹੂਲਤ ਅਕਸਰ ਸੁਰੱਖਿਆ ਨਾਲ ਟਕਰਾ ਜਾਂਦੀ ਹੈ।

ਜੇਨਕਿਨਸ ਕੇਸ ਲਈ, ਬਿਲਟ-ਇਨ ਪ੍ਰਮਾਣੀਕਰਨ ਬਹੁਤ ਨਾਜ਼ੁਕ ਹੈ: ਜੇਨਕਿਨਜ਼ ਵਿੱਚ ਕਦੇ ਵੀ ਬਿਲਟ-ਇਨ ਪ੍ਰਮਾਣੀਕਰਨ ਵਿਧੀਆਂ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ. ਭੂਮਿਕਾ-ਅਧਾਰਤ ਅਧਿਕਾਰ ਰਣਨੀਤੀ ("RBAC") ਪਲੱਗਇਨ ਦੇ ਨਾਲ, ਇੱਕ ਤੀਜੀ-ਧਿਰ ਵਿਧੀ (SAML, LDAP, Google …) ਦੀ ਚੋਣ ਕਰਨਾ ਬਿਹਤਰ ਹੈ। ਅਤੇ ਇਸ ਨਾਲ ਬਹੁਤ ਸਾਵਧਾਨੀ ਰੱਖੋ admin ਖਾਤਾ

ਧਿਆਨ ਰੱਖੋ ਕਿ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ ਅਤੇ pipeline ਜੇਨਕਿਨਜ਼ ਵਿੱਚ ਫਾਈਲਾਂ ਨੂੰ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ। ਨਾਲ ਵੀ ਇਹੀ ਹੈ ਕੋਡ-ਵਜੋਂ-ਸੰਰਚਨਾ ਪਲੱਗਇਨ ਅਤੇ ਇਸਦੀਆਂ ਕੌਂਫਿਗ ਫਾਈਲਾਂ, ਜੋ ਜੇਨਕਿਨਜ਼ ਕੌਂਫਿਗਰੇਸ਼ਨ ਤੇ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ।

ਸਵੈ-ਹੋਸਟਡ ਤੋਂ ਬਦਲਣਾ CI/CD ਕਲਾਉਡ-ਅਧਾਰਿਤ SaaS ਵਾਲੇ ਸਿਸਟਮ ਸੰਗਠਨ ਨੈੱਟਵਰਕ ਦੇ ਅੰਦਰ ਪਾਸੇ ਦੀ ਗਤੀ ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲੇ ਕੁਝ ਸੰਭਾਵੀ ਜੋਖਮਾਂ ਨੂੰ ਖਤਮ ਕਰਦੇ ਹਨ, ਪਰ ਹੋਰਾਂ ਨੂੰ ਜੋੜਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਮੌਜੂਦਾ ਅੰਦਰੂਨੀ ਪ੍ਰਣਾਲੀਆਂ ਅਤੇ ਬਾਹਰੀ ਪ੍ਰਣਾਲੀਆਂ ਵਿਚਕਾਰ ਬਾਹਰੀ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਣਾ। CI/CD ਟੂਲ.

ਸੰਸਥਾਵਾਂ ਨੂੰ ਮਿਹਨਤ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈcisਸਖ਼ਤ ਕਰਨ ਵਿੱਚ ਢੁਕਵੀਂ ਦੇਖਭਾਲ CI/CD ਸਿਸਟਮ, ਸਭ ਤੋਂ ਵੱਧ ਪਾਬੰਦੀਆਂ ਵਾਲੀਆਂ ਸੈਟਿੰਗਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਹੌਲੀ-ਹੌਲੀ ਘੱਟੋ-ਘੱਟ ਲੋੜੀਂਦੀਆਂ ਅਨੁਮਤੀਆਂ ਨਾਲ ਖੁੱਲ੍ਹਦਾ ਹੈ pipeline ਕਦਮ

ਵਿੱਚ ਸੁਰੱਖਿਆ ਨੂੰ ਸੰਰਚਿਤ ਕਰਨਾ CI/CD ਟੂਲ ਗੁੰਝਲਦਾਰ ਕਾਰਨਾਮਾ ਹੋ ਸਕਦਾ ਹੈ। ਕਈਆਂ ਕੋਲ ਪਲੱਗਇਨ ਜਾਂ ਐਕਸਟੈਂਸ਼ਨ ਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਜ਼ਿਆਦਾਤਰ ਕਮਜ਼ੋਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਅਜਿਹੇ ਗੁੰਝਲਦਾਰ ਔਜ਼ਾਰਾਂ ਲਈ ਸੁਰੱਖਿਆ ਗਲਤ ਸੰਰਚਨਾ ਸਕੈਨਰ, ਜਾਂ ਬੈਂਚਮਾਰਕ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ।

ਕੋਡ ਨੂੰ ਇੰਜੈਕਟ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ pipeline ਮਨੋਰੰਜਨ ਅਤੇ ਮੁਨਾਫ਼ੇ ਲਈ ਹੁਕਮ

ਐਮ3ਐਮ3ਐਨ70: ਕੀ ਤੁਸੀਂ ਕਦੇ Untrusted Code Checkouts ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ, ਜੋ ਕਿ ਕਮਜ਼ੋਰ ਕਾਰਵਾਈਆਂ ਅਤੇ ਸਕ੍ਰਿਪਟਾਂ ਕਮਾਂਡ-ਇੰਜੈਕਸ਼ਨ ਲਈ ਕਮਜ਼ੋਰ ਹਨ?

ਇਹ ਭਾਗ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ pipeline ਆਪਣੇ ਆਪ ਵਿੱਚ ਕੋਡਿੰਗ ਗਲਤੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ ਜੋ ਮਾੜੇ ਅਦਾਕਾਰਾਂ ਨੂੰ ਮਨਮਾਨੇ ਕੋਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨੂੰ ਇੰਜੈਕਟ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ pipeline ਬਿਨਾਂ ਬਦਲੇ pipeline ਸਰੋਤ ਖੁਦ. ਉਦਾਹਰਣ ਵਜੋਂ ਇੱਕ PR ਦੀ ਵਰਤੋਂ ਕਰਨਾ

ਇੱਕ ਦੀ ਪਹਿਲੀ ਉਦਾਹਰਣ ਬਦਕਿਸਮਤ GitHub ਵਰਕਫਲੋ:

# INSECURE. Provided as an example only.
on:
  pull_request_target #1

jobs:
  build:
    name: Build and test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: $ #2

      - uses: actions/setup-node@v1
      - run: |
          npm install #3
          npm build
      # ... more steps ...

ਜੋੜਨਾ pull_request_target ਇੱਕ ਅਵਿਸ਼ਵਾਸਯੋਗ PR ਦੇ ਸਪੱਸ਼ਟ ਚੈੱਕਆਉਟ ਦੇ ਨਾਲ ਵਰਕਫਲੋ ਟਰਿੱਗਰ ਇੱਕ ਖ਼ਤਰਨਾਕ ਅਭਿਆਸ ਹੈ ਜੋ ਰਿਪੋਜ਼ਟਰੀ ਸਮਝੌਤਾ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਣ ਵਿੱਚ, ਇਹਨਾਂ ਦਾ ਬਦਕਿਸਮਤੀ ਵਾਲਾ ਸੁਮੇਲ:

  • pull_request_target ਇਵੈਂਟ, ਜਿਸ ਕੋਲ ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਟਾਰਗੇਟ ਰਿਪੋਜ਼ਟਰੀ ਅਤੇ ਟਾਰਗੇਟ ਰਿਪੋਜ਼ਟਰੀ ਸੀਕਰੇਟਸ ਲਈ ਲਿਖਣ ਦੀ ਇਜਾਜ਼ਤ ਹੁੰਦੀ ਹੈ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਬਾਹਰੀ ਫੋਰਕਸ ਤੋਂ ਵੀ, ਅਤੇ PR ਦੇ ਟਾਰਗੇਟ ਰਿਪੋਜ਼ਟਰੀ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਚੱਲਦਾ ਹੈ,
  • ਸਰੋਤ ਤੋਂ ਪੀਆਰ ਕੋਡ ਚੈੱਕਆਉਟ ਕਰੋ, ਅਵਿਸ਼ਵਾਸਯੋਗ ਰੈਪੋ,
  • ਕਿਸੇ ਵੀ ਸਕ੍ਰਿਪਟ ਨੂੰ ਚਾਲੂ ਕਰੋ ਜੋ PR ਨਿਯੰਤਰਿਤ ਸਮੱਗਰੀ 'ਤੇ ਕੰਮ ਕਰ ਸਕਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ ਦੇ ਮਾਮਲੇ ਵਿੱਚ npm installਹੈ, ਅਤੇ
  • ਟਰਿੱਗਰ ਕਰਨ ਲਈ ਕਿਸੇ ਸ਼ਰਤ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰਨਾ pull_request_target ਇਵੈਂਟ ਸਿਰਫ਼ ਤਾਂ ਹੀ ਚਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਜੇਕਰ ਕਿਸੇ ਕਿਸਮ ਦਾ 'ਇਸ PR ਦੀ ਜਾਂਚ ਕੀਤੀ ਗਈ ਸੀ' ਲੇਬਲ PR ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੋਵੇ (ਬਾਹਰੀ ਉਪਭੋਗਤਾ PR ਨੂੰ ਲੇਬਲ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰ ਸਕਦੇ)।

ਦੂਜੀ ਉਦਾਹਰਣ ਅਵਿਸ਼ਵਾਸੀ ਇਨਪੁਟ ਲੈਂਦੀ ਹੈ (ਕਿਸੇ ਮੁੱਦੇ, ਟਿੱਪਣੀ ਜਾਂ pull request) ਨੂੰ ਪਾਸ ਕੀਤੇ ਗਏ ਆਰਗੂਮੈਂਟਾਂ ਦੇ ਸਰੋਤ ਵਜੋਂ pipeline ਸਮੀਕਰਨਾਂ ਰਾਹੀਂ ਕਮਾਂਡ। ਇਹ ਹੈ pipeline OS ਕਮਾਂਡ ਇੰਜੈਕਸ਼ਨ ਕਮਜ਼ੋਰੀ ਦਾ ਸੰਸਕਰਣ।

- name: Check title
  run: |
    title="$"
    if [[ ! $title =~ ^.*:\ .*$ ]]; then
      echo "Bad issue title"
      exit 1
    fi

ਰਨ ਓਪਰੇਸ਼ਨ ਟੈਂਪਲੇਟ ਦੇ ਅਧਾਰ ਤੇ ਇੱਕ ਅਸਥਾਈ ਸ਼ੈੱਲ ਸਕ੍ਰਿਪਟ ਤਿਆਰ ਕਰਦਾ ਹੈ, ਜਿਸਦੇ ਨਾਲ $ ਬਦਲ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਜਿਸ ਨਾਲ ਇਹ ਸ਼ੈੱਲ ਕਮਾਂਡ ਇੰਜੈਕਸ਼ਨ ਲਈ ਕਮਜ਼ੋਰ ਹੋ ਜਾਂਦਾ ਹੈ। ਨਕਲੀ GitHub ਖਾਤੇ ਵਾਲਾ ਹਮਲਾਵਰ ਇੱਕ ਸਿਰਲੇਖ ਨਾਲ ਸਮੱਸਿਆ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ a"; bad_code_goes_here;#, ਅਤੇ ਬੂਮ! 

ਦਲਦਲ ਦਾ ਗੁੱਸਾ: ਓਹ, ਉਹ ਲੋਕ ਸਿਰਫ਼ ਇੱਕ ਮੁੱਦਾ ਖੋਲ੍ਹ ਕੇ ਕਮਾਂਡ ਇੰਜੈਕਸ਼ਨ ਲਈ ਦਰਵਾਜ਼ਾ ਖੋਲ੍ਹ ਰਹੇ ਸਨ...

GitHub ਐਕਸ਼ਨਾਂ ਵਿੱਚ ਕੋਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਕਮਜ਼ੋਰੀਆਂ ਸਨ, ਜਿਵੇਂ ਕਿ ਗਾਜੀਰਾ-ਟਿੱਪਣੀ, ਹੁਣ ਠੀਕ ਹੋ ਗਿਆ ਹੈ। ਕਿਰਪਾ ਕਰਕੇ ਪੜ੍ਹੋ। "GitHub ਵਰਕਫਲੋ ਵਿੱਚ ਗੈਰ-ਭਰੋਸੇਯੋਗ ਇਨਪੁੱਟ" ਪੂਰੇ ਵੇਰਵਿਆਂ ਲਈ

ਕਹਾਣੀ ਦਾ ਨੈਤਿਕ: ਪਹਿਲਾਂ PR ਦੀ ਸਮੀਖਿਆ ਕੀਤੇ ਬਿਨਾਂ ਕਦੇ ਵੀ ਗੈਰ-ਭਰੋਸੇਯੋਗ ਸਰੋਤਾਂ ਤੋਂ PRs ਚੈੱਕਆਉਟ ਨਾ ਕਰੋ ਅਤੇ ਨਾ ਬਣਾਓ। ਇੱਥੇ 'ਭਰੋਸੇਯੋਗ ਨਹੀਂ', ਜਦੋਂ ਤੱਕ ਕਿ ਮੂਲ ਦੇ ਸਖ਼ਤ ਪ੍ਰਮਾਣੀਕਰਨ ਦੇ ਅਧੀਨ ਨਾ ਹੋਵੇ, ਦਾ ਅਰਥ ਕੋਈ ਵੀ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਹਾਈਜੈਕ ਕੀਤਾ ਗਿਆ ਡਿਵੈਲਪਰ ਖਾਤਾ ਹੋ ਸਕਦਾ ਹੈ।

 

ਇੱਥੇ ਅਣਇੱਛਤ ਮਾਲਵੇਅਰ ਤੈਨਾਤੀ!

ਲਗਾਤਾਰ ਤਾਇਨਾਤੀ ਆਟੋਮੇਸ਼ਨ ਸਿਖਰ ਹੈ, ਪਰ ਉਹ ਸਿਖਰ ਉਚਿਤ ਪ੍ਰਵਾਨਗੀ ਨਿਯੰਤਰਣਾਂ ਦੀ ਘਾਟ ਕਾਰਨ ਨਿਰਾਸ਼ ਹੋ ਸਕਦਾ ਹੈ pipeline ਵਹਾਅ

ਸਰੋਤ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਵੈਚਾਲਿਤ ਤੈਨਾਤੀ ਦੇ ਜੋਖਮ commit ਉਤਪਾਦਨ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਖਤਰਨਾਕ ਕੋਡ ਨੂੰ ਉਤਪਾਦਨ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਖੋਜੇ ਬਿਨਾਂ ਤੈਨਾਤ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਸ਼ਾਮਲ ਹੈ, ਅਤੇ ਨਾਲ ਹੀ ਤੈਨਾਤੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਗਲਤੀਆਂ ਦੇ ਵਿਘਨ ਜਾਂ ਆਊਟੇਜ ਪੈਦਾ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਵੀ ਸ਼ਾਮਲ ਹੈ।

ਇਹਨਾਂ ਜੋਖਮਾਂ ਨੂੰ ਘਟਾਉਣ ਲਈ, ਅਕਸਰ ਇਹ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਸੰਗਠਨ ਆਪਣੀ ਤੈਨਾਤੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਇੱਕ "ਸਖਤ ਬ੍ਰੇਕ" ਲਾਗੂ ਕਰਨ, ਜਿਸਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਰੀਲੀਜ਼ਾਂ ਨੂੰ ਅੰਤਮ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਤੈਨਾਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ।

ਉਹ ਦਰਵਾਜ਼ੇ ਬੰਦ ਕਰ ਰਹੇ ਹਨ।

ਦਲਦਲ ਦਾ ਗੁੱਸਾ: ਉਹ ਖੁਸ਼ਹਾਲ ਡਿਫਾਲਟ ਪਾਸਵਰਡ CI/CD ਔਜ਼ਾਰਾਂ ਨੂੰ ਸਾਫ਼ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ। /var/lib/jenkins/secrets/initialAdminPassword ਹੁਣ ਇੱਕ ਡੈੱਡ ਟ੍ਰੈਕ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਟੂਲ ਹੁਣ 2FA ਪ੍ਰਦਾਨ ਕਰ ਰਹੇ ਹਨ, ਜਿਸਨੂੰ ਕੋਵਿਡ ਨੇ ਪ੍ਰਸਿੱਧ ਬਣਾਇਆ ਹੈ, ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਸਭ ਤੋਂ ਆਲਸੀ ਕੋਡ ਬਾਂਦਰ ਵੀ ਇਸਨੂੰ ਵਰਤ ਰਿਹਾ ਹੈ!

ਐਮ3ਐਮ3ਐਨ70: ਅਸੀਂ 2FA ਲੜ ਰਹੇ ਹਾਂ, ਪਰ ਇਹ ਇੰਨਾ ਆਸਾਨ ਨਹੀਂ ਹੈ। ਉਨ੍ਹਾਂ ਮੁੰਡਿਆਂ ਨੂੰ ਸਪੀਅਰ-ਫਿਸ਼ ਕਰਨਾ ਔਖਾ ਹੈ, ਕਿਉਂਕਿ "ਸਕੈਟਰ ਸਵਾਈਨ" ਨੇ ਟਵਿਲੀਓ ਨਾਲ ਕੀਤਾ. WebAuthn ਕੁੰਜੀਆਂ ਨਾਲ ਇਹ ਬਹੁਤ ਜ਼ਿਆਦਾ ਮੁਸ਼ਕਲ ਹੈ। ਘੱਟੋ ਘੱਟ, ਅਸੀਂ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹਾਂ MFA ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਲਈ ਕੂਕੀਜ਼ ਚੋਰੀ ਕਰੋ, ਪਰ ਡਿਵੈਲਪਰ ਦੇ ਡੱਬੇ ਵਿੱਚ ਦਾਖਲ ਹੋਣ ਦੀ ਲੋੜ ਹੈ।

ਮਲਟੀ-ਫੈਕਟਰ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਮਾਣੀਕਰਨ ਗੁਪਤ ਲੀਕ ਦੇ ਜੋਖਮ ਨੂੰ ਸੀਮਤ ਕਰਨ ਲਈ ਸਹੀ ਦਿਸ਼ਾ ਵਿੱਚ ਇੱਕ ਚੰਗਾ ਕਦਮ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਆਧੁਨਿਕ DevOps ਟੂਲ MFA ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ। ਅਤੇ WebAuthn / U2F ਦੇ ਅਧੀਨ ਪ੍ਰਮਾਣੀਕਰਨ ਕੁੰਜੀਆਂ (ਦੇਖੋ FIDO2 ਪ੍ਰੋਜੈਕਟ) ਸ਼ਾਇਦ DevOps ਵਿੱਚ MFA ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਵਿਕਲਪ ਹਨ, ਜੇਕਰ ਸਹੀ ਢੰਗ ਨਾਲ ਪ੍ਰਬੰਧਿਤ ਕੀਤਾ ਜਾਵੇ।

ਦਲਦਲ ਦਾ ਗੁੱਸਾ: DevOps ਮੁੰਡੇ ਜਾਗ ਰਹੇ ਹਨ। ਉਨ੍ਹਾਂ ਦੇ ਖੂਨ ਵਿੱਚ "ਘੱਟ ਤੋਂ ਘੱਟ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ" ਵਾਲੀ ਚੀਜ਼ ਹੈ। ਅਤੇ ਉਹ ਹੁਣ ਕੋਡ ਬਾਂਦਰ ਨਹੀਂ ਰਹੇ। ਹੁਣ ਅਸੀਂ ਸਮੀਖਿਅਕਾਂ ਦੁਆਰਾ ਰੰਗੇ ਹੱਥੀਂ ਫੜੇ ਜਾਂਦੇ ਹਾਂ।

ਵਾਸਤਵ ਵਿੱਚ, pipelines ਹੁਣ ਕੁਝ ਸਾਲ ਪਹਿਲਾਂ ਨਾਲੋਂ ਥੋੜ੍ਹੇ ਜ਼ਿਆਦਾ ਮਜ਼ਬੂਤ ​​ਹਨ, ਕਮਜ਼ੋਰ ਕਾਰਵਾਈਆਂ ਅਤੇ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਵਾਧੂ ਸੁਰੱਖਿਆ ਜਾਂਚ ਕਦਮਾਂ ਦੇ ਨਾਲ ਜਿਨ੍ਹਾਂ ਨੇ ਚੋਰੀ-ਛਿਪੇ ਸਾਡੇ ਡਰਾਪਰਾਂ ਦਾ ਪਤਾ ਵੀ ਲਗਾਇਆ ਹੈ। commits ਅਤੇ ਪੈਕੇਜ ਜੋ ਅਸੀਂ ਹਾਈਜੈਕ ਕੀਤੇ ਸਨ।

ਪਾਠਕ ਲਈ ਸਵਾਲ: ਕੀ ਸਰੋਤਾਂ ਤੋਂ ਸਾਫਟਵੇਅਰ ਬਣਾਉਣ ਅਤੇ ਉਤਪਾਦਨ ਵਿੱਚ ਤੈਨਾਤ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਇੱਕ ਜੋਖਮ ਭਰਿਆ ਕਾਰੋਬਾਰ ਹੈ? ਕੀ ਤੁਸੀਂ ਆਪਣੇ DevOps ਨੂੰ ਇਸ ਪੜਾਅ ਵਿੱਚ ਦੇਖ ਸਕਦੇ ਹੋ ਬਹੁਤ ਵਧੀਆ ਸਮਾਂ ਬੁਰੇ ਬੰਦਿਆਂ ਲਈ?

ਅੰਤਮ ਸਿਫਾਰਸ਼ਾਂ

ਕਿੱਥੋਂ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ CI/CD pipelines?

ਪਹਿਲੀ ਸਿਫਾਰਸ਼ ਇੱਥੇ ਸਧਾਰਨ ਹੈ: ਧਿਆਨ ਨਾਲ ਸਮੀਖਿਆ pipelines (ਉਹ ਨਾਜ਼ੁਕ ਸੁਰੱਖਿਆ ਮੁੱਦਿਆਂ ਲਈ ਸਰੋਤ)। ਸਮੀਖਿਆਵਾਂ ਮਹਿੰਗੀਆਂ ਹਨ ਪਰ ਜ਼ਰੂਰੀ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਮੀਖਿਅਕਾਂ ਨੂੰ ਇਸ ਗੱਲ ਦਾ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਦੇਖਣਾ ਹੈ। ਹਰ ਕਦਮ ਦੀ ਕਮੀਆਂ ਲਈ ਜਾਂਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।

ਸ਼ਾਇਦ ਸਵੈਚਾਲਿਤ ਖਤਰਨਾਕ ਕੋਡ ਸਕੈਨਰਾਂ ਨਾਲ ਲੈਸ ਮਾਹਰ ਸਮੀਖਿਅਕਾਂ ਦਾ ਸੁਮੇਲ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ।

ਦੂਜੀ ਸਿਫਾਰਸ਼ ਇਹ ਹੈ ਕਿ ਲਿਖਣ ਵਾਲੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਸਿਖਲਾਈ ਦਿਓ pipelines ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸੁਰੱਖਿਆ 'ਤੇ ਬਣਾਈ ਰੱਖੋ. ਵਿਚਾਰਨ ਵਾਲੀਆਂ ਗੱਲਾਂ:

  • ਲੰਬੇ ਸਮੇਂ ਦੇ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਨੂੰ ਸੰਭਾਲਣ ਦੀ ਪਰੇਸ਼ਾਨੀ ਤੋਂ ਬਚਦੇ ਹੋਏ, ਅੰਦਰੂਨੀ ਅਤੇ ਕਲਾਉਡ ਸੇਵਾਵਾਂ ਨਾਲ ਪ੍ਰਮਾਣੀਕਰਨ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕਿਵੇਂ ਸੰਭਾਲਣਾ ਹੈ।
  • ਸੀਮਤ ਕਿਵੇਂ ਕਰੀਏ pipelineਸਰੋਤਾਂ ਦੇ ਸਹੀ ਸਮੂਹ ਤੱਕ ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੈ। ਘੱਟੋ-ਘੱਟ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਦਾ ਸਿਧਾਂਤ ਫਿਰ ਚਮਕਦਾ ਹੈ।
  • ਬਣਾਉਣ ਲਈ ਕਦਮ ਕਿਵੇਂ ਲਿਖਣੇ ਹਨ pipelineਵਰਜਨ ਪਿੰਨਿੰਗ ਵਾਂਗ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰਨ ਯੋਗ, ਅਤੇ ਕਮਾਂਡ ਇੰਜੈਕਸ਼ਨ ਕਮਜ਼ੋਰੀਆਂ ਤੋਂ ਬਚਣਾ।
  • ਸੁਰੱਖਿਆ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਤੈਨਾਤੀਆਂ ਨੂੰ ਕਿਵੇਂ ਮਨਜ਼ੂਰੀ ਦੇਣੀ ਹੈ (ਉਹ ਹੋਰ ਹਨ!): ਕਿਹੜੀ ਸੁਰੱਖਿਆ standards ਦਾ ਮੇਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਸੰਬੰਧਿਤ ਚੈੱਕ/ਗੇਟ ਕਿਵੇਂ ਜੋੜਨੇ ਹਨ pipelines.

ਤੀਜੀ ਸਿਫਾਰਸ਼ ਇਹ ਹੈ ਕਿ ਸੰਰਚਿਤ ਕਰੋ CI/CD ਧਿਆਨ ਨਾਲ ਸਿਸਟਮ. ਮਜ਼ਬੂਤ ​​ਪ੍ਰਮਾਣੀਕਰਨ, ਕੋਈ ਡਿਫਾਲਟ ਪਾਸਵਰਡ ਜਾਂ ਅਸੁਰੱਖਿਅਤ ਸੈਟਿੰਗਾਂ ਨਹੀਂ, ਘੱਟੋ-ਘੱਟ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ... ਇੰਸਟਾਲ ਕੀਤੇ ਪਲੱਗਇਨਾਂ ਅਤੇ ਐਕਸਟੈਂਸ਼ਨਾਂ ਵਿੱਚ ਕਮਜ਼ੋਰੀਆਂ ਦਾ ਧਿਆਨ ਰੱਖੋ। ਇਹ ਅਗਲੀਆਂ ਪੋਸਟਾਂ ਦਾ ਕੇਂਦਰ ਹੋ ਸਕਦਾ ਹੈ, ਕਿਰਪਾ ਕਰਕੇ ਜੁੜੇ ਰਹੋ।

ਚੌਥੀ ਸਿਫਾਰਸ਼ ਇਹ ਹੈ ਕਿ ਦਾ ਲਾਭ ਉਠਾਓ CI/CD pipelineਸੁਰੱਖਿਆ ਆਟੋਮੇਸ਼ਨ ਲਈ ਐੱਸ.. ਸਰੋਤ ਕੋਡ ਵਿਸ਼ਲੇਸ਼ਣ (SAST), ਸਰੋਤ ਰਚਨਾ ਵਿਸ਼ਲੇਸ਼ਣ (SCA), ਸੀਕ੍ਰੇਟ ਲੀਕ ਸਕੈਨਿੰਗ, ਐਂਟੀ-ਮਾਲਵੇਅਰ ਟੂਲ, ਕੰਟੇਨਰ ਸੁਰੱਖਿਆ ਸਕੈਨਰ, ਜਾਂ ਆਟੋਮੇਟਿਡ ਰਨਟਾਈਮ ਡਿਟੈਕਟਰ (DAST ਅਤੇ ਮਾਲਵੇਅਰ) ਨੂੰ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਚਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। pipeline. ਅਤੇ ਤੁਹਾਡਾ ਸੰਗਠਨ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ standardਵਿੱਚ ਸੁਰੱਖਿਆ ਸਕੈਨਿੰਗ 'ਤੇ ਕਵਰੇਜ ਬਾਰੇ CI/CD.

ਯਾਦ ਦਿਵਾਓ, ਇਹ ਔਜ਼ਾਰ ਅਜੇ ਵੀ ਸਮੀਕਰਨ ਤੋਂ ਮਾਹਰ ਸਮੀਖਿਆ ਨੂੰ ਨਹੀਂ ਹਟਾਉਂਦੇ, ਨਹੀਂ ਤਾਂ ਤੁਹਾਡੇ ਵਿੱਚ ਸੁਰੱਖਿਆ ਦੀ ਗਲਤ ਭਾਵਨਾ ਹੋ ਸਕਦੀ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ OWASP ਟੌਪ-ਟੈਨਸ ਦੇ ਮਾਹਰ ਹੋ, ਤਾਂ ਇੱਕ ਵਧੀਆ ਹਾਲੀਆ ਪ੍ਰੋਜੈਕਟ ਹੈ OWASP ਚੋਟੀ ਦੇ 10 CI/CD ਸੁਰੱਖਿਆ ਜੋਖਮ.

ਬੇਦਾਅਵਾ ਨੋਟ

(1) ਇਸ ਪੋਸਟ ਵਿੱਚ ਦਿੱਤੀਆਂ ਉਦਾਹਰਣਾਂ GitHub ਦੀ ਵਰਤੋਂ ਇਸ ਤਰ੍ਹਾਂ ਕਰ ਰਹੀਆਂ ਹਨ SCM, ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ ਵਜੋਂ AWS, ਅਤੇ GitHub Actions ਜਾਂ Jenkins ਵਜੋਂ CI/CD ਔਜ਼ਾਰ। ਇਹ ਆਪਣੇ ਵਿਕਲਪਾਂ ਨਾਲੋਂ ਕਮਜ਼ੋਰ / ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹਨ। ਪ੍ਰੈਸ ਦਾ ਕੋਈ ਮਾੜਾ ਇਰਾਦਾ ਨਹੀਂ ਹੈ! ਇਹ ਔਜ਼ਾਰ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹਨ ਅਤੇ ਇਹਨਾਂ ਦੀ ਸਹੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

(2) ਐਮ3ਐਮ3ਐਨ70 ਅਤੇ ਦਲਦਲ ਦਾ ਗੁੱਸਾ ਕਾਲਪਨਿਕ ਪਾਤਰ ਹਨ। ਵਿਅਕਤੀਆਂ ਜਾਂ ਸਮੂਹਾਂ ਨਾਲ ਕੋਈ ਵੀ ਸਮਾਨਤਾ, ਜੀਵਤ ਜਾਂ ਮੌਤ, ਸਿਰਫ਼ ਸੰਜੋਗ ਹੈ... ਜਾਂ ਕੀ ਇਹ ਹੈ?

ਹੋਰ ਪੜ੍ਹਨ ਲਈ

sca-ਟੂਲਜ਼-ਸਾਫਟਵੇਅਰ-ਰਚਨਾ-ਵਿਸ਼ਲੇਸ਼ਣ-ਟੂਲਜ਼
ਆਪਣੇ ਸਾਫਟਵੇਅਰ ਜੋਖਮਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ, ਸੁਧਾਰੋ ਅਤੇ ਸੁਰੱਖਿਅਤ ਕਰੋ
ਆਪਣਾ ਮੁਫ਼ਤ ਖਾਤਾ ਪ੍ਰਾਪਤ ਕਰੋ।
ਕੋਈ ਕ੍ਰੈਡਿਟ ਕਾਰਡ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ
ਮੁਫ਼ਤ ਸ਼ੁਰੂ ਕਰੋ

ਆਪਣੇ ਸਾਫਟਵੇਅਰ ਵਿਕਾਸ ਅਤੇ ਡਿਲੀਵਰੀ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰੋ

ਜ਼ਾਇਜੇਨੀ ਪ੍ਰੋਡਕਟ ਸੂਟ ਦੇ ਨਾਲ

ਮੁਫ਼ਤ ਸ਼ੁਰੂ ਕਰੋ
ਉਤਪਾਦ ਟੂਰ ਲਓ
ਜ਼ਾਇਗੇਨੀ ਲੋਗੋ ਚਿੱਟਾ

© 2026 ਜ਼ਾਇਜੇਨੀ। ਸਾਰੇ ਹੱਕ ਰਾਖਵੇਂ ਹਨ

ਲਿੰਕਡਿਨ-ਇਨ ਐਕਸ-ਟਵਿੱਟਰ Youtube

ਉਤਪਾਦ

ਸਰੋਤ

ਕੰਪਨੀ

ਕਾਨੂੰਨੀ