Secure Development (SDLC) Policy

1. Purpose

This policy states how Lever AI builds and maintains its software so that security is designed in, defects are caught before release and cannot silently recur, and the code that ships is reviewed, tested, and free of embedded secrets. It expands the secure-development principle summarised in the Information Security Policy and is the authoritative statement of Lever AI's development requirements. How releases are gated, deployed, and rolled back is set out in the Change Management Policy.

2. Scope

This policy applies to all software Lever AI develops and operates — the agent runtime, the MCP tool server, the admin-facing web application, document-processing code, and deployment and operational tooling — and to everyone who writes or lands code for the company, including contractors. It applies equally to human-written and AI-generated code.

3. Policy

3.1 Secure by design

Security is considered from design onward, not retrofitted. Designs favour least privilege (tools and services hold only the access they need), deterministic and scoped interfaces over open-ended ones, validation of external input — including the content of customer-supplied documents — and failure modes that refuse rather than guess. Significant design decisions and their rationale are recorded in the repository alongside the code they concern. The standing write-safety controls that govern what the shipped agent may do in a customer's tenant — read-back verification, duplicate guards, the prohibition on invented data, and human-in-the-loop decisions — are set out in the AI Governance Policy.

3.2 Source control and code review

All source code is held in private GitHub repositories under version control; there is no other path to production, as the Change Management Policy enforces. Substantive changes — new features, changes to security-relevant behaviour, changes to write paths against customer systems — are reviewed by an engineer other than the author where a second engineer exists. Lever AI is a company of single-digit headcount, and this policy is honest about the consequence: independent review of every change cannot be guaranteed. Where it is not available, the mandatory compensating controls of the Change Management Policy apply in full — the release test suite, the deploy gate, and version-stamped attributable deployments — so that unreviewed code is still tested, recorded, and traceable to its author before it can reach production.

3.3 Testing and incident-derived regression packs

Behaviour is verified by the offline test suite that gates every release under the Change Management Policy. Within development, the following are mandatory:

• new functionality ships with tests that exercise its behaviour;
• defect fixes are made tests-first: a test that reproduces the defect is written and observed to fail before the fix is made, and remains in the suite afterwards;
• incidents produce regression packs built from the incident's real payloads — the actual inputs that triggered the failure, replayed as tests — added to the suite as part of root-cause analysis under the Incident Response and Business Continuity Policy, so the same failure cannot recur unnoticed.

3.4 AI-assisted development

Engineers may use AI tools to generate or modify code. AI-generated code is held to exactly the same bar as human-written code: it receives the same review under section 3.2, must pass the same tests, and passes through the same release gates — it is never exempted from any control on the grounds that a model produced it. The engineer who commits AI-generated code is accountable for it as if they had written it, and must understand what it does before landing it. Secrets and customer data must not be placed into development prompts except through the company's approved AI provider under the terms that govern the service itself (see the AI Governance Policy and the Vendor and Third-Party Risk Management Policy).

3.5 Secrets hygiene

Secrets — credentials, API keys, tokens, and private keys — are never committed to source control, embedded in code, or written to logs. Service credentials are held in Azure App Service configuration and a restricted auth store, per the Cryptography and Encryption Policy. Repositories must not contain live credentials even in history: if a secret is committed, it is treated as a suspected compromise — the credential is rotated immediately and the event is handled under the Incident Response and Business Continuity Policy. Test fixtures use dummy values, never real credentials.

3.6 Dependency management

Third-party dependencies are taken from reputable public registries and pinned through lockfiles, so builds are reproducible and what runs in production is known exactly. Source-control- native dependency vulnerability alerts on the company's repositories are monitored, and affected dependencies are remediated within the timelines of the Vulnerability Management Policy. Dependency updates are reviewed before adoption — an update is a change like any other and passes the release test suite. A software bill of materials can be generated from the lockfiles on request.

3.7 Environments and data in development

Development and validation are performed against designated test tenants, never against live customer tenants. Customer data is not copied into development environments or test fixtures; where realistic data shapes are needed, synthetic data is used. Access to production data and customer environments is governed by the Access Control Policy.

4. Responsibilities

The Founder is accountable for this policy. Every engineer is responsible for the code they land — including AI-generated code — for writing the tests this policy requires, and for keeping secrets out of the repository. Detailed security roles are set out in the Security Roles and Responsibilities document.

5. Exceptions

Exceptions to this policy require the Founder's written approval, a recorded rationale and compensating control, and an expiry date.

6. Review

This policy is reviewed at least annually and after any significant change to the technology stack, the development toolchain, the team, or the threat environment.