O DevSecOps integra decisões e evidências de segurança à entrega de software, em vez de tratá-las apenas como uma revisão final. Em um pipeline de integração contínua e entrega contínua (CI/CD) multicloud, a questão central não é qual nuvem executa a aplicação, mas sim qual componente pode alterar o código-fonte, executar o código de build, publicar um artefato ou chamar uma API de implantação do provedor. Essas capacidades definem o limite de segurança.
Para este curso, o contexto de provedores abrange AWS, Microsoft Azure e Google Cloud. Cada provedor possui seu próprio limite de recursos e identidades, enquanto um plano de controle de CI central coordena as definições do pipeline, o agendamento de jobs, as aprovações e o registro de resultados. Esta lição estabelece uma carga de trabalho delimitada para que, posteriormente, os controles possam ser avaliados em relação a identidades, artefatos e destinos de implantação concretos.
Uma revisão de segurança de um pipeline multicloud não pode começar enquanto não estiver claro quais partes estão no escopo, pois um runner ou um registro fora desse escopo pode alterar uma versão de lançamento (release) sem passar por revisão. O limite do pipeline é o conjunto de repositórios, serviços do plano de controle, runners, identidades, repositórios de artefatos e interfaces de implantação que participam da transformação de uma alteração em uma versão de lançamento. Ele começa quando uma alteração no repositório pode influenciar o comportamento do pipeline e estende-se até as ações da API do provedor que criam ou modificam a carga de trabalho. Requisições em tempo de execução (runtime) para a aplicação implantada estão fora desse limite, embora evidências posteriores possam vincular uma versão de lançamento ao comportamento em tempo de execução.
O plano de controle central, denominado ci-control, não está automaticamente dentro da AWS, do Azure ou do Google Cloud. Seus runners executam os jobs de build e implantação e, em seguida, autenticam-se separadamente na conta AWS dev, na assinatura Azure dev e no projeto Google Cloud orders-dev. Um runner passa a fazer parte do limite de um provedor apenas quando é hospedado nele. Sua localização altera a exposição de rede e os mecanismos de identidade disponíveis, mas não elimina a necessidade de autorização do provedor com escopo restrito.
Agora podemos identificar quais componentes cruzam o limite de cada provedor.
Um pipeline centralizado reduz a duplicação apenas quando seus controles são aplicados de forma consistente. A dispersão de credenciais (credential sprawl) ocorre quando muitos jobs, repositórios ou ambientes de provedores mantêm credenciais distintas de longa duração e com amplo acesso. Uma credencial de implantação vazada pode permanecer válida após o término do job que a utilizou, e o uso de uma credencial compartilhada impede que os registros de auditoria distingam uma execução de pipeline de outra. Credenciais de curta duração, geradas por execução, limitam tanto o tempo de vida útil quanto o escopo da implantação afetada.
Os controles de varredura também podem sofrer desvios. Uma varredura de vulnerabilidades com um limite de falha em um fluxo da AWS e um limite diferente em um fluxo do Azure ou Google Cloud não representa uma decisão de segurança unificada, mesmo que todos os fluxos utilizem a mesma ferramenta de varredura. O pipeline deve registrar o artefato avaliado, o conjunto de regras, o resultado da análise e a decisão do ponto de controle (gate). O log de um job bem-sucedido comprova apenas que o job relatou sucesso durante sua janela de execução registrada; isoladamente, isso não prova que todos os recursos no provedor correspondem agora ao estado desejado.
A cópia entre nuvens (cross-cloud) introduz outra fronteira. Uma imagem copiada entre registros pode ser substituída, copiada de forma incompleta ou promovida sob uma tag já conhecida. Tags identificam uma referência mutável, enquanto um digest identifica o conteúdo específico da imagem. A regra reutilizável consiste em autorizar cada ação do provedor de forma independente e manter as evidências do artefato exato em cada etapa de transferência.
A carga de trabalho em execução é a orders-api, um serviço que escuta na porta 8080. O código-fonte da aplicação reside no repositório orders-api-repo, enquanto as definições de infraestrutura estão no orders-infra-repo. Um processo de build gera a imagem de contêiner fictícia orders-api:1.0; as alterações de infraestrutura são avaliadas como a stack Terraform orders-infra. Manter os repositórios de código-fonte e de infraestrutura separados permite que controles subsequentes atribuam permissões distintas de revisão, execução e implantação para cada tipo de alteração.
A imagem é promovida para aws-ecr/orders-api, azure-acr/ordersapi e gcp-ar/orders-api e, em seguida, implantada por meio de ações de API específicas de cada provedor em seus respectivos ambientes de desenvolvimento. A promoção significa copiar o mesmo digest da imagem verificada para cada registro, e não reconstruir a imagem a partir do código-fonte para cada nuvem. A reconstrução criaria artefatos distintos cujos conteúdos e evidências poderiam divergir, apesar de compartilharem a mesma tag orders-api:1.0.
Podemos examinar os fluxos de artefatos e de infraestrutura que essa carga de trabalho torna explícitos.