How Daylit secures itself: a weekly test and Security Watch

Daylit tests itself. Every week we look at all our public addresses the way an outsider would. Every hour we hold the software in every container against the official lists of vulnerabilities. What we find, we see in our admin; what is urgent reaches us by mail straight away.

The weekly security test

Every week the platform itself tests every address Daylit serves: our own sites and our customers'. Gently, one request at a time, never logging in, never guessing passwords. Per address:

• Encryption: the certificate is valid and not about to expire; old protocols (TLS 1.0 and 1.1) are refused; http goes to https.
• Security headers: HSTS, nosniff, Referrer-Policy and clickjacking protection.
• What must stay private: no open .git, .env, wp-config backups, debug logs, phpinfo or directory listings.
• WordPress: no user names for strangers, xmlrpc closed, no version in the page.
• The router: only the ports we opened on purpose.

Every finding gets a level: high (fix now), medium or low. New findings of medium or higher reach us by mail at once.

Daylit Security Watch

Every hour Security Watch compares the software in every container with three official sources:

• the Debian security tracker: every known vulnerability per package, with the version that fixes it;
• CISA's list of vulnerabilities that are being exploited right now;
• the security advisories of the Dutch NCSC.

Per container we first take an inventory: the operating system, every package and its version, PHP, WordPress and its plugins. A package behind the fixed version is a finding; one on the list of active exploitation is critical.

Updates at Daylit go through the release pipeline: on Test first, then live. Shielding and patching are deliberate steps a person approves, so a quick fix never takes your site offline by accident.

What else we do

• A container per site: a hole in one site does not reach another.
• Two-step verification (passkey or app) for My Daylit, always required for admins; going live, going back and accepting keys ask for your passkey every time.
• Daily backups and a snapshot before every update.
• An audit log that cannot be changed unnoticed: who did what, and when.
• No secrets in packages or messages: keys and passwords live only in the environment that needs them.

Honest

An automated test does not find everything, and we do not (yet) hold a certification such as ISO 27001. We do build to those standards and write down what we do. Spot something that is not right? Mail us: we respond quickly and are happy to credit you if you like.