Nobody's website gets scanned by accident
Wegweiser can now scan a client's public website for vulnerabilities and bring the findings back beside everything else it knows about them. The interesting part is not the scanner. It is what had to be true before we would let anyone press the button.
Wegweiser has been able to tell you whether a client's website is up for a while now. From today it can also tell you whether it is sound.
Point it at a client's public site and it crawls the thing from the outside, tests it the way somebody hostile would, and brings back what it found: injection, missing protections, exposed information, weak transport. The findings land on that client's organisation page, directly under the uptime card, because they are two readings of the same public surface. Is it up, and is it sound.
That part is not novel. Plenty of tools scan a website. What took the time was everything around it, because this is the first thing Wegweiser does where the consequence lands on somebody who is not a Wegweiser user and cannot be asked.
The button has three switches in front of it
A vulnerability scan is not a read. It sends real requests at a live web server, including the kind an attacker sends. It shows up in that company's logs. It can trip their own security tooling. On a fragile site it can produce errors for real visitors.
So turning it on is three separate decisions, and they get three separate clicks:
- A master connects Fenrir under Integrations and stores the credential.
- A master arms website scanning for the tenant. Nothing is scanned by this. It only makes the option visible.
- A master names one client's website and confirms that client has agreed.
The temptation is to collapse those into one switch, and the reason not to is easy to picture. An MSP pastes an API key into a settings page in March. In November somebody presses a button on a client page, and the company on the other end has never heard of any of this.
The third decision is also the one that gets written down. Wegweiser records who confirmed it, when, and which version of the wording they confirmed. Not a paragraph rendered near a checkbox, which proves nothing eight months later, but a row with a name in it. The wording is versioned because wording changes, and "they agreed to something we no longer show you" is not an answer to give anybody's solicitor. Change the address and the confirmation is taken again: a different address is a different company's website.
A client is not one website
Your client has a marketing site. They probably also have a shop, or a customer portal, or a booking system, and there is a fair chance all three were built by different people and are hosted in different places.
So a website is the unit, not a client. Each one carries its own permission, its own schedule, its own findings and its own grade. They are deliberately not averaged into a single score for the client, because an average is exactly how the one that is actually broken hides behind the three that are fine.
How often, and who the limit is for
Every other rate limit in Wegweiser exists to keep our systems standing up. This one does not. A scan button somebody can hold down is a denial of service attack with your name on the invoice, so the ceilings are there for the company being scanned:
- one scan per website per day
- four scans a day across any one client
- twenty a day across your whole estate
There is no override. Not for a master, not for support, not for us. The limit protects somebody who is not in the room, and an override is just the same button with an extra click in front of it. The schedule obeys it too, which matters more than the manual case: an unattended weekly sweep is the thing most likely to hammer a web server while nobody is watching.
When the button is unavailable it says why, and when the next scan can run.
What comes back
Findings, not a PDF. Each one arrives with its own history, which is the part a scanner on its own cannot give you:
- new since the last scan, so you know what appeared this month
- fixed, recorded rather than deleted, so "we sorted that in March" is a thing the page can still tell you
- still open, with the date it first appeared, which is the line that gets a developer to actually look at it
If the same issue comes back after being fixed, it returns attached to its original history rather than arriving as fresh news. A regression reads as a regression.
There is also a report, named for the client and the date, that you download and send them. It is a file, not a link into somebody else's console.
What it does not do yet, said plainly
The card is labelled "Website security" and not "AI-enriched website security", because the AI interpretation is not built yet and we would rather ship an honest label than a flattering one.
When it does land it will run inside Wegweiser on your own configured AI provider, not on the scanner's. If you chose a European provider, or a model running on your own hardware, you chose that on purpose, and a client's vulnerability list is not the thing to quietly route around it with. It is also the more useful version: Wegweiser knows which of that client's machines sit behind the website, and what your own documentation says the site is for. "This injection flaw is on the portal your runbook says takes the orders" is a sentence a scanner cannot write.
The same lesson, twice in one week
Shipping alongside it: one refused API key no longer becomes twenty bug reports.
Monday's post was about a single locked door arriving as twenty-six separate alerts. This week the same shape turned up again from the other direction. When a model provider rejects a credential, the analysis was trying the call, then the synthesis, then a fallback, each carrying the same dead key and earning the same refusal. One expired key produced three distinct error signatures per analysis, and our own triage dutifully filed each as its own issue. Twenty issues, one credential.
A rejected key is the one failure a retry cannot mend, so it now stops at the first refusal and says once what is wrong and where to fix it. Transient failures still get their retries, because those genuinely do come good.
One fault should cost one alert. It is not a new lesson. It is just one that needs learning in every place a call is made twice.