Acesso às configurações do conjunto de regras

1. Navegue para a guia Configurações de seu repositório no GitHub..
2. Na barra lateral esquerda, em Rules, clique em Rulesets para acessar a página de configurações do Ruleset.
3. Clique no botão verde Novo RuleSet
4. Adicione as informações necessárias para definir o conjunto de regras e clique em Create (Criar ).

Adição de regras de proteção em conjuntos de regras

Ao clicar no botão verde New Branch RuleSet, é exibida uma página para preenchimento dos detalhes do Ruleset.

1. Nomeie seu RuleSet e ative/desative/avalie o conjunto de regras selecionando no menu suspenso Status de ativação

2. Configure as ramificações de destino clicando em Adicionar destino. Selecione Include (Incluir**), Exclude (Excluir****), Default (Padrão** ) ou All (Todos ) para configurar os critérios de direcionamento da Filial. GitHub suporta a sintaxe fnmatch para direcionamento baseado em padrões.

3. Configure as permissões de Bypass na lista Bypass clicando em Add bypass. Você pode adicionar as funções necessárias que podem ignorar as verificações. Você pode deixar a lista vazia (isso equivale a ativar a opção Não permitir o desvio dessas configurações nas configurações tradicionais de proteção de ramificação).

4. Habilite a opção Exigir um pull request antes de fazer o merge em Regras de ramificação.

5. Ative a opção Requerer aprovações e configure o Número necessário de aprovações antes de mesclar configurado para pelo menos 1 ou o número de aprovações necessárias em sua equipe

6. Ative a opção Descartar as aprovações de solicitação pull antigas quando novas confirmações forem enviadas por push para revisar todas as mudanças mais recente antes que elas possam ser mescladas em outra ramificação

Limitação

Atualmente, a lista de atores de desvio só pode ser recuperada dos conjuntos de regras em nível de repositório. Se um conjunto de regras for definido em nível de organização, essas informações não poderão ser recuperadas desses conjuntos de regras, de acordo com as permissões padrão.

Para recuperar a lista de atores de bypass dos conjuntos de regras em nível de organização, revise o acesso necessário e conceda à conta Functional ID/GitHub que está executando o pipeline privilégios elevados (acesso de proprietário à organização ). Isso ocorre devido ao modelo de permissão GitHub's, que restringe a visibilidade dos metadados do ator que ignora o conjunto de regras em nível de organização sem a autorização apropriada para evitar vazamento de informações confidenciais.

Para obter mais informações, consulte a documentação oficial do site GitHub sobre conjuntos de regras de organização e atores de desvio.

Configuração de verificações de status para o conjunto de regras

1. Ative a opção Require status checks to pass before merging..

Para poder configurá-las como verificações de status necessárias, primeiro é necessário acionar um pipeline de PR/CI antecipadamente (somente as verificações de status existentes são listadas na IU).

Depois de ativar a opção Require status checks to pass before merging, é necessário configurar as verificações de status específicas que devem passar antes de mesclar uma solicitação pull.

2. Na lista de verificações de status disponíveis, ative as seguintes opções para verificações:

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

Essas verificações são as verificações de status de pull request padrão esperadas no pipeline.

Adição de todos os conjuntos de regras padrão (configuração completa)

Esse comando CURL define as verificações de status padrão necessárias e as configurações de revisão de pull request.

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
      }
    }
  ]
}'

Acessando Configurações de Proteção de Ramificação

1. Navegue para a guia Configurações de seu repositório no GitHub..
2. Na barra lateral esquerda, clique em Ramificações para acessar a página de configurações de ramificação
3. Role até a seção Regras de proteção de ramificação.
4. Localize a ramificação que deseja configurar (geralmente a ramificação "principal").
5. Selecione o botão Editar próximo ao nome da ramificação para modificar suas regras de proteção.

Incluindo regras de proteção de ramificação

Se nenhuma regra existente estiver configurada, clique no botão Incluir regra e insira o nome da ramificação correspondente no campo **Branch name pattern** Em seguida, prossiga com as etapas a seguir:

1. Ative a opção Requerer uma solicitação pull antes de mesclar
2. Ative a opção Requerer aprovações e configure o Número necessário de aprovações antes de mesclar configurado para pelo menos 1 ou o número de aprovações necessárias em sua equipe
3. Ative a opção Descartar as aprovações de solicitação pull antigas quando novas confirmações forem enviadas por push para revisar todas as mudanças mais recente antes que elas possam ser mescladas em outra ramificação

4. Ative a opção Não permitir ignorar as configurações para evitar que administradores e funções personalizadas com a permissão de ignorar proteções de ramificação ignorem as verificações de proteção de ramificação necessárias.

Atualmente, os avisos são flutuantes nos registros se a verificação Do not allow bypassing these settings não estiver ativada. Ele não será reprovado na verificação de proteção da agência até que a verificação se torne obrigatória em meados de março. Ative a verificação até meados de março para evitar falhas no pipeline.

As solicitações pull devem ser aprovadas antes de serem mescladas na ramificação principal. Essa regra assegura que as mudanças sejam revisadas e examinadas pelos membros da equipe, promovam a colaboração, a qualidade do código e a aderência aos padrões do projeto

Configurando verificações de status

Verificações de status são necessárias emDevSecOps para impor um conjunto abrangente de medidas de qualidade e segurança no código. Isso assegura que as mudanças de código sejam seguras e confiáveis antes de serem mescladas em uma ramificação protegida.. Ao requerer que as verificações de status sejam aprovadas antes da mesclagem, é possível evitar que o código quebrado ou não testado seja implementado na produção

Quando uma solicitação pull é enviada, o pipeline PR/CI aciona automaticamente uma série de testes, validações e outras verificações para verificar as mudanças propostas.

Somente quando todas as verificações de status necessárias forem aprovadas, a solicitação pull será considerada elegível para mesclagem na ramificação protegida.

Ao aproveitar as verificações de status dentroDevSecOps, você pode manter a qualidade do código, aderir aos padrões de codificação e garantir a ausência de vulnerabilidades ou falhas críticas antes de incorporar alterações na ramificação protegida do seu projeto.

Para obter mais informações sobre como configurar verificações de status, consulte a seção Configurando somente verificações de status(Configuração de verificações de status) para obter uma implementação de referência.

1. Ative a opção Require status checks to pass before merging..

Para poder configurá-las como verificações de status necessárias, primeiro é necessário acionar um pipeline de PR/CI antecipadamente (somente as verificações de status existentes são listadas na IU).

Depois de ativar a opção Require status checks to pass before merging, é necessário configurar as verificações de status específicas que devem passar antes de mesclar uma solicitação pull.

2. Na lista de verificações de status disponíveis, ative as seguintes opções para verificações:

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

As verificações de status mostradas devem passar antes de mesclar uma solicitação pull.

Essas verificações são as verificações de status de pull request padrão esperadas no 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"
    ]
  }
}]

Configurações opcionais

Além das configurações acima, você tem a opção de definir as seguintes configurações adicionais para as regras de proteção de ramificação. Observe que as verificações de status fornecidas porDevSecOps não validará ou aplicará essas configurações.

• Requerer confirmações assinadas: essa configuração requer que todas as confirmações na ramificação protegida sejam assinadas, evitando que mudanças maliciosas sejam feitas no código.

• Requerer histórico linear: Essa configuração requer que todas as confirmações na ramificação protegida tenham um histórico linear. Isso significa que qualquer solicitação pull mesclada na ramificação protegida deve usar uma mesclagem de squash ou uma mesclagem de nova base. Um histórico de confirmação estritamente linear pode ajudar as equipes a reverter mudanças mais facilmente.

Essas configurações adicionais são opcionais e podem ser customizadas com base em seus requisitos e preferências específicos

Incluindo Todas as regras de proteção de ramificação (Configuração completa)

As regras de proteção de ramificação também poderiam ser configuradas pelo comando curl a seguir, depois de substituir as variáveis $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}'

Esse comando CURL define as verificações de status necessárias e as configurações de revisão de solicitação de pull (pull).

Quando essas configurações tiverem sido configuradas, qualquer tentativa de mesclar uma solicitação pull para o $BRANCH será rejeitada, a menos que a solicitação pull tenha sido aprovada por pelo menos um outro usuário.

Configurando apenas verificações de status (Configuração de verificações de status)

Se você desejar apenas configurar as verificações de status necessárias, poderá usar o comando CURL a seguir como uma referência:

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}'

Em nossa implementação de referência, nós já fornecemos uma configuração de amostra para o repositório hello-compliance-app, portanto, é possível usá-la como um ponto de início e customizá-la de acordo com suas necessidades

Siga o exemplo anterior para assegurar a qualidade do código e a adesão às medidas de segurança para seu repositório. Para assegurar que isso ocorra, configure as regras de proteção de ramificação e as verificações de status necessárias