A service page should answer six questions at a glance: who owns this, when was the inventory last refreshed, which findings are reachable, which have a fix ready, is the merge gate on, and what exceptions are open. Anything beyond that belongs a click away.
Why keep it short
The CNCF platforms white paper lists reducing cognitive load as an essential goal of a platform. A dependency tab with 400 raw findings does the opposite. Developers learn to skip it. A short, ordered summary gets read, and the detail stays available for those who need it.
Backstage's own description says its catalog exists to manage all your software in one place, including services, libraries, data pipelines, websites and ML models. That makes the catalog a natural home for the summary, whichever portal you use.
The six facts
| Fact | What it tells the developer | Why it matters |
|---|---|---|
| Owner | The team accountable for this service | Findings need someone to route to |
| Inventory freshness | Date of the last dependency scan or SBOM | A stale inventory hides new risk |
| Reachable findings | Count and top items where vulnerable code is used | Focuses work on what can be hit |
| Fix ready | Findings with an available fixed version | Shows quick wins |
| Gate status | Whether the merge check is on and passing | Confirms the service is on the path |
| Open exceptions | Active exceptions with end dates | Prevents silent risk acceptance |
Notice what is missing: total CVE counts, severity histograms and trend lines. Those are for security leadership views, not for a developer deciding what to do before lunch.
Steps to build it
- Pick the six facts and agree the definition of each with the security team.
- Pull the data from your scanner or inventory through an API, not by hand.
- Show one status color per fact, with a text label so it works without color.
- Link each fact to the underlying detail and a short guide on what to do.
- Add a banner when the service is off the golden path, saying which controls are missing.
- Try it with three developers and ask what they would click first.
Pitfalls
- Showing a score with no explanation. Developers cannot act on a number.
- Mixing old and new data. Always show the age of what you display.
- Counting findings in dev only tools the same as in shipped code. Separate them or say so.
- Building the view before ownership data is clean. If the owner field is wrong, every other fact is misrouted. See what a software catalog is and why vulnerability management needs one.
Leadership view is separate
Keep an aggregate view for managers: services by wave, time to fix, exceptions by age. See how to measure paved road adoption.
Where Safeguard fits
Safeguard produces the underlying data: SBOM and dependency scanning, reachability analysis, available fixes, policy and gate status, and asset discovery to help with ownership gaps. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Open the demo and compare the raw list with the reachable subset. That second view is what the service page should lead with.
Click through it at your own pace, or open it full screen.
Quick check
Should the portal show every CVE?
Not on the service page. Lead with reachable findings and fixes ready, and link to the full list.
Do we need a portal to show this?
No. A simple dashboard or a README badge can show the same six facts.
Sources
Last reviewed: 19 October 2026.
