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
- Requirements: identify assets, actors, harm, data classifications, regulatory or contractual constraints, and security outcomes. Write testable acceptance criteria before selecting controls.
- Threat model: map data flows and trust boundaries; state assumptions, abuse cases, mitigations, and residual risk. STRIDE is optional vocabulary, not an exhaustive method.
- Design: choose controls that fit the trust model, including server-side authorization, data isolation, safe failure behavior, and AI capability boundaries. Explain rejected alternatives.
- Implement: make each boundary enforceable in code and configuration; protect input, output, credentials, dependencies, logs, and operational paths.
- 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.
Loop to the affected phase when evidence contradicts an assumption or a design changes. Stop when each material decision has an accountable owner, direct evidence or an explicit gap, and a disposition for residual risk.
Reference Files
| Load when | File |
|---|---|
| You need a version-pinned source and its decision use | references/source-index.md |
| Defining assets, boundaries, abuse cases, or security criteria | references/security-requirements-threat-modeling.md |
| Choosing identity, sessions, permissions, or service access | references/authentication-authorization.md |
| Handling requests, files, URLs, serialized data, output, or AI content | references/input-validation-data-handling.md |
| Adding a key, token, credential, or signing material | references/secrets-lifecycle.md |
| Adding, updating, building, or publishing dependencies | references/dependency-supply-chain.md |
| Designing logs, audit events, monitoring, or forensic evidence | references/secure-logging-audit.md |
| Sharing infrastructure or data across tenants, including control/application planes, tenant context, support access, or tenant lifecycle proof | references/multi-tenant-isolation.md |
| Reviewing a change or defining a security review gate | references/secure-code-review.md |
| Preparing artifacts, exceptions, rollback, or response for release | references/release-evidence.md; load release-engineering to carry those controls and evidence through build, registry, promotion, and deployment gates |
| Learning from an incident, near miss, or escaped defect | references/incident-learning.md |
| Designing an LLM, RAG pipeline, model integration, or agent tool | references/ai-llm-security.md |
Templates
| Use when | File |
|---|---|
| Starting a feature or system threat model | templates/lightweight-threat-model.md |
| Writing security acceptance criteria for a specification or change | templates/security-acceptance-criteria.md |
| Reviewing a security-relevant code change | templates/secure-code-review-checklist.md |
Guardrails
- Treat prompts, retrieved content, tool output, webhooks, files, and client-provided identity or tenant fields as untrusted until a boundary validates them.
- A framework, scan, SBOM, signature, provenance attestation, or checklist is evidence about a limited claim, not proof that software is safe.
- Do not make a control universal: authentication protocols depend on the trust model; row-level security is one isolation mechanism; secret rotation follows events and risk; controls need verification in their actual deployment.
- Keep completed threat models and security acceptance criteria confidential when they expose system boundaries or weaknesses. Use placeholders, never real credentials or private deployment details.
Portability
Use the host environment's normal mechanisms to create artifacts, run tests, and obtain approvals. Do not assume a vendor, cloud, identity provider, database, CI system, or deployment topology.