On this page
- Check completion and coverage before interpreting a result count.
- Keep the failed attempt separate from the last completed baseline.
- A successful lookup with no matches still has a defined scope and date.
First find out which part failed
A source upload, dependency reader, vulnerability service and document export are different stages. A failure in one does not automatically tell you what happened in the others. Begin with the safe error message and the assessment attempt it belongs to, rather than repeatedly clicking the same button.
For source intake, check whether the material was accepted and whether any coverage limitation was reported. For component discovery, check whether a recognised document was usable. For vulnerability results, look for the lookup status and the time of the last successful check. These details matter more than a reassuring zero.
Read an empty result in context
The following states can all produce a short list or no list at all. They should lead to different next actions.
| Observed state | Reasonable interpretation | Next step |
|---|---|---|
| Check completed with no matches | No matches were returned for the checked inputs at that time | Review coverage and keep the dated result |
| Vulnerability lookup unavailable | The lookup does not establish whether there are matches | Retry when available and keep the degraded state visible |
| No usable dependency document found | The accepted evidence did not establish the component inventory | Supply or correct the relevant inventory evidence |
| New attempt failed; older run completed | The older result remains historical evidence | Investigate the new attempt without presenting the old inputs as current |
What ConformOps keeps separate
ConformOps records OSV lookup health rather than treating an unavailable service as evidence of no vulnerabilities. Component discovery also distinguishes an absent recognised document from documents it could not parse. Neither state means that the product has no dependencies.
A queued, running or failed repeat assessment is kept separate from the newest completed baseline. You can still understand the earlier record while investigating the latest attempt. If inputs changed, the earlier baseline may be marked stale. Readable historical evidence is not a current approval.
The release evidence guide explains the relationship between inputs, runs and later changes. You should be able to name the release and run before sharing any result.
Retry without losing the question you were investigating
Record what you expected, the safe error code, when it occurred and whether the issue followed an input change. If a dependency file is malformed, another identical attempt may fail in the same way. If the problem is an external lookup outage, changing product facts is unlikely to help.
Use the application's supported retry or repeat assessment control and inspect the resulting state. Do not label a previous report as fresh just because the new attempt has started. If there has never been a completed run, partial output from a failed attempt is not a usable baseline.
Ask for help without sending your repository in an email
A useful support request explains the operation, the time, the visible state and what you already tried. Remove credentials and unrelated personal information from anything you share. Do not paste source files or an entire evidence package into a first support message.
The guide to getting unstuck includes a request template and helps distinguish a software problem from an unanswered compliance question. A good recovery leaves you with an explainable result, not just a screen that happens to be green.
Frequently asked questions
Does zero vulnerabilities mean my product is secure?
No. It means no matches were reported within the scope and conditions of that check, if it completed successfully. It does not cover every vulnerability, prove exploitability decisions or establish CRA compliance.
Can I keep using my previous assessment after a failed rerun?
The completed record remains useful as historical evidence. Check whether it still describes the current release and inputs. A failed new attempt does not make an older or stale baseline current.
Does ConformOps execute my application to scan it?
No. Its source intake processes accepted evidence relevant text; it does not execute your repository code. A readiness assessment does not replace runtime security testing or a penetration test.