A mudança para modernizar as operações aumentará a demanda por segurança da cadeia de suprimentos de software

Não é surpresa que os aspectos de segurança da cadeia de fornecimento de software estejam ameaçados atualmente. Primeiro, o log4j chegou às notícias e fez com que todos corressem para mitigar a vulnerabilidade mais difundida e problemática na cadeia de suprimentos de software.

Mais recentemente, o Spring4Shell apareceu em nosso radar; mais uma vulnerabilidade introduzida pelo framework que está causando caos para as empresas que precisam lidar com a ameaça.

Então, foi um tanto agradável ver o GitHub introduzir novas funcionalidades visando a segurança da cadeia de suprimentos de software. Foi especialmente agradável depois de digerir o último relatório da Sonatype sobre o estado da cadeia de suprimentos de software , no qual eles forneceram estatísticas que deveriam assustar qualquer tecnólogo preocupado com segurança, não importa qual seja sua função. De nota:

• Existem 37 milhões de versões de componentes OSS disponíveis agora
• 29% dos projetos populares contêm pelo menos uma vulnerabilidade de segurança conhecida
• Aumento de 650% YoY em ataques cibernéticos direcionados a fornecedores de código aberto

Essas descobertas são particularmente preocupantes porque o relatório determinou que “o aplicativo moderno médio contém 128 dependências de código aberto ”.

Agora, você sabe que não sou fã de matemática, mas vamos fazer um pouco.

Na Estratégia de Aplicação do Estado de 2022 , encontramos várias estatísticas dignas de nota:

• Os aplicativos modernos (nativos de contêiner e móveis) representam em média 33% do portfólio de aplicativos corporativos
• Empresas de todos os setores mantêm um portfólio médio de aplicativos de cerca de 200 aplicativos

Portanto, 33% de 200 significa que uma empresa típica tem uma média de 66 aplicativos modernos em seu portfólio. Usando a média de dependência de código aberto da Sonatype, o que significa que a empresa média pode estar carregando o fardo de proteger 8448 dependências de código aberto diferentes. Agora, é quase certo que haja sobreposição entre os aplicativos. Aplicativos nativos de contêiner quase sempre compartilham o mesmo ambiente de orquestração de contêiner (o Kubernetes é o rei do COE atualmente) e, portanto, a carga é realmente menor em termos de dependências específicas, mas não no sentido de que cada uma dessas instâncias precisa ser atualizada no caso de uma vulnerabilidade.

Sem fazer mais contas, vamos todos concordar que proteger a cadeia de suprimentos de software hoje é uma tarefa significativa, dado o tamanho dos portfólios de aplicativos e a inclusão de dependências de código aberto.

A nova funcionalidade do GitHub ajuda a resolver isso ao “encontrar e bloquear vulnerabilidades que atualmente são exibidas apenas no rich diff de uma solicitação de pull”. Em outras palavras, ele se integra ao pipeline de CI/CD e verifica, em tempo real, vulnerabilidades conhecidas.

Legal. Essa não é uma capacidade incomum. O DevSecOps vem impulsionando esse tipo de movimento de segurança de “mudança para a esquerda” há anos. A maioria dos pipelines de CI/CD, independentemente das ferramentas, são capazes de executar verificações de segurança no código. No entanto, nem todos integram a capacidade de escanear vulnerabilidades conhecidas que podem estar profundamente ocultas em dependências ou ser o resultado de um erro lógico que não é tão fácil de detectar.

Agora, é claro que você deve incluir o máximo de segurança possível no pipeline de CI/CD para eliminar vulnerabilidades e erros que podem prejudicá-lo mais tarde. Mas não foi por isso que fizemos esse exercício.

SRE, Software e Segurança da Cadeia de Suprimentos

A razão pela qual eu destaco o problema com a cadeia de suprimentos de software existente é que ela só vai piorar à medida que as organizações modernizam as operações com abordagens SRE. Isso ocorre porque, em sua essência, as práticas de SRE dependem da automação que, como tenho certeza de que você sabe, depende de software e scripts, muitos dos quais são — espere por isso — de código aberto.

Na verdade, não deveria ser surpresa saber que muitas dessas ferramentas de código aberto usadas pelo DevOps serão usadas pelos SREs. Se você quiser simplificar as funções e o relacionamento, os SREs são DevOps para produção. Enquanto os profissionais de DevOps normalmente se concentram no pipeline de criação e lançamento de software, os SREs se concentram no pipeline de operações de software. Isso significa não apenas os aplicativos, mas também a segurança dos aplicativos e os serviços de entrega, bem como plataformas e ambientes (como núcleo, nuvem e borda). O escopo do pessoal de SRE abrange a pilha de TI, tornando sua tarefa significativamente mais difícil quando se trata de proteger a cadeia de suprimentos de software.

Basta dizer que a segurança da cadeia de fornecimento de software deve ser uma preocupação para todas as organizações porque afeta todo o ciclo de vida do aplicativo, do desenvolvimento à compilação, lançamento, implantação e operação.

E isso deve ser uma preocupação para organizações que esperam sobreviver à sua jornada de transformação digital. Há uma mudança significativa chegando às empresas em todos os lugares, e isso impacta o próprio coração da organização: a arquitetura empresarial.

A maioria das arquiteturas empresariais foi estabelecida há décadas, com base em estruturas desenvolvidas sob a premissa de que os recursos eram fixos e inflexíveis e que o data center era o foco do universo empresarial.

Nada disso é verdade mais e, mesmo que fosse, o negócio também mudou. Esse negócio agora é cada vez mais digital, e um negócio digital com processos orientados por dados não pode ser adequadamente representado por uma arquitetura projetada para representar um negócio físico com processos orientados por humanos. A arquitetura empresarial deve ser modernizada e, ao fazer isso, novos domínios devem ser incorporados, como o das operações de SRE.

E elas são. Nossa pesquisa deste ano descobriu que 37% das organizações já adotaram operações de SRE para modernizar aplicativos e operações, e outros 40% estão planejando fazer isso nos próximos 12 meses. Isso significa ferramentas e scripts, software e dados, e um conjunto completo de tecnologias que darão suporte a essa nova função dentro da organização.

E com software, scripts e pilhas vêm as cadeias de suprimentos e a segurança. E a única coisa que aprendemos com DevOps que você não pode ignorar ao modernizar as operações é que as práticas de SRE incorrerão em grande parte da mesma dívida técnica e desafios de segurança.

A boa notícia é que, diferentemente do DevOps e dos processos de construção, as operações de SRE serão uma nova prática para as organizações. E estabelecer novas práticas significa estabelecer novas formas de operar, incluindo a integração da segurança desde o início.