RTECO-2247: Add jf Install-/Save-/Update-/Publish-PSResource commands

[bhanurp]

Summary

Part of RTECO-2247 — registers four top-level commands wrapping PowerShell's PSResourceGet module: jf Install-PSResource, jf Save-PSResource, jf Update-PSResource, jf Publish-PSResource. Deliberately four separate commands (matching native PowerShell cmdlet names) rather than one jf psresource <verb> wrapper — unlike jf choco, which uses a single-command, first-positional-argument dispatch.

Depends on (must merge first, or this repo's go.mod needs re-pinning to released versions once they land):

• build-info-go: RTECO-2247: PSResource (PowerShell PSResourceGet) FlexPack collectors build-info-go#430
• jfrog-cli-core: RTECO-2247: Add PSResource project type jfrog-cli-core#1620
• jfrog-cli-artifactory: RTECO-2247: PSResource (PowerShell PSResourceGet) setup + FlexPack command jfrog-cli-artifactory#563

Note on go.mod: this branch carries replace directives pinning all three dependencies above to their own RTECO-2247(-psresource) branches (same canonical repos, not a fork) so this repo can build against the unreleased changes. Marked with an explicit release-blocking comment in go.mod — these need to come out once the sibling PRs merge and real released versions can be pinned.

What's here

• buildtools/cli.go — the four cli.Command entries, built from a shared table (psResourceCommandEntries) rather than four hand-duplicated literals, all backed by one psResourceCmd(cmdletName) helper.
• docs/buildtools/psresource/help.go — per-cmdlet help text, rendered from one shared template parameterized by a small cmdletMeta struct (the four cmdlets' help is ~90% identical prose).
• utils/cliutils/commandsflags.go — the shared flag set (--build-name, --build-number, --module, --project, --repo, --repo-resolve, --server-id).
• Integration tests (psresource_test.go) — help text on every platform, CLI-level build-flag-pair validation, and (skipping gracefully without a local pwsh + PSResourceGet install) end-to-end dependency/artifact build-info collection for all four commands.
• CI workflow (psresourceTests.yml) — cross-platform (Linux/macOS/Windows), unlike jf choco's Windows-only requirement, since PSResourceGet via pwsh is cross-platform.

Notable bug fix included (found via an adversarial multi-agent code review after the initial implementation)

• Curation audit silently disabled: WrapCmdWithCurationPostFailureRun was called with each cmdlet's own PascalCase name ("Install-PSResource", etc.) as cmdName, but jfrog-cli-security's post-failure curation audit gates on a fixed, generic verb allowlist ({install, build, i, add, ci, get, mod}) shared across every package manager — none of our names was ever in it, so the audit was a silent no-op for all four commands. Install/Save/Update now pass the matching "install" verb; Publish (which uploads rather than resolves a package, so curation can't block it the way this audit checks for) runs directly without a curation cmdName that would never apply.

Test plan

• go test . -run PSResource -v -args -test.psresource=true and go test ./buildtools/... ./docs/buildtools/psresource/... — all pass (end-to-end tests skip gracefully on this machine, which has no pwsh installed).

• New regression tests for the curation-cmdName fix, GetAIDescription's per-cmdlet map lookup, and dispatch-reaching coverage for Save/Update/Publish (previously only Install-PSResource's real dispatch logic was ever exercised past the shared --help early-return).

• golangci-lint clean, gofmt clean.

• All tests passed. New tests added for the bug found during review.

• All static analysis checks passed.

• This pull request is on the master branch.

• I used gofmt for formatting the code before submitting the pull request.

• Full flow was locally tested (help text on every platform; end-to-end paths verified with pwsh unavailable, which is the graceful-skip path).

🤖 Generated with Claude Code

---

Marked as draft: this repo's required No-Replace check hard-fails while any replace github.com/jfrog/* directive is active in go.mod (regardless of target) — and this branch needs one for each of build-info-go#430, jfrog-cli-core#1620, and jfrog-cli-artifactory#563 until they merge and this branch can pin real released versions. Will mark ready for review once those merge and the replace directives come out.

[github-actions]

View full scan results in JFrog Platform

📗 Scan Summary

• Frogbot scanned for vulnerabilities and found 3 issues

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

---

🐸 JFrog Frogbot

[github-actions]

NpmLocalRepositoryConfig

at utils/tests/consts.go (line 96)

🎯 Static Application Security Testing (SAST) Vulnerability

Severity	Finding
Low	Credentials for restricted resources included directly in source code

Full description

Vulnerability Details

Rule ID:	go-hardcoded-credentials

Overview

Hardcoded credentials are usernames, passwords, API keys, or other secrets
embedded directly in source code. This practice, identified by CWE-798, is
highly insecure because it makes it easy for anyone with access to the code to
discover and misuse the credentials. If the code is publicly released, shared,
or leaked, the credentials will be exposed to unauthorized parties.

Vulnerable example

In this example, the database username and password for the frog pond are
hardcoded directly in the source code as string literals. This is a major
security risk, as anyone who can read this file can steal the credentials and
gain unauthorized access to the database.

package main

import (
	"database/sql"
	"fmt"
	"log"

	_ "[github.com/go-sql-driver/mysql](https://github.com/go-sql-driver/mysql)"
)

func main() {
	// VULNERABLE: Hardcoded database credentials for the frog pond.
	frogUser := "pond_admin"
	frogPassword := "LeapFlog123!"
	pondName := "lilypad_db"

	connStr := fmt.Sprintf("%s:%s@tcp(127.0.0.1:3306)/%s",
		frogUser, frogPassword, pondName)

	lilypadDB, err := sql.Open("mysql", connStr)
	if err != nil {
		log.Fatalf("Error opening database: %v", err)
	}
	defer lilypadDB.Close()

	err = lilypadDB.Ping()
	if err != nil {
		log.Fatalf("Error pinging database: %v", err)
	}
	fmt.Println("Successfully connected to the frog pond.")
}

Remediation

The remediated code retrieves the database credentials from environment
variables instead of hardcoding them. This is a much more secure approach, as
it separates the secrets from the source code. This allows credentials to be
managed securely by deployment systems and rotated without changing the code.

package main

import (
	"database/sql"
	"fmt"
	"log"
	"os"

	_ "[github.com/go-sql-driver/mysql](https://github.com/go-sql-driver/mysql)"
)

func main() {
	// SECURE: Retrieve credentials from environment variables.
	frogUser := os.Getenv("FROG_DB_USER")
	frogPassword := os.Getenv("FROG_DB_PASS")
	pondName := os.Getenv("FROG_DB_NAME")

	if frogUser == "" || frogPassword == "" || pondName == "" {
		log.Fatal("DB credentials are not set in environment variables.")
	}

	connStr := fmt.Sprintf("%s:%s@tcp(127.0.0.1:3306)/%s",
		frogUser, frogPassword, pondName)

	lilypadDB, err := sql.Open("mysql", connStr)
	if err != nil {
		log.Fatalf("Error opening database: %v", err)
	}
	defer lilypadDB.Close()

	err = lilypadDB.Ping()
	if err != nil {
		log.Fatalf("Error pinging database: %v", err)
	}
	fmt.Println("Successfully connected to the frog pond.")
}

---

🐸 JFrog Frogbot

[github-actions]

NpmLocalScopedRespositoryConfig

at utils/tests/consts.go (line 97)

🎯 Static Application Security Testing (SAST) Vulnerability

Severity	Finding
Low	Credentials for restricted resources included directly in source code

Full description

Vulnerability Details

Rule ID:	go-hardcoded-credentials

Overview

Hardcoded credentials are usernames, passwords, API keys, or other secrets
embedded directly in source code. This practice, identified by CWE-798, is
highly insecure because it makes it easy for anyone with access to the code to
discover and misuse the credentials. If the code is publicly released, shared,
or leaked, the credentials will be exposed to unauthorized parties.

Vulnerable example

In this example, the database username and password for the frog pond are
hardcoded directly in the source code as string literals. This is a major
security risk, as anyone who can read this file can steal the credentials and
gain unauthorized access to the database.

package main

import (
	"database/sql"
	"fmt"
	"log"

	_ "[github.com/go-sql-driver/mysql](https://github.com/go-sql-driver/mysql)"
)

func main() {
	// VULNERABLE: Hardcoded database credentials for the frog pond.
	frogUser := "pond_admin"
	frogPassword := "LeapFlog123!"
	pondName := "lilypad_db"

	connStr := fmt.Sprintf("%s:%s@tcp(127.0.0.1:3306)/%s",
		frogUser, frogPassword, pondName)

	lilypadDB, err := sql.Open("mysql", connStr)
	if err != nil {
		log.Fatalf("Error opening database: %v", err)
	}
	defer lilypadDB.Close()

	err = lilypadDB.Ping()
	if err != nil {
		log.Fatalf("Error pinging database: %v", err)
	}
	fmt.Println("Successfully connected to the frog pond.")
}

Remediation

The remediated code retrieves the database credentials from environment
variables instead of hardcoding them. This is a much more secure approach, as
it separates the secrets from the source code. This allows credentials to be
managed securely by deployment systems and rotated without changing the code.

package main

import (
	"database/sql"
	"fmt"
	"log"
	"os"

	_ "[github.com/go-sql-driver/mysql](https://github.com/go-sql-driver/mysql)"
)

func main() {
	// SECURE: Retrieve credentials from environment variables.
	frogUser := os.Getenv("FROG_DB_USER")
	frogPassword := os.Getenv("FROG_DB_PASS")
	pondName := os.Getenv("FROG_DB_NAME")

	if frogUser == "" || frogPassword == "" || pondName == "" {
		log.Fatal("DB credentials are not set in environment variables.")
	}

	connStr := fmt.Sprintf("%s:%s@tcp(127.0.0.1:3306)/%s",
		frogUser, frogPassword, pondName)

	lilypadDB, err := sql.Open("mysql", connStr)
	if err != nil {
		log.Fatalf("Error opening database: %v", err)
	}
	defer lilypadDB.Close()

	err = lilypadDB.Ping()
	if err != nil {
		log.Fatalf("Error pinging database: %v", err)
	}
	fmt.Println("Successfully connected to the frog pond.")
}

---

🐸 JFrog Frogbot

[github-actions]

NpmRemoteRepositoryConfig

at utils/tests/consts.go (line 98)

🎯 Static Application Security Testing (SAST) Vulnerability

Severity	Finding
Low	Credentials for restricted resources included directly in source code

Full description

Vulnerability Details

Rule ID:	go-hardcoded-credentials

Overview

Hardcoded credentials are usernames, passwords, API keys, or other secrets
embedded directly in source code. This practice, identified by CWE-798, is
highly insecure because it makes it easy for anyone with access to the code to
discover and misuse the credentials. If the code is publicly released, shared,
or leaked, the credentials will be exposed to unauthorized parties.

Vulnerable example

In this example, the database username and password for the frog pond are
hardcoded directly in the source code as string literals. This is a major
security risk, as anyone who can read this file can steal the credentials and
gain unauthorized access to the database.

package main

import (
	"database/sql"
	"fmt"
	"log"

	_ "[github.com/go-sql-driver/mysql](https://github.com/go-sql-driver/mysql)"
)

func main() {
	// VULNERABLE: Hardcoded database credentials for the frog pond.
	frogUser := "pond_admin"
	frogPassword := "LeapFlog123!"
	pondName := "lilypad_db"

	connStr := fmt.Sprintf("%s:%s@tcp(127.0.0.1:3306)/%s",
		frogUser, frogPassword, pondName)

	lilypadDB, err := sql.Open("mysql", connStr)
	if err != nil {
		log.Fatalf("Error opening database: %v", err)
	}
	defer lilypadDB.Close()

	err = lilypadDB.Ping()
	if err != nil {
		log.Fatalf("Error pinging database: %v", err)
	}
	fmt.Println("Successfully connected to the frog pond.")
}

Remediation

The remediated code retrieves the database credentials from environment
variables instead of hardcoding them. This is a much more secure approach, as
it separates the secrets from the source code. This allows credentials to be
managed securely by deployment systems and rotated without changing the code.

package main

import (
	"database/sql"
	"fmt"
	"log"
	"os"

	_ "[github.com/go-sql-driver/mysql](https://github.com/go-sql-driver/mysql)"
)

func main() {
	// SECURE: Retrieve credentials from environment variables.
	frogUser := os.Getenv("FROG_DB_USER")
	frogPassword := os.Getenv("FROG_DB_PASS")
	pondName := os.Getenv("FROG_DB_NAME")

	if frogUser == "" || frogPassword == "" || pondName == "" {
		log.Fatal("DB credentials are not set in environment variables.")
	}

	connStr := fmt.Sprintf("%s:%s@tcp(127.0.0.1:3306)/%s",
		frogUser, frogPassword, pondName)

	lilypadDB, err := sql.Open("mysql", connStr)
	if err != nil {
		log.Fatalf("Error opening database: %v", err)
	}
	defer lilypadDB.Close()

	err = lilypadDB.Ping()
	if err != nil {
		log.Fatalf("Error pinging database: %v", err)
	}
	fmt.Println("Successfully connected to the frog pond.")
}

---

🐸 JFrog Frogbot