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.
1.9 KiB
1.9 KiB
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.mdon 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-holdlabel (../../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.mdreview 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.mdso 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.