{"meta":{"title":"Práticas recomendadas para proteger seu sistema de compilação","intro":"Orientação sobre como proteger o final da sua cadeia de suprimentos — os sistemas que você usa para construir e distribuir artefatos.","product":"Qualidade de segurança e código","breadcrumbs":[{"href":"/pt/code-security","title":"Qualidade de segurança e código"},{"href":"/pt/code-security/tutorials","title":"Tutorials"},{"href":"/pt/code-security/tutorials/implement-supply-chain-best-practices","title":"Implementar as práticas recomendadas da cadeia de suprimentos"},{"href":"/pt/code-security/tutorials/implement-supply-chain-best-practices/securing-builds","title":"Protegendo builds"}],"documentType":"article"},"body":"# Práticas recomendadas para proteger seu sistema de compilação\n\nOrientação sobre como proteger o final da sua cadeia de suprimentos — os sistemas que você usa para construir e distribuir artefatos.\n\n## Sobre este guia\n\nEste guia descreve mudanças de maior impacto que você pode fazer para melhorar a segurança de seus sistemas de construção. Cada seção descreve uma alteração que você pode fazer em seus processos para melhorar a segurança. As mudanças de maior impacto estão listadas primeiro.\n\n## Qual o risco?\n\nAlguns ataques a cadeias de suprimentos de software visam diretamente o sistema de construção. Se um invasor pode modificar o processo de construção, ele pode explorar seu sistema sem o esforço de comprometer contas pessoais ou código. É importante garantir que você não se esqueça de proteger o sistema de compilação, bem como contas pessoais e código.\n\n## Proteja seu sistema de compilação\n\nExistem vários recursos de segurança que um sistema de construção deve ter:\n\n1. Os passos de compilação devem ser claros e repetitivos.\n\n2. Você deve saber exatamente o que foi executado durante o processo de compilação.\n\n3. Cada compilação deve começar em um ambiente fresco, então uma construção comprometida não persiste para afetar futuras compilações.\n\n   ```\n          GitHub Actions pode ajudá-lo a cumprir com essas capacidades. As instruções de compilação são armazenadas no seu repositório, junto com seu código. Você escolhe o ambiente em que sua compilação é executada, incluindo Windows, Mac, Linux ou executores que você mesmo hospeda. Cada build começa com uma nova imagem do executor, o que torna difícil para um ataque persistir no seu ambiente de build.\n   ```\n\nAlém dos benefícios de segurança, GitHub Actions permite disparar builds manualmente, periodicamente ou em eventos do Git em seu repositório para builds de forma frequente e rápida.\n\n```\n          GitHub Actions é um grande tópico, mas um bom lugar para começar é [AUTOTITLE](/actions/learn-github-actions/understanding-github-actions), bem como [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#choosing-github-hosted-runners) e [AUTOTITLE](/actions/using-workflows/triggering-a-workflow).\n```\n\n## Gerar atestados de artefatos para suas compilações\n\nOs atestados de artefatos permitem que você crie garantias de procedência e integridade infalsificáveis para o software que você cria. Por sua vez, as pessoas que consomem seu software podem verificar onde e como seu software foi criado.\n\nAo gerar atestados de artefato com seu software, você cria declarações assinadas criptograficamente que estabelecem a procedência do build e incluem as seguintes informações:\n\n* Um link para o fluxo de trabalho associado ao artefato\n* O repositório, a organização, o ambiente, o SHA de commit e o evento de gatilho do artefato\n* Outras informações do token OIDC usado para estabelecer a procedência. Para saber mais, confira [OpenID Connect](/pt/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect).\n\nVocê também pode gerar atestados de artefato que incluam uma SBOM (lista de materiais de software) associada. Associar suas compilações a uma lista de dependências de código aberto usadas nelas fornece transparência e permite que os consumidores cumpram os padrões de proteção de dados.\n\nOs atestados de artefato incluem uma assinatura sobre um artefato criado, juntamente com links para o código-fonte e instruções de compilação. Se você assinar sua compilação com atestados de artefato, não será necessário gerenciar seu próprio material para chave de assinatura.\nGitHub trata disso para você com a autoridade de assinatura que operamos.\n\nPara saber mais, confira [Usar atestados de artefatos para estabelecer a procedência de compilações](/pt/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds).\n\n## Assine suas compilações\n\nDepois que o processo de compilação estiver seguro, você deverá evitar que alguém altere o resultado final do processo de compilação. Uma ótima maneira de fazer isso é assinar suas compilações. Ao distribuir software publicamente, isso é frequentemente feito com um par de chaves de criptografia pública/privada. Você usa a chave privada para assinar a compilação e você publica sua chave pública para que os usuários do seu software possam verificar a assinatura na compilação antes de usá-lo. Se os bytes da compilação forem modificados, a assinatura não será verificada.\n\nA forma como exatamente você assina a sua compilação dependerá do tipo de código que você está escrevendo e dos seus usuários. Muitas vezes, é difícil saber como armazenar com segurança a chave privada. Uma opção básica aqui é usar GitHub Actions segredos criptografados, embora você precise ter cuidado para limitar quem tem acesso a esses GitHub Actions fluxos de trabalho.\nSe sua chave privada estiver armazenada em outro sistema acessível pela Internet pública (como o Microsoft Azure ou o HashiCorp Vault), uma opção mais avançada é autenticar com o OpenID Connect, para que você não precise compartilhar segredos entre sistemas. Se é o caso de sua chave privada só estar acessível de uma rede privada, outra opção é usar executores auto-hospedados para GitHub Actions.\n\nPara obter mais informações, consulte [Usar segredos em ações do GitHub](/pt/actions/security-guides/encrypted-secrets), [OpenID Connect](/pt/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect) e [Executores auto-hospedados](/pt/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners).\n\n## Usar versões imutáveis\n\nSe você estiver usando ativos de versão de outros projetos em seu sistema de build ou criando versões para seu próprio trabalho, deverá reduzir o risco de segurança garantindo que essas versões sejam imutáveis, o que significa que elas não poderão ser alteradas após a publicação. As versões imutáveis ajudam a evitar ataques de cadeia de fornecedores e alterações acidentais. Para saber mais, confira [Versões imutáveis](/pt/code-security/supply-chain-security/understanding-your-software-supply-chain/immutable-releases).\n\n## Reforçar a segurança para GitHub Actions\n\nHá muitas etapas adicionais que você pode tomar para proteger GitHub Actionsadicionalmente. Em particular, tenha cuidado ao avaliar fluxos de trabalho de terceiros, e considere usar `CODEOWNERS` para limitar quem pode fazer alterações nos seus fluxos de trabalho.\n\nPara saber mais, confira [Referência de uso seguro](/pt/actions/security-guides/security-hardening-for-github-actions) e [Referência de uso seguro](/pt/actions/security-guides/using-githubs-security-features-to-secure-your-use-of-github-actions).\n\n## Próximas etapas\n\n* ```\n          [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/end-to-end-supply-chain-overview)\n  ```\n\n* ```\n          [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-accounts)\n  ```\n\n* ```\n          [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-code)\n  ```"}