The Five Most Common Software Security Activities in BSIMM12

An organisation that wants to make its software more secure has a long menu to choose from in the Building Security In Maturity Model (BSIMM), which lists many dozens of possible measures. Taylor Armerding, Security Advocate at the Synopsys Software Integrity Group, looks at which of them organisations actually adopt first.

The twelfth BSIMM report, published on September 28, describes 122 software security activities, also called controls, observed across 128 participating organisations. Those organisations came from several regions and nine verticals: financial services, FinTech, independent software vendors, IoT, healthcare, cloud, insurance and technology among them. The activities sit within 12 practices, which in turn fall under four domains: governance, intelligence, secure software development life cycle (SSDL) touchpoints, and deployment.

Borrowing loosely from George Orwell, Armerding notes that all the activities are useful but some appear to be more useful than others. For organisations at the start of their software security maturity efforts, BSIMM12 therefore offers a short list of the most widely adopted activities, which cover the fundamentals.

A description of practice that doubles as a roadmap

BSIMM describes itself as a measuring stick for software security initiatives (SSIs), and it is also the basis of an annual report, unusual in the field, that follows how software security programmes develop over time. The model is descriptive. It does not instruct organisations; it records what they are doing in close to real time and leaves each one to judge what suits its own SSI.

Armerding argues that this makes it useful as a roadmap as well. Although the model, the data collection and the yearly reports are all based on observation, the historical data can be used to set out, and in effect recommend, how an SSI is established and developed until it becomes mature and effective for the organisation concerned. As with a road map, more than one route leads to the same place.

So the five most common activities in BSIMM12 will not necessarily suit every organisation. Still, when nearly everyone adopts something, there is usually a reason, and all five are regularly found in highly successful SSIs.

Jacob Ewers, principal consultant with the Synopsys Software Integrity Group and a co-author of BSIMM12, attributes their popularity to the fact that hundreds of capable practitioners have put them in place in almost every SSI the team has examined, so organisations that ignore that experience are likely missing something they ought to do. The same five have held the top positions for four years, which, according to Ewers, shows they apply widely and add value to programmes of every size, shape and level of maturity. He stops short of saying every firm must adopt them. "If you're not doing them, it's worth investigating why," he said.

The five activities

Armerding presents the list as a kind of starter kit. Each activity is shown with its place in the BSIMM framework, domain first and practice second.

1. Implement life cycle instrumentation and use it to define governance

Governance: Strategy and metrics

Software security leaders are moving decisively towards risk-based controls across their whole software portfolio, so that development teams can find and fix flaws and defects earlier in the software development life cycle (SDLC). Some form of this activity is in place at 92% of BSIMM12 participants. Secure life cycle processes build security into an application proactively throughout its development. Put simply, proponents of life cycle instrumentation weave software security closely into development by gathering data at different points of the SDLC and using it to set and enforce security policies.

2. Ensure host and network security basics are in place

Deployment: Software environment

The report compares attempting software security without host and network security to putting shoes on before socks. Among participants, 91% make sure these basics are covered across their data centres and networks, a sign that they see the need for a solid foundation.

3. Identify PII obligations

Governance: Compliance and policy

Many organisations rightly rank the protection of personally identifiable information (PII) among their highest priorities. In BSIMM12, 89% of participants identify their PII requirements and 43% have also compiled a PII inventory. Armerding points out that moving workloads to hosted environments such as the cloud does not reduce PII obligations and can make it harder to recognise all of them. Organisations need to know where PII is held and stop it from being disclosed without authorisation.

4. Perform security feature review

SSDL touchpoints: Architecture analysis

Organisations that take security seriously build their architecture analysis around a review of security features. Such a review might reveal, for instance, a system open to privilege escalation attacks or a mobile app that wrongly stores PII locally. This activity is practised by 88% of BSIMM12 participants.

5. Use external penetration testers to find problems

Deployment: Penetration testing

Internal software security champions may raise warnings that nobody acts on. External penetration testers, on the other hand, can show an organisation plainly that it has security weaknesses too, something 87% of participants have accepted.

Gaps in static analysis, and a shift to automation

Ewers named one surprise that concerns him. Although static application security testing (SAST) tools are readily available and widely used, 20% of participants do not use automated tools for static analysis. He accepts that firms may have valid reasons to skip automated SAST, but advises against dropping code inspection altogether or depending only on manual review, which consumes a lot of resources.

On the whole, though, he finds it encouraging that almost all of the leading activities involve automation. That means security testing is getting much better at keeping pace with development, which is accelerating exponentially. Ewers expects automation of security work across the board to keep improving, and said that over time these efforts will need to be tied into measurement frameworks that support decisions and create feedback loops that improve themselves.