Development, testing and production environments are segregated.
Ensure strict separation and protection across all environments involved in software development. For example, enforce multi-factor authentication, conditional access, and network segmentation and restrict connections and monitor continuously, with minimal direct human access and reduced use of production software in non-production settings; Maintain a zero-trust architecture, logging and auditing all operations, access attempts, and security controls; Proactively monitor for vulnerabilities is necessary to uphold robust environmental segregation and security.
Protect production secrets to prevent developers from accessing secrets or credentials for production environments. Implement mechanisms to safeguard these secrets, such as limiting access to authorized personnel using a separation of duties principle and encrypting production secrets stored in configuration files before deployment. Prevent leakage across environments to ensure that production secrets are never used in development or testing environments, as these typically have lower security standards. Avoid storing unprotected secrets in code repositories. Adopt secure storage practices- use encryption-at-rest for all sensitive credentials and secrets associated with production systems. Leverage dedicated tools for secure key and secrets management. Enforce access controls and implement rigorous key management protocols to ensure that only personnel authorized for production deployments can access sensitive data. These practices enhance environmental security, reduce risk exposure, and uphold the integrity of application configurations and credentials.
ID | Operation | Description | Phase | Agent |
---|---|---|---|---|
SSS-01-01-01-01-01 | Implement separation of duties for secret management | Ensure that only authorized personnel have access to add production secrets to configuration files upon deployment. Follow the separation of duty principle, where developers do not have access to production secrets, limiting access to those responsible for production deployments. | Deployment | Security teams, DevOps teams |
SSS-01-01-01-01-02 | Encrypt secrets in configuration files | Encrypt all production secrets in configuration files to prevent unauthorized access. Do not store plaintext secrets in configuration files, especially in development or testing environments, as these environments often have lower security standards. | Development | Security teams, IT Operations |
SSS-01-01-01-01-03 | Avoid storing secrets in code repositories | Prohibit the storage of unprotected secrets in code repositories to prevent potential exposure. Use a dedicated tool for managing secrets securely, ensuring that sensitive credentials and secrets are encrypted and not accessible through version control systems. | Development | DevOps teams, Security teams |
SSS-01-01-01-01-04 | Secure key management for access control | Implement encryption-at-rest for all sensitive credentials in production systems and handle key management securely. Restrict access to keys to only those personnel responsible for production deployments, maintaining strict access control to protect sensitive data. | Post-deployment | Security teams, Compliance officers |
Industry framework | Academic work | Real-world case |
---|---|---|
Information Security Manual (ISM-0400) NIST Secure Software Development Framework (PO.5.1) OWASP SAMM: Software Assurance Maturity Model (I-SD-1-B) |
All build processes must be executed on isolated, hosted build platforms operating on shared or dedicated infrastructure rather than individual workstations. This requirement enforces strict environmental segregation, aligning with the principles of zero-trust architecture and robust environmental protection. Examples of hosted build platforms include GitHub Actions, Google Cloud Build, and Travis CI.
ID | Operation | Description | Phase | Agent |
---|---|---|---|---|
SSS-01-01-01-02-01 | Select a hosted build platform | Use a hosted build platform, such as GitHub Actions or Google Cloud Build, on shared or dedicated cloud infrastructure instead of individual workstations. This ensures isolation and controlled access. | Preparation | Security Team, DevOps Team, Project Manager |
SSS-01-01-01-02-02 | Isolate hosted environments | Restrict builds from running on local development workstations by enforcing policies that only allow builds to start on the hosted platform. Regularly monitor build requests to confirm they originate from approved environments. | Development | Security Team, DevOps Team |
SSS-01-01-01-02-03 | Use digital signatures | Attach a digital signature to each build to certify its origin and prevent tampering, linking it to the hosted infrastructure. Use a secure key management system within the platform to handle digital signatures. | Development | Security Team, DevOps Team |
Industry framework | Academic work | Real-world case |
---|---|---|
Information Security Manual (ISM-0400) NIST Secure Software Development Framework (PO.5.1) SLSA Supply-chain Levels for Software Artifacts (Level 2,3. Build platform-Isolation strength-Hosted) |
Build platforms must enforce isolation to ensure that runs cannot influence each other, even within the same project. Isolation safeguards include preventing builds from accessing platform secrets, such as provenance signing keys, ensuring the integrity of the build provenance, ensuring builds that overlap in time cannot interact preventing issues such as memory manipulation across builds, provisioning ephemeral environments for each build preventing persistent influences between consecutive builds, mitigating risks of "cache poisoning" by ensuring outputs remain consistent regardless of cache usage, and restricting remote influence or interactions unless they are explicitly captured and audited as external parameters. These measures ensure robust separation and maintain the security and integrity of all development and operational environments.
ID | Operation | Description | Phase | Agent |
---|---|---|---|---|
SSS-01-01-01-03-01 | Ensure Secret Isolation | Configure the build platform to prevent builds from accessing platform secrets, such as provenance signing keys, to maintain the authenticity of the build provenance. This step ensures that secrets are fully isolated and inaccessible to build processes. | Development | Security Teams, Build Platform Engineers |
SSS-01-01-01-03-02 | Enforce ephemeral build environments | Provision an ephemeral, isolated environment for each build to prevent one build from persisting data or influencing subsequent builds. This guarantees that each build runs independently and does not retain any state after completion. | Deployment | DevOps Teams, IT Operations |
SSS-01-01-01-03-03 | Prevent concurrent build interference | Implement controls to ensure that builds running concurrently cannot affect one another. For example, prevent any shared memory access or other forms of cross-build influence to ensure each build is fully isolated, even if they overlap in time. | Development | Infrastructure Teams, Security Engineers |
SSS-01-01-01-03-04 | Safeguard against cache poisoning | Configure the build platform to prevent one build from injecting false entries into a shared build cache used by another build, ensuring consistent build outputs regardless of cache usage. This step protects against "cache poisoning" attacks. | Post-deployment | DevOps Teams, Security Analysts |
SSS-01-01-01-03-05 | Restrict remote influence | Ensure the build platform does not open services that allow remote influence on the build environment unless explicitly defined as external parameters in the provenance. This step prevents unauthorized remote access or control over the build process. | Development | Security Teams, Build Platform Engineers |
Industry framework | Academic work | Real-world case |
---|---|---|
Information Security Manual (ISM-0400) NIST Secure Software Development Framework (PO.5.1) SLSA Supply-chain Levels for Software Artifacts (Level 3. Build platform-Isolation strength-Isolated) |