CI/CD Security Verification - Orchestrator
Purpose
This is a meta-workflow skill that orchestrates comprehensive CI/CD security reviews by combining version comparison, control verification, risk analysis, and reporting. Use this when you need a complete, automated security assessment.
When to Use This Skill
Use ci-cd-verification when:
- •Running in automated CI/CD pipeline (headless, comprehensive review)
- •User requests "full security review" or "complete security assessment"
- •Pre-deployment security gate requiring thorough analysis
- •User says "run all security checks" or similar
Use individual skills instead when:
- •Just want to compare versions → Use
compare-versions - •Just want to verify controls → Use
countermeasure-verification - •User has specific, narrow request → Use appropriate specific skill
How It Works
This skill guides you through a multi-step workflow, calling other tools as needed:
Step 1: Architectural Drift Detection
Tool: compare_versions
Action: Compare baseline version against current/PR state
Output: Structured diff showing what changed
Step 2: Control Implementation Verification
Tool: countermeasure_verification
Action: Verify countermeasures are correctly implemented
Condition: Only if PR/changes are linked to issue tracker tasks
Output: Implementation verification results
Step 3: Risk Delta Analysis
Action: Analyze comparison results for security implications
Process: Interpret structured diff, assess risk changes, identify critical issues
Step 4: Generate Comprehensive Report
Action: Create human-readable security report
Output: Unified report covering all findings
Orchestration Workflow
# User: "Run full CI/CD security verification"
# The skill returns workflow guidance:
result = ci_cd_verification(baseline_version="v1.0-approved")
# You then execute the workflow:
# STEP 1: Architectural drift
version_diff = compare_versions(baseline_version="v1.0-approved")
diff = json.loads(version_diff)
# Analyze the diff
architecture_changes = diff['architecture']
security_changes = diff['security']
# STEP 2: Control verification (if applicable)
# Check if PR has issue tracker references
issue_refs = extract_issue_refs_from_git() # Your text parsing
if issue_refs:
cm_verification = countermeasure_verification(issue_references=issue_refs)
# Analyze and update test statuses
# STEP 3: Risk analysis
# Interpret the diffs, assess security impact
# STEP 4: Generate unified report
# Combine all findings into one comprehensive report
When Each Sub-Tool Is Needed
compare_versions - ALWAYS
Always call this - it's the foundation of the security review
- •Shows what changed architecturally
- •Shows new threats/countermeasures
- •Provides structured data for analysis
countermeasure_verification - CONDITIONAL
Call only if:
- •PR has issue tracker references (PROJ-1234 in branch/commits)
- •Countermeasures are linked to those issues
- •PR claims to implement specific controls
Skip if:
- •No issue tracker integration
- •PR is purely architectural (new features, not security fixes)
- •No countermeasures linked to PR's issues
Risk Analysis & Reporting - ALWAYS
Always do this - synthesize findings into actionable report
Comprehensive Report Structure
Your final report should combine findings from all steps:
# 🚨 CI/CD Security Verification Report ## Executive Summary - Overall risk level (CRITICAL/HIGH/MEDIUM/LOW) - Key findings count - Recommendation (APPROVE/REQUEST CHANGES/REJECT) ## Architectural Changes [From compare_versions output] - Components added/removed/modified - Dataflows added/removed/modified - Trust zone changes ## Security Impact [From compare_versions output] - New threats introduced - Severity increases - Countermeasures removed - Risk indicators ## Control Implementation Verification [From countermeasure_verification output - if applicable] - Controls verified - Implementation status (passed/failed) - Evidence and findings ## Risk Delta Analysis [Your interpretation] - How do changes affect overall security posture? - Relationship between architecture and security changes - Critical issues requiring attention ## Recommendations - What must be fixed before merge - What should be addressed before production - What documentation is needed
Comparison vs Orchestration
compare_versions (focused):
- •One specific task: compare two states
- •Returns data, minimal interpretation
- •User wants specific comparison
ci_cd_verification (comprehensive):
- •Multiple tasks orchestrated
- •Full security review workflow
- •User wants complete assessment
Example Usage Scenarios
Scenario A: Developer Wants Quick Comparison
User: "What changed since baseline?"
You: Call compare_versions(baseline_version="baseline")
Interpret results, show summary
Scenario B: CI/CD Pipeline Full Review
User: "Run CI/CD security checks"
You: Call ci_cd_verification(baseline_version="v1.0-approved")
Follow orchestration guidance
Call compare_versions
Call countermeasure_verification (if relevant)
Generate comprehensive report
Scenario C: Developer Implementing Control
User: "Did I implement PROJ-1234 correctly?"
You: Call countermeasure_verification(issue_references="PROJ-1234")
Analyze code vs countermeasure requirement
Update test status
Remember
- •This is an orchestrator - it coordinates other tools, doesn't do the work itself
- •Be flexible - Not every workflow needs all steps
- •Use judgment - Skip irrelevant steps (e.g., no control verification if no issue tracker)
- •Comprehensive output - Final report should cover all security aspects
- •Automated context - In CI/CD, you have full autonomy to run complete workflow
Use this skill for comprehensive, automated CI/CD security reviews that combine multiple analyses into one thorough security assessment.