Securing the ML Lifecycle
The final model is evaluated against the separate test data . Such a model can then be made available in the context of , for example , a cloud service so that it can be queried ( sometimes referred to as an inference model ). However , how this is done technically depends on the framework that was used for training ( e . g ., scikit-learn , keras , or pytorch ). Interoperability standards such as ONNX 8 try to address this . The MLOps community 9 also emphasizes that we cannot treat machine learning like traditional software engineering .
Figure
3-1 brings together our observations concerning the ML lifecycle and introduces the assets and stakeholders involved , which will be discussed in the next sections .
Figure 3-1 : ML Lifecycle , Assets and Stakeholders
For the purposes of this paper , we need to emphasize that the entire ML process is a result of several stakeholders interacting . This observation is fundamental for our discussion of the security requirements concerning the ML process as well as its technical artifacts .
Several stakeholders may participate in any given machine learning lifecycle 10 . Some entity will be the actual owner of the training data or act as an aggregator to whom ownership-like rights have been transferred as part of some legal agreement . The training code may be owned by some other entity , but it can be as confidential as the training data , as it includes the final training model architecture and selected parameters . The final “ trained ” ( inference ) model may be owned by either of the two former entities , but could also have been transferred to a separate ,
10
IIC Journal of Innovation 41