Self-Hosted Security Baseline Scorecard

Table of contents

• What the score means
• How the method works
• The ten controls
• How to interpret the bands
• What to fix first
• Boundary review and recovery
• Exporting and sharing safely

What the score means

The scorecard is a practical evidence check: it reveals missing ownership, weak operating habits, and unverified assumptions, but it cannot guarantee security, certify a deployment, or replace technical review.

A high score matters only when backed by current notes, configuration evidence, and repeatable practice. A self-hosted service may have strong authentication and still be exposed through an overlooked port, owned by nobody, or impossible to restore. Use the result as a prioritized work queue.

The approach follows the risk-management direction of the NIST Cybersecurity Framework 2.0 and the prioritized baseline actions in CISA’s Cross-Sector Cybersecurity Performance Goals. It is deliberately narrower than a full framework assessment and aimed at practical operation of a small self-hosted environment.

How the method works

Each of ten controls gets one answer:

• Yes = 10 points: the control is in place and useful evidence can be named.
• Partial = 5 points: protection exists, but coverage, ownership, documentation, or testing is incomplete.
• No = 0 points: the control is absent, unknown, or unsupported by credible evidence.

The maximum is 100. Evidence quality is not automatically scored. Keep a short note stating what was checked, where it can be verified, and when it was last reviewed. If you cannot verify an answer, choose Partial or No rather than treating intention as implementation.

The widget keeps one note per control, exports a dated JSON record, and generates a normal dofollow HTML link containing the score and rating. All processing happens locally in the browser. It does not need passwords, tokens, private keys, recovery codes, or configuration secrets. Notes should still be written as if another reviewer will read them.

The ten controls

These controls are connected. Strong authentication has limited value when exposure is unknown; a backup has limited value when restore has never worked.

1. Named owner. One person or team is accountable for access, updates, backups, security decisions, and incident actions. Evidence might be a maintained service record, runbook, or ownership entry.

2. Defined security-update process. You can track updates for the host, operating system, images, reverse proxy, identity provider, and important dependencies, with review notes and a safe rollback path. No arbitrary universal patch deadline is required.

3. Strong admin authentication. Administrative access uses strong credentials and an appropriate second factor where available. Separate admin access from ordinary use and protect remote administration deliberately. The OWASP Authentication Cheat Sheet covers MFA, re-authentication, throttling, and sensitive accounts.

4. Least privilege. Users, services, containers, jobs, and administrators receive only needed permissions. Remove stale accounts, avoid shared admin identities, and review access after ownership or architecture changes.

5. Inventory of internet exposure and ingress. You know which services are public, VPN-only, or local; which ports are forwarded; and which proxy, DNS, firewall, relay, or IPv6 rules provide access. Include dashboards, management panels, and temporary routes.

6. Controlled secret storage and rotation. Passwords, API keys, certificates, signing keys, and connection strings are kept under controlled access rather than scattered through shell history, repositories, images, or shared notes. There is a path for creation, rotation, revocation, and recovery. The OWASP Secrets Management Cheat Sheet covers lifecycle and access practices.

7. Protected backups that passed restore. Important data and configuration are backed up away from the live service’s credentials and access path. At least one restore has been exercised and documented; a successful backup job alone is not proof of recovery.

8. Retained security logs and alerts. Authentication events, privilege changes, admin actions, configuration changes, failures, and meaningful access events are retained long enough to investigate, with alerts reaching someone who can act. Follow the OWASP Logging Cheat Sheet and keep passwords, tokens, keys, and other sensitive values out of logs.

9. Vulnerability review for images and dependencies. Review container images, operating-system packages, application dependencies, and deployment inputs for known weaknesses. Record what was checked, what was accepted, and what was updated or removed.

10. Exercised incident procedure. Maintain a written path for suspected compromise: contain access, preserve useful evidence, rotate affected secrets, restore or rebuild safely, notify the right people, and record follow-up work. Exercise it with a small scenario before an outage forces improvisation.

How to interpret the bands

These bands are OpenAlt’s disclosed rubric, not an audit standard. They prioritize work; they do not establish compliance or predict the likelihood of compromise.

Score	Rating	Practical meaning
85–100	Ready with evidence	Most baseline controls are in place and supported by notes or records; continue review and address exceptions.
65–84	Close, gaps remain	Useful safeguards exist, but gaps may undermine design, access control, or recovery.
40–64	High-risk gaps	Important controls are missing, unknown, or untested; limit exposure and fix high-impact weaknesses first.
0–39	Not ready	Foundational controls or evidence are insufficient; begin with ownership, access, exposure, backups, and updates.

A Ready with evidence result still permits a serious weakness. One exposed admin panel, unrecoverable database, or unrotated high-value token can outweigh several low-impact improvements. The score is not a guarantee, certification, or probability of compromise.

What to fix first

Fix the paths that could create broad access or permanent data loss before polishing documentation.

1. Reduce unnecessary internet exposure, especially for administration, databases, dashboards, and host management.
2. Protect privileged accounts with strong authentication, separate admin paths, and reviewed permissions.
3. Confirm backups are protected from the live environment and complete a restore test.
4. Find shared, embedded, stale, or untracked secrets; rotate the most consequential ones first.
5. Retain useful logs and alert on authentication, privilege, configuration, and service failures.
6. Establish an update and vulnerability-review process.
7. Document ownership and exercise the incident procedure.
8. Complete lower-risk documentation after the high-impact paths are covered.

Do not delay a dangerous fix while waiting for perfect records. Make the change, record what was verified, and leave a clear next action.

Boundary review and recovery

“Private” is a description to verify, not a security control. A service may be reachable through a forwarded port, reverse proxy, VPN account, overlay network, remote-management tool, cloud relay, DNS mistake, IPv6 route, or compromised client. Review every path into the host and every path between services.

For each service, ask:

• What address and port accept connections?
• Which network or identity can reach it?
• Is authentication enforced before the application loads?
• Can it reach the host, other containers, backups, or secret stores?
• What changes when proxy, firewall, VPN, or DNS settings change?

This connects exposure inventory with least privilege. The NIST Cybersecurity Framework treats understanding and managing cybersecurity risk as ongoing work, while CISA’s goals organize practical actions across Govern, Identify, Protect, Detect, Respond, and Recover.

Recovery is a security control, not merely an operations task. If an attacker can alter live data and the only backup through the same account, host, or storage path, recovery may fail when it matters. Protect backups, restrict deletion, monitor backup jobs, and test restoration using a documented procedure. A restore test demonstrates recoverability; a green job status only demonstrates that a job ran.

For deployment patterns, see the Authentik Docker Compose guide and Vaultwarden Docker Compose guide. For logging and alerting ideas, browse the monitoring category and the wider self-hosted guides.

Exporting and sharing safely

Share decisions and evidence references, not secret values. Before exporting JSON or publishing the generated link:

• Remove passwords, tokens, private keys, recovery codes, session values, and connection strings from notes.
• Do not paste full environment files, raw logs, firewall exports, or backup manifests.
• Replace sensitive hostnames, usernames, public addresses, and internal paths with neutral labels when unnecessary.
• Keep the date and control notes so a reviewer can understand what was checked.
• Treat the HTML link as a score-and-rating summary, not a security attestation.

Local browser processing reduces unnecessary data transfer, but it does not make notes safe by default. Review the export before sending it to a collaborator, posting it in a repository, or attaching it to an issue. A useful report explains what is true, what remains uncertain, and what action comes next—without disclosing the material needed to access the environment.