# 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`).