[ISM] SecDevOps practices:

SecDevOps practices are used for application development.

[SSDF] Compliance as code: Secure development environments (SSS-02-02-02)

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.

[SAMM] Secure and isolate sensitive application secrets (SSS-02-02-02-01)

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.

Operations

ID Operation Description Phase Agent
SSS-02-02-02-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-02-02-02-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-02-02-02-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-02-02-02-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

References

Industry framework Academic work Real-world case
Information Security Manual (ISM-1780)
NIST Secure Software Development Framework (PO.5.1)
OWASP SAMM: Software Assurance Maturity Model (I-SD-1-B)

[SLSA] Build platform-isolation strength-Hosted (SSS-02-02-02-02)

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.

Operations

ID Operation Description Phase Agent
SSS-02-02-02-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-02-02-02-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-02-02-02-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

References

Industry framework Academic work Real-world case
Information Security Manual (ISM-1780)
NIST Secure Software Development Framework (PO.5.1)
SLSA Supply-chain Levels for Software Artifacts (Level 2,3. Build platform-Isolation strength-Hosted)

[SLSA] Implement isolated build platforms for secure environment segregation (SSS-02-02-02-03)

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.

Operations

ID Operation Description Phase Agent
SSS-02-02-02-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-02-02-02-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-02-02-02-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-02-02-02-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-02-02-02-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

References

Industry framework Academic work Real-world case
Information Security Manual (ISM-1780)
NIST Secure Software Development Framework (PO.5.1)
SLSA Supply-chain Levels for Software Artifacts (Level 3. Build platform-Isolation strength-Isolated)