Review Workflow

The Defensive Review Lifecycle

Linmas structures defensive security reviews into five explicit stages. This prevents context bloat, ensures focused analysis by the right specialist, and produces reproducible evidence before code is merged or deployed.

1. Scope

Define the exact boundaries of the change being inspected. Linmas reviews operate on concrete artifacts:

• A specific Git commit or pull request diff (e.g. patch.diff);
• A single cloud infrastructure template (Terraform, CloudFormation, Kubernetes manifest);
• A focused API route handler or database query.

Keeping the input bounded prevents hallucination and ensures high-signal security findings.

2. Route

Select the appropriate specialized skill for the target domain:

• Unclear / Multi-domain risk: Start with linmas-security-domain-router to identify the primary concern.
• Application code / API changes: Use linmas-secure-code-reviewer.
• System & auth architecture: Use linmas-secure-systems-architect.
• IAM & infrastructure: Use linmas-cloud-hardening-architect.
• Operational readiness: Use linmas-security-operations-lead.

3. Review

The skill evaluates the scoped input against defensive principles, threat models, and safe defaults. The output is normalized into structured findings containing:

• Risk title & category: Clear vulnerability classification (e.g. SQL injection, SSRF, permissive IAM role);
• Severity & impact: Why this finding matters and what an adversary could achieve;
• Policy evaluation: Comparison against defined policy thresholds (e.g. baseline-appsec).

4. Remediate

Linmas provides actionable, code-level fix recommendations rather than generic security advice. The remediation includes the exact code or configuration snippet necessary to eliminate the vulnerability.

5. Verify

Every fix must include a concrete verification step:

• A regression unit test or integration test asserting safe behavior;
• A re-run of the Linmas review on the amended patch to confirm the policy decision turns to PASS.