JFrog Artifactory runs inside roughly half the enterprises we engage with, which makes it one of the highest-leverage pieces of infrastructure in their supply chain security posture. It is also, out of the box, a default-permissive system where the easy path during rollout produces a configuration that cannot be defended later. The specific hardening choices compound: an unnecessarily permissive remote repository plus an anonymous-read-enabled default plus a loosely scoped access token ends up being the attack path in an incident review three years later. This guide is what we walk customers through during Artifactory hardening engagements in 2023 — the operational choices that move the configuration from "ran the installer" to "would pass a penetration test."
What is the most important Artifactory configuration to change first?
Disable anonymous access globally. This is under Administration → Security → General Settings, checkbox "Allow Anonymous Access." Unchecking it requires that every client authenticate. Many Artifactory deployments leave it enabled during rollout so internal clients work without friction, then never disable it — leading to public-internet exposure of internal packages in environments where the Artifactory instance has any external ingress path.
After that, audit for repositories explicitly marked as allowing anonymous reads even when the global setting is disabled. The per-repo override is a common oversight.
How should remote repositories be configured safely?
Remote repositories are the Artifactory feature most often involved in supply chain incidents, because they proxy external registries and cache artifacts. Three hardening steps:
Pin the upstream URL. Use only the canonical upstream (e.g., https://registry.npmjs.org for npm, not a mirror). Mirrors have been compromised or have had availability issues that degrade your build reliability.
Enable checksum verification. Artifactory can compare downloaded artifacts against the upstream's published checksums. In version 7 this is on by default for some repo types and off for others — verify per repo.
Configure exclude patterns for malicious namespaces. Typosquat campaigns recurrently target specific package-name patterns. Maintain an exclude list that blocks known-malicious prefixes. Update quarterly from threat intel sources.
Set an appropriate "include pattern" for internal-only dependencies. If your org publishes internal packages with a specific scope (e.g., @company/*), make sure the remote npm repo excludes that scope so a dependency confusion attack cannot pull an attacker-published @company/something from the public registry.
What does a good RBAC model look like for Artifactory?
Three principles:
Separate read and write permissions per repository. The common failure is giving CI service accounts write access to all repos "for convenience." A CI job that builds service X should be able to push artifacts only to the service-X publish repo, and it should read only from the repos it actually consumes. Enforce with permission targets, not with trust.
Use groups, not per-user grants. Permission targets should be assigned to groups (SRE, CI-service-X, QA-reader). Group membership is then the audit-visible lever. Per-user grants are invisible to rotation reviews.
Short-lived access tokens for automation. Artifactory supports token TTLs. Set them. A CI pipeline that runs for at most an hour should not be using a token that works for a year. Access token leakage is a real incident class; short TTLs reduce the blast radius.
How should artifact signing and provenance be configured?
Artifactory supports signing through its built-in keys and external integration with Sigstore for some repo types in 2023. For hardening:
- Enable signing on every build-promotion event. Unsigned artifacts should not be promotable to production repos.
- Store signing keys outside Artifactory — ideally in a dedicated KMS (AWS KMS, GCP KMS, Vault Transit). Artifactory should have access to sign but not to export.
- Publish signed SBOMs alongside artifacts. SPDX or CycloneDX, signed with the same or a sibling key.
- For container images, enable Docker Content Trust or use Cosign-signed manifests; Artifactory's image repos can store Cosign signatures as OCI artifacts.
What audit logging should be enabled and where does it go?
Artifactory's audit log covers authentication events, permission changes, and administrative actions. Three configurations to verify:
Enable the audit log at the highest verbosity your storage tolerates. Default verbosity misses some events that matter in incident response.
Ship the audit log off-system. Forward to your SIEM via syslog, Filebeat, or direct S3 export. An audit log stored only on the Artifactory instance is compromised along with the instance.
Monitor for specific high-value events. New token creation, admin group membership changes, anonymous-access-enabled events, bulk artifact deletes. Each of these has appeared in real incident timelines and each is inexpensive to alert on.
What about network-level hardening?
Three practices:
- No public ingress unless essential. Artifactory should live inside your private network. External access should be via your corporate VPN or a scoped zero-trust proxy, not by exposing the Artifactory UI to the internet.
- Mutual TLS for CI clients. CI pipelines that pull artifacts should authenticate with client certificates in addition to tokens.
- Egress control. Artifactory fetching from remote registries should be routed through a dedicated egress gateway with logging and allowlisting.
What misconfigurations do we see most often?
The five-item list from incident reviews across our customer base:
- Anonymous access enabled globally.
- Access tokens with one-year TTLs used by CI.
- Remote npm/PyPI repos without dependency-confusion exclude patterns.
- Signing configured but not enforced at promotion.
- Audit log on local disk only.
Any of these on its own is recoverable. Two or three combined is how incidents happen.
How Safeguard Helps
Safeguard integrates with Artifactory to continuously verify the hardening state described in this guide — anonymous access settings, remote repo configuration, RBAC posture, signing enforcement, audit log destinations — against a policy baseline, and flags drift in real time. Griffin AI summarizes Artifactory posture across the organization so you can see the one instance that has anonymous access re-enabled without running a manual audit. The platform also pulls signed SBOMs from Artifactory-hosted artifacts into the broader SBOM graph, so the artifact repository is visible in the same reachability and policy views as the rest of the supply chain. For teams running Artifactory at enterprise scale, Safeguard provides the continuous-verification layer that keeps hardening from decaying silently after rollout.