0
0
A capacidade das organizações de obter valor do Kubernetes – e, de forma mais ampla, da tecnologia nativa da nuvem – está sendo prejudicada por preocupações com a segurança. Uma das maiores preocupações reflete um dos maiores desafios atuais do setor: proteger a cadeia de suprimentos de software.
O ” 2023 State of Kubernetes Report ” da Red Hat descobriu que a segurança do Kubernetes está em questão em algumas empresas. Com base em uma pesquisa com profissionais de DevOps, engenharia e segurança de todo o mundo, o relatório revela que 67% dos entrevistados atrasaram ou desaceleraram a implantação devido a preocupações com a segurança do Kubernetes, 37% tiveram receita ou perda de clientes devido a um contêiner/Kubernetes incidente de segurança e 38% citam a segurança como uma das principais preocupações com as estratégias de contêineres e Kubernetes.
A cadeia de suprimentos de software tem sido cada vez mais criticada, e as lojas Kubernetes estão sentindo o calor. Quando perguntados com quais problemas específicos de segurança da cadeia de suprimentos de software eles estavam mais preocupados, os entrevistados da pesquisa da Red Hat observaram:
- Componentes de aplicativos vulneráveis (32%)
- Controles de acesso insuficientes (30%)
- Falta de listas de materiais de software (SBOM) ou proveniência (29%)
- Falta de automação (29%)
- Falta de auditabilidade (28%)
- Imagens de contêiner inseguras (27%)
- Aplicação de política inconsistente (24%)
- Pontos fracos do pipeline de CI/CD (19%)
- Modelos IaC inseguros (19%)
- Pontos fracos do controle de versão (17%)
Essas preocupações parecem bem fundamentadas entre os entrevistados, com mais da metade observando que eles têm experiência em primeira mão com quase todos eles – especialmente componentes de aplicativos vulneráveis e pontos fracos do pipeline de CI/CD.
Há muita sobreposição entre esses problemas, mas as organizações podem minimizar as preocupações sobre todos eles concentrando-se em uma coisa: conteúdo confiável.
A capacidade de confiar no conteúdo está se tornando cada vez mais desafiadora à medida que mais e mais organizações usam código-fonte aberto para desenvolvimento nativo da nuvem. Mais de dois terços do código do aplicativo são herdados de dependências de código aberto, e confiar nesse código é fundamental para aumentar a segurança do aplicativo e da plataforma e, por extensão, obter o máximo valor da plataforma de orquestração de contêineres.
De fato, as organizações não podem criar produtos e serviços confiáveis, a menos que/até que possam confiar no código usado para criá-los. Listas de materiais de software são projetadas para ajudar a garantir a proveniência do código, mas não devem ser usadas isoladamente. Em vez disso, os SBOMs devem ser considerados como parte de uma estratégia multifacetada para proteger a cadeia de suprimentos de software, com conteúdo confiável no centro.
Nenhum SBOM é uma Ilha
Os SBOMs fornecem as informações de que os desenvolvedores precisam para tomar decisões informadas sobre os componentes que estão utilizando. Isso é especialmente importante porque os desenvolvedores extraem de vários repositórios e bibliotecas de código aberto para criar aplicativos. No entanto, a própria existência de um SBOM não garante a integridade. Por um lado, um SBOM é tão benéfico quanto atualizado e verificável . Por outro lado, listar todos os componentes de um software é apenas o primeiro passo. Depois de conhecer os componentes, você precisa determinar se há problemas conhecidos para esses componentes.
Os desenvolvedores precisam de informações iniciais de qualidade e segurança sobre os componentes de software que estão selecionando. Provedores de software e consumidores devem se concentrar em compilações curadas e bibliotecas de código aberto reforçadas que foram verificadas e atestadas com verificações de proveniência. A tecnologia de assinatura digital desempenha um papel importante na garantia de que um artefato de software não foi alterado de forma alguma durante o trânsito do repositório público para o ambiente do usuário final.
É claro que, mesmo com tudo isso instalado, as vulnerabilidades acontecem. E, devido ao grande número de vulnerabilidades identificadas em todo o conjunto de desenvolvedores de software, informações adicionais são necessárias para ajudar as equipes a avaliar o impacto real de uma vulnerabilidade conhecida.
Problemas de VEX
Algumas questões têm um impacto maior do que outras. É aí que entra o VEX — ou Vulnerability Exploitability eXchange. Por meio de um documento VEX legível por máquina, os provedores de software podem relatar a capacidade de exploração de vulnerabilidades encontradas nas dependências de seus produtos — de maneira otimizada, usando sistemas de notificação e análise de vulnerabilidades proativos e automatizados.
Observe que o VEX vai além de fornecer dados e status de vulnerabilidade; também inclui informações de exploração. O VEX ajuda a responder à pergunta: esta vulnerabilidade foi explorada ativamente? Isso permite que os clientes priorizem e gerenciem com eficiência a correção. Algo como o Log4j justificaria uma ação imediata, por exemplo, enquanto uma vulnerabilidade sem uma exploração conhecida pode esperar. Decisões adicionais de priorização podem ser feitas com base na determinação se um pacote está presente, mas não usado ou exposto.
Atestado: A terceira perna do banquinho
Além dos SBOMs e da documentação VEX, a atestação do pacote é necessária para gerar confiança no conteúdo.
Você precisa saber que o código que está usando foi desenvolvido, selecionado e construído com princípios de segurança em mente e fornecido com os metadados necessários para verificar a proveniência e o conteúdo. Quando documentos SBOMs e VEX são fornecidos, você tem uma maneira de mapear vulnerabilidades conhecidas para componentes de software no pacote que está avaliando, sem a necessidade de executar um scanner de vulnerabilidade. Quando assinaturas digitais são usadas para atestado de pacotes e metadados associados, você tem uma maneira de verificar se o conteúdo não foi adulterado em trânsito.
Conclusão
Os padrões, as ferramentas e as práticas recomendadas mencionadas se alinham (e complementam) ao modelo DevSecOps e ajudarão muito a aliviar as preocupações de segurança que andam de mãos dadas com o ritmo rápido de implantação que o Kubernetes permite.
FONTE: DARKREADING