 This includes vulnerability scanning, management, and patching components.  For development environments with access to sensitive data, apply these controls in those environments, too Maintain an up-to-date inventory of components using a Software Bill of Materials (SBOM) to ensure you have an up-to-date, accurate, and signed inventory preventing tampering with deployed packages.  SBOMs can be used to detect and alert for new, zero-date vulnerabilities quickly At the time of writing, SBOMs do not cover models, their artefacts, and datasets; If your LLM application uses its own model, you should use MLOPs best practices and platforms offering secure model repositories with data, model, and experiment tracking You should also use model and code signing when using external models and suppliers Anomaly detection and adversarial robustness tests on supplied models and data can help detect tampering and poisoning as discussed in Training Data Poisoning; ideally, this should be part of MLOps pipelines; however, these are emerging techniques and may be easier implemented as part of red teaming exercises Implement sufficient monitoring to cover component and environment vulnerabilities scanning, use of unauthorised plugins, and out-of-date components, including the model and its artefacts Implement a patching policy to mitigate vulnerable or outdated components.  Ensure that the application relies on a maintained version of APIs and the underlying model Regularly review and audit supplier Security and Access, ensuring no changes in their security posture or T&Cs.  Example Attack Scenarios An attacker exploits a vulnerable Python library to compromise a system