Notifications
Clear all
Topic starter
05/07/2026 6:53 pm
TL;DR: As enterprises treat AI models as first-class software artifacts, TrojAI and JFrog describe a workflow for scanning models, automating red teaming, and attaching compliance evidence before deployment, according to TROJ.AI. The real shift is governance: model risk now belongs in the same lifecycle controls as binaries, packages, and containers.
NHIMG editorial — based on content published by TROJ.AI: AI Security Where DevSecOps Meets AI Security: TrojAI + JFrog Integration
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: How should security teams govern AI models in DevSecOps pipelines?
A: Treat models as controlled artifacts with ownership, versioning, provenance, and release approval.
Q: Why do AI models need more than static scanning before deployment?
A: Static scanning can identify known file and dependency issues, but it does not show how a model behaves under adversarial prompts or multi-turn interactions.
Q: What breaks when model evidence is kept outside the artifact system?
A: Auditability breaks because reviewers cannot reliably prove which version was tested, who approved it, or whether the deployed model matches the tested one.
Practitioner guidance
- Classify models as governed artifacts Require provenance, version ownership, and approval status before a model enters build or deployment workflows.
- Add behavioural tests to pre-deployment gates Run single-turn and multi-turn adversarial tests on models that will influence decisions, customer interactions, or agent actions.
- Attach evidence to the artifact itself Preserve scan findings, red-team outputs, and approval records with the model in the repository or catalog.
What's in the full article
TROJ.AI's full post covers the operational detail this analysis intentionally leaves for the source:
- How the TrojAI Detect workflow connects into JFrog Artifactory and Evidence at the artifact level
- What automated red teaming looks like for single-turn, multi-turn, and agentic model tests
- How compliance teams can attach audit-ready evidence to model releases and approvals
- Where the planned runtime defence layer would sit in the broader AI security workflow
👉 Read TROJ.AI's analysis of AI model supply chain security in DevSecOps →
AI model supply chain security in DevSecOps: what changes now?
Explore further
05/07/2026 7:14 pm
AI model governance is now a supply chain problem, not a model-only problem. Once models are versioned and distributed like software artifacts, the security boundary moves to the registry, repository, and approval workflow. That means provenance, traceability, and chain of custody are now governance requirements, not optional hygiene. Practitioners should treat model intake as a controlled identity-adjacent event, not a convenience step.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
A question worth separating out:
Q: How do teams balance runtime AI monitoring with release-time controls?
A: Use release-time controls to decide what is allowed into production, then use runtime monitoring to detect drift, abuse, or unsafe behaviour after deployment. The two layers solve different problems, and runtime detection cannot compensate for weak pre-deployment governance.
👉 Read our full editorial: AI model supply chain governance now extends into DevSecOps
