Security · Disclosure
Security
Security is a design constraint, not a checklist. Here's how we practice it internally and how to reach us if you find a vulnerability.
Last updated: 25 May 2026
Our practices
How we build secure products
01
Threat modelling on every engagement
Before writing a line of code we ask: what are the assets, who are the adversaries, and what are the attack vectors? We use STRIDE and MITRE ATT&CK as analytical frameworks — not as checkbox exercises.
02
OWASP Top 10 as a baseline minimum
Every web platform we ship is reviewed against the current OWASP Top 10. Injection, broken authentication, sensitive data exposure, insecure deserialization — these are not acceptable in production code we authored.
03
Dependency management
We use automated tooling (Dependabot, Snyk, npm audit) to flag vulnerable dependencies before they reach production. We do not ship packages with known high or critical CVEs without documented risk acceptance from the client.
04
Secrets management
Secrets never live in source code or version control. We use environment variable management via platform-native secret stores. Credentials are rotated at the end of every engagement and each team member has the minimum access needed for their role.
05
Secure authentication by default
We implement auth with refresh-token rotation, short-lived access tokens, bcrypt password hashing (cost factor ≥ 12), CSRF protection, and rate limiting on all auth endpoints. MFA is recommended for every admin interface we build.
06
Security headers on every deployment
Content-Security-Policy, HTTP Strict Transport Security, X-Frame-Options, X-Content-Type-Options, Permissions-Policy — these are part of our standard deployment checklist, not optional extras.
07
Penetration testing
We offer black-box, grey-box, and white-box penetration testing as a standalone service. We also recommend our clients commission independent third-party pen tests on platforms we build — we are not the right people to test our own work.
Responsible disclosure
Found a vulnerability?
We operate a coordinated disclosure policy. If you've found a security issue in any system we operate, please tell us before going public — we'll work fast to fix it and credit you for the find.
Email us
Send details to security@logiclayersolution.uk with the subject line 'Vulnerability Report'. Encrypt sensitive details using our PGP key if needed (available on request).
We acknowledge
We will acknowledge receipt within 48 hours on business days and assign the report an internal tracking reference.
We investigate
We triage the report, reproduce the issue, and assess severity using CVSS 3.1. We will keep you updated at least every 5 business days.
We remediate
Critical and high severity findings are remediated within 7 days. Medium within 30 days. Low within 90 days. We will notify you when a fix is deployed.
Credit
With your permission, we will credit you by name in our security acknowledgements. We ask that you wait for our fix confirmation before public disclosure.
In scope
Out of scope
General security questions: security@logiclayersolution.uk