You can't write a document about your own prod systems without knowing what (if any!) cryptography *your* prod systems use.
On Wed, Jan 21, 2026 at 1:27 AM ManiR <[email protected]> wrote: > 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 >> -- >> > -- Death to <Redacted>, and butter sauce. Don't boil me, I'm still alive. <Redacted> lobster!
