feat: Add support for credential manager options; add Secrets SDK Win32 persistence flag

[traeok]

What It Does

• Implements support for credential manager options in Imperative. Add a property for credentialManagerOptions at the root-level of the object in .zowe/settings/imperative.json to specify options to a credential manager.
• Implements support for providing a persistence override for setting credentials on Windows. When provided as the persist property in the credentialManagerOptions object, credentials are stored using the given persistence value. Incorrect persistence values are ignored and "enterprise" (CRED_PERSIST_ENTERPRISE, or 0x3) is the default.

How to Test

• Install dependencies and build all SDKs & CLI on this branch: npm install && npm run build
• Update your .zowe/settings/imperative.json file to contain the new credential manager option:

{
  "overrides": {
    "CredentialManager": "@zowe/cli"
  },
  "credentialManagerOptions": {
    "persist": "session"
  }
}

• Using the build of Zowe CLI, run ZOWE_IMPERATIVE_LOG_LEVEL=TRACE zowe --help
• Check the log at .zowe/logs/imperative.log and see the following:

[TRACE] [DefaultCredentialManager.js:96] [DefaultCredentialManager] Persistence level received (win32): session

• Run zowe config secure and enter in your secure values
• Check the Credential Manager in Windows and see that the secure props are saved with the given persistence level, e.g.:

Where the persistence shows "Logon session" with the example above.

Review Checklist
I certify that I have:

• updated the changelog
• manually tested my changes
• added/updated automated unit/integration tests
• created/ran system tests (provide build number if applicable)
• followed the contribution guidelines

To fix the problem, we should prevent storing any properties on namespaceObj whose keys could introduce prototype pollution—specifically "__proto__", "constructor", or "prototype". The simplest way to do this, and to minimize functional changes, is to add an explicit check that rejects such keys before performing the assignment. If such a key is detected, we should throw an error (e.g., using ImperativeError) and refuse the operation. This preserves all existing logic and validation, only adding a guard clause before the assignment in set.

Alternatively (and arguably even more robustly), we could replace the storage structure with a Map object. However, as this requires a potentially more extensive change (possibly impacting serialization and other logic), and the code is already interface-driven (ISettingsFile), the correct way with the smallest disruption is to simply prohibit dangerous keys.

All changes are to be made within the set method (lines 131-143) in packages/imperative/src/settings/src/AppSettings.ts.

No new imports are needed.

---

[traeok]

I agree, but this change would be considered a bug fix and not an enhancement. Given that there are already 2 enhancements in this PR, I feel that it's sensible to resolve this in a follow-up PR to keep PR changes minimal and relevant to original issue/request scope.

[codecov]

Codecov Report

❌ Patch coverage is 94.11765% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 91.84%. Comparing base (fdd6221) to head (3ef675c).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
...tive/src/security/src/CredentialManagerOverride.ts	85.18%	4 Missing ⚠️
...ackages/imperative/src/settings/src/AppSettings.ts	90.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2630      +/-   ##
==========================================
+ Coverage   91.81%   91.84%   +0.02%     
==========================================
  Files         644      645       +1     
  Lines       19143    19208      +65     
  Branches     4124     4146      +22     
==========================================
+ Hits        17577    17641      +64     
- Misses       1564     1565       +1     
  Partials        2        2              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[traeok]

Regarding the remaining SonarCloud issue: Member 'displayName: string' is never reassigned; mark it as readonly

While I agree, I'm choosing to leave the member as-is as this code has existed in the codebase for some time. We can revisit in v4 if we feel that its important to address.

[github-actions]

📅 Suggested merge-by date: 11/11/2025

[gejohnston]

I identified something that might be a typo in a comment, which is harmless, but might be misleading.

The results in the log are as follows:

[2025/10/28 17:20:41.970] [TRACE] [DefaultCredentialManager.js:96] [DefaultCredentialManager] Persistence level received (win32): session

[2025/10/28 17:17:15.879] [TRACE] [AppSettings.js:58] {
  overrides: { CredentialManager: '@zowe/cli' },
  credentialManagerOptions: { persist: 'session' }
}

I think that the log records are consistent with the code changes. The test instructions in the PR might be slightly wrong.

[gejohnston]

Minor detail: Unless I badly misunderstand, the comment about loading from "team config" is a typo.

[traeok]

Thanks Gene - I initially jotted this down as a to-do for this PR, but after some discussions offline & in standup we felt it was best to save that for v4. I updated the comment in 3ca7d34 to reflect that 👍

I also updated the PR description to more accurately reflect the message seen in the log.

[sonarqubecloud]

Quality Gate failed

Failed conditions
4 Security Hotspots
72.7% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud