Read Me First

A plain-language introduction to the Vulnerability Management Platform.

If you have just been handed this software and you have no idea what it is, start here. This page assumes you know nothing about the project. It explains who it is for, what it does, the world it belongs to, how to switch it on, and what looking after it involves. There is no technical knowledge assumed and nothing here requires you to be a programmer.

Everything described below is something the software actually does today. Where a feature is planned but not built, it says so.

---

1. Who this is for

This is a tool for the people inside an organisation whose job is to find security weaknesses in the organisation's computer systems and get them fixed before an attacker uses them.

In practice, that means:

• The person who runs the vulnerability programme. Often called a vulnerability management programme manager. They are accountable for the organisation knowing what it owns and how exposed it is.
• Security analysts. The people who look at the daily list of problems and decide which ones matter, who should fix them, and by when.
• Remediation owners. The system administrators, platform engineers, and application teams who actually apply the patch or change the configuration. They receive work; they do not decide priorities.
• The head of security (CISO) and their leadership. They need a simple, honest answer to "are we getting safer or worse?" that can be shown to a board.
• Governance, risk and compliance (GRC) staff and auditors. They need documented proof that the organisation looked for weaknesses, ranked them sensibly, and fixed the serious ones on time.
• DevSecOps leads. The people who want a build to fail automatically when it drags a dangerous, known-attacked component into production.

It is not a tool for home users, and it is not something an individual runs on their own laptop to protect themselves. It is built for an organisation with an estate of systems and a team responsible for them.

---

2. What it does

In a few plain sentences:

The software keeps a register of everything your organisation owns that could be attacked — servers, laptops, cloud machines, network gear, applications. It takes in the results of security scans run by other tools, matches each reported problem against public catalogues of known weaknesses, and then adds published intelligence about each one: how severe it is, how likely it is to be attacked in the next month, and whether attackers are known to be using it right now.

It then does the thing a spreadsheet cannot: it puts every open problem in your organisation into one ranked list, ordered by the real-world probability of being attacked, adjusted for how important and how exposed the affected machine is. Anything confirmed to be under active attack is pushed to the top automatically, no matter how unremarkable its severity score looks.

From there it drives work to completion. Each item gets an owner and a deadline based on its risk, deadlines are chased automatically, work can be mirrored into your existing ticketing system, and every decision is recorded permanently so it can be shown to an auditor later. An optional AI assistant can draft tailored fix instructions, but it can never change anything without a person approving it first.

Important limitation, stated up front: this platform does not perform scans itself. It orchestrates and consumes the results of scanners you already run. Think of it as the brain that decides what to do about what your scanners found, not the thing that does the looking.

---

3. The domain: what vulnerability management actually is

If you are new to security work, here is the setting.

Software has flaws. Some of those flaws let an attacker do something they should not — read data, take over a machine, spread to other machines. When such a flaw is discovered and made public, it is given a unique public reference number so that everyone in the world can talk about the same flaw without confusion. That reference is called a CVE. There are hundreds of thousands of them, and tens of thousands more appear every year. The rate of new ones has risen sharply — submissions grew roughly 263% between 2020 and 2025.

Organisations run scanners to find them. A scanner is a tool that inspects your machines, works out what software is installed, and reports which known flaws apply. A mid-sized organisation running scanners across a few thousand machines routinely ends up with tens of thousands, sometimes millions, of individual reported problems. Each one of those — "this specific flaw, on this specific machine" — is called a finding. A finding is the unit of work.

And that is the real problem. No organisation can fix tens of thousands of things. The entire discipline is about deciding what to fix first. Historically that was done using a severity score called CVSS, which rates each flaw from 0 to 10 based on how bad it would be if exploited. But CVSS answers the wrong question. It says how bad the damage would be, not how likely anyone is to actually try. In practice only a small fraction of published flaws are ever exploited in the wild, so a team working strictly down a severity-ordered list spends most of its effort on things nobody will ever attack, while a genuinely dangerous mid-severity flaw sits ignored.

Two newer signals fixed that, and they are the heart of this platform:

• EPSS (the Exploit Prediction Scoring System) publishes, every day, a probability that each known flaw will be exploited in the next 30 days. It is calculated from over a thousand real-world variables. It answers "how likely is this to actually be attacked?"
• KEV (the Known Exploited Vulnerabilities catalogue, published by the US government's cyber agency, CISA) is a list of flaws confirmed to be under active attack right now. If something is on the KEV list, the argument is over — it is being used against real organisations today, and government agencies are given a legal deadline to fix it.

This platform ranks by exploit probability first and forces KEV items to the very top. That is the single design decision everything else follows from.

Two other pieces of context matter:

Business criticality. The same flaw on a spare test machine and on the payroll database are not the same risk. Somebody has to say which machines matter. That judgement is recorded against each asset and it feeds directly into the ranking.

Compliance. Most organisations are contractually or legally obliged to run a vulnerability management programme, and to prove it. The three regimes this platform maps to are ISO/IEC 27001 (an international information-security standard, whose clause A.8.8 requires the systematic identification and remediation of technical vulnerabilities), PCI DSS (the card-payment industry's rules, whose Requirements 6 and 11 cover patching and regular scanning), and the CIS Controls (a widely used practical checklist, whose Control 7 covers continuous vulnerability management). There is also a view that maps activity onto the NIST Cybersecurity Framework. Auditors ask for evidence against these; this platform generates it.

One current event worth knowing, because it shaped the design: from April 2026 the US National Vulnerability Database — for years the default place everyone got their flaw details from — stopped enriching every CVE and now prioritises KEV-listed and other high-priority ones. Any tool that depended on it alone now has gaps. This platform deliberately draws on several sources, records where every piece of information came from and when, and keeps working when any one of them goes quiet.

---

4. Where it fits

One organisation per installation. The platform is single-tenant: each customer organisation gets its own separate installation with its own database. Your data is never mixed with another company's. Internal structure — divisions, business units — is represented as data inside your own installation.

Expected customers. Mid-sized to large enterprises with a real security team and an estate in the range of thousands to tens of thousands of machines. The design target is tens of thousands of assets and millions of findings. It is not aimed at very small businesses without a security function, and hyperscale internet companies are out of scope for this version.

It sits in the middle of a toolchain. It expects to be surrounded by systems you already run:

Neighbouring system	What the platform does with it
Your vulnerability scanner	Imports scan results. OpenVAS/Greenbone is the reference scanner supported in this version. Results from other tools can be submitted directly through the platform's interface for machines.
Public flaw catalogues and feeds	Automatically pulls severity details, daily exploit-probability scores, and the actively-exploited catalogue. These are free and public — no licence to buy.
Threat intelligence feeds	Accepts intelligence published in the standard security formats (STIX/TAXII) and links it to the flaws you are already tracking.
Your ticketing system	Two-way synchronisation with JIRA and ServiceNow, so engineers work in the tool they already use and the platform still sees when the ticket is closed.
Your build pipelines	A gate that can flag or block a build when it introduces a problem above a risk threshold you set.
Your chat / alerting channels	Sends signed alerts to web addresses you register, so a newly confirmed high-risk item reaches people quickly.
Your company login (single sign-on)	Staff sign in with their normal corporate identity. The platform has no password of its own and stores none.
An AI language model	Optional. When configured, it drafts tailored fix instructions. When not configured, everything else works exactly the same.

What is deliberately not here yet. Automatic discovery of cloud machines in AWS, Azure and Google Cloud without installing anything on them is planned for a later release; it is not in this version. Neither is a scanning engine of the platform's own. If a review or a sales conversation implies otherwise, correct it.

---

5. First run: the very first thing to do

There are two different starting points depending on why you are here.

If you are evaluating it (most first-time readers)

There is a self-contained package that includes the application, its database, and a full set of realistic demo data, all in one. You need Docker installed, and nothing else. From the project folder, type these two lines exactly:

docker build -f preview/Dockerfile -t vmp-preview .
docker run --rm -p 4000:4000 -e PORT=4000 --name vmp-preview vmp-preview

Then open http://localhost:4000 in a browser.

You will land directly inside the console, already signed in as a demo administrator, with several months of invented but realistic security data across every screen. There is nothing to configure and no account to create.

The very first thing to do once it opens:

1. You arrive on Risk Posture — the dashboard. Look at the headline numbers and the 30-day detection trend. This is the view a security leader lives in.
2. Click Queue in the left-hand menu. This is the ranked list — the heart of the product. The item at the top is what the platform believes your organisation should fix next, out of everything it knows about.
3. Tick the KEV only box. The list narrows to problems confirmed to be under active attack right now.
4. Click any row. A panel opens headed "Why this rank?". It shows every factor that produced that position — the exploit probability, the severity, whether it is on the actively-exploited list, how important the machine is, how exposed it is, whether it sits on an attack path — each with the source it came from and a warning if that source is out of date.

That fourth step is the product. If you understand that panel, you understand the platform.

Two practical notes: the port number you publish and the PORT value you pass must match (4000 in the example above; any port works as long as both say the same thing). And by design nothing is saved — every restart gives you a clean, freshly populated demo. See §10 if you want changes to survive a restart.

If you are standing up a real installation

You are not the first reader of this page — you are an operator, and your instructions live in user-docs/production-setup.md. In short: the database schema is applied automatically on deployment, and then a one-time initialiser is run that clears the database and writes only the handful of rows a real system needs — the organisation record, the first administrator, the default scoring and deadline settings, and the catalogue of eight compliance controls. No invented data is loaded.

The one thing to get right before you start: the first administrator must be created during that initialisation. Sign-in is delegated to your corporate login, and anyone who signs in without having been set up in advance is created automatically with the ordinary Analyst role — which cannot administer anything. If you skip the first administrator, nobody can configure the system.

---

6. Setting up your working environment

This assumes a real installation, not the demo. Work in this order.

Step 1 — Sign in and confirm you are an administrator. Open the address of your installation. You will be sent to your organisation's normal single sign-on, and returned signed in. Your name and role are shown at the bottom of the left-hand menu. It should say Admin.

Step 2 — Load your asset inventory. Nothing works well until the platform knows what you own and which of it matters. Assets can be loaded in bulk, and they also arrive automatically as scan results are imported. The platform de-duplicates as it goes: it recognises the same machine reported by two different tools under two different names, using the most stable identifier available — a cloud machine's own resource identifier is trusted most, then its full hostname, then its network hardware address, then its IP address. A machine known only by IP address is recorded as provisional until something better appears. This is why you get one asset, not four.

Step 3 — Set business criticality. For each significant asset, open it from the Assets screen and set its business criticality from the dropdown. This is the single most valuable piece of human judgement you will contribute, because it directly changes what the ranking tells your team to do next. Do the important machines first; everything else can default.

Step 4 — Create credentials for your machines. Scanners, pipelines and automation do not sign in as people. They use separate scoped credentials that can be given narrowly limited permissions — for example, permission to submit findings but nothing else. An administrator creates these.

Step 5 — Connect your scanner. Register your scanner and begin importing its reports. Imported results are matched to assets, matched to catalogued flaws, and enter the ranked queue automatically. Submitting the same report twice is safe — duplicates reconcile to a single record rather than creating phantom problems.

Step 6 — Confirm the public feeds are flowing. These are configured to run on a schedule out of the box. Open the Intel screen and look at Feed Source Health: every source should show a recent successful update. This screen exists precisely so you find out that a feed went quiet from a dashboard, not from an incident.

Step 7 — Connect your ticketing system. Register your JIRA or ServiceNow connection so remediation work appears where your engineers already work, and so closing the ticket closes the loop back here.

Step 8 — Register alert destinations. Add the web addresses that should be notified when a new high-risk problem is confirmed. You can send a test message to verify each one before relying on it.

Step 9 — Set your deadlines and your scoring policy. The defaults are sensible: critical-risk items must be fixed within 7 days, high within 30, medium within 90, low within 180. Items on the actively-exploited catalogue are instead pinned to the official regulatory deadline published for them. All of these windows, and the weightings behind the ranking, are adjustable per installation — change them to match your own policy rather than letting your policy drift to match the tool.

Step 10 — Add the build-pipeline gate, if you want one. Define the risk threshold at which a build should be flagged or blocked, and wire the check into your pipelines.

Step 11 — Optionally enable the AI assistant. Supply an AI provider key. Without one the AI panel simply reports that AI is not configured and every other function is unaffected. Nothing in the platform depends on AI being switched on.

A note you need before you start, so it does not surprise you: in this version the Admin screen in the web console is a read-only overview. It shows which scanners are connected and which alert destinations are registered, and whether each is active. The actual configuration work in steps 4, 5, 7, 8, 9 and 10 — creating credentials, registering integrations and alert destinations, changing deadlines and scoring, and changing somebody's role — is done through the platform's documented interface for machines rather than through screens. Bulk asset loading in step 2 is the same. This is a genuine gap in the user interface, not a hidden menu you have failed to find. Your operator or integrator will do this work; the published interface specification is included with the project.

---

7. Day to day

Once it is running, here is what an ordinary week looks like for each kind of user.

The security analyst — triage

This is the main daily loop, and it should take minutes rather than hours.

1. Open the Queue. It is already ordered — you do not sort or filter to find the important work, because the ordering is the product.
2. Tick KEV only first. Anything here is being actively attacked in the wild. Clear this list before you touch anything else.
3. Click a row to see why it ranks where it does, then open the finding itself for the full picture — its current status, its deadline (shown in red once overdue), its full history, and the factor-by-factor explanation.
4. Decide what happens to it. From the finding you can move it along its lifecycle: Open → In Progress → Remediated → Verified Closed, or divert it to Risk Accepted or False Positive. Every one of these changes requires you to type a reason. That is deliberate: the reason becomes part of the permanent audit record, and it is what your auditor will read next year.
5. If you need help fixing it, click Request guidance on the finding. The AI assistant drafts step-by-step remediation instructions tailored to that particular machine's configuration. Everything it produces is labelled as AI-generated and lists the exact underlying records each claim came from. If it does not have enough information to be specific, it says so rather than inventing plausible-sounding steps.

The remediation owner — doing the work

You are assigned findings and remediation tasks. Your loop is: see what is assigned to you on the Tasks screen, do the work, and mark the finding as remediated with a note about what you did. If your organisation has connected a ticketing system, your work will appear there too and closing the ticket updates the platform. You cannot change asset criticality or reconfigure the system — that is not your job and the software enforces it.

The programme manager — inventory and coverage

Live in the Assets screen. Watch for machines with no owner, machines whose criticality has never been set, machines marked provisional because they are only known by IP address, and machines still listed as live that were actually decommissioned months ago. Each asset shows its aggregate risk and the findings behind it, so you can see the riskiest machines rather than only the riskiest flaws.

The security leader — the story

The Risk Posture dashboard is the summary: the spread of findings across priority bands, how many actively-exploited items are outstanding, whether deadlines are being met, and a 30-day trend. The trend is the number that answers the board's question.

The GRC analyst — evidence

Go to Compliance. Choose a start date and an end date, generate a report, and download it. It draws on what actually happened in that period: what was found, how it was prioritised, what was fixed, and the proof of closure. The same screen lists the control catalogue the platform maps activity against.

Everyone occasionally — the specialist screens

• Intel — the health of each data feed, and the external threat intelligence that has been matched to flaws you are already tracking.
• Attack Paths — you nominate your most valuable systems ("crown jewels"), and this shows the routes an attacker could chain together to reach them. Flaws sitting on such a route are automatically promoted above equally-scored flaws that are not.
• AI Queue — anything the AI has proposed that would change something waits here for a person to approve or reject. Nothing takes effect until somebody clicks. Fully autonomous AI action exists in the design but ships switched off in this version.

---

8. Ongoing care

What the platform does for itself, on a schedule

You do not need to trigger any of this:

How often	What happens
Daily (early morning)	The exploit-probability scores for every known flaw are refreshed and the whole estate is re-ranked to match.
Twice a day	The actively-exploited catalogue is refreshed; anything newly listed jumps to the top band immediately.
Every hour	Overdue items are detected, flagged, and escalated to whoever is configured to receive them.
Every 15 minutes	Ticket status is synchronised in both directions with JIRA / ServiceNow.
Every couple of minutes	Undelivered alerts are retried.

Because exploit probability changes daily, the order of the queue changes daily by itself, with no human action. That is normal and is the point.

What people still need to do

Weekly

• Glance at Intel → Feed Source Health. A feed that has quietly stopped is the one failure that degrades the ranking without any alarm going off. The platform keeps working and marks the affected values as stale rather than blocking, so nothing breaks — but stale data ranks worse than fresh data, and you should know.
• Clear the actively-exploited queue.
• Look at the AI Queue so approvals do not pile up.

Monthly

• Review overdue items. Persistent overdue findings mean either the deadlines are wrong or the remediation team is under-resourced; both are management problems, not tool problems.
• Review new assets and set criticality on anything significant that arrived without it.
• Close out decommissioned machines. Findings on a retired machine should be closed as no longer applicable — they then stop counting toward active risk while remaining in the historical record.

Quarterly

• Re-examine every Risk Accepted item. Risk acceptance is a decision to live with something, not a way to make it disappear, and circumstances change — particularly if the flaw has since appeared on the actively-exploited catalogue.
• Generate a compliance evidence report for the quarter, whether or not an audit is due. It is cheap, and it means you find gaps in your evidence before an auditor does.
• Confirm the deadline windows and scoring weights still match your written policy.

Annually, or at audit time

• Produce evidence reports for the full audit period.
• Review who has which role, and remove people who have changed jobs or left.
• Review the machine credentials issued to scanners and pipelines, and revoke any that are no longer used.

Backups. How this works depends on where you are running. On the managed platform, storage is provided and backed up by the platform — you are not responsible for it. If you are self-hosting, the database holds your entire audit trail and evidence history and must be backed up like any other system of record; the evidence is worth as much as the findings. The demonstration package described in §5 keeps nothing by default and is not a place to store anything you care about.

---

9. Glossary

Asset — anything you own that can be attacked: a server, a laptop, a cloud machine, a network device, an application.

Finding — one specific flaw on one specific asset. The unit of work. The same flaw on fifty machines is fifty findings.

Vulnerability / CVE — a publicly catalogued software flaw and its unique worldwide reference number.

CVSS — a 0-to-10 severity score. Says how bad it would be, not how likely it is.

EPSS — a daily-updated probability that a given flaw will be exploited within 30 days. The primary ranking signal in this platform.

KEV — the government-published catalogue of flaws confirmed to be under active attack. Anything on it is forced to the top priority band regardless of its severity score.

Priority band — the coarse grouping shown against each finding: P0 Active Exploitation, then Critical, High, Medium, Low.

Enrichment — the published facts added to a flaw after it arrives: its severity, its exploit probability, its actively-exploited status. Each is stored with its source and the time it was fetched.

Stale — an enrichment value whose source has not been refreshed recently. Shown as a warning rather than hidden, so you can judge how much to trust a ranking.

Business criticality — your own judgement of how much a particular asset matters. Feeds directly into ranking.

Exposure — how reachable an asset is, for instance internet-facing versus internal-only.

SLA / deadline — the date by which a finding must be resolved, derived from its risk. Higher risk means less time.

Risk acceptance — a recorded, justified decision to live with a finding. It leaves the active work count but stays in the record permanently.

False positive — a finding the scanner reported that turns out not to be real.

Crown jewel — an asset you have nominated as one of the most valuable things you own, used as the target when working out attack paths.

Attack path — a chain of connected machines and flaws by which an attacker could work their way from an entry point to a crown jewel.

STIX / TAXII — the standard formats for publishing and subscribing to threat intelligence.

Scanner — the separate tool that inspects machines and reports flaws. This platform consumes scanner output; it is not itself a scanner.

Audit trail — the permanent record of who did what, when, and why. Cannot be edited.

Single sign-on (SSO) — signing in with your normal corporate identity rather than a password held by this application.

Role — what a given person is allowed to do. See §11.

Single-tenant — one installation per customer organisation, with its own separate database.

---

10. Sample data, and starting clean

What ships with the demonstration package. The evaluation package described in §5 arrives pre-loaded with entirely fictional but realistic data: roughly 95 assets of varying types, criticalities and exposures; around 45 catalogued flaws with full severity, exploit probability and actively-exploited information; and roughly 650 findings spread across every lifecycle state — some overdue, some reopened after being re-detected, some involving regulated personal data. There are remediation tasks, a couple mirrored into ticketing systems, AI guidance that has been approved and a couple still awaiting approval, threat intelligence linked to actively-exploited flaws, scan records, alert deliveries, build-gate decisions that blocked and passed, and crown jewels with genuine attack paths running to them. Every screen is populated because every screen has real data behind it.

You can ask for a smaller set (about 16 assets and 70 findings) for a quick look, or a larger one (about 260 assets and 2,600 findings) to see how it feels at volume.

None of it is real. It is fictional. Do not quote any number from a demo instance in a report.

Starting fresh in the demonstration package requires no effort at all: it wipes and re-loads on every start, so simply restarting gives you a clean, fully populated system. That is deliberate — a guaranteed-identical starting point is more useful for evaluation than accumulated clutter. If instead you want your changes to survive a restart, there is a setting that switches persistence on; see preview/README.md.

Starting fresh in a real installation is a different, deliberately guarded operation. The initialiser can wipe the database and reload only the minimal base rows, but it is designed to be hard to do by accident: it shows you exactly what it is about to delete, refuses to touch a database that already has data unless you explicitly force it, requires a separate explicit acknowledgement for staging and production targets, and then requires you to type a confirmation phrase. A production wipe needs three separate deliberate opt-ins. There is also a preview mode that shows the plan and changes nothing. Details are in user-docs/production-setup.md.

---

11. Who can do what

There are four roles.

Role	What they can do
Admin	Everything, plus the things nobody else can: manage users and their roles, issue and revoke credentials for machines, register scanner / ticketing / threat-intel connections and alert destinations, and change the deadline windows and the ranking weights.
Analyst	The triage role. Reads everything, manages the asset inventory, imports scan results and submits findings, runs and cancels scans, ingests threat intelligence, nominates crown jewels, runs build-gate evaluations, moves findings through their lifecycle, assigns owners, records risk acceptances, and approves or rejects AI suggestions. Cannot change system configuration.
Remediation Owner	The person doing the fixing. Works assigned findings and remediation tasks, moves them through the lifecycle, and requests AI guidance. Cannot alter the asset inventory, cannot import scans, and cannot configure anything.
Auditor	Read-only, plus reports. Can see everything, including the full audit trail, and can generate compliance evidence — but cannot change a single thing. Attempts to write are refused by the software, not merely hidden.

Two things to know about accounts:

• Everyone signs in through your organisation's normal login. The platform holds no passwords whatsoever.
• A person who has never signed in before is created automatically the first time they do, with the Analyst role. An administrator then adjusts it. This is why the very first administrator has to be set up during installation — otherwise the first person through the door lands as an Analyst and nobody can promote them.

Machines are handled separately from people. A scanner or a pipeline uses a credential that carries only the specific permissions it needs, so a scanner that can submit findings cannot also read your compliance reports. No person or machine can reach data outside the scope it was granted, and anything not explicitly permitted is refused.

---

12. Other documents, and where to go next

Inside user-docs/:

Document	Read it when
READ-ME-FIRST.md (this page)	You are new and want the whole picture in plain language.
quickstart.md	You want the condensed version — what it does, how to start it, and a one-line description of every screen. Good as a refresher or a handout.
production-setup.md	You are the operator standing up a real staging or production installation for a customer. Covers the one-time initialisation, the safety gates around it, setting up the first administrator, and how to verify the result.
testing.md	You want to know how anyone can be confident this works. Explains, in plain terms, what is automatically proved before any change ships, and lists what each test demonstrates. Useful if you are being asked to trust the ranking.
store-thumbnail.png	A product image for listings. Not documentation.

Elsewhere in the project, if you need it: preview/README.md explains the self-contained evaluation package in detail, including running it on a different port and keeping data between restarts. README.md at the top level is the project's public overview, including its market context. collateral/ contains the sales and marketing material — one-pagers, white papers and a user guide. specs/ holds the full written specification the software was built against, including the published interface contract for machines. initial-research/ holds the original market and standards research that motivated the project.

---

13. Common questions and things that catch people out

Does it scan my network? No. It consumes the results from scanners you already run, and adds the intelligence, ranking, workflow and evidence around them. If you have no scanner, get one first.

Why is a medium-severity problem sitting above a critical one? Almost certainly because the medium one is on the actively-exploited catalogue, or has a much higher exploit probability. That is the platform working exactly as designed. Click the row and read "Why this rank?" — the reasoning is always shown in full.

The order of the queue changed overnight and nobody touched it. Correct. Exploit probabilities are republished daily and the estate is re-ranked automatically to match. Expect this.

There is no password field. Where do I create accounts? There are none to create here. Sign-in goes to your organisation's normal login, and the platform never stores a password. People appear the first time they sign in.

I cannot find where to add a scanner / change a deadline / change someone's role. Those screens do not exist in this version. The Admin screen is a read-only overview. That configuration is done through the platform's interface for machines. See the note at the end of §6.

Why is the demonstration package signed in automatically? It deliberately bypasses login, because it is self-contained and has no corporate identity service to talk to. It also carries a built-in demonstration encryption key and runs everything in one container with no backups. Never deploy that package to production. It is for evaluation only, and it announces this loudly when it starts.

Nothing I did in the demo survived a restart. Also by design — it wipes and re-seeds every start. Turn on the persistence setting if you need otherwise.

I ran it and the page will not load. The most common cause is a mismatch between the port you published and the port you told it to listen on. They must be the same number.

Do I have to use the AI features? No. Leave the AI provider key unset and the AI panel simply reports it is not configured. Everything else — ranking, workflow, deadlines, reporting, integrations — is unaffected. AI augments this platform; it never gates it.

Can the AI change things on its own? No. In this version every AI-suggested change waits in the AI Queue for a person to approve it, and anything approved can be reversed. The mechanism for granting genuine autonomy under a named policy exists in the design but ships switched off.

Can the AI make something up? It is constrained not to. Every claim it makes must cite the underlying record it came from, and claims about severity, exploit probability or exploited status that are not backed by a real stored record are rejected. When it lacks the context to be specific it says so instead of guessing.

One of the data feeds went down. Have I lost the ranking? No. Ingestion and ranking continue on the remaining sources, and the affected values are marked stale with their last known value and the time they were last fetched. Nothing blocks on a dead feed. When two sources disagree, both are kept with their origins recorded and a defined precedence is applied rather than one silently overwriting the other.

A problem we fixed months ago has come back. If a later scan detects it again, the original finding re-opens rather than a duplicate being created — so its whole history stays in one place. That is intended.

We imported the same scan report twice. Nothing bad happens. Duplicate and retried submissions reconcile to a single record.

A finding arrived with no CVE number. It is still accepted, still ranked on whatever signals exist, and the missing information is recorded as a gap. It is re-ranked automatically if the details arrive later. Nothing is ever silently dropped.

Why does it insist on a reason for every status change? Because the reason is the evidence. A year from now, "why was this accepted rather than fixed?" is exactly the question an auditor will ask, and the answer needs to be in the record rather than in somebody's memory.

Does it discover my cloud machines automatically? Not in this version. Agentless discovery for AWS, Azure and Google Cloud is planned for a later release. For now, cloud machines arrive through your scanner or through bulk loading.

---

14. Where to get help

This project is part of the World's Biggest Software Project initiative — an open effort to build credible alternatives to expensive proprietary software. The community there is the place for questions, feedback, feature requests, and getting involved:

https://wbsp.ai

Domain expertise is as welcome as code. If you run a vulnerability management programme and something described here does not match how the work is really done, that feedback is more valuable to the project than a bug report.

Before you ask: user-docs/quickstart.md for a fast refresher on the screens, user-docs/production-setup.md for installation problems, preview/README.md for issues with the evaluation package, and user-docs/testing.md if you want to check whether a particular behaviour is deliberate and proven rather than accidental.