While application security is certainly not a new domain or topic, it is increasingly cited as a priority among security and technology executives. There are many aspects to implementing effective application security. One key aspect is following secure software development practices for internal application development activities.
There’s an overarching inclination as an industry and ecosystem to “push security left” and implement a secure software development lifecycle. Part of doing that involves building secure software development practices as part of application development activities. However, for organizations early in this journey, it can be confusing to understand where to start and what to follow.
To help bridge that gap, we will discuss three leading frameworks intended to reduce the number of vulnerabilities created during software development. The three sources we will be looking at are OWASP’s Software Assurance Maturity Model (SAMM), Synopsys Building Security In Maturity Model (BSIMM) and NIST’s Secure Software Development Framework (SSDF).
OWASP Software Assurance Maturity Model
First on the list is OWASP’s SAMM. SAMM is broken down across five business functions: governance, design, implementation, verification, and operations. Each function includes three security practices, and each security practice contains three levels of maturity.
One of the major differences between SAMM and BSIMM is that SAMM is a prescriptive model, whereas BSIMM is descriptive. Therefore, SAMM prescribes specific actions and practices organizations can take to improve their software assurance. SAMM is an open-source framework, meaning it isn’t proprietary and can be contributed to by the community.
BSIMM
On the other hand, BSIMM is a descriptive study of software security initiatives across various organizations with differing levels of maturity. It compiles these findings and quantifies them as part of its annually published studies. BSIMM is on its 11th iteration and has over 130 contributing organizations, providing a richly diverse set of contributors.
Unlike SAMM or SSDF, which are open source, the BSIMM is a licensed model through Synopsys, formerly Cigital. This licensing model means that some of the underlying calculations and assessment questions across the security activities and domains are not made public. Additionally, organizations must work through Synopsys to get officially assessed with the BSIMM model and join the community of other organizations that have done so.
NIST SSDF
NIST’s SSDF, also known as NIST 800-218, provides a core set of secure development practices which can be integrated throughout the Software Development Lifecycle (SDLC). What’s unique about SSDF is that, unlike BSIMM or SAMM, SSDF doesn’t define its own unique practices, but instead pulls from existing secure software development guidance and sources such as BSIMM, SAMM, OWASP ASVS, and existing NIST guidance among others.
Much like BSIMM, while SSDF describes secure software development practices, it doesn’t prescribe how to implement them. This allows for a flexible and dynamic framework focused on secure software outcomes rather than specific implementation details. SSDF also takes a plain-language approach, making it a valuable tool for discussing secure development practices across communities of business owners/executives, software producers, and consumers.
SSDF’s practices are organized into four groups: preparing the organization; protecting the software; producing well-secured software; and responding to vulnerabilities.
Where To From Here?
While it is clear that more executive leadership across organizations are stating that secure application development is a priority, there has to be action associated with those claims. Not knowing exactly where to start is a problem for some, and that is where guidance such as SAMM, BSIMM, and SSDF can come into play.
The concern to mitigate software vulnerabilities also crosses the chasm from the private sector into the public sector. The recent Cybersecurity Executive Order (EO) included requirements for NIST to identify secure software development practices. That is where the underway improvements of their SSDF come into play, which included several workshops throughout 2020.
This existing and evolving industry guidance for secure software development, coupled with talking points from leadership, is promising. That said, it isn’t all sunshine and rainbows. Organizations are increasingly depending on open source software (OSS), and in recent studies by Harvard and the Linux Foundation, the average free and open source software (FOSS) developer-only spent about 2.3% of their time on improving the security of their code. Securing the open source software supply chain will be a topic for another discussion.
These problems aside, organizations should have a vested interest in producing secure and resilient software. Failing to produce secure software can have myriad ramifications, such as loss of customer trust, loss of revenue, and regulatory consequences. Utilizing the frameworks and guidance discussed above is a great start for any organization looking to improve the security hygiene of its software.
