{"meta":{"title":"Imposição de configuração de segurança","intro":"Entenda as complexidades da implementação de security configurations.","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/reference","title":"Referência"},{"href":"/pt/code-security/reference/security-at-scale","title":"Segurança em escala"},{"href":"/pt/code-security/reference/security-at-scale/security-configuration-enforcement","title":"Imposição de configuração de segurança"}],"documentType":"article"},"body":"# Imposição de configuração de segurança\n\nEntenda as complexidades da implementação de security configurations.\n\nSecurity configurations podem ser impostos, o que significa que os proprietários do repositório não podem alterar o status de habilitação dos recursos habilitados ou desabilitados pela configuração.\n\n## Situações que interrompem a imposição\n\nAlgumas situações podem interromper a aplicação de security configurations. Por exemplo, a ativação do code scanning não se aplicará a um repositório se:\n* GitHub Actions é inicialmente habilitado no repositório, mas depois é desativado no repositório.\n* GitHub Actions exigidas pelas configurações do code scanning não estão disponíveis no repositório.\n* Executores auto-hospedados com o rótulo `code-scanning` não estão disponíveis.\n* A definição de quais idiomas não devem ser analisados usando a configuração padrão do code scanning é alterada.\n\n## Imposição e a API REST\n\nSe um usuário em sua organização ou empresa tentar alterar o status de habilitação de um recurso em uma configuração imposta usando a API REST, a chamada à API parecerá bem-sucedida, mas nenhum status de habilitação será alterado."}