// Security by default
What 7 years in information security taught me about building software
Lessons from internal audits and supplier assessments, applied to building software that is safe by default.
What this covers
- What I did for seven years
- The same few weak spots come up again and again
- The cheapest security is the kind built in early
- What supplier assessments teach about trust
- Threat modelling for people who are not security specialists
- Turning a security background into better products
What I did for seven years
Before XIVU, I spent seven years in information security, as a consultant and as an in-house Deputy Information Security Officer. The organisations I worked with came from automotive, banking, the public sector and enterprise software.
I ran internal ISMS audits to check whether security controls really work, and I assessed whether suppliers could be trusted with sensitive data. More about that background is on the About page.
The same few weak spots come up again and again
In the internal audits I ran, the findings were rarely about clever attacks. They were about basics: access rights nobody reviewed, data kept longer than needed, logs nobody read, configuration left at its defaults.
The cheapest security is the kind built in early
A control that is part of the first plan costs little. The same control added after launch means changing a data model, a process and often a contract.
Retention is the clearest example. Deciding on day one that enquiries are deleted after 12 months is one scheduled job. Deciding it three years later means first finding every copy.
What supplier assessments teach about trust
Assessing suppliers taught me to ask four questions before signing: Where does the data go? Who can access it? What happens if they are breached? How do we get out again? Those questions apply to every hosting provider, AI vendor and agency. They are also the core of our Supplier Security Check.
Threat modelling for people who are not security specialists
You do not need a security team to start. List what you protect, who might want it and how they could get it. Then fix the most likely path first.
Take a simple contact form. What you protect is names, email addresses and messages. Who wants it is mostly spam bots. The likely path is automated abuse. So the first fixes are a hidden honeypot field, rate limiting and a short retention period, not a security programme.
Turning a security background into better products
I apply the same habits to my own site. The xivu.io contact form stores only what it needs, keeps IP addresses only as a salted hash for rate limiting, deletes those records after 48 hours and deletes enquiries from the database after 12 months. The logs contain no names, email addresses or message text. Defaults like these cost almost nothing at the start and keep a one-person company safe without slowing it down. The full list for this website is on our trust page.
Have something to ship?
FREE INTRO CALL · FIXED QUOTE WITHIN 2 WORKING DAYS OF THE CALL
Start a project