SSD Architecture

CGGD

This page explains the architecture of the SSD (Software Supply chain Defense) 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.

---

1. Source Code & CI Integrations

• GitHub Actions / Bitbucket / Jenkins / ArgoCD

  • These tools serve as entry points into the SSD pipeline.

  • Source code commits, pull requests, and deployment workflows trigger SSD services.

  • On-prem CLI and webhook support are provided to integrate external pipelines into the SSD flow.

2. SSD Core Components

• SSD UI & SSD Gate

• User interface for managing pipelines, scans, and reports.

• The Gate enforces security and compliance checks before approving deployment.

• SSD Service (Supply Chain API)

• Core service that orchestrates scanning, validation, and policy enforcement.

• Interfaces with external tools (Snyk, ZAP, MobSF, etc.).

• SSD Preprocessor

• Normalizes incoming requests and metadata before analysis.

• Ensures all components are formatted for policy checks and DB storage.

• SSD OPA (Open Policy Agent)

• Centralized policy enforcement engine.

• Applies security, compliance, and governance rules across the toolchain.

3. Scanning & Security

• Source Scan / Artifact Scan

• Source code scans for vulnerabilities, secrets, and compliance issues.

• Artifact scans (containers/images) for CVEs and misconfigurations.

• OWASP ZAP / MobSF / Snyk

• ZAP: Dynamic application security testing.

• MobSF: Mobile application security analysis.

• Snyk: Dependency and open-source library vulnerability scanning.

• SSD Vuln DB & SSD OSS DB

• Internal vulnerability and open-source software databases.

• Provide a knowledge base for known issues, CVEs, and license risks.

• Kubescape Service

• Kubernetes-native security and compliance scanning.

4. Data & Observability

• Postgres / MinIO-S3

• Storage for scan results, logs, and artifacts.

• Supports scalability and audit logging.

• Dgraph

• Graph database to map relationships between components, artifacts, and vulnerabilities.

• OpenTelemetry (OTEL) Collector

• Collects telemetry data for performance and monitoring.

• Exposes metrics via /metrics.

• Performance Monitoring & CI Monitoring

• Ensures pipeline stability, execution time, and compliance adherence.

5. Orchestration & Workflow

• RabbitMQ

• Message broker for communication between SSD services.

• Toolchain Temporal

• Workflow orchestration to manage long-running scans and approvals.

• Spinnaker

• Multi-cloud deployment orchestration with integrated SSD security checks.

• Kube Detector

• Monitors Kubernetes clusters for compliance drift and vulnerabilities.

• Deployment Firewall

• Ensures only policy-compliant workloads can be deployed.

6. Security & Access Control

• Token Machine

• Issues secure tokens for pipeline and service authentication.

• OPA (Deployment level)

• Enforces runtime and deployment-time policies.

7. Project Monitoring

• Provides centralized visibility into:

• Scan results (source, artifacts, dependencies).

• Policy enforcement status.

• Deployment security posture.

8. End-to-End Flow (High-Level)

1. Developer pushes code → CI tool triggers SSD webhook.

2. SSD Preprocessor collects metadata.

3. SSD Service orchestrates scans (source, artifact, OSS, vuln DB lookups).

4. Results stored in Postgres / MinIO and relationships tracked in Dgraph.

5. SSD OPA evaluates policies.

6. If compliant → pass through SSD Gate → deployment orchestrated via Spinnaker / ArgoCD.

7. If not compliant → fail with detailed reporting in SSD UI.

8. Continuous monitoring (Kubescape, OTEL, Kube Detector) ensures post-deployment security.