If a step takes objects as input arguments, these objects are is stored in an ArgumentsAction for visualization and to provide a record of parameters – unless the input fails to serialize. However Steps can take completely arbitrary input types. For robustness it would be better if we only store simple types that can be used for visualization (basically anything that is legal for a DescribableModel) and NOT just any random input.

We also need to ensure complex objects passed in are sanitized (remove inputs containing passwords) & length-limited. If they're Describables we should explode them into UninstantiatedDescribables for recursive argument processing and safer storage.

Concrete example: we've seen at least one example recently where Artifactory plugin's steps are passing in a class with the Pipeline-internal CpsScript as a (transient) field. This causes a serious memory leak because the Step's arguments can remain in memory after the build has completed and that CpsScript carries a lot of baggage.

This isn't a bug in Pipeline itself per se – because plugins providing Steps shouldn't be abusing the inputs or passing in very complex object types – but it's better to protect against bad inputs than not to.