CGE-P Capstone Rubric
The CGE-P capstone validates that a candidate can build, document, and operate GRC engineering systems — not just describe them. Submissions are scored across eight dimensions blending mechanical static-analysis (Tier 0) with qualitative judgment (Tier 1). Pass = weighted average >= 80.
- Visibility: public
- Max size: 50 MB
- Max files: 10,000
Required artifacts
- README.md describing what the repo demonstrates and how to run it
- At least one of: Terraform/CloudFormation/Pulumi IaC, OPA/Sentinel policy-as-code, OSCAL/SCAP machine-readable docs
- At least one CI workflow (.github/workflows/, .gitlab-ci.yml, etc.) that runs compliance checks
- Explicit control-to-code mapping (NIST 800-53, NIST 800-171, CMMC, SOC 2, or comparable)
Compliance-relevant infrastructure is defined as code, modular, validated, and follows IaC best practices.
Tier 0 (deterministic)
- • terraform fmt -check (no diffs)
- • terraform validate per module (passes)
- • tflint (no errors)
- • checkov (no HIGH/CRITICAL severity findings on infra)
Tier 1 (AI scored)
- • Modules have a single concern and clear inputs/outputs
- • Variables have descriptions; outputs are scoped to what other modules need
- • No hardcoded account IDs, regions, or secrets
- • State management is explicit (remote backend or documented choice)
Scoring bands
- 90-100
- All Tier 0 pass; modules clearly scoped; descriptive variables; clean state management.
- 70-89
- Tier 0 mostly passes (1-2 minor issues); module structure reasonable but some boundary violations.
- 50-69
- Tier 0 has multiple failures or HIGH severity findings; modules conflate concerns.
- 0-49
- No IaC, or IaC fails to validate, or fundamental security misconfigurations.
Compliance requirements are expressed as executable policies — not just documented in prose.
Tier 0 (deterministic)
- • At least one .rego, .sentinel, conftest, or comparable policy file exists
- • conftest test (or equivalent) passes against included examples
- • Policy files have associated tests
Tier 1 (AI scored)
- • Policies map to specific named controls (e.g., 'enforces NIST AC-3')
- • Policies are deny-by-default where appropriate; allow-list narrow
- • Test cases cover both compliant and non-compliant inputs
- • Policies are scoped (per-resource, per-namespace) — not monolithic
Scoring bands
- 90-100
- Policies clearly map to controls; comprehensive tests; deny-by-default; production-ready.
- 70-89
- Policies present and tested; mapping to controls present but partial.
- 50-69
- Policies present but no tests, or no clear control mapping.
- 0-49
- No policy-as-code, or policies are ineffective placeholders.
Compliance checks run automatically on every change — not as a manual step.
Tier 0 (deterministic)
- • .github/workflows/, .gitlab-ci.yml, or equivalent CI config exists
- • CI invokes at least one compliance scanner (checkov, tfsec, semgrep, gitleaks, conftest, etc.)
- • CI is wired to fail the build on policy violations (not informational-only)
Tier 1 (AI scored)
- • Pipeline blocks merge on critical findings — not just reports them
- • Scanner output is preserved as build artifact for audit trail
- • Pipeline runs on PRs against main, not just on push to main
- • Distinct stages: lint -> validate -> security -> deploy (not one mega-step)
Scoring bands
- 90-100
- CI blocks non-compliant code; scans run on PRs; artifacts preserved; staged pipeline.
- 70-89
- CI runs scanners but is informational-only, or only on main.
- 50-69
- CI exists but doesn't run compliance scanners.
- 0-49
- No CI, or CI is purely cosmetic.
The system detects drift, misconfiguration, or violation of controls in real time — not via point-in-time audit.
Tier 0 (deterministic)
- • Detection or monitoring code present (Lambda functions, EventBridge rules, AWS Config rules, Falco rules, Sigma rules, or equivalent)
Tier 1 (AI scored)
- • Detections target specific controls or threat scenarios — not generic 'all events'
- • Detection logic includes thresholds, deduplication, or noise reduction
- • Alert routing is defined (where does an alert go? to whom?)
- • Test coverage exists for detection logic (unit tests, replay-against-fixtures)
Scoring bands
- 90-100
- Targeted detections mapped to controls; tested; alert routing defined.
- 70-89
- Detections present, partial test coverage, alert routing implied.
- 50-69
- Detection logic exists but is generic or untested.
- 0-49
- No monitoring or detection logic.
Compliance evidence is generated automatically from system state — not assembled manually for audits.
Tier 0 (deterministic)
- • OSCAL JSON/XML files validate against the OSCAL schema, OR
- • Evidence-collection scripts (Python/Go/Node) exist that query cloud APIs or system state
- • Output evidence has a defined schema (JSON Schema, OSCAL component-definition, or equivalent)
Tier 1 (AI scored)
- • Evidence collection is wired up (cron, EventBridge, GitHub Actions schedule) — not just runnable in theory
- • Collected evidence is stored with provenance (timestamp, source, control ID)
- • OSCAL or equivalent machine-readable format used for at least one artifact (SSP, SAP, SAR, POAM, component-def)
- • Evidence pipelines handle failure (retries, dead-letter, alerts on stale data)
Scoring bands
- 90-100
- Wired-up automated collection; OSCAL or equivalent; provenance preserved; failure handling.
- 70-89
- Collection scripts exist and are documented but not scheduled, or OSCAL is partial.
- 50-69
- Manual scripts only; no schema; no scheduling.
- 0-49
- No evidence automation.
Controls are tested for effectiveness — not just declared as implemented.
Tier 0 (deterministic)
- • Test files present (terraform test, pytest, jest, go test, kitchen-terraform, etc.)
- • Tests pass when the suite is invoked
- • Tests reference specific controls or compliance requirements in names or comments
Tier 1 (AI scored)
- • Tests verify both positive (control allows compliant action) and negative (control blocks non-compliant action) cases
- • Tests are integration-level where it matters — not just unit tests of stub code
- • Test inputs cover edge cases relevant to the control (privileged users, cross-account, unusual regions, etc.)
- • Test failures would meaningfully indicate a real compliance gap
Scoring bands
- 90-100
- Comprehensive positive/negative tests; integration-level; tied to controls.
- 70-89
- Tests present and pass; coverage is partial.
- 50-69
- Token tests; no negative cases; not tied to controls.
- 0-49
- No tests, or tests don't run.
An auditor can trace any compliance requirement to the specific code, policy, or detection that satisfies it — and vice versa.
Tier 0 (deterministic)
- • gitleaks finds no secrets in the repository
- • README.md or docs/ directory exists
- • At least one document explicitly maps controls to artifacts (table, matrix, or per-file headers)
Tier 1 (AI scored)
- • Mapping is bidirectional: from control -> artifact and from artifact -> control
- • Mapping uses standard control IDs (NIST 800-53 rev 5, NIST 800-171 rev 3, CMMC L2, SOC 2 TSC, etc.) — not custom invented IDs
- • Mapping is current with the code (no orphaned references to deleted files)
- • Documentation explains the 'why' for non-obvious choices, not just 'what'
Scoring bands
- 90-100
- Bidirectional mapping; standard control IDs; current; explains rationale.
- 70-89
- Mapping present but one-directional, or partial; standard IDs used.
- 50-69
- Some control references but no real mapping; or invented IDs.
- 0-49
- No control-to-code documentation.
The repository reflects professional software engineering practice — not a one-off prototype.
Tier 0 (deterministic)
- • LICENSE file present
- • gitleaks: no secrets in repo
- • semgrep --config=auto: no HIGH/CRITICAL findings
- • README explains setup, prerequisites, and how to run
Tier 1 (AI scored)
- • Code is organized and named consistently (no 'untitled.py', no 'temp/', no large dead-code blocks)
- • Dependencies are pinned (lockfile committed) and reasonable in scope (no kitchen-sink imports)
- • Commits tell a story (not 'wip', 'fix', 'asdf') — at least the most recent ones
- • No PII, customer names, real production data, or live credentials anywhere in the repo
Scoring bands
- 90-100
- Clean structure; pinned deps; meaningful commits; no security/PII issues.
- 70-89
- Mostly clean; minor lints; commits adequate.
- 50-69
- Disorganized but functional; some HIGH semgrep findings.
- 0-49
- Unprofessional or contains secrets/PII (auto-fail trigger).
If any of these apply, the submission fails regardless of weighted score:
- • Repository is private or inaccessible
- • Active secrets detected in the repository (verified non-test credentials)
- • Repository contains real PII or production credentials
- • Repository is a fork of a published reference solution with no meaningful modification
- • Repository has no README — we need at least a README to understand the submission
Every score returned to a candidate includes: per-dimension score, the Tier 0 check results that informed it, the Tier 1 reasoning, and at least one quoted file/line excerpt as evidence. Candidates who fail receive the same breakdown plus actionable guidance per dimension.