Não é de surpreender que, hoje em dia, os aspectos de segurança da cadeia de suprimentos de software estejam sob ameaça. Primeiro, o log4j ganhou destaque nas notícias e fez com que todos corressem para mitigar essa vulnerabilidade extremamente disseminada e problemática na cadeia de suprimentos de software.
Mais recentemente, o Spring4Shell surgiu em nosso radar — mais uma vulnerabilidade introduzida por um framework, causando transtornos para as empresas que precisam lidar com a ameaça.
Portanto, foi até certo ponto agradável ver o GitHub lançar uma nova funcionalidade voltada para a segurança da cadeia de suprimentos de software. Isso foi especialmente positivo depois de analisar o relatório mais recente da Sonatype sobre o estado da cadeia de suprimentos de software, no qual foram apresentadas estatísticas que deveriam assustar qualquer profissional de tecnologia preocupado com segurança, independentemente de sua função. Entre os destaques:
- Agora, há 37 milhões de versões de componentes de software de código aberto disponíveis
- 29% dos projetos populares contêm pelo menos uma vulnerabilidade de segurança conhecida
- Aumento de 650% em relação ao ano anterior nos ataques cibernéticos direcionados a fornecedores de código aberto
Essas constatações são particularmente preocupantes porque o relatório determinou que “uma aplicação moderna contém, em média, 128 dependências de código aberto.”
Agora, você sabe que não sou muito fã de fazer contas, mas vamos fazer algumas.
No relatório State of Application Strategy de 2022, encontramos várias estatísticas dignas de nota:
- Aplicações modernas (nativas de contêineres e móveis) representam, em média, 33% do portfólio de aplicações empresariais
- Empresas de todos os setores mantêm um portfólio médio de cerca de 200 aplicativos
Portanto, 33% de 200 significa que uma empresa típica tem, em média, 66 aplicações modernas em seu portfólio. Considerando a média de dependências de código aberto da Sonatype, isso significa que uma empresa típica pode ter de arcar com a responsabilidade de proteger 8.448 dependências de código aberto diferentes. É quase certo, porém, que haja sobreposição entre as aplicações. Aplicações nativas de contêiner quase sempre compartilham o mesmo ambiente de orquestração de contêineres (o Kubernetes é atualmente o líder entre os COEs). Assim, a carga é, na verdade, menor em termos de dependências específicas, mas não no sentido de que cada uma dessas instâncias precise ser atualizada caso surja uma vulnerabilidade.
Sem fazer mais cálculos, vamos apenas concordar que proteger a cadeia de suprimentos de software hoje é uma tarefa considerável, 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 esse problema ao “encontrar e bloquear vulnerabilidades que atualmente são exibidas apenas no rich diff de uma solicitação de pull”. Em outras palavras, ela se integra ao pipeline de CI/CD e verifica, em tempo real, a existência de vulnerabilidades conhecidas.
Legal. Esse não é um recurso incomum. Há anos, o DevSecOps vem impulsionando esse tipo de abordagem de segurança de “shift left”. A maioria dos pipelines de CI/CD, independentemente das ferramentas utilizadas, é capaz de realizar verificações de segurança no código. No entanto, nem todos incorporam a capacidade de procurar vulnerabilidades conhecidas que possam estar profundamente ocultas nas dependências ou resultar de um erro de lógica mais difícil de detectar.
Agora, é claro que você deve incorporar o máximo possível de segurança ao pipeline de CI/CD para eliminar vulnerabilidades e erros que podem acabar lhe causando problemas mais tarde. Mas não foi por isso que fizemos este exercício.
SRE, software e segurança da cadeia de suprimentos
O motivo pelo qual destaco o problema da atual cadeia de suprimentos de software é que ele só tende a piorar à medida que as organizações modernizam suas operações com abordagens de SRE. Isso porque, em sua essência, as práticas de SRE dependem da automação que, como você certamente sabe, depende de softwares e scripts, muitos dos quais são — pasme — de código aberto.
Na verdade, não deveria ser surpresa saber que muitas dessas ferramentas de código aberto usadas por profissionais de DevOps também serão utilizadas por SREs. Para simplificar as funções e a relação entre elas, os SREs são o DevOps da produção. Enquanto os profissionais de DevOps normalmente se concentram no pipeline de compilação e lançamento de software, os SREs se concentram no pipeline de operações de software. Isso inclui não apenas os aplicativos, mas também os serviços de segurança e entrega de aplicativos, além de plataformas e ambientes (como núcleo, nuvem e borda). A atuação dos profissionais de SRE abrange toda a pilha de TI, o que torna 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 suprimentos de software deve ser uma preocupação para todas as organizações, pois afeta todo o ciclo de vida das aplicações — do desenvolvimento à compilação, passando pelo lançamento e pela implantação, até a operação.
E isso deve ser motivo de preocupação para as organizações que esperam sobreviver à sua jornada de transformação digital. Uma mudança significativa está chegando às empresas em todo o mundo e afetará o próprio coração da organização: a arquitetura empresarial.
A maioria das arquiteturas empresariais foi estabelecida décadas atrás, com base em frameworks desenvolvidos sob a premissa de que os recursos eram fixos e inflexíveis e de que o data center era o centro do universo dos negócios.
Nada disso é mais verdade e, mesmo que fosse, a empresa também mudou. Agora, ela está cada vez mais digital, e uma empresa digital com processos orientados por dados não pode ser representada adequadamente por uma arquitetura projetada para representar uma empresa física com processos conduzidos por pessoas. A arquitetura corporativa precisa ser modernizada e, nesse processo, novos domínios precisam ser incorporados, como o das operações de SRE.
E é isso que estão fazendo. Nossa pesquisa deste ano constatou que 37% das organizações já adotaram operações de SRE para modernizar aplicações e operações, e outras 40% planejam fazer isso nos próximos 12 meses. Isso inclui ferramentas e scripts, software e dados, além de toda uma pilha de tecnologias que dará suporte a essa nova função dentro da organização.
E, com softwares, scripts e stacks, vêm também as cadeias de suprimentos e a segurança. E uma coisa que aprendemos com o DevOps e que você não pode ignorar ao modernizar as operações é que as práticas de SRE acarretarão grande parte da mesma dívida técnica e dos mesmos desafios de segurança.
A boa notícia é que, diferentemente do DevOps e dos processos de build, as operações de SRE serão uma prática nova para as organizações. E estabelecer novas práticas significa definir novas formas de operar — incluindo a incorporação da segurança desde o início.
Sobre o autor
Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.
Mais publicações de Lori Mac VittiePublicações relacionadas no blog
O estado da maturidade digital empresarial: a transformação digital ainda não terminou
Explore como a IA impacta as empresas, as aplicações da IA generativa, as estratégias para modernizar as operações de TI e os benefícios da maturidade digital com a F5.
Como a IA generativa acelera a transformação digital
Veja como a IA generativa impulsiona a transformação digital nas empresas, acelerando tendências como a integração de APIs, os desafios dos modelos operacionais de TI híbrida e a adoção de AIOps.
Seis capacidades técnicas para acelerar a transformação digital
As arquiteturas empresariais atuais carecem dos fatores necessários de agilidade, escalabilidade, segurança e observabilidade, essenciais para impulsionar a mudança tecnológica. No entanto, estas seis capacidades fundamentais ajudarão as empresas a gerenciar riscos e desafios ao longo de sua transformação digital.
Inverter a API é a transformação digital de que as empresas precisam para participar e competir em uma economia de APIs
As organizações detêm um valor latente — na forma de APIs internas — que precisam explorar para competir em uma economia de APIs. Embora os desafios técnicos e de segurança possam desestimular algumas delas, as empresas precisam reconhecer que inverter suas APIs permitirá liberar o valor da organização como plataforma.
A modernização da TI começa pela infraestrutura
O hardware e o software evoluíram rapidamente desde os primórdios da internet, mas, para aproveitar ao máximo os benefícios resultantes dessa evolução, as organizações precisam avaliar e modernizar sua infraestrutura e a entrega de aplicativos. Acelere os esforços de modernização com a nova F5 rSeries.