Accelerating Vulnerability Identification and Remediation
Rapid development and deployment cycles have long been criticized for the potential to introduce more flaws in software. But the “move fast and break things” adage doesn’t hold up in modern environments, which are increasingly being targeted by malicious actors. On the other hand, faster release cycles can also mean patches can be implemented faster — and this is just one factor that is accelerating the rate at which software teams can fix bugs.
As demand for reliable, secure software increases, a number of tactics and technologies have emerged to help teams build, maintain, fix, and secure their applications faster than ever. Approaches such as DevSecOps, bug bounty programs, open source bug reporting, and even Google’s Project Zero have had substantial influence on how we secure software. But if identifying and patching vulnerabilities has become easier, why are we still reading about so many breaches? Let’s explore.
The wide adoption of DevOps solutions and organization workflows, which we’ve seen in recent years, means faster release cycles of software. In the not-so-distant past, a software company would release an updated version every few months, which would contain fixes for security issues detected and patched in that period. Anything that wasn’t yet discovered or fixed would have to wait for the next release in another few months. With DevOps methodology and technology in place, software vendors and open source project maintainers release versions of their product dozens of times a day — when the fix is ready, the product receives it, cutting the time-to-fix dramatically.
Some organizations are going a step further to implement security into development processes. Research from ESG shows that 62% of organizations have a plan or are evaluating use cases for DevSecOps implementation. And those organizations that have already put these processes into place are seeing radical improvements in the speed at which they can identify and remediate vulnerabilities.
Bug bounty programs have also become mainstream. Some platforms allow software vendors to use the power of crowdsourcing to discover security issues in their own products. This flow must be managed with a dedicated framework for bug fixing. And as the discovery of issues grows, the organization is compelled to create better ways to fix them, and the time-to-fix is getting shorter.
Within the open source community, code management solutions such as GitHub, GitLab, and others have a built-in way to report and track security issues so that open source maintainers and users can easily report and follow vulnerabilities that are presented in an open source project. The information is public (on the public projects), and the maintainers and the community feel committed to fixing issues quickly.
A final factor is the impact made by Google’s Project Zero. As part of this initiative, Google has a team of security researchers dedicated to studying zero-day vulnerabilities in the hardware and software systems that are depended upon by users around the world. In 2021, Google’s Project Zero detected a record 58 zero-day vulnerabilities in the wild.
In addition, most software companies that are presented in Project Zero’s data set aren’t your ordinary software vendors, and the project forces these major tech companies to fix security issues within 90 days, which results in shifts in engineering culture and organizational structure as the engineering community at large emulates the big innovators.
Patches for software are often delivered via updates that require a consumer to upgrade to the latest version, a move which can often impact operations. Resolution in a timely manner can even be impossible, in some cases. Companies developing software today are often relying on a high percentage of open source code and many components that create complexity. Upgrading an open source library, which a company relies on throughout its codebase, or a specific version of a docker image, could mean substantial changes across its products. A single security fix might create a massive amount of work for engineering teams. As a result, teams must prioritize bug fixes, and only critical security issues are getting resolved.
Automation is key. It’s impossible for software consumers and vendors to deal with a large amount of security risk in large codebases without using an automated process for detection, remediation, and prevention. Prioritizing is also important. A small engineering team could easily find itself overwhelmed with all the potential security issues disclosed, but it usually doesn’t affect its software. To determine if applications are affected by security risks, companies need to take a comprehensive approach — from source code, throughout the DevOps pipelines releasing it, and through the production environment in the cloud. Connecting those dots helps engineers properly manage security risks in apps.
Companies should also employ technologies to assess the health and reputation of open source code. Factors to evaluate include quality, maintainability, popularity, and risk for supply-chain incidents. Automated security tools can play a role here as well by preventing risky code from entering the codebase and notifying developers of potentially dangerous packages. Also, employing a software bill of materials (SBOM) can provide transparency into the software components used in applications, accelerate the identification and remediation of potential vulnerabilities, and help achieve compliance with government regulations.
Copyright © 2022 Informa PLC Informa UK Limited is a company registered in England and Wales with company number 1072954 whose registered office is 5 Howick Place, London, SW1P 1WG.