"Shift-everywhere" security is beginning to take hold in corporate America as organizations move to fortify their software supply chains, according to the latest release of Synopsys' annual Building Security in Maturity Model (BSIMM) report.
"The [BSIMM13 findings] demonstrate that BSIMM member organizations' software security initiatives are maturing, and they're now looking for ways to drive the scalability, efficiency, and overall effectiveness of their programs," Synopsys software integrity group general manager Jason Schmitt said in a statement.
Now in its 13th year, BSIMM is managed by Synopsys, an integrated systems design company. The model draws on interviews during a BSIMM assessment of more than 130 member organizations. Each year, BSIMM analyzes the security practices of more than 130 organizations (including Adobe, PayPal, and Lenovo) and their cumulative efforts to protect their collective 145,000-plus applications. After each assessment, the data is anonymized and added to a data pool where it is analyzed statistically to highlight trends about how the BSIMM companies are securing their software.
This year, BSIMM reports an overall increase in member organizations' activities aimed at automated and continuous security testing throughout their software development lifecycle (SDLC) and managing risk across their entire application portfolios. The findings also demonstrate an evolution in how enterprises approach security.
"The BSIMM13 findings suggest that with the attention placed on software supply chains, most enterprise organizations are taking a risk-based approach to application security," said Schmitt. "Such an approach recognizes that security isn't limited to the codebase. It includes the process of software development where security reviews and testing 'shift everywhere' to continuously improve security outcomes."
A Holistic Approach from Left to Right
Last year, product teams were observed embracing the "shift-left" mantra, while this year organizations are investing in security scanning throughout the SDLC, said Forrester senior analyst for security and risk Janet Worthington.
"For example, development organizations are implementing software composition analysis (SCA) in the pre-release phases—design, development, and test—because components can be introduced at different times," said Worthington. "And these same teams are implementing SCA in production because new vulnerabilities are always being disclosed."
Developers are developing everywhere, so it makes sense to shift security everywhere, said Jamie Boote, associate principal consultant for the BSIMM13 report.
"Now that we're moving into agile and DevSecOps, everything is happening everywhere," said Boote. "So shift everywhere is a way to test everywhere that it makes sense to test."
"That means that some activities are actually shifting right," he continued. "For example, a good time to secure API calls may be with a production control."
Caroline Wong, chief strategy officer at Cobalt Labs, has performed more than three dozen BSIMM assessments in the past. According to Wong, shift left wrongly assumes there's a linear set of steps involved in software development.
"These days, the linear set of steps often happens so quickly and so frequently that rather than a phased process from left to right, the model might be more accurately described as 'everything everywhere all at once," said Wong. "Shift everywhere makes sense and implies that it’s important to conduct security activities at every stage of the software development lifecycle."
Secure software development is a complex beast with many moving parts, explained Mike Parkin, senior technical engineer at Vulcan Cyber, a cyber-risk remediation SaaS firm. As such, the process bears simplification.
"By taking a shift-everywhere approach, the entire process moves to a more secure model," said Parkin. "It’s a more holistic approach and lets an organization adapt to a new system all at once rather than in a piecemeal form."
Daniel Kennedy, research director for information security and networking at 451 Research (part of S&P Global Market Intelligence), added that even companies that have effectively shifted left need to shift right, too.
"There are always vulnerabilities that leak through or where the risk of their presence has been balanced against delivery needs and accepted," said Kennedy.
Kennedy explained that denial-of-service attacks, brute-force attacks, screen scraping, and many other problems aren't necessarily addressed by the security quality of the code in an application. He also pointed out that open-source security vulnerabilities that weren't known when the library was first leveraged may be discovered in production.
"Shift-right technologies allow an organization a way to address some of the problems unique to the production environment—as well as create breathing room for correcting things that are part of the code or infrastructure as code," said Kennedy.
QA Invited to the Security Party
As part of their efforts to shift everywhere, organizations have made significant progress integrating security options into CI/CD pipelines and developer tool chains over the last 12 months. BSIMM13 reports 48% year-over-year growth in activities that enable organizations to include security tests in QA automation.
"QA time can be the perfect time for some tests to identify risk, so it makes sense to put them there," said Boote.
According to Forrester's Worthington, when product teams extend their automated quality tests by incorporating security tests into that process, they can benefit from economies of scale, reduce manual effort, and create tighter feedback loops.
This integration also helps address the common problem that organizations face of seeing the same types of security vulnerabilities pop up over and over again.
"Integrating known, previously found security-vulnerability testing into QA is a clever way to reduce the number of future instances of any previously observed vulnerability types," pointed out Wong.
Moving security into QA is also an acknowledgment by security teams that they need to delegate some day-to-day security testing to teams outside security, Kennedy added. "If a series of tests are being run against an application, including a DAST scan alongside of that can make sense for many organizations," he said.
He cautioned, however, that sometimes non-security teams may lack the specific security knowledge needed to properly interpret results is lacking in others. Accordingly, some care must be exercised in how security is implemented so that people don't get frustrated and drop the security scanning parts of the testing altogether.
"The painful realization here is that there’s much room for improvement in adding security checks to the QA process," said Vulcan Cyber's Parkin. "Security is a fundamental part of quality in software. While most QA programs are focused on 'make sure it works,' and many automated testing tools aren’t configured to test for security issues, it's good to see software vendors moving to include this functionality."
SBOMs
BSIMM13 also found that identifying and securing open-source software has become a top priority for its participating companies—and apparently for good reason. According to Eilon Elhadad, senior director for the software supply chain at cloud-security vendor Aqua Security, the traditional in-house approach to developing and updating applications—while great for visibility and control—is incompatible with modern time-to-market demands.
"Open-source software facilitates rapid development and release cycles," said Elhadad. "It enables organizations to incorporate ready-made components into their application stack so they can quickly release software. As the pace increases, so does the need for open-source software. Today, even a weekly build can pull in numerous open-source components."
That creates problems, though, since tracking dependencies for applications is extremely complex and near impossible to do manually, explained Elhadad. Every application has dependencies—and the only way to understand those is to have a software bill of materials (SBOM).
"SBOMs enable organizations to identify and track all third-party components—in particular open-source components—and comply with licensing requirements," he said. "It also helps ensure that the organization does not run vulnerable open-source components and keeps track of critical updates and patches. It helps organizations utilize open-source components as needed while maintaining security and compliance."
BSIMM13 noted a 51% increase over BSIMM12 in activities associated with controlling open-source risk over the last 12 months—as well as a 30% increase in organizations building and maintaining an SBOM to fully catalog the components within their deployed software.
Indeed, security teams need to know what they are defending so that they can quickly understand their risk and what they need to do when vulnerabilities are discovered, said Sounil Yu, CISO of cyber-asset management vendor JupiterOne. To this end, SBOMs foster efficiency, agility, and even transparency.
"Without an SBOM, the timeline for fixing those vulnerabilities can stretch into months or years, because security teams have to wait for notification from each supplier," said Yu. "Many organizations do not have either mature or modern software development practices and the requirement to produce an SBOM exposes that deficiency."
Because of the transparency that SBOMs create, said Yu, producers are going to be reluctant to produce SBOMs—while consumers will want them.
"The ability to produce an SBOM is highly correlated with the modernity and maturity of a producer's software development practices and technology stack," said Yu. "Whether their SBOM is shared with me or not, just having the ability to easily produce one gives me, as a consumer, a higher level of confidence that their software development practices are modern or mature enough to counter a wide range of common issues related to vulnerable or poorly maintained software."
Recommendations
Whether an organization has a mature software security program or is just starting one, BSIMM13's authors recommend the following:
- Put automated software-security tools in place to remedy defects and identify vulnerabilities
- Use data to drive security decisions and create and enforce software-security policies
- Move toward automating security testing and decisions—and away from labor-intensive manual approaches
- Move to smaller, automated checks within the SDLC—replacing manual activities, such as pen-testing and manual code review, with smaller and faster pipeline testing
- Create a comprehensive SBOM as soon as possible.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
