Entre as várias ferramentas no portfólio da Kaspersky está uma plataforma dedicada para proteger ambientes em contêineres. Mas nesta postagem, quero falar sobre o Kaspersky Container Security (KCS), não como um representante do fornecedor, mas como membro de uma equipe que usa ativamente essa solução em sua rotina de trabalho. Nossa Equipe de Segurança de Produto é responsável por estabelecer processos de desenvolvimento seguros em toda a empresa. Estamos envolvidos em todas as etapas do ciclo de vida de desenvolvimento de software, e nossa prioridade é ajudar as equipes de produto a detectar problemas de segurança com antecedência para que possam cumprir o cronograma de seus lançamentos. Para isso, criamos vários fluxos de trabalho, um dos quais se concentra especificamente na segurança do contêiner. É nesse contexto que contamos com nossa própria plataforma Kaspersky Container Security.
As soluções de segurança para contêineres geralmente são vistas principalmente como verificadores de imagens para registros de contêineres. No entanto, o Kaspersky Container Security (KCS) é uma plataforma de segurança mais abrangente para ambientes de contêiner que lida com várias tarefas em virtude de sua integração de ponta a ponta no fluxo de trabalho do contêiner. Embora certamente inclua um cenário de verificação do contêiner, o que é inegavelmente importante, nossa experiência com o KCS mostrou que seu valor real se torna aparente quando ele é integrado em vários pontos ao longo do fluxo de trabalho de uma só vez:
Em sua essência, o processo é padrão. O KCS verifica as imagens em busca de problemas comuns em contêineres: vulnerabilidades conhecidas, malware, segredos codificados diretamente no código (hardcoded) e configurações incorretas. No entanto, o resultado da verificação não é apenas um veredicto único e abstrato. O sistema calcula uma classificação de risco com base nas descobertas, fornecendo uma imagem clara da postura de segurança do ativo. Na prática, isso é incrivelmente útil porque as equipes não veem apenas uma mensagem de “imagem ruim”; elas obtêm um detalhamento claro do que está de fato gerando o risco e do que precisa ser corrigido primeiro.
Mas isso não é tudo. O KCS funciona bem para cenários em que não é suficiente apenas encontrar um problema: é necessário vinculá-lo ao ciclo de vida do artefato. Quando uma equipe gerencia centenas de compilações, a verificação periódica do registro não é suficiente e quase sempre requer intervenção manual. É preciso saber qual pipeline introduziu o risco, quais políticas foram acionadas e quais são as próximas etapas. O KCS fornece esse vínculo essencial.
Uma característica menos conhecida do KCS é seu recurso de verificação em grande escala dentro de pipelines de CI/CD. Para nossa equipe, essa é a maneira mais eficaz de usar o KCS. A lógica é direta: você integra o verificador no pipeline e os resultados da verificação aparecem diretamente nos logs de execução. Eles também são enviados para o console central da solução, onde são registrados em uma seção de CI/CD dedicada que vincula as descobertas ao nome do artefato, horário de verificação, pipeline e nível de gravidade.
Em um ambiente de CI/CD, é possível verificar imagens de arquivos compactados TAR ou diretamente de repositórios Git. Pronto para uso, é compatível com GitLab, Jenkins, TeamCity e GitHub Actions; na prática, o KCS pode ser integrado em qualquer orquestrador de pipeline.
Outro aspecto crítico do uso do KCS no CI/CD envolve as políticas de segurança. Nossa solução usa um modelo em que as políticas permitem não apenas coletar resultados, mas também controlar o comportamento do próprio pipeline. Isso é útil para implementações em fases. Você pode iniciar no modo de auditoria e, em seguida, avançar gradualmente para compilações com falha quando forem detectados segredos, configurações incorretas críticas ou vulnerabilidades. Essa abordagem evolutiva geralmente funciona melhor do que simplesmente apertar um botão para bloquear tudo de uma vez.
Executamos nosso próprio sistema de análise de composição, portanto, não tratamos o KCS como uma fonte de verdade única. Em vez disso, serve como uma poderosa camada extra em nossos fluxos de trabalho, e é nesse aspecto que ele entrega mais valor.
Enquanto nosso sistema interno de análise de composição lida com rastreamento de componentes, dependências e avaliação de risco em nível de código, o KCS se destaca na proteção do perímetro do contêiner. Ele cuida da verificação técnica de imagens e da segurança de CI/CD, ao mesmo tempo em que agrega relatórios sobre artefatos de contêiner. Não entra em conflito com nossa análise interna; ele a reforça exatamente no ponto em que os contêineres recebem cargas de trabalho reais.
Isso é particularmente útil para nós em dois cenários. Primeiro, ele fornece controle de artefatos em estágio inicial durante o desenvolvimento. Em segundo lugar, ele atua como um gatekeeper durante o aprovação de versão. Não debatemos mais os riscos algum tempo depois do lançamento; nós os detectamos no ponto exato em que a equipe ainda pode corrigir rapidamente um Dockerfile, um gráfico do Helm ou um conjunto de configurações sem uma longa cadeia de aprovação.
O modo como ele lida com uma lista de materiais de software (SBOM) também merece destaque. Nosso sistema depende principalmente de SBOMs relevantes e atualizados. O KCS oferece modos específicos para o processamento de SBOMs e pode até mesmo gerar resultados de verificação no mesmo formato. Nesse sentido, o KCS se integra perfeitamente aos nossos processos internos, permitindo incorporá-lo aos nossos fluxos de trabalho existentes, em vez de precisarmos adaptar nossos fluxos a ele.
Sua outra camada poderosa é a segurança do cluster. Neste estágio, o KCS evolui para além de ser apenas uma ferramenta de verificação de imagens. Ele apresenta políticas de tempo de execução para contêineres e nós, modos de auditoria e bloqueio, além de um conjunto de perfis de segurança. Em termos práticos, isso significa que o KCS pode ser usado não apenas para encontrar vulnerabilidades em uma imagem, mas também para monitorar o que o contêiner está realmente fazendo quando ativo. As políticas podem considerar a proveniência da imagem, assinaturas digitais, restrições de recursos e volumes, bem como até mesmo os processos e as conexões de rede em execução dentro do contêiner.
Quando um problema é detectado, você tem a opção de registrar os resultados no modo de auditoria primeiro, em vez de bloquear o processo imediatamente. Em ambientes de produção, essa é sempre a decisão mais inteligente. Outra ferramenta vital é garantir a procedência confiável das imagens. O KCS é compatível com a verificação de assinatura digital, o que muda o foco de simplesmente encontrar CVEs para proteger toda a cadeia de fornecimento de software da empresa.
O KCS faz mais do que apenas exibir os problemas que detecta; ele serve como uma fonte abrangente de relatórios. Ele pode gerar relatórios sobre imagens, riscos aceitos e benchmarks do Kubernetes.
Os relatórios gerados estão disponíveis nos formatos HTML, PDF, CSV, JSON e XML, com compatibilidade específica para SARIF em relatórios detalhados, o que é ideal para integração em fluxos de trabalho AppSec. Quanto aos SBOMs mencionados acima, os cenários de verificação podem gerar artefatos e resultados nos formatos CycloneDX e SPDX, facilitando a conexão a processos existentes.
Para simplificar, o KCS complementa nossos fluxos de trabalho perfeitamente: não porque resolve todos os problemas, mas porque se integra de forma muito eficaz aos cenários de engenharia.
Também valorizamos o fato de que a equipe do produto considera o nosso feedback. A equipe do KCS realmente incorpora nossas solicitações operacionais práticas em seu roteiro de desenvolvimento. Por exemplo, a integração profunda do SBOM e os tipos de relatório específicos foram adicionados ao KCS como resultado direto de nossa experiência prática.
Em resumo, quando integrado corretamente, o Kaspersky Container Security ajuda a abranger várias áreas ao mesmo tempo: desde a verificação básica de contêineres até CI/CD e segurança de clusters. Em nossa experiência, ele fornece valor real em um ecossistema de contêiner ativo. Saiba mais sobre a solução na página oficial do KCS.
The software supply chain has become one of the most attractive targets for modern adversaries, but the attacks seen in 2025 did not focus solely on poisoning dependencies or hijacking packages. Increasingly, attackers are targeting the infrastructure that powers the software delivery lifecycle itself.
Build servers, CI/CD runners, package managers, and developer workstations all sit inside an organization’s trusted delivery path. They are designed to execute code automatically, often with elevated privileges, and to move artifacts through the environment without scrutiny. Those same design principles make them ideal attack surfaces. Once an adversary gains access to this trusted infrastructure, malicious activity can blend seamlessly into legitimate build and release workflows.
Now, adversaries are increasingly adopting “shift-left” tactics to subvert build runners, poison development dependencies, and weaponize automation tools before code can even reach a production server. Instead of breaching the perimeter and forcing malware inward, attackers are compromising the systems that organizations inherently trust to deliver software. The result is a class of intrusion that is harder to detect, faster to scale, and capable of bypassing traditional security controls by abusing automation itself.
Build servers and runners are high-value targets because they routinely execute privileged actions. They compile code, pull dependencies, move artifacts, and deploy software – all activities that mirror the behavior of an attacker attempting to establish persistence or distribute malware.
Threat actors have recognized that compromising build infrastructure gives them an opportunity to weaponize trust. In one case, attackers exploited a vulnerable self-hosted TeamCity server and remained undetected for more than a year. After gaining access, they created a benign-looking build configuration that was executed by a trusted build agent running with SYSTEM privileges. That build job then deployed a backdoor into internal environments.
Since the malicious code was delivered through a legitimate CI/CD task, it appeared indistinguishable from normal operational activity. No suspicious external binary was introduced, no obvious malware delivery mechanism was observed, and the deployment path blended into routine release workflows. This kind of attack points to the core challenge defenders face: In CI/CD environments, malicious behavior often looks exactly like expected behavior.
Pipeline compromise does not always require direct malware execution on the build server. In many cases, attackers simply manipulate automation workflows to make the organization’s own tools carry out the intrusion.
One observed intrusion, noted in this year’s Annual Threat Report, involved the compromise of a GitLab service account token. The attacker used the token to create projects containing malicious Ansible playbooks, which were then automatically executed by the organization’s CI/CD pipeline. The build system treated the attacker’s commands as authorized automation, effectively turning the deployment pipeline into the orchestration mechanism for the compromise. This is what makes CI/CD subversion so dangerous. Rather than needing to evade the build process, the attacker simply inherits it.
Once inside the pipeline, the adversary gains the same benefits as the automation itself. This includes trusted execution, access to internal resources, and the ability to move laterally under the guise of legitimate activity. Traditional security tools often struggle to distinguish malicious pipeline actions from expected operational tasks, especially when those tasks are executed under valid service identities.
Some of the most effective “shift-left” attacks in 2025 targeted the developers themselves, bypassing the targeting of target code or infrastructure first. Campaigns like Contagious Interview used fraudulent job offers to compromise developers working in cryptocurrency and blockchain sectors. Victims were directed to fake skill-assessment sites where they encountered fabricated technical errors and were instructed to run commands to “fix” the issue. Those commands silently deployed malware on the developer’s workstation. This approach gave attackers direct access to the developer’s local environment, including SSH keys, repository access, tokens, and credentials. From there, the path into source code repositories and CI/CD systems became significantly easier.
By compromising the human operators behind the development process, attackers gain access at the earliest stage of the software lifecycle – what might be the ultimate “shift left” advantage. Instead of attacking production systems, they infiltrate the environments where software is built, tested, and trusted. This reinforces an important reality in which the software pipeline extends beyond infrastructure. Developers, maintainers, and service accounts are all part of the attack surface.
Another growing tactic is the unauthorized registration of attacker-controlled systems as legitimate build runners. In the Sha1-Hulud campaign, malware infected systems and registered them as self-hosted GitHub runners under attacker-defined names. These rogue runners were then able to execute build tasks as trusted participants in the CI/CD process.
This is especially dangerous because self-hosted runners are often granted broad access to repositories, secrets, and deployment workflows. Once a malicious runner is registered, the attacker gains persistent, authorized access inside the development pipeline without needing to repeatedly exploit vulnerabilities.
The campaign also used malicious workflow triggers to ensure persistence. Certain workflows were designed to execute code when a user posted a comment in a repository discussion, turning routine collaboration features into execution mechanisms. Attackers no longer hijack the builds, opting instead to embed themselves into the development lifecycle in modern CI/CD compromise tactics.
While build infrastructure attacks surged, dependency poisoning remained a critical vector in 2025. Attackers published malicious versions of popular build packages that executed reconnaissance scripts during installation. These scripts harvested tokens, inspected environments, and in some cases targeted locally hosted AI systems.
In parallel, attackers used phishing to compromise trusted maintainer accounts, allowing them to append malicious code to legitimate package updates. As the updates originated from verified accounts and trusted repositories, they passed through normal review channels undetected.
Malicious code inherits the trust of the source that delivers it is now one of the defining characteristics of modern supply chain compromise. When dependencies, runners, and build jobs are all trusted by default, attackers only need to compromise one link in the chain to gain access to the entire pipeline.
The core difficulty in defending CI/CD infrastructure is that standard build activity inherently resembles malicious behavior. Compiling binaries, downloading packages, invoking scripts, opening network connections, and moving artifacts are normal actions in a build environment. These same actions are also hallmarks of compromise. That overlap creates a blind spot. If a malicious job executes under a valid service account on a trusted runner, the behavior may appear legitimate unless the account performs actions that clearly deviate from its role.
This means traditional detection models based on signatures or isolated indicators are insufficient. Defenders need visibility into context – who created the job, what changed, where the runner was registered, what secrets were accessed, and whether the workflow deviates from expected patterns. The challenge is no longer identifying malware alone. It is verifying the integrity of every automated action across the pipeline.
The solution to CI/CD subversion is removing implicit trust from the automation process. Every build runner, dependency, script, and service identity should be continuously verified. Security teams need to know when new runners are registered, when build configurations change unexpectedly, when secrets are introduced into workflows, and when jobs exhibit suspicious runtime behavior.
This starts with strong dependency integrity controls such as Software Bills of Materials (SBOMs) to detect unauthorized package changes. It extends to secrets hygiene practices that identify exposed credentials in repositories and pipeline configurations.
Build runners should be treated as high-value systems, monitored for suspicious child processes, credential access attempts, reverse tunnels, and persistence mechanisms. Unauthorized registrations or unusual runner names should trigger immediate investigation.
Equally important is behavioral monitoring for build jobs themselves. New or modified pipelines created by service accounts, jobs interacting with unfamiliar repositories, or workflows that establish network tunnels should all be treated as potential indicators of compromise. The objective is to ensure that trust is earned continuously, not granted automatically.
CI/CD pipelines have become one of the most strategically valuable targets in enterprise environments. They sit at the intersection of source code, secrets, automation, and deployment. A compromise at this layer gives attackers privileged access to the entire software delivery chain. The attacks that continue to make news headlines show that adversaries understand this well. They are exploiting build infrastructure, abusing automation workflows, hijacking developer trust, and embedding themselves directly into the software lifecycle.
For defenders, this means the security model must evolve. Protecting the pipeline requires treating automation infrastructure as critical security infrastructure, applying runtime protection to build agents, verifying the integrity of dependencies, and continuously monitoring every workflow for signs of abuse. The era of implicit trust in CI/CD is over. The organizations that adapt will be the ones that recognize a fundamental truth: In modern software delivery, the pipeline is part of the perimeter – and attackers are already inside it.
Third-Party Trademark Disclaimer:
All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.
In 2025, the enterprise risk landscape experienced a paradigm shift: the adoption of AI and LLMs officially becoming the primary driver of cloud risk. Today, almost 88% of organizations now leverage AI in at least one business function. With this level of integration, the risk of AI is now outpacing traditional security guardrails, culminating in a highly complex and interconnected attack surface.
SentinelOne’s® new AI and Cloud Verified Exploit Paths and Secrets Scanning Report examines this evolving threatscape and draws on telemetry from over 11,000 anonymized customer environments to offer deeper visibility into how threat actors are actively exploiting modern cloud and AI infrastructures.
A primary finding of the 2026 report is the rising proliferation of AI-specific credentials. The data indicates that AI-related secrets — such as OpenAI API Keys, Azure OpenAI API Keys, and others — increased by approximately 140% in a span of one year. This growth correlates directly with the rapid embedding of AI technologies into customer support systems, internal tooling, financial platforms, and product experiences.
Ubiquitous deployment has generated a widespread organizational pattern known as “shadow AI” – the unsanctioned use of AI tools in an environment without formal IT approval or security oversight. In practice, this occurs when developers or internal teams utilize unmanaged or personal LLM keys to process corporate data outside of sanctioned IT or security channels. Since these AI integrations span numerous internal applications, the same API keys are frequently duplicated and stored within code repositories, SaaS configurations, and development scripts. Compounding this, these credentials are often implemented without proper access controls or routine rotation schedules.
The sprawl of these credentials renders them difficult to track via standard secrets management protocols, establishing a requirement for more centralized governance over how AI keys are issued and utilized.
Unlike traditional cloud credentials that primarily facilitate resource manipulation, the compromise of AI keys introduces unique risk vectors. AI services frequently operate at the intersection of various enterprise systems, including CRM platforms, ticketing systems, and analytics tools, which means a single compromised LLM API key can provide an attacker with broad visibility into diverse datasets. The risks associated are categorized with exposed AI keys into two primary areas:
While AI credentials represent a novel attack surface, the traditional cloud secrets landscape has concurrently grown more complex. In 2025, organizations exposed approximately twice as many types of critical secrets as they did in 2024. This diversification spans AI platforms, cloud providers, SaaS services, and payment processors, pointing to how a single compromise can result in a broader blast radius across revenue-generating systems and infrastructure.
High-privilege cloud provider keys associated with AWS, Azure, and GCP remain the primary anchor of critical risk. The exposure of these keys can facilitate complete account takeover, infrastructure manipulation, and large-scale data exfiltration. As well, the exposure of payment gateway keys, such as those for Stripe and Razorpay, expands the potential damage by putting Personally Identifiable Information (PII) and financial data at risk, enabling the direct abuse of payment workflows.
Repository and CI/CD tokens also introduce supply chain risks, where high-severity credentials like a GITHUB_TOKEN can grant attackers direct access to deployment pipelines and source code, allowing a localized leak to escalate into a systemic infrastructure incident. From a collective standpoint, secrets exposure is exponentially spanning payments, coding, and software development workflows, making risk an interconnected and complex challenge.
To evaluate how these exposed secrets translate into practical risks, the SentinelOne researchers leveraged the Offensive Security Engine (OSE)
to generate Verified Exploit Paths. This technology analyzes misconfigurations, vulnerabilities, and exposed secrets in context to determine realistic exploitability.
The telemetry demonstrates that attackers generally do not rely on highly complex, theoretical attack chains. Instead, threat actors consistently exploit recurring entry points, specifically targeting misconfigured external services and widely abused Common Vulnerabilities and Exposures (CVEs). Notably, legacy vulnerabilities remain highly prevalent across customer environments and serve as reliable initial access points. The top verified exploit paths continue to involve older, critical CVEs, including:
Since these vulnerabilities are public and well-documented, threat actors possess proven techniques and automated tooling to exploit them whenever they persist in production environments. Once initial access is achieved through these legacy vulnerabilities, attackers routinely follow reachable secrets to pivot into additional services, such as utilizing an exposed key found in a cloud bucket to access an AI assistant, and subsequently, the customer data it processes.
Addressing the interconnected risks of AI integration and cloud secrets requires a structured, objective approach to security architecture. The report outlines several concrete capabilities and practices including:
As AI systems are increasingly built atop existing cloud, payment, and CI/CD platforms, weaknesses in traditional credentials inevitably become weaknesses in the AI infrastructures that rely upon them. The full report provides complete datasets and comprehensive exploit path models allowing today’s security teams to align their internal security policies with the realities of current threat actor behaviors. Learn more about the objective metrics behind the latest wave of credential exposure and vulnerability exploitation to establish more resilient and fully-controlled infrastructure architectures.
Third-Party Trademark Disclaimer:
All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.
Over the past year, a new pattern has emerged in attacks on the open source supply chain. Attackers are focusing on exfiltrating secrets (like API keys) in order to both publish malicious packages from an attacker-controlled machine as well as gain access to more projects in order to propagate the attack.
These attacks often start by compromising a workflow on GitHub Actions.
Let’s talk through what you can do today to secure your GitHub Actions workflows, what work GitHub has been doing to secure open source, and what to expect in the coming months for further security enhancements.
Many of these attacks start by looking for exploitable GitHub Actions workflows.
The most critical action you can take is to enable CodeQL to review your GitHub Actions workflow implementation (available for free on public repositories) to inspect your workflows for security best practices.
Next, review our detailed actions security guidance. In particular:
Entrarpull_request_target.When an attack happens, we publish information about compromised dependencies in our Advisory Database. You can get up-to-date information directly from the Advisory Database or use tools like Dependabot (also free for public repositories) to notify you when you have malicious or vulnerable dependencies.
These attacks follow the same pattern: they focus on exfiltrating secrets to publish malicious packages from an attacker-controlled machine, as well as using those malicious packages to gain access to more projects to propagate the attack.
Instead of using secrets in your workflows, you can use an OpenID Connect token that contains the workload identity of the workflow to authorize activities. We’ve worked with many systems to integrate with Actions this way, including cloud providers, package repositories, and other hosted services.
Specifically, GitHub partners with the OpenSSF to support this security capability, called trusted publishing, in package repositories, which is now supported across npm, PyPI, NuGet, RubyGems, Crates, and other package repositories. Not only does trusted publishing remove secrets from build pipelines, it also provides a valuable signal when a newly published package stops using trusted publishing: the community uses this signal to investigate if the package came from an attacker using exfiltrated credentials.
npm is the largest package repository in the world, with over 30,000 packages published each day. We scan every npm package version for malware, and our detections are constantly updated and improved as attacks evolve. Hundreds of newly published packages contain malicious code daily, so when detected, a human reviews to confirm it’s a true positive before we take action. At this scale, even a 1% false-positive rate would disrupt hundreds of legitimate publishes daily.
In late 2025 the Shai-Hulud attacks motivated a revamped security roadmap for npm, which we talked about in Our plan for a more secure npm supply chain and Strengthening supply chain security: Preparing for the next malware campaign. In response to Shai-Hulud we accelerated the roll-out of capabilities like npm trusted publishing, continued work on malware detection and removal, and engaged with open source maintainers on what npm security capabilities would have the biggest positive impact. Even when the community agrees a change must be made, those changes can mean that people need to change their workflow, or worse, cause backwards incompatibility. We’re working to provide as smooth a transition as possible.
Similarly, with the most recent round of attacks we are revisiting our security roadmap for GitHub Actions and accelerating actions security capabilities where work was already underway. You can give us feedback on the GitHub Actions security roadmap in the community discussion post.
Open source is a global public good and one of humanity’s greatest collaborative projects. We have not seen the end of attacks on open source, but GitHub is committed to defending it across npm, actions, or whatever comes next. As we work on rolling out these security capabilities, we look forward to your feedback on what’s most impactful and how we manage the transition to a more secure future.
The post Securing the open source supply chain across GitHub appeared first on The GitHub Blog.
