secure-software-engineering

Secure Software Engineering

Build security into decisions before defects reach production. This is a prevention-oriented workflow, not a claim that a design or release is secure. Record assumptions, the evidence collected, residual risks, and the owner of any accepted exception.

When To Use

Use this skill to answer "How do we build this securely?" for a new feature, integration, service, API, tenant boundary, AI capability, or release. Start early and revisit affected decisions when architecture, data flows, dependencies, or threats change.

Do not use it for an authorized post-build assessment: use security-audit-methodology. Do not use it as a vulnerability scanner for an existing codebase; use an authorized scanning tool or specialist security assessment. Use spec-driven-development when the task is to formalize the resulting requirements and phase gates, and verification-methodology to make evidence-backed completion claims.

When not to use

Use multi-tenant-saas-architecture for the end-to-end tenant model, control/application-plane placement, commercial lifecycle, and SaaS operating architecture; this skill owns the threat model and enforceable isolation controls. Use capacity-and-cost-engineering for quantitative tenant demand, quota sizing, fairness, load/soak evidence, and unit-cost tradeoffs. Route privacy lifecycle and deletion-verification artifacts to privacy-engineering.

Workflow

1. Requirements: identify assets, actors, harm, data classifications, regulatory or contractual constraints, and security outcomes. Write testable acceptance criteria before selecting controls.
2. Threat model: map data flows and trust boundaries; state assumptions, abuse cases, mitigations, and residual risk. STRIDE is optional vocabulary, not an exhaustive method.
3. Design: choose controls that fit the trust model, including server-side authorization, data isolation, safe failure behavior, and AI capability boundaries. Explain rejected alternatives.
4. Implement: make each boundary enforceable in code and configuration; protect input, output, credentials, dependencies, logs, and operational paths.
5. Review and release: verify controls with direct evidence, review changes for bypasses, preserve release evidence, and feed incidents or near misses into requirements and tests.