Secure Development

The Secure Development module governs how your engineering organization builds and releases software safely. It is the governance layer over secure software development lifecycle (SDLC) activity: projects, threat models, application security reviews, secure code reviews, security test gates, and exceptions where production data is used in non-production environments.

This module does not own source code, change requests, or vulnerabilities themselves. Those live in version control, Change Management, and Vulnerability Management. Secure Development is the governance record of the SDLC discipline: who reviewed what, what threats were modelled, what test gates passed, what exceptions were granted and why.

When you would reach for this

You set up secure development when:

A framework, customer, or internal policy requires a documented secure-SDLC program.
New product initiatives need threat-modelling at design time.
Application security reviews need an audit trail of what was assessed and what was decided.
Secure code reviews on sensitive code paths need to be tracked.
Pre-release security test gates need to be enforced and recorded.
Production data flowing into non-production environments needs explicit, time-bounded, approved exceptions.

You don’t reach for this for the engineering work itself (the code, the pipelines). Secure Development is the governance overlay on top.

What lives in secure development

Multiple record types:

Secure development project is the umbrella for an engineering effort being governed. Each project carries scope, owners, and link points for the other records.
Threat model captures the design-time threat-modelling output: assets, actors, threats, mitigations, residual risks.
Application security review captures a security review of an application or subsystem, with scope, methodology, findings.
Secure code review captures a code review on sensitive code paths.
Security test gate captures the pre-release security testing that gated a release: SAST, DAST, dependency scan, manual test results.
Production-data-in-test exception captures the approved, time-bounded use of production data in a non-production environment.

A worked example: a video game studio governs its release-readiness

A video game studio ships a popular online multiplayer game with substantial server infrastructure, in-game economy, and a player community. New features and live-ops releases ship weekly. Each release has security implications: cheats, exploits, payment fraud, account takeover. The security engineering lead, Yuki, sets up Secure Development like this.

Step 1: project structure. Each major workstream becomes a secure development project: matchmaking-platform, in-game-economy, account-services, community-features. Each project has scope, owners, and a snapshot capturing the threat surface.

Step 2: threat modelling at design time. For each significant feature (a new in-game purchase flow, a new social feature, a new matchmaking algorithm), a threat model is created at design time. The threat model captures: what’s being added, what actors might attack it, what threats are in scope, what mitigations are designed in, what residual risks remain after mitigations.

Step 3: application security review before release. Before a feature ships, an application security review is performed. The review captures: scope of what was assessed, methodology used, findings, recommended actions. Findings flow into the main Findings register.

Step 4: code reviews on sensitive paths. Code touching authentication, payment processing, the in-game economy, or external API integrations gets a documented secure code review. The reviewer (not the code’s author) signs off.

Step 5: security test gates per release. Each release passes through a security test gate: SAST clean, dependency scan within thresholds, DAST against staging clean, manual test for the highest-risk areas signed off. The gate’s pass/fail is recorded; failures block the release.

Step 6: production-data exceptions. Occasionally, a debugging investigation needs production telemetry replayed in staging. The team requests a production-data-in-test exception: scope (which subset of data, what masking applies), time bound (typically 72 hours), approver (the data protection officer), justification. After the window expires, the data is purged.

After a year:

Every release has a documented gate record showing the security tests that passed.
Every major design has a threat model.
Sensitive code paths have signed-off reviews.
Production-data exceptions are bounded and audited.
An external audit (SOC 2, ISO 27001, console-platform compliance review) can be shown the full secure-SDLC trail.

What you’ll see in the product

Secure Development lives under Governance → Secure Development in the workspace.

Multiple top-level tabs: Projects, Threat Models, Application Security Reviews, Secure Code Reviews, Security Test Gates, Production-Data Exceptions.

Inside each record, you see the structured detail, the linked subject, the actor, and the activity history.

Every change is captured in the workspace Audit Log.

Common workflows

Standing up a secure development project

Secure Development → Projects → New project. Scope, owners, snapshot.
Create threat models as new features are designed.
Run application security reviews before release.

Threat modelling

From the project, create a new threat model.
Capture the feature being modelled, actors, threats, mitigations, residual risks.
Route for review by the security engineering lead.
Mitigations may generate controls, findings, or follow-up assessments.

Running a security test gate

From the project (or directly under Security Test Gates), create a gate for the upcoming release.
Link to the change request and/or release.
Record SAST, DAST, dependency scan, and manual test results.
Pass or fail the gate; failures block the release through the gating policy.

Requesting a production-data exception

Production-Data Exceptions → New. Scope, time bound, justification, requested approver.
Approver reviews and either approves or denies with rationale.
On approval, the team uses the data; on expiry, the data is purged.

Change Management - releases gated by Secure Development gates live here.
Vulnerability Management - findings from application security reviews often become vulnerabilities.
Findings - all kinds of secure-development findings live here.
Exceptions - production-data exceptions also surface in the central exceptions register.
Assets - the systems being developed often have asset records.