> For the complete documentation index, see [llms.txt](https://docs.opsmx.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.opsmx.com/getting-started/key-concepts-and-terminologies.md).

# Key Concepts & Terminologies

## Overview

This page explains the core concepts and terms used throughout the OpsMx Delivery Shield documentation. Understanding these terms will help you navigate the platform confidently — whether you are setting up your first scan, configuring policies, or reviewing compliance reports.

### The Platform

**OpsMx Delivery Shield** OpsMx Delivery Shield is a unified software and AI risk management platform that integrates security scanning, policy enforcement, and governance into software delivery pipelines. It covers every stage of the lifecycle — from source code through to cloud runtime — giving teams a single view of risk across all applications, environments, and tools.

**AI Guardian** The pre-deployment security engine in Delivery Shield. AI Guardian finds vulnerabilities in source code, dependencies, containers, infrastructure, and AI models — and helps teams fix them automatically before anything reaches production. It is the shift-left security layer of the platform.

**Argonaut** The post-deployment operations engine in Delivery Shield. Argonaut monitors deployed applications, diagnoses failures, and guides teams through remediation — directly inside Slack — using AI-powered recommendations and executable commands.

**Gateway** The central control plane of Delivery Shield. The Gateway hosts the dashboard, policy engine, DBOM, reporting layer, and alert management system. It can be OpsMx-managed as a SaaS deployment or self-hosted in your own infrastructure.

**Agent or Delegate** A Kubernetes-based execution engine deployed inside your cluster. The Agent receives scan instructions from the Gateway via gRPC and executes all scans locally — so credentials, source code, and raw scan data never leave your environment. Each connected cluster runs its own Agent.

**Context Engine** The intelligence backbone of the OpsMx AI platform. It continuously ingests, correlates, and serves contextual data from across the DevSecOps ecosystem — grounding every AI recommendation and automated action in accurate, real-time, lifecycle-wide context.

### Security Scanning

**SAST — Static Application Security Testing** A scanning technique that analyzes source code at rest — without running it — to identify security vulnerabilities such as insecure coding patterns, injection risks, hardcoded secrets, and unsafe API usage. In Delivery Shield, SAST is powered by Semgrep, SonarQube, and Opengrep.

**SCA — Software Composition Analysis** A scanning technique that examines open-source libraries and third-party dependencies for known CVEs, outdated packages, and license compliance risks. In Delivery Shield, SCA is powered by Trivy and Grype, with findings matched against the NVD, GitHub Security Advisories, and OSV databases.

**DAST — Dynamic Application Security Testing** A scanning technique that tests running applications from the outside — simulating how an attacker would interact with a deployed service. It finds runtime vulnerabilities invisible to static analysis, such as SQL injection, XSS, authentication flaws, and session management issues. In Delivery Shield, DAST is powered by OWASP ZAP.

**IaC Security — Infrastructure as Code Security** Scanning of infrastructure definition files — Terraform, Kubernetes manifests, Helm charts, Dockerfiles, and CloudFormation templates — for misconfigurations, insecure settings, and policy violations. In Delivery Shield, IaC Security is powered by Trivy and Kubescape.

**CSPM — Cloud Security Posture Management** Continuous monitoring and assessment of cloud infrastructure configurations across AWS, Azure, and GCP — detecting misconfigurations, overly permissive access policies, unencrypted resources, and compliance gaps. In Delivery Shield, CSPM is powered by ScoutSuite and Cloud Custodian.

**Secrets Detection** Scanning of source code, container images, and IaC files for accidentally committed sensitive data — API keys, tokens, passwords, and private certificates. Secrets Detection is integrated into SAST and container image scans within Delivery Shield.

**Container Image Scanning** Security analysis of container images — scanning every layer for OS package vulnerabilities, application dependency CVEs, embedded secrets, and misconfigurations. In Delivery Shield, container image scanning is powered by Trivy and Grype.

**AI Model Scanning** Security analysis of machine learning model artifacts — detecting malware, trojans, poisoned weights, deserialization attacks, and dependency risks embedded in serialized model files such as PyTorch, TensorFlow, ONNX, and Sklearn models. In Delivery Shield, AI model scanning is powered by ModelScan.

### Vulnerability & Risk

**CVE — Common Vulnerabilities and Exposures** The industry-standard identifier for known security vulnerabilities. Each CVE has a unique ID — for example, CVE-2021-44228 (Log4Shell) — and is catalogued in the National Vulnerability Database (NVD) with a severity score.

**CVSS — Common Vulnerability Scoring System** The standardized framework for rating the severity of security vulnerabilities, on a scale from 0 to 10. Scores are grouped into severity bands — Critical (9.0–10.0), High (7.0–8.9), Medium (4.0–6.9), Low (0.1–3.9), and Informational (0).

**CWE — Common Weakness Enumeration** A community-developed list of common software and hardware security weaknesses. Where CVE identifies a specific vulnerability instance, CWE identifies the underlying weakness category — for example, CWE-89 is SQL Injection and CWE-79 is Cross-Site Scripting.

**Exploitability** A measure of how practically accessible a vulnerability is to an attacker in your specific application context. A CVE with a Critical CVSS score but in a library that is never loaded in your production environment has low exploitability. Delivery Shield uses exploitability as a key factor in contextual risk scoring — so teams focus on what is actually dangerous, not just what scores highest on paper.

**Risk Score** An AI/ML-driven score calculated by Delivery Shield that combines CVE severity, exploitability, environment context, business impact, and fix availability into a single, prioritized risk number per finding. Risk Scores help teams focus remediation effort where it matters most.

**Application Security Score** An aggregate score representing the overall security posture of an application — calculated from all open findings across SAST, SCA, DAST, container, IaC, and cloud scans. The score updates automatically as new findings are detected or existing ones are remediated.

**False Positive** A finding that is reported by a scanner but does not represent a real security risk in the specific context of your application. Delivery Shield supports exception management to suppress confirmed false positives — preventing them from repeatedly appearing in reports without discarding the original finding record.

### Policies & Governance

**OPA — Open Policy Agent** The industry-standard policy-as-code engine used by Delivery Shield to define and enforce security and compliance rules. Policies are written in a language called Rego and evaluated automatically at every pipeline gate and deployment event.

**Rego** The policy language used to write OPA rules. Rego policies define what conditions must be true for a deployment to be allowed — for example, no Critical CVEs, no unprotected default branches, or no deployment during a blackout window.

**Rules Genie** An AI feature in Delivery Shield that converts plain-language policy descriptions into executable Rego rules automatically. Security and compliance teams describe what they want to enforce in plain English and Rules Genie generates the corresponding OPA policy — no Rego expertise required.

**Policy-as-Code** The practice of defining security and compliance rules as version-controlled code rather than manual documentation or spreadsheet checklists. Policy-as-code ensures rules are consistently enforced, auditable, and reviewable alongside application code.

**Deployment Firewall** The automated policy gate at the end of the delivery pipeline. The Deployment Firewall evaluates every release against all defined OPA policies and automatically passes, blocks, or escalates a deployment based on the results. It is the last line of defense before code reaches production.

**Blackout Window** A defined time period during which all deployments are automatically blocked — for example, quarter-end dates, maintenance windows, or compliance freeze periods. Blackout Windows are configured as policies in the OPA Policy Engine.

**Approval Gate** A checkpoint in the delivery pipeline that requires explicit human approval before a deployment can proceed. Approval Gates can be configured as mandatory for specific environments — for example, any deployment to production must be approved by a senior engineer.

**Exception** A time-bound, tracked override that allows a deployment to proceed despite a policy violation. Exceptions are logged with the approver identity, reason, and expiry date — and Delivery Shield sends automatic reminders when an exception is approaching its expiry.

**Separation of Duties** A governance control — often required for SOX compliance — that prevents the same person from both approving and executing a deployment. Configured as a policy in Delivery Shield.

### Bills of Materials

**SBOM — Software Bill of Materials** A structured, machine-readable inventory of every component, library, and dependency in an application — including version, origin, license, and known CVEs. Delivery Shield generates SBOMs automatically at the artifact level using Syft and exports them in CycloneDX, SPDX, or JSON format.

**DBOM — Delivery Bill of Materials** An OpsMx concept that goes beyond the SBOM. The DBOM is the end-to-end record of every security check, scan result, policy gate decision, approval, and deployment action from code commit to production. It is the foundation of audit readiness in Delivery Shield.

**MBOM — Model Bill of Materials** An inventory of every component within an AI or ML model — framework, weights, version, origin, license, and CVE status. Generated automatically by ModelScan for every scanned model artifact, in CycloneDX format.

**PBOM — Prompt Bill of Materials** An inventory of every prompt, template, and input configuration used with an AI model — with an associated risk assessment. Used to maintain traceability of AI interactions alongside model and delivery lineage.

**CycloneDX** An industry-standard SBOM format optimized for security use cases — including vulnerability exchange (VEX) and license compliance. Delivery Shield generates and accepts SBOMs in CycloneDX format.

**SPDX — Software Package Data Exchange** An industry-standard SBOM format originally developed by the Linux Foundation — widely used for license compliance and regulatory reporting. Delivery Shield supports SPDX as an export format for SBOMs.

### Infrastructure & Scanning

**ScanConfig CRD** A Kubernetes Custom Resource Definition that stores scan configuration persistently on the Agent cluster — defining what to scan, which scanners to use, and any scheduling or polling settings. ScanConfigs survive Agent restarts and can be managed via kubectl alongside the Delivery Shield dashboard.

**ScanJob CRD** A Kubernetes Custom Resource Definition representing each individual scan execution. A ScanJob is created every time a scan is triggered — tracking its current status, progress, and final outcome. ScanJobs can be inspected directly via kubectl.

**Polling** A scan trigger method where the Agent periodically checks a repository or registry for changes — new commits, tags, or image versions — and automatically triggers a scan when a change is detected. Polling is the recommended alternative to webhooks for environments where inbound network access to the Agent cluster is restricted.

**Webhook** A scan trigger method where the Git provider (GitHub, GitLab, etc.) sends an event to the Agent's Collector service immediately when a push, pull request, or tag event occurs. Webhooks provide the lowest scan latency but require inbound network access to the Agent cluster.

**mTLS — Mutual TLS** A security protocol where both the client and the server authenticate each other using certificates before any data is exchanged. Delivery Shield uses mTLS for all communication between the Gateway and the Agent — preventing unauthorized access or interception.

**gRPC** A high-performance, open-source remote procedure call framework used for communication between the Delivery Shield Gateway and the Agent. All scan configurations and results travel over this gRPC channel, encrypted with mTLS.

### AI & Model Security

**LLM — Large Language Model** An AI model trained on large amounts of text data that can generate, summarize, translate, and reason about text. Examples include GPT-4, Claude, and Llama. Delivery Shield includes specific security controls for LLMs — including adversarial testing via Garak and runtime monitoring.

**Prompt Injection** An attack where adversarial inputs are crafted to redirect or manipulate the behavior of an LLM — causing it to ignore safety guidelines, reveal sensitive data, or execute unintended actions. Garak tests deployed LLMs for prompt injection vulnerabilities.

**MCP — Model Context Protocol** A structured communication framework that enables AI models and agents to interact with external tools, APIs, and data sources. Delivery Shield includes MCP Security controls to govern and audit these interactions — enforcing least-privilege access and detecting context poisoning.

**Jailbreak** An attempt to bypass an LLM's safety constraints or alignment guardrails — making the model produce outputs it was designed to refuse. Garak simulates jailbreak attempts against deployed models as part of adversarial testing.

**Behavioral Drift** An unexpected change in how an AI model responds to inputs — which may indicate that the model has been tampered with, retrained with poisoned data, or is degrading over time. ModelScan and Garak both monitor for behavioral drift in deployed models.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.opsmx.com/getting-started/key-concepts-and-terminologies.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.