Shell scripts (.sh): executes system commands. Useful for inspecting PostgreSQL configs, access rights, env vars.

When running the shell script, the program sets the following environment variables that can be used inside the script:

SQL scripts (.sql): used to make queries to the PostgreSQL database in order to obtain information about settings, database objects, user rights, etc.

Currently, only one SELECT query is supported for SQL files. The result of this request is passed to the validator. This limitation should be taken into account when designing SQL checks; complex checks may require either a more complex SELECT query or splitting into several separate checks.

For validators that process results of sh-scripts:

Example Lua script for shell script validation simple_bash_validate.lua:

-- GLOBAL DATA

-- result.stdout the output of stdout from the executed bash script
-- result.stderr the output of stderr from the executed bash script
-- result.return_code the return code from the executed bash script

function validate_result()
	local success = true
	local status_str = "Success"
	local short_desc = "The check was successful"
	local full_desc = "All parameters meet the requirements"
	local recommend = "No action is required"

	if not result.stdout == "hello world" then
		status_str = "Warning"
		short_desc = "Validation error"
		full_desc = "The X parameter does not match the Y format"
		recommend = "Fix the X parameter"
	end

	-- Important! The return value should look exactly like this.
	-- That is, the structure (table) should not change.
	-- {
	--		status: one of the values is (Warning, Info, Error, Success, Failed)
	--		short_description: String
	--		full_description: String
	--		recommendation: String
	-- }
	local result_table = {
			status = status_str,
			short_description = short_desc,
			full_description = full_desc,
			recommendation = recommend
	}
	return result_table
end

For validators that process results of SQL scripts:

The Lua script receives a global table sql_results. This table is an array where each element is a table corresponding to a row of the SQL query result. The field names in these nested tables match the column names in the SELECT query.

Example Lua script for SQL validation simple_sql_validate.lua:

-- GLOBAL DATA

-- sql_results a table with the result of SQL execution

function validate_result()

    local success = true
    local status_str = "Success"
    local short_desc = "Error: SQL data is not received or incorrect"
    local full_desc = "All parameters meet the requirements"
    local recommend = "No action is required"

    -- Checking for the presence of the first line
    if sql_results and sql_results[1] then
        -- Getting the first row (this is a table)
        local first_row = sql_results[1]

		-- an example for a table of the form:
		-- pg_version
		------------------------
		-- pg version data bla bla bla
        if first_row and type(first_row) == 'table' and first_row.pg_version then

            short_desc = first_row.pg_version
            status_str = "Success" 
            full_desc = "Version PostgreSQL: " .. short_desc
        else
             short_desc = "Error: The 'pg_version' field was not found in the SQL result"
             status_str = "Failed"
        end
    else
        -- sql_results is empty
        status_str = "Failed"
    end

	-- Important! The return value should look exactly like this.
	-- That is, the structure (table) should not change.
	-- {
	--		status: one of the values is (Warning, Info, Error, Success, Failed)
	--		short_description: String
	--		full_description: String
	--		recommendation: String
	-- }

    local result_table = {
            status = status_str,
            short_description = short_desc,
            full_description = full_desc,
            recommendation = recommend
    }
    return result_table
end

Html: generates a report as an HTML page. This format is suitable for visual analysis, as it supports interactive elements, styling, and is easily readable in a web browser.

Json: generates the report in JSON format. This is a plain-text, machine-readable format commonly used for data exchange between systems. JSON reports are well-suited for automated processing, integration with monitoring or SIEM systems, or further analysis via scripts and other tools.

Full: when this option is selected (and it is the default), the program generates reports in all supported formats simultaneously (i.e., both HTML and JSON). This allows users to obtain both a human-readable version for immediate inspection and a machine-readable version for automation—without needing to re-run the utility. Output filenames are based on the value of the --output argument, with appropriate .html and .json extensions.

The --groups option allows selective execution of specific check groups, defined as keys in the section object of the configuration file. This is useful for targeted testing or staged audits.

The --unsecure option is intended for special use cases. In release builds, the program by default verifies the checksums of all its components—including bundled executor and validator scripts. This ensures tool integrity and protects against accidental or malicious modifications. If any of these files have been altered (e.g., during development or customization of standard checks), the program will refuse to run and report a checksum mismatch error. The --unsecure flag bypasses this verification, allowing the tool to run with modified files.