You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The detection engine today is event-driven — rules fire when something happens. There's no notion of point-in-time configuration state and no answer to "how does this org score against CIS Google Workspace Benchmark v1.5?"
Buyers routinely ask:
"What's our current CIS benchmark score?"
"Show me drift from our chosen baseline over the last 30 days."
"Did anything that should be enabled get turned off?"
Event-driven detection misses these because:
The misconfiguration may have existed since before Aperio was installed (no event).
The fix may have been silently reverted (the reversion fires, but operators need the current state, not the event log).
Goals
Configuration snapshotter — per-connector, periodic capture of the entire posture-relevant config surface into a typed snapshot.
Baseline catalog — ship CIS Google Workspace, CIS M365, CIS GitHub, CIS Okta benchmarks as YAML; let customers author org-specific baselines.
Scoring engine — score each connector snapshot against each enabled baseline; persist time-series of scores.
Drift detection — diff today's snapshot against yesterday's; alert on regressions away from the baseline.
When a new snapshot lands, diff it against the previous snapshot. Any control that flipped PASS → FAIL opens a SecurityFinding with ruleKey = "baseline.regression.<baseline>.<controlId>". This routes through the existing finding pipeline + workflow #50.
UI surface
/baselines — list of enabled baselines, current pass rate, trend sparkline.
/baselines/<id> — per-control table: status, last evaluated, observed value, remediation. Filter by failing.
Per-control drift timeline — green/red bar per day for the last 90 days.
Dashboard tile — "CIS Google Workspace score: 82% (↓ 3% this week)".
Phasing
Phase
Scope
P1
Schema; snapshot capture for Google Workspace; CIS Google Workspace baseline YAML; scoring engine; /baselines index page
Reuses: IntegrationConnection, SecurityFinding, the finding pipeline.
Adjacent to Handle disallowed CORS origins explicitly #5 (compliance frameworks) — baselines are configuration benchmarks, frameworks are risk-control mappings; both feed evidence packs.
Problem
The detection engine today is event-driven — rules fire when something happens. There's no notion of point-in-time configuration state and no answer to "how does this org score against CIS Google Workspace Benchmark v1.5?"
Buyers routinely ask:
Event-driven detection misses these because:
Goals
Non-goals
Proposed design
Snapshot model
Per-connector snapshot capture (runs on a daily schedule, separate from event-driven sync):
Baseline format (YAML)
Built-in baselines live in
baselines/:Scoring engine
internal/baseline/Go package:ConfigurationSnapshot, evaluate each baseline control's check expression against the snapshot JSON.BaselineScorerow per (org × baseline × control × snapshot).Drift detection
When a new snapshot lands, diff it against the previous snapshot. Any control that flipped
PASS → FAILopens aSecurityFindingwithruleKey = "baseline.regression.<baseline>.<controlId>". This routes through the existing finding pipeline + workflow #50.UI surface
/baselines— list of enabled baselines, current pass rate, trend sparkline./baselines/<id>— per-control table: status, last evaluated, observed value, remediation. Filter by failing.Phasing
/baselinesindex pageOpen questions
References
IntegrationConnection,SecurityFinding, the finding pipeline.