We ran our own security scanner on ourselves.

Date: 2026-05-30 Site under test: stratalogic.co.za (production) Tool: DM3 (our own product) Time from "scan finished" to "fix shipped to production": ~90 minutes

The setup

DM3 is one of the tools we build at Strata Logic. It's a web audit platform that scans live sites for missing security headers, SEO regressions, and basic technical hygiene. We sell it as a free first scan that turns into a paid recurring monitor.

The question every prospect eventually asks is some version of: "Does it actually work?"

The most credible answer is to run it on our own production site and ship the fixes in public. So I did.

What DM3 found

Three missing security headers on stratalogic.co.za:

| Header | Status before | |---|---| | Content-Security-Policy | missing | | Referrer-Policy | missing | | Permissions-Policy | missing |

Several other security headers were already in place and reported correctly, including Strict-Transport-Security (HSTS with includeSubDomains), X-Frame-Options, X-Content-Type-Options, and X-XSS-Protection.

The findings were specific enough to act on immediately. Not "improve your security posture" but a concrete, prioritised list of what was missing. That bridge from finding to action is what most security tooling doesn't deliver.

What we shipped

Two of the three findings were fixed and live within 90 minutes of receiving the scan, in a single deploy. Both missing headers now apply to every response, including cached ones, and we added automated tests so they can't silently disappear in a future change. We also went further than the baseline recommendation, locking down browser capabilities the marketing site has no reason to use. That kind of hardening is cheap to do and quietly removes risk that was sitting there for no reason.

The third finding, Content-Security-Policy, was deliberately deferred. A good CSP is its own project, and a lazy one adds a checkmark with no real security benefit. We'd rather defer it honestly than ship a fake fix.

Verification

The fix is publicly verifiable. Re-running DM3 against the same URL after the deploy confirmed the two findings had flipped from "missing" to "present with a secure value", and CSP remained flagged, exactly the state we expected. The headers are live on this site right now, visible to anyone who cares to check.

Why this matters

Security headers are invisible until the day they aren't. They don't change how your site looks or feels, so they're easy to skip, and most sites do. They quietly close off whole categories of attack: clickjacking, content-type confusion, leaking referrer data to third parties, handing browser capabilities to scripts that should never have them. Skipping them isn't a visible problem until something exploits the gap, and by then it's an incident, not a checklist item.

And the cost of that incident is rarely just technical. This is the part that gets overlooked. When a site gets defaced, starts serving malware, or leaks customer data, the damage that lasts is reputational. Customers who see a security warning on your site, or hear that your business was compromised, don't read the post-mortem. They just remember that it happened. A few headers set in advance are a great deal cheaper than rebuilding that trust afterwards.

The point of this exercise isn't that we set a few headers. It's that the gap existed on our own site, a tool we built caught it, and we closed it the same morning. That's the difference between security as a one-time launch task and security as something you actually keep an eye on.

What this proves

Two things, in order of importance:

1. DM3 produces actionable findings, not just observations. A scanner that tells you "missing CSP" without giving you anything to act on is barely better than nothing. DM3's findings were clear enough that we could turn them into a shipped fix the same morning. That's the gap that separates security checkbox-tooling from security tooling people actually act on.

2. We use our own product. The site you're reading this on was hardened using the tool we sell. We don't have a "trust us" pitch. We have a live site you can check and a track record of acting on what the scan finds.

The honest gaps we found

DM3 isn't perfect. Two specific things we noticed while using it:

• The X-XSS-Protection: 1; mode=block header is reported as "present" without flagging that modern browsers ignore this header entirely (Chrome removed XSS auditors in 2019). Saying "present" sets the wrong mental model: the header is doing nothing.
• The Permissions-Policy recommendation is minimal. A site that uses none of the relevant browser features could lock down far more than DM3 suggests. DM3 could surface this as a "minimum to pass / comprehensive lockdown" choice rather than just suggesting the minimum.

Both are in DM3's roadmap as a result of this session.

Want the same audit on your site?

Run a free DM3 scan at dm3.co.za. You'll get the same kind of findings on the same kind of headers within a few seconds, with a clear, prioritised picture of what's missing.

If you don't have a developer to act on the findings, talk to us. We've done this enough times that the second case study we write is going to look a lot like this one.