# Security Risk and Prioritization

As applications, AI agents, and services move through the software lifecycle, risks need to be continuously evaluated and prioritized. Risk is multi-dimensional—severity, exploitability, reachability, runtime exposure, deployment context, ownership, business impact, and compliance all play a role. OpsMx aggregates signals, enriches them with context, and helps teams understand which risks matter most, why they matter, and what to address first. 

The system is designed to secure, monitor, and enforce policies across the software delivery lifecycle using multiple integrated tools and services.

This architecture ensures:

* End-to-end supply chain security
* Integration with CI/CD pipelines
* Vulnerability detection and prevention
* Policy-driven deployment control
* Centralized monitoring and reporting

It creates a **secure, automated, and scalable environment** for modern DevSecOps practices.

<figure><img src="/files/wZFTikwm8xn155c9MqAf" alt=""><figcaption></figcaption></figure>

The SSD architecture consists of the following blocks:

### **1.  Outer Block** &#x20;

These are external systems that interact with SSD through webhooks or CLI integrations:

* **Spinnaker, Jenkins, ArgoCD, GitHub Actions, BitBucket** – The CI/CD tools that are used for building  and deploying pipelines.
* **Performance Monitoring** – Collects performance data for observability.
* **On-prem CLI/Webhook** – It triggers for Jenkins and GitHub actions to initiate the processes.

### **2. SSD Core Block**&#x20;

This is the main processing area where SSD performs scanning, analysis, and orchestration:

* **SSD UI** – User interface for interaction.
* **SSD Gate** – Entry point for incoming requests and tasks.
* **Token Machine** – Manages authentication and secure access.
* **Rabbit MQ** – Message broker for communication between SSD components.

**Scanning & Monitoring**

* **Source Scan** – Analyzes source code for vulnerabilities.
* **Artifact Scan** – Scans build artifacts for security compliance.
* **Project Monitor** – Tracks project activities and scan results.
* **Snyk CI Monitoring** – External vulnerability monitoring integration.

**Core Processing**

* **SSD Preprocessor** – Prepares incoming data for scanning.
* **SSD Service (Supply Chain API)** – Core API layer connecting the SSD modules.
* **Dgraph** – Graph database for managing dependencies and relationships.
* **SSD OPA** – Policy enforcement using Open Policy Agent.

**Storage & Data Flow**

* **MinIO / S3** – Object storage for artifacts and scan results.
* **Postgres** – Relational database for structured data storage.

#### **Security & Compliance Tools**

* **OWASP ZAP** – Security scanning for vulnerabilities.
* **Open Telemetry (OTEL) Collector** – Metrics and telemetry data collection.

### **Kubernetes Cluster Integration Block (Right Section)**

SSD integrates with Kubernetes to monitor and enforce the policies:

* **Kube Detector** – Detects cluster-level vulnerabilities.
* **Kubescape Service** – Kubernetes security scanning.
* **Deployment Firewall & OPA** – Enforces deployment policies and rules.

### **Databases Block (Bottom-Right)**

The following databases are dedicated for storing vulnerability and open-source component data:

* **SSD Vuln DB** – Vulnerability database.
* **SSD OSS DB** – Open-source software component database.

The summary of the architecture is as follows:

* Deployment and runtime security are managed in **Kubernetes** with **Kubescape** and **Deployment Firewall**.
* **Policies** are enforced through **SSD OPA** before deployment.
* Results are processed by **SSD Service** and stored in **Dgraph**, **Postgres**, or **S3**.
* **Scanning modules** (source, artifact) and **monitoring tools** analyze inputs.
* Data enters through **SSD Gate**, passes security and policy checks.
* CI/CD tools trigger SSD processes via webhooks or CLI.

\
\
\
\
\
\ <br>


---

# Agent Instructions: 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/ssd/security-risk-and-prioritization.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.