Feature/xray 144147 onboard yarn v4

[gauriy-tech]

• The pull request is targeting the dev branch.
• The code has been validated to compile successfully by running go vet ./....
• The code has been formatted properly using go fmt ./....
• All static analysis checks passed.
• All tests have passed. If this feature is not already covered by the tests, new tests have been added.
• Updated the Contributing page / ReadMe page / CI Workflow files if needed.
• All changes are detailed at the description. if not already covered at JFrog Documentation, new documentation have been added.

What

Onboards Yarn V4 (Berry, native .yarnrc.yml mode) to jf curation-audit (jf ca),
and unifies Yarn V3 + V4 curation on a metadata-only lockfile resolution path.

Why / Design

jf ca must build a complete yarn.lock to enumerate the dependency graph, without
downloading tarballs (curation blocks blocked tarballs with a 403, which aborts a normal
install before the lockfile is written).
Approaches considered:

• yarn install --mode=update-lockfile (previous V3 behavior): rejected — it still
  fetches uncached tarballs to compute checksums, so a curation 403 on a blocked uncached
  package aborts before yarn.lock is written.
• Hosted plugin via yarn plugin import <url>: rejected — adds a runtime network
  dependency, breaks air-gapped CI.
• .yarnrc.yml flags (enableNetwork: false, etc.): rejected — doesn't produce a
  complete lockfile for uncached packages.
• Chosen: embedded resolution-only plugin (jfrog-yarn-resolve-lockfile.cjs, //go:embed).
  It calls project.resolveEverything() + project.persistLockfile() — resolving the full
  graph from registry metadata only (no tarball fetch), so blocked packages never abort
  the lockfile. The plugin is written into the per-run temp dir, never the customer's project.
  V3 behavior change (intentional): V3 curation previously used --mode=update-lockfile;
  it now uses the same embedded plugin as V4. V3 had the identical tarball-fetch abort problem,
  so this gives V3 strictly better behavior and keeps V3/V4 on one code path.

Highlights

• Yarn V4 native mode: registry + auth read from .yarnrc.yml (no jf yarn-config step).
• Non-invasive: all resolution happens in a temp copy; the only touch to the original project
  is bumping yarn.lock mtime so the next run can skip re-resolution.
• Full workspace coverage: attachWorkspaceMembersToRoot audits every workspace member's
  dependencies from the root, matching npm/pnpm.
• --run-native is a no-op for Yarn V4 (always native) with a deferred warning.
• V1 is rejected up front with an actionable message; V2 falls back to direct-dependency probing.

Tests

• TestRegisterYarnPluginInYarnrc, TestAttachWorkspaceMembersToRoot (yarn package)
• TestPromoteYarnWorkspaceMember incl. the $HOME-stop case (curation package)

---

---

[gauriy-tech]

I have read the CLA Document and I hereby sign the CLA

[attiasas]

Nice work!, check out my comments

In addition, please add integration tests at: curation_test.go

[github-actions]

📗 Scan Summary

• Frogbot scanned for vulnerabilities and found 1 issues

Scan Category	Status	Security Issues
Software Composition Analysis	✅ Done	Not Found
Contextual Analysis	✅ Done	-
Static Application Security Testing (SAST)	✅ Done	1 Issues Found 1 High
Secrets	✅ Done	-
Infrastructure as Code (IaC)	✅ Done	Not Found

---

🐸 JFrog Frogbot

[github-actions]

🎯 Static Application Security Testing (SAST) Vulnerability

Severity	Finding
High	Untrusted input is included in web page content

Full description

Vulnerability Details

Rule ID:	go-xss

Overview

Cross-Site Scripting (XSS) is a vulnerability that allows attackers to inject
malicious scripts into web pages viewed by other users. These scripts can steal
sensitive information, hijack user sessions, deface websites, or redirect users
to malicious sites.

Vulnerable example

func displayMessage(w http.ResponseWriter, r *http.Request) {
    message := r.URL.Query().Get("message")
    fmt.Fprintf(w, "<h1>%s</h1>", message)
}

In this example, the displayMessage function retrieves a message from the
query parameters and directly embeds it into an HTML response without any
escaping. This makes it vulnerable to XSS attacks as an attacker could craft
a malicious message containing JavaScript code.

Remediation

To mitigate XSS vulnerabilities, always sanitize and encode user input before
embedding it into HTML responses:

func displayMessage(w http.ResponseWriter, r *http.Request) {
    message := r.URL.Query().Get("message")
    tpl.Execute(w, html.EscapeString(message))
}

In the remediation, we've introduced the html/template package to properly
escape and sanitize the message before embedding it into the HTML response.
We use html.EscapeString to mark the message as safe HTML content, ensuring it's
not escaped by the template engine.

Code Flows

Vulnerable data flow analysis result

↘️ r.Host (at curation_test.go line 274)

↘️ "http://" + r.Host (at curation_test.go line 274)

↘️ "http://" + r.Host + "/api/npm/npms/" (at curation_test.go line 274)

↘️ base (at curation_test.go line 277)

↘️ fmt.Sprintf({"name":"xml","dist-tags":{"latest":"1.0.1"},"versions":{"1.0.1":{"name":"xml","version":"1.0.1","dist":{"shasum":"97e0d0e9603c6ffd00fbf5419b3f48a6f4e0c7d9","tarball":"%sxml/-/xml-1.0.1.tgz"}}}}, base) (at curation_test.go line 277)

↘️ yarnPackument(r) (at curation_test.go line 256)

↘️ body (at curation_test.go line 257)

---

🐸 JFrog Frogbot

[attiasas]

omitempty is missing?