The software development process has been shifting left due to the growing challenge of developing and delivering software releases faster and faster. Agile methodologies and new roles, such as Dev Ops, have been created as a result of this shift.
Shift left testing has been focused on testing your proprietary code, but what about your open source components? When are you making sure you are not using problematic licenses or if you have known security vulnerabilities in your product?
In this post, I’m going over everything you need to know about shift left practices in the agile development era and how you can shift left your open source auditing.
More than 10 years ago the typical development and QA cycle was organized around ‘base levels’. Developers would work on a base-level and when it was done, it was passed to QA. QA would test that base-level and feed the results back to the development team to fix. Then the cycle would be repeated as necessary.
Since it is easier and cheaper to fix bugs detected earlier in the process, new strategies of shifting tests earlier in the software development lifecycle were introduced to help identify issues as early as possible. Early detection accelerates the process of taking corrective steps, thus reducing the time and cost of fixing these issues. Shifting left, basically means shifting testing earlier as possible (to the left on the lifecycle axis).
Shift left practices are about integrating your testing into your software development process and thereby uncovering defects earlier when it is easier and less expensive to fix.
Larry Smith published an article, back in 2001, explaining how linking these two functions at lower levels of management can expand your testing program while reducing manpower and equipment needs. Testing, feedback, and revisions happen on a daily basis in shift left practice. This promotes agility and lets the project team scale their efforts to boost productivity.
We’ve addressed the issue of delayed discoveries in one of our earlier post. The Ponemon Institute concluded in a study that if vulnerabilities get detected in the early development process, they cost around $80 on an average. However, the same vulnerabilities can cost about $7600 to fix if detected during the production stage.
That’s a huge price. Also, it doesn’t even include the pressure of meeting (or missing) the release dates. As the software development stages progress, the cost of addressing any uncovered bugs also raises. Often exponentially.
Shift Left is all about uncovering as many issues as possible as early as you can in the software development process, so the cost of fixing them is under control and also to improve the quality of the shipped products.
By testing often, your team and stakeholders can remain aware of the current state of the code and make informed decisions throughout the project. But is shift left testing, in its traditional manner, enough today?
According to Forrester’s developer survey, four out of five developers say that they’ve used open-source frameworks or projects in applications that they have developed or delivered in the past 12 months.
This shows that open source is practically ubiquitous. It’s being used at scale by almost all commercial software companies. So why is the majority, if not all, of your shift left testing focused on your proprietary code? When are you auditing your open source components?
Large software companies use code scanning to know which open source licenses they are using and if there are any security vulnerabilities in their product. But code scanning is usually done in pre-release phase. The cost of discovering an issue at this stage is extremely high and it usually will lead to postponed releases. We offer an agile approach to open source management, by integrating into your build process and ‘auditing’ your open source components everytime you run your build.
There are two primary aspects you need to shift left in regards to open source:
Companies that use code scanning technologies, where you scan your code after the development stage, sometimes learn they are using a problematic component and need to replace it in a very late stage. This can cause significant delays in release and increase your project cost (just like identifying bugs before release). This can be easily solved by integrating open source management into your continuous integration processes with WhiteSource.
More than 4000 security vulnerabilities are discovered in open source projects a year and all you have to do is match your components to the discovered problematic components. In most cases, you will even have a patch released. All you need to do is find the issue as early as possible and update the version or release the component.
At what point in your software development lifecycle are you checking your open source compliance and ensuring you do not have security vulnerabilities in your product? And what are the main challenges that you face?