The implementation phase of the software development life cycle is, in many respects, the most important phase because this is where the software is built. It is of critical importance that this phase is executed with the goal of producing secure, functional and efficient software.

The OWASP Software Assurance Maturity Model (SAMM) provides a way for organizations to improve their ability to implement secure software. Within this model implementation is a business function that consists of three security practices:

The model provides a way to evaluate the maturity of the three practices and offers guidance on how to increase the maturity of each practice.

Secure Build

The secure build practice consists of two sub-practices or “streams ”: the build process stream and the software dependencies stream. Good security throughout the SDLC is built upon good software development practices. This is especially true of the build process. The build process should be formally described and repeatable. Anyone in the organization should be able to produce a successful build based on the formal description. A mechanism such as code signing should also be implemented, which can verify the integrity of the artifacts produced. Once the build process is repeatable, automation further removes human error. As part of the automation process, one should use automated security testing tools (SAST). The final step in developing a mature secure build process is to specify security checks, where a failed check results in a failed build. These checks will vary depending on the risk profile of the application being built.

The second stream in the secure build practice is software dependencies. Modern software development is heavily reliant on using third-party software to implement lower-level functionality. To ensure secure software, it is essential to ensure the security of the third-party components used to build that software. The first step in achieving this is to know which third-party components are present and in use within your software. By creating a software bill of materials (SBOM), one can track all components used in the software construction. The SBOM should contain, at a minimum, the name of the library used, its version and the license that the library was issued under. One should routinely check all libraries in the SBOM for known security issues. The SBOM should be updated regularly as components are added and removed from the software. Any issues found with any of the components should be treated like other issues found in the custom-built code. Failed security checks for the third-party libraries should cause the build to fail, just as failed security checks do for the custom-built code.

Secure Deployment

The second practice in the implementation business function is secure deployment, which consists of the deployment process stream and the secret management stream. The deployment process is similar in structure to the build process and is again based on good software development practice. The first step is to formalize the deployment process so that it is repeatable. Given a reliable specification, the process may then be automated—bringing all the benefits of automation to deployment. Automated security testing should be integrated into the automated deployment pipeline. Dynamic application security testing (DAST) should be performed here to detect any vulnerabilities present in the code, as well as test any security-related issues in the configuration of the deployed software. Finally, the integrity of the deployed code should be verified based on the signatures created during the software build.

Secret management plays an important role in the security of the deployed applications and breach prevention. It is necessary to have a clear separation between the secrets used in production and in testing environments. Developers should never have access to production secrets. Secrets should be stored and encrypted outside of code and configuration files to prevent their exposure through source code repositories. One can leverage automated tools to inject secrets into configuration files when needed in the production environment. Some tools can scan source code repositories to detect leaked secrets. When secrets are detected, they should be revoked and removed from the repositories. Finally, one should perform secret life cycle management. There should be a mechanism that provides for the efficient rotation and decommissioning of secrets. All access to secrets should be logged in a central location and reviewed to detect suspicious behavior.

Defect Management

The third practice in the implementation function is defect management. This consists of defect tracking, as well as metrics and feedback. The defects tracking practice aims to integrate security issues found during the testing and production phases into the organization’s standard defect tracking system. All found security issues should be classified in a consistent way across the organization and should have associated SLAs based on the classification given. One should also implement an automated alerting system to alert relevant stakeholders whenever the SLA for a given issue is violated. An exception process can require signoff for the cases where the risk is acceptable to the business.

An essential part of defect management is the ability to measure the performance of the organization in handling found security issues. To do this requires developing metrics and feedback that accurately measure performance against the security goals of the organization. Metrics such as time to detect, time to resolve, SLA violations, number of regressions and windows of exposure on live systems can give useful information for improving the defect management process. One should conduct regular reporting on these metrics and drive information sharing regarding the types and severities of vulnerabilities found. These metrics can optimize the overall security strategy. They may indicate the necessary changes during testing, the frequency of testing and the training that the developers receive with respect to certain types of vulnerabilities. The chosen metrics should be reviewed on a regular basis to ensure that they provide the necessary information to improve the overall security process.

Getting security right in the implementation phase of the SDLC is crucial for producing secure software systems. The OWASP Software Assurance Maturity Model (SAMM) provides a set of practices, as well as a means of measuring the maturity of those practices, which help organizations get security right. Any organization interested in implementing secure software should consider adopting this model as part of their software development practice.