Secure Development Lifecycle Policy

1. Objective

Define security controls for the entire development lifecycle, from requirements to production operation.

2. Scope

Applies to frontend code, Edge Functions, migration scripts, environment configuration and release processes.

3. Settings

• SAST: static security analysis in the code.
• Shift-left: address security from the planning phase.
• Mudanca critica: change in auth, RLS, export, Edge Functions or personal data.

4. Mandatory Guidelines

1. Planning

• Security requirements must be defined for new features.
• Critical changes must include risk and impact assessment.

2. Development

• Apply input validation and sanitization.
• Prohibit secrets in client and repository code.
• Follow multi-tenant segregation standards (hub_id, RLS and roles).

3. Code review

• PR with at least one reviewer for normal changes.
• PR with reinforced review for critical changes.
• PR must describe risk, testing and rollback.

4. Tests

• Run lint and relevant tests before merging.
• Run SAST check (Semgrep or equivalent).
• Test permission scenarios (allowed + denied) in RLS changes.

5. Deploy and operation

• Deploy must follow the approved change process.
• Critical errors must be monitored in observability.
• Reported vulnerabilities must be included in the backlog with priority.

5. Roles and Responsibilities

• Engineering: implement and validate technical controls.
• Tech Lead: review critical changes and release merges.
• CTO: approve high-risk exceptions.
• Product: guarantee security and privacy requirements in the functional scope.

6. Exceptions

Temporary exceptions are only permitted with approval from CTO, documented risk and correction deadline.

7. Compliance and Evidence

Minimum evidence:

• PRs with security checklist.
• Result of lint/tests/SAST in the delivery cycle.
• Recording of security incidents and corrective actions.

8. Review and Versioning

• Quarterly review.
• Immediate review after a security incident with a developing cause.