Delivery Shield Architecture

This page explains the SSD (Software Supply chain Defense) architecture platform as represented in the diagram below. 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.

The SSD architecture consists of the following blocks:

1. Outer Block

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

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.