Hi All, Thank you for the responses and suggestions so far.
We understand the suggestion to use an LLM as a starting point; however, for our compliance and audit requirements, we would like to ensure that the resulting CBOM is technically accurate and well-grounded in PostgreSQL’s actual behavior. Could you please let us know: - whether there are any *existing sample CBOMs or similar cryptographic inventories* available for PostgreSQL (even informal or community-created ones), and - what would be the *recommended approach or steps* to identify and document PostgreSQL’s cryptographic mechanisms accurately. If anyone has previously undertaken a *similar exercise* (CBOM, crypto inventory, or security documentation) for PostgreSQL, any guidance, references, or documentation outlining the *process followed* would be greatly appreciated. Thank you again for your time and help. Regards, Manikandan R On Wed, Jan 21, 2026 at 1:34 AM Nico Williams <[email protected]> wrote: > On Tue, Jan 20, 2026 at 02:47:36PM +0530, ManiR wrote: > > We would like your guidance on the *cryptographic mechanisms used by > > PostgreSQL*, including: > > FYI this is the sort of thing where LLMs shine. I would start by asking > an LLM to write this and then I'd have expert humans review it. > > Keep in mind that some of the cryptographic mechanism/algorithm usage is > transitive via PostgreSQL's dependencies (e.g., SASL, GSS-API, TLS), but > you might not be interested in expanding that (since you might want to > do separate CBOMs for those. > > Keep in mind that some uses are not actually uses, like the PG crypto > extension, which makes cryptography available to PG _applications_. > > You should also look at options to _not_ use cryptographic mechanisms. > I.e., options to use cleartext protocols. Obviously it's much worse to > have a cleartext protocol than one that uses, say, 1DES, even though > 1DES is so weak as to be useles. Often auditors have a blind spot here. > > And it's important not to treat the presence of, say, MD5 as fatal when > it's not being used for security-critical purposes. > > IMO, > > Nico > -- >
