It is in the admin section due to security reasons: the script can basically do anything on your system so it is only safe to be checked by an admin.

I think we found a secure workaround for this: I will prohibit Groovy parsers to scan the console log. They are permitted only to scan files on the agent. Then only an agent might be compromised by a not well behaving script.

The older Warnings plugin is the only way to define a custom console parser given this restriction – so this is a regression in functionality, blocking us from fully moving over to Warnings NG. Since the system-level parsers are able to be defined only by Jenkins administrators, how about allowing those parsers to access the console log while allowing job-level custom parsers to access only files in the workspace?

It would be nice if the parser would be configurable in a declarative manner. Then the security concerns would be alleviated and any job can just provide the configuration in a file.

We need to parse the whole job log, so using tee is not an option for us. This is really blocking us from moving forward to warnings-ng plugin. This I can do now by fetching the log from the currentBuild and writing it to a file.

For the old warnings plugin I could add a parser with 

Jenkins.instance.getExtensionList(hudson.plugins.warnings.WarningsDescriptor.class).get(0).addGroovyParser(new hudson.plugins.warnings.GroovyParser(...))

How can this be done for the new warnings-ng plugin?