How can you tell a seeded security demo environment from real data?

A seeded demo environment is a sample project loaded with data chosen to showcase features. Tells include perfectly varied severities, tidy names, findings that always resolve cleanly and no failed scans. The reliable test is to bring your own repository or manifest and see whether the product behaves the same way.

What seeding is and why it exists

Vendors need a demo that always works. They create a sample organisation, load known vulnerable projects and tune the data so each feature has something to show. This is reasonable. The risk is that a buyer mistakes the staged result for typical behaviour.

Six tells

1. Even spread. Findings are neatly distributed across critical, high, medium and low. Real estates are lumpy.
2. Friendly names. Repositories called payments-service and web-frontend, with clean directory layouts and no legacy folders.
3. Everything is fixable. Every finding has an available fix, and every fix applies without conflict.
4. No noise. There are no duplicates, no findings in test fixtures and no ambiguous items needing judgement.
5. No failures. Scans never time out, integrations never show errors and no repository is unsupported.
6. Round timing. Everything completes in a few seconds, regardless of size.

One tell is not damning. Several together mean you are looking at a stage set.

A short test to run

Ask to repeat one flow on your data. A good, small test is a single manifest from a repository you know, since it needs no installation:

1. Choose a manifest with a real mix of old and new dependencies.
2. Run the same flow the vendor just demonstrated.
3. Count findings, note the ones you cannot explain and the ones you expected but do not see.
4. Look for what the product says when it cannot do something. A clear message is a good sign. Silence is not.

Compare what you see with the tidy picture from the demo.

Questions for the vendor

• Is this data from a real customer, anonymised, or built for demos?
• What does the product show for a repository it cannot fully analyse?
• Can you run this on a messy repository of mine, live?
• Which features in this demo depend on setup I would need to do first?

Straight answers matter more than polished ones.

Why this is worth ten minutes

Buyers who skip this step often meet the real product during rollout, when developers see noisier lists, slower scans and fixes that need work. Nothing was hidden, but nothing was tested either. A short run on your own manifest moves that surprise to before the contract, where it costs far less.

Try it yourself

Click through it at your own pace, or open it full screen.

Treat it as a sample, and look for the six tells above. Then compare with what the free scan returns for a manifest of yours at gold.safeguard.sh/scan.

Quick check

Last reviewed: 19 October 2026.