mindforge-cc 10.0.3 → 11.0.0

package/.mindforge/skills/compliance-as-code/SKILL.md

@@ -0,0 +1,195 @@
+---
+name: compliance-as-code
+version: 1.0.0
+min_mindforge_version: 0.1.0
+status: stable
+triggers: compliance as code, policy engine, OPA rego, automated compliance, audit evidence, SOC2 mapping, HIPAA control, compliance check, policy enforcement, control framework, compliance report, regulatory automation
+---
+
+# Skill — Compliance as Code
+
+## When this skill activates
+Any task involving automated compliance verification, policy-as-code implementation,
+audit evidence generation, regulatory control mapping, or compliance CI integration.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Identify the compliance framework(s) applicable (SOC2, HIPAA, PCI-DSS, GDPR).
+2. Map specific controls to technical policies that can be automated.
+3. Define evidence requirements for each control.
+
+### During implementation
+- Write policies as code (OPA/Rego, Sentinel, Conftest).
+- Integrate policy checks into CI pipeline (fail on violation).
+- Generate machine-readable evidence automatically.
+
+### After implementation
+- Verify all mapped controls have automated verification.
+- Set up continuous compliance dashboard with drift alerts.
+- Document policy-to-control mapping in ARCHITECTURE.md.
+
+## Policy Engines
+
+### OPA (Open Policy Agent) with Rego
+- General-purpose policy engine.
+- Declarative policy language (Rego).
+- Use for: infrastructure policies, API authorization, data access control.
+- Integrations: Kubernetes (Gatekeeper), Terraform, CI pipelines, API gateways.
+
+```rego
+package terraform.aws
+
+deny[msg] {
+    resource := input.resource.aws_s3_bucket[name]
+    not resource.server_side_encryption_configuration
+    msg := sprintf("S3 bucket '%s' must have encryption enabled", [name])
+}
+```
+
+### HashiCorp Sentinel
+- Policy-as-code for Terraform Enterprise/Cloud.
+- Enforces infrastructure policies before apply.
+- Use for: cost controls, naming conventions, required tags, approved regions.
+
+```hcl
+import "tfplan"
+
+main = rule {
+    all tfplan.resources.aws_instance as _, instances {
+        all instances as _, r {
+            r.applied.tags contains "environment"
+        }
+    }
+}
+```
+
+### Conftest
+- Testing framework for structured configuration data.
+- Uses OPA/Rego policies against YAML, JSON, HCL, Dockerfile.
+- Use for: Kubernetes manifests, Docker configs, CI pipelines.
+
+```rego
+package main
+
+deny[msg] {
+    input.kind == "Deployment"
+    not input.spec.template.spec.securityContext.runAsNonRoot
+    msg := "Containers must run as non-root"
+}
+```
+
+## Control Framework Mapping
+
+### SOC2 Trust Service Criteria
+| Control | Policy | Automated Check |
+|---------|--------|-----------------|
+| CC6.1 (Logical Access) | IAM least privilege | No wildcard permissions in policies |
+| CC6.6 (System Boundaries) | Network segmentation | Security groups restrict ingress |
+| CC7.2 (Monitoring) | Log aggregation | All services emit structured logs |
+| CC8.1 (Change Management) | PR approval required | Branch protection rules enforced |
+
+### HIPAA Security Rule (164.312)
+| Control | Policy | Automated Check |
+|---------|--------|-----------------|
+| 164.312(a)(1) Access Control | Role-based access | RBAC policies enforced |
+| 164.312(a)(2)(iv) Encryption | Data encrypted at rest | All storage encrypted |
+| 164.312(b) Audit Controls | Audit logging | All PHI access logged |
+| 164.312(e)(1) Transmission Security | TLS required | No HTTP endpoints |
+
+### PCI-DSS
+| Requirement | Policy | Automated Check |
+|-------------|--------|-----------------|
+| 2.2 System hardening | CIS benchmark | Configuration scanner passes |
+| 3.4 Data encryption | Encryption at rest | Storage encryption verified |
+| 6.5 Secure development | SAST/DAST | No critical findings in scan |
+| 10.2 Audit trails | Comprehensive logging | All access events captured |
+
+## Evidence Generation
+
+### Automated Evidence Types
+- **Configuration snapshots**: point-in-time state of security configs.
+- **Policy evaluation results**: pass/fail with details for each control.
+- **Access review reports**: who has access to what, generated automatically.
+- **Deployment audit trails**: who deployed what, when, with what approval.
+
+### Evidence Requirements
+- Timestamped and immutable (stored in append-only log).
+- Machine-readable (JSON/structured format for automated processing).
+- Traceable (linked to specific control and policy).
+- Continuous (generated on every change, not just at audit time).
+
+### Example Evidence Output
+```json
+{
+  "control": "CC6.1",
+  "framework": "SOC2",
+  "policy": "no-wildcard-iam-permissions",
+  "result": "PASS",
+  "timestamp": "2024-01-15T10:30:00Z",
+  "resource": "arn:aws:iam::123456:policy/app-service",
+  "details": "No wildcard actions found in policy document",
+  "evidence_hash": "sha256:abc123..."
+}
+```
+
+## CI Pipeline Integration
+
+### Pipeline Stage: Policy Check
+```yaml
+stages:
+  - name: compliance-check
+    steps:
+      - conftest test --policy policies/ deployment.yaml
+      - opa eval --data policies/ --input tfplan.json "data.terraform.deny"
+    on_failure: block_deployment
+```
+
+### Enforcement Levels
+- **Advisory**: log warning, don't block (for new policies being rolled out).
+- **Soft mandatory**: block with override option (requires approval).
+- **Hard mandatory**: block deployment, no override (critical security controls).
+
+### Gradual Rollout of New Policies
+1. Deploy policy in advisory mode (2 weeks).
+2. Review violations, adjust policy if false positives.
+3. Promote to soft mandatory (2 weeks).
+4. Promote to hard mandatory after all violations resolved.
+
+## Compliance Dashboard
+
+### Key Metrics
+- **Compliance score**: percentage of controls with passing automated checks.
+- **Drift count**: controls that passed previously but now fail.
+- **Time to remediate**: average time from violation detection to fix.
+- **Coverage**: percentage of controls with automated verification.
+
+### Alerting
+- Drift detected: immediate alert to security team.
+- New violation in PR: block merge, notify developer.
+- Compliance score drops below threshold: escalate to CISO.
+- Evidence generation failure: alert compliance team.
+
+## Reporting
+
+### Continuous Compliance Report
+- Generated on demand or on schedule (weekly/monthly).
+- Shows: all controls, current status, evidence links, violation history.
+- Format: PDF for auditors, JSON for automated systems.
+
+### Audit Preparation
+- Pre-audit checklist: verify all evidence is current and complete.
+- Gap analysis: identify controls without automated verification.
+- Remediation tracking: SLA for fixing violations.
+
+## Self-check before task completion
+
+Before marking a task done when this skill was active:
+
+- [ ] Did I read the full SKILL.md before starting? (Not just the triggers)
+- [ ] Is every control mapped to an automated policy?
+- [ ] Are policies integrated into CI (blocking on violation)?
+- [ ] Is evidence generated automatically (not manually)?
+- [ ] Is there a compliance dashboard with drift alerting?
+- [ ] Are enforcement levels appropriate (advisory → soft → hard)?
+- [ ] Is the policy-to-control mapping documented?

package/.mindforge/skills/conflict-resolution/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: conflict-resolution
+version: 1.0.0
+min_mindforge_version: 10.3.0
+status: stable
+triggers: conflict resolution engineering, technical disagreement, architecture debate, priority conflict resolution, team friction, code review conflict, design decision deadlock, tech stack disagreement, cross-team dispute, engineering opinion conflict, consensus building, disagree and commit
+---
+
+# Conflict Resolution
+
+## When this skill activates
+
+This skill activates when resolving technical disagreements, mediating architecture debates, handling priority conflicts, addressing team friction, or breaking design decision deadlocks. It applies to tech leads, engineering managers, and senior engineers who must navigate conflicts and drive teams toward resolution.
+
+## Mandatory actions when this skill is active
+
+### Before engaging in conflict resolution
+
+1. **Diagnose the conflict type** — Is this a technical disagreement (different approaches to the same goal), a priority conflict (what to work on first), or an interpersonal conflict (personality clash)? Different types require different interventions.
+2. **Verify the conflict is real** — Sometimes perceived conflicts are actually misunderstandings. Ask each party to state their position and their understanding of the other party's position. Clarify before attempting resolution.
+3. **Assess stakes and urgency** — Low-stakes conflicts (coding style preference) can be deferred or decided by convention. High-stakes conflicts (architectural choice) require immediate resolution. Triage accordingly.
+4. **Check your neutrality** — If you have a strong opinion on the outcome, you're not a neutral mediator. Either recuse yourself or explicitly acknowledge your bias before facilitating.
+
+### During conflict resolution
+
+#### Technical Disagreements
+
+- **Separate facts from opinions** — Facts: "Option A has 200ms latency." Opinions: "Option A feels cleaner." Debate facts rigorously. Acknowledge opinions but deprioritize them.
+- **Demand evidence** — Don't let "I think" or "in my experience" dominate. Require benchmarks, prototypes, or references to real-world implementations. Speculation loses to data.
+- **Use ADRs (Architecture Decision Records)** — Formalize the debate: each side writes a proposal with context, decision, consequences, and alternatives rejected. Writing forces rigor and surfaces unstated assumptions.
+- **Run time-boxed experiments** — If the debate can't be resolved theoretically, prototype both approaches. Two engineers, two days, working implementation. Compare results objectively.
+- **Escalate with recommendations** — If consensus is impossible, escalate to the tech lead or architect with a clear summary of both positions and a recommended path. Don't ask them to re-litigate the debate.
+
+#### Architecture Debates
+
+- **Ground in requirements** — What are the non-negotiable constraints? Performance? Scalability? Maintainability? Cost? Often debates evaporate when requirements are explicit.
+- **Identify tradeoffs explicitly** — No architecture is strictly better. Microservices improve scalability but increase operational complexity. Monoliths simplify deployment but limit independent scaling. Name the tradeoffs.
+- **Use the "two-way door" test** — If the decision is reversible, pick one and move on. If it's a one-way door (hard to undo), invest more time in deliberation.
+- **Timebox the debate** — Architecture debates can spiral. Set a 1-hour limit. If no consensus, escalate or use decision frameworks (DACI, voting, tech lead decides).
+- **Agree on success criteria** — Before implementing, define how you'll evaluate the choice in 3-6 months. If metric X doesn't improve, revert or pivot.
+
+#### Priority Conflicts
+
+- **Quantify impact** — Use a simple framework: Revenue Impact (High/Medium/Low), Risk Mitigation (High/Medium/Low), Strategic Alignment (High/Medium/Low). Score each project. Prioritize High-High-High over Low-Low-Low.
+- **Surface opportunity cost** — Every "yes" to one project is a "no" to another. Make the tradeoff explicit: "If we prioritize Project A, Project B slips by 6 weeks. Is that acceptable?"
+- **Involve stakeholders early** — Priority conflicts between engineering and product require product input. Don't let engineers decide in isolation.
+- **Revisit priorities regularly** — Priorities change. Revisit every quarter. Don't cling to a roadmap when circumstances shift.
+
+#### Code Review Conflicts
+
+- **Distinguish style from substance** — Style conflicts (tabs vs spaces, single quotes vs double quotes) should be decided by linters, not humans. Substance conflicts (error handling, edge cases) require discussion.
+- **Use "strong opinions, weakly held"** — If the reviewer feels strongly, they should explain why. If the author disagrees, they should explain their reasoning. The senior engineer or tech lead breaks the tie if necessary.
+- **Offer alternatives, not just criticism** — Don't say "This is wrong." Say "Have you considered X? It avoids Y problem and simplifies Z."
+- **Distinguish blocking from non-blocking feedback** — Blocking: correctness issues, security vulnerabilities, performance regressions. Non-blocking: refactoring suggestions, readability improvements. Blocking feedback must be addressed before merge. Non-blocking can be deferred to a follow-up PR.
+
+#### Interpersonal Conflicts
+
+- **Separate behavior from identity** — Address observable behavior, not personality. "You interrupted Sarah three times in the last meeting" is actionable. "You're rude" is a personal attack.
+- **Hold 1:1 conversations first** — Don't surface interpersonal conflict in group settings. Speak to each party individually, understand their perspective, then bring them together.
+- **Use "I" statements, not "you" statements** — "I felt frustrated when the deadline slipped without warning" is less defensive than "You failed to communicate the delay."
+- **Focus on shared goals** — Remind both parties: we're all trying to ship great software. Conflict over approach is healthy. Conflict over personalities is not.
+- **Escalate when necessary** — If conflict is causing sustained team dysfunction, escalate to your manager or HR. Don't try to play therapist.
+
+#### Consensus Building
+
+- **Start with alignment** — Find common ground first. "We all agree the system is too slow. The disagreement is whether to optimize queries or add caching." Starting with agreement reduces defensiveness.
+- **Use the "disagree and commit" principle** — If consensus is impossible and time is limited, the decision-maker (tech lead, architect, manager) makes the call. Dissenters must commit fully once the decision is made, even if they disagreed.
+- **Document dissent respectfully** — If someone strongly disagrees, allow them to document their concerns in the ADR. Future-you will appreciate knowing what tradeoffs were considered.
+- **Revisit after implementation** — Schedule a retrospective 3-6 months later. Was the decision correct? What would we do differently next time? Learning compounds with reflection.
+
+### After conflict resolution
+
+- **Document the resolution** — Write down: what the conflict was, what decision was made, who made it, and what the reasoning was. Prevents re-litigating the same debate in 6 months.
+- **Verify buy-in** — After resolution, check with each party individually: "Are you on board with this decision?" Surface any lingering resentment before it festers.
+- **Monitor team dynamics** — Conflict can damage relationships. Check in with team members regularly. If trust is broken, actively rebuild it through transparent communication and collaboration.
+- **Reflect on resolution effectiveness** — Did the conflict resolution process work? Was it too slow? Too rushed? Adjust your approach for next time.
+
+## Self-check before task completion
+
+- [ ] Conflict type is diagnosed (technical, priority, or interpersonal)
+- [ ] Evidence and facts are used to ground technical disagreements, not opinions
+- [ ] Tradeoffs are explicitly identified in architecture debates
+- [ ] Priority conflicts are quantified with impact scoring (revenue, risk, strategy)
+- [ ] Code review conflicts distinguish blocking vs non-blocking feedback
+- [ ] Interpersonal conflicts address observable behavior, not personality
+- [ ] Resolution is documented with decision rationale and alternatives considered
+- [ ] Buy-in is verified with each party after resolution

package/.mindforge/skills/connection-pooling/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: connection-pooling
+version: 1.0.0
+min_mindforge_version: 0.1.0
+status: stable
+compose: database-patterns
+triggers: connection pooling, pool sizing, connection lifecycle, pgbouncer, connection leak, pool exhaustion, connection timeout, pool monitoring, connection reuse, max connections, idle connection, pool configuration
+---
+
+# Skill — Connection Pooling
+
+## When this skill activates
+Any task involving database connection pool configuration, pool sizing,
+connection leak debugging, PgBouncer setup, or pool exhaustion issues.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Determine the workload characteristics (connection duration, concurrency level).
+2. Calculate optimal pool size using the sizing formula.
+3. Identify whether application-level or external pooling is appropriate.
+
+### During implementation
+- Configure connection validation (test-on-borrow or background validation).
+- Set appropriate timeouts for checkout, idle eviction, and max lifetime.
+- Add leak detection with stack trace logging.
+
+### After implementation
+- Monitor pool metrics (active, idle, waiting counts).
+- Set alerts for pool exhaustion and high wait times.
+- Document pool configuration in ARCHITECTURE.md.
+
+## Pool Sizing Formula
+
+```
+optimal_pool_size = (core_count * 2) + effective_disk_spindles
+```
+
+- For SSD: effective_spindles = 1 (low seek time).
+- Typical range: 20-50 connections per application instance.
+- More connections != better performance (context switching overhead).
+- PostgreSQL max_connections default is 100 — shared across ALL clients.
+
+### Example Calculations
+| Cores | Storage | Formula | Pool Size |
+|-------|---------|---------|-----------|
+| 4 | SSD | (4*2)+1 | 9 |
+| 8 | SSD | (8*2)+1 | 17 |
+| 16 | HDD (4 disks) | (16*2)+4 | 36 |
+
+## Connection Lifecycle
+
+```
+CREATE → VALIDATE → USE → RETURN → IDLE → EVICT
+```
+
+### Create
+- Establishing a new connection (expensive: TCP handshake + auth + TLS).
+- Pool pre-creates `min_idle` connections at startup.
+
+### Validate
+- Test connection is still alive before handing to application.
+- Methods: `SELECT 1`, TCP keepalive, driver-level ping.
+- Background validation preferred over test-on-borrow (lower latency).
+
+### Use
+- Application borrows connection from pool.
+- Connection is marked as "active" — not available to others.
+- Timeout if application holds too long (leak detection trigger).
+
+### Return
+- Application returns connection to pool after query completes.
+- Connection reset (clear session state, temp tables, transaction state).
+
+### Idle
+- Connection sits in pool waiting for next request.
+- `idle_timeout`: evict if unused for too long (default: 10 minutes).
+- `max_lifetime`: destroy after absolute age (default: 30 minutes).
+
+### Evict
+- Connection destroyed (closed at TCP level).
+- Reasons: idle timeout, max lifetime, validation failure, pool shrinking.
+
+## PgBouncer Modes
+
+### Session Pooling
+- Connection assigned to client for entire session duration.
+- Supports all PostgreSQL features (prepared statements, LISTEN/NOTIFY).
+- Least efficient — similar to no pooling.
+
+### Transaction Pooling (Recommended)
+- Connection assigned per transaction, returned after COMMIT/ROLLBACK.
+- Most common production mode.
+- Limitations: no prepared statements, no session-level SET commands.
+
+### Statement Pooling
+- Connection assigned per individual statement.
+- Most aggressive sharing — highest connection efficiency.
+- Limitations: no transactions, no multi-statement operations.
+
+## Leak Detection
+
+### Symptoms
+- Pool exhaustion (all connections checked out, waiters queuing).
+- Gradually increasing active connection count over time.
+- Application hangs waiting for connection from pool.
+
+### Detection
+- `checkout_timeout`: fail fast if no connection available within N seconds.
+- `leak_detection_threshold`: log stack trace if connection held > N seconds.
+- Monitor: connections_active should correlate with request rate.
+
+### Prevention
+- Always use try-with-resources / context managers.
+- Set aggressive checkout timeouts (5-10 seconds).
+- Connection wrapper that auto-returns on GC (safety net, not primary).
+
+## Pool Exhaustion Handling
+
+### DO
+- Queue with timeout (wait up to 5s for available connection).
+- Return clear error message: "Connection pool exhausted, try again later."
+- Alert operations team immediately.
+- Log queue depth and wait times.
+
+### DO NOT
+- Create unlimited connections (will crash the database).
+- Retry immediately in a tight loop (makes it worse).
+- Silently wait forever (request hangs, client times out).
+
+## Monitoring Metrics
+
+| Metric | Alert Threshold | Description |
+|--------|----------------|-------------|
+| `pool.active` | > 80% of max | Connections in use |
+| `pool.idle` | < 2 | Available connections |
+| `pool.waiting` | > 0 for > 5s | Requests queued for connection |
+| `pool.checkout_time_avg` | > 100ms | Time to acquire connection |
+| `pool.timeout_count` | > 0 | Failed connection acquisitions |
+| `pool.create_count` | Spike detection | New connections being created |
+
+## Self-check before task completion
+
+Before marking a task done when this skill was active:
+
+- [ ] Did I read the full SKILL.md before starting? (Not just the triggers)
+- [ ] Is pool size calculated using the formula (not arbitrary)?
+- [ ] Are connection timeouts configured (checkout, idle, max lifetime)?
+- [ ] Is leak detection enabled with stack trace logging?
+- [ ] Are pool metrics instrumented and alerting configured?
+- [ ] Is the pooling mode appropriate for the workload?

package/.mindforge/skills/container-security/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: container-security
+version: 1.0.0
+min_mindforge_version: 10.1.1
+status: stable
+triggers: container security, image scanning, runtime policy, rootless container, secrets injection, container network policy, pod security standard, image provenance, base image hardening, container isolation, runtime detection, supply chain container
+compose: security-review
+---
+
+# Skill — Container Security
+
+## When this skill activates
+Any task involving container image security, runtime hardening,
+Kubernetes security policies, container secret management,
+or supply chain integrity for containerized workloads.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Select base image strategy (distroless preferred, Alpine acceptable, Ubuntu last resort).
+2. Identify secrets required and injection mechanism (never env vars in manifests).
+3. Define network policy requirements (default-deny baseline).
+4. Determine Pod Security Standard level (restricted > baseline > privileged).
+
+### During implementation
+- Pin base images by digest (not just tag) for reproducibility.
+- Run as non-root user (UID > 10000).
+- Set filesystem to read-only where possible.
+- Drop all Linux capabilities, add back only what's needed.
+- Never store secrets in image layers or environment variables in manifests.
+- Use multi-stage builds to exclude build tools from runtime image.
+
+### After implementation
+- Run Trivy/Grype scan — block on CRITICAL or HIGH CVEs.
+- Sign image with cosign and generate SBOM.
+- Verify Pod Security Standard compliance.
+- Test NetworkPolicy blocks unauthorized traffic.
+- Confirm secrets are injected at runtime (not baked in).
+
+## Image Scanning
+
+### CI Pipeline Integration
+```yaml
+# Block deployment if critical CVEs found
+- trivy image --severity CRITICAL,HIGH --exit-code 1 $IMAGE
+```
+
+### Scan Frequency
+- On every build (CI gate).
+- Weekly scheduled scan of running images (new CVEs discovered post-deploy).
+- Before promotion between environments.
+
+### Vulnerability Management
+- CRITICAL: Block deployment, fix immediately.
+- HIGH: Block deployment, fix within 48 hours.
+- MEDIUM: Track, fix within sprint.
+- LOW: Backlog, fix opportunistically.
+
+## Base Image Strategy
+
+| Priority | Image Type | Use Case |
+|----------|-----------|----------|
+| 1 | `gcr.io/distroless/static` | Go binaries, no shell needed |
+| 2 | `gcr.io/distroless/base` | C/C++ apps needing libc |
+| 3 | `alpine:3.x` | When shell/package manager needed |
+| 4 | `ubuntu:22.04-minimal` | Complex runtime dependencies |
+
+### Rules
+- Pin by digest: `FROM alpine@sha256:abc123...`
+- Rebuild weekly to pick up base image security patches.
+- Never use `latest` tag in production.
+
+## Runtime Hardening
+
+### Pod Security Standards (Kubernetes)
+
+**Restricted (target for all workloads):**
+```yaml
+securityContext:
+  runAsNonRoot: true
+  runAsUser: 10001
+  readOnlyRootFilesystem: true
+  allowPrivilegeEscalation: false
+  capabilities:
+    drop: ["ALL"]
+  seccompProfile:
+    type: RuntimeDefault
+```
+
+### Container Isolation
+- Use gVisor or Kata Containers for untrusted workloads.
+- Separate namespaces for different trust levels.
+- Resource limits (CPU, memory) to prevent DoS.
+
+## Secrets Management
+
+### Injection Methods (Ranked)
+1. **External Secrets Operator** → syncs from Vault/AWS SM to K8s Secret → volume mount.
+2. **Vault Agent Sidecar** → injects secrets into shared volume at runtime.
+3. **CSI Secret Store Driver** → mounts secrets as files.
+4. **Sealed Secrets** → encrypted in Git, decrypted in cluster.
+
+### Anti-patterns (NEVER do)
+- Secrets as environment variables in Pod spec/Deployment manifest.
+- Secrets baked into container image.
+- Secrets in ConfigMaps.
+- Secrets committed to Git (even "encrypted" without proper tooling).
+
+## Network Policies
+
+### Default Deny Baseline
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny-all
+spec:
+  podSelector: {}
+  policyTypes:
+    - Ingress
+    - Egress
+```
+
+Then explicitly allow required flows:
+- Ingress: only from specific services/namespaces.
+- Egress: only to required databases, APIs, DNS.
+
+## Supply Chain Integrity
+
+### Image Provenance
+1. Sign all images with `cosign` in CI.
+2. Generate SBOM (Software Bill of Materials) with `syft`.
+3. Enforce signature verification in admission controller (Kyverno/OPA).
+4. Use deterministic builds for reproducibility.
+
+### Admission Control
+- Reject unsigned images.
+- Reject images from untrusted registries.
+- Reject images with known critical CVEs.
+- Reject pods violating security context requirements.
+
+## Self-check
+- [ ] Base image pinned by digest.
+- [ ] Non-root user configured.
+- [ ] Read-only filesystem enabled.
+- [ ] All capabilities dropped (add back minimally).
+- [ ] Image scanned with zero CRITICAL/HIGH CVEs.
+- [ ] Secrets injected at runtime (not in manifest or image).
+- [ ] NetworkPolicy default-deny applied.
+- [ ] Image signed and SBOM generated.
+- [ ] Pod Security Standard: restricted level.