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.
58 lines
2.1 KiB
Markdown
58 lines
2.1 KiB
Markdown
# 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.
|