RFC: Proposed Security Review Strategy ( rpm/deb inclusion )

[mdurighettomiriade]

Hi everyone,

Devrim, the maintainer of the PostgreSQL RPM repository (yum.postgresql.org), has recently updated the policy for including new extensions.
As detailed in his announcement ( PostgreSQL RPM Repo Security Review and Audit
), new additions are currently paused unless they include a comprehensive "security review of the code."

I think Devrim is right and we need to improve in this area.
We need to provide a formal, human-written security review document backed by continuous, verifiable evidence from our pipeline.

I am putting together a roadmap to fulfill this requirement and would love to get your thoughts, ideas, or feedback on whether this covers all the necessary bases.

Here is the proposed action plan:

1. Manual Security Review

We will draft a doc/SECURITY-REVIEW.md document signed by a reviewer. This will manually address the critical architectural questions that automated tools cannot catch and we need to define a formal workflow.

2. Enhancing our CI Security Pipeline

We already use CodeQL, scan-build, UBSan, and valgrind memcheck. As team we think to add:

ASan alongside UBSan for more exhaustive memory error detection across the entire test suite.

Custom Semgrep rules to catch our specific anti-patterns or more rules in CodeQL.

3. Supply Chain Security for Packagers

We should automatically generate an SBOM and run CVE scanning on our dependencies (like OpenSSL and libcurl) using tools like osv-scanner ( ) or syft ( https://github.com/anchore/syft ). Any suggestion on this point is valuable.

4. Unified Evidence Reporting and Release Tagging

Finally, we will add a ci-security-report stage to our pipeline that aggregates all the automated outputs (CodeQL, scan-build, UBSan, etc.) into a single, versioned Markdown artifact (with date, commit hash, and counts).
This artifact will act as the verifiable appendix to our manual SECURITY-REVIEW.md. Once the groundwork is laid, we will tag our next stable release (1.7.2) to provide the required checksum tarball and officially initiate the inclusion request.

What do you think about these roadmap ?

Are there any specific edge cases, tools, or security constraints I might have missed that we should include in the manual review?

Kind Regards