Okay, But Actually… A Pile of Security Vocabulary Is Not a Security Review
I love a security lecture that begins after absolutely no questions.
Someone hears “Supabase, Cloudflare, Stripe and an email service” and, within minutes, we are discussing California residents, EU citizens, Brazilian data, envelope encryption, blast radius, data processing agreements, breaches and lawsuits.
At no point has anyone asked what the application does.
Does it store contact details? Financial records? Private documents? Passwords? Is it an internal tool used by three employees, or a public platform with thousands of customers? Who can create an account? Which services receive the data? What permissions exist? Is anything particularly sensitive involved?
None of this information is apparently necessary.
The verdict has already arrived: you do not understand cybersecurity, you are going to get sued and a world of pain awaits.
Very efficient.
A security review usually contains questions
The funny thing is that actual security guidance begins by understanding the system.
OWASP’s threat-modelling guidance organises the process around four questions:
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- Did we do a good enough job?
Notice which question comes first.
It is not “How many intimidating terms can we fit into a reply?”
Before identifying threats, you need to understand the application, its users, its data flows, its dependencies and the boundaries between its components.
The current NIST Cybersecurity Framework also begins by identifying the data, people, devices, systems and services that matter to the organisation. Their importance to the business affects how the risks should be handled.
Even the UK Information Commissioner’s guidance for a data protection impact assessment tells organisations to describe the nature, scope, context and purpose of the processing before assessing risk.
Apparently “find out what is happening first” is quite popular among people who do this professionally.
The impressive words refer to real things
The annoying part is that none of those words are nonsense.
Data residency matters. Encryption matters. Blast radius matters. Contracts with data processors matter. Different countries have different privacy and data protection requirements.
These are all legitimate subjects.
Throwing them into a conversation at random does not turn the conversation into a security assessment.
“Are you holding Californian resident data?” could eventually lead to useful questions about the people involved, the type of information being processed, which organisations are responsible for it and which laws apply.
Merely announcing “California” does not reveal any of those answers.
The same applies to the EU and Brazil. Data connected to people in different jurisdictions can create different obligations, but this cannot be analysed from the name of a database provider and the approximate revenue of the business.
The product has to enter the conversation at some point.
Before discussing encryption, what are we encrypting?
“Is the data stored as plain text or encrypted at rest with envelope encryption?”
That sounds excellent in a comment. There are several technical terms and all of them are wearing a tie.
Here is what they mean in normal-person language.
Encryption in transit protects information while it travels across the internet.
When you submit a form, log into an account or make a purchase, information has to travel from your device to the service you are using. Encryption scrambles it during that journey so anyone who manages to intercept it should see unreadable nonsense instead of your details.
It is the difference between sending information inside a locked delivery van and writing it on a postcard.
HTTPS, which you will recognise from website addresses, is the normal way websites provide this protection.
Encryption at rest protects information while it is sitting in storage.
Imagine somebody steals a hard drive or gets hold of a database backup. Encryption at rest is supposed to prevent them from opening it and immediately reading everything inside.
The application can still display the information to people who are allowed to see it. The protection is around the stored copy.
Then we have envelope encryption.
Despite the magnificent name, nobody is placing your database inside a tiny encrypted envelope.
The information is locked using one key. That key is then locked using another, more heavily protected key.
Imagine storing documents in several locked boxes, then keeping the keys to those boxes inside a safe. If managed properly, this makes it easier to protect and replace the keys without using one loose key for everything.
Google’s Cloud Key Management documentation describes envelope encryption in almost exactly those terms: encrypting one key with another key.
Useful? Absolutely.
Proof that the whole application is secure? Not even slightly.
If somebody steals an employee’s login and that employee is allowed to view the information, the application may still show it to them.
If every administrator can see every customer’s records, encryption does not make those permissions sensible.
If an application accidentally shows one customer another customer’s information, the data has already been unlocked so the application can display it.
If a powerful account holds the keys to everything, stealing that account may still give somebody access to everything.
Encryption protects against particular ways data can be stolen. It does not correct every other bad decision inside the application.
This is why “Is it encrypted?” rarely deserves a one-word answer.
Which information? Protected while travelling, while stored, or both? Who is allowed to unlock it? What happens if that person’s account is stolen? Does the information need extra protection inside the application?
Additional encryption may be completely justified for particularly sensitive information. It also introduces more keys, more recovery problems and more opportunities for somebody to lock themselves out of their own data.
We cannot decide whether it is necessary until we know what is being stored.
Before asking about envelope encryption, I would like the revolutionary information of what is inside the envelope.
The blast radius of what?
“Blast radius” describes how much damage an incident could cause or how far it could spread.
Useful concept.
Now we need an incident.
Are we considering a stolen customer password? A compromised administrator account? An exposed database credential? A vulnerable dependency? A malicious employee? A breached third-party service?
Each one can affect a different part of the system and requires different controls.
You cannot determine the blast radius without knowing how the application is structured, which systems connect to each other, what each credential can do and how access is separated between customers.
Dropping “What’s the blast radius?” into a reply without that information is the cybersecurity version of walking past a building and asking whether the fire doors comply.
Perhaps we could enter the building first.
“Client data” tells me almost nothing
The phrase “client data” gets used as though it describes one universally terrifying substance.
A newsletter subscriber’s email address is client data.
So is an unpublished acquisition agreement.
So is a support conversation, a billing address, a company logo, a tax record, a password and a medical diagnosis.
They do not have the same sensitivity. A leak would not cause the same harm. The same people should not necessarily have access to them, and they do not all justify identical controls.
A useful review would ask:
- What information is being collected?
- Why does the application need it?
- How sensitive is it?
- Who owns it?
- Who can access it?
- Which providers process it?
- How long is it retained?
- What would happen to a person or business if it were exposed?
- How likely is that exposure?
- Which controls would meaningfully reduce the risk?
Those answers determine whether the application needs stronger access restrictions, additional encryption, regional hosting, audit logs, shorter retention, contractual protections or an entirely different design.
Without them, we are decorating an imaginary system with security controls.
A DPA is important when it is actually relevant
A data processing agreement is not another word for “serious business.”
Depending on the organisations, jurisdictions and processing involved, a DPA may be required between a business and a developer or service provider handling personal data on its behalf. It can define responsibilities, security obligations, subprocessors, assistance with data rights, breach notifications and what happens to the data when the relationship ends.
That matters.
It still does not tell us whether access permissions have been configured properly. It does not stop somebody collecting information they do not need. It cannot fix an exposed credential or notice that a former contractor still has administrator access.
Signing a DPA and then ignoring the application would be a very organised way to remain insecure.
Security should be proportional to the actual risk
A private tool used by three people to organise public business information does not need the same controls as a financial platform serving thousands of customers.
That does not give the smaller product permission to be careless. It means the time, money and attention should go towards the risks that genuinely exist.
Perhaps the most important controls are multi-factor authentication, sensible permissions, encrypted connections, reliable backups and a process for removing staff access.
Perhaps the project handles information sensitive enough to justify application-level encryption, detailed audit trails, regional restrictions, formal penetration testing and specialist legal advice.
You discover that by examining the project.
You do not discover it by seeing the word “Supabase” and immediately predicting litigation.
Security work involves prioritisation. If every possible risk receives the same dramatic treatment, the business gets an expensive pile of controls without knowing which problems any of them were supposed to solve.
What a useful first conversation sounds like
Someone who genuinely wants to help might begin with:
“What are you building?”
“What information will it store?”
“Who will use it?”
“Which countries are involved?”
“Which providers will process the information?”
“What happens if an ordinary account is compromised?”
“What can an administrator access?”
“Are there contractual or regulatory requirements we need to design around?”
Those questions may eventually lead to an uncomfortable answer.
The current architecture may be inappropriate. The business might need different infrastructure, stronger controls, a DPA, specialist testing or legal guidance. A feature may need to be redesigned or removed entirely.
I am perfectly willing to have that conversation.
What annoys me is receiving the verdict before anyone has collected a single relevant fact.
Business owners should not have to memorise a cybersecurity glossary before they are allowed to commission software. That is part of what they are paying a competent developer for.
The developer should find out what the product will handle, raise the risks that genuinely apply and explain the decisions in language the client understands. They should also know when the project needs a security specialist, legal advice or controls beyond their own expertise.
If somebody can already see a lawsuit and a “world of pain” before they know what you are building, the drama is doing considerably more work than the assessment.
Before asking about envelope encryption, find out what is in the damn envelope.