Authored by: Taylor Armerding, Security Advocate, Synopsys Software Integrity Group
For any organisation 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 organisations. The organisations 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 organisations start the software security maturity journey with the most fundamental activities, BSIMM12 provides a short list of the most popular.
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 organisations what to do—it documents what organisations are doing in near real time and lets each organisation 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 organisation. 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 organisation. 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 co-author 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 organisations, 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.
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 realise the necessity of setting a good foundation for software security by ensuring that host and network security basics are in place across their data centres 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 organisations. 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 recognising all associated obligations. Organisations should understand where PII resides and prevent unauthorised disclosure of PII.
4. Perform security feature review
SSDL touch points: Architecture analysis
Security-aware organisations centre 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 organisation that it isn’t immune to security weaknesses—a reality that 87% of BSIMM12 participants have recognised.
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.