Widespread open source usage is simply a fact in organizations of every size, across all verticals. This is not a passing trend – open source usage will continue to grow. Developers are going to keep incorporating open source components into their code: it’s cost-effective, it helps companies accelerate the DevOps lifecycle and it frees up developers’ time to give their organization’s proprietary codes the extra magic they need to stand out in today’s marketplace.
The advantages of using open source components are obvious, and organizations are using more and more of them – either in the development of their products or in the internal tools that they use. As this practice continues to grow, it’s important to pause for one moment and take a closer look at the processes and DevSecOps tools that we use when we work with open source software: are they the same as the ones we’ve always used for proprietary or third-party code? If your answer was “yes”, I suggest moving on to this next set of questions that were recently raised in an MSDN blog post about open source management:
- Can we trust all the open source libraries that are in use?
- Do the open source libraries align with our organization’s application security standards?
- Do we accept all types of open source licenses?
- Do we even track which OSS components are added to our systems?
As the blog post points out - the larger the organization, the harder it probably is to answer those questions. But even smaller companies are challenged when requested to audit their open source components.
The advantages of using open source code are well known to everyone in the industry. However, many organizations are not as quick to realize the responsibilities that go along when using open source:
Staying Safe - Open Source Application Security
The security measures required of organizations when using open source code are different than the ones we traditionally use for proprietary code: since open source code, as the name suggests, is open to the public, vulnerabilities can easily be found and exploited by hackers. This doesn’t mean open source is less secure – the open source community is also vigilant about security, and the transparency that might allow some parties to exploit the code also works for fixing issues: when vulnerabilities are discovered, they are addressed and fixes or patches are created and published swiftly. It’s important that organizations know their open source inventory and are aware of code updates so that they can address vulnerabilities as soon as they are discovered - and before a security breach costs them valuable resources.
Mind Your Licenses - Open Source License Compliance
The field of open source licensing might be confusing at first, if you’re not a copyright attorney. There is a variety of open source licenses out there, and different components use different licenses. When developers incorporate open source into a product throughout the DevOps lifecycle, licensing restrictions usually aren’t usually at the top of their minds. Organizations often end up discovering a license compliance issue during an audit. To enable developers to do their jobs without being held back by heavy-handed legal policies, it’s extremely important to identify potential licensing incompatibilities before they require you take apart your products code.
And so, we arrive at this troubling question: if you’re not sure which open source components are included in your product, or even their location in your product’s architecture - how can you ensure the level of their quality and security. How can you make sure vulnerabilities or compliance issues are addressed?
Keep Calm and Automate
The vulnerabilities and risks that I mentioned earlier are significant, but can be easy to manage when you track your open source usage continuously, starting as early in the DevOps lifecycle as possible. An automated tool that runs on your continuous integration or continuous delivery server and tracks your open source components - identifying application security, licensing or quality issues every time you run your build, will help you to address any risks or vulnerabilities in your open source components before fixes and updates cause delays in releases and cost so much time and money.
Shift Left Your Open Source Management
The agile DevOps practice of shifting your ALM left helps teams get to a smooth product release, and is extremely compatible with open source management: identifying open source code risks before the components are deeply embedded in your product, and remediating them as part of the DevOps lifecycle and not after it’s finished – will save your managers, your CISO and your developers many sleepless nights, and help you deliver the product your customers want, right on time.