Credit: ID 131802795 © Retrocoloring | Dreamstime.com
Security tools don’t have to be a frustration point for developers. Whether they are or not has to do with how much these tools have developers in mind, understanding the way developers actually work, their workflows and workloads and the kind of overflow of security alerts they are bombarded with.
Code warriors are busy people. But while many of us picture them coding away at the speed of light, meeting ever shortening times to market and pulling innovative products out of their magician-like hats, a great deal of developers’ time is unglamorously spent tracking open source vulnerabilities and attending to their remediation.
To free developers up to the kind of agile development we’re imagining, companies need to find ways to alleviate the pressures of security management placed on them. Companies need to adopt tools that not only detect open source vulnerabilities but also prioritize their severity and reduce the number of alerts that reach developers.
Automation and continuous monitoring tools will track open source usage and alert on vulnerabilities. But merely letting developers know of open source vulnerabilities will not suffice to get them to actually attend to them. Indeed, the pressures on development teams to up the pace of innovation along with the steady growth in open source consumption means that if open source security concerns are going to get heard and handled, SCA tools will need to step it up in accommodating developers’ pursuit of more secure coding.
Shifting security as far left as possible, the new generation of SCA tools include web advisor technology that provides developers with insight into open source components in the pre-selection stage before components are pulled and integrated into the code.
Early insight into open source components combined with the ability to set policies that block vulnerable components from entering the code does a fair amount to prevent costly, time-consuming, remediations throughout the development lifecycle. But it is not a solution fit for vulnerabilities that are added to the code, weighing on developers’ time and patience when they need to remediate them out later.
For that SCA technology needed to drill down deeper, uncovering the next layer of a vulnerable component’s use in the application. Sure enough, deeper investigation into the composition of vulnerabilities reveals that not all vulnerabilities were created equal.
Vulnerabilities can be either effective or ineffective, meaning they either receive calls to the proprietary product, therefore directly impacting the security of the code, or they don’t. Going one step beyond the mere binary of vulnerable/non-vulnerable, the diagnosis of vulnerable open source components as either effective or ineffective changes the face of security management.
By understanding which vulnerable components are effective, and which are not, developers can reduce their workload by 70 to 80%. According to our latest report on the state of open source vulnerability management, less than 16% of all vulnerabilities found in our beta test were effective ones requiring immediate attention and treatment, while 84% of vulnerabilities found did not require high priority alerting.
The ability to prioritize effective vulnerabilities over ineffective ones has been the ground shaking change that development teams have been waiting for and has been the practical answer to developers’ oversaturation with security alerts.
Taking proactive security measures requires understanding the makeup of your application and which open source components are actively putting it at risk. Prioritizing the effective vulnerabilities first will allow developers to attend to them in time and will enable code security to become an attainable goal in your organization. Until the next phase of open source security gets underway, the type of drill down that effective usage analysis technology offers is the only way to truly scale open source security.