The pace of software development has kicked into high gear, with new versions being churned out at a breakneck pace. In hopes of shortening the development cycle, organizations are fast adopting the DevOps model which relies far more on automation, new practices, and of course continuous tools to help get the job done.
The DevOps model was established to improve coordination between the development and production teams, making the process of getting new software out the door faster and smoother. The rapid release of new updates to applications like we see from companies such as Netflix and Facebook has done a great deal to improve the user experience, providing them with better products, and changing our expectations for how a top notch software house should perform.
One of the ways that teams working with DevOps have achieved these results stems from a significant amount of “shifting left” various checks on the code and increasing visibility across teams for better efficiency.
While this shift to a more agile methodology has proved to have significant results in getting high quality releases out on tighter schedules, the question moving forward is how to keep the code secure?
There is now an understanding throughout the industry that securing the code should be a core business objective. This has led to DevOps’ evolution into the DevSecOps model that looks to integrate security practices into the DevOps tool chain.
Making this shift can be a scary endeavor for many organizations who had never quite succeeded in implementing security even before they moved to the faster DevOps model. Changing practices within your organization, while challenging, can actually help to overcome a number of important challenges, especially as they relate to prioritization.
Reducing Friction Between Development and Security Teams
There is already a lot of friction between security teams and developers, with security doing their hardest to get an already stressed engineering staff to address vulnerabilities that they are unable to see as directly affecting their product, and therefore not really worthy of their time and attention.
From the developer’s point of view, their first priority is pushing out a product that performs its basic functions without crashing. Security for them is an added bonus, but more often just an extra pain that slows down their release schedule.
However, in a DevSecOps model that uses the right automated tools, security does not have to come at the expense of sticking to the timeline. One of the tools that developers depend on for making their tight schedules are open source components. These components, which are written and maintained by the open source community and make up between 60-80% of the code base in modern applications, give developers the powerful features that they need for their products without forcing them to reinvent the wheel.
Unfortunately, developers do not have a practical way of manually keeping track of which open source components have known vulnerabilities before they add them to their products or monitoring said products post release when new vulnerabilities are reported. These oversights can have significant effects like we saw in the Equifax breach last September when hackers exploited a vulnerable version of Apache Struts 2 in the company’s web portal to steal the personally identifiable information belonging to over 145.9 million people.
The application security testing tools that they were using help protect their proprietary code were unable to catch this vulnerable component because only Software Composition Analysis (SCA) solutions are able to identify and alert on open source components with known vulnerabilities. To put it bluntly, they lacked the proper automated tools for the job.
Simply put, if a security team does not know which components they are using, and which ones are vulnerable, then they cannot direct their development team on what to patch or where.
Establishing Facts Based Prioritization Through Adoption of Automated Tools
Visibility is key element of DevSecOps and is invaluable for communicating to developers why remediating certain vulnerabilities should be prioritized. This is where automation can cut the amount of friction of having a security team member sitting on the development crew.
Using the right continuous, automated tools at the earliest, and even later stages of the DevOps tool chain can add improved visibility to the process and make the product’s code significantly more secure. Whether it is helping developers to choose the right components before they even make a pull request from open source repositories, using a selection tool like the Web Advisor to check if the component meets their organization’s policies for security, license compliance, and even quality, can help save time on remediations after the code has already been compiled.
Moreover, technology like WhiteSource’s Effective Usage Analysis can be a game changer for keeping code secure. According to our research into Java, 70% of vulnerable functionalities in open source components are not in fact effective, and therefore do not have a direct impact on their product. Practically, this means a 70% reduction in the scope of alerts that need to be addressed for remediation, making prioritization an easier task.
Automating this process of analyzing the open source components and presenting the data on a platform that is accessible for all participants of the DevSecOps tool chain to see can help to pass on the message of what is most important, providing evidence that remediations are really worth their time and effort.