Container Image Risks: Why Skipping Verification Today Breaks Your Service Tomorrow
Nikita, technical leader of the Evolution Container Security and Addons team at Cloud.ru, outlines four common container security pitfalls that repeatedly appear in client Kubernetes environments. The post covers vulnerable dependencies, supply-chain attacks on image registries, secret leakage in layers, and CI/CD exposure points, supported by concrete incidents from production clusters.
Thin spot 1. Untracked vulnerabilities in dependencies
The most frequent issue is outdated software carrying known CVE entries combined with overly permissive configurations. Small teams often stay current because their infrastructure is simple, while large enterprises remain on old versions due to extensive custom integrations but compensate with strict access policies. Mid-sized organizations face the worst position: custom wrappers already hinder updates, yet they lack dedicated security staff or tooling to offset the risk.
A 2025 vulnerability in nvidia-container-toolkit (CVE-2025-23266) illustrates the danger. The flaw resided in OCI hooks that execute with host privileges. An attacker could embed a malicious library inside a minimal Dockerfile; after escaping the container, the attacker enumerated pods, located a service account with nodes/proxy rights, and used the kubelet port 10250 to execute commands on another node, ultimately accessing mounted secrets. The incident combined the NVIDIA component vulnerability with excessive service-account privileges. A second high-severity flaw appeared in the same component shortly afterward, reinforcing that privileged add-ons such as GPU operators and CNI plugins require patching within days rather than weeks.
Thin spot 2. Supply chain attacks: even pinned tags are not safe
The classic advice to avoid the latest tag proved insufficient when attackers compromised Aqua Security developer accounts in early 2026. They performed force pushes that reassigned more than seventy Trivy tags to malicious commits containing secret-exfiltration logic. Later, using a remaining compromised service account, they published tainted images directly to Docker Hub. Organizations pulling fresh images without cache or additional verification could have deployed the malicious versions.
Cloud.ru avoided impact through a private registry with caching and mandatory manual review plus secondary scanning before promotion. The incident demonstrated that a tag can be silently rebound to different content; the only reliable reference is the full SHA256 digest of the image manifest. Additional protection comes from Cosign signatures verified inside the cluster by Connaisseur, Kyverno, or Image Validating Admission Policies. The article also notes the gh0stEdit class of attacks that can alter unpacked layer contents while preserving manifest hashes.
Thin spot 3. Secret leakage: regex-based detection still works
Developers continue to commit private keys and hardcoded credentials that end up baked into container layers. Two real cases involved a DevOps engineer who left an SSH key in a working directory before pushing, and a tester who hardcoded credentials that survived the build pipeline. Simply overwriting the file or rebuilding a new image does not remove the secret from Git history or from previously pushed image layers; rotation of the secret itself remains the only reliable remediation.
Effective controls begin with pre-commit hooks that block commits containing obvious secret patterns locally. Subsequent layers include CI/CD scanning with tools such as Trivy and Checkov, followed by registry-level scanning provided by Evolution Container Security.
Thin spot 4. CI/CD as an attack vector
The article concludes by noting that supply-chain and secret issues ultimately converge in CI/CD pipelines. Automated verification of image signatures, continuous vulnerability monitoring, and strict service-account hygiene are required to prevent a single compromised upstream image or leaked credential from granting cluster-wide access.
Related articles
Should Python Libraries Raise Minimum Dependency Versions to Block Vulnerable Releases?
Seth Larson of the Python Software Foundation argues that library maintainers should not automatically raise the minimum allowed version of a dependency after a vulnerability is disclosed. He states that dependency metadata exists to declare compatibility, while security decisions belong to the application owner who controls the final build. The recommendation has sparked debate in the Python community, with some maintainers supporting the separation of concerns and others viewing security constraints as part of library support obligations. CodeScoring’s analysis examines the practical impact on the ecosystem, noting that over 10,000 packages depend on urllib3 and tens of thousands more rely on numpy, requests, and pandas. The piece concludes that version bounds may incorporate security considerations only after evaluating real usage, affected versions, and downstream compatibility, but they cannot replace application-level vulnerability management with lockfiles and tools such as pip-audit.
Corporate Nextcloud Security Gaps: Default Settings, Antivirus Failures and Open Source Integration Challenges
A detailed analysis from K2Tech reveals that corporate Nextcloud deployments require extensive security hardening beyond default open source configurations. The article examines integration with LDAP, WAF, Anti-DDoS and multiple antivirus engines including ClamAV, Kaspersky Scan Engine and PT Sandbox over ICAP. Critical issues include antivirus plugins bypassing scans during unreachable states or chunked file uploads via MOVE commands, allowing infected files to reach S3 storage. Performance tests on identical 4 vCPU and 16 GB RAM hardware showed Kaspersky Scan Engine delivering the highest throughput while PT Sandbox imposed heavy CPU loads. The piece also covers architecture spanning MariaDB Galera, Redis, Elasticsearch and multi-AZ S3, plus the need for custom parameter tuning and continuous testing due to frequent Nextcloud releases. Overall, the report emphasizes that true corporate-grade security for open source file sharing demands significant post-installation effort and monitoring.
FakeGit Campaign Floods GitHub with 7,600 Fake Repositories to Distribute SmartLoader Malware
The FakeGit operation has created or repurposed approximately 7,600 repositories on GitHub to trick users and automated agents into downloading SmartLoader, a loader that installs additional malware including the StealC infostealer. Attackers clone legitimate projects, replicate documentation and developer profiles, and host malicious ZIP files in GitHub Releases that have already accumulated over 14 million downloads across roughly 200 repositories. A notable tactic called AgentBaiting targets AI systems by disguising more than 800 repositories as AI Skills or MCP servers, leading tools from Anthropic, Google, and OpenAI to recommend malicious packages. The infection chain uses LuaJIT to execute obfuscated Lua scripts that deploy SmartLoader, which establishes persistence via scheduled tasks and resolves command-and-control infrastructure through a blockchain dead drop on Polygon. Over 600 listings linked to the campaign have also appeared on public directories such as LobeHub, Glama, and MCP Market, extending the reach beyond GitHub. Defenders are advised to maintain approved catalogs of AI components, apply application control policies, and monitor for LuaJIT execution and anomalous outbound traffic.
Securing CI/CD in Open Source Projects: Cilium’s Final Guide to Credentials, Verification, and Remaining Gaps
VK Cloud has published the third and final part of its translated Cilium series on protecting the software supply chain in open source projects. The article details how Cilium isolates CI and production credentials using separate GitHub environments, enforces keyless signing with Sigstore Cosign and SBOM attestations, and applies strict release controls that prevent compromised workflows from reaching production images. It also covers the team’s ongoing security operations, additional hardening measures such as immutable tags and mandatory DCO sign-offs, and a gap analysis against OpenSSF Scorecard and SLSA standards. The post examines GitHub’s 2026 Actions security roadmap and explains how planned platform features like dependency blocking, scoped secrets, and native egress firewalls align with Cilium’s existing controls. The piece concludes by emphasizing defense-in-depth and the importance of openly sharing supply-chain security practices across the open source community.