## 6 Lab-Built Scenario and Benchmarking
### Quantitative Benchmarking Results
#### 6.3.2 User Interaction with AZTRM-D Implemented System  
Figures 10 and 11 provide a detailed visual explanation of the secure workflows that govern how developers and administrators interact with the AZTRM-D implemented system, particularly concerning code management and server access. Figure 10 specifically illustrates the Secure Git Server Workflow within AZTRM-D, emphasizing a shift-left security approach where checks are integrated early and continuously. This diagram highlights the multi-layered security gates and stringent administrative approvals mandated before any code can progress from individual developer repositories to a production-ready state. The process begins with individual developers initiating a 'Request to Commit to Main Repository', an action that is immediately 'Audit Logged' to maintain a comprehensive and immutable trail of all changes. Before any code is considered for merging, it undergoes a 'Vulnerability Scan (SAST)' (Static Application Security Testing), which analyzes the source code for potential security flaws without executing it. If this scan fails, the commit is automatically rejected, forcing the developer to remediate the identified issues. A successful scan triggers an 'Audit Log' and requires 'Admin 1 Approval', a critical human gate for code quality and initial security verification. Following this, a 'Secrets Scan' is performed on the developer's code. This is crucial for detecting any accidentally embedded credentials, API keys, or other sensitive information, preventing their exposure in the codebase. A failed 'Secrets Scan' also results in rejection, while a successful one is logged. Figure 9: The internal security process flow for a device operating under the AZTRM-D model, from secure boot to continuous monitoring and policy enforcement. Figure 10: The secure Git Server workflow within AZTRM-D, illustrating the mandatory security checks and administrative approvals required for code progression. Figure 11: The Multi-layered User Authentication and Session Management Flow for accessing a device-hosted server under AZTRM-D’s strict ZT policies. Once individual developers have successfully passed these initial checks and approvals, their work is integrated through a 'Merge' operation into a unified 'QA (Merge of all Dev Repositories)' environment. This integrated codebase is logged and then requires 'Admin 2 Approval', serving as a higher-level quality assurance or security review. If approved, the integrated code proceeds to a 'Dependency and SBOM (Software Bill of Materials) Check'. This step is vital for supply chain security, examining all third-party libraries and components for known vulnerabilities and ensuring a complete inventory of software ingredients. A failure here sends the code back for remediation. Success at this stage is logged, and the QA version then undergoes a dynamic 'Vulnerability Scan (DAST)'. Unlike SAST, DAST tests the application in its running state to find vulnerabilities that only appear during execution. If the 'DAST' is not passed, the build is rejected. After successfully passing DAST, the code is subjected to an 'Infrastructure as Code Scan'. This ensures that any configuration scripts or templates used to deploy the application are also secure and compliant, checking for misconfigurations that could create vulnerabilities in the deployment environment. If this scan is passed, the code moves to the 'Stage (QA Approved Version Repository)', serving as a hardened pre-production environment. Every successful step continues to be logged. The final gate before production is the 'Super Admin Approved' decision, representing the highest level of authorization. Upon receiving this approval, the release artifact is formally 'Signed (Sign Release Artifact)', a critical cryptographic step for ensuring its integrity and authenticity. This signed artifact is then stored in a 'Secure Rep (repository)'. From this secure storage, the application is finally deployed to the 'Prod (Production Repository)'.