SSDLC & Workflow Orchestration

Relevant source files

The following files were used as context for generating this wiki page:

• core/ssdlc.py
• core/stage_runner.py
• CLI_API_INVENTORY.md
• samples/api-examples/demo-scenarios/automation/yaml-playbooks.json
• frontend/src/pages/EnhancedDashboard.jsx
• demo_ssdlc_stages/04_build_ci.yaml

Introduction

The SSDLC (Secure Software Development Lifecycle) and Workflow Orchestration system within Fixops provides a structured framework for managing security checkpoints across the software delivery pipeline. It facilitates the ingestion, normalization, and analysis of security artifacts—such as SBOMs, SARIF scans, and design manifests—at specific stages of development. By leveraging an orchestration layer, the system enables automated responses to security findings through customizable playbooks and decision-gating mechanisms.

The primary scope of this module is to ensure that every stage of development, from requirements gathering to operation, is governed by consistent security policies and verifiable evidence. This orchestration allows for complex sequences like triggering emergency WAF rules upon detecting critical vulnerabilities or blocking deployments based on consensus-driven AI analysis.

Sources: core/stage_runner.py:11-20, samples/api-examples/demo-scenarios/automation/yaml-playbooks.json:44-55, frontend/src/pages/EnhancedDashboard.jsx:236-248

SSDLC Stages and Execution

The SSDLC process is divided into logical stages, each responsible for processing specific input types and generating canonical output reports. The StageRunner class coordinates the I/O handling for these stages, ensuring that artifacts are stored in a run registry and optionally signed for transparency.

Lifecycle Stages

The following table describes the core stages of the SSDLC as defined in the system's execution logic:

Stage	Input Artifact	Output Artifact	Purpose
Requirements	requirements-input.csv	requirements.json	Maps business features to security control references and SSVC anchors.
Design	design-input.json	design.manifest.json	Assesses architecture risk based on component exposure and data classification.
Build	sbom.json	build.report.json	Indexes software components and identifies historical RCE risks (e.g., Log4j).
Test	scanner.sarif	test.report.json	Normalizes scanner findings and calculates code/branch coverage.
Deploy	tfplan.json / Manifests	deploy.manifest.json	Analyzes infrastructure posture for gaps like public S3 buckets or unpinned images.
Operate	ops-telemetry.json	operate.snapshot.json	Monitors runtime telemetry and checks against KEV/EPSS threat feeds.
Decision	decision-input.json	decision.json	Aggregates all stage reports to reach a final ALLOW/BLOCK/DEFER verdict.

Sources: core/stage_runner.py:70-98, core/stage_runner.py:166-310, CLI_API_INVENTORY.md:214-232

Stage Processing Flow

The execution flow begins with the ingestion of raw artifacts, followed by normalization through the InputNormalizer. The StageRunner then calculates stage-specific risk scores.

Workflow Orchestration & Playbooks

Workflow orchestration is driven by a playbook library that defines automated responses to specific security triggers. These playbooks are defined in YAML and executed based on conditions such as vulnerability severity or CVSS scores.

Playbook Structure

Playbooks consist of a series of steps that interact with external integrations (Jira, Slack, GitHub).

• Triggers: Events such as vulnerability_detected, scheduled (cron), or remediation_completed.
• Actions: Pre-approved operations including create_jira_ticket, update_waf_rules, quarantine_container, and update_deployment_gate.
• Logic: Steps can include conditional execution and output variable passing (e.g., using a created Jira ticket URL in a Slack alert).

Sources: samples/api-examples/demo-scenarios/automation/yaml-playbooks.json:15-42, samples/api-examples/demo-scenarios/automation/yaml-playbooks.json:57-110

Automated Response Sequence

The following sequence diagram shows the interaction during a "Critical Vulnerability Response" workflow:

Evidence and Transparency

A core component of the orchestration is the creation of a verifiable Evidence Bundle. This is a signed ZIP archive containing all canonical stage outputs and a manifest.json with SHA-256 checksums of every document.

Security Controls and Verification

The system evaluates findings against established control frameworks like ISO 27001 and CIS.

Control ID	Description	Logic Source
ISO27001:AC-2	Public S3 Buckets	Deploy Posture Analysis
ISO27001:SC-28	Encryption Gaps	Resource Property Check
CIS-K8S:5.4.1	Unpinned Images	Container Spec Validation
SLSA v1.0	Build Provenance	Build CI Attestations

Sources: core/stage_runner.py:535-565, demo_ssdlc_stages/04_build_ci.yaml:104-122, CLI_API_INVENTORY.md:225-235

Integration with CI/CD

The SSDLC orchestration is designed for "Plug-and-Play" integration into existing CI pipelines. The CLI provides a make-decision command that uses the pipeline result as an exit code (0 for ALLOW, 1 for BLOCK), enabling automated gating.

CLI Deployment Commands

# Ingest SARIF and evaluate policies
fixops-cli ingest --format sarif --scan-file results.sarif.json \
  --service-name payment-service --environment production

# Execute pipeline and gate deployment
fixops make-decision --service-name payment-service --scan-file results.sarif

Sources: CLI_API_INVENTORY.md:20-45, frontend/src/pages/EnhancedDashboard.jsx:218-228

Conclusion

The SSDLC & Workflow Orchestration system provides a robust mechanism for enforcing security standards across the development lifecycle. By centralizing the processing of security artifacts into defined stages and providing a playbook-driven automation engine, it reduces the manual effort required for security reviews and provides a transparent, auditable trail of all deployment decisions.