We looked at your server, your code and every website you run. Nothing was changed. This report shows what we found, what matters most, and how to fix each item.
Two items can be reached from the internet and lead to the server or to money. The single biggest step is closing SSH to the internet. Backups and updates are separate, fixable problems.
Reachable from the whole internet and leads to root, money or customer data: critical. Needs an insider account, a leaked key or a crafted request: high. Defence in depth: medium. Hygiene: low.
Business choices such as running coding agents are not findings. Only the missing guardrails around them are rated.
Immediate actions first, then every finding under six area headings, then how the system is set up today. Open a finding for the evidence and the fix.
The two criticals, then the four highs that remove the most risk. Each line opens the full finding with evidence and steps.
The biggest single step is closing SSH to the internet. Everything else gets easier once the only server is no longer reachable by anyone with a key.
Owners are roles, not names. Dates are our proposal; confirm them with us on the call.
Six areas: server access, secrets, updates, deployment, backups, and what is already done well.
In fullThe SSH port is reachable from the whole internet and one root key is shared by every operator
Port 22 answers from any address. All five operators sign in as root with the same key, so a single leaked laptop gives full control of the only server and there is no way to tell who did what.
In fullThe database port accepts connections from any address
PostgreSQL listens on all interfaces and the host firewall allows 5432 from anywhere. Password authentication is the only barrier.
In fullTLS 1.0 and 1.1 are still accepted
nginx negotiates TLS 1.0 and 1.1. No current browser needs them and payment-card rules forbid them.
In fullSecurity headers are missing on the storefront
No Content-Security-Policy, X-Frame-Options or Referrer-Policy is sent.
In fullThe live payment secret key is committed in the repository history
The production payment key appears in 14 commits. Anyone with read access to the repository, including two former contractors, can issue refunds and read customer payment records.
In fullThe environment file is readable by every local account
The file holding API keys has mode 644. Any process on the server can read every credential.
In full61 security updates are pending and the server has not restarted in 412 days
Unattended upgrades download packages but the kernel in memory is the one from the last boot. Published vulnerabilities for that kernel version include local privilege escalation.
The storefront runs on a Node release that no longer receives security fixes.
In fullChanges are edited directly on the production server with no review and no rollback
Staff and coding agents write to the live working tree. A watcher commits whatever it finds every two minutes. There is no review, no test gate and no tested way back.
In fullNothing outside the server checks whether the shop is up
The only health check runs on the server it is checking. When the server is down, so is the alert.
In fullApplication logs are kept for three days
Three days is too short to investigate an incident found a week later.
Listed for completeness. None is reachable from outside.
In fullDatabase backups are written to the same disk as the database
The nightly dump lands in /var/backups on the only volume. A disk failure, a ransomware event or a mistaken delete removes the database and every backup together. No restore has ever been tested.
In fullCertificates renew automatically and are valid on every domain
All three domains present a valid certificate with more than 60 days left and automatic renewal is working.
In fullThe admin panel requires two-factor sign-in
Every admin account has two-factor authentication enforced.
One server runs the shop, the database and the scheduled jobs. Two outside providers sit in front of it.
White boxes are other providers. The coral area is the one server the company runs.
Swipe sideways to see the whole diagram.
| Item | Today | Status |
|---|---|---|
| Operating system | Ubuntu 22.04 LTS | Supported |
| Kernel | 5.15.0-91, 412 days since restart | Restart due |
| Node runtime | 16.20.2 | End of life |
| PostgreSQL | 14.9 | Supported |
| Backups | Nightly, same disk | At risk |
| Monitoring | Local timer only | Gap |
Scroll sideways to see all columns.
Green is the target state: controls that should be in place before the next release.
Swipe sideways to see the whole diagram.
Read-only throughout. Nothing was changed.
| Rating | Means |
|---|---|
| Critical | Reachable from the whole internet without credentials and leads to the server, money or customer data. Or an active sign of compromise. |
| High | One realistic step away: an insider or contractor account, a leaked key, a crafted email or request. Or a credible data-loss or outage risk. |
| Medium | A defence-in-depth gap, drift, or a missing guardrail. |
| Low | Hygiene. |
| Info | Inventory or a verdict with no rating. |
| Pass | Controls that are in place and working. |
Automation itself is a business choice and is not rated. Only the missing guardrails around it are.