NO! Never! (I can see security folks seething and gnashing teeth right now) They should not have that access unless absolutely necessary. QA should match Production enough to be usable to resolve most all issues. If not, then you typically give "firefighter" access to production....this would be VERY short access (day or so if that) and watched. This is rare to do unless mission critical issues that can not be hunted down in QA.

To build upon Chris's answer, bear in mind that just because the client is marked "non-modifiable" in SCC4 does not mean that someone with developer authorizations and SE38 cannot still do harm. In fact, you mentioned the main reason to not grant this: debug. Using the debug feature, a knowledgeable person can bypass authorizations and substitute different values during runtime of a program. This would be a classic way to inject something malicious without leaving much of a trace. Not to mention, using debug does have a performance impact on production, in that it locks up the work process in privileged mode for the duration of the debug session.

Cheers,
Matt

"Our ABAPer is requesting to grant SE38 on permanent basis in Production Environment"...I would be keeping an eye on that "ABAPer" from here on. haha

Hi Aeman,

It is not recommended to grant access to the transaction SE38 or "/h" debug option in a production environment. If an ABAP programmer wants to display the code, they should use a DEV, QAS or PRE-PROD environment to do that. Also, if your company is running audit processes, they will probably check if someone have access to transactions like those ones in a production environment. As Matt wrote in his comment, with the debug option, a programmer can find the "Authorization Check" in the ABAP code and bypass authorization restrictions in a production environment, so that is an additional reason to deny that access in PROD.

To solve that request, I will recommend you to tell them to display the code or debug processes in a system that is not a production environment.

Regards,

Carlos

I dont know the details because im not in security, but you can allow to debug while not being able to let them change values while debugging. Also you can let them have access to for example TRX SE80, but do not allow them to execute programs, so they can see the source code but they can not execute the reports/function modules/etc directly. I know it can be done cause i have seen it.

Hope that helps.