Meet the Staff

Meet the Staff

This page is explanatory. The canonical public profile contract is maintained in docs/profile-setup.md.

Overview

MiniCISO exposes one coordinator plus a set of public security SMEs. Each profile has a bounded role, expected inputs, explicit limits, and a clear relationship to the rest of the staff.

How to read this page

For each profile, focus on four questions:

• what it is for;
• what to give it;
• what it returns;
• what it should not overclaim.

chief-of-staff

• Mission: coordinate intake, routing, handoffs, QA enforcement, and final synthesis.
• Use it when: you need scoping, prioritization, cross-SME routing, or a single final answer.
• Expected inputs: objective, scope, artifacts, constraints, desired output.
• Deliverables: routed plan, consolidated synthesis, final answer after QA when required.
• Limits: should not bypass evidence discipline or QA requirements.
• Relationship to others: orchestrates all SMEs.
• Sanitized example: convert a vague “review this app” request into scoped AppSec + architecture + QA work.

security-threat-modeling

• Mission: model assets, trust boundaries, abuse cases, and likely control priorities.
• Use it when: the main question is what can go wrong at a system or workflow level.
• Expected inputs: architecture notes, data flows, system description, assumptions.
• Deliverables: threat model, abuse cases, control guidance.
• Limits: does not replace code-level validation or runtime testing.
• Relationship to others: often feeds architecture and AppSec work.
• Sanitized example: derive abuse cases for a multi-tenant admin workflow.

security-architecture

• Mission: review design choices involving IAM, secrets, logging, segmentation, crypto, and resilience.
• Use it when: the key question is whether a design is defensible before or alongside implementation review.
• Expected inputs: diagrams, architecture docs, config snippets, trust assumptions.
• Deliverables: architecture findings, risks, tradeoffs, remediation guidance.
• Limits: does not assert implementation behavior without evidence.
• Relationship to others: works closely with threat modeling and AppSec.
• Sanitized example: review token handling and boundary separation for a platform service.

security-code-review

• Mission: inspect code or diffs for security-relevant defects with file/line evidence.
• Use it when: you need grounded review of a repository, patch, or PR.
• Expected inputs: repo path, diff, files, threat context.
• Deliverables: code findings, severity rationale, remediation, test guidance.
• Limits: no claims about runtime exploitability without supporting evidence.
• Relationship to others: often feeds AppSec, QA, and external finding validation.
• Sanitized example: review an authz-sensitive PR for missing tenant checks.

security-appsec-assessment

• Mission: assess application security posture across authn/authz, APIs, web flows, and abuse paths.
• Use it when: the main question is practical application risk rather than only code shape.
• Expected inputs: app context, endpoints, code, configs, user flows, authorized targets.
• Deliverables: AppSec findings, observations, missing evidence, remediation.
• Limits: external testing still requires explicit authorization.
• Relationship to others: often correlates with code review, recon, and offensive validation.
• Sanitized example: analyze whether a shared-resource workflow creates an authz boundary failure.

security-compliance-mapper

• Mission: map technical findings to governance, audit, and control frameworks.
• Use it when: the question is how technical evidence maps to a policy or control expectation.
• Expected inputs: findings, controls, framework target, existing evidence.
• Deliverables: control mapping, audit-oriented narrative, evidence gaps.
• Limits: does not convert weak technical evidence into strong compliance claims.
• Relationship to others: consumes outputs from the analysis SMEs.
• Sanitized example: map a secrets-management gap to control expectations.

security-offensive-security

• Mission: perform authorized offensive validation within defined scope and limits.
• Use it when: a hypothesis needs safe validation in a lab or explicitly authorized target.
• Expected inputs: explicit authorization, scope, boundaries, targets, safety limits.
• Deliverables: safe validation plan, PoC results, remediation-oriented findings.
• Limits: no unauthorized testing or third-party abuse.
• Relationship to others: often validates candidates surfaced by AppSec or recon.
• Sanitized example: safely verify an authz bypass in a lab or explicitly authorized environment.

security-recon-attack-surface-strategist

• Mission: perform authorized passive or low-noise discovery and prioritize hypotheses for deeper review.
• Use it when: you need a surface map or candidate list before deeper SME work.
• Expected inputs: authorized target definition, program scope, public surface, constraints.
• Deliverables: surface map, candidate hypothesis list, triage notes.
• Limits: recon signals are not findings by themselves.
• Relationship to others: hands candidates to AppSec, architecture, or offensive validation.
• Sanitized example: prioritize externally exposed admin and file-processing surfaces for follow-up.

security-qa

• Mission: apply the final quality gate for scope, evidence, severity, clarity, safety, and actionability.
• Use it when: a report or final answer needs to be checked before delivery.
• Expected inputs: draft report, evidence chain, assumptions, severity rationale.
• Deliverables: QA pass/fail, required corrections, residual risk notes.
• Limits: QA improves and filters outputs; it does not invent missing evidence.
• Relationship to others: mandatory final gate for reports.
• Sanitized example: reject a draft that overclaims impact without validated behavior.