How we work securely
How Engineer ApS builds and operates securely: the practices we hold to, how this site is hardened, and where to report a vulnerability.
Security is not a service we sell separately. It is how the work is done: the threat model is part of the design, the hardening is part of the build, and the proof is part of the handover.
How we build
- Least privilege by default. Services run as their own unprivileged users, with the narrowest access that lets them work. A component compromised is a component that cannot reach the next one.
- Secrets never reach the repository. Credentials live in a secret store or in the deployment layer, never in source and never in a build artefact. Automated scanning runs on every commit, and a hit stops the commit.
- Infrastructure described as code. Servers are built from a description that can be read, reviewed and rebuilt — so the configuration of a machine is a document under version control rather than a memory in somebody’s head.
- Dependencies pinned and audited. What a system is made of is written down, and the list is checked against published advisories rather than trusted because it worked last month.
- Encryption in transit, everywhere. Certificates are issued and renewed automatically, and the renewal is monitored, because the common way TLS fails is a certificate nobody was watching.
- Backups that are restored, not just taken. A backup is a claim until somebody restores from it. We test the restore.
How this site is built
We hold our own site to the same standard, and you can verify every line of this from your own browser.
- No backend, no database, no admin login. Every page is a static file written out before you asked for it, so there is no application to exploit, no session to steal, and no injection surface at all.
- One first-party script, under a kilobyte. It filters a list as you type. It makes no request, stores nothing and runs nowhere else.
- A strict Content Security Policy, declared in the page
itself, with
form-action 'none'— the site posts no forms anywhere. - Subresource Integrity on the stylesheet. The bundle is fingerprinted and hashed at build time, so your browser can verify it arrived unmodified.
- No third-party requests. No analytics, no embedded fonts, no map widget, no consent banner. Open your browser’s network panel and count the hosts: there is one, and it is ours.
- No cookies. The whole of what is and is not stored is on the cookies page.
- A machine-readable disclosure policy at
/.well-known/security.txt, so a researcher who finds something knows where to send it without asking.
How it is operated
One small server in Toronto, described in code, with the access log masked as it is written and kept about thirty days. The credits page names every piece of software on it; the privacy page says exactly what it records while it answers.
Reporting a vulnerability
If you have found a weakness in this site or in anything we operate, write to welcome@engineer.company and say what you found and how to reproduce it. We will confirm receipt, tell you what we are doing about it, and credit you if you would like to be credited. There is no bounty programme and no legal threat — just an address that reaches an engineer.
Want the same rigour applied to your own systems? ask us to look.
