manuelarango1229/devsecops-engine-

Purpose and entry point

This repository is a reusable GitHub Actions DevSecOps engine. Consumer repositories invoke its workflow with workflow_call; it scans source code and a running/containerized target, evaluates risk through three independent gates, and publishes security artifacts. The orchestration entry point is .github/workflows/reusable-devsecops.yml.

Pipeline orchestration and target boundary

The reusable workflow accepts source repository, image/URL, port, service criticality, environment, language, and optional GHCR credentials. It establishes the boundary between a consumer’s build/deployment context and this centrally managed analysis pipeline. Container images may be pulled and run for dynamic scans; an external target_url is an alternative target.

• .github/workflows/reusable-devsecops.yml

• scripts/recon.py

Discovery and scan planning

The detector identifies language and scan mode, then builds scan_config.json. It also determines applicable ISO/IEC 27034 application-security controls (ASCs), based on language and service criticality. This configuration drives later source-analysis selection and provides normative traceability.

• scripts/detector.py

• scripts/iso27034.py

• config/iso27034_framework.json

Security evidence collection

The workflow coordinates four evidence sources: Semgrep SAST against the source repository, Trivy SCA for dependency/image CVEs, OWASP ZAP DAST against the reachable application, and Nuclei pentesting validation. Reconnaissance prepares the live target for the dynamic stages. These scanners are external CLI/container tools controlled by the workflow rather than embedded application services.

• .github/workflows/reusable-devsecops.yml

• scripts/recon.py

Normalized findings model

Raw scanner outputs converge in a normalizer that deduplicates and maps findings into the canonical findings.json format. Each finding is associated with an asc_id, creating the handoff from heterogeneous tool outputs to policy and decision engines.

• scripts/normalizer.py

• schema/finding_schema.json

• scripts/iso27034.py

Risk-enrichment and decision engines

Three separate decision paths evaluate the normalized findings. The traditional gate applies configured severity thresholds. The SSVC gate uses SSVC v2.1 context plus EPSS and CISA KEV exploitability signals. The AI engine performs contextual evaluation, validates against SSVC context, and produces confidence and attack-chain-oriented output; it uses Groq-hosted LLaMA primarily, with documented fallback providers and static fallback.

• scripts/gate.py

• scripts/ssvc_gate.py

• scripts/ai_engine.py

• config/scan_policy.json

Final synthesis and outputs

The gate stage compares traditional, AI, and SSVC decisions, including divergence and SSVC quality metrics, to emit PASS, CONDITIONAL, or FAIL in gate_decision.json. Reporting then renders the executive Markdown report. GitHub Actions artifacts expose the scan configuration, normalized findings, AI evaluation, decision record, and report to consumers.

• scripts/gate.py

• scripts/report_generator.py

• .github/workflows/reusable-devsecops.yml

Runtimes and external dependencies

The control plane is GitHub Actions on Ubuntu runners, executing Python scripts listed through requirements.txt. It depends on GitHub/GHCR for source and optional private-image access, Groq API credentials for AI assessment, and external security intelligence represented by EPSS and CISA KEV. Scanner runtimes are Semgrep, Trivy, OWASP ZAP, and Nuclei.

• requirements.txt

• .github/workflows/reusable-devsecops.yml