Local-LLC/SECURITY.md

SECURITY.md

Security policy for Local LLC, owned by the Security Engineer role (ORGANIZATION.md) with standing authority to block any merge on a finding — a block only the Security Engineer or the Founder can lift (WORKFLOW.md, EMPLOYEE_HANDBOOK.md).

Secrets

• No secret, credential, API key, or token is ever committed to a Gitea repository — including in test fixtures, example configs, or commit history that gets later "cleaned up." Once committed, treat it as compromised: rotate it, don't just remove it from the latest commit.
• Secrets live in the deployment environment's secret store (Portainer-managed secrets, or the runner's secret configuration for ACT Runner jobs — see ACT_RUNNER.md), never in a repository, project doc, or Plane task description.
• .env.example style files document which variables are needed, never real values.

Authentication

• Every AI employee authenticates as itself (its own Gitea/Plane identity per ORGANIZATION.md/GITEA.md) — never through a shared credential shared across roles.
• Any project that adds its own authentication (user-facing login, service-to-service auth) gets a Security Engineer review of the auth design before implementation begins, not just at PR review — auth design mistakes are expensive to unwind after the fact.

Containers

• Base images are pinned to a specific version/digest, not a floating latest tag.
• Containers run as a non-root user unless there's a specific, documented reason they can't.
• New container images or significant Dockerfile changes get a Security Engineer review before merge, the same as auth changes.

Dependencies

• Adding a new dependency is a deliberate choice, not a default — prefer what's already in the project's dependency set over adding an equivalent new one.
• New dependencies are checked for known vulnerabilities and reasonably active maintenance before being added, not after a scan flags them post-merge.
• Dependency version bumps that aren't purely patch-level get a changelog check, not a blind bump — especially for anything touching auth, crypto, or serialization.

Supply chain

• CI workflow files (.gitea/workflows or equivalent) that touch deployment credentials or publish artifacts require Security Engineer review, per ACT_RUNNER.md's deployment policy.
• Third-party GitHub Actions / Gitea Actions used in workflows are pinned to a commit SHA, not a mutable tag, wherever the action supports it.
• Any script that downloads and executes code from an external source at build or runtime is treated as a supply-chain risk requiring explicit Security Engineer sign-off — this mirrors the Founder-level prohibition on downloading/executing untrusted files, applied to CI/build pipelines.

Reporting and handling findings

• A Security Engineer finding attaches a security-hold label in Plane (PLANE.md) and blocks merge until resolved or explicitly overridden by the Founder.
• Findings are documented with enough detail for the responsible engineer to actually fix the issue, not just "this is insecure" — see EMPLOYEE_HANDBOOK.md on what a real review looks like; the same standard applies to security findings.
• A pattern of findings in the same area (e.g. repeated secret-handling mistakes in one project) gets recorded in memory/lessons-learned.md so it's caught earlier next time, not just fixed reactively each time it recurs.

What Security does not do

Security reviews and can block merges; it does not write the fix. The responsible engineer implements the fix and resubmits for review, the same as any other rejected PR (WORKFLOW.md).