JFrog Artifactory Security Review
A virtual repository resolves local repositories first, then remote caches, then the remote source, so a misconfigured order can serve the wrong package. We test permission targets, access tokens and repository resolution. CREST-certified testers, fixed price from £2,880 for a 2-day single-instance scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
Artifactory runs two permission models side by side, the legacy Permissions V1 and the newer Permissions V2, and which one is enforced changes what a user with manage rights can grant to others.
A JFrog Artifactory instance is only as locked down as the permission targets, tokens and repository resolution order your team configured
JFrog’s own documentation on permissions confirms that access is granted through permission targets, each combining a set of resources such as repositories, builds and Release Bundles with the users or groups allowed to reach them and the actions each is granted. Permissions are additive and must be explicitly checked, and JFrog’s own note flags that under the legacy Permissions V1 model a user holding manage could grant manage and every other permission to anyone else, a gap the newer Permissions V2 model closes so a manage holder can only grant permissions they hold themselves, never manage itself. We test which permission model is actually enforced, and what a user holding manage rights can grant beyond their own access.
Since Artifactory 7.84.3, JFrog’s documentation confirms the anonymous user is removed from the Anything and Any Remote permissions by default, so anonymous read access now has to be granted deliberately through its own permission target rather than inherited from a broad default. JFrog is equally explicit that API Keys are deprecated legacy credentials that function like passwords, and recommends Access Tokens instead because they are time-bound, revocable and can be scoped to specific permissions; generating a new Access Token never automatically invalidates an older one, so a compromised token has to be revoked by hand. We test whether anonymous access has been re-added deliberately, and whether any deprecated API Keys are still active alongside Access Tokens.
We review the permission targets, access tokens, groups, virtual repository resolution order and CI credentials configured on your own Artifactory instance, the same way we review pipeline configuration on GitHub Actions rather than GitHub Actions itself. We never test Artifactory’s own codebase or attempt to find vulnerabilities in the underlying product.
SCOPE
What we review on a single JFrog Artifactory instance
Permission Targets: Permissions V1 vs V2
Artifactory grants access through permission targets that combine physical resources, repositories (filtered by Ant-style include and exclude path patterns), builds, Release Bundles, destinations and pipeline sources, with the users or groups allowed to reach them, and JFrog documents that permissions are additive and must be explicitly granted rather than inferred. Under the legacy Permissions V1 model a user holding manage could grant manage and every other permission to anyone else; JFrog’s newer Permissions V2 model, available on both JFrog Cloud and self-hosted from Artifactory 7.77.2, fixes this so a manage holder can only pass on the permissions they hold, never manage itself, though a feature flag can still revert to the older, less secure behaviour. We test which permission model is enforced, what each permission target actually grants, and whether the manage-permission behaviour has ever been reverted.
Anonymous Access
JFrog documents that, since Artifactory 7.84.3, the anonymous user is removed from the Anything and Any Remote permissions by default, and its own best-practice guidance is to grant anonymous access only through a dedicated permission target scoped to read-only access on specific repositories where it is genuinely needed. An instance upgraded from an older version, or one where a broad permission target was recreated by hand, can still leave anonymous users with far more read access than the current default assumes. We test what an anonymous, unauthenticated request can actually reach across every repository type.
Access Tokens vs API Keys
JFrog is explicit that API Keys are deprecated legacy credentials that function like passwords, and recommends Access Tokens instead because they are time-bound, revocable and, since Artifactory 7.21.1, scoped tokens that can be limited to specific group memberships rather than carrying full account access. Generating a new Access Token never automatically invalidates an older one; revocation only happens when a token’s ID is explicitly added to Artifactory’s revocation list, so a leaked token stays valid until someone actively revokes it. We test which credential type is actually in use across users and automation, and whether any deprecated API Keys or unrevoked old tokens are still active.
CI/CD Credentials via OIDC
JFrog documents a service-to-service OIDC flow built for CI/CD automation, where a pipeline such as a GitHub Actions workflow presents a short-lived OIDC token that Artifactory validates against a pre-configured Identity Mapping before issuing a narrowly scoped, short-lived Access Token, removing the need for a long-lived static secret stored in the pipeline at all. An Identity Mapping that includes a username pattern lets a matching transient user automatically inherit every group configured with Automatically Join New Users, which can hand a pipeline more access than the mapping’s own group list shows. We test which CI/CD systems authenticate via OIDC, what each Identity Mapping actually resolves to, and whether Auto Join groups widen a pipeline’s effective permissions.
Virtual Repository Resolution Order
JFrog’s own documentation on virtual repositories sets out a fixed search order: local repositories are resolved first, then remote repository caches, then the remote repositories themselves, and recommends ordering the underlying repositories so trusted local sources are checked before any external network call is made. A virtual repository that resolves a public remote registry ahead of, or in the absence of, the internal package with the same name can be tricked into serving a build tool an attacker-published package instead of the internal one. We test the actual resolution order configured on every virtual repository, and whether an internal package name could be shadowed by a same-named public package.
Groups and Role Assignment
A group in Artifactory represents a role in the system, and JFrog documents assigning a set of permissions to a group so that adding a user to it grants every permission the group carries in one step, with an option to automatically join new users to a group as they are created. A group with Administer Platform or Manage Resources assigned, or one still set to auto-join new users from an earlier configuration, can hand every new account far broader access than the business intends. We test which groups exist, what roles and permission targets each one actually carries, and whether auto-join is still active on a group it should not be.
SSO, SAML and LDAP Authentication
Artifactory delegates authentication to external identity providers over SAML 2.0, OAuth 2.0, OIDC or LDAP, converting every successful login into the platform’s own JFrog Access Token regardless of which method was used, and JFrog’s own security guidance recommends disabling the basic authentication method once an external identity provider is fully configured to avoid a split-identity gap between the two. Where LDAP group sync determines permissions, a stale or mismatched group mapping can leave a user with access that no longer matches their directory group membership. We test which authentication methods are enabled, whether basic authentication has been disabled where SSO is in place, and whether LDAP or SAML group sync actually matches current permissions.
Repository Permission Actions and Remote Cache Behaviour
Artifactory documents five repository-level permission actions, Read, Annotate, Deploy/Cache, Delete/Overwrite and Manage, and two of them behave more narrowly than their names suggest: on a remote repository, Read only allows downloading artifacts Artifactory has already cached from the upstream, fetching something new from the remote for the first time needs the separate Deploy/Cache permission, and Artifactory documents that non-unique Maven snapshots can always be overwritten once Deploy is granted, whatever the Delete/Overwrite permission says. A group granted Deploy without accounting for its remote-cache or snapshot-overwrite side effects can end up with more write access than its name implies. We test which of the five actions each group actually holds against every repository, and whether Deploy alone is quietly granting overwrite rights the business assumed Delete controlled.
Admin Exposure and Platform Access
Administer Platform is one of the roles a group or user can be assigned in Artifactory, and JFrog documents that only a user with admin privileges, or a project admin for their own project, can create admin-scoped Access Tokens; the JFrog Platform UI, REST API and CLI all authenticate against the same underlying Access Token regardless of which interface is used. How the Artifactory UI and API are exposed, whether they sit behind your own network controls or are reachable directly from the internet, determines who can reach that authentication boundary at all. We test how the platform is actually exposed, who holds Administer Platform rights, and what an admin-scoped token can reach.
JFrog Cloud vs Self-Hosted
Several controls this page covers differ by deployment: Permissions V2 is available on both JFrog Cloud and self-hosted Artifactory from version 7.77.2, mTLS authentication is used specifically in certain JFrog Cloud deployments, and HTTP SSO, which relies on an external reverse proxy handling authentication, is documented as unsupported on SaaS. A self-hosted instance carries direct responsibility for patching, network exposure and upgrade timing, while a JFrog Cloud instance depends on JFrog’s own platform operations for those parts of the stack. We confirm which deployment model applies to your instance before scoping the engagement.
OUR PROCESS
JFrog Artifactory Security Review: From Scope to Attestation
Scope and Access
We agree which Artifactory instance, repositories and permission targets are in scope, plus at least one login for each group and role tier in use.
Permission and Token Mapping
We map every permission target, group, access token and virtual repository resolution order against the access it actually grants.
Manual Testing
A CREST-certified tester manually tests permission target boundaries, anonymous access, token scope, resolution order and CI credential exposure, chaining findings where they compound.
Attestation and Retest
You get a technical report with CVSS scores and reproduction steps, a walkthrough call, a free retest once fixes are deployed, and an attestation letter for auditors.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST JFrog Artifactory pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent JFrog Artifactory Security Review Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
2 to 3 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote3 to 5 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote5 to 7 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test JFrog Artifactory For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From JFrog Artifactory Security Review
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need to test our Artifactory instance?
We need at least one login for each distinct group and role in use, ideally a read-only account rather than a user with Administer Platform, plus a sample access token if CI/CD authentication is in scope. Read access to your current permission targets and groups speeds up scoping but isn’t needed to start.
Will testing touch our live data?
Testing focuses on permission targets, tokens, groups, repository resolution order and CI credentials rather than the artifacts and packages already stored in your repositories. Where proving a finding needs a test package or a temporary token, we agree the exact scope with you first and remove anything we create once testing is complete.
Is this hosted on our infrastructure or JFrog’s?
Artifactory can run self-hosted on your own infrastructure or as JFrog Cloud, and a small number of controls, including mTLS authentication and HTTP SSO support, differ between the two. We confirm which deployment model applies to your instance during scoping and test the configuration you actually control.
How long does a JFrog Artifactory security review take?
A single instance with a typical set of repositories, permission targets and groups sits in our 2-day single-instance scope, with a report landing around 5 working days after kickoff. An instance running many permission targets, multiple identity provider integrations, or a large CI/CD footprint extends that scope.
What is out of scope for a single-instance review?
Testing Artifactory’s own source code or the underlying storage backend behind your repositories is not included, and we do not run denial-of-service testing against the instance. A connected CI/CD platform’s own security review, such as GitHub Actions or Jenkins, is scoped and quoted separately.
Do you need our source code or admin access?
No. We test with the accounts and tokens you provide, and we do not need standing Administer Platform access beyond what is needed to verify a specific finding during the engagement.
Does JFrog have a policy on customer penetration testing?
Self-hosted Artifactory is software you run yourself, so there is no vendor notification process to follow before testing your own instance, and a genuine vulnerability in Artifactory’s own code is reported through JFrog’s own security channels instead. JFrog Cloud is JFrog’s own hosted platform, so we confirm JFrog’s current customer security-testing terms for it during scoping.
Are your testers CREST certified?
Yes. Every Artifactory engagement is carried out by UK-based, CREST-certified testers, and your report and attestation letter are recognised by auditors and insurers accordingly.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your JFrog Artifactory instance
A virtual repository resolves local repositories first, then remote caches, then the remote source, so a misconfigured order can serve the wrong package. We test permission targets, access tokens and repository resolution. CREST-certified testers, fixed price from £2,880 for a 2-day single-instance scope, quoted within 24 hours.
