Module: S08 — SDLC Gate Harnesses · Duration: ~75 minutes
Format: Verbatim transcript. Cues [SLIDE N] map to 03-slide-deck.html.
[SLIDE 1 — Title]
This is Module S Zero Eight: SDLC Gate Harnesses. Seventy-five minutes. The final module of Pillar Two — Application Security and the SDLC. Four sub-sections: the control plane shift, multi-scanner orchestration, trend analysis and risk scoring, and vulnerability triage at scale. By the end you can build a harness that enforces security at creation time, orchestrates four scanner types in parallel, scores risk per PR, and turns hundreds of CVEs into three things to fix this week.
[SLIDE 2 — S08.1: The Control Plane Shift]
Sub-section one. The control plane shift. Traditional SDLC security runs scans after the commit and reviews findings days or weeks later. A developer pushes on Tuesday. The SAST report lands in a dashboard on Thursday. The secret leaked in the commit is in git history by Friday. The review-time model assumes a slow, human-paced pipeline. That assumption is now false.
[SLIDE 3 — The AI coding agent problem]
Here is why. AI coding agents — Copilot, Cursor, autonomous agents — create code, dependencies, workflows, and infrastructure faster than review-time checks can process. An agent can introduce a new dependency with a transitive vulnerability, scaffold a new IAM role with an over-broad policy, and add a new API endpoint without authorization, all in a single session. A review-time gate that runs overnight and surfaces findings in a dashboard the next morning is structurally too slow. By the time the finding is reviewed, the code is in production.
The speed asymmetry is the core problem. Creation happens in seconds. Review happens in hours or days. The defense must move to the creation side.
[SLIDE 4 — Creation-time guardrails]
The control plane shift. Enforce security at creation time, not review time. A creation-time guardrail runs synchronously in the developer's path — pre-commit, pre-merge, in the IDE — and blocks the insecure artifact before it lands. The developer learns immediately that the dependency has a critical CVE, that the IAM policy is public, that the secret is in the diff. The feedback loop is seconds, not days.
This is not shift-left as a slogan. It is a structural change to where the gate lives. Review-time: post-commit, nightly, dashboard, ticket days later. Creation-time: pre-commit, pre-merge, inline, seconds. The action changes from "report to a dashboard" to "block the action, inline."
[SLIDE 5 — Hard gate vs soft gate]
Not every finding should block. A hard gate blocks the pipeline — the PR cannot merge, the commit is rejected. A soft gate warns — the developer sees the finding but can proceed. The decision matrix per scan type is the policy.
Validated secrets — hard block. An active breach path. SAST critical with high confidence — hard block. A confirmed critical weakness ships an exploit path. SCA matching CISA KEV or EPSS above 0.7 — hard block. Known-exploited or high-probability-of-exploitation. IaC public exposure — public S3 bucket, zero-zero-zero-zero slash zero — hard block. Immediate risk.
SAST medium or low — soft warn. Surface for review, don't block. SCA with low EPSS and a fix available — soft warn. Triage and schedule. License unknown or copyleft — soft warn. Legal review, not a security block.
The principle: block what is immediately dangerous. Warn what needs attention but is not immediately dangerous. Over-blocking trains developers to override without reading. Under-blocking ships vulnerabilities. The matrix is the calibration.
[SLIDE 6 — S08.2: Multi-Scanner Orchestration]
Sub-section two. Multi-scanner orchestration. Running each scanner type in isolation produces siloed findings. Semgrep in its dashboard, Snyk in its dashboard, Gitleaks in its dashboard. Each with its own severity scale. Each reviewed or ignored separately. The orchestrator unifies them.
[SLIDE 7 — Parallel scanners]
The four scanner types are independent — they analyze different artifacts. They run in parallel. SAST, Semgrep and CodeQL, about ninety seconds. SCA, Snyk and OWASP Dependency-Check, about thirty seconds. Secrets, Gitleaks and TruffleHog, about ten seconds. IaC, Checkov and OPA, about fifteen seconds. Parallel execution bounds wall-clock time to the slowest scanner, not the sum. Sequential would be one hundred forty-five seconds. Parallel is ninety. On a large PR, that difference is the difference between a usable guardrail and one developers disable.
[SLIDE 8 — Aggregation + dedup]
Each scanner emits findings in its own format with its own severity vocabulary. Semgrep uses error-warning-info. Snyk uses critical-high-medium-low. Checkov uses failed-passed. The orchestrator normalizes to a unified schema with a documented severity mapping. The mapping is policy, not improvisation.
Then dedup. Findings overlap across scanners. A Semgrep rule and a CodeQL query may flag the same SQL injection. A Snyk finding and an OWASP Dependency-Check finding may report the same CVE in the same dependency. The orchestrator deduplicates via the dedup-key. Within scan type and across scan types. Duplicate findings erode trust — the developer assumes the bot is broken when it reports the same thing three times.
[SLIDE 9 — Cross-scanner triage]
Some findings relate across scan types in ways simple dedup cannot catch. An SCA finding — a vulnerable library — is only exploitable if the vulnerable code path is reachable in the application, which a SAST scanner can determine. An IaC finding — a public S3 bucket — is only a real exposure if the bucket contains sensitive data.
The LLM triage layer correlates across scanners. The correlation can upgrade severity — an SCA finding upgraded because the vulnerable path is reachable — or downgrade — an IaC finding downgraded because the exposed resource contains no sensitive data. Cross-scanner correlation is where the orchestrator produces insight no single scanner could. And it is token-budgeted: high-severity findings first, because those are the ones that block.
[SLIDE 10 — S08.3: Trend Analysis + Risk Scoring]
Sub-section three. Trend analysis and risk scoring. A single build's findings are a snapshot. The harness's power over time is trend. Is the codebase getting safer or riskier. Trend turns point-in-time findings into a directional signal.
[SLIDE 11 — Risk score per PR]
The trend history produces a single risk score per PR that can gate approval. The score combines the current PR's new findings — severity-weighted, critical twenty-five, high ten, medium three, low one — with net direction, new introduced minus existing fixed, and a trend modifier. A rising trend over ten builds multiplies the score by one point two.
The score gates approval. Below thirty, pass. Thirty to sixty, requires a security reviewer's explicit approval. Above sixty, blocked until findings are resolved. The thresholds are policy. The score is computed, consistent, and auditable — not a gut call. Net direction matters: a PR that introduces five criticals but fixes seven is net-positive. A PR that introduces five and fixes zero is net-negative.
[SLIDE 12 — Per-author attribution]
Finding counts attributed per author identify where security debt concentrates. This is for coaching, not punishment — the framing matters. An author who introduces many SAST findings may need a thirty-minute session on the common patterns. A team that introduces many IaC findings may need the gate matrix explained.
The framing guardrail. Attribution data is visible to the author and their lead, not broadcast. It feeds into coaching conversations, not performance reviews. The harness policy should make this explicit. Misuse of attribution as a punishment tool destroys the psychological safety that makes the gate effective. Attribution without coaching is surveillance. Coaching without data is guesswork. The harness provides the data.
[SLIDE 13 — S08.4: Vulnerability Triage at Scale]
Sub-section four. Vulnerability triage at scale. A large application has hundreds of dependencies, each with a CVE history. The NVD publishes thousands of CVEs per year. Dependency scanners match dependencies to CVEs and produce a list — often hundreds of findings for a mature application. Raw and untriaged, the list is overwhelming. The harness triages it to a prioritized remediation queue.
[SLIDE 14 — EPSS inverts CVSS-only prioritization]
The key insight. EPSS — the Exploit Prediction Scoring System — is a probability score from zero to one representing the likelihood that a CVE will be exploited in the wild in the next thirty days. It is produced by FIRST from real-world exploit data.
EPSS inverts a common failure mode. Prioritizing by CVSS severity alone. A CVSS nine point eight — critical — with EPSS zero point zero one is almost certainly never exploited. A CVSS seven point five — high — with EPSS zero point eight is likely being exploited right now. CVSS measures impact if exploited. EPSS measures probability of exploitation. Together they prioritize correctly. And CISA KEV — the Known Exploited Vulnerabilities catalog — is the highest-confidence signal: confirmed active exploitation. A KEV match jumps to the top of the queue. Fix in hours.
[SLIDE 15 — The prioritized queue]
The output is a single prioritized queue. CISA KEV matches — remediate immediately, hours. EPSS above 0.7 and reachable in our environment — remediate urgently, days. EPSS above 0.7 but not confirmed reachable — verify reachability, then remediate. High CVSS, low EPSS — schedule in the normal backlog. Low CVSS, low EPSS — accept risk or batch-fix opportunistically.
This queue turns hundreds of raw CVEs into three things to fix this week. That is the harness's value. Not finding more vulnerabilities, but making the existing flood actionable.
[SLIDE 16 — What you take into S09]
S Zero Nine shifts to cloud security harnesses. The SDLC gate harness is operational — creation-time guardrails, multi-scanner orchestration, trend and risk scoring, vulnerability triage at scale. Continuous posture management, drift detection, and remediation across CSPM, CWPP, and CIEM in live cloud environments. From gating the pipeline to governing the cloud.
[End of script]
# Teaching Script — Module S08: SDLC Gate Harnesses **Module**: S08 — SDLC Gate Harnesses · **Duration**: ~75 minutes **Format**: Verbatim transcript. Cues `[SLIDE N]` map to `03-slide-deck.html`. --- [SLIDE 1 — Title] This is Module S Zero Eight: SDLC Gate Harnesses. Seventy-five minutes. The final module of Pillar Two — Application Security and the SDLC. Four sub-sections: the control plane shift, multi-scanner orchestration, trend analysis and risk scoring, and vulnerability triage at scale. By the end you can build a harness that enforces security at creation time, orchestrates four scanner types in parallel, scores risk per PR, and turns hundreds of CVEs into three things to fix this week. [SLIDE 2 — S08.1: The Control Plane Shift] Sub-section one. The control plane shift. Traditional SDLC security runs scans after the commit and reviews findings days or weeks later. A developer pushes on Tuesday. The SAST report lands in a dashboard on Thursday. The secret leaked in the commit is in git history by Friday. The review-time model assumes a slow, human-paced pipeline. That assumption is now false. [SLIDE 3 — The AI coding agent problem] Here is why. AI coding agents — Copilot, Cursor, autonomous agents — create code, dependencies, workflows, and infrastructure faster than review-time checks can process. An agent can introduce a new dependency with a transitive vulnerability, scaffold a new IAM role with an over-broad policy, and add a new API endpoint without authorization, all in a single session. A review-time gate that runs overnight and surfaces findings in a dashboard the next morning is structurally too slow. By the time the finding is reviewed, the code is in production. The speed asymmetry is the core problem. Creation happens in seconds. Review happens in hours or days. The defense must move to the creation side. [SLIDE 4 — Creation-time guardrails] The control plane shift. Enforce security at creation time, not review time. A creation-time guardrail runs synchronously in the developer's path — pre-commit, pre-merge, in the IDE — and blocks the insecure artifact before it lands. The developer learns immediately that the dependency has a critical CVE, that the IAM policy is public, that the secret is in the diff. The feedback loop is seconds, not days. This is not shift-left as a slogan. It is a structural change to where the gate lives. Review-time: post-commit, nightly, dashboard, ticket days later. Creation-time: pre-commit, pre-merge, inline, seconds. The action changes from "report to a dashboard" to "block the action, inline." [SLIDE 5 — Hard gate vs soft gate] Not every finding should block. A hard gate blocks the pipeline — the PR cannot merge, the commit is rejected. A soft gate warns — the developer sees the finding but can proceed. The decision matrix per scan type is the policy. Validated secrets — hard block. An active breach path. SAST critical with high confidence — hard block. A confirmed critical weakness ships an exploit path. SCA matching CISA KEV or EPSS above 0.7 — hard block. Known-exploited or high-probability-of-exploitation. IaC public exposure — public S3 bucket, zero-zero-zero-zero slash zero — hard block. Immediate risk. SAST medium or low — soft warn. Surface for review, don't block. SCA with low EPSS and a fix available — soft warn. Triage and schedule. License unknown or copyleft — soft warn. Legal review, not a security block. The principle: block what is immediately dangerous. Warn what needs attention but is not immediately dangerous. Over-blocking trains developers to override without reading. Under-blocking ships vulnerabilities. The matrix is the calibration. [SLIDE 6 — S08.2: Multi-Scanner Orchestration] Sub-section two. Multi-scanner orchestration. Running each scanner type in isolation produces siloed findings. Semgrep in its dashboard, Snyk in its dashboard, Gitleaks in its dashboard. Each with its own severity scale. Each reviewed or ignored separately. The orchestrator unifies them. [SLIDE 7 — Parallel scanners] The four scanner types are independent — they analyze different artifacts. They run in parallel. SAST, Semgrep and CodeQL, about ninety seconds. SCA, Snyk and OWASP Dependency-Check, about thirty seconds. Secrets, Gitleaks and TruffleHog, about ten seconds. IaC, Checkov and OPA, about fifteen seconds. Parallel execution bounds wall-clock time to the slowest scanner, not the sum. Sequential would be one hundred forty-five seconds. Parallel is ninety. On a large PR, that difference is the difference between a usable guardrail and one developers disable. [SLIDE 8 — Aggregation + dedup] Each scanner emits findings in its own format with its own severity vocabulary. Semgrep uses error-warning-info. Snyk uses critical-high-medium-low. Checkov uses failed-passed. The orchestrator normalizes to a unified schema with a documented severity mapping. The mapping is policy, not improvisation. Then dedup. Findings overlap across scanners. A Semgrep rule and a CodeQL query may flag the same SQL injection. A Snyk finding and an OWASP Dependency-Check finding may report the same CVE in the same dependency. The orchestrator deduplicates via the dedup-key. Within scan type and across scan types. Duplicate findings erode trust — the developer assumes the bot is broken when it reports the same thing three times. [SLIDE 9 — Cross-scanner triage] Some findings relate across scan types in ways simple dedup cannot catch. An SCA finding — a vulnerable library — is only exploitable if the vulnerable code path is reachable in the application, which a SAST scanner can determine. An IaC finding — a public S3 bucket — is only a real exposure if the bucket contains sensitive data. The LLM triage layer correlates across scanners. The correlation can upgrade severity — an SCA finding upgraded because the vulnerable path is reachable — or downgrade — an IaC finding downgraded because the exposed resource contains no sensitive data. Cross-scanner correlation is where the orchestrator produces insight no single scanner could. And it is token-budgeted: high-severity findings first, because those are the ones that block. [SLIDE 10 — S08.3: Trend Analysis + Risk Scoring] Sub-section three. Trend analysis and risk scoring. A single build's findings are a snapshot. The harness's power over time is trend. Is the codebase getting safer or riskier. Trend turns point-in-time findings into a directional signal. [SLIDE 11 — Risk score per PR] The trend history produces a single risk score per PR that can gate approval. The score combines the current PR's new findings — severity-weighted, critical twenty-five, high ten, medium three, low one — with net direction, new introduced minus existing fixed, and a trend modifier. A rising trend over ten builds multiplies the score by one point two. The score gates approval. Below thirty, pass. Thirty to sixty, requires a security reviewer's explicit approval. Above sixty, blocked until findings are resolved. The thresholds are policy. The score is computed, consistent, and auditable — not a gut call. Net direction matters: a PR that introduces five criticals but fixes seven is net-positive. A PR that introduces five and fixes zero is net-negative. [SLIDE 12 — Per-author attribution] Finding counts attributed per author identify where security debt concentrates. This is for coaching, not punishment — the framing matters. An author who introduces many SAST findings may need a thirty-minute session on the common patterns. A team that introduces many IaC findings may need the gate matrix explained. The framing guardrail. Attribution data is visible to the author and their lead, not broadcast. It feeds into coaching conversations, not performance reviews. The harness policy should make this explicit. Misuse of attribution as a punishment tool destroys the psychological safety that makes the gate effective. Attribution without coaching is surveillance. Coaching without data is guesswork. The harness provides the data. [SLIDE 13 — S08.4: Vulnerability Triage at Scale] Sub-section four. Vulnerability triage at scale. A large application has hundreds of dependencies, each with a CVE history. The NVD publishes thousands of CVEs per year. Dependency scanners match dependencies to CVEs and produce a list — often hundreds of findings for a mature application. Raw and untriaged, the list is overwhelming. The harness triages it to a prioritized remediation queue. [SLIDE 14 — EPSS inverts CVSS-only prioritization] The key insight. EPSS — the Exploit Prediction Scoring System — is a probability score from zero to one representing the likelihood that a CVE will be exploited in the wild in the next thirty days. It is produced by FIRST from real-world exploit data. EPSS inverts a common failure mode. Prioritizing by CVSS severity alone. A CVSS nine point eight — critical — with EPSS zero point zero one is almost certainly never exploited. A CVSS seven point five — high — with EPSS zero point eight is likely being exploited right now. CVSS measures impact if exploited. EPSS measures probability of exploitation. Together they prioritize correctly. And CISA KEV — the Known Exploited Vulnerabilities catalog — is the highest-confidence signal: confirmed active exploitation. A KEV match jumps to the top of the queue. Fix in hours. [SLIDE 15 — The prioritized queue] The output is a single prioritized queue. CISA KEV matches — remediate immediately, hours. EPSS above 0.7 and reachable in our environment — remediate urgently, days. EPSS above 0.7 but not confirmed reachable — verify reachability, then remediate. High CVSS, low EPSS — schedule in the normal backlog. Low CVSS, low EPSS — accept risk or batch-fix opportunistically. This queue turns hundreds of raw CVEs into three things to fix this week. That is the harness's value. Not finding more vulnerabilities, but making the existing flood actionable. [SLIDE 16 — What you take into S09] S Zero Nine shifts to cloud security harnesses. The SDLC gate harness is operational — creation-time guardrails, multi-scanner orchestration, trend and risk scoring, vulnerability triage at scale. Continuous posture management, drift detection, and remediation across CSPM, CWPP, and CIEM in live cloud environments. From gating the pipeline to governing the cloud. --- [End of script]