Existe um ciclo virtuoso na tecnologia que expande os limites do que está sendo construído e de como está sendo usado. Um novo desenvolvimento tecnológico surge e captura a atenção do mundo. As pessoas começam a experimentar e descobrem novas aplicações, casos de uso e abordagens para maximizar o potencial da inovação. Esses casos de uso geram valor significativo, alimentando a demanda pela próxima iteração da inovação e por sua vez, uma nova onda de inovadores cria a próxima geração de casos de uso, impulsionando novos avanços.
A conteinerização tornou-se a base do desenvolvimento moderno de software nativo em nuvem, suportando novos casos de uso e abordagens para a construção de aplicativos resilientes, escaláveis e portáteis. Ela também contém as chaves para a próxima inovação em entrega de software, exigindo simultaneamente a evolução para um software seguro por design e continuamente atualizado, servindo como o meio para chegar lá.
Abaixo, falarei sobre algumas das inovações que levaram à nossa revolução conteinerizada, bem como algumas das características do desenvolvimento de software nativo em nuvem que levaram a esse ponto de inflexão — um ponto que preparou o mundo a se afastar das distribuições Linux tradicionais e adotar uma nova abordagem para a entrega de software de código aberto.
A iteração nos aproximou da ubiquidade
Muitas inovações abriram caminho para uma entrega de código aberto mais segura e eficiente. Para aproveitar seu tempo e minhas palavras, destacarei três marcos específicos. Cada etapa, desde os Contêineres Linux (LXC) até o Docker e, por fim a Iniciativa de Contêineres Abertos (OCI), foi construída sobre sua antecessora, abordando limitações e desbloqueando novas possibilidades.
O LXC lançou as bases, aproveitando os recursos do kernel Linux (ou seja, cgroups e namespaces) para criar ambientes leves e isolados. Pela primeira vez, os desenvolvedores puderam empacotar aplicativos com suas dependências, oferecendo um certo grau de consistência entre diferentes sistemas. No entanto, a complexidade do LXC para os usuários e a falta de um catálogo de distribuição de imagens padronizado dificultaram sua ampla adoção.
O Docker surgiu como um divisor de águas, democratizando a tecnologia de contêineres. Simplificou o processo de criação, execução e compartilhamento de contêineres, tornando-os acessíveis a um público mais amplo. A interface amigável do Docker e a criação do Docker Hub, um repositório central para imagens de contêineres, fomentaram um ecossistema vibrante. Essa facilidade de uso impulsionou a rápida adoção, mas também levantou preocupações sobre a dependência de fornecedores e a necessidade de interoperabilidade.
Reconhecendo o potencial de fragmentação, a OCI (Open Containers Initiative) interveio para padronizar formatos e tempos de execução de contêineres. Ao definir especificações abertas, a OCI garantiu que os contêineres pudessem ser construídos e executados em diferentes plataformas, promovendo um cenário competitivo e saudável. Projetos como runC e containerd, nascidos da OCI, forneceram uma base comum para tempos de execução de contêineres e possibilitaram maior portabilidade e interoperabilidade.
Os padrões OCI também permitiram que o Kubernetes (outro padrão independente de fornecedor) se tornasse uma plataforma verdadeiramente portátil, capaz de rodar em uma ampla gama de infraestruturas e permitindo que as organizações orquestrassem seus aplicativos de forma consistente em diferentes provedores de nuvem e ambientes locais. Essa padronização e as inovações associadas desbloquearam todo o potencial dos contêineres, abrindo caminho para sua presença onipresente no desenvolvimento de software moderno.
O software em contêineres está devorando o mundo
Os avanços no Linux, a rápida democratização de contêineres por meio do Docker e a padronização do OCI foram impulsionados pela necessidade, com a evolução dos casos de uso de aplicativos nativos em nuvem impulsionando a orquestração e a padronização. Essas características dos aplicativos nativos em nuvem também destacam por que uma abordagem de propósito geral para distribuições Linux não oferece mais aos desenvolvedores de software as bases mais seguras e atualizadas para desenvolver.
Arquitetura orientada a microsserviços: Aplicativos nativos em nuvem são normalmente desenvolvidos como um conjunto de pequenos serviços independentes, com cada microsserviço executando uma função específica. Cada um desses microsserviços pode ser desenvolvido, implantado e mantido de forma independente, o que proporciona enorme flexibilidade e resiliência. Como cada microsserviço é independente, os desenvolvedores de software não precisam de pacotes de software abrangentes para executar um microsserviço, contando apenas com o essencial dentro de um contêiner.
Conscientes do uso de recursos e eficientes: Os aplicativos nativos da nuvem são desenvolvidos para serem eficientes e conscientes do uso de recursos, minimizando a sobrecarga na infraestrutura. Essa abordagem simplificada se alinha naturalmente com contêineres e uma estratégia de implantação efêmera, com novos contêineres sendo implantados constantemente e outras cargas de trabalho sendo atualizadas com o código mais recente disponível. Isso reduz os riscos de segurança, aproveitando os pacotes de software mais recentes, em vez de esperar por patches e backports de distribuição.
Portabilidade: Os aplicativos nativos da nuvem são projetados para serem portáteis, com desempenho e confiabilidade consistentes, independentemente de onde o aplicativo esteja sendo executado. Graças à padronização do ambiente por contêineres, os desenvolvedores podem superar as antigas dores de cabeça do tipo “funcionou bem na minha máquina”.
O ciclo virtuoso da inovação que impulsiona novos casos de uso e por fim, novas inovações é evidente quando se trata de conteinerização e da ampla adoção de aplicativos nativos da nuvem. Fundamentalmente, esse ponto de inflexão entre inovação e demandas de casos de uso impulsionou uma taxa incrível de mudança no software de código aberto — chegamos a um ponto em que as desvantagens de segurança, desempenho e inovação das distribuições Linux tradicionais “congeladas no tempo” superam a familiaridade e a estabilidade percebida da última geração de entrega de software.
Então, como deve ser a próxima geração de entrega de software de código aberto?
Chainguard OS
Para atender às expectativas modernas de segurança, desempenho e produtividade, os desenvolvedores de software precisam do software mais recente, no menor formato possível, projetado para o seu caso de uso, sem nenhum dos CVEs que representam riscos para o negócio (e uma lista de “correções” das equipes de segurança). Atender a esses parâmetros exige mais do que apenas refazer o passado. Em vez disso, a próxima geração de entrega de software de código aberto precisa começar na fonte do software seguro e atualizado: os mantenedores upstream.
É por isso que a Chainguard desenvolveu essa nova abordagem sem distros, reconstruindo continuamente pacotes de software com base não nas distros downstream, mas nas fontes upstream que removem vulnerabilidades e adicionam melhorias de desempenho. Chamamos isso de Chainguard OS .
O Chainguard OS serve como base para os amplos resultados de segurança, eficiência e produtividade que os produtos Chainguard oferecem hoje, “Chainguarding” um catálogo em rápido crescimento de mais de 1.000 imagens de contêiner.
O Chainguard OS adere a quatro princípios-chave para tornar isso possível:
- Integração e entrega contínuas: enfatiza a integração, os testes e o lançamento contínuos de pacotes de software upstream, garantindo um pipeline de desenvolvimento simplificado e eficiente por meio da automação.
- Nano atualizações e reconstruções: favorece atualizações e reconstruções incrementais ininterruptas em vez de grandes atualizações de versão, garantindo transições mais suaves e minimizando mudanças disruptivas.
- Artefatos mínimos, reforçados e imutáveis: elimina o excesso de fornecedores desnecessários dos artefatos de software, tornando os pacotes secundários e extras opcionais para o usuário, ao mesmo tempo em que melhora a segurança por meio de medidas de reforço.
- Minimização Delta: mantém os desvios do upstream no mínimo, incorporando patches extras somente quando essencial e somente pelo tempo necessário até que uma nova versão seja cortada do upstream.
Talvez a melhor maneira de destacar o valor dos princípios do Chainguard OS seja ver o impacto nas imagens do Chainguard.
Na captura de tela abaixo (e que pode ser visualizada aqui ), você pode ver uma comparação lado a lado entre uma imagem externa <python:latest> e <cgr.dev/chainguard/python:latest> Chainguard.
Além da discrepância bastante clara na contagem de vulnerabilidades, vale a pena examinar a diferença de tamanho entre as duas imagens de contêiner. A imagem Chainguard representa apenas 6% da imagem alternativa de código aberto.
Junto com o tamanho minimizado da imagem, a imagem do Chainguard foi atualizada pela última vez apenas uma hora antes da captura de tela, algo que acontece diariamente:
Cada imagem do Chainguard é um exemplo prático do valor que o Chainguard OS oferece, oferecendo uma alternativa sólida ao que já existia. Talvez o maior indicador seja o feedback que recebemos dos clientes, que compartilharam como as imagens de contêiner do Chainguard ajudaram a eliminar CVEs, proteger suas cadeias de suprimentos, alcançar e manter a conformidade e reduzir o trabalho dos desenvolvedores, permitindo-lhes realocar recursos preciosos.
Acreditamos que os princípios e a abordagem do Chainguard OS podem ser aplicados a uma variedade de casos de uso, estendendo os benefícios dos pacotes de software continuamente reconstruídos a partir do código-fonte para uma parcela ainda maior do ecossistema de código aberto.
Se você achou isso útil, não deixe de conferir nosso whitepaper sobre o assunto ou entre em contato com nossa equipe para conversar com um especialista na abordagem distroless da Chainguard.
Observação: este artigo foi escrito e contribuído por Dustin Kirkland — vice-presidente de engenharia da Chainguard .
Fonte e imagens: https://thehackernews.com/2025/04/have-we-reached-distroless-tipping-point.html
