A security scan was run on a couple of servers I manage. In the resulting reports, some mastercard "matches" were found in the following file:


I'd like to show that I am being proactive in terms of security but:

  • I think it's pretty unlikely that any real mastercard details should be found in this file, considering my app does not save such information, nor even have it entered into a form
  • I am very loathe to delete or even move/rename this file because of potential deleterious effects on the functioning of postgresql

So my question is, how should I satisfy the security staff that:

  • the mastercard "matches" are false positives, or;
  • I have taken appropriate action to mitigate any potential security breaches?



Download the original PostgreSQL package (the same version that you have installed) from your OS package repository. Unpack it to /tmp and compare the original with your current version. They should be 100% identical, and if they're identical, then the numbers clearly weren't stored by your server but rather came directly from the OS maintainers or PostgreSQL developers.

Open the file and look inside. It is a text file, and in the middle it has several occurences of numbers that look like xxxx xxxx xxxx xxxx, some of which kinda look like bank card numbers. Use context to judge whether they are card numbers or not.

For example, line 2969 from version 11.4 has the text 4110 4111 3446 3447. Taken out of context it looks like a card number, and a lazily written regex could confuse this with the real thing (although it doesn't pass checksum verification).

But if you look at it in context it should be obvious that these are four separate fields with PostgreSQL internal parameters, which only happen to be 4-digit and next to each other, resulting in this potential false positive:

insert OID = 869 ( inet 11 10 -1 f b I t t "," 0 0 1041 910 911 2496 2497 - - - i m f 0 -1 0 0 _null_ _null_ _null_ )
insert OID = 650 ( cidr 11 10 -1 f b I f t "," 0 0 651 1267 1427 2498 2499 - - - i m f 0 -1 0 0 _null_ _null_ _null_ )
insert OID = 774 ( macaddr8 11 10 8 f b U f t "," 0 0 775 4110 4111 3446 3447 - - - i p f 0 -1 0 0 _null_ _null_ _null_ )
insert OID = 1000 [...]

I have taken appropriate action to mitigate any potential security breaches?

According to the official documentation they are only used to create the database system in the first place. However, if you do not know what the script was used for, you should not delete it. It is likely used to create the database.

Whomever, is responsible for the database, might be upset if you delete the only copy of the script used to create the database (in the event of a failure). Since the file is just a text document. You should output the script, and present it to the "security staff".

Backend Interface (BKI) files are scripts in a special language that is understood by the PostgreSQL backend when running in the "bootstrap" mode. The bootstrap mode allows system catalogs to be created and filled from scratch, whereas ordinary SQL commands require the catalogs to exist already. BKI files can, therefore, be used to create the database system in the first place. (And they are probably not useful for anything else.)

initdb uses a BKI file to do part of its job when creating a new database cluster. The input file used by initdb is created as part of building and installing PostgreSQL by a program named genbki.sh, which reads some specially formatted C header files in the src/include/catalog/ directory of the source tree. The created BKI file is called postgres.bki and is normally installed in the share subdirectory of the installation tree.

Source: Chapter 51. BKI Backend Interface

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.