BSIMM: Top five software security activities that create a better software security initiative

Looking to build trust in your software? Start with BSIMM12’s top five software security activities.

BSIMM trends in software security activities | Synopsys

For any organization looking to improve the security of its software, Building Security In Maturity Model (BSIMM) has dozens of options. Many dozens. 

The 12th iteration of the BSIMM report, released September 28, details 122 software security activities (also known as controls) that were observed in the 128 participating organizations. The organizations represented multiple geographies and nine verticals including financial services, FinTech, independent software vendors, IoT, healthcare, cloud, insurance, and technology. 

Those activities are grouped into 12 practices that are, in turn, grouped into 4 domains: governance, intelligence, secure software development life cycle (SSDL) touchpoints, and deployment.

But, to paraphrase George Orwell, although all activities are useful, some are apparently more useful than others. So, to help organizations start the software security maturity journey with the most fundamental activities, BSIMM12 provides a short list of the most popular. 

BSIMM12 report | Synopsys

Tracking the cutting edge of software security initiatives

BSIMM is a self-described measuring stick for software security initiatives (SSI). It’s also the subject of a unique annual report that tracks the evolution of software security program implementations. BSIMM is descriptive, not prescriptive. It doesn’t tell organizations what to do—it documents what organizations are doing in near real time and lets each organization decide for itself what will work best for its SSI. 

For that reason, it also functions as a roadmap to better software security. While the model, data gathering, and annual reporting are observational and descriptive, we can use the historical data to define—one might say, prescribe—how SSIs are instantiated and matured toward a destination. The destination is an SSI that is mature and effective for that organization. Of course, just as is the case with a physical roadmap, there are multiple routes to get to a destination.

All of which means that the five most popular activities observed in BSIMM12 may or may not be the best fit for each organization. But if everybody, or almost everybody, is doing them, there’s probably a good reason. Indeed, these activities are all commonly found in highly successful SSIs.

Jacob Ewers, principal consultant with the Synopsys Software Integrity Group and a coauthor of BSIMM12, said the top activities are popular because “hundreds of smart people have implemented them in nearly every SSI we’ve looked at. If you’re not learning from these organizations, you’re probably missing out on something you should be doing.”

And given that those activities have remained in the top five for four years now, Ewers said it shows they are “broadly applicable and valuable to programs of many shapes, sizes, and maturity levels. While we would not say that every firm should do these, if you’re not doing them, it’s worth investigating why.”

BSIMM top five software security activities

What follows could be viewed as a starter kit. The name of each activity is followed by where it’s listed under a domain and practice within the BSIMM framework.

1. Implement life cycle instrumentation and use to define governance

Governance: Strategy and metrics
Software security leaders are dramatically shifting to using risk-based controls across the entire software portfolio, enabling development teams to find and fix flaws and defects earlier in the software development life cycle (SDLC). A large majority (92%) of BSIMM12 participants have implemented some form of this activity.

92% of BSIMM participants have implemented risk-based controls | Synopsys

Secure software life cycle processes are proactive approaches to building security into an application throughout development. In essence, “life cycle instrumentation” advocates are working software security tightly into the application development process by collecting data at various stages of the SDLC and using that data to create and enforce software security policies.

2. Ensure host and network security basics are in place

Deployment: Software environment
As BSIMM12 puts it, “Trying to implement software security before putting host and network security in place is like putting on shoes before your socks.” Another large majority of participants (91%) show they realize the necessity of setting a good foundation for software security by ensuring that host and network security basics are in place across their data centers and networks. 

3. Identify PII obligations

Governance: Compliance and policy
Securing personally identifiable information (PII) is—as it should be—a top priority for many organizations. A full 89% of participants are identifying their PII requirements, and 43% also have built a PII inventory. It’s important to note that outsourcing to hosted environments like the cloud doesn’t relax PII obligations, and can even increase the difficulty of recognizing all associated obligations. Organizations should understand where PII resides and prevent unauthorized disclosure of PII.

89% of BSIMM participants have set their PII requirements | Synopsys

4. Perform security feature review

SSDL touchpoints: Architecture analysis
Security-aware organizations center their architecture analysis on a review of security features. Such a review would, for example, identify a system that was vulnerable to escalation of privilege attacks or a mobile application that incorrectly put PII in local storage. In BSIMM12, 88% of participants have implemented this activity.

5. Use external penetration testers to find problems

Deployment: Penetration testing
While warnings from internal software security champions may go unheeded, external penetration testers can clearly demonstrate to an organization that it isn’t immune to security weaknesses—a reality that 87% of BSIMM12 participants have recognized.

Ewers said one concerning surprise is that, given the availability and widespread use of static application security testing (SAST) tools, “20% of the participants aren’t using automated tools to perform static analysis. There are certainly valid reasons why firms might not do automated SAST, but we wouldn’t recommend completely forgoing code inspection or relying solely on a resource-intensive manual review.”

Moving to automation

Overall, however, Ewers said it is encouraging that just about all the top activities involve the move to automation, which means security testing is getting much better at keeping up with the exponential increase in the speed of development. 

“We’re getting better at automating security efforts across the board,” he said. “We can expect this to trend to continue, but over time these efforts must be hooked into measurement frameworks for decision support and self-improving feedback loops.”

Full details on BSIMM activities, trends, and takeaways are available in the latest report.

bsimm12-ad.jpg

 
Taylor Armerding

Posted by

Taylor Armerding

Taylor Armerding

Taylor Armerding is an award-winning journalist who left the declining field of mainstream newspapers in 2011 to write in the explosively expanding field of information security. He has previously written for CSO Online and the Sophos blog Naked Security. When he’s not writing he hikes, bikes, golfs, and plays bluegrass music.


More from Managing security risks