¶ Scan Profiles and What Clean Means
A scan profile is the named set of checks a scan runs, and a clean result is a statement about that set: it says the checks in the profile found nothing in the objects that were read, not that the objects are free of security defects.
That distinction is the single most important thing to understand about reading an ABAP code scan, and it is not specific to one product. Every static analyser has a scope, and every clean report is scoped. What matters is whether the report tells you what the scope was.
¶ What is a scan profile?
The scanner ships one catalogue of checks and a set of profiles over it. A profile is a subset of that catalogue, and the operator chooses one when starting a run. The subsets are organised by the severity a check declares, so a run can ask the whole catalogue, or only the critical checks, or only the critical and high ones, and so on.
| Profile shape | What it runs | What a clean result from it means |
|---|---|---|
| Full catalogue | every check the product ships | every check was asked and none fired |
| Critical and high | the two most serious bands | those checks found nothing; the medium and low ones were not asked |
| One severity band | the checks in that band only | a narrow question was asked and answered |
| Quick | no explicit check list; a general analysis pass instead | a real analysis, produced by a different route from a per-category audit |
A narrow profile is a legitimate choice. Scanning a large namespace against the critical checks alone is fast and produces a short list of things to fix first. The mistake is not running one. The mistake is reading its output as though the whole catalogue had run.
A profile is a named subset of one catalogue, and the number of checks behind it is what a clean result from it is worth.
¶ Why does a clean result depend on the profile?
Take the missing authorisation check, which is one of the most common defects in custom ABAP and is rated in the middle of the severity range rather than at the top. A program that reads payroll data with no AUTHORITY-CHECK in front of it will be reported by the full profile and will not be reported by a critical-only profile, because the check that names that defect is not a critical one.
In both cases the object is read, sent for analysis, and comes back with nothing. The run completes, the object count is right, and the result is clean. One of those results means the code passed every question the product knows how to ask. The other means six or seven questions were asked and this was not one of them.
Nothing about the code changed between the two. The profile did.
A clean card reads the same whether the whole catalogue was asked or one band of it, so the profile beside it is part of the result.
¶ How many ways can a scan finish with nothing?
At least four, and they are different facts:
- The checks ran and none fired. The honest clean result, and the one a reader assumes.
- The check for the defect present was not in the profile. The object was read; the question was not asked.
- There was nothing to analyse. An object with no source, or one that is nothing but comments, completes without an analysis pass.
- The object was not read. If the scan account cannot read an object type, that object contributes nothing to the report.
Only the first is a clean bill of health. This is the platform-wide rule stated on what a finding does and does not claim: a zero and "we were not told" are different answers, and a check that never ran is not a check that passed.
¶ How to read a clean ABAP scan
- Note the profile. The run records which profile it used. Read the result against it, and treat the profile name as part of the result rather than as metadata.
- Note the denominator. How many objects, how many lines. A clean result over four objects is a statement about four objects.
- Compare the object count with the candidate count. If discovery offered more objects than the report covers, something was not read.
- Run the full profile at least periodically. A narrow profile is for speed. A statement about the code needs the whole catalogue behind it at some point.
¶ Limits
- A profile is a severity subset, not a customer ruleset. The profiles are bands over one shipped catalogue. They are not per-customer policies, and the checks in them are not authored per landscape.
- A profile counts checks, not certainty. Asking every check the product ships is not the same as asking every question that could be asked. A defect class outside the catalogue is outside the report.
- A result screen is narrower than a run. The profile a run used is recorded with the run. When a result is exported, forwarded or screenshotted on its own, it travels without its scope, so carry the run reference with it.
- A narrow profile makes a fast scan, not a cheap one. Reading the objects costs the same. What changes is how much is asked of what was read.
¶ Frequently asked questions
¶ Which profile should we run?
The full catalogue for anything you intend to report on, and a critical-only profile when you want a short list to fix first. Running the narrow one is fine; publishing its output as a clean bill is not.
¶ Can we build our own profile?
Profiles ship with the product as severity bands over one catalogue. Per-check editing is not enabled on a standard licence, so the practical choice is which band or bands to run.
¶ Does a wider profile take longer?
Not proportionally. Most of the cost of a scan is reading each object and sending it for analysis, which is the same work either way. The number of checks changes what is asked, not how many objects are handled.
¶ How do we prove to an auditor which checks ran?
By reference to the run. The run records the profile it used, the objects it read and the line count it covered. Quote the result together with that record rather than on its own.