Repo hygiene: templates, Dependabot, and security policy

.github/dependabot.yml

@@ -0,0 +1,18 @@
+version: 2
+
+updates:
+  # Keep GitHub Actions up to date (workflow actions + reusable actions).
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+      day: "monday"
+      time: "06:00"
+      timezone: "Europe/Berlin"
+    open-pull-requests-limit: 5
+
+    # Group all GitHub Actions updates into a single weekly PR to reduce noise.
+    groups:
+      github-actions:
+        patterns:
+          - "*"

SECURITY.md

@@ -0,0 +1,49 @@
+# Security Policy
+
+This document describes how to report security vulnerabilities for **IdentityLifecycleEngine (IdLE)** and what
+maintainers/consumers can expect in terms of response and disclosure.
+
+> Note: Detailed guidance for maintainers (required repository settings, Dependabot configuration, and operational
+> checks) lives in `docs/advanced/security.md`.
+
+## Supported Versions
+
+IdLE is currently in active development.
+
+- **Only the latest released version is considered supported for security fixes.**
+- Security fixes are developed on `main` and released as soon as practical.
+
+## Reporting a Vulnerability
+
+Please **do not** open a public GitHub issue for security-sensitive reports.
+
+Preferred channel:
+
+1. Use **GitHub Security Advisories** to privately report a vulnerability:
+   - Repository → **Security** → **Advisories** → **New draft security advisory**
+
+What to include:
+
+- A clear description of the issue and potential impact
+- Reproduction steps or a minimal proof-of-concept (if available)
+- Affected version(s), configuration, and environment details
+- Any suggested fix or mitigation (optional)
+
+If you are unsure whether something is security-relevant, report it anyway via Security Advisories.
+
+## Coordinated Disclosure
+
+Maintainers will:
+
+- Acknowledge receipt as soon as reasonably possible
+- Work with the reporter to reproduce and validate the issue
+- Prepare a fix and a release plan
+- Publish an advisory and release notes once a fix is available
+
+We aim to coordinate disclosure to reduce risk for users while ensuring proper credit for reporters.
+
+## Maintainer Notes
+
+Maintainers should ensure repository security hygiene is enabled and continuously monitored. See:
+
+- `docs/advanced/security.md`

docs/advanced/security.md

@@ -1,8 +1,8 @@
 # Security and Trust Boundaries
 
-IdLE is designed to execute *data-driven* lifecycle workflows in a deterministic way.
+IdLE is designed to execute **data-driven** identity lifecycle workflows in a deterministic way.
 
-Because IdLE is an orchestration engine, it must be very explicit about **what is trusted** and **what is untrusted**.
+Because IdLE is an orchestration engine, it must be explicit about **what is trusted** and **what is untrusted**.
 
 ## Trust boundaries
 
@@ -20,6 +20,15 @@ These inputs may come from users, CI pipelines, or external systems and **must b
 
 IdLE enforces this by rejecting ScriptBlocks when importing workflow definitions and by validating inputs at runtime.
 
+IdLE assumes these inputs are **data only**. Dynamic / executable content must be rejected.
+
+Current enforcement principles:
+
+- Workflow definitions must be static data structures (hashtables/arrays/strings/numbers/bools).
+- ScriptBlocks inside workflow definitions are rejected.
+- Event sinks must be objects with a `WriteEvent(event)` method. ScriptBlock sinks are rejected.
+- Step registry handlers must be **function names (strings)**. ScriptBlock handlers are rejected.
+
 ### Trusted extension points (code)
 
 These inputs are provided by the host and are **privileged** because they determine what code is executed:
@@ -89,3 +98,43 @@ Redaction is intentionally centralized at output boundaries to keep the executio
 - Use providers for system operations; do not embed authentication logic inside steps.
 - Emit events using `Context.EventSink.WriteEvent(Type, Message, StepName, Data)`.
 - Avoid global state. Steps should be idempotent whenever possible.
+
+## Repository security hygiene (maintainers)
+
+This section documents the repository-level security posture and the settings maintainers should keep enabled.
+
+### Dependency hygiene (Dependabot)
+
+IdLE uses Dependabot to keep GitHub Actions dependencies current.
+
+- Configuration file: `.github/dependabot.yml`
+- Expected behaviour: a **weekly** PR that groups GitHub Actions updates
+
+**Verify**:
+
+1. Repository → **Insights** → **Dependency graph** → **Dependabot**
+2. Confirm update activity and that PRs are being opened
+
+### Recommended GitHub repository security settings
+
+These settings are managed in GitHub and cannot be enforced via source control. Maintain them as part of routine repo maintenance:
+
+- **Dependabot alerts**: enabled
+- **Dependabot security updates**: enabled
+- **Secret scanning**: enabled (and **push protection** if available for the repo)
+- **Branch protection rules** on `main`:
+  - Require pull requests before merging
+  - Require status checks to pass before merging (CI)
+  - Restrict force pushes
+- **Least privilege** for workflows:
+  - Use explicit `permissions:` blocks in workflows
+  - Prefer read-only defaults unless a job needs write access
+
+**Verify** (typical locations):
+
+- Repository → **Settings** → **Security** (feature availability depends on GitHub plan)
+- Repository → **Settings** → **Branches** (branch protection)
+
+## See also
+
+- Root security policy: `SECURITY.md`