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 centralized 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 centralized 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.