Work HistoryServicesAbout MeContact

Secure Software Development Lifecycle (SDLC) Process

ReactionGears LLC

Document Owner Mike Kerr, Founder & Principal Engineer
Version 1.0
Effective Date August 31, 2026
Last Reviewed August 31, 2026
Review Cadence Annually, and after any significant change to tools or process
Primary Standard NIST SP 800-218 (Secure Software Development Framework, SSDF)
Supporting Standards OWASP ASVS, OWASP Top 10
Companion Documents Information Security Policy v1.0, Cyber Risk Management Framework v1.0

1. Purpose

This document describes the Secure Software Development Lifecycle (SDLC) process ReactionGears LLC follows to build, test, deploy, and maintain software securely. It ensures that security is considered at every phase of development rather than treated as an afterthought, and that the applications we deliver to clients are built with secure defaults and validated before release.

The process is aligned with the NIST Secure Software Development Framework (SSDF, SP 800-218) and applies OWASP guidance (ASVS, Top 10) for application-level security.

2. Scope

This process applies to all software ReactionGears designs, develops, deploys, or maintains for clients, and to the tools and environments used to do so. It applies to the Principal (Mike Kerr) and any approved subcontractor.

3. Secure SDLC Principles

  • Security by design and by default: Secure choices are the baseline, not an add-on.
  • Least privilege everywhere: Code, credentials, and infrastructure grant only the access required.
  • Shift left: Vulnerabilities are prevented and caught as early in the lifecycle as possible.
  • Defense in depth: Multiple layers of control (input validation, authorization, encryption, monitoring).
  • Human accountability for all code: Every change, including AI-assisted code, is reviewed and owned by the Principal before it ships (see Section 5).

4. SDLC Phases and Security Activities

4.1 Requirements & Design

  • Capture security and privacy requirements alongside functional requirements (authentication, authorization, data sensitivity, compliance needs such as PCI-DSS or HIPAA where relevant).
  • Perform lightweight threat modeling for features that touch authentication, payments, personal data, multi-tenancy, or external integrations — identifying where mistakes would be expensive and designing controls accordingly.
  • Choose frameworks and services with strong security track records and secure defaults.
  • Define the data model with tenant isolation and least-privilege access in mind from the start.

4.2 Development

  • Follow secure coding practices: parameterized queries (no string-built SQL), input validation, output encoding to prevent injection and XSS, safe authentication/session handling, and correct authorization checks on every protected operation.
  • Enforce tenant isolation at the database layer for multi-tenant systems (e.g., PostgreSQL Row-Level Security), so one tenant can never access another’s data even if application logic fails.
  • Secrets management: API keys, tokens, and credentials are kept out of source code and stored in environment variables or a secrets manager. Repositories are configured with secret scanning; any exposed secret is rotated immediately.
  • Use version control (Git) for all code, with private client work kept in private repositories and a clear, reviewable commit history.

4.3 Dependency & Supply-Chain Management

  • Source third-party dependencies only from reputable registries.
  • Monitor dependencies for known vulnerabilities using automated tooling (e.g., dependency/vulnerability alerts) and apply security updates promptly.
  • Prefer well-maintained, widely-adopted libraries; minimize the dependency surface.

4.4 Testing & Verification

  • Code review: Every change is reviewed before it is merged and deployed. Reviews specifically check authentication, authorization, data handling, secrets, and error handling — not just functionality.
  • Automated checks: Type checking, linting, secret scanning, and dependency vulnerability scanning run as part of the development workflow.
  • Functional and edge-case testing of critical paths, including negative tests for access control and input validation.
  • Security-focused verification for high-risk areas (auth flows, payment/webhook handling and idempotency, tenant isolation) before release, guided by OWASP ASVS-style checks appropriate to the application’s risk level.

4.5 Deployment & Release

  • Environment separation: Development, staging, and production are kept separate with independent credentials. Production data is never copied into lower environments.
  • Repeatable, automated deployments through defined pipelines, with the ability to roll back quickly if an issue is detected.
  • Secure configuration: HTTPS/TLS enforced, secure headers where applicable, least-privilege service accounts, and secrets injected at deploy time rather than baked into artifacts.
  • Change management: Changes are deliberate, reviewed, and traceable to a commit.

4.6 Operations & Maintenance

  • Keep runtime dependencies, platforms, and servers patched.
  • Monitor provider security alerts and, where available, application/access logs for anomalies.
  • Respond to security issues per the Incident Response process in the Information Security Policy (Section 12), including immediate rotation of any exposed credential and client notification without undue delay and no later than 72 hours.

4.7 Decommissioning

  • On project or feature end, revoke credentials and access, securely delete data no longer required (subject to contract and law), and remove unused integrations and secrets.

5. AI-Assisted Development

ReactionGears makes extensive, responsible use of AI coding tools. Our controls for AI-assisted development:

  • AI-written code is a review surface, not a trust boundary. All AI-generated code is reviewed by the Principal with the same rigor as human-written code — with particular attention to authentication, authorization, data handling, secrets, and edge cases — before it is merged or deployed.
  • The human is accountable. The Principal owns every change that ships, regardless of how it was drafted.
  • No secrets to AI tools. Production credentials, secrets, and sensitive client data are not pasted into AI tools; work is done against specs, schemas, and non-sensitive context.
  • Spec-driven: AI tools are directed against detailed, reviewed specifications, and the resulting code is validated against those requirements and the security checks above.

6. Roles and Responsibilities

  • Principal (Mike Kerr): Owns this process; performs threat modeling, secure development, code review, security verification, and secure deployment; approves releases.
  • Subcontractors/Collaborators (if engaged): Follow this process, submit work for review, and never bypass security controls or checks.

7. Continuous Improvement

This process is reviewed at least annually and after any significant change to tools, platforms, or lessons learned from incidents or near-misses. Improvements are incorporated into the standard workflow.

This document describes the secure software development practices of ReactionGears LLC and is provided for vendor and client due diligence. It should be read alongside the ReactionGears LLC Information Security Policy and Cyber Risk Management Framework. Specific contractual security terms take precedence over this general process.

ReactionGears LLC · Yorba Linda, California · [email protected] · www.reactiongears.com