By submitting this form, you agree to our 

Regulatory compliance in the software supply chain is a moving target that shifts with every dependency, security advisory, and regulatory update. Cloudsmith’s EPM puts control back in your hands by enabling development and operations teams to create real-time policy enforcement, right where it matters: at the package level.

By leveraging OPA and Rego, EPM lets you define precise, programmatic policies that determine how packages are evaluated, tagged, or quarantined before they’re ever promoted downstream. That means compliance policy enforcement is built directly into your distribution pipeline rather than being left to chance, or worse, post-release audits.

For development teams out there, the last thing we want to do is slowing you down with red tape security features. We want to help shift compliance left in the supply chain so issues are caught early, consistently, and transparently. Whether it’s blocking unlicensed packages, quarantining vulnerable builds, or ensuring artifacts meet naming conventions, EPM ensures that policies are applied automatically and uniformly through your own unique policy-as-code configurations.


Copy-Left policy that matches license strings

This policy is important from a compliance perspective because the use of 

 in production environments can create significant legal and operational risks if not properly managed. Many of these licenses impose obligations, such as requirements to disclose source code, distribute derivative works under the same license, or provide attribution, that may in some cases be incompatible with an organisation’s business model, intellectual property strategy, or contractual commitments.

By proactively detecting both free-text and standardised System Package Data Exchange (

) variants of these licenses, the policy ensures that potentially problematic code is flagged before it reaches production, enabling the necessary legal review or approval. This not only reduces the risk of inadvertent license violations but also demonstrates due diligence in open-source governance, which is often a key expectation in audits, customer contracts, and regulatory environments.

The license trigger conditions are highlighted in our detailed schema which is available towards the bottom of 

 v.3.1.1 package that we know has a GNU Lesser General Public License (

) license that should trigger the policy:

 If you have a tagging response action attached to your policy, you could tag the package with 

This policy checks whether a package includes specific 

 descriptors in the filename. This could be the simplest way for an organisation to state whether a package is a debug package, and therefore should not be ingested into, say, the 

The policy will trigger on these kind of wildcard examples:


Cloudsmith EPM allows users to easily match package filename metadata based on Regular Expression (RE) string matching patterns. Once ready, you can download the 

 Python package and push it to Cloudsmith to cause the policy violation:

From a compliance perspective, preventing debug, test, or temporary builds from entering production is critical because these artifacts often contain unverified code, verbose logs, or experimental features that were never intended for public release. If deployed, they may expose sensitive internal information, introduce security vulnerabilities, or degrade system performance, any of which can result in regulatory noncompliance, contractual breaches, or audit findings. Enforcing this control at the ingestion point ensures that only vetted, production-ready packages flow downstream, reducing the likelihood of costly incidents while demonstrating due diligence in software governance.

The use of RegEx strengthens this control by providing a highly adaptable mechanism for detecting noncompliant naming conventions across diverse development and CI/CD practices. Instead of hardcoding rigid checks, RegEx allows compliance teams to define broad yet precise patterns that evolve alongside the organisation’s software ecosystem. This flexibility enables policy enforcement to remain effective without creating excessive operational overhead.

This policy exists to ensure that packages coming from upstream sources are explicitly reviewed and marked as "

" before being allowed to proceed in the pipeline.

You could think of this as an advanced use-case for tagging. When both conditions are true, the policy will trigger. Note: There is also a commented-out condition for restricting it to specific repositories, if you’d prefer to whitelist certain repositories that are not under the same level of regulatory scrutiny.

From a compliance perspective, this policy enforces a controlled workflow for handling externally sourced or upstream packages, which are often beyond the direct control of the security team. By requiring an explicit "

" tag before these packages are considered safe, it creates a checkpoint where security, licensing, and quality reviews can be performed. This helps prevent unverified or potentially malicious code from entering production systems. It also encourages consistent documentation of the approval process, which can be important for compliance frameworks such as SOC 2, ISO 27001, or internal governance policies.

From a risk management perspective, the policy reduces the chance of introducing vulnerabilities, licensing conflicts, or compatibility issues from upstream sources. Operationally, it gives teams the flexibility to integrate valuable external software while maintaining a robust safeguard against unvetted changes. Over time, this approach can significantly improve software supply chain security, maintain regulatory compliance, and protect the organisation’s reputation by ensuring only reviewed and trusted packages make it into critical environments.


 architecture packages and blocks others like 

To trigger the above policy (which blocks all architectures 

), you'd want to upload or sync a Python package that is built for a 

 architecture - like arm64. However, pip by default fetches packages built for your local system architecture, so you typically won't download architecture-specific wheels unless they're explicitly tagged.

This architecture-specific allow list policy plays a critical role in compliance by ensuring that only packages built for the approved amd64 architecture are permitted in production and testing environments. In organisations standardised on x86-based servers, containers, and CI/CD pipelines, introducing packages built for other architectures, such as the case with arm64, can create hidden risks such as runtime failures, inconsistent behaviour across platforms, or the inability to reproduce builds reliably.

From a compliance perspective, these risks undermine key principles of software assurance, reproducibility, and auditability, all of which are essential for demonstrating control over the software supply chain. Blocking non-amd64 packages at enforcement ensures that software deployed downstream aligns with documented infrastructure baselines, reducing the likelihood of noncompliant system configurations.

Additionally, different architectures may introduce unique vulnerabilities, require distinct patching procedures, or fall outside the scope of validated security tools and compliance checks. Allowing multiple architectures without proper governance complicates vulnerability management, weakens evidence for audit trails, and can create gaps in regulatory coverage. By restricting deployments to a single, vetted architecture, this policy simplifies compliance verification, strengthens the integrity of vulnerability scanning, and provides assurance that all deployed software is consistent with approved security and operational standards.

Build your own compliance policies with Cloudsmith EPM

These four examples illustrate just a handful of the ways Cloudsmith EPM can be applied to enforce regulatory compliance across your software supply chain. From licensing governance to architecture restrictions, debug-build quarantines to upstream approvals, each policy demonstrates how compliance controls can be codified, automated, and enforced consistently.

But this is only the beginning. Because EPM is powered by OPA and Rego, it offers almost limitless flexibility to address the unique compliance challenges your team is facing. Whether you’re aligning with industry standards like ISO 27001 or SOC 2, meeting customer contract requirements, or simply reducing operational risk, you can design policies as code that fit your exact environment.

The power lies in treating compliance as part of your pipeline rather than an afterthought. With Cloudsmith EPM, you can move fast without breaking trust, ultimately ensuring that every package that flows downstream has already been checked, validated, and approved against the rules that matter most to your business.Check out our official documentation on how to 

Nigel Douglas

Head of Developer Relations

Compliance policies in EPM

Typosquatting is now a well-known exploit, whereby malicious actors register domains or package names that are visually similar to popular ones. Examples include misspelling 

 as “expresss” - a mistake we’ve all made when typing too fast under pressure. Normally, when you make a typo retrieving a software package, you just get a build error since the package doesn’t exist. However, adversaries pick up on these subtle behaviours and in the process publish package names, deliberately containing malware, knowing someone is inevitably going to make this mistake at some point.

We just saw this threat has escalated. Instead of just mimicking individual package names in ecosystems like npm or PyPI, attackers are squatting on 

An alarming post by Bruno Schaatsbergen on 

 highlights this issue. A user discovered an active container registry at 

, which is the GitHub Container Registry. The poster warns: “I'm not sure who owns it, but be careful”. And it makes sense, unless investigated further, it’s unclear what is currently being distributed via this fake registry. Funny side note, if you go to the fake (ghrc.io) instead of the correct Github Container Registry address, it displays one of those generic default Nginx web server pages instead of the expected Github redirect (

Again, simple typo, swapping the positions of “r” and “c” leads to a completely different registry. Given that container workflows often operate in scripts or automated pipelines, a single-character mistake can redirect your push or pull operations to an attacker-controlled endpoint.

While it might seem unlikely that this is happening right now in any organisation, a simple 

 would show you that this typo has been made on quite a number of occasions. If your CI/CD workflow is also scripted to push to 

, those images will never reach GitHub, and instead will end up elsewhere. In doing so, the adversaries operating 

 could intercept or modify container images. They might serve backdoored images, leak credentials, or inject exploits. But this stuff is easy to make mistakes with. In logs or configuration files, 

 basically look identical at a glance. Developers may not notice the swap until something breaks, or even worse, when the damage is already done.

But you can take action. As an immediate first step, you can carefully review your registry URLs, especially in automation files like Dockerfiles, CI pipelines, docker push or docker pull commands. Additionally, you could enforce DNS or host-level protections to prevent access to known malicious or typo versions like GHRC. Explicitly only allow the registries that you expect to work with.

 exists as a live container registry masquerading behind a one-letter typo of 

This reflects an escalation from typosquatting individual package names to targeting entire registries.

The implications are severe. As the story evolves, it is worth adopting some vigilance when working with your container registries.

 later clarified that while the 401 response and 

 header are standard parts of the OCI spec, in this case they’re being returned by a server that isn’t a registry at all. The fact that only the 

 endpoint mimics OCI behavior, while the rest of the site is a default nginx install, suggests the setup is intentionally crafted to lure OCI clients into sending credentials to a fake token API.

This scenario highlights why companies should prefer providing developers a registry within their organisation. Having a control plane (like Cloudsmith) in front of registries in which to verify and block things like this fake registry, backed-up by a powerful audit trail for post-incident forensics.

Typosquatting a package? How about typosquatting the whole registry!

In July 2025, two of the npm ecosystem’s most widely used packages became unwitting carriers of malware. The first, 

, was compromised after its maintainer was deceived by a phishing email disguised as a message from npm support. With stolen credentials, attackers published malicious versions that spread rapidly into developer environments worldwide, dragging related packages into the breach.

Shortly afterwards, the seemingly innocuous utility ‘

’ (a lightweight library downloaded more than 2.3 million times each week) was taken over in the same way. For roughly six hours, anyone installing the package, directly or through the countless tools that rely on it, was unknowingly pulling a version laced with a backdoor. What makes this striking is not the sophistication of the malware, but the ubiquity of its host. The ‘is’ Javascript testing library does little more than check whether a value is a number, a string, or empty, yet precisely because it is so simple, it is embedded everywhere. Its compromise meant that risk cascaded across the software ecosystem almost instantly.

These events were part of a broader wave of supply chain attacks in which malicious packages are deliberately seeded into public registries. Analysts now estimate that the OpenSSF’s 

 project tracks more than 35,000 confirmed cases across npm, PyPI and other ecosystems. What once seemed rare is now industrialised.

Traditional vulnerabilities are flaws to be patched. Malicious packages are different. They are intentional weapons that arrive through normal developer workflows; invisible, inherited deep in dependency trees, and executed automatically by build systems. When a package with millions of weekly downloads is compromised, six hours is enough to spread malware worldwide. By the time advisories are published or scanners raise alerts, the damage is already done.

Intelligence is only valuable if it is enforced

Open source intelligence has improved dramatically, and projects like OpenSSF Malicious Packages and OSV.dev provide vital, structured data. But feeds alone do not change outcomes. What matters is whether that intelligence is enforced at the moment a package attempts to enter your organisation. Otherwise it becomes background noise while builds continue to ingest whatever registries serve.

Cloudsmith’s approach to artifact security

 (EPM). Intelligence from OSV.dev and OpenSSF is now integrated directly into Cloudsmith repositories, so known hostile packages can be blocked, quarantined or tagged at the point of entry; before they touch developer machines, CI pipelines, or production builds.

Even with strong ingress enforcement, new vulnerabilities and threats can emerge after artifacts are already in your repositories. A package that was safe yesterday might later be linked to a newly disclosed CVE or malware signature.

 steps in. This feature, available in EPM-enabled workspaces, performs hourly checks of your stored artifacts against up-to-date vulnerability and threat intelligence sources, such as CVE aggregators and EPSS databases. When a new threat is detected in a previously ingested artifact, Continuous Security flags it immediately without relying on manual re-scans or waiting for scheduled checks. This ensures that your repository remains secure not just at the moment of ingestion, but continuously over time, adapting to evolving risks.

The crucial difference between this approach and those of other legacy artifact management platforms is that Cloudsmith treats this as core to artifact management, not as an optional add-on. When security is sold separately, it is inconsistently applied and easy to bypass. In Cloudsmith it is inseparable from the platform itself, which means every package is subject to the same level of scrutiny the moment it arrives.

), organisations can tune enforcement to their own needs; strict blocking in production, tagging in development, quarantining for review in sensitive environments. Developers do not need to stop and think about dependency safety: those controls are enforced automatically, enabling development teams to move quickly without increasing risk.

Why a unified multi-format repository matters

Attackers are promiscuous in their choice of target. Today it is npm, tomorrow PyPI, RubyGems or Docker Hub. A fragmented security model (one tool for JavaScript, another for Python, another for containers) leaves seams. Seams are where gaps form, where integration fails, and where policy is not applied consistently.

Cloudsmith’s multi-format repositories eliminate those seams. Whether the artifact is npm, PyPI, Docker or NuGet, it traverses the same controlled gateway, subject to the same policies and the same intelligence sources, organised in a manner that makes sense to your organisation. Security and distribution are not separate concerns; they are two sides of the same process.

From artifact management to artifact trust

The compromise of ‘is’ demonstrated how quickly risk can propagate when even a trivial dependency is weaponised. Six hours, millions of downloads, and the possibility of global exposure. In that context, treating malware detection as an optional extra bolted onto artifact management is no longer defensible.

Cloudsmith brings intelligence, policy and artifact management together into one fully managed, cloud-native platform, where trust is enforced automatically at the point of entry across every format your teams use. Developers keep building at pace. Security teams know every package is vetted.

Trust is not inherited within the software supply chain. It has to be enforced.

Interested in exploring our advanced security features more for yourself? 

Grab some time with me or another member of our team.

Stephen Abraham

Account Executive

Six Hours Too Late: Why Malware Detection Must Be Built Into Artifact Management

Cloudsmith’s Enterprise Policy Management (EPM) now supports the Open Source Vulnerability (

) database as an additional data source, so users can define 

 policies. OSV.dev is a distributed vulnerability database specifically for open source software (OSS) packages, including dependencies. The open, precise, and distributed vulnerability information for OSS projects from OSV complements EPM’s existing vulnerability data from Common Vulnerability Scoring System (

) and Exploit Prediction Scoring System (

The OSV database was originally developed by Google, and is fully open source. It consolidates data from multiple vulnerability repositories that follow the OSV schema, such as 

 database, Python Packaging Advisory Database (

OSV offers a straightforward API that allows clients to look up vulnerabilities based on either a specific commit hash or a package version. All records adhere to the 

 specification, which was created through collaboration with open-source communities. This schema provides a standard approach, for both human- and machine-readable format for detailing vulnerabilities, ensuring they can be accurately linked to exact package versions and commits.

Creating a Malicious Package policy in Cloudsmith

Let’s look at an example of Cloudsmith EPM policy. This one serves as a malware detection gate. EPM runs 

 the Cloudsmith security scan completes during package synchronisation, making scan results available as 

. In this case, the policy code loops over the 

 array, which is the OSV malware data from the scan. For each vulnerability object, it checks, “does the ID start with the string 

So what does this policy do in practice? It flags any package that has been reported as known malicious as part of the OpenSSF Malicious Packages project. "

" is used specifically in vulnerability feeds to indicate malware-related findings. Once a match is found, Cloudsmith will execute the 

 for this policy, such as to quarantine, tag, or block package promotion.

 a blog post in July 2025 about a set of npm linter packages, including 

, that were hijacked via phishing to drop malware. Looking up eslint-plugin-react_editor within the OSV database we can see there’s already a matching entry with the ID 

Each malware ID comes with an associated 

 that provides all the surrounding context for policy decisions. We are using a free string search for “MAL-” to capture malware IDs.

In this scenario, we downloaded the tarball in a sandbox environment:

 tarball to Cloudsmith without installing it locally, which is safer when testing the malicious package.

 We are detecting based on malware, not on vulnerabilities. In this case there is no CVSS vulnerability data associated with the package, however, the package is still quarantined and tagged for Malware due to the malware findings from the Malicious Packages project.

 explain how the package was quarantined with the relevant malware information. Here’s a command you could use to return information specific to OSV findings:

 filter, you get the entire output of the Cloudsmith EPM decision logs. Within these logs, you’ll see:

: Times the policy evaluation started and ended.

: The exact data used to evaluate the policy.

: Which actions were actually invoked on the package.

Protect Yourself Against Malicious Packages!

By integrating OSV as a data source, Cloudsmith EPM gains access to vulnerability intelligence that directly maps to specific OSS package versions and commits. These 

 policies complement the existing CVSS and EPSS coverage by filling critical gaps, particularly in cases where a package may not register a conventional CVSS vulnerability score but is still compromised, such as with malware-flagged releases.

With OSV’s standardised schema and rich ecosystem of upstream sources, EPM will detect and act on threats that might otherwise slip through traditional scoring-based detection, extending its ability to quarantine, block, or tag malicious packages before they impact production environments.

Managing Malicious Packages with Cloudsmith EPM

Cloudsmith now detects malicious packages using data from OSV.dev and the OpenSSF Malicious Packages project so you can 

 packages designed to attack your supply chain 

Below is a quick primer on malicious packages, how Cloudsmith protects customers from malware with 

 (EPM) policy-as-code, and what’s next.

 is an artifact published to a public registry (npm, PyPI, RubyGems, etc.) that’s intentionally crafted to harm users or systems. Unlike a vulnerability (a flaw to be fixed), this is 

: credential theft, data exfiltration, backdoors, cryptominers, or build-pipeline compromise — delivered as a normal-looking dependency.

 for malware (it “rides” the OSS dependency graph via a compromised dependency into apps and CI/CD; more on that below).

While traditional malware often arrives via email attachments, web drive-bys, or exploit kits, 

 differ. Attackers publish them to registries (or compromise maintainers) so that 

 (CI, package managers) do the installation work for them, shifting the battleground to developer workflows and dependency resolution.

Software packages as delivery vehicles for malware isn’t a new thing. The 2018 

 incident was an early wake-up call: a trusted package was weaponized through a hidden dependency to target a cryptocurrency app. The threat has only grown. In mid-2025, 

researchers uncovered a coordinated malware campaign on npm

 attributed to North Korean threat actors, involving dozens of malicious packages disguised as developer tools. These packages, collectively downloaded thousands of times, deployed multi-stage payloads and backdoors like 

. Even as registries introduce stronger security controls, attackers continue to adapt.

 (OpenSSF), maintains a public, comprehensive, cross-ecosystem database of reports on malicious software packages (e.g., from npm, PyPI, RubyGems). It collects detailed intelligence on malicious packages—such as account takeover attacks, dependency confusion, and malware embedded via post-install hooks—and makes this information openly available using the 

As of August 2025, the database contains ~35,000 malicious package reports.

Cloudsmith integrates this data feed via 

, providing hourly checks against the OpenSSF database. When a malicious package is found, Continuous Security works with 

 (EPM) to automatically flag and quarantine it, preventing the harmful software from entering your builds.

 Blocking malicious packages at the source prevents them from ever reaching your systems.

Prevent attackers from compromising builds or slipping backdoors into production.

 Guardrails reduce risk without slowing teams down.

Catching threats before they’re integrated saves time, effort, and reputational risk.

Meet compliance and customer expectations: 

Support audits and build trust with security-conscious buyers.

Tap into a community-maintained feed of verified malicious packages across major ecosystems.

As attacks adapt, so will Cloudsmith. We’ll continue to expand detection by adding more threat intelligence sources, richer context and deeper automation in EPM. Upcoming work includes incorporating deps.dev to surface package quality and maintainability data, and adding more community feeds like OSV.dev - a great example of the open source community working together to solve supply chain security challenges. 

We’re also exploring ways for Enterprise customers to bring their own internal threat intelligence feeds into Continuous Security, further tailoring protection to their environment. Our goal is to broaden coverage and shorten the time it takes to detect and respond to threats. If there are specific feeds or heuristics you’d like us to prioritize, let us know.

in our documentation. Interested in learning more? 


Claire McDyre

Product Manager

Malicious Package Detection in Cloudsmith

Why developers must prioritise logging and visibility in CI/CD pipelines

This marks the final entry in our 10-part series on the OWASP Top 10 for CI/CD security risks. While production environments often benefit from rigorous hardening, logging and observability, in CI/CD pipelines this often remains critically under-addressed, despite being a key focus of OWASP. In this post, we’ll unpack the security risks posed by insufficient logging in CI/CD environments, why it matters, and how you can strengthen your defences using modern artifact management solutions like Cloudsmith, alongside powerful open-source tools like Falco and GUAC.

Risk of attacks going undetected in CI/CD pipelines

Without proper logging and visibility, attackers can move through your CI/CD systems undetected - whether stealing credentials, injecting malicious code, or tampering with artifacts. This lack of audit-ability makes post-incident investigations nearly impossible, delaying containment and increasing the potential damage.

As we look to evolving regulatory pressures through EU’s Cyber Resiliency Act (

), Network and Information Systems Directive 2 (

) and Digital Operational Resilience Act (

), it’s more urgent than ever to have adequate auditing and visibility capabilities to meet these compliance requirements.

At the same time, threat actors are increasingly exploiting programmatic access, automated bots, and compromised tokens to breach and persist within CI/CD pipelines. While strong observability might feel like a "nice-to-have" on a checklist, it should be your first line of defence and your best tool for recovery.


Why logging in CI/CD is often overlooked

While logging is typically mature in production environments (covering servers, apps, and network infrastructure) CI/CD systems often fall through the cracks. Consider how many tools touch your pipeline:


Supply Chain Management (GitHub & GitLab)

Deployment/orchestration platforms (Kubernetes)

Artifact repositories (Cloudsmith, Nexus & Artifactory)

Each of these components introduces new vectors, and often lack default security logging capabilities unless explicitly configured.


How to build effective logging and visibility in CI/CD

There are several elements to achieving sufficient logging and visibility:

Before you can secure your pipeline, you need to inventory every system involved, from source code managers, build servers, artifact storage, through to deployment systems, whether that be Kubernetes or Terraform. Open-source tools like 

 (Graph for Understanding Artifact Composition) help you 

 between artifacts, identify missing SBOMs/SLSA attestations, and catch policy violations. GUAC ingests metadata like SBOMs and builds a graph to trace how artifacts are produced, increasing transparency across your pipeline.

 explores the various nodes and relationships of GUAC. The below 

 searches the GUAC graph for any vulnerabilities affecting that Package URL (PURL), including transitive ones.


 of a given PURL. Users can generate a summary of all SBOMs, SLSA attestations, vulnerabilities and licensing information that GUAC knows about for the artifact:

 are enabled and accessible. Naturally, this same rule applies to other SCM tools like Gitlab and CI servers like CircleCI. These sources should include user access logs (such as logins and permission changes), as well as pipeline events (build triggers and artifact uploads). Developers also need to be able to track API usage and access token activity, deployment actions and runtime configurations, and more. 

. API tokens, webhooks, and CLI-based interactions are commonly exploited, and we must ensure visibility covers these too.

3. Centralise logs for correlation & alerting


Shipping logs to a centralised Security Information and Event Management (

) like Datadog allows you to correlate events across tools and detect anomalies early. Thankfully, Cloudsmith now offers a prebuilt Datadog Agent container with the 

 already installed. This streamlines observability by eliminating manual integration steps and avoiding version drift. You’ll get dashboards and alerts covering, artifact usage and delivery, audit logs, compliance status, and suspicious access patterns. In this way you can monitor if a previously unused artifact is suddenly downloaded from a production repository. That could be a red flag for your team.

4. Detect unwanted SCM activity in real-time with Falco


In some cases you might prefer not to send all events and logs to a centralised SIEM solution like Datadog, Dynatrace or Splunk (either due to verbosity of logs or due to storage costs). In these scenarios, 

 could be a great lightweight approach for monitoring real-time events from Supply Chain Management (SCM) platforms like 

 as well as the hosts and orchestration layers (

). Falco is an open-source runtime security tool that integrates seamlessly with GitHub and Kubernetes via dedicated plugins. It listens to events in real time and can alert you when something suspicious happens, like, if a user pushes sensitive credentials like Kubernetes 


For GitHub, Falco can set up webhooks on your repositories, analyse push events, new branch creation, token usage, as well as alert you via Slack, email, or send those alerts back into your SIEM. Falco doesn’t store or index your data, meaning it's a fast, lightweight, and cost-effective alternative for sufficient logging and visibility of Github. Think of it as a security camera for your repositories and clusters.

5. Enforce security policies and log decisions


As a comprehensive artifact management platform, Cloudsmith allows users to define and enforce security policies around artifact usage and publishing. Every decision made by these policies is logged and can be queried via API. We call these 

Example API call to retrieve policy logs:

You’ll get detailed insight into the evaluation start and end times of the Cloudsmith security policies, but also inputs used to evaluate those policies, the results and actions taken, as well as providing traceability and supporting regulatory audits and incident investigations.

Separate to decision logs, Cloudsmith provides client logs and audit logs. 

 provide a single pane of glass to visualise, filter, and export information about package usage within your entire workspace. It keeps the same artifact-agnostic support to unify information about all of your repositories, packages, and users in one place. No matter if your goal is gaining visibility, performing an exploratory analysis, or reporting to stakeholders, client logs provide all the information that you need. With client logs you could analyse which Maven artifacts were downloaded last month, or better understand all the different artifacts used in a staging pipeline.

 provide a timeline view of non-package (but typically administrative) actions that have occurred within the repository, such as creating/modifying repository Retention Rules or creation of an Entitlement Token.

You can’t protect what you can’t see.
Logging and visibility are your eyes and ears in fast-moving CI systems.


Invest the time to get it right, and your response time in a real-world attack could shrink from hours to minutes. That’s where different approaches matter. SIEMs can be really powerful for audit-ability of all logs data from multiple different CI/CD sources, but a dedicated event streaming approach through Falco might be ideal for triggering detections when a user has made an anomalous change to your Github repository in real-time.

CI/CD systems are increasingly targeted, so treat them like production. Logging must cover both human and programmatic access. Centralising logs unlocks correlation, detection, and faster incident response. Open-source tools like Falco and GUAC, and platforms like Cloudsmith and Datadog, make observability scalable and actionable. If you're deploying code to production, you need full visibility into your build and release pipeline. If you enjoyed this content, you can download the 

Cloudsmith Blog

Compliance policies in EPM

Typosquatting a package? How about typosquatting the whole registry!

Six Hours Too Late: Why Malware Detection Must Be Built Into Artifact Management

Managing Malicious Packages with Cloudsmith EPM

Malicious Package Detection in Cloudsmith

OWASP CI/CD Part 10: Insufficient Logging and Visibility

Of Course We Embrace Open Source!

Unlocking policy-as-code automation with Cloudsmith EPM

Using Trivy Inside Cloudsmith

OWASP CI/CD Part 9: Improper Artifact Integrity Validation

Security is a leading priority for 2025

AI is now writing code at scale - but who’s checking it?