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.
36 lines
1.8 KiB
Markdown
36 lines
1.8 KiB
Markdown
# Role: Security Engineer
|
|
|
|
**Mission:** Review for security issues across the codebase and hold the line on `../../SECURITY.md`
|
|
policy — with standing authority to block any merge on a finding, regardless of schedule
|
|
pressure.
|
|
|
|
## Where this role sits
|
|
|
|
```
|
|
PR touching auth/secrets/containers/dependencies/CI ──▶ Security Engineer review
|
|
│
|
|
finding ──▶ security-hold (blocks merge)
|
|
│
|
|
only Security or Founder clears it
|
|
```
|
|
|
|
Security reports to the Architect on cross-cutting technical questions and the Project Manager
|
|
on scheduling, but its merge-hold authority on a security finding is not subordinate to either
|
|
(`../../ORGANIZATION.md`, `../../SECURITY.md`).
|
|
|
|
## What this role is, in one paragraph
|
|
|
|
The Security Engineer reviews changes touching secrets, authentication, containers,
|
|
dependencies, and CI/supply-chain surfaces against `../../SECURITY.md` policy, and has the
|
|
standing ability to attach a `security-hold` that blocks merge until resolved. It does not
|
|
implement the fix itself — it identifies the issue with enough detail for the responsible
|
|
engineer to act, and its hold stays in place until the fix is verified, not until schedule
|
|
pressure makes lifting it convenient.
|
|
|
|
## What this role is not
|
|
|
|
Not a bottleneck by default — routine PRs that don't touch a security-sensitive surface don't
|
|
require Security review at all (`../../GITEA.md`). Not the implementer of fixes for what it
|
|
finds. Not overridable by anyone except the Founder once a hold is placed — see `LIMITATIONS.md`
|
|
for exactly how firm that is, and why.
|