Add cipher seeding with Rust SDK encryption to enable cryptographically correct test data generation

[theMickster]

🎟️ Tracking

https://bitwarden.atlassian.net/browse/PM-31013

📔 Objective

Continue to build on the initial success of the Seeder with incremental progress towards a solid tool.

1. Replaces hardcoded string arrays with a structured data system — enabling filtered and targeted test data generation
2. Adds 50 real companies across 3 geographic regions with domain, category, and type metadata
3. Introduces deterministic username generation to login ciphers
4. Implements 3 organizational structure models (Traditional, Spotify, Modern) for realistic collection hierarchies
5. Enhanced the CLI to allow for different organizational types
6. Encrypts all collection names via the Rust SDK
7. Establishes extensibility patterns for future cipher types

Please take a moment to read the README.md files, the CLAUDE.md, and a few of the TODOs in XML comments.
Those will help guide you towards where we will be going with the work.

🤖 Built with Claude Code

[claude]

Claude finished @theMickster's task in 6m 10s —— View job

---

Code Review Summary (Re-Review)

Reviewed PR: #6896 - Add cipher seeding with Rust SDK encryption to enable cryptographically correct test data generation

Review Type: Re-review after commit 8203ee148 ("Refactor org seeder")

Previous Review: Commit a3bfedad0

---

Changes Since Last Review

File	Change
util/Seeder/Factories/OrganizationSeeder.cs	Added default encryption keys as static fields; modified CreateEnterprise() to accept optional publicKey/privateKey parameters
util/Seeder/Recipes/OrganizationWithVaultRecipe.cs	Simplified organization creation by passing keys directly to factory method

Analysis of New Changes

The refactoring in commit 8203ee148 improves the API design:

1. Default keys added (lines 10-11): Static default public/private keys provide fallback values. This is acceptable for a test data seeder - the CLAUDE.md documentation explicitly states "Seeded keys are for testing only - regenerate for each test run."

2. API improvement: Passing keys as optional parameters (publicKey = null, privateKey = null) is cleaner than the previous pattern of creating the organization then mutating its properties. The recipe now uses a single constructor call:

   // Before (2 operations)
   var organization = OrganizationSeeder.CreateEnterprise(name, domain, seats);
   organization.PublicKey = orgKeys.PublicKey;
   organization.PrivateKey = orgKeys.PrivateKey;
   
   // After (1 operation)  
   var organization = OrganizationSeeder.CreateEnterprise(
       name, domain, seats, orgKeys.PublicKey, orgKeys.PrivateKey);

3. Unchanged behavior: Dynamic key generation still occurs via GenerateOrganizationKeys() - the defaults are only used when keys are not explicitly provided.

---

Review Assessment

No new issues identified. The refactoring is a minor improvement that does not introduce security, correctness, or breaking change concerns.

Existing Unresolved Threads

The PR has 4 unresolved discussion threads, all acknowledged for follow-up work:

Thread	Topic	Status
OrganizationSeeder type safety	Builder/type-state pattern for seeders	PM-31403 (high priority follow-up)
FolderSeeder usability	Clarification on folder-cipher assignment	Acknowledged for future PR
RustSdkService static members	SonarCloud suggestion	Minor refactoring discussion
Recipe complexity	Strategy pattern for cipher types	PM-31403

These represent ongoing architectural discussions that are appropriately scoped for follow-up PRs.

---

Result: Approved - no blocking issues

Reviewed at commit 8203ee1

[github-actions]

Checkmarx One – Scan Summary & Details – a23924bd-20fa-431e-becb-b06d427d2ed5

New Issues (6)

Checkmarx found the following issues in this Pull Request

#	Severity	Issue	Source File / Package	Checkmarx Insight
1		CSRF	/src/Api/Auth/Controllers/AccountsController.cs: 291	details Method at line 291 of /src/Api/Auth/Controllers/AccountsController.cs gets a parameter from a user request from model. This parameter value flow... Attack Vector
2		CSRF	/src/Api/Vault/Controllers/CiphersController.cs: 1178	details Method at line 1178 of /src/Api/Vault/Controllers/CiphersController.cs gets a parameter from a user request from id. This parameter value flows ... Attack Vector
3		CSRF	/src/Api/Vault/Controllers/CiphersController.cs: 1062	details Method at line 1062 of /src/Api/Vault/Controllers/CiphersController.cs gets a parameter from a user request from id. This parameter value flows ... Attack Vector
4		CSRF	/src/Api/Vault/Controllers/CiphersController.cs: 1527	details Method at line 1527 of /src/Api/Vault/Controllers/CiphersController.cs gets a parameter from a user request from id. This parameter value flows ... Attack Vector
5		CSRF	/src/Api/Vault/Controllers/CiphersController.cs: 1403	details Method at line 1403 of /src/Api/Vault/Controllers/CiphersController.cs gets a parameter from a user request from id. This parameter value flows ... Attack Vector
6		Use_Of_Hardcoded_Password	/util/Seeder/Factories/UserSeeder.cs: 58	details The application uses the hard-coded password DefaultPassword for authentication purposes, either using it to verify users' identities, or to acces... Attack Vector

Fixed Issues (2)

Great job! The following issues were fixed in this Pull Request

Severity	Issue	Source File / Package
	CSRF	/src/Api/Tools/Controllers/SendsController.cs: 68
	CSRF	/src/Api/Vault/Controllers/CiphersController.cs: 293

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 56.06%. Comparing base (67f8cbf) to head (8203ee1).
⚠️ Report is 18 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6896      +/-   ##
==========================================
- Coverage   56.08%   56.06%   -0.02%     
==========================================
  Files        1968     1969       +1     
  Lines       86974    87065      +91     
  Branches     7748     7755       +7     
==========================================
+ Hits        48776    48810      +34     
- Misses      36393    36447      +54     
- Partials     1805     1808       +3     

☔ 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.

[withinfocus]

This looks awesome and after a quick read makes sense to me, but @Hinton can perform something more thorough and so that you're aligned.

[Hinton]

A very high level review, hope to get back to reviewing this more in-depth by the end of the week.

[SaintPatrck]

CLAUDE.md looks good. Just one question about the README based on other threads.

[MGibson1]

Seeding

I really like the data production stuff you put together, especially the consistent generation thinking.

What is unclear to me is, since you're accepting a seed rather than a deterministic Random instance, are you using the same value everywhere or somehow iterating it? It seems like everything accepting a required, shared Random and a deterministic usage order would produce predictable results while ensuring we aren't just using the same array index for everything.

SDK drift risk

What is the challenge this approach presents regarding drift between the SDK shim being used here, the shimless SDK used in clients, and the non-sdk client code?

[theMickster]

Seeding

I really like the data production stuff you put together, especially the consistent generation thinking.

What is unclear to me is, since you're accepting a seed rather than a deterministic Random instance, are you using the same value everywhere or somehow iterating it? It seems like everything accepting a required, shared Random and a deterministic usage order would produce predictable results while ensuring we aren't just using the same array index for everything.

SDK drift risk

What is the challenge this approach presents regarding drift between the SDK shim being used here, the shimless SDK used in clients, and the non-sdk client code?

I see where you're headed and I agree that the pseudorandom data points aren't perfect and I agree that the Rust SDK interface is rough and needs refactoring, but that's the point of this POC at this point. Get it working + show meaningful return on investment and iterate fast with byte sized PRs.

For me, this is the first of 5-7 PRs that I want to churn through in the next 2 weeks.

What I do not want (nor what I really ever do with POC work like this) is to have one PR continue on for weeks with many commits and code churn that ends up being impossible for human review.

So big question for the team is whether or not we can accept the work as a feasible starting point knowing that we're going to idéate fast with many byte sized PRs in the next 2-3 weeks to get us just one Organization + Vault Recipe knowing that we've got a whole heck of a lot more planned beyond just this little thing here.

[theMickster]

@Hinton & @MGibson1 : Sonar Cloud is barking about the RustSdkService and it's members being marked as static. I am not considering it for this PR because it's an intrusive change at this point IMO, but is that something for the TODO list?

[MGibson1]

I don't see any comments by sonar cloud on this PR, can you link to the actual complaint? I don't see any issue with the pattern, isn't that generated by csbindgen, too?

[theMickster]

Sonar in VS Code was where I saw these. I think I am connected to our instance (I'll double-check). It's the standard issue static refactor. 🤔

Methods and properties that don't access instance data should be static (csharpsquid:S2325)

[theMickster]

We have an item added to the hit list to refactor this and the associated integration tests owned by admin console.
https://bitwarden.atlassian.net/browse/PM-31403