Security posture assessment

ident response costs, and auditable compliance evidence that updates automatically rather than requiring manual compilation.

Core Solution

Building a continuous security posture assessment system requires three architectural pillars: event-driven data ingestion, a deterministic policy engine, and a state-backed scoring model. The following implementation demonstrates a TypeScript-based posture engine that aggregates findings, applies risk weights, and calculates a composite posture score.

Step-by-Step Implementation

1. Define the Risk Taxonomy: Map findings to severity, exploitability, and business impact. Establish a weighted scoring model (0–100) where higher scores indicate better posture.
2. Instrument Data Collectors: Deploy agents or API connectors for IaC, cloud APIs, dependency manifests, and runtime telemetry. Normalize findings into a unified schema.
3. Deploy Policy Engine: Use OPA/Rego or TypeScript-based policy functions to evaluate findings against baselines. Support drift detection and context-aware overrides.
4. Build State Store: Persist posture snapshots with versioning. Enable diff comparison between commits, deployments, and time windows.
5. Calculate & Expose Score: Aggregate weighted findings, apply business context modifiers, and expose via API, dashboard, or CI/CD status check.

TypeScript Posture Engine

import { createClient, RedisClientType } from 'redis';
import { evaluatePolicy } from './policy-engine';

interface Finding {
  id: string;
  source: 'sast' | 'cspm' | 'dependency' | 'runtime';
  severity: 'critical' | 'high' | 'medium' | 'low';
  exploitability: boolean;
  businessContext: 'customer-facing' | 'internal' | 'dev-only';
  timestamp: number;
}

interface PostureState {
  score: number;
  findings: Finding[];
  lastUpdated: number;
  driftDetected: boolean;
}

const SEVERITY_WEIGHTS = { critical: 25, high: 15, medium: 8, low: 3 };
const CONTEXT_MULTIPLIER = { 'customer-facing': 1.0, 'internal': 0.7, 'dev-only': 0.4 };
const EXPLOITABILITY_PENALTY = 0.85;

export class PostureEngine {
  private redis: RedisClientType;

  constructor(redisUrl: string) {
    this.redis = createClient({ url: redisUrl });
  }

  async initialize() {
    await this.redis.connect();
  }

  async ingestFindings(findings: Finding[]): Promise<PostureState> {
    const baseline = await this.getBaseline();
    const driftDetected = this.detectDrift(findings, baseline);
    
    let rawPenalty = 0;
    for (const f of findings) {
      const baseWeight = SEVERITY_WEIGHTS[f.severity];
      const contextMod = CONTEXT_MULTIPLIER[f.businessContext];
      const exploitMod = f.exploitability ? EXPLOITABILITY_PENALTY : 1.0;
      rawPenalty += baseWeight * contextMod * exploitMod;
    }

    // Normalize to 0-100 scale, cap at 0
    const score = Math.max(0, 100 - Math.round(rawPenalty));
    const state: PostureState = {
      score,
      findings,
      lastUpdated: Date.now(),
      driftDetected
    };

    await this.redis.set(`posture:state:${Date.now()}`, JSON.stringify(state));
    return state;
  }

  private detectDrift(current: Finding[], baseline: Finding[]): boolean {
    const currentIds = new Set(current.map(f => f.id));
    const baselineIds = new Set(baseline.map(f => f.id));
    const diff = new Set([...currentIds].filter(x => !baselineIds.has(x)));
    return diff.size > 0;
  }

  private async getBaseline(): Promise<Finding[]> {
    const latest = await this.redis.keys('posture:state:*');
    if (latest.length === 0) return [];
    const data = await this.redis.get(latest[latest.length - 1]);
    return data ? JSON.parse(data).findings : [];
  }
}

Architecture Decisions & Rationale

• Event-Driven Ingestion over Batch Scanning: Webhooks from CI/CD, cloud control planes, and runtime agents feed findings into a message queue (Kafka/SQS). This eliminates scan windows and ensures posture reflects the actual deployed state.
• State Store with Versioning: Redis or PostgreSQL maintains posture snapshots keyed by commit SHA, deployment ID, or timestamp. Versioning enables diff tracking, audit trails, and rollback validation.
• Policy Engine Separation: OPA/Rego handles declarative policy evaluation, while TypeScript handles aggregation, weighting, and state management. This separation allows security teams to write policies without touching application code, while engineering controls scoring logic.
• Context-Aware Scoring: CVSS alone is insufficient. Business context (customer-facing vs. dev-only) and exploitability signals adjust weights dynamically, preventing score inflation from low-risk findings and ensuring engineering prioritization aligns with actual risk.

Pitfall Guide

1. Treating Assessment as a Scan, Not a State: Scans produce point-in-time data. Posture assessment requires persistent state tracking. Without versioned snapshots, you cannot measure drift or validate remediation.
2. Ignoring Configuration Drift: Infrastructure changes between assessments create blind spots. Implement drift detection by comparing current state against the last approved baseline, not just scanning from scratch.
3. Over-Indexing on CVSS Without Business Context: A CVSS 9.8 vulnerability in a dev-only internal service poses different risk than the same score in a payment gateway. Context modifiers prevent misallocation of remediation resources.
4. Alert Fatigue from Untriaged Findings: Dumping raw scanner output into Slack or Jira guarantees ignored alerts. Implement severity routing, duplicate suppression, and automated triage based on exploitability and exposure.
5. Lack of Remediation Ownership & SLA Tracking: Findings without assigned owners and time-bound SLAs become technical debt. Tie posture scores to engineering OKRs and enforce escalation paths when scores drop below thresholds.
6. Static Thresholds in Dynamic Environments: Fixed score thresholds (e.g., "fail if <80") break in rapidly scaling or multi-tenant environments. Use dynamic baselines that adjust based on environment criticality and deployment velocity.
7. Excluding Runtime & Dependency Data: SAST/IaC scanning misses runtime misconfigurations, ephemeral credentials, and transitive dependency vulnerabilities. Integrate SBOM analysis, runtime telemetry, and secrets rotation logs into the posture model.

Best Practices from Production:

• Shift policy evaluation to pre-commit and pre-deploy gates.
• Automate remediation for low-risk, high-frequency findings (e.g., tag enforcement, encryption defaults).
• Calibrate scoring monthly using incident data and false positive feedback loops.
• Expose posture as a CI/CD status check, not a separate security tool.
• Maintain a single source of truth for findings; avoid tool-specific dashboards.

Production Bundle

Action Checklist

• Define risk taxonomy: Map severity, exploitability, and business context to scoring weights
• Instrument data collectors: Deploy IaC, cloud API, dependency, and runtime connectors
• Deploy policy engine: Implement OPA/Rego or TypeScript-based evaluation functions
• Configure state store: Set up versioned persistence for posture snapshots and drift tracking
• Integrate with CI/CD: Add posture score as a required status check before deployment
• Establish remediation SLAs: Assign ownership, set escalation thresholds, and automate low-risk fixes
• Calibrate scoring monthly: Adjust weights using incident data, false positive rates, and deployment velocity

Decision Matrix

Scenario	Recommended Approach	Why	Cost Impact
Early-stage startup (<10 devs)	IaC + Dependency scanning + TypeScript posture engine	Low overhead, fast feedback, scales with team size	Low (open-source + minimal infra)
Regulated enterprise (SOC2/HIPAA)	CSPM + OPA policy engine + State-backed audit trail	Compliance requires continuous evidence, drift tracking, and policy versioning	Medium (licensed CSPM + managed state store)
Multi-cloud environment	Event-driven ingestion + Unified scoring model + Runtime telemetry	Cross-cloud visibility prevents siloed assessments and inconsistent baselines	High (multi-cloud agents + message queue + observability stack)
High-velocity CI/CD (multiple deploys/day)	Pre-commit policy gates + Drift detection + Automated remediation	Batch scanning breaks deployment flow; continuous evaluation maintains velocity	Medium (CI/CD integration + automation tooling)

Configuration Template

{
  "postureEngine": {
    "scoring": {
      "severityWeights": { "critical": 25, "high": 15, "medium": 8, "low": 3 },
      "contextMultiplier": { "customer-facing": 1.0, "internal": 0.7, "dev-only": 0.4 },
      "exploitabilityPenalty": 0.85,
      "baselineThreshold": 80
    },
    "ingestion": {
      "sources": ["sast", "cspm", "dependency", "runtime"],
      "queue": "kafka://security-findings",
      "batchSize": 50,
      "timeoutMs": 3000
    },
    "state": {
      "store": "redis",
      "ttlDays": 90,
      "driftDetection": true,
      "snapshotInterval": "deployment"
    },
    "policy": {
      "engine": "opa",
      "rulesPath": "./policies/security.rego",
      "evaluationMode": "strict"
    }
  }
}

Quick Start Guide

1. Initialize the engine: Clone the posture assessment repository, install dependencies (npm ci), and set REDIS_URL and KAFKA_BROKERS in .env.
2. Load baseline policies: Place OPA/Rego rules in ./policies/ or use the provided TypeScript policy functions. Run npm run policy:validate to verify syntax.
3. Start ingestion: Launch the Redis and Kafka instances locally via Docker Compose. Run npm run posture:start to begin consuming findings and calculating scores.
4. Verify state: Query the posture API (GET /api/v1/posture/latest) or check Redis keys. A score between 0–100 will appear, with driftDetected: false on first run.
5. Integrate with CI/CD: Add the posture check step to your pipeline. Block deployments when score < baselineThreshold or driftDetected === true.