Is your feature request related to a problem? Please describe.
We parse jf audit --format=json and jf ca --format=json output directly in an internal tool. Between two captures, we explicitly updated jf from 2.109.0 to 2.120.0. Across that jump, jf audit's JSON shape changed on a clean (zero-violation) scan.
Controlled comparison, same project (private, name redacted here), same run conditions, jf ca --format=json only, diffed byte-for-byte:
jf 2.109.0 and jf 2.120.0 produced identical output.
So this is not a claim that jf's JSON output is broadly unstable — jf ca held steady across the same version jump. The problem is scoped to jf audit.
Less-controlled comparison — two jf audit --format=json captures of a clean scan, at different jf versions (Fixture A's exact version wasn't recorded, and it's a different project than Fixture B, so this pair has two confounds, not one; noting that plainly rather than glossing over it):
Fixture A (older, version unrecorded):
[
{
"scan_id": "b1977de9-086b-436b-b5da-d433b9d24057",
"violations": [],
"component_id": "<group>:<artifact>:1.0-SNAPSHOT",
"package_type": "Maven",
"status": "completed"
}
]
Fixture B (jf 2.120.0):
[
{
"scan_id": "ad47729c-b7f9-429e-b966-e8880bfeb11d",
"component_id": "root",
"package_type": "generic",
"status": "completed"
}
]
| Field |
Fixture A |
Fixture B (2.120.0) |
Same? |
violations |
present, [] |
absent entirely |
❌ |
component_id |
real Maven GAV |
"root" |
❌ |
package_type |
"Maven" |
"generic" |
❌ |
status |
"completed" |
"completed" |
✅ |
The concerning part isn't any single field value — it's that violations can disappear entirely with no schema-version marker and no changelog signal we could find. A missing violations key is easy for a consumer to misread as "no violations," which is the dangerous direction to be wrong in for a security-scanning command specifically.
Describe the solution you'd like to see
We're not asking you to restore either specific shape above — we don't know which (if either) is "correct." We're asking for a stability contract for --format=json output, starting with jf audit and jf ca:
- A documented, versioned JSON schema per command, and/or
- A schema-version field embedded in the JSON output itself, bumped and changelogged whenever the shape changes
so that scripts, CI pipelines, or agents parsing this output can detect a shape change and fail loudly instead of silently misinterpreting missing/renamed fields.
JFrog CLI version: 2.109.0 → 2.120.0
Is your feature request related to a problem? Please describe.
We parse
jf audit --format=jsonandjf ca --format=jsonoutput directly in an internal tool. Between two captures, we explicitly updatedjffrom 2.109.0 to 2.120.0. Across that jump,jf audit's JSON shape changed on a clean (zero-violation) scan.Controlled comparison, same project (private, name redacted here), same run conditions,
jf ca --format=jsononly, diffed byte-for-byte:jf2.109.0 andjf2.120.0 produced identical output.So this is not a claim that
jf's JSON output is broadly unstable —jf caheld steady across the same version jump. The problem is scoped tojf audit.Less-controlled comparison — two
jf audit --format=jsoncaptures of a clean scan, at differentjfversions (Fixture A's exact version wasn't recorded, and it's a different project than Fixture B, so this pair has two confounds, not one; noting that plainly rather than glossing over it):Fixture A (older, version unrecorded):
[ { "scan_id": "b1977de9-086b-436b-b5da-d433b9d24057", "violations": [], "component_id": "<group>:<artifact>:1.0-SNAPSHOT", "package_type": "Maven", "status": "completed" } ]Fixture B (
jf2.120.0):[ { "scan_id": "ad47729c-b7f9-429e-b966-e8880bfeb11d", "component_id": "root", "package_type": "generic", "status": "completed" } ]violations[]component_id"root"package_type"Maven""generic"status"completed""completed"The concerning part isn't any single field value — it's that
violationscan disappear entirely with no schema-version marker and no changelog signal we could find. A missingviolationskey is easy for a consumer to misread as "no violations," which is the dangerous direction to be wrong in for a security-scanning command specifically.Describe the solution you'd like to see
We're not asking you to restore either specific shape above — we don't know which (if either) is "correct." We're asking for a stability contract for
--format=jsonoutput, starting withjf auditandjf ca:so that scripts, CI pipelines, or agents parsing this output can detect a shape change and fail loudly instead of silently misinterpreting missing/renamed fields.
JFrog CLI version: 2.109.0 → 2.120.0