Authored by: Taylor Armerding, Software Security Expert, at Synopsys Software Integrity Group
The goal of a Software Security Initiative (SSI) is to improve the security of every element of the software journey — designing it, building it, and maintaining it. That takes a combination of standards, policies, and metrics structured to fit the individual needs of an organisation and scaled around its staff, processes, and software portfolio.
And it takes people with the right skills and the appropriate authority to create, maintain, and improve an SSI.
Using BSIMM as a roadmap to a better software security initiative
The BSIMM, now in its 11th iteration, is designed to help organisations navigate the often-treacherous path of developing an effective SSI and serve as a free tool that measures its maturity once it’s created.
It does this through in-depth observations of the SSIs of participating companies — 130 for this year’s report — primarily in nine verticals and spanning multiple geographies.
The BSIMM never prescribes a set way to create and improve an SSI. Instead, it observes and reports on software security activities or controls (121 this year) that organisations are actually spending time and money to do.
The BSIMM has been described as both a measuring stick and a roadmap, not an instruction manual. Its observations yield useful information on how SSIs mature and are structured, including which individuals or groups are usually in charge of the major components of an SSI. The roles and responsibilities of those individuals and teams is the focus of this post.
Who is responsible for driving effective software security initiatives?
Indeed, if an organisation hopes to develop an effective SSI, it’s crucial to set priorities and make clear who is responsible for making those priorities a reality. This will empower and motivate those involved — any confusion over either or both will undermine the initiative and damage morale.
Through more than a decade of research, the BSIMM has found the following to be key players in a successful and effective SSI.
Executive leadership is the most critical role in software security initiatives, since the most successful security initiatives — those that achieve organisation-wide impact — are typically those with executive sponsorship. A senior executive in charge of security brings both accountability and empowerment to the initiative. And the roadmap function of the BSIMM means an executive can use it as a shortcut to measure and develop all aspects of an organisation’s SSI, since it gives a detailed look at what similar organisations are doing. It removes guesswork — the BSIMM provides actionable activities and practices that an executive can turn into processes and procedures that fit the organisation.
Software security group
A software security group (SSG) leader and the SSG itself are only slightly less critical to an SSI than the executive in charge. All of the 130 organisations surveyed for BSIMM11 have an active SSG in place. Its importance lies in its consistency and focus on security. Without an SSG, it’s unlikely that an organisation will be able to carry out all necessary BSIMM activities across a software portfolio. The BSIMM has found that more-mature SSGs include individuals with both coding and architectural skillsets.
The evolving role of SSGs
But SSGs are changing. Last year’s BSIMM10 was the first to document SSIs driven by engineering-led efforts — those originating bottom-up in the development and operations teams rather than top-down from a centralised SSG.
That means as software security initiatives evolve, the SSG might be entirely a corporate team, entirely an engineering team, or an appropriate hybrid.
For that reason, BSIMM11 has expanded the definition of the SSG. Rather than implying that it’s always centralised in corporate, the report now specifically acknowledges that SSGs may be a collection of people from corporate, engineering, and perhaps elsewhere.
Although members of the software security team are ideal SSG members, they can be hard to find, so the best alternative is to start with developers and teach them about security.
The responsibilities of SSG members include comparing and selecting security tools, defining secure design guidelines and acceptable remediation actions, and so on. In the spirit of agility, these individuals could also contribute significant amounts of code to delivery, including code that operates continuous build and integration, and code that goes beyond simply adding defect discovery steps to the pipeline. They could even implement security features or broader security architecture as part of the delivery team, as well as author orchestration or other infrastructure-as-code solutions for secure packaging, delivery, and operations.
Many software security initiatives have contributors — often developers, testers, or architects — who are interested in improving the organisation’s overall security. These individuals, known as satellites, security sponsors, or security champions, aren’t directly members of the SSG but they play a key role in increasing stakeholder and executive awareness, understanding, and support of current SSI activities and future needs and goals.
Satellite team members are sometimes chosen for software portfolio coverage, with one or two members in each product group, but they are sometimes chosen for other reasons such as technology stack coverage or geographical reach. Sometimes they’re more focused on specific issues such as cloud migration and IoT architecture.
For example, the satellite role is evolving rapidly in firms embracing DevOps and DevSecOps. These firms recruit members from cloud and related security-oriented roles and increasingly have them apply their expertise for everyone’s benefit.
And it’s clear that a strong satellite is a sign of a mature SSI. BSIMM11 found that 13 of the 15 firms with the highest BSIMM scores have a satellite group, with an average size of 269 people.
The report also noted that “the more-successful satellite groups get together regularly to compare notes, learn new technologies, and expand stakeholder understanding of the organisations’ software security state.”
Software security initiatives are a team effort
All other individuals in an organisation, even if they aren’t directly involved in security, are still instrumental in its success. For an SSI to be effective and to mature, it needs cross-departmental efforts and a variety of stakeholders, including:
Builders: This group includes developers, architects, and their managers, who must take at least some responsibility for both the definition of “secure enough” and ensuring that what’s delivered achieves it.
Testers: The main job of this group is to conduct functional and feature testing, but some also include a bit of security testing. More recently, some testers have started to anticipate how software architectures and infrastructures can be attacked and are working to find the right balance between automation and manual testing to ensure adequate security testing coverage.
Operations: Software security doesn’t end when software is shipped. That means operations teams must continue to design, defend, and maintain resilient environments for the life of a product. An increasing amount of security effort is becoming software-defined and happening in operations.
Administrators: This group needs to understand the distributed nature of modern systems, create and maintain secure builds, and begin to practice the principle of least privilege, especially when it comes to the applications they host or attach to as services in the cloud.
Executives and middle management: Business owners and product managers also must understand how early investment in security design and security analysis affects the degree to which users will trust their products. Any sizable business today depends on software to work, so software security is a business necessity.
The bottom line is that although an effective software security initiative requires leadership and clearly defined roles and responsibilities, software security is a team effort. These days it has to be, because even if you aren’t a software company per se, simply being in business means you are a software company. Your security, and success, depends on its security.