Every company that runs servers in the cloud consulting services faces the same uncomfortable question: do we actually know what is running, and do we know which parts are dangerous right now? Most organisations cannot answer confidently.
OptimusCyber Citadel is the project we built to answer that question honestly and automatically. The easiest way to picture it is as an automated security inspector and remediation workbench for cloud infrastructure — in short, practical cloud vulnerability management from end to end. It inspects your cloud consulting services, works out which ones carry known security weaknesses, removes the false alarms, ranks what remains by real-world danger, and then lets you fix, verify, and track those issues from a single dashboard. It does all of this using simple, transparent rules, with no paid services required and at essentially zero running cost.
A simple analogy
Imagine a building inspector visiting an office block. A lazy inspector reads the original blueprints and lists every problem the building might have. A good inspector walks every floor, checks what was actually built, ignores the problems that were already repaired, and then hands the owner a prioritised list — “fix the wiring on floor 3 today, repaint the lobby whenever.”
The big idea: cloud consulting services vulnerability management as a pipeline
Good cloud consulting services vulnerability management is not really about owning a scanner. Most teams do not struggle because they lack a scanner. They struggle because the signal-to-noise ratio is terrible, and because finding a problem is not the same as fixing it.
How it works — the five stages
Stage 1 — Collect (what we run)
Citadel connects to the cloud and inspects each server’s actual live state: the operating system, the installed packages, the exact versions, and the running services. It works across AWS, Google Cloud, and Azure. On AWS it uses Systems Manager (SSM) to run inspection commands inside each server, so it captures what is genuinely running rather than what a console merely claims is there.
Stage 2 — Find the weaknesses (what is vulnerable)
Next, Citadel checks that inventory against the National Vulnerability Database (NVD) — the U.S. government’s official, public catalogue of known software vulnerabilities. For every piece of software it asks a precise question: are there known security holes for this exact version?
Stage 3 — Remove the ones already fixed (what is actually exploitable)
This stage quietly does the most work. Here is the catch: NVD does not know how individual operating-system vendors actually ship their software. Vendors such as Ubuntu frequently backport a security fix — patching the problem while keeping the old version number — so to a version-matching tool it still looks vulnerable even though it was fixed weeks ago.
Stage 4 — Recommend (what to do)
Every vulnerability that survives gets a clear tier:
- Fix available now — there is a patch you can install today.
- Fix upstream but not ready — the vendor is working on it; keep watching.
- No fix yet — nothing to install; monitor and apply mitigations.
Stage 5 — Advise, apply, and track (close the loop)
This is the stage that turns a list of problems into resolved problems. Stages 1–4 establish the truth; Stage 5 is where an operator actually acts on it — all from one screen, without hand-running commands.
Plain-language advisories.
A dashboard to browse everything.
One-click apply, then validate.
Lifecycle tracking and reports.
What the demo showed
Numbers make the value concrete. On a single Ubuntu server, Citadel began with 1,258 possible vulnerabilities. After removing the issues the vendor had already fixed, 801 genuine findings remained — each tagged with a recommendation and a danger ranking.
But the most important finding was an honest one: most of those 801 issues had no instant fix yet. So the realistic message is “keep the system updated, monitor, and patch as fixes land” rather than “run one magic command” — and Stage 5 is exactly what makes that ongoing tracking possible. A tool that tells you this truth is far more useful than one that pretends every problem has an instant button.
How the engine actually runs
Citadel has two delivery modes that share the same core logic. In the deployed product, everything is database-driven: a single service starts the web server, serves the dashboard, runs the database, and performs a daily refresh of the vulnerability data — running Stages 2–4 against the database and layering Stage 5’s advisories, apply, and UI on top.
A quick glossary
| Term | Plain-English meaning |
|---|---|
| CVE | A unique ID for one specific publicly-known security vulnerability. |
| NVD | The U.S. government’s official, free database of known vulnerabilities. |
| EPSS | A score estimating how likely a vulnerability is to actually be exploited. |
| KEV | A list of vulnerabilities attackers are already exploiting in the real world. |
| SSM | AWS Systems Manager — used to run inspection and fix commands inside a server. |
| Backport | A fix applied to an older version without changing its version number. |
Important things to keep in mind
A few honest caveats shape how the tool should be used. Most findings will not have an instant fix — expected, not a defect, because the fixable ones have already been filtered out. The one-click apply capability runs real commands on real servers, so it must be used with caution and proper change control. Reports should show the date the analysis ran, not when the inventory was collected, so readers are never misled about how current the picture is.
Why this matters for GRC and operational risk
From a governance, risk, and compliance perspective, Citadel does far more than find bugs. Each stage produces an inspectable, dated artifact, and Stage 5 adds a full lifecycle record — open, patched, resolved — for every finding. Together they form a clean audit trail running all the way from asset discovery to verified remediation. That traceability directly supports regulatory compliance reporting, feeds operational risk metrics, and gives internal audit a defensible record of exactly how each vulnerability was identified, de-duplicated against vendor fixes, prioritised by real exploitability, fixed, and verified.
Frequently asked questions
Does Citadel use AI to find vulnerabilities?
No. Detection, filtering, and ranking use deterministic rules and free public data, which keeps the results auditable and predictable. There is an optional AI-enhanced advisor that improves the wording of patch advice for higher-severity findings, but it never invents fixes and falls back to the rule-based advisor if unavailable.
Can it actually fix problems, not just report them?
Yes — that is Stage 5. It can apply a fix to a server, verify the fix took effect, and track the finding through its lifecycle. Because it acts on live systems, it should be used within normal change-management controls.
Why are so many findings left without a fix?
Because that is the honest reality of security. Many vulnerabilities have no released patch yet. Citadel has already removed the ones that were fixed, so what remains genuinely needs monitoring.
How much does it cost to run?
Effectively nothing for the core. It relies on free public data sources (NVD, EPSS, KEV) and lightweight code. The only optional paid component is the AI-enhanced advisory wording.
The bottom line
OptimusCyber Citadel turns cloud consulting services vulnerability management from an overwhelming wall of alerts into a short, honest, prioritised to-do list — and then helps you actually complete it. It inventories what you really run, matches it against the official vulnerability database, strips out what your vendor already fixed, ranks what remains by genuine real-world danger, and finally lets you apply, verify, and track each fix from one place.
