fix: extract & pass correct headers & header values to exhort

[Strum355]

Description

Based on the changes to the backend here: guacsec/trustify-dependency-analytics#514

Checklist

• I have followed this repository's contributing guidelines.
• I will adhere to the project's code of conduct.

Additional information

Anything else?

Will need to bump in vscode extension after merge

[qodo-code-review]

Review Summary by Qodo

Fix header names and extraction logic for Trustify backend

🐞 Bug fix

Walkthroughs

Description

• Updated header names from rhda-* to trust-da-* prefix
• Refactored setRhdaHeader() to accept explicit options key parameter
• Simplified getTokenHeaders() by removing vendor token loop logic
• Updated JSDoc and option names to use TRUSTIFY_DA_* prefix consistently

Diagram

flowchart LR
  A["Header Constants"] -->|Updated prefix| B["trust-da-* headers"]
  C["setRhdaHeader Function"] -->|Added optsKey param| D["Direct option lookup"]
  E["getTokenHeaders Function"] -->|Removed vendor loop| F["Simplified header setup"]
  G["JSDoc & Options"] -->|Renamed to TRUSTIFY_DA_*| H["Consistent naming"]

Loading

File Changes

1. src/analysis.js 🐞 Bug fix +14/-24

Update header names and refactor header extraction logic

• Changed header constant values from rhda-* to trust-da-* prefix (token, telemetry-id, source,
 operation-type, pkg-manager)
• Modified setRhdaHeader() function signature to accept optsKey parameter for direct option key
 lookup instead of deriving it from header name
• Removed vendor-specific token loop from getTokenHeaders() that handled snyk and oss-index tokens
• Updated all setRhdaHeader() calls to pass explicit option keys like TRUSTIFY_DA_TOKEN,
 TRUSTIFY_DA_SOURCE, etc.

src/analysis.js

---

2. src/index.js 📝 Documentation +3/-3

Align JSDoc option names with TRUSTIFY_DA prefix

• Updated JSDoc option names from RHDA_SOURCE, RHDA_TOKEN, RHDA_TELEMETRY_ID to
 TRUSTIFY_DA_SOURCE, TRUSTIFY_DA_TOKEN, TRUSTIFY_DA_TELEMETRY_ID
• Aligned option naming convention with backend changes for consistency

src/index.js

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (2) 📎 Requirement gaps (0)

✅ 1. trust-da-token logged in debug 📘 Rule violation ⛨ Security

Description

When TRUSTIFY_DA_DEBUG is true, header values are printed and trust-da-token is not excluded
by RegexNotToBeLogged, so the token can be logged. Additionally, getCustom() may log the value
of TRUSTIFY_DA_TOKEN because it does not match the current token-redaction regex, leaking secrets
into logs.

Code

src/analysis.js[R256-257]

if (process.env["TRUSTIFY_DA_DEBUG"] === "true") {
  console.log("Headers Values to be sent to Trustify DA backend:" + EOL)

Evidence

Compliance requires that no secrets/tokens appear in logs. The debug logging in getTokenHeaders()
prints all headers except those matching RegexNotToBeLogged, but the updated token header name is
trust-da-token (not matched by the regex). Separately, getCustom() logs keys not matching
RegexNotToBeLogged, and the new key TRUSTIFY_DA_TOKEN does not match
/TRUSTIFY_DA_.*_TOKEN|ex-.*-token/, so its value can be printed too.

Rule 5: Generic: Secure Logging Practices
Rule 6: Generic: Security-First Input Validation and Data Handling
src/analysis.js[12-16]
src/analysis.js[248-263]
src/tools.js[6-41]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Debug logging can print sensitive token values because `trust-da-token` and `TRUSTIFY_DA_TOKEN` are not covered by the current `RegexNotToBeLogged` redaction logic.
## Issue Context
- `getTokenHeaders()` prints header key/value pairs when `TRUSTIFY_DA_DEBUG === "true"`.
- `getCustom()` also logs option/env values in debug mode for keys not matching `RegexNotToBeLogged`.
- After this PR, token-bearing identifiers are `trust-da-token` (header) and `TRUSTIFY_DA_TOKEN` (option/env key), neither of which match `/TRUSTIFY_DA_.*_TOKEN|ex-.*-token/`.
## Fix Focus Areas
- src/analysis.js[248-263]
- src/analysis.js[12-16]
- src/tools.js[6-41]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. CLI validate-token broken 🐞 Bug ✓ Correctness

Description

Vendor-specific token headers (ex-snyk-token/ex-oss-index-token) are no longer generated, but the
CLI still sets TRUSTIFY_DA_<PROVIDER>_TOKEN. This makes the validate-token command (and any flow
still using vendor tokens) send no auth header and fail.

Code

src/analysis.js[R248-254]

function getTokenHeaders(opts = {}) {
-	let supportedTokens = ['snyk', 'oss-index']
let headers = {}
-	supportedTokens.forEach(vendor => {
-		let token = getCustom(`TRUSTIFY_DA_${vendor.replace("-", "_").toUpperCase()}_TOKEN`, null, opts);
-		if (token) {
-			headers[`ex-${vendor}-token`] = token
-		}
-		let user = getCustom(`TRUSTIFY_DA_${vendor.replace("-", "_").toUpperCase()}_USER`, null, opts);
-		if (user) {
-			headers[`ex-${vendor}-user`] = user
-		}
-	})
-	setRhdaHeader(rhdaTokenHeader, headers, opts);
-	setRhdaHeader(rhdaSourceHeader, headers, opts);
-	setRhdaHeader(rhdaOperationTypeHeader, headers, opts);
-	setRhdaHeader(rhdaPackageManagerHeader, headers, opts)
-	setRhdaHeader(rhdaTelemetryId, headers, opts);
+	setRhdaHeader(rhdaTokenHeader, headers, 'TRUSTIFY_DA_TOKEN', opts);
+	setRhdaHeader(rhdaSourceHeader, headers, 'TRUSTIFY_DA_SOURCE', opts);
+	setRhdaHeader(rhdaOperationTypeHeader, headers, rhdaOperationTypeHeader.toUpperCase().replaceAll("-", "_"), opts);
+	setRhdaHeader(rhdaPackageManagerHeader, headers, rhdaPackageManagerHeader.toUpperCase().replaceAll("-", "_"), opts)
+	setRhdaHeader(rhdaTelemetryId, headers, 'TRUSTIFY_DA_TELEMETRY_ID', opts);

Evidence

getTokenHeaders now only reads TRUSTIFY_DA_TOKEN (plus source/telemetry) and no longer maps
TRUSTIFY_DA_SNYK_TOKEN/TRUSTIFY_DA_OSS_INDEX_TOKEN to ex-*-token headers. The CLI validate-token
command still produces TRUSTIFY_DA_<provider>_TOKEN, and unit tests assert ex-snyk-token
behavior—indicating a repo-internal contract that is now broken.

src/analysis.js[248-255]
src/cli.js[29-55]
test/analysis.test.js[114-205]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR removed vendor-token header generation, but `src/cli.js` and unit tests still use `TRUSTIFY_DA_<PROVIDER>_TOKEN` and expect `ex-snyk-token` headers. This breaks `validate-token` and any vendor-token-based authentication.
### Issue Context
`getTokenHeaders()` now only reads `TRUSTIFY_DA_TOKEN` and no longer maps `TRUSTIFY_DA_SNYK_TOKEN`/`TRUSTIFY_DA_OSS_INDEX_TOKEN` into request headers.
### Fix Focus Areas
- src/analysis.js[248-255]
- src/cli.js[29-55]
- test/analysis.test.js[114-205]
### Suggested approach
Choose one:
1) **Migrate**: Change CLI validate-token to accept/set `TRUSTIFY_DA_TOKEN` (remove provider arg if no longer needed) and update tests accordingly.
2) **Compatibility**: Add fallback logic so `getTokenHeaders()` still emits `ex-snyk-token`/`ex-oss-index-token` when `TRUSTIFY_DA_SNYK_TOKEN`/`TRUSTIFY_DA_OSS_INDEX_TOKEN` are provided, while also supporting the new `trust-da-token` header.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. No RHDA_* fallback 🐞 Bug ⛯ Reliability

Description

Env/opts keys for auth/source/telemetry were changed to TRUSTIFY_DA_* without any fallback. Existing
users setting RHDA_TOKEN/RHDA_SOURCE/RHDA_TELEMETRY_ID (or tooling still producing them) will
silently stop sending headers.

Code

src/analysis.js[R236-240]

+function setRhdaHeader(headerName, headers, optsKey, opts) {
+	let rhdaHeaderValue = getCustom(optsKey, null, opts);
if (rhdaHeaderValue) {
  headers[headerName] = rhdaHeaderValue
}

Evidence

The header-value lookup now uses explicit option keys (e.g., TRUSTIFY_DA_TOKEN) and there is no code
path that checks RHDA_* keys. The public Options typedef also only documents TRUSTIFY_DA_* keys,
indicating a breaking rename with no compatibility shim.

src/analysis.js[236-254]
src/index.js[15-46]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The client now only reads `TRUSTIFY_DA_TOKEN/SOURCE/TELEMETRY_ID` and will ignore legacy `RHDA_*` settings, causing silent auth/telemetry/header omissions for existing deployments.
### Issue Context
`setRhdaHeader` was changed to read an explicit `optsKey` and `getTokenHeaders` only passes `TRUSTIFY_DA_*` keys.
### Fix Focus Areas
- src/analysis.js[236-254]
- src/index.js[15-46]
### Suggested approach
- In `getTokenHeaders`, attempt `TRUSTIFY_DA_*` first, then fallback to `RHDA_*` equivalents if present.
- Optionally, when `TRUSTIFY_DA_DEBUG=true`, log a single deprecation warning if `RHDA_*` keys are detected.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. rhda*Header names misleading 📘 Rule violation ✓ Correctness

Description

Constants like rhdaTokenHeader now hold Trustify DA header names (e.g., trust-da-token), which
is misleading and reduces self-documentation. This increases maintenance risk and the chance of
future misconfiguration.

Code

src/analysis.js[R12-16]

+const rhdaTokenHeader = "trust-da-token";
+const rhdaTelemetryId = "telemetry-anonymous-id";
+const rhdaSourceHeader = "trust-da-source"
+const rhdaOperationTypeHeader = "trust-da-operation-type"
+const rhdaPackageManagerHeader = "trust-da-pkg-manager"

Evidence

The naming compliance item requires identifiers to match their purpose/meaning. The rhda* constant
names suggest RHDA headers, but the values are Trustify DA header names, making the identifiers
misleading.

Rule 2: Generic: Meaningful Naming and Self-Documenting Code
src/analysis.js[12-16]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Header constants are still named with `rhda*` prefixes even though they now represent Trustify DA headers, which is misleading.
## Issue Context
The constants were updated to new Trustify DA header names (e.g., `trust-da-token`) but the identifier names were not updated accordingly.
## Fix Focus Areas
- src/analysis.js[12-16]
- src/analysis.js[228-241]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[ruromero]

I've added some comments on top of the AI review