There are two aspects for SBOM: (1) syntax/schema/fields and (2) actual
content (with respect to the actual dependencies).

We first focus on (1).


1. You can bump the Cyclone DX version number from 1.5 to 1.6, which is
the latest version.


2. The provided SBOM complies with Cyclone DX standard (1.5 & 1.6).
That means the data objects that are listed in the document do exist
and are valid, from a schema perspective. However elements can still be
missing.


3. One required element that is missing: the supplier name for each
component. Example for rocksb: 
{ 
  "bom-ref": "rocksdb-bba5e7b", 
  "type": "library", 
  "name": "rocksdb", 
  "version": "bba5e7b", 
  "purl": "github/facebook/rocksdb@bba5e7b", 
  "supplier" : { 
    "name" : "Facebook" 
  }     
}


4. Also missing: the dependencies list should list all components, not
only the top-level component, even if they have no dependencies.
Example: 
{ 
  "ref": "MariaDB", 
    "dependsOn": [ 
     ...
    ] 
  },
  { 
    "ref" : "zlib-1.3.1" 
  }, 
  ...



Optional:

5. The lifecyle phase that the SBOM was generated from can and should
be included in the metadata field (not sure if you are doing this
during build or post-build): 
"metadata": { 
  "lifecycles": [
    { "phase": "build"},
    { "phase": "post-build" }
  ]
}


And now to the content.
First, this section of the Wiki [1] is extremely important, because it
defines the dependency types and how they are used in the build
process.


1. If you are building from source and linking those artifacts into
your release, then the github PURLs are valid (assuming the source used
in your build process originates from or is identical to the Github
source).
The supplier name of this component can then be either the owner of the
repo (deduced from the URL github.com/$OWNER/repo) OR Github itself (as
they can be seen as the distributor of the source code).

2. If you are linking against a static lib that is provided by the
build environment, e.g. OS installed package, then you have to provide
that in the PURL. 
IIIRC, depending on what platform server is built and with what build
parameters, zlib or pcre2 might be linked this way.
In that case the package information has to be retrieved from the OS
package manager. E.g., the purl will then look like this:
pkg:deb/debian/zlib1g@1:1.2.13.dfsg-1?arch=amd64&distro=bookworm
The supplier in that case is Debian because they are distributing the
package.


3. This is not covered by SBOM spec, but is IMHO important:
disambiguation for the different platforms and architectures that
server is built for.
I suggest to use the metadata.properties[] element for that, e.g.
[ 
  { "name": "arch", "value" : "x86_64"},
  { "name" : "os", "value" : "Debian"}
]


[1] https://mariadbcorp.atlassian.net/wiki/x/HQDOjg