Shifting left has been focused on testing proprietary code earlier. But at what point in the lifecycle are you checking your open source compliance and ensuring you do not have security vulnerabilities? If you shift this process left and perform it earlier in your software development lifecycle, just like with testing, you can see the same benefits of saving time, money, and headaches.
The software development process has been shifting left due to the growing challenge of developing and delivering software releases faster and faster. Agile methodologies, configuration management, and new practices, such as DevOps, have been created (or at least impacted) as a result of this shift.
Shifting left has been focused on testing proprietary code earlier in the lifecycle, but what about open source components? When are you making sure you are not using problematic licenses and that there are no known security vulnerabilities in your product?
Here, I address what you need to know about shift-left practices and how you can shift your open source auditing left, too.
What We Mean by Shift Left
Ten 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. The cycle would be repeated as necessary.
Shift left practices are about integrating your testing into your software development process, thereby uncovering defects earlier, when they are 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 a shift-left practice. This promotes agility and lets the project team scale its efforts to boost productivity.
Saving Time and Reducing Costs
A report by IBM Security Systems reveals that vulnerabilities detected in the early development process cost $80 on average to fix. However, the same vulnerabilities can cost $7,600 to fix if they are not detected until the production stage.
Shifting left is all about uncovering as many issues as possible as early as you can in the software development process, both so that the cost of fixing them is under control and so you can improve the ultimate 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 shifting left to focus on proprietary code enough?
Open Source Compliance and Security Checks
According to a Forrester’s developer survey, four out of five developers say they’ve used open source frameworks or projects in applications they have developed or delivered in the past year.
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 whether there are any security vulnerabilities in their product. But code scanning is usually done in the prerelease phase. The cost of discovering an issue at this stage is extremely high, and if the vulnerability is severe, it usually will lead to postponed releases. What is needed is an agile approach, by integrating open source management into your build process and auditing your open source components every time you run your build.
There are two primary aspects you need to shift left in regard to open source components.
The first is license compliance. It is essential that you ensure all your open source components are licensed properly—no license means it is merely a public code, but the author still hold the copyrights for it and you cannot use it—and that you can comply with the open source license.
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 just before release). This can be easily solved by integrating open source management into your continuous integration processes.
The second aspect is security vulnerabilities. Unlike proprietary code, with open source code you have the benefit of a large, active, capable, and committed community identifying and fixing issues.
More than four thousand security vulnerabilities are discovered in open source projects a year. When you are planning on using open source components, you just need to search for them and see if any problems have been reported. 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? If you shift this process left and perform it earlier in the lifecycle, just like many in DevOps are now doing with testing, you can see the same benefits of saving time, money, and headaches.
About the author
Experienced entrepreneur with deep background in R&D and product management. At Eurekify. and later CA, became an expert in designing and implementing complex management and compliance software systems, and in delivering them to the market. Now co-founded and manages WhiteSource.
