Security you measure. Not security you declare.
An old pentest, tickets marked “closed” and scanners nobody reads aren’t security: they’re a feeling. We build the controls inside your company —on every code change, on every public advisory, across the full history of your repositories— and leave them running with your team.
Every control proves it works: if it can’t show it catches a planted case, it doesn’t count as a control.
actually
checked?
The problem
Almost no company has zero security. What’s missing is knowing whether what it has actually works. In security, fear sells itself; what we sell here is a measurement.
“The pentest is closed”
Says a ticket from years ago. Nobody went back to the code to check the fix is still there.
“We have alerts”
Half switched on, posting to a channel where they get lost among a hundred other messages.
“We heard about it on social media”
The vulnerability of the week arrives through a post, not a system. And nobody knows whether it affects you.
“Everything is urgent”
Dozens of top-priority tickets. When everything is urgent, priority no longer sorts anything.
“We have backups”
In the same account as what they back up. Whoever can delete the data can delete the backup.
The first one is the most misleading: a closed ticket isn’t a measurement, it’s an opinion from years ago.
Four layers, each at its own moment
None is enough on its own. Each one covers what the previous one can’t see, and each runs when it makes sense to run.
1 · A gate on every commit
Deterministic rules in CI. Whatever breaks a rule doesn’t get merged. Cheap, fast and opinion-free.
2 · Review of every PR
An agent in a separate context, with a checklist, before a person approves.
3 · Service audit
The OWASP ASVS standard over the whole repository, with an expiry date: if the surface changed, it gets audited again.
4 · Permission matrix
User A requests user B’s data, in a test environment. The only layer that tests the entire class of authorization flaws.
AI sits in layers 2 and 3, as a tool for the team and never as the approver: what it proposes, a person approves. If someone sells you an AI that secures you on its own, ask them who approves what it proposes.
Monitoring: from public advisory to your ticket
When a vulnerability comes out, the question isn’t whether it’s serious. It’s whether it runs in your production. A script reads the primary sources and matches each advisory against what is actually deployed: runtimes, images and dependencies.
Advisory
Match
Ticket
What gets fixed first
Fixing what can’t be exploited eats the time you need for what can. Five questions, in order; the first “no” stops the chain, and every answer carries how it was measured.
Is it in production?
In what’s deployed, not on someone’s branch.
In the exposed process?
Server, browser, command line, or only at build time.
Is the function reached?
The library being there isn’t enough: the code has to use it.
Are they met?
The configuration and options the advisory requires.
And what do they have to chain?
The internet, a logged-in user, or an insider.
What passes all five goes first. What doesn’t is documented with its measurement, and goes back in the queue if something changes.
Secrets: the whole history, not just today
A key deleted in the next commit is still in the repository. The full history gets scanned, and the output never copies a value.
| The usual way | With this method | |
|---|---|---|
| Scope | The code on the main branch | The full history of every repository |
| Proof | “Found nothing” | A planted secret has to show up, or the scan doesn’t count |
| Output | A long, unsorted list | Every finding with where it is, whether it’s still live and what to do |
| Values | Copied into the report | Redacted: the report doesn’t become another leak |
| Afterwards | Once, then archived | Daily, flagging only what’s new |
A command that failed doesn’t mean “there’s nothing”: it means “I couldn’t see”. Mixing the two up is the most common way to declare something safe that nobody looked at.
What alerts, and to whom
A detector with no destination is the same as not having one. Every source has its channel, and every channel has someone who reads it.
Everything on, nothing read
- Detectors half enabled, with nowhere to go
- Alerts mixed in with operational noise
- The security report in the same channel as the rest of the team
Every alert reaches whoever decides
- One channel per alert type, with its threshold
- The urgent interrupts; the rest waits for its review
- Anything that maps an attack stays with those who need it
A rule that protects you from the system itself: the model that reads an alert doesn’t write. The ticket is built by a separate step from structured data, so malicious text in an advisory can’t turn into a command.
So a compromised admin can’t delete everything
The most damaging cloud attack doesn’t break anything: it uses a legitimate account to delete data and backups. The design makes sure that chain doesn’t work.
Immutable copy, in another account
The backup survives even if the entire production account is lost.
Policies that deny deletion
Not even an admin can turn off recovery or delete backups, except through a controlled break-glass access.
Short sessions
Admin permissions last as long as the task, and don’t live on the everyday laptop.
Measures are ordered by cost and effect, and the one that sounds first isn’t always the one that goes first: a protection an admin can turn off with one command only counts alongside the policy that stops them.
The rules that hold everything else up
An outsider looking at your security has to be under more control than anyone. The answer is rules, not trust.
Author isn’t approver
No change goes in without a person on your side approving it. Not even the ones the AI proposes.
The infrastructure plan is read in full
A small change can drag in a big replacement. You read the plan, not the diff, and back up first.
The code rules, not the ticket
A finding is closed when the code proves it, not when someone ticked it off.
Named, read-only access
Read-only by default. Switch off the user and everything keeps running.
The case · a 4-year-old fintech
A financial platform with no CISO, a small team and a lot of legacy code. One person, leveraged by AI, working from the inside:
It came out of two months of work on a real platform, mistakes included, not out of a demo. What you buy isn’t a list of findings: it’s a system that keeps finding them when whoever built it is no longer watching.
Anonymized reference case, the same one as brain.placedium.com: no client name, no findings, no third-party data. Figures are rounded down.
Who it’s for
You don’t need a security team. You need to want to know, with data, where you stand.
You move money or sensitive data
Fintech, payments, healthcare, or any business where a security mistake stops being anecdotal.
You don’t have a CISO
And security is split across a team that also has to ship the product.
You have an audit with open findings
And you don’t know which are still live in today’s code.
You had a scare
And you want the next one caught by a system, not a post.
Your team already codes with AI
And you want that same speed to come with review, not with more risk.
The board asks “are we OK?”
And nobody can answer with a measurement in hand.
If what’s missing is someone to lead all of technology, not just security, that’s a Fractional CTO.
How it starts
First we measure where you stand. Layers are added from cheapest to most expensive.
What runs and what gets watched
What’s deployed, what gets scanned and where it alerts.
Measured, not estimated
Every data point with the command that produced it, so it can be repeated.
From cheapest to most expensive
First, the free stuff you already had switched off.
Running on its own
Off anyone’s laptop, with its channel and its threshold.
Your team runs it
The rules, the scripts and the documentation stay on your side.
If the survey shows the urgent thing is something else, you hear it right there, and the baseline is yours anyway.
Companies and projects I've been part of
Over 25 years in fintech, banking, retail, media, streaming and government: the companies I worked at, and the projects and clients that went through my teams.
Names belong to their owners; the circles are initials, not logos. In blue, the companies I worked at; around them, projects and clients.
Monitor.
Hand over.
“A closed ticket isn’t a measurement. The code that runs is.”
Let’s talk. A baseline.
Tell us what you have and what worries you. A short conversation is enough to know where to start measuring.