Accesso alle impostazioni del set di regole

1. Passa alla scheda Settings del tuo repository su GitHub.
2. Nella barra laterale sinistra, sotto Regole, fare clic su Regole per accedere alla pagina delle impostazioni delle regole.
3. Fare clic sul pulsante verde Nuovo RuleSet di filiale
4. Aggiungere le informazioni necessarie per definire il Ruleset e fare clic su Crea.

Aggiunta di regole di protezione nei set di regole

Facendo clic sul pulsante verde Nuovo set di regole di diramazione, viene visualizzata una pagina per la compilazione dei dettagli del set di regole.

1. Assegnare un nome al sito RuleSet e abilitare/disabilitare/valutare il set di regole selezionando dal menu a tendina lo stato di abilitazione

2. Configurare i rami di destinazione facendo clic su Aggiungi destinazione. Selezionare Includi**, Escludi****, Predefinito** o Tutti per configurare i criteri di targeting delle filiali. GitHub supporta la sintassi fnmatch per il puntamento basato su modelli.

3. Configurare i permessi di bypass sotto l'elenco Bypass facendo clic su Aggiungi bypass. È possibile aggiungere i ruoli richiesti che possono aggirare i controlli. È possibile lasciare l'elenco vuoto (ciò equivale ad attivare l'opzione Non consentire l'aggiramento di queste impostazioni nelle impostazioni tradizionali di protezione del ramo).

4. Attivare l'opzione Richiedi una richiesta di pull prima dell'unione in Regole di diramazione.

5. Abilitare l'opzione Richiedi approvazioni e impostare il Numero richiesto di approvazioni prima dell'unione su almeno 1 o il numero di approvazioni richieste nel team.

6. Abilitare l'opzione Elimina le approvazioni delle richieste di pull obsolete quando viene eseguito il push dei nuovi commit per esaminare tutte le modifiche più recenti prima che possano essere unite in un altro ramo.

Limitazione

Attualmente, l'elenco degli attori bypassati può essere recuperato solo dai set di regole a livello di repository. Se un ruleset è definito a livello di organizzazione, queste informazioni non possono essere recuperate da tali ruleset, in base alle autorizzazioni standard.

Per recuperare l'elenco degli attori bypassati dai set di regole a livello di organizzazione, verificare l'accesso richiesto e concedere all'account Functional ID/GitHub che sta eseguendo la pipeline privilegi elevati (accesso proprietario all'organizzazione ). Ciò è dovuto al modello di autorizzazione GitHub's, che limita la visibilità dei metadati degli attori che bypassano il set di regole a livello di organizzazione senza un'autorizzazione appropriata per impedire la fuga di informazioni sensibili.

Per ulteriori informazioni, consultare la documentazione ufficiale di GitHub sui set di regole di organizzazione e sugli attori di bypass.

Configurazione dei controlli di stato per le reti di regole

1. Abilitare l'opzione Require status checks to pass before merging.

Per poterli impostare come controlli di stato richiesti, è necessario prima attivare una pipeline PR/CI (solo i controlli di stato esistenti sono elencati nell'interfaccia utente).

Dopo aver abilitato l'opzione Require status checks to pass before merging, è necessario configurare i controlli di stato specifici che devono superare prima di unire una richiesta di pull.

2. Nell'elenco dei controlli di stato disponibili, abilitare le seguenti opzioni per i controlli:

• tekton/code-branch-protection
• tekton/code-cis-check
• tekton/code-detect-secrets
• tekton/code-unit-tests
• tekton/code-vulnerability-scan

Questi controlli sono i controlli di stato delle richieste di pull previsti di default nella pipeline.

Aggiunta di tutte le regole predefinite (configurazione completa)

Questo comando CURL imposta sia i controlli di stato richiesti che le impostazioni di revisione delle richieste di pull.

curl -H "Authorization: Bearer $(cat ${APP_TOKEN_PATH})" "${APP_API_URL}/repos/${APP_REPO_OWNER}/${APP_REPO_NAME}/rulesets" \
    -XPUT -d '{
  "name": "Branch Protection Equivalent Ruleset",
  "target": "branch",
  "enforcement": "active",
  "bypass_actors": [], // as the list is empty no one can bypass which is equivalent to enforce_admins: true with no restriction
  "conditions": {
    "ref_name": {
      "include": ["refs/heads/master"],
      "exclude": []
    }
  },
  "rules": [
    {
      "type": "required_status_checks",
      "parameters": {
        "strict_required_status_checks_policy": true,
        "required_status_checks": [
          {
            "context": "tekton/code-unit-tests"
          },
          {
            "context": "tekton/code-branch-protection"
          },
          {
            "context": "tekton/code-cis-check"
          },
          {
            "context": "tekton/code-vulnerability-scan"
          },
          {
            "context": "tekton/code-detect-secrets"
          }
        ]
      }
    },
    {
      "type": "pull_request",
      "parameters": {
        "required_approving_review_count": 1,
        "dismiss_stale_reviews_on_push": true,
        "require_code_owner_review": false,
        "require_last_push_approval": false,
        "required_review_thread_resolution": false
      }
    }
  ]
}'

Accesso alle impostazioni di protezione del ramo

1. Passa alla scheda Settings del tuo repository su GitHub.
2. Nella barra laterale sinistra, fare clic su Filiali per accedere alla pagina delle impostazioni del ramo.
3. Scorri fino alla sezione Regole di protezione del ramo.
4. Individuare il ramo che si desidera configurare (di solito il ramo "principale").
5. Selezionare il pulsante Modifica accanto al nome ramo per modificarne le regole di protezione.

Aggiunta di regole di protezione del ramo

Se non è impostata alcuna regola esistente, fare clic su Aggiungi regola e immettere il nome del ramo corrispondente nel campo **Branch name pattern**. Quindi, procedere con i seguenti passi:

1. Abilitare l'opzione Richiedi una richiesta di pull prima dell'unione.
2. Abilitare l'opzione Richiedi approvazioni e impostare il Numero richiesto di approvazioni prima dell'unione su almeno 1 o il numero di approvazioni richieste nel team.
3. Abilitare l'opzione Elimina le approvazioni delle richieste di pull obsolete quando viene eseguito il push dei nuovi commit per esaminare tutte le modifiche più recenti prima che possano essere unite in un altro ramo.

4. Abilitare l'opzione Non consentire l'aggiramento delle impostazioni per impedire agli amministratori e ai ruoli personalizzati con l'autorizzazione di bypassare le protezioni di ramo di aggirare i controlli di protezione di ramo richiesti.

Attualmente, gli avvisi vengono visualizzati nei log se il controllo di Do not allow bypassing these settings non è abilitato. Non fallirà il controllo di protezione delle filiali fino a quando il controllo non sarà reso obbligatorio entro la metà di marzo. Si prega di attivare il controllo entro la metà di marzo per evitare il malfunzionamento della conduttura.

Le richieste di pull devono essere approvate prima dell'unione nel ramo principale. Questa regola garantisce che le modifiche vengano sottoposte a revisione e controllo da parte dei membri del team, promuove la collaborazione, la qualità del codice e il rispetto degli standard del progetto.

Configurazione dei controlli stato

Sono richiesti controlli di statoDevSecOps applicare una serie completa di misure di qualità e sicurezza sul codice. Ciò garantisce che le modifiche al codice siano sicure e affidabili prima che vengano unite in un ramo protetto. Richiedendo che i controlli di stato vengano superati prima dell'unione, è possibile impedire che il codice interrotto o non testato venga distribuito in produzione.

Quando viene inoltrata una richiesta di pull, la pipeline PR/CI attiva automaticamente una serie di test, convalide e altri controlli per verificare le modifiche proposte.

Solo quando tutti i controlli di stato richiesti avranno esito positivo la richiesta di pull sarà considerata idonea per l'unione nel ramo protetto.

Sfruttando i controlli di stato all'internoDevSecOps, puoi mantenere la qualità del codice, aderire agli standard di codifica e garantire l'assenza di vulnerabilità o difetti critici prima di incorporare le modifiche nel ramo protetto del tuo progetto.

Per ulteriori informazioni sulla configurazione dei controlli di stato, fare riferimento alla sezione Configurazione solo dei controlli di stato(Configurazione dei controlli di stato) per un'implementazione di riferimento.

1. Abilitare l'opzione Require status checks to pass before merging.

Per poterli impostare come controlli di stato richiesti, è necessario prima attivare una pipeline PR/CI (solo i controlli di stato esistenti sono elencati nell'interfaccia utente).

Dopo aver abilitato l'opzione Require status checks to pass before merging, è necessario configurare i controlli di stato specifici che devono superare prima di unire una richiesta di pull.

2. Nell'elenco dei controlli di stato disponibili, abilitare le seguenti opzioni per i controlli:

• tekton/code-branch-protection
• tekton/code-cis-check
• tekton/code-detect-secrets
• tekton/code-unit-tests
• tekton/code-vulnerability-scan

I controlli di stato visualizzati devono essere superati prima di unire una richiesta di pull.

Questi controlli sono i controlli di stato delle richieste di pull previsti di default nella pipeline.

[{
  "type": "branch-protection",
  "name": "code-review",
  "params": {
    "checks": [
      "tekton/code-branch-protection",
      "tekton/code-unit-tests",
      "tekton/code-cis-check",
      "tekton/code-vulnerability-scan",
      "tekton/code-detect-secrets"
    ]
  }
}]

Impostazioni facoltative

Oltre alle impostazioni precedenti, è possibile configurare le seguenti impostazioni aggiuntive per le regole di protezione del ramo. Tieni presente che i controlli di stato forniti daDevSecOps non convaliderà né applicherà queste impostazioni.

• Richiedi commit firmati: questa impostazione richiede la firma di tutti i commit sul ramo protetto, impedendo modifiche dannose al codice.

• Richiedi cronologia lineare: questa impostazione richiede che tutti i commit per il ramo protetto abbiano una cronologia lineare. Ciò significa che tutte le richieste di pull unite nel ramo protetto devono utilizzare un'unione di squash o un'unione di modifica. Una cronologia di commit strettamente lineare può aiutare i team a invertire più facilmente le modifiche.

Queste impostazioni aggiuntive sono facoltative e possono essere personalizzate in base ai requisiti e alle preferenze specifiche.

Aggiunta di tutte le regole di protezione del ramo (Configurazione completa)

Le regole di protezione del ramo possono essere impostate anche dal seguente comando curl, dopo aver sostituito le variabili $GH_TOKEN, $OWNER, $APP_API_URL $REPO, $BRANCH.

curl -u ":$GH_TOKEN" $APP_API_URL/repos/$OWNER/$REPO/branches/$BRANCH/protection -XPUT -d '{"required_pull_request_reviews":{"dismiss_stale_reviews":true},"required_status_checks":{"strict":true,"contexts":["tekton/code-branch-protection","tekton/code-unit-tests","tekton/code-cis-check","tekton/code-vulnerability-scan","tekton/code-detect-secrets"]},"enforce_admins":null,"restrictions":null}'

Questo comando CURL imposta sia i controlli di stato richiesti che le impostazioni di revisione della richiesta di pull.

Una volta configurate queste impostazioni, qualsiasi tentativo di unire una richiesta di pull a $BRANCH verrà rifiutato, a meno che la richiesta di pull non sia stata approvata da almeno un altro utente.

Configurazione solo controlli stato (Configurazione controlli stato)

Se si desidera configurare solo i controlli di stato richiesti, è possibile utilizzare il seguente comando CURL come riferimento:

curl -H "Authorization: Bearer $(cat ${APP_TOKEN_PATH})" "${APP_API_URL}/repos/${APP_REPO_OWNER}/${APP_REPO_NAME}/branches/master/protection" \
    -XPUT -d '{"required_pull_request_reviews":{"dismiss_stale_reviews":true},"required_status_checks":{"strict":true,"contexts":["tekton/code-branch-protection","tekton/code-unit-tests","tekton/code-cis-check","tekton/code-vulnerability-scan","tekton/code-detect-secrets"]},"enforce_admins":null,"restrictions":null}'

Nella nostra implementazione di riferimento, abbiamo già fornito una configurazione di esempio per il repository hello - compliance - app, in modo da poterla utilizzare come punto di partenza e personalizzarlo in base alle tue esigenze.

Seguire l'esempio precedente per garantire la qualità e il rispetto delle misure di sicurezza per il repository. Per garantire che ciò avvenga, configurare le regole di protezione del ramo e i controlli di stato necessari.