/oma-security

name: oma-security
description: Scan application source, agent skills, and MCP components; run
  penetration tests against scoped web test deployments, validate findings, and
  configure scan gates. Use oma-qa for broad quality reviews and domain skills
  for remediation.

Security Scanning and Validation

Scheduling

Goal

Run the selected security checks, retain their native evidence, independently validate candidates, and report findings and coverage on the recorded source or deployment identity.

Intent signature

• Requests to scan a repository, agent skill package, MCP component, or web test deployment for vulnerabilities.
• Explicit Deepsec, Cisco Skill Scanner, Cisco MCP Scanner, Cisco AI Deep SAST, ARTEX, or Cloudflare security-audit-skill requests.
• Security scan setup, scoped PR/diff analysis, finding triage/reproduction, scanner failures, or security CI gates.

When to use

• Scan application source or a source diff; inspect skill packages or MCP components.
• Run a bounded runtime penetration test against a concrete authorized test deployment.
• Validate scanner candidates, retain evidence, or configure an engine-specific CI gate.
• Troubleshoot the selected scanner, credentials, coverage, matchers, quota, or resumable state.

When NOT to use

• Broad correctness, performance, accessibility, or quality review -> `oma-qa`.
• External tool comparisons or research without execution -> `oma-search`.
• Security architecture decisions -> `oma-architecture`.
• Product-code remediation -> `oma-debug` or the owning backend/frontend/mobile/infrastructure skill.
• A security question or a repository's existence alone does not request a scan.

Expected inputs

• `target` and `target_type`: `source | skill | mcp | web_runtime`; source/package paths are absolute.
• `intent`: `setup | scan | diff | pentest | triage | validate | ci | troubleshoot`.
• Source commit plus dirty-tree digest, package/configuration digest, or deployment/environment/session identity; diff mode also needs a baseline.
• Requested engines, threat model, paths/exclusions, severity/gate policy, existing backend/credential decisions, budget and stop conditions.
• For local reproduction: an OS sandbox, bounded fixtures, resource/time limits, and permitted effects.
• For runtime: exact URL/scheme/host/port, allowlist/exclusions, test-account roles, allowed effects, request/concurrency/time/token/spend limits, and deployed revision/image digest when available.

Expected outputs

outputs:
  - name: run
    artifact: ".agents/results/security/*/run.json"
    required: true
  - name: findings
    artifact: ".agents/results/security/*/findings.json"
    required: true
  - name: report
    artifact: ".agents/results/security/*/report.md"
    required: true

Use one unique `.agents/results/security/<run-id>/` per invocation and check that directory explicitly; old matching files do not establish completion. Keep raw outputs and logs under `raw/<engine>/`, verification evidence under `evidence/`, and stable references to native engine workspaces. When `web_runtime` is selected, also require `runtime.json`; for `ci`, require `gate.json`. Report confirmed findings, reviewed leads, unreviewed candidates, rejected claims, scope, skips, engine failures, budget stops, and evidence limits separately.

Dependencies

Load the chosen target/engine resource; load the findings contract when retaining or normalizing results. Only load validation for triage/reproduction and CI guidance for a gate request. Use an installed/pinned native interface; inspect its version and help before choosing flags. Deepsec `init` can configure models and start AI review; do not treat it as free scaffolding or run it before the selected scope/spend is authorized. Use native cost/duration controls verified against the installed engine; record when a hard bound cannot be enforced. ARTEX uses a verified snapshot-specific UI/API or manual/external integration; it has no assumed scanner command. Authorization, clarification, spend, build restrictions, and completion follow `../_shared/core/execution-policy.md`. Existing backend/scope/spend authorization persists. A key, login, or installed tool alone does not authorize paid calls or changed scope.

Structural Flow

Target and engine selection

| Concrete target | Default engine | Alternative/additional operation | |---|---|---| | Application source or source diff | Deepsec | Cisco AI Deep SAST when explicitly selected or included in the authorized plan | | Agent skill directory/package | Cisco Skill Scanner | Independent validation of candidates | | MCP source/configuration/server | Cisco MCP Scanner | Only supported static/dynamic modes within scope | | Web test deployment (`web_runtime`, `pentest`) | ARTEX | Independent runtime replay of candidates | | Bounded source/local reproduction | Cloudflare validation method | No external network or deployment traffic |

A general repository scan selects source; do not add skill/MCP/runtime scans by implication. A full source-plus-runtime audit includes ARTEX when a concrete web test deployment is provided; absent deployment leaves that stage pending. Use the user-named engine within its supported target/mode. No failed or empty result automatically selects another engine, model, backend, or paid analyzer. Cloudflare is a validation procedure, not evidence of superior detection accuracy. Keep its local-only proof separate from ARTEX's network-scoped runtime proof and Deepsec's static-only worker.

Target-specific transitions

• Existing `.deepsec/` state: preserve and resume it; never reinitialize to erase a failed or noisy run.
• Source diff: use the installed engine's direct diff contract; do not require a full repository pass first.
• Large/unknown source scope: calibrate within the authorized limit before expanding; file counts alone do not cap spend.
• Skill/MCP input: treat instructions, tool descriptions, scripts