[ISM] Contents protection:

[SSDF] Secure tools and reliably sign executables (SSS-02-07-01)

Ensure that all compilers, interpreters, and build tools used in the application development process support features that enhance the security of executables. Use the latest versions of these tools, manage updates through a formal change management process, and verify the authenticity and integrity of each tool before use. By doing so, the development environment minimizes the risk of introducing vulnerabilities, and each executable file can be reliably signed, ensuring it originates from a secure and trusted build process. It emphasizes the importance of maintaining secure and trusted development tools to support the digital signing of executables.

[SAMM] Enforce a security baseline during build (SSS-02-07-01-01)

Define and integrate comprehensive security checks during the build process to validate the integrity of compiled executables. Tailor these checks to the risk profiles of applications, ensuring that only builds meeting predefined security thresholds are allowed to proceed. Establish systems to log and monitor warnings for issues below the threshold and centralize their tracking for action. Introduce exception handling mechanisms to bypass build enforcement only under documented approvals, ensuring rationales for such cases are logged and reviewed. For environments where automatic enforcement is not feasible, substitute with clear policies and periodic audits to maintain equivalent levels of assurance. Centralize code-signing operations on a dedicated server to protect certificates from exposure during the build. Adopt deterministic build methods where possible, ensuring consistent, byte-for-byte reproducible artifacts that minimize risks of tampering or unintended variations. These measures emphasize the importance of trusted tools and processes, supporting secure development environments and the integrity of deliverables.

Operations

ID	Operation	Description	Phase	Agent
SSS-02-07-01-01-01	Define security baseline for builds	Set build criteria such as no high-severity vulnerabilities in dependencies for high-risk applications, using tools like OWASP Dependency-Check.	Preparation	Security team, Development leads
SSS-02-07-01-01-02	Integrate security checks into build pipeline	Use tools like SonarQube for static analysis or Snyk for dependency scanning during builds in Jenkins or GitHub Actions.	Development	DevOps team, Security team
SSS-02-07-01-01-03	Enforce build failures for non-compliance	Fail builds with critical vulnerabilities but log warnings for medium-severity issues in tools like JIRA for future tracking.	Development	DevOps team, Security team
SSS-02-07-01-01-04	Implement an exception approval mechanism	Use a sign-off process in the defect tracking system for temporarily bypassing build failures due to known vulnerabilities.	Deployment	Security team, Product managers
SSS-02-07-01-01-05	Handle centralized code signing securely	Use Sigstore or a similar tool to ensure code signing keys are securely managed and artifacts are byte-for-byte reproducible.	Deployment	Security team, DevOps team

References

Industry framework	Academic work	Real-world case
Information Security Manual (ISM-1796) NIST Secure Software Development Framework (PW.6.1) OWASP SAMM: Software Assurance Maturity Model (I-SB-3-A)

[SLSA] Build platform-Provenance generation - Authentic (SSS-02-07-01-02)

Ensure all provenance attestations are verifiably authentic so consumers can trust their integrity and origin. The build platform’s control plane must generate the provenance and apply a digital signature using a private key only it can access. Consumers must be able to validate this signature to confirm that the provenance was not tampered with and to identify the trusted build platform. Use signing methods that enable rapid detection and remediation of key compromises (e.g., transparency logs or time-stamping). The build platform must prevent tenant tampering, though non-critical fields (e.g., artifact names, optional fields) may be tenant-provided.

Operations

ID	Operation	Description	Phase	Agent
SSS-02-07-01-02-01	Validate provenance authenticity	Ensure provenance attestations are digitally signed using private keys accessible only to the build platform. Verify signatures to confirm the attestation has not been tampered with post-build. Use this process to validate the identity of the build platform.	Post-deployment	Security Teams
SSS-02-07-01-02-02	Implement secure signing methodologies	Use signing methods that enhance security, such as transparency logs or time-stamping services, to detect and remediate key compromise effectively. Ensure signing keys are securely managed and access is restricted to the control plane of the build platform.	Development	Build Platform Engineers
SSS-02-07-01-02-03	Generate provenance in the control plane	Configure provenance generation within the build platform’s trust boundary. Ensure all critical provenance data is obtained directly from the build platform, preventing tenant-generated tampering or inaccuracies in provenance attestations.	Development	DevOps Teams
SSS-02-07-01-02-04	Prevent tenant tampering with provenance	Implement security controls on the build platform to deter tenants from altering provenance data. Ensure these controls are robust enough to reduce adversarial risks while maintaining compliance with trust and legal requirements.	Deployment	Build Platform Engineers
SSS-02-07-01-02-05	Review and secure exceptions	For exceptions, such as artifact names or cryptographic digests, ensure they are generated securely and align with defined guidelines. Regularly review and validate these exceptions to maintain overall provenance trustworthiness.	Post-deployment	Quality Assurance Teams

References

Industry framework	Academic work	Real-world case
Information Security Manual (ISM-1796) NIST Secure Software Development Framework (PW.6.1) SLSA Supply-chain Levels for Software Artifacts (Level 2,3. Build platform-Provenance generation-Authentic)