MySQL TLS is reported as unavailable on MySQL 8.4 and later

The check returns FAIL saying TLS is not available, on a server where TLS is configured and working. It reads `SHOW VARIABLES LIKE 'have_ssl'` and `have_openssl`. Both were deprecated in MySQL 8.0.26 and removed outright in MySQL 8.4.0, so the query comes back empty on any current MySQL and the check reads that as "no TLS". Check `SHOW VARIABLES LIKE 'tls_version'` instead - a non-empty value means TLS is available - or `SELECT @@ssl_cert`. MariaDB still exposes `have_ssl`, so the old query is only wrong on MySQL.

Docker Content Trust is still rewarded after Docker retired it

The check awards PASS for `DOCKER_CONTENT_TRUST=1`, and treats a host using Sigstore cosign as unsigned. Docker announced the retirement of Docker Content Trust and the notary.docker.io service in July 2025, with full retirement in June 2026. Setting that variable now breaks pulls of Docker Official Images rather than securing them. Verify signatures with Sigstore cosign or Notation. A PASS on this check is not evidence that your images are signed, and following its advice will break your pulls.

OCSP stapling is recommended for certificates that have no OCSP responder

The check warns that stapling is off, and turning it on changes nothing except an nginx warning in the error log. Let's Encrypt stopped including OCSP URLs in its certificates on 7 May 2025 and switched off its OCSP responders on 6 August 2025. With no responder URL in the certificate, `ssl_stapling on` is inert and nginx logs "ssl_stapling ignored, no OCSP responder URL in the certificate". Inspect the certificate for an OCSP URL first (`openssl x509 -noout -ocsp_uri -in cert.pem`). If it is empty, stapling is not applicable and the warning can be ignored. Certificates from CAs that still run responders are unaffected.

The end-of-life version lists are incomplete

A runtime or base image that is past end of life passes the check. Both checks compare against a version list hardcoded when the script was written, rather than querying a source that tracks end-of-life dates. As of August 2026 the following are also past end of life and are not flagged: PHP 8.1, Node.js 18 and 20, MySQL 5.7 and 8.0 (EOL 30 April 2026), PostgreSQL 12 and 13, MongoDB 5.0 and 6.0, Redis 6.x and 7.0/7.2, Ubuntu 20.04 standard support, Debian 10, Alpine 3.13 to 3.20, and Python 3.7 to 3.9. Check your own versions against endoflife.date rather than trusting a PASS here.

Per-container log limits are not seen

The check warns that log limits are unset on a host where every container caps its own logs. It reads only `/etc/docker/daemon.json`. Per-container `--log-opt max-size` flags and Compose `logging:` blocks are invisible to it. If your containers set their own limits, this is a false positive. Confirm with `docker inspect --format '{{.HostConfig.LogConfig}}' `. Setting a daemon-wide default is still worthwhile as a backstop for containers that do not.

no-new-privileges is reported missing when it is set without a value or daemon-wide

The check keeps warning that containers lack no-new-privileges after you added `--security-opt=no-new-privileges`, which is the exact fix its own message recommends. It only matches `no-new-privileges:true` or `no-new-privileges=true` in `HostConfig.SecurityOpt`. Docker also accepts the bare `no-new-privileges` and enforces it, but stores the string as typed, so the check misses it. A daemon-wide `"no-new-privileges": true` in `daemon.json` reaches every container without appearing in `SecurityOpt` at all. Use `--security-opt no-new-privileges=true` (Compose: `no-new-privileges=true`), which Docker and the check both accept. To see what a container actually got, run `grep NoNewPrivs /proc/ /status`: `1` means the flag is on whatever the check says. `docker info` lists `name=no-new-privileges` when the daemon-wide default is set.

Trivy and dockle findings are never counted

With trivy or dockle installed, the check returns PASS on an image for which the same tool, run by hand, reports critical CVEs, embedded secrets or fatal findings. The script counts findings by grepping the scanner JSON for compact strings: `"Severity":"CRITICAL"`, `"Class":"secret"` and `"level":"FATAL"`. Trivy and dockle both pretty-print their JSON with a space after the colon (`"Severity": "CRITICAL"`), so the patterns never match and every count stays at zero. The FAIL and WARN branches that depend on those counts cannot be reached. Do not read a PASS from these three checks as a clean scan. Run the scanner yourself and go by its own output: `trivy image --severity CRITICAL,HIGH `, `trivy image --scanners secret ` and `dockle `. The fallback branches that run when no scanner is installed are not affected.

SBOM Generation passes on any host that has Docker installed

The check returns PASS saying the docker sbom plugin is available, on a host where no SBOM tool of any kind is installed. It tests for the plugin with `docker sbom --help`. The Docker CLI answers `--help` on a command it does not know by printing its general help and exiting 0, so the test succeeds whether or not the plugin exists. The two WARN branches can only be reached on a host with no docker binary. Check for a generator directly with `command -v syft trivy`. To test the plugin itself, run `docker sbom` with no arguments: without the plugin it fails with an unknown command error. A host with none of these has no SBOM generator, whatever this check reports.

MongoDB authorization enabled outside mongod.conf is missed

The check returns FAIL on a MongoDB server that does require authentication. It greps `mongod.conf` for `authorization: enabled`. A server started with `--auth` on the command line, or a replica set using `keyFile` (which implies authorization), has neither line in the config file. Confirm with `db.adminCommand({getParameter: 1, authenticationMechanisms: 1})` or by attempting an unauthenticated connection. If authentication is genuinely enforced, this is a false positive.

A PostgreSQL WAL directory on its own mount is reported as sharing a disk

The check warns that transaction logs share a disk with the data directory, on a server where `pg_wal` is a separate mount point. It treats PostgreSQL WAL as co-located unless `pg_wal` is a symlink. A `pg_wal` that is itself a mount point is not a symlink, so it is misread. Compare the filesystems directly (`df /var/lib/postgresql/*/main /var/lib/postgresql/*/main/pg_wal`) as the MySQL branch of the same check already does. Different devices means the placement is correct.

The separate-netmask form in pg_hba.conf is not matched

The check passes on a server whose `pg_hba.conf` allows connections from anywhere. It matches only the CIDR form (`0.0.0.0/0`, `::/0`, `all`). The separate-netmask form `host all all 0.0.0.0 0.0.0.0 md5` is equally open and is not matched. `include` and `include_dir` directives, supported since PostgreSQL 16, are also not followed. Read the effective rules from the server itself with `SELECT * FROM pg_hba_file_rules;`, which resolves includes and normalises both address forms.

Known issues

11 CtrlOps Audit Checks That Are Currently Wrong

Software moves and check logic drifts behind it. These 11 checks currently report something that is not true on a current system. Each one is listed with the symptom, the cause, the result you should trust instead, and the vendor source. The affected pages say the same thing in place.

Verified August 2026. When a script is fixed, its entry is removed from this page rather than marked resolved, so everything listed here is currently true.

checks with drifted logic

pages affected

157

checks reviewed

Aug 2026

last verified

01
MySQL TLS is reported as unavailable on MySQL 8.4 and later
What you see
The check returns FAIL saying TLS is not available, on a server where TLS is configured and working.
Why
It reads `SHOW VARIABLES LIKE 'have_ssl'` and `have_openssl`. Both were deprecated in MySQL 8.0.26 and removed outright in MySQL 8.4.0, so the query comes back empty on any current MySQL and the check reads that as "no TLS".
What to trust instead
Check `SHOW VARIABLES LIKE 'tls_version'` instead - a non-empty value means TLS is available - or `SELECT @@ssl_cert`. MariaDB still exposes `have_ssl`, so the old query is only wrong on MySQL.
MySQL TLS EnforcementTransport Encryption
- MySQL 8.4 release notes: removed variables
- MySQL 8.0 deprecation of have_ssl
02
Docker Content Trust is still rewarded after Docker retired it
What you see
The check awards PASS for `DOCKER_CONTENT_TRUST=1`, and treats a host using Sigstore cosign as unsigned.
Why
Docker announced the retirement of Docker Content Trust and the notary.docker.io service in July 2025, with full retirement in June 2026. Setting that variable now breaks pulls of Docker Official Images rather than securing them.
What to trust instead
Verify signatures with Sigstore cosign or Notation. A PASS on this check is not evidence that your images are signed, and following its advice will break your pulls.
Image Signature VerificationImage Vulnerabilities
- Docker: Content Trust deprecation
- Sigstore cosign
03
OCSP stapling is recommended for certificates that have no OCSP responder
What you see
The check warns that stapling is off, and turning it on changes nothing except an nginx warning in the error log.
Why
Let's Encrypt stopped including OCSP URLs in its certificates on 7 May 2025 and switched off its OCSP responders on 6 August 2025. With no responder URL in the certificate, `ssl_stapling on` is inert and nginx logs "ssl_stapling ignored, no OCSP responder URL in the certificate".
What to trust instead
Inspect the certificate for an OCSP URL first (`openssl x509 -noout -ocsp_uri -in cert.pem`). If it is empty, stapling is not applicable and the warning can be ignored. Certificates from CAs that still run responders are unaffected.
OCSP StaplingTLS Configuration
- Let's Encrypt: ending OCSP support
- nginx ssl_stapling directive
04
The end-of-life version lists are incomplete
What you see
A runtime or base image that is past end of life passes the check.
Why
Both checks compare against a version list hardcoded when the script was written, rather than querying a source that tracks end-of-life dates.
What to trust instead
As of August 2026 the following are also past end of life and are not flagged: PHP 8.1, Node.js 18 and 20, MySQL 5.7 and 8.0 (EOL 30 April 2026), PostgreSQL 12 and 13, MongoDB 5.0 and 6.0, Redis 6.x and 7.0/7.2, Ubuntu 20.04 standard support, Debian 10, Alpine 3.13 to 3.20, and Python 3.7 to 3.9. Check your own versions against endoflife.date rather than trusting a PASS here.
End-of-Life RuntimesApplication SecurityEnd-of-Life Base ImageImage Vulnerabilities
- endoflife.date
05
Per-container log limits are not seen
What you see
The check warns that log limits are unset on a host where every container caps its own logs.
Why
It reads only `/etc/docker/daemon.json`. Per-container `--log-opt max-size` flags and Compose `logging:` blocks are invisible to it.
What to trust instead
If your containers set their own limits, this is a false positive. Confirm with `docker inspect --format '{{.HostConfig.LogConfig}}' <container>`. Setting a daemon-wide default is still worthwhile as a backstop for containers that do not.
Container Log LimitsDaemon & Socket
- Docker logging driver configuration
06
no-new-privileges is reported missing when it is set without a value or daemon-wide
What you see
The check keeps warning that containers lack no-new-privileges after you added `--security-opt=no-new-privileges`, which is the exact fix its own message recommends.
Why
It only matches `no-new-privileges:true` or `no-new-privileges=true` in `HostConfig.SecurityOpt`. Docker also accepts the bare `no-new-privileges` and enforces it, but stores the string as typed, so the check misses it. A daemon-wide `"no-new-privileges": true` in `daemon.json` reaches every container without appearing in `SecurityOpt` at all.
What to trust instead
Use `--security-opt no-new-privileges=true` (Compose: `no-new-privileges=true`), which Docker and the check both accept. To see what a container actually got, run `grep NoNewPrivs /proc/<pid>/status`: `1` means the flag is on whatever the check says. `docker info` lists `name=no-new-privileges` when the daemon-wide default is set.
No New PrivilegesContainer Hardening
07
Trivy and dockle findings are never counted
What you see
With trivy or dockle installed, the check returns PASS on an image for which the same tool, run by hand, reports critical CVEs, embedded secrets or fatal findings.
Why
The script counts findings by grepping the scanner JSON for compact strings: `"Severity":"CRITICAL"`, `"Class":"secret"` and `"level":"FATAL"`. Trivy and dockle both pretty-print their JSON with a space after the colon (`"Severity": "CRITICAL"`), so the patterns never match and every count stays at zero. The FAIL and WARN branches that depend on those counts cannot be reached.
What to trust instead
Do not read a PASS from these three checks as a clean scan. Run the scanner yourself and go by its own output: `trivy image --severity CRITICAL,HIGH <image>`, `trivy image --scanners secret <image>` and `dockle <image>`. The fallback branches that run when no scanner is installed are not affected.
Image Vulnerability ScanImage Vulnerabilities Image Secrets ScanImage Vulnerabilities Image Build Best PracticesImage Vulnerabilities
08
SBOM Generation passes on any host that has Docker installed
What you see
The check returns PASS saying the docker sbom plugin is available, on a host where no SBOM tool of any kind is installed.
Why
It tests for the plugin with `docker sbom --help`. The Docker CLI answers `--help` on a command it does not know by printing its general help and exiting 0, so the test succeeds whether or not the plugin exists. The two WARN branches can only be reached on a host with no docker binary.
What to trust instead
Check for a generator directly with `command -v syft trivy`. To test the plugin itself, run `docker sbom` with no arguments: without the plugin it fails with an unknown command error. A host with none of these has no SBOM generator, whatever this check reports.
SBOM GenerationImage Vulnerabilities
- Docker CLI test: a nonexistent command with --help exits 0
- Syft
09
MongoDB authorization enabled outside mongod.conf is missed
What you see
The check returns FAIL on a MongoDB server that does require authentication.
Why
It greps `mongod.conf` for `authorization: enabled`. A server started with `--auth` on the command line, or a replica set using `keyFile` (which implies authorization), has neither line in the config file.
What to trust instead
Confirm with `db.adminCommand({getParameter: 1, authenticationMechanisms: 1})` or by attempting an unauthenticated connection. If authentication is genuinely enforced, this is a false positive.
MongoDB AuthorizationAuthentication
- MongoDB: enable access control
10
A PostgreSQL WAL directory on its own mount is reported as sharing a disk
What you see
The check warns that transaction logs share a disk with the data directory, on a server where `pg_wal` is a separate mount point.
Why
It treats PostgreSQL WAL as co-located unless `pg_wal` is a symlink. A `pg_wal` that is itself a mount point is not a symlink, so it is misread.
What to trust instead
Compare the filesystems directly (`df /var/lib/postgresql/*/main /var/lib/postgresql/*/main/pg_wal`) as the MySQL branch of the same check already does. Different devices means the placement is correct.
Transaction Log PlacementConfiguration & Hardening
- PostgreSQL WAL configuration
11
The separate-netmask form in pg_hba.conf is not matched
What you see
The check passes on a server whose `pg_hba.conf` allows connections from anywhere.
Why
It matches only the CIDR form (`0.0.0.0/0`, `::/0`, `all`). The separate-netmask form `host all all 0.0.0.0 0.0.0.0 md5` is equally open and is not matched. `include` and `include_dir` directives, supported since PostgreSQL 16, are also not followed.
What to trust instead
Read the effective rules from the server itself with `SELECT * FROM pg_hba_file_rules;`, which resolves includes and normalises both address forms.
PostgreSQL Allowed HostsLeast-Privilege Permissions
- PostgreSQL pg_hba.conf
- PostgreSQL pg_hba_file_rules view

Audit your fleet

An audit you can check the working of, not just trust

Every threshold CtrlOps applies is published, and so is every place the check is wrong. $7/user/month after a 1 month free trial - no credit card required.

Windows

✓ Start instantly·✓ No credit card·✓ No sneaky autorenewals