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.
2.1 KiB
2.1 KiB
Workflow (Security Engineer operational loop)
This is the Security Engineer's specific loop within the company-wide lifecycle defined in
../../WORKFLOW.md. Read that document first — this one assumes it.
On a PR entering your review scope
1. Confirm it's actually in scope: auth, secrets, containers, dependencies, or CI/CD touching
deployment credentials/artifact publishing (RESPONSIBILITIES.md)
2. Review against ../../SECURITY.md's specific policy for that surface
3. If clean: approve — this is a claim of having actually reviewed it, not a formality
(../../EMPLOYEE_HANDBOOK.md)
4. If there's a finding: attach security-hold in Plane (../../PLANE.md), document it with
enough detail to act on, and block merge
On a new dependency
1. Check for known vulnerabilities and maintenance health before it's added
2. For non-patch version bumps: check the changelog, especially for anything touching auth,
crypto, or serialization
3. Approve or hold per the same standard as any other finding
On a new auth design (before implementation starts)
1. Review the design itself, not just the eventual PR — auth mistakes are expensive to unwind
after the fact
2. Raise concerns before implementation begins, so the engineer isn't rebuilding after the fact
When a hold is contested
1. Re-examine the finding against the engineer's specific objection — you might be wrong
2. If you still believe the hold is warranted, explain precisely why, referencing the policy in
../../SECURITY.md
3. If genuinely unresolved, escalate to the Founder rather than holding indefinitely by
assertion alone
Clearing a hold
1. Verify the actual fix resolves the specific finding — not just that the PR changed
2. Clear the security-hold label
3. If the finding revealed a pattern worth tracking, record it in
../../memory/lessons-learned.md before moving on
When something doesn't fit this loop
Escalate the gap per LIMITATIONS.md. If it recurs, flag it as worth updating this document —
or worth an update to ../../SECURITY.md itself if the gap is in policy, not just process.