How to Monitor a Deployed App for Security Regressions

A security regression is when something that was safe becomes unsafe without anyone deciding it should. No exploit, no attacker yet. Just drift: a header dropped in a refactor, a cert nobody renewed, a debug route that shipped by accident.

The scan you ran the day you launched will not catch any of it. That scan was a snapshot. Regressions happen after it.

Here is a practical setup that catches them without becoming a second job.

1. Get a baseline

Before you can catch a regression, you need to know what "good" looked like. Scan the deployed URL once and record what it found. Point the free scanner at your production domain. It reads the security surface a browser and an attacker both see: response headers, TLS, exposed paths, backend exposure.

Fix what it turns up. Now you have a clean baseline. The regression you care about is any drift away from it.

2. Re-scan on a schedule, not on a whim

A one-time scan cannot detect drift, because drift is a change over time. You need two data points. So the scan has to repeat.

Pick a cadence that matches how often the app changes:

• Ships daily or has real traffic: scan daily.
• A side project you touch weekly: scan weekly.
• Changes only when you deploy: scan on deploy.

The point is not to scan constantly. It is to scan often enough that a regression is caught in days, not discovered by a user months later.

3. Alert on the diff, not the total

This is the part people get wrong. If your monitor emails you the full list of findings every run, you will mute it inside a week. Standing issues you already decided to accept are noise.

What you actually want is the diff: alert me only when a finding is new since the last run, at or above a severity I care about. A header that was fine last week and is missing this week is a signal. The same twelve low-severity notes every run are not.

A good monitor alerts once, on the run that first sees a new finding, then goes quiet until something else changes.

4. Watch the boring, high-value things

The regressions that hurt are rarely exotic. They are boring:

• Security headers (Content-Security-Policy, Strict-Transport-Security) silently dropped by a config change.
• TLS certificate expiry creeping up while nobody watches the date.
• Exposed routes (/debug, /.env, an admin panel) that shipped by accident.
• Backend endpoints answering requests they should reject.

None of these change your status code. An uptime monitor will not see them. That is the difference between uptime monitoring and security monitoring.

5. Make it survive you forgetting

The whole reason to automate this is that you will forget to do it by hand. So the setup has to run without you: a scheduled scan, a diff-based alert, and a channel you actually read.

If you want that turnkey, that is what Seatrial monitors do: register a URL, pick a frequency, and get paged only when a new security finding shows up. Fixing a header is the easy part. Noticing when it comes back is the hard part, and that is the part worth automating.