Integration Name
JFrog Artifactory — new package. There is no JFrog or Artifactory package in packages/ today, so it isn't in the Integration Name dropdown.
Dataset Name
New data streams:
jfrog_artifactory.audit — audit trail log (primary ask)jfrog_artifactory.access — Artifactory access log (proposed second stream, see below)
Integration Version
N/A — the integration does not exist yet.
Agent Version
N/A — no specific version constraint; a current Elastic Agent / Fleet release is assumed.
OS Version and Architecture
N/A for the integration itself — collection shouldn't be OS-specific. Both self-hosted (Linux, Windows, Docker, Kubernetes) and JFrog Cloud deployments are in scope.
User Goal
Collect JFrog Artifactory audit trail logs into Elastic Security as a supported integration, mapped to ECS.
Artifactory is the artifact repository and binary store at the centre of many software supply chains — it holds the build outputs, container images, and packages that get deployed to production. Its audit trail is the record of who changed access to that store: creation, update, and deletion of users, groups, permission targets, and access tokens (and, from Artifactory 7.131.0, changes to access configuration settings).
That makes it high-value security telemetry for a source that can't be collected out of the box today:
- Supply-chain integrity — detect a new access token, a permission target widened to a production repository, or a service account granted deploy rights.
- Privilege escalation and persistence — token creation and group membership changes in the system that gates artifact publishing.
- Insider risk and offboarding — verify that access removal actually happened.
- Compliance — an auditable trail of access changes over a system holding release artifacts.
Existing Features
There's no JFrog or Artifactory integration in this repository — no packages/jfrog* or packages/artifactory*, and no existing request for one that I could find.
The available options today are all custom, and none of them ship parsing, ECS mappings, dashboards, or detection rules:
- Custom Logs (Filestream) against
access-security-audit.log — the log is pipe-delimited, not JSON, so every user has to write and maintain their own dissect/grok pipeline. The Data Changed column is a nested JSON blob using single-letter permission codes (r/t/w/d/m) that needs its own decoding step.
- JFrog Cloud Log Streaming → Elastic for JFrog Cloud customers. JFrog already ships an Elastic destination, but it delivers raw log lines — there's no ECS mapping or content on the Elastic side.
A first-party package would turn a per-customer parsing exercise into a supported, ECS-mapped source with content.
What did you see?
Self-hosted — audit trail log
Written to $JFROG_HOME/artifactory/var/log/access-security-audit.log, one pipe-delimited record per line, with these columns:
| Column |
Notes |
| Date |
yyyy-MM-dd'T'HH:mm:ss.SSSZ |
| Trace ID |
correlates a request across JFrog services |
| User IP |
unknown for internal service tokens |
| User |
actor; unknown for internal service tokens |
| Logged Principal |
the service that performed the operation |
| Entity Name |
the security entity that was modified |
| Event Type |
C = Create, U = Update, D = Delete |
| Event |
USR = user, GRP = group, PRM = permission, TKN = token |
| Data Changed |
JSON describing the change; permission codes r=Read, t=Annotate, w=Deploy/Cache, d=Delete, m=Manage |
This maps cleanly onto ECS — Date → @timestamp, User → user.name, User IP → source.ip, Event Type + Event → event.action / event.type with event.category: iam, Entity Name → the affected user/group/role target, Trace ID → trace.id.
By default the log rotates across 10 × 100 MB files (1 GB total), tunable via <maxIndex> / <MaxFileSize> in logback.xml — worth noting for collection, since a busy instance can roll files quickly.
JFrog Cloud (SaaS)
Self-hosted deployments have the file on disk; Cloud customers don't. JFrog Cloud offers two paths:
- JFrog Cloud Log Streaming (Enterprise+ subscription) streams
access-audit, access-security-audit, Artifactory access logs, and Artifactory request logs to a destination list that already includes Elastic, with both "Bulk API" and "Data Streams" options.
- Cloud Log Collection writes application logs into a dedicated Artifactory repository for download.
Open question — collection mechanism. I couldn't find a REST API that returns audit events. The only audit-related endpoint in the docs is PATCH /access/api/v1/config, which enables/disables audit logging and is self-hosted only. So this looks less like a typical CEL/agentless API-poll package and more like:
- a filestream input for self-hosted, plus
- ingest pipelines, ECS mappings, and dashboards sitting behind JFrog Cloud Log Streaming's existing Elastic destination for Cloud.
Confirming the intended Cloud path — and whether the streamed payload is structured or the same pipe-delimited line — is the main design question, and one JFrog could probably answer directly.
Anything else?
Proposed second data stream — Artifactory access log. Alongside the audit trail, Artifactory writes an access log (artifactory-access.log) covering security-relevant events: accepted and rejected logins, plus artifact download, browse, and deploy activity. Where the audit trail answers who changed access, the access log answers who pulled or pushed which binary — directly useful for supply-chain monitoring, detecting credential abuse against the repository, and spotting bulk artifact exfiltration. JFrog Cloud Log Streaming already carries it. Suggest treating the audit trail as the primary stream and access logs as a second, optional one.
Suggested content. Dashboards along these lines:
- Access changes overview — audit events over time by action and actor; breakdown of user vs. group vs. permission vs. token changes; a high-signal panel for token creation and permission-target changes; a recent-changes table for review.
- Artifact access overview (with the access-log stream) — authentication successes and failures over time, top actors and repositories, deploys by user, and failed-login sources.
Detection-rule candidates: access token created; permission target granted on a production repository; admin group membership change; a spike in failed authentication against Artifactory; anomalous bulk downloads.
Naming. Suggesting jfrog_artifactory for the package. If JFrog Xray or other JFrog Platform services are likely to follow, a broader jfrog package with per-service data streams may age better — happy to follow whatever the team prefers.
References
Integration Name
JFrog Artifactory — new package. There is no JFrog or Artifactory package in
packages/today, so it isn't in the Integration Name dropdown.Dataset Name
New data streams:
jfrog_artifactory.audit— audit trail log (primary ask)jfrog_artifactory.access— Artifactory access log (proposed second stream, see below)Integration Version
N/A — the integration does not exist yet.
Agent Version
N/A — no specific version constraint; a current Elastic Agent / Fleet release is assumed.
OS Version and Architecture
N/A for the integration itself — collection shouldn't be OS-specific. Both self-hosted (Linux, Windows, Docker, Kubernetes) and JFrog Cloud deployments are in scope.
User Goal
Collect JFrog Artifactory audit trail logs into Elastic Security as a supported integration, mapped to ECS.
Artifactory is the artifact repository and binary store at the centre of many software supply chains — it holds the build outputs, container images, and packages that get deployed to production. Its audit trail is the record of who changed access to that store: creation, update, and deletion of users, groups, permission targets, and access tokens (and, from Artifactory 7.131.0, changes to access configuration settings).
That makes it high-value security telemetry for a source that can't be collected out of the box today:
Existing Features
There's no JFrog or Artifactory integration in this repository — no
packages/jfrog*orpackages/artifactory*, and no existing request for one that I could find.The available options today are all custom, and none of them ship parsing, ECS mappings, dashboards, or detection rules:
access-security-audit.log— the log is pipe-delimited, not JSON, so every user has to write and maintain their own dissect/grok pipeline. TheData Changedcolumn is a nested JSON blob using single-letter permission codes (r/t/w/d/m) that needs its own decoding step.A first-party package would turn a per-customer parsing exercise into a supported, ECS-mapped source with content.
What did you see?
Self-hosted — audit trail log
Written to
$JFROG_HOME/artifactory/var/log/access-security-audit.log, one pipe-delimited record per line, with these columns:yyyy-MM-dd'T'HH:mm:ss.SSSZunknownfor internal service tokensunknownfor internal service tokensC= Create,U= Update,D= DeleteUSR= user,GRP= group,PRM= permission,TKN= tokenr=Read,t=Annotate,w=Deploy/Cache,d=Delete,m=ManageThis maps cleanly onto ECS — Date →
@timestamp, User →user.name, User IP →source.ip, Event Type + Event →event.action/event.typewithevent.category: iam, Entity Name → the affected user/group/role target, Trace ID →trace.id.By default the log rotates across 10 × 100 MB files (1 GB total), tunable via
<maxIndex>/<MaxFileSize>inlogback.xml— worth noting for collection, since a busy instance can roll files quickly.JFrog Cloud (SaaS)
Self-hosted deployments have the file on disk; Cloud customers don't. JFrog Cloud offers two paths:
access-audit,access-security-audit, Artifactory access logs, and Artifactory request logs to a destination list that already includes Elastic, with both "Bulk API" and "Data Streams" options.Open question — collection mechanism. I couldn't find a REST API that returns audit events. The only audit-related endpoint in the docs is
PATCH /access/api/v1/config, which enables/disables audit logging and is self-hosted only. So this looks less like a typical CEL/agentless API-poll package and more like:Confirming the intended Cloud path — and whether the streamed payload is structured or the same pipe-delimited line — is the main design question, and one JFrog could probably answer directly.
Anything else?
Proposed second data stream — Artifactory access log. Alongside the audit trail, Artifactory writes an access log (
artifactory-access.log) covering security-relevant events: accepted and rejected logins, plus artifact download, browse, and deploy activity. Where the audit trail answers who changed access, the access log answers who pulled or pushed which binary — directly useful for supply-chain monitoring, detecting credential abuse against the repository, and spotting bulk artifact exfiltration. JFrog Cloud Log Streaming already carries it. Suggest treating the audit trail as the primary stream and access logs as a second, optional one.Suggested content. Dashboards along these lines:
Detection-rule candidates: access token created; permission target granted on a production repository; admin group membership change; a spike in failed authentication against Artifactory; anomalous bulk downloads.
Naming. Suggesting
jfrog_artifactoryfor the package. If JFrog Xray or other JFrog Platform services are likely to follow, a broaderjfrogpackage with per-service data streams may age better — happy to follow whatever the team prefers.References