Produce security governance compliance report

[heeki]

Produce security governance compliance report

Summary

Platform engineering teams evaluating Loom for adoption need visibility into the security and governance controls that the system automatically enforces. A compliance report should enumerate all built-in controls across authentication, authorization, infrastructure, data protection, resource governance, and audit — giving teams confidence that the platform meets their security posture requirements without manual intervention.

Context

Loom implements a layered security model spanning Cognito authentication, scope-based RBAC, least-privilege IAM roles, resource tagging policies, Secrets Manager integration, network segmentation, and audit logging. However, there is no consolidated view that a platform engineering team can review or export to verify compliance. The report should be generated from the system's actual configuration — not static documentation — so it stays accurate as the platform evolves.

Requirements

• R1: report-endpoint — The backend should expose a GET /api/security/compliance-report endpoint (scope: security:read) that generates a structured compliance report enumerating all security and governance controls the system implements. The report should be returned as JSON with sections for each control domain.

• R2: authentication-controls — The report must document authentication controls including: Cognito User Pool configuration (password policy, MFA status), OAuth2 flows (USER_PASSWORD_AUTH for users, client_credentials for M2M), token validation and propagation, and the auth config endpoint exposure policy (pool ID and region only — never client IDs or secrets).

• R3: authorization-controls — The report must document authorization controls including: the 19 resource server scopes, group-to-scope mappings for all Cognito groups (admin and user types), per-endpoint scope enforcement via require_scopes, and user-type/group-based resource filtering (e.g., demo users see only loom:group=demo resources).

• R4: iam-controls — The report must document IAM controls including: the least-privilege role template (shared/iac/role.yaml) with its specific policy statements (bedrock, bedrock-agentcore, secretsmanager, observability, memory), conditional policy inclusion (memory policy only when a memory ARN is provided), and the managed role lifecycle (creation, attachment, deletion).

• R5: data-protection-controls — The report must document data protection controls including: Secrets Manager usage for credential storage (client secrets, OAuth2 tokens) with in-memory caching (5-minute TTL), write-only secret fields (never returned in GET responses), secret cleanup on resource deletion, and the has_oauth2_secret boolean pattern for indicating secret presence without exposure.

• R6: resource-governance-controls — The report must document resource governance controls including: tag policy enforcement (required vs optional tags, default values, validation on deploy), tag profiles (named presets satisfying required policies), tag propagation to all AWS resources created during deployment, and group-based resource scoping.

• R7: network-controls — The report must document network controls including: ALB with TLS 1.3 termination (ELBSecurityPolicy-TLS13-1-2-2021-06), HTTP-to-HTTPS redirect, security group configurations (ALB ingress, ECS task ingress restricted to ALB), private subnet placement for ECS tasks, and SSM-based database access (no direct RDS exposure).

• R8: audit-controls — The report must document audit controls including: login event tracking with browser session correlation, action audit trail (category, type, resource name), page view tracking with duration, per-session timeline reconstruction, and admin dashboard analytics.

• R9: frontend-report-page — The frontend should provide a "Compliance Report" view accessible to users with security:read scope. The page should render the report sections in a readable format with expandable control domains and support exporting the report as JSON.

• R10: deployment-controls — The report must document deployment controls including: SAM CLI-based deployments with parameterized templates, environment-based naming conventions, infrastructure-as-code for all resources (no manual console changes), and the multi-stack separation (infra, rds, ec2, ecs) for blast radius containment.

Relevant Files

File	Description
backend/app/dependencies/auth.py	require_scopes, UserInfo, group-to-scope mappings
backend/app/routers/security.py	Security admin endpoints (roles, authorizers, credentials, permissions)
backend/app/routers/settings.py	Tag policy and tag profile CRUD
backend/app/routers/admin.py	Audit endpoints (login, action, pageview, sessions, summary)
backend/app/services/iam.py	IAM role creation and management
backend/app/routers/credentials.py	Credential management with Secrets Manager
shared/iac/role.yaml	Least-privilege IAM role template
shared/iac/cognito.yaml	Cognito User Pool, groups, scopes, clients
shared/iac/infra.yaml	ALB, security groups, TLS, network configuration
SPECIFICATIONS.md	Root security considerations and auth architecture

Labels

feature, security, backend, frontend