[New Integration] JFrog Artifactory

### 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 `` / `` 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**

- [Audit Trail Log](https://docs.jfrog.com/administration/docs/audit-trail-log) — fields, log path, rotation
- [Manage Audit Logs](https://docs.jfrog.com/administration/docs/manage-audit-logs)
- [Access Log](https://docs.jfrog.com/administration/docs/access-log)
- [JFrog Cloud Log Streaming](https://docs.jfrog.com/administration/docs/jfrog-cloud-log-streaming) — log types and supported destinations, including Elastic
- [Cloud Log Collection](https://docs.jfrog.com/administration/docs/cloud-log-collection)

Start by reviewing package conventions under packages/ and the self-hosted access-security-audit.log format; confirm whether JFrog Cloud Log Streaming sends structured or pipe-delimited records and settle the filestream versus cloud scope. Done means the supported streams, collection path, ECS mappings, and proposed content are agreed.

Written by the indexing model from the issue text.