12 Bare-Minimum Benchmarks for AppSec Initiatives
The newly published Building Security in Maturity Model provides the software security basics organizations should cover to keep up with their peers.
September 23, 2020
![](https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/blteff40987ed1b73e1/64f0d2f493f10ef0488a5cf5/1.png?width=700&auto=webp&quality=80&disable=upscale)
As application security methodology and best practices have evolved over more than a decade, the Building Security in Maturity Model (BSIMM) has been there each year to track how organizations are making progress. BSIMM11, released last week by Synopsys, is based on the software security practices in place at 130 different firms across numerous industries, including financial services, software, cloud, and healthcare.
The practices were measured by the model's proprietary yardstick, which lumps 121 different software security metrics into four major domains: governance, intelligence, secure software development lifecycle (SSDL) touchpoints, and deployment. Each of these domains are further broken down into three practice categories containing numerous activities that slide from simple to very mature.
Similar to previous reports, BSIMM11 shows that most organizations are at the very least hitting the basics — including activities like performing external penetration testing and instituting basic software security training across development organizations. The following are the most common activities cited for each practice category, providing an excellent yardstick for the bare minimum that organizations should be doing to keep up with their peers.
Activity: Implement life cycle governance
One of the most common foundational activities in place at organizations is the implementation of life cycle governance, which includes conditions for release, such as gates, checkpoints, guardrails, and milestones. According to BSIMM11, 90% of organizations have implemented life cycle governance. And many organizations are going a step further and enforcing governance policies as well. For example, 47% of orgs also verify release conditions with measurements and track exceptions.
Activity: Identify PII obligations
Some 86% of organizations are able to wrap their arms around their regulatory requirements by identifying their obligations with regard to personally identifiable information (PII). That's the most common compliance activity, though just by a hair as 72% of organization are also unifying their views and practices across all regulatory standards. BSIMM11 shows that organizations are incrementally improving their compliance capabilities over time by also taking action on their obligations. The number of organizations that actively build a PII inventory to be protected within their app portfolio has risen by 10 percentage points in the past two years, up to 42%. Similarly, the percentage of organizations implementing and tracking controls for compliance rose to 47% from 36% over the same course of time.
Activity: Conduct security awareness training
Conducting some general form of security awareness training across an organization has become an industry norm for enterprise development organizations, though even this one isn't perfectly adhered to. According to BSIMM11, approximately 64% put their software stakeholders through at least an introductory course, even if it is tailored to specific audiences. Meantime, role-specific training is common, though not prevalent, with 29% of organizations engaging in this activity.
Activity: Create a data classification scheme and inventory
Most software organizations today are operating at fairly low levels of maturity when it comes to threat modeling, developing abuse case stories, and generally thinking like an attacker. Just over 63% of organizations are able to do the bare minimum in this regard, according to BSIMM11, namely by creating a data classification scheme and inventory to start prioritizing application importance or risk levels based on the data stored and attractiveness to attackers. Meanwhile, just 8% organizations build attack patterns and abuse cases tied to potential attackers -- a ratio that has held steady over the past couple of years.
Activity: Integrate and deliver security features
To satisfy the need for security repeatability, many organizations have embraced the practice of providing proactive guidance and code to provide preapproved security features that offer functions in building-block fashion, such as authentication, role management, and cryptography. That way, developers needn't reinvent the wheel every time they have to add these standard features to their projects. Approximately 78% of organizations engage in this AppSec activity, according to BSIMM11. There's still lots of room to grow when it comes to security features and design. For example, while many organizations provide these feature resources to dev teams, a scant 11% require use of approved security features and frameworks from an approved list or repository.
Activity: Translate compliance constraints to requirements
In recognition that developers are not compliance experts (not that they should need be), many security organizations today are taking the burden of interpreting things like PCI DSS standards into software requirements. Approximately 72% of organizations do this today, according to BSIMM11. Coming in a close second in this category by a whisker, just under 72% of organizations also create security standards to explain required ways to adhere to enterprise policies with regard to everything from performing identity-based authentication to how developer infrastructure should be configured.
Activity: Perform security feature review
Approximately 88% of organizations now perform some kind of security feature review of software developed in their organizations, according to BSIMM11. This is still usually the only thing that most organizations do to analyze their software architecture for security, but the industry is gaining ground on that one. Over the past two years, the percentage of organizations that perform design review of high-risk applications has bumped up by five points to 32%.
Activity: Use automated tools along with manual review
The DevSecOps movement and years of advocacy from security champions have driven a greater emphasis on automation to the code review process. Almost 77% of organizations now incorporate static analysis into the code review process for the sake of efficiency and consistency, according to BSIMM11. How the automation is used is still all over the map, with some building those automated checks into code management or delivery pipeline workflows. However, these tools are not being consistently enforced as a requirement. Only 38% of organizations make code review mandatory for all projects.
Activity: Ensure QA supports edge/boundary value conditioning testing
Code review is just the first step in a solid review of the security of deployed software. Additional security testing like black-box testing probes the vulnerabilities in the construction of the software. At a minimum, about eight in 10 organizations at least makes sure QA teams extend beyond functional testing to perform basic adversarial tests and probe simple edge cases and boundary conditions, according to BSIMM11. But there's still a lot of room to grow on many other fronts. For example, just 32% of organizations integrate black-box security tools into the QA process.
Activity: Use external penetration testers to find problems
At the very least, the majority of software teams at least check the box for penetration testing. Nearly 88% use external penetration testing to provide evidence of exploitable vulnerabilities in code and configuration, according to BSIMM11. Additionally, 77% use the findings from these tests by feeding them into defect management and mitigation systems, and 68% back up those external findings with red-team tests and other internally led penetration testing.
Activity: Ensure host and network security basics are in place
BSIMM11 found that the establishment of host and network security basics stand as the very most common software security action in play across all organizations. Approximately 93% of organizations ensure they've locked down the security of the data center and network assets that run their software because, as the report points out, "Doing security before getting host and network security in place is like putting on shoes before putting on socks."
Activity: Create or interface with incident response
While many organizations struggle to track and fix software bugs found in operations, at a minimum most (83%) have at least established some form of interface between developers and security incident responders, according to BSIMM11. Additionally, 78% also reported they identify software defects found through operations monitoring and feed them back into development. However, more advanced activities, such as running software incident response simulations using bug info identified by operations as a way to improve the secure software development life cycle, remain elusive. Only 8% engage in that activity.
Activity: Create or interface with incident response
While many organizations struggle to track and fix software bugs found in operations, at a minimum most (83%) have at least established some form of interface between developers and security incident responders, according to BSIMM11. Additionally, 78% also reported they identify software defects found through operations monitoring and feed them back into development. However, more advanced activities, such as running software incident response simulations using bug info identified by operations as a way to improve the secure software development life cycle, remain elusive. Only 8% engage in that activity.
As application security methodology and best practices have evolved over more than a decade, the Building Security in Maturity Model (BSIMM) has been there each year to track how organizations are making progress. BSIMM11, released last week by Synopsys, is based on the software security practices in place at 130 different firms across numerous industries, including financial services, software, cloud, and healthcare.
The practices were measured by the model's proprietary yardstick, which lumps 121 different software security metrics into four major domains: governance, intelligence, secure software development lifecycle (SSDL) touchpoints, and deployment. Each of these domains are further broken down into three practice categories containing numerous activities that slide from simple to very mature.
Similar to previous reports, BSIMM11 shows that most organizations are at the very least hitting the basics — including activities like performing external penetration testing and instituting basic software security training across development organizations. The following are the most common activities cited for each practice category, providing an excellent yardstick for the bare minimum that organizations should be doing to keep up with their peers.
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