¶ What One ABAP Finding Identifies
An ABAP security finding is a statement about one object in one scan: it names the program or function module, the object type, the line range, the class of defect, a severity, and, where the analysis established one, the path through the code from the statement that takes the input to the statement that uses it.
That is a narrower unit than "this system has a code defect", and holding the narrower thing in mind is what makes a report readable. The RedRays ABAP Code Scanner keeps four levels apart: a finding belongs to one object scan, an object scan belongs to one run, and a run belongs to one project. Each of those is a different denominator, and a percentage taken over the wrong one is the most common way to misread a code scan.
A project is the outermost of the four levels, and every count underneath it belongs to a run that can still be named.
¶ What is on a finding?
| Part | What it is |
|---|---|
| Object and object type | the program, function module, class or other repository object the finding is about |
| Line range | where in the stored source the defect sits |
| Issue type and title | the class of defect, and a title naming the shape it took in this object |
| Description | the analysis service's own sentence about what was found |
| Data path | the source statement and the sink statement, printed as two hops |
| Severity | the band the finding was assigned |
| Exploitability verdict | whether the analysis judged the defect reachable, and what blocks it if not |
| Recommendation | what to change in the code |
| Status | what a person has decided about the finding since |
| Source listing | the ABAP as it was read at scan time, with the finding's lines highlighted |
The two parts that carry the most weight are the data path and the source listing, because together they let a developer confirm or reject the finding without leaving the screen.
The finding carries the path and the source it was argued from, so the developer can accept or reject it without opening SAP.
¶ Why is the data path the important part?
Because the individual statements are not defects. A dynamic CALL FUNCTION appears throughout ordinary ABAP, including SAP's own. A PARAMETERS line is how every report on every SAP system takes input. What makes a defect is a parameter declared on the selection screen reaching a dynamic call with nothing between the two constraining it.
A finding of that shape prints both hops: the declaration, then the call. Neither line is actionable alone. The pair is the finding, and it is the part a text search over source cannot produce.
¶ What does the severity mean?
The severity is a band assigned to the finding, and it drives how a scan is summarised. Two things about it are worth knowing before a number is quoted from a report.
First, severity is editable. A reviewer who decides a finding is less serious than it was rated can change the band, and the summary above the findings then follows the change. A severity in a mature installation is therefore one of two things: what the scan assigned, or what the last person to look decided.
Second, a severity is a rating, not a measurement of the customer's exposure. It says how bad this class of defect is in general. It does not know your client strategy, your network position or who holds the transaction.
¶ What does the status mean?
The scan writes one status, meaning nobody has looked at the finding yet. Every other status is a human decision: accepted, not exploitable, or fixed. A decision recorded against a finding carries forward when the same object is scanned again, so triage is not repeated at every run.
A status is a statement about a decision, not about the code. A finding marked not exploitable is still in the report and still in the export, which is the point: suppressing a finding is not the same as not finding one.
¶ What does "exploitable" claim?
That the analysis judged the defect reachable in the code as written, and, where it did not, that it recorded the reason. It is not an exploitation. Nothing was attempted against a running system, no function module was called and no data was read. The only mechanism that revisits the verdict is a retest, which reads the object's current source out of SAP and analyses it again.
¶ Limits
- A finding is about one object as it stood when it was read. The stored source is what the finding is argued from. If the object changed afterwards, the finding still reads exactly as it did.
- A finding is not a statement about the estate. It is one check's answer about one object. Nothing follows from it about the other objects in the same package, let alone the rest of the system.
- Findings are not deduplicated. Nothing joins the same defect across two objects, two runs, two projects or two systems. A second scan of one object writes new findings rather than updating the old ones.
- The absence of a finding has more than one cause. The checks may have run and found nothing; the check for the defect present may not have been in the profile; or the object may not have been read at all. Scan profiles and what clean means separates them.
- A rate over a small object is arithmetic, not a measurement. One finding in a twelve-line program is a defect density of eighty-three per thousand lines, and it means nothing. Read counts against the object count and line count the run states.
¶ Frequently asked questions
¶ Can a developer act on a finding without opening SAP?
Usually yes. The finding carries the source as it was read, with the affected lines marked, the data path, and the recommendation. Confirming the defect and deciding the fix can be done from the finding; making the change happens in SAP.
¶ What happens when the code is fixed?
Re-check the finding. A retest reads the object's current source out of the SAP system and analyses it again, so the answer is about the code as it stands rather than the copy the original scan stored.
¶ Does a finding say which authorisation object protects the code?
Where a check is about a missing authorisation check, the recommendation names what should be checked. It does not analyse who holds that authorisation today. That is SAP segregation of duties analysis.
¶ Why do two scans of the same program produce two sets of findings?
Because each run is recorded separately, which is what makes it possible to say a finding is new rather than merely present. A decision recorded against a finding carries forward; the rows themselves are not merged.