12 AppSec Activities Enterprises Can't Afford to Skip
The latest Building Security in Maturity Model (BSIMM9) report offers a statistically backed, bare-minimum benchmark for software security initiatives.
October 5, 2018
![](https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/bltf2c28b0868c9e9c2/64f0d58e51fd69760dd7da60/01-everyone.jpg?width=700&auto=webp&quality=80&disable=upscale)
Awareness continues to build for application security, the toolsets are evolving, and more organizations than ever have changed at least some of their processes to account for designing security into software. But the fact is that huge challenges still remain in delivering more secure software.
"The technology is often hard to use, introduces friction in automated processes, requires headcount to achieve the desired effectiveness, and improves much more slowly than software evolves. From a consumer perspective, the vendor marketplace is fragmented," says Sammy Migues, principal scientist for application security firm Synopsys. "Moreover, processes are in constant flux. There is debt in nearly every organization, with approaches built for waterfall ecosystems being molded into agile forms or DevOps shapes."
This industry condition provides the impetus for Synopsys' continuing drive to update the Building Security in Maturity Model (BSIMM), which endeavors to measure the use of major best (or, sometimes, bare minimum) practices in application security in use within large organizations. This week the firm released BSIMM9, which examines the use of 116 identified AppSec activities by 120 different firms. These activities are lumped into four major domains: Governance, Intelligence, Secure Software Development Lifecycle (SSDL) Touchpoints, and Deployment.
From there, they're further broken down into 12 major buckets of practice categories — this includes categories such as Strategy and Metrics, Attack Models, and Code Review. Each of these categories includes a number of activities that can be engaged in, from the very simple to the very complex and mature.
In examining activities with this context, BSIMM9 identified 12 activities that the majority of organizations typically engage in today. Most of them are very simple — meaning there's lots of room for improvement across the board — but they at least offer a glimpse into a simple benchmark for organizations as they look at their own internal practices.
"Although we can't directly conclude that these 12 activities are necessary for all software security initiatives, we can say with confidence that these activities are commonly found in highly successful initiatives," the BSIMM9 report states. "This suggests that if you are working on an initiative of your own, you should consider these 12 activities particularly carefully."
Activity: Identify gate locations and gather necessary artifacts
According to the BSIMM9 report, approximately 84.2% of organizations at a minimum identify where release gates or checkpoints for security design need to be placed within existing development processes. Unfortunately, most organizations do not currently use security gates to any great effect, with only about 35% of them actually enforcing gates with measurements and exception tracking.
Activity: Identify PII obligations
At the very least, the overwhelming majority of organizations specifically identify a list of the different regulatory obligations they have to protect personally identifiable information (PII) within data stored and manipulated by their software. Around 84.2% of organizations identify these PII obligations today. The trouble is that simply doing this is like toeing the starting line when it comes to protecting PII in software. Most organizations don't go any further than that. Only about 32.5% of them actually identify PII data inventory to be protected within an application, and just 35.8% implement and track controls for compliance.
Activity: Provide awareness training
In order to promote a culture of software security throughout the development organization, about 66.7% of organizations run at least some kind of broad-based awareness training, either via external or internal training programs or through e-learning. The trouble is that most of that training is still not tailored to the groups that need it. Just 28.3% of organizations deliver role-specific education for different populations, such as developers, QA engineers, and project managers. More troubling, when more advanced curriculum is made available, they're not providing incentives for software delivery teams to take it. A scant 3.3% of organizations reward progression through curriculum.
Activity: Create a data classification scheme and inventory
Approximately 62.5% of organizations come to an agreement on a data classification scheme and use it to inventory the kinds of data their software handles. The idea behind this is to prioritize application importance or risk levels based on the classified data stored or manipulated within. For many organizations, that's about as sophisticated as they get when it comes to modeling and prioritizing software to direct security design. Only 31.7% of organizations do anything to identify potential attackers of their software, and approximately 44.2% use attack intelligence in any way. Even worse, a slim 8.3% of organizations build attack patterns and abuse cases tied to potential attackers.
Activity: Build and publish security features
A large majority of organizations recognize the need for security repeatability. As such, they develop cookie-cutter security features, such as authentication, role management, key management, audit/log functionality, and cryptography protocols, for developers to use in their software. Just under 80% of organizations build and publish these kinds of security features. While these features may be present, their use is still mostly aspirational — a rare 7.5% of organizations require the use of approved features and frameworks, or even have a review board to approve and maintain secure design patterns.
Activity: Create a security portal
Approximately 65% of organizations establish a well-known, central location where everyone can get information about software security. This is usually an internal reference website developed by the software security group. Additionally, about 62.5% of organizations create security standards to place within that portal. Whether anyone actually pays attention to these standards is another question. Just 8.3% of organizations use secure coding standards to guide their development practices.
Activity: Perform security feature review
About 84% of organizations perform some kind of security feature review of software developed in their organizations. This is a good start, but for many organizations it's the only thing they do to analyze software architecture for sound security. Only about 27.5% of organizations today perform design review of high-risk applications, and just 12.5% of organizations define and use an architecture analysis process.
Activity: Have software security group perform ad-hoc review
Just over 68% of organizations have their software security group perform ad-hoc code review of software in development. This is typically done for high-risk applications done in an opportunistic fashion. Only about a third of organizations make code review mandatory for all projects, and very few take a systematic approach to reviewing code.
Activity: Ensure QA supports edge/boundary value-conditioning testing
The good news is that about 83% of organizations ensure that their QA teams goes beyond functional testing to perform basic adversarial tests and probe simple edge cases and boundary conditions. However, beyond that, security testing is still very immature. Only a quarter of organizations integrate black-box security tools into the QA process, and just 10% of organizations include security tests in QA automation.
Activity: Use external penetration testers to find problems
The majority of software security groups use penetration testing to offer up evidence of the inherent attackability of software that has already been deployed. Approximately 87.5% of organizations use external pen testers to find problems. However, they're often using them to just scratch the surface of software. Only 8.3% of organizations use external penetration testing to perform deep-dive analysis.
Activity: Ensure host and network security basics are in place
Nearly 87% of organizations do their due diligence to ensure that host and network security basics are in place to provide a solid foundation for the software that operates in these environments. But more advanced practices – such as orchestration for containers and virtualized environments, developing application inventories with operations bill of materials, or even ensuring cloud security basics – were pretty much nonexistent in the 120 organizations studied for this year's report.
Activity: Identify software bugs found in operations monitoring and feed them back to development
Most organizations — 85% — identify software defects found in operations monitoring and feed them back to development. However, those defects are more often than not left to sit on the development team's desk. Only about 4.2% of organizations fix all occurrences of bugs found in operations. And they don't usually learn from these mistakes. Only 5.8% of organizations enhance their SSDL to ensure that developers don't make those same coding mistakes in the future.
Activity: Identify software bugs found in operations monitoring and feed them back to development
Most organizations — 85% — identify software defects found in operations monitoring and feed them back to development. However, those defects are more often than not left to sit on the development team's desk. Only about 4.2% of organizations fix all occurrences of bugs found in operations. And they don't usually learn from these mistakes. Only 5.8% of organizations enhance their SSDL to ensure that developers don't make those same coding mistakes in the future.
Awareness continues to build for application security, the toolsets are evolving, and more organizations than ever have changed at least some of their processes to account for designing security into software. But the fact is that huge challenges still remain in delivering more secure software.
"The technology is often hard to use, introduces friction in automated processes, requires headcount to achieve the desired effectiveness, and improves much more slowly than software evolves. From a consumer perspective, the vendor marketplace is fragmented," says Sammy Migues, principal scientist for application security firm Synopsys. "Moreover, processes are in constant flux. There is debt in nearly every organization, with approaches built for waterfall ecosystems being molded into agile forms or DevOps shapes."
This industry condition provides the impetus for Synopsys' continuing drive to update the Building Security in Maturity Model (BSIMM), which endeavors to measure the use of major best (or, sometimes, bare minimum) practices in application security in use within large organizations. This week the firm released BSIMM9, which examines the use of 116 identified AppSec activities by 120 different firms. These activities are lumped into four major domains: Governance, Intelligence, Secure Software Development Lifecycle (SSDL) Touchpoints, and Deployment.
From there, they're further broken down into 12 major buckets of practice categories — this includes categories such as Strategy and Metrics, Attack Models, and Code Review. Each of these categories includes a number of activities that can be engaged in, from the very simple to the very complex and mature.
In examining activities with this context, BSIMM9 identified 12 activities that the majority of organizations typically engage in today. Most of them are very simple — meaning there's lots of room for improvement across the board — but they at least offer a glimpse into a simple benchmark for organizations as they look at their own internal practices.
"Although we can't directly conclude that these 12 activities are necessary for all software security initiatives, we can say with confidence that these activities are commonly found in highly successful initiatives," the BSIMM9 report states. "This suggests that if you are working on an initiative of your own, you should consider these 12 activities particularly carefully."
About the Author(s)
You May Also Like
CISO Perspectives: How to make AI an Accelerator, Not a Blocker
August 20, 2024Securing Your Cloud Assets
August 27, 2024