SDLC Draft 2 - Design and Code processes #
1. Design
1.1 Design Standards
Project Interstate adheres to a rigorous set of security design standards to minimize risk and support security-by-design principles. These include:
- Enforcing layered architecture with defined trust boundaries
- Implementing least privilege access across all subsystems
- Encrypting all sensitive data both at rest and in transit
- Minimizing attack surfaces by defaulting to secure configurations
- Avoiding hardcoded credentials and requiring robust authentication for all interfaces
All teams follow centralized documentation for security architecture guidelines and threat model templates, ensuring consistency and reviewability across the entire system.
1.2 Security Training
All engineering personnel involved in Project Interstate undergo quaterly security training covering secure architecture, threat modeling, secure API and firmware interactions, secure coding practices, cryptographic standards, and insider threat awareness. Teams involved in high-impact areas (e.g., Navigation AI, vehicle control) receive role-specific workshops.
Security updates and tooling changes are continuously shared through mandatory monthly security briefings. Training completion is tracked, and participation is required before major design reviews or implementation sprints.
1.3 Design Processes
The SDL mandates the following processes during design:
- Formalized threat modeling using STRIDE and attack trees
- Design documentation reviews including architecture and security walkthroughs
- Definition and validation of ship criteria before implementation
Each component is required to complete a signed security checklist, and no design progresses to implementation without explicit sign-off by the security advisor.
1.4 Secure Programming Languages
Design choices prioritize the use of memory-safe or strongly typed languages:
- Rust for embedded and firmware components due to its memory safety and performance
- TypeScript for cloud-side components
- Python (with sandboxing) for AI experimentation with runtime constraints
Legacy C/C++ code is only used in performance-critical areas and is tightly encapsulated. All such components require manual code audits and additional fuzz testing.
1.5 Tooling
Security tooling is integrated early into design validation:
- Threat modeling tools (e.g., Microsoft Threat Modeling Tool)
- Architecture diff tools to detect unreviewed changes
- Code linting and design rule enforcement using custom design-time checks
All tools used in design documentation or modeling are vetted by the security team and tracked for compliance.
1.6 Zero Trust Architecture
Project Interstate follows Zero Trust principles from design:
- No implicit trust between services or layers
- All requests are authenticated and authorized contextually
- Network segmentation isolates critical services (e.g., vehicle control, firmware update modules)
- Continuous risk evaluation is built into the runtime policy engine
Each component must operate under the assumption that breaches are possible. Systems are designed to fail safely, maintain audit trails, and support forensic analysis.
2. Code
2.1 Secure IDE Environment
Developers work in a controlled environment using VSCode Enterprise, where all extensions are reviewed and signed by the internal security team. Workstations are protected with endpoint detection and response (EDR), ensuring only authorized tools and binaries can run.
Code changes are only committed from secure devices and are signed with hardware-based physical keys (e.g., YubiKeys). Access to source code is gated by device trust, and telemetry logs all developer activity.
2.2 Trusted Tools
The development pipeline restricts tools to those validated by the central security team. CI/CD systems are containerized, isolated, and hardened. Build artifacts are reproducible and signed.
Developer environments use signed toolchains and secure dependencies, and build systems verify tool integrity before execution. Any deviation triggers alerts and blocks builds.
2.3 Risk-Aware Coding Practices
All code interfacing with control systems or firmware undergoes strict reviews. Special attention is paid to API endpoints and code that bridges decision logic and driving components, ensuring:
- All inputs are validated at ingress
- Critical actions require redundant checks and command signatures
- Firmware interaction is sandboxed or isolated from non-critical systems
These pathways are fuzz-tested and manually reviewed with attack modeling techniques.
2.4 Credential Hygiene
Hardcoded credentials are forbidden. Developers use short-lived, scoped tokens obtained via secure vaults. Secrets are rotated automatically, and access is monitored for anomalies.
Sensitive variables are never written to logs or error messages. Debugging interfaces are disabled in production builds.
2.5 Dependency Management
All third-party packages and libraries are scanned continuously using OWASP Dependency-Check and Snyk. Vulnerable or outdated packages block builds and trigger automated patch workflows.
Transitive dependencies are tracked and visualized. Critical systems avoid deep dependency trees and prefer verified, minimal packages.
2.6 Insider Risk and Least Privilege
Code repositories and development infrastructure implement granular access control:
- Git access is role-scoped and logs all interactions
- Branch protection enforces signed commits and PR approvals from security reviewers
- Sensitive modules (e.g., vehicle control, firmware updater) require two-person approval to merge
Access policies follow a least privilege model, and all roles are reviewed quarterly.