Remote code analysis in ATC – Maintain exemptions approvers according to their responsibilities
This is the twelfth blog of the blog series about Remote Code Analysis in ABAP Test Cockpit (ATC).
See also the blogs:
If developers want to supress ATC findings from the ATC result list, they can create exemption requests for those findings, which have to be approved by a quality expert (see also the blog Remote Code Analysis in ATC – Working with Exemptions). Until now, while requesting an exemption a developer could choose any quality expert from the approver list, which was maintained by the ATC administrator in the SAP GUI transaction ATC.
For example, the hard-coded username can present a security risk and it appears as an error in the ATC result list:
While requesting the exemption for this ATC finding a developer can choose any approver from the list:
This list is maintained on the central ATC check system in the ATC transaction (under Exemptions->Maintain Approvers):
Especially in remote ATC scenario, if one central ATC system manages the quality of a number of local systems in the customer landscape, it can be useful in some cases to be able to specify the areas of responsibility of the approvers in more detail. For example you might want to assign some experts as approvers for a specific software component, an experienced security expert as an approver for security issues and so on.
This is now possible with the SAP Note 3128712 – Enabling a more flexible means of assigning exemption processing responsibilities.
How to maintain the areas of approver responsibilities
The ATC administrator can define areas of approver responsibilities on the central ATC check system in the ATC transaction under the Exemptions ->Maintain Approver Responsibilities:
Under the Responsibilities tab approvers can be assigned to the specific areas of responsibilities. It is also possible to assign one approver to multiple areas of responsibilities or several approvers can take care of the same area of responsibility. Under the Areas tab the areas are defined based on check groups (for ATC check specific aspects) and objects groups (for object specific aspects). The details of the groups are maintained in the respective tabs Check Groups and Object Groups.
Let’s take a closer look at this using our source code example containing the security issue with the hard-coded username. This source code example also contains another issue, related to the read access to the table without ORDER BY clause, which appears as a warning in the ATC result. We want to establish a security expert, who will be an approver for all ATC security related exemptions, and all other ATC exemptions should be approved by other selected approvers. Let’s start with the tab Responsibilities (you can start with any tab) and assign the user DOLINSKAJA as approver for security findings related exemptions and the users JUNG, EDER and BERND as approvers for all non-security issues (just click the “+” button and enter an approver and an area of responsibility):
Now you can define the SECURITY and NON-SECURITY responsibility areas by providing area name and description. For this example we want to focus our responsibilities areas on ATC security checks and not distinguish objects groups (just consider all objects):
Next, we will define the ONLY_CVA check group by providing name, description and the check class (of course it is possible to define more complex selection options by for example adding additional categories, using patterns in the Option column and so on):
Now we define analogous to the ONLY_CVA check group, the ALL_EXCEPT_CVA check group, containing all checks except of the security checks:
Finally, we define the object group, containing all objects (since we don’t distinguish object groups in this example):
Generally, there are more options for the definition of object groups. In the Selection Options area you can use as a selection option “System Group”, “Application Component” or “Software Component” or define objects namespaces using patterns:
After saving changes we click the Check button to validate all our entries. The warning below signalizes that we haven’t defined any selection options for the object group ALL. This is correct, but in our example it is not required. Since during definition process of approver responsibilities areas you do many inputs, you should always use the Check button to verify your changes.
Don’t forget to click the Save button to save all your changes.
Finally, the approver areas of responsibilities must be enabled in the ATC transaction (under the Basic Settings):
Now a developer can rerun the ATC over the source code example. If the developer now requests an exemption for the security finding, only the security expert will be suggested as approver in the Request Exemption wizard:
If the developer requests an exemption for another ATC finding (read access to the table without ORDER BY clause), then the approvers of the NON-SECURITY responsibility area will be suggested:
Of course you can continue the definition and for example assign the security expert as approver for all other responsibility areas or restrict the responsibility of the security expert to a certain software component and so on.
How to extend the selection options for check groups and object groups
For the check groups we consider currently only the Check Class as a selection options category. You may want to expand this in order for example to differentiate non-security checks on the ATC message level. For such use cases there is the possibility to extend the check group selection criteria over the BAdI:
You can then create your BAdI and implement the interface IF_SATC_CI_CGRP_FILTER. This interface has only one method IS_PART_OF_GROUP, which gets as input the information about check name and message code, and you can use this information to override the selection options of the check group with your own aspects.
In the same way you can extend the object group by creating the BAdI for the object group and implementing the corresponding interface IF_SATC_CI_OGRP_FILTER:
There you get more information as input from the IF_SATC_CI_XMPT_OBJECT_INFO interface, for example object type, object name, system group and so on. Thus, you can use more criteria for the object group definition, for example define the object group containing objects older then a specific date or objects from a specific system and so on.
In this way you can flexibly override the selection options of a check group or/and an object group with your own BAdIs.
Thanks for your continued work on the ATC. This new functionality is very interesting to us.
On checking the OSS note though, do I correctly understand that the satellite systems need prerequisite notes applying and the system needs to be at least on 7.40?
yes, your understanding is correct.