[ISM] Security headers:

[SSDF] Secure code access (SSS-01-07-01)

Secure all code forms—including source code, executable code, and configuration-as-code—using the principle of least privilege. Store code in a restricted-access repository, enforce version control and commit signing, conduct code owner reviews, and apply cryptographic protections. These measures ensure that only authorized personnel and tools can access or modify the code, safeguarding its integrity and preventing unauthorized access.

[SAMM] Protect application secrets and credentials (SSS-01-07-01-01)

Protect application secrets and credentials stored in configuration files and code to ensure compliance with the principle of least privilege and maintain production system security. Developers should not have direct access to production secrets. Implement mechanisms to safeguard secrets, such as assigning authorized personnel to add secrets to configuration files during deployment, adhering to the separation of duty principle, and encrypting all production secrets stored in configuration files and ensuring encryption-at-rest. Avoid storing production secrets in configuration files used for development or testing environments, as these typically have lower security postures. Additionally, ensure that sensitive credentials and secrets are not left unprotected in code repositories. Use purpose-built tools for secure storage and key management to enforce access controls, allowing only authorized personnel responsible for production deployments to handle these secrets. This approach minimizes the risk of unauthorized access and ensures the integrity and confidentiality of sensitive data.

Operations

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

References

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

[SLSA] Execute builds on isolated platforms (SSS-01-07-01-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-01-07-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-07-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-07-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

References

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

[SLSA] Enforce build platform isolation (SSS-01-07-01-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-01-07-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-07-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-07-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-07-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-07-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

References

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