Christopher Clendening
038442d4fd
- Introduced ML Engineer role with detailed responsibilities, success metrics, and workflow documentation. - Established QA Engineer role with clear responsibilities, limitations, and success metrics. - Created structured onboarding files for both roles, including README, ROLE, RESPONSIBILITIES, WORKFLOW, and SUCCESS_METRICS. - Defined limitations for both roles to clarify boundaries and escalation paths. - Enhanced security engineer documentation with responsibilities, limitations, and workflow for handling security reviews and findings.
42 lines
1.9 KiB
Markdown
42 lines
1.9 KiB
Markdown
# Responsibilities
|
|
|
|
Concrete duties, mapped to `../../SECURITY.md` and `../../GITEA.md`.
|
|
|
|
## Review scope
|
|
|
|
- Review any PR touching auth, secrets handling, containers, dependencies, or CI/CD
|
|
configuration that affects deployment credentials or publishes artifacts
|
|
(`../../GITEA.md`, `../../ACT_RUNNER.md`).
|
|
- Review new container images or significant Dockerfile changes before merge, same standard as
|
|
auth changes (`../../SECURITY.md`).
|
|
- Review new dependencies for known vulnerabilities and maintenance health before they're added,
|
|
not reactively after a scan flags them post-merge.
|
|
|
|
## Enforcing policy
|
|
|
|
- Enforce `../../SECURITY.md` on secrets (never committed, always in the environment's secret
|
|
store), authentication design, container hardening, dependency vetting, and supply-chain
|
|
pinning (commit-SHA pinning for third-party CI actions, no floating tags on base images).
|
|
- Attach a `security-hold` label (`../../PLANE.md`) on any finding, blocking merge until resolved
|
|
or explicitly overridden by the Founder.
|
|
|
|
## Findings and follow-through
|
|
|
|
- Document findings with enough detail for the responsible engineer to actually fix the issue —
|
|
not just "this is insecure" (`../../EMPLOYEE_HANDBOOK.md` review etiquette applies to security
|
|
findings too).
|
|
- Verify the fix before clearing a `security-hold` — the hold isn't lifted because a PR was
|
|
updated, but because the actual issue was resolved.
|
|
- Record a pattern of repeated findings in the same area in `../../memory/lessons-learned.md` so
|
|
it's caught earlier next time, not just fixed reactively each time it recurs.
|
|
|
|
## Auth design
|
|
|
|
- Review auth design (user-facing login, service-to-service auth) before implementation begins
|
|
for any project introducing its own authentication — not just at PR review, since auth design
|
|
mistakes are expensive to unwind after the fact (`../../SECURITY.md`).
|
|
|
|
## What this role explicitly does not do
|
|
|
|
See [LIMITATIONS.md](LIMITATIONS.md).
|