A.8.25: Secure Development Life Cycle
Control Objective
To ensure that information security is designed and implemented within the development lifecycle of information systems.
Policy Statement
anDREa embeds security constraints directly into every stage of its Software-as-a-Service (SaaS) application lifecycle. By enforcing a structured Development, Testing, Acceptance, and Production (DTAP) framework, code-defined quality gates, immutable logging pipelines, and automated deployment paths, anDREa ensures that modifications to the myDRE ecosystem are thoroughly vetted, authorized, and insulated against data misuse or supply chain compromise.
1. Fundamental Security Design Requirements
All system engineering and development activities must align with the following core architectural mandates:
- Segregation of Duties: The software lifecycle is organized to ensure that no single individual can develop, test, and push code changes to production without independent oversight or automated verification.
- Separation of Facilities: Staging, compilation, and testing environments are strictly partitioned from production environments to insulate real-time customer data workloads from development activities.
- Unique Identity Allocation: All internal users, developers, and engineers are provisioned with unique, non-repudiable identity accounts within our unified directory infrastructure.
- Enforced Credential Profiles: Strong password structures are enforced across all services. For sensitive, privileged, or administrative connections, multi-factor authentication (MFA) is strictly mandatory.
- Data Minimization: anDREa operates purely as an infrastructure provider and does not possess or store raw research data. Consequently, no live customer or research data is ever utilized within development, testing, or acceptance loops.
- Architecture Integrity: Foundational design patterns are aligned with A.08.27 - Secure system architecture and engineering principles.
Privileged Execution and Oversight (Azure PIM)
Administrative modifications during the lifecycle rely on Just-In-Time (JIT) role elevation via Azure Privileged Identity Management (PIM):
- PIM access is limited exclusively to trained, explicitly mandated individuals.
- Active role lifecycles are strictly time-bound. Upon activation, automated audit notifications are dispatched instantly to
licenseadmin@mydre.orgalongside global Security and Global Administrators. - The MT periodically audits all PIM states, structural assignments, and eligibility pools to ensure long-term role health.
note
Definitive operational mapping for engineering and management personas is located within the Definition of (Security) Roles and Responsibilities and the anDREa Roles & Responsibilities Matrix.
2. The DTAP Isolation Architecture
The deployment and staging lifecycle of the myDRE ecosystem follows a strict four-tiered DTAP (Development, Testing, Acceptance, Production) framework:
| Environment | Hosting Environment | Access Matrix | Trigger & Deployment Conditions |
|---|---|---|---|
| Development | Local Developer Laptops | Assigned Individual Engineers | Code debugging and component validation are performed locally inside the engineer's workspace context. |
| Testing | Dedicated Microsoft Azure Subnet | Assigned Developers & QA Testers | Local code is committed to specialized feature/* branches, triggering a test build deployment. |
| Acceptance | Dedicated Microsoft Azure Subnet | Developers, Support & Assurance, Invited Guests | Triggered when feature validation is completed. Developers add metrics to the Release Plan and raise a formal Pull Request (PR) to shift code into the main branches. |
| Production | Isolated Microsoft Azure Production Subscriptions | Active Researchers, Authorized Tenants | Triggered following successful acceptance sign-offs and an architectural review of the Release Plan. Code is promoted via an authorized deployment pipeline. |
Automated Verification and Pipeline Promotion Guardrails
- The SonarCloud Quality Gate: Transitioning code from a
featurebranch intodevelopormainrequires a Pull Request (PR). Every PR programmatically initiates an automated SonarCloud Static Application Security Testing (SAST) scan. The system automatically blocks code merges if vulnerabilities, security hotspots, or code-smell deviations are detected. - Production Deployment Authorization: Pushing builds from Acceptance into Production requires formal manual approval from an authorized Operations Manager, Solution Architect, or Technical Architect.
- Deployment Traceability: Pipeline run profiles and compilation states triggering a production deployment are retained indefinitely to facilitate instant point-in-time rollbacks or application recovery.
- Resource Cross-Contamination Boundaries: Acceptance and Production environments operate in isolation. The only structural components shared across these layers are:
- Pre-vetted, non-sensitive Virtual Machine (VM) configuration templates.
- A unified Entra ID identity directory (though access to the Acceptance sandbox remains restricted and requires an explicit invitation).
3. Core Technologies & Technical Workflows
- Programming Stack: C#, .NET, TypeScript, ReactJS, PowerShell, Bash, Azure ARM, and Bicep (Infrastructure-as-Code).
- Code Framework Controls: Standard code constructs, dependency boundaries, and defensive design parameters are governed by the Secure Coding Checklist.
- Vulnerability & Availability Defenses: To protect proprietary platform logic, a master backup of the active myDRE source code repository is compiled and transferred to an external Escrow Deposition Service every quarter (see A.08.04 - Access to source code).
- Hotfix Continuity Rules: Security hotfixes, emergency patches, and critical bug resolutions are subject to the same rigorous testing, code analysis, and approval gates as standard features. No bypass mechanisms or ad-hoc pipeline exemptions are permitted.
For a granular look at day-to-day scrum behaviors and testing protocols, refer to A.05.37 - Documented operating procedures and A.08.29 - Security testing in development and acceptance.
4. Logging & Audit Trail Protection
- Immutability Parameters: Platform event logs and foundational system traces are aggregated within Azure Log Analytics Workspaces. The workspace is configured with an unalterable append-only profile; new entries can be ingested, but existing log files cannot be modified, deleted, or cleared by any identity tier.
- Oversight Boundaries: System logging tracks platform-level control planes, administrative role alterations, and core operating system events from underlying infrastructure nodes. In accordance with the Shared Responsibility Model, anDREa does not log or monitor application-level activities or workloads executed inside research VMs.
5. Organizational Tools & Artifact Output
Development Support Infrastructure
- Azure DevOps Boards: Work item tracking, sprint scheduling, and roadmap planning.
- Azure DevOps Pipelines & Artifacts: Automated Continuous Integration/Continuous Delivery (CI/CD) and secure binary package management.
- GitHub: Master source control, code review storage, and branch tracking.
- Google Workspace & Test Plans: Inter-team coordination, formalized risk assessments, and test matrices.
Produced Lifecycle Documentation
Every sprint and platform release generates a standardized set of operational artifacts maintained within the Azure DevOps Wiki and Corporate Knowledge Base:
- Functional and Technical Architecture Documentation.
- Public and Tenant Release Notes.
- User Manuals and Technical How-To Guides.
- Formalized Test Plans and Validation Scripts.
- Work Item Tracking (WIT) histories for Features, PBIs, and Bugs.