The yearly BSIMM (Build Security In Maturity Model) gives the industry great insight into how top performing companies wrap security into their software development processes. The latest BSIMM is the 10th yearly report and this year sees a much greater emphasis on automation when it comes to security. In this blog, we will look at BSIMM 10 and draw out the main points that show us how we can effectively increase our security assurance during the SDLC.
BSIMM 10, like the software industry, is reacting to the increased speed of software changes, and releases, facilitated by Agile, DevOps, Cloud, and other advances. To that end, BSIMM 10 talks a lot about how security needs to match the speed of software development, otherwise it will be left behind, or simply seen as a blocker. This is drawn out in the reference:
"To align better with DevOps values (e.g., agility, collaboration, responsiveness), SSI leaders are replacing traditional people-driven activities with pipeline-driven automated tasks. Often this comes in the form of automated security tool execution, bugs filed automatically to defect notification channels, builds flagged for critical issues, and automated triggers to respond to real-time operational events."
We see this often in security teams. While the tools involved in DevOps combine together in concert to take code changes through build, test, and release, security checks often involve a human element - either to do the checks manually, or to run the security tools and interpret the outputs.
Some security tools come with APIs to be wrapped into the DevOps suite of tooling, however many do not. We all know the great command line tools such as Nikto or SQLMap that can find vulnerabilities, however they need someone to run them. Given that the timeline from code change to release is measured in minutes or hours, this delay to get someone to run these tools disrupts the DevOps flow and means they are likely dropped or run infrequently.
An important part of DevSecOps is to make sure it scales to the needs of the organisation. A security team can focus security efforts on one application or project, likely the highest risk system, however as BSIMM shows, mature or maturing organisations will want DevSecOps to scale across all development and thus provide assurance for common regulations and sensitives data, such as PII or PCI checks
"In addition to incremental progress on the activities that security engineers have begun to define, engineering-led security efforts will also seek to apply what security engineers have delivered to one development team to the organization as a whole. This means documenting and sharing software process, extracting explicit organizational policies and standards from existing automation, and formalizing identification of data-driven obligations such as those due to PCI or to other PII use."
This is then further reflected in the trends the BSIMM researchers are seeing in the industry, which leads to their advice:
"The BSIMM focuses on the real-world “what” of software security, leaving the “how” and the “how much” to each organization and its unique culture, budget, resources, constraints, software portfolio, and business objectives. Generally, the how is trending toward automation, so it’s time to integrate an “automate first” strategy into your SSI, and the how much derives from consistently applying a clearly defined risk management approach that is connected to other organizational cybersecurity risk management initiatives (e.g., cloud, privacy, digital transformation)."
BSIMM 10 lists the following tasks for Level 2 and Level 3 in the Security Testing category. These maturity aspects show that the best organisations will look to combine automated security tools into the SDLC, along with specific technical aspects like fuzz testing of APIs, risk analysis of results, and coverage analysis of what testing is being run.
ST2.1 Integrate black-box security tools into the QA process
ST2.4 Share security results with QA.
ST2.5 Include security tests in QA automation.
ST2.6 Perform fuzz testing customized to application APIs.
LEVEL 3 :
ST3.3 Drive tests with risk analysis results.
ST3.4 Leverage coverage analysis.
ST3.5 Begin to build and apply adversarial security tests (abuse cases).
The research from the BSIMM team reflects the trends seen by professionals and vendors in the software and cloud security industry, including Uleska. This is why the Uleska Platform contains a number of features that help organisations quickly and efficiently improve and mature their software security. The Uleska Platform:
* Automates and orchestrates existing commercial and open source security tooling (including SAST, DAST, SCA, and others), along with extensibility for custom tools and scripts.
* Easily integrates with DevOps platforms to run security testing during build and QA phases, wrapping security checks in with QA.
* Integrates with popular SDLC communication and vulnerability tracking tools such as Jira, Slack, and others.
* Automatically analyses the business risk associated with vulnerabilities to aid prioritisation.
* Provides coverage analysis intelligence to let you know what security aspects your testing for, and which you are not covering.
* Easily scales to 100s of applications and systems, providing PCI, PII, and other regulatory coverage results through our easy to use UI and API.
You can find out more about BSIMM and download their latest report at https://www.bsimm.com/