Operations | Monitoring | ITSM | DevOps | Cloud

CRA turns software trust from assumed to legally required

For years, buying software meant trusting the vendor. The Cyber Resilience Act changes that relationship by codifying what vendors must do – auditing dependencies, confirming exploitable vulnerabilities, and enforcing security best practices – as legal obligations, not internal choices. For customers, that means software safety is no longer a matter of brand reputation. For vendors, it means governance gaps that were once internal concerns are now deal blockers.

Scanners aren't enough. Here's the layer most teams are missing.

Vulnerability scanners tell you what's wrong with what you already pulled. They don't stop a malicious package from entering your environment in the first place. A private registry with minimum release age policies adds that missing layer – packages newer than two or three days don't reach developers until the industry has had time to identify and remove malicious ones from public registries. Active campaigns like TeamPCP are targeting npm, PyPI, and Maven Central right now. The gate has to come before the scan. Cloudsmith provides that gate.

Shai-Hulud style attacks need more than scanning

Pre-install scripts mean a malicious package can compromise a developer's laptop the moment it's pulled – no build, no deploy, no install required. That breaks the old model where scanning catches a bad package after the fact, when it's already too late. The fix is active policy enforcement at the point of pull, using signals like package age, signed provenance, and maintainer trust to filter out malicious packages before they ever land.

Make SBOM generation a build step, not a compliance project

Compliance work that lives outside the build pipeline becomes developer friction – and friction kills adoption. The simpler fix is to make SBOM generation a standard pipeline step via a reusable template, with output routed automatically to central storage and surfaced to the teams who need it. When developers can see their own license issues and vulnerability exposure without filing a ticket, compliance stops being a tax and starts being a byproduct of shipping.

Vulnerability scanners find problems. A firewall prevents them.

A vulnerability scanner tells you what's wrong with dependencies you've already pulled. A dependency firewall decides what enters your environment in the first place. Instead of pulling blindly from public registries, every request is proxied through the firewall – where policy controls what's permitted, threat intelligence flags malicious packages that scanners never see, and enforcement happens at the earliest possible point. Scanning what's already inside is too late.

The golden path: security that works because it's the easy path

A golden path for dependency management isn't a policy document – it's a preconfigured private registry with upstream proxies covering every ecosystem your teams use, set as the default. Developers don't opt into security; they get it automatically by using the standard toolchain. The alternative is teams configuring their own controls, producing inconsistent postures and compounding risk across the org. If the secure path requires extra steps, developers will route around it. Make it the easiest option and the policy enforces itself.

The most dangerous window is before threat intel knows about it

When a malicious package is first published, threat intelligence sources haven't flagged it yet – and every team pulling from a public registry is exposed during that entire window. The fix isn't faster scanning; it's a policy that holds new packages for a defined cooldown period before they're eligible to pull. By the time the window closes, the threat intelligence has caught up. Teams pulling direct from npm or PyPI have no equivalent enforcement layer – which is exactly how attacks like Shai-Hulud got in.

Cooldown policies - Block malicious packages at the index

Every dependency pull is a trust decision. Public registries don't vet what they serve. Cooldown policies give you a gate at the moment that matters most: when a package first enters your environment. Dan McKinney (Solutions Engineering Manager) walks through how Cloudsmith's cooldown policies work and how to configure one in under five minutes. What Dan covers.

The Miasma worm explained: How it Hit Red Hat and Microsoft

Miasma has already hit Red Hat and 73 Microsoft GitHub repos. Here's how it works and what your team can do right now. Nigel Douglas, Head of Developer Relations at Cloudsmith, breaks down the Miasma worm – a self-replicating supply chain attack and evolved variant of Mini Shai-Hulud from threat group TeamPCP. Learn how Miasma uses the yo-yo attack method to move laterally across registries and workstations, why conventional scanners missed it, and the practical steps security teams can take today, including cooldown policies and continuous risk assessment.