Proposed documentation page: Credentials optionally stored in plain text is not considered a vulnerability

To confirm:

This is saying if the credential is not necessary for the feature to operate or there are other ways to provide it that it is permissible to be unencrypted.

Where the credential is required and there is no other way to provide it encrypted or may still possibly be considered a vulnerability.

Is that correct interpretation of the proposal?

This seems like an odd delineation to me.

EDIT: Note this is focusing on the case of "the key is optional, but can only be stored unencrypted in the database"

I'll be the first to admit that there is always going to be some unencrypted boundary line on a server, there are obviously cases where unencrypted keys are not considered a vulnerability. CWE-312 would not be absolute in that regard that all unencrypted data is vulnerability. However generally where most of these are entered in a location where an administration is clearly aware of the fact that information is being stored in plain text (thus meeting a clearly understood security risk). I don't see that assumption holding true for a Drupal Form UI, which I would not expect a no-code user to understand is not securely stored (unless the form makes this clear the data is not securely stored).

As an analogy, most of us use a web browser that offers some from of password keeper feature (we may not utilize it however it is often there). When you enter your details in them you are expecting them to be stored as securely as they could possibly be.

In the Data Loss Prevention world we talk about data at rest, data in motion and data in use. From the standpoint of Drupal information stored in the Database that is not being actively read by Drupal is data at rest, and normally needs to be protected against theft. A simple SQL Exploit (such as SA-CORE-2026-004) poses a direct risk to API leakage of keys stored in the database insecurely. (Obviously we don't store everything encrypted as we are considering in layers of security required based on data sensitivity.)

The fact that Drupal Core does not contain built in encryption is not itself a valid defense for any code not to securely store the data.

There is a reason most of us use the Key module, it technically moves the vulnerability liability from us to the Key module (and the Key module usually moves it to the User by specifying that Config is NOT secure and expecting them to store it securely on disk, or use a key management system).

I'm not sure how to write the above into a simple policy, I'm only sure that a blanket exclusions on optional API keys doesn't seem like the best choice for a policy boundary. Must like the discussions reasonably on Captcha this feels more like a need for the DST to educate module owners and encourage them to disclose themselves out of responsibility.