Good scan output starts with a one line verdict, lists only the findings that caused it, prints file, line and fix for each, and ends with a clear exit code and a link for detail. A developer should know in five seconds whether the build passed and why.
The problem with raw scanner logs
Many tools print everything: thousands of lines about files scanned, rules loaded and findings of every level. The one line that matters is buried. Developers scroll, give up, and rerun. Log design is a developer experience decision, and it affects whether findings get fixed.
A layout that works
- Verdict first. One line: "Security check failed: 2 blocking findings, 14 informational."
- Blocking findings next. Each with file, line, plain description and the fix.
- A short summary of the rest. Counts only, with a link to the full report.
- Timing. Total scan duration, so slowness is visible to everyone.
- Where to go. A link to the dispute path and the FAQ.
Keep colors optional. Some logs strip them, and meaning should survive plain text.
Exit codes are part of the interface
| Situation | Suggested exit behavior | Message |
|---|---|---|
| No blocking findings | Zero | "Passed" |
| Blocking findings | Non zero, a specific code | "Failed: blocking findings" |
| Scanner error or timeout | A different non zero code | "Scan did not complete" |
| Configuration error | Another distinct code | "Check configuration" |
Distinct codes let a pipeline treat a finding differently from an outage. If everything exits with the same code, you cannot choose fail open for outages and fail closed for findings.
Make findings copyable
Print file and line in a form editors and CI viewers can link to. Print package names with exact versions, and the safe version where one exists. A command that reproduces the scan locally is worth a line.
Control the volume
Print blocking items in full, and cap the number shown with a note about the rest. If hundreds of informational items appear in every run, move them to a report artifact. People should not need to scroll past noise to find a failure.
Keep it stable
Teams build scripts and search habits around output. Changing the format without notice breaks them. Announce changes, and offer a machine readable output mode, such as JSON, for tooling.
Test with someone new
Ask a developer who has never seen the tool to read a failing log and tell you what to do next. Watch where they hesitate. That is the line to rewrite.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how each finding names a file, a line and a reason.
Safeguard's CLI runs scans from a terminal and a pipeline. The free scan shows the report format without installing anything.
Quick check
Should scan logs include every finding?
No. Print the blocking ones in full, summarize the rest, and keep the complete list in a report people can open when they need it.
Why separate exit codes for errors and findings?
So the pipeline can decide differently. You may want findings to block while a scanner timeout only warns, based on your risk tier.
Last reviewed: 19 October 2026.
