Example workflow you can build
Turn a dependency alert into an owned fix.
An agent traces a package alert to the deployed service and its owner. Security and service owners decide the response.
01 The problem
Your system
"Our portal uses an upload library with a known vulnerability."
Webhookstarts an oz0 job
02 The agent investigates
- Tool rules & approvals
- Model budgets
- Job history
Your task plugin
Runs on your oz0 node
Connector tool · Advisories
Comparing the installed library with the security advisory.
Result: Version is in the affected range.
Connector tool · Deployment inventory
Your systems
- Upload library
- Deployed image
- Customer portal
Result: Library found in production.
Connector tool · Ticketing
Links the affected version and service. Flags what still needs checking.
03 People decide
Your security and release process
Set the priority and review a tested patch through the usual process.
04 The outcome
Approved
Your systems
Applies the approved replacement image.
Agent checks the running version and service health.
Denied
Rejected patch or failed tests: revise.
Keep the finding open.
Both possible outcomes are shown. No real actions run.
How these parts fit
- Plugin
- Installable package of agents, tools or instructions.
- Agent
- Uses your model to choose tool calls.
- Connector
- Plugin providing tools for an outside system.
- Tool
- Exposes actions the agent can call.
- Webhook
- Notification that starts configured work.
Use existing plugins or build these integrations. Plugin docs
Package presence does not prove exploitability. A merged patch does not prove deployment.
What you connect
Connect the repository, advisory service, deployed package inventory, service ownership, ticketing and release records. Configure a model and access rules.
Build an agentA starting point
cve-triage reads lockfiles, checks OSV, ranks findings and drafts tickets. Service mapping and remediation tracking need your integrations.
DocsThese starters are documented; publication varies. See oz0 Hub for availability.