The Gate Engine

The Gate Engine

The gate engine is the deterministic heart of security-mcp. It takes a change (or a whole codebase), runs a wide battery of analysis in parallel, reconciles the results against your policy, exceptions, and a baseline, and returns a single defensible verdict. Agents call it, CI calls it, and you can call it directly. Same engine, same rules, every time.

The pipeline

flowchart TD
  A[Load policy] --> B[Scope: recent_changes / full / targets]
  B --> C[Classify change]
  C --> D[Detect surfaces<br/>web, api, infra, iOS, Android, AI, agentic]
  D --> E[Build control catalog]
  E --> F[Scanner readiness check]
  F --> G[Collect evidence map]
  G --> H[35 checks in parallel]
  H --> I[Apply vulnerability SLAs]
  I --> J[Build coverage manifest]
  J --> K[Apply exceptions]
  K --> L[Confidence score]
  L --> M[Baseline regression diff]
  M --> N{Verdict: PASS / FAIL}
  N --> O[Persist baseline]

Loading

Step by step:

1. Load policy. Read the active policy file, verify its signature if integrity is enabled, and resolve the target environment (dev/staging/prod) and its severity-block thresholds.
2. Scope the change. Default mode is recent_changes (diff between base and head refs). Other modes scan the full codebase or a specific set of targets.
3. Classify the change. Determine languages, frameworks, and the nature of the diff.
4. Detect surfaces. Identify which attack surfaces are present so checks run surface-aware: web, API, infrastructure, iOS, Android, AI/LLM, and agentic tool-use.
5. Build the control catalog. Resolve which controls apply to the detected surfaces and policy.
6. Scanner readiness. Probe which external scanners are installed and available; missing scanners are recorded, not silently skipped.
7. Collect evidence. Gather the evidence map that ties findings and controls to concrete locations.
8. Run 35 checks in parallel. See the module list below.
9. Apply vulnerability SLAs. Age findings against the policy SLAs and escalate breaches.
10. Build the coverage manifest. Record what ran, what was skipped, and why, so coverage is auditable.
11. Apply exceptions. Suppress findings covered by valid, approved, unexpired exceptions.
12. Score confidence. confidence = 0.7 * automated-coverage + 0.3 * scanner-score.
13. Baseline regression diff. Compare against the persisted baseline; any new HIGH or CRITICAL relative to baseline is a regression.
14. Verdict. Combine policy thresholds, SLA breaches, regressions, and coverage gaps into PASS or FAIL.
15. Persist baseline. Write the accepted state forward for next time.

Confidence and coverage

A check module that crashes does not get to lower the score quietly. A crashed module produces a HIGH severity "coverage gap" finding, so a broken analyzer is loud, not invisible. A baseline regression is treated as HIGH. Confidence blends how much of the catalog the automated checks covered with how the orchestrated scanners scored, weighted 70/30.

Check modules

35 checks run in parallel: 33 distinct analysis modules plus 2 precomputed coverage feeds. Several are deep modules with large curated pattern sets.

Deep modules (with pattern counts)

Module	Patterns	What it finds
docker-deep	49	Dockerfile and container build misconfigurations and escapes
data-platform	47	Data store, warehouse, and pipeline exposure and access flaws
auth	43	Authentication and session weaknesses: tokens, lockout, OAuth, JWT
injection	42	SQL, NoSQL, command, SSTI, path traversal, and related injection classes
gitops	41	GitOps and deployment-config drift and secret exposure
supply-chain	32	Dependency confusion, typosquatting, and provenance gaps
business-logic	31	Multi-step flow abuse, mass assignment, and money arithmetic flaws
agentic-instructions	11	Tool-use and agent instruction-handling risks
ai-governance	3	AI bounded-output and governance controls

Two more high-coverage modules sit alongside these: k8s (70 patterns) for Kubernetes manifest and RBAC issues, and iac (56 patterns) for general infrastructure-as-code misconfiguration.

Standard modules

One line each:

• secrets: hardcoded credentials, keys, and tokens.
• dependencies: known-vulnerable packages and SCA.
• crypto: weak algorithms, bad modes, and timing-unsafe comparisons.
• web / Next.js: web framework misconfig, CSP, CSRF, and SSRF surfaces.
• api: API authz, rate limiting, and exposure issues.
• mobile-ios: iOS platform security and data protection.
• mobile-android: Android platform security and permissions.
• graphql: GraphQL introspection, depth, and authz abuse.
• database: database access and configuration risks.
• dlp: data-loss-prevention and PII handling.
• sbom: software bill of materials completeness.
• playbook (IR): incident-response readiness.
• runtime / DAST: live runtime checks against a staging target.
• ci-pipeline: CI/CD pipeline injection and trust issues.
• nuclei (DAST): templated dynamic scanning against a staging target.
• required-artifacts: presence of policy-mandated artifacts.
• scanners: orchestration and result merging of external scanners.

The two precomputed coverage feeds round out the 35 and supply the coverage manifest with what ran versus what applied.

External scanners orchestrated

The gate orchestrates best-in-class open scanners and merges their findings into the unified result:

Scanner	Role
gitleaks	Secret detection
semgrep	Static analysis (SAST)
trivy	Vulnerability and config scanning
osv-scanner	Dependency vulnerability lookup
checkov	IaC misconfiguration
conftest	Policy-as-code (OPA/Rego)
zaproxy	Dynamic application security testing

Scanner readiness is reported up front, so a missing scanner shows as reduced coverage rather than a false all-clear.

Live threat intelligence

The gate enriches findings with live intelligence, cached for 24 hours so repeated runs stay fast and offline-tolerant.

Source	Effect
CISA KEV	Known-exploited vulnerabilities flagged and SLA-escalated
EPSS	Exploit probability; a score above 0.5 escalates the finding
OpenSSF Scorecard	Dependency project health signal
npm registry	Package metadata for supply-chain checks

Offline behavior

SECURITY_OFFLINE disables all egress. The gate then runs entirely from local analysis and any cached intel, with no outbound calls. Private, scoped package names are never sent to public endpoints even when online. See Environment Variables and Security and Hardening.