How do you evaluate the risk of allowing a particular static method call in a pipeline?

[David Karr]

When I try to call a static method in a pipeline script that doesn't have an existing script approval, I get an exception, which requires a script approval.

What exactly is the risk involved here?  How does someone evaluate the risk of calling a particular static method?  For instance, I needed to emit some json from an object, so I tried to use the JsonOutput class, which has all static methods.  My Jenkins admin is going through channels to determine whether there's a risk here, and this seems like a waste of time to me.

[James Nord]

well toJson can take a URL which could be a file:// path to some file on the master which you should not be able to read which could allow you to retrieve anything (including all secrets) in a Jenkins home.

(There is also a method that takes a closure which is abitrary code.)

Basically yeah - that would be a security risk :)

As for how do you evaluate it, you need to think how can I misuse this to get access to something that I should not be able to...

But, I will push this a different way.

Pipeline should be used for orchestration and not complex build logic.  Putting in build logic makes it hard to test and debug and adds load to Jenkins.  Why don't you do the data manipulation in shell scripts where you can easily test / reproduce issues in a local environment?