Enterprises are leveraging a variety of open source products including operating systems, code libraries, software, and applications for a range of business use cases. While using open source comes with cost, flexibility, and speed advantages, it can also pose some unique security challenges. Given that open source components may be present in up to 96% of commercial applications, how can you be sure that your software is secure?
We asked two members of the Cloud Academy Content Team— Logan Rakai, our DevOps specialist and Stuart Scott, our specialist in all things security—to share their tips for helping keep your open source components secure.
What makes open source components so vulnerable to security risks?
The short release cycles of some open source projects can be difficult to keep up with. On the plus side, new features and patches get deployed sooner rather than later. However, auditing every release can be someone’s full-time job, and by the time you’ve managed all the issues in one release, another one is ready. Flavor-of-the-week open source frameworks are a security nightmare and while having an automated system to scan for the latest updates will help, it’s not a failsafe that can identify all of the issues.
With such a wide base of users to test the software, spot potential bugs, and security flaws, open source software (OSS) is often considered more secure. However, when it comes to catching and fixing security issues, simply having more eyes on the problem isn’t enough. Security problems require security expertise and not all developers are security experts. They may know enough to try and implement certain fixes, but this can create a false sense of risk mitigation. More advanced topics like cryptography, for example, further narrow the field for those who can review code for such security flaws.
Dependencies in open source projects allow some vulnerabilities to fly under the radar. Projects that include unknown third-party libraries pulled from package managers may be passing on vulnerabilities that aren’t easily visible. Many developers pin version ranges to ensure future patches are available. However, a dependency that is several projects removed may be more difficult to notice in the first place, and is more likely to be an attack vector that can be exploited.
What can developers and DevOps teams do to better secure open source components?
Treat everything as code, including compliance. Doing so will help ensure that known regulations including those for the payment card industry (PCI) or healthcare (HIPAA) information privacy are followed. This will also make it easier to ensure that patches are universally applied.
Embrace automation. Staying up to date on vulnerabilities logged in online sources such as the National Vulnerability Database or postings on project home pages is necessary, but also time consuming. Put some frontline tools in place to help catch the obvious things (there are some great commercial and open source Dynamic Application Security Testing (DAST) solutions available) and employ monitoring tools to keep up with what’s happening in real time. Tools such as SumoLogic are great and serve as a modern alternative to a Security Information and Event Management (SIEM). At a minimum, static code analysis must be part of the CI/CD process, which provides automated, early detection of security issues to complement peer reviews.
Bring developers and security together. Enlist your security teams to train developers to drive thorough understanding of security and the latest trends. An initial secure coding workshop held in partnership with the security team is a great way to kick things off. Invite them to design reviews and include them in sessions when high-risk changes are being made.
Build a security-first culture. Your organization must focus on more than just bringing developers and security together, but also ensure that effective security practices are built into everything you do. The best fixes and the best alerting mechanisms in the world cannot resolve poor security practices. The Equifax breach for example, attributed to vulnerable versions of the open source software Adobe Struts, is a case in point. Since the well-publicized breach in 2017, companies are still downloading the vulnerable versions of the package despite the fact that a patch is available. (The patch was also available two months before the Equifax breach and has been issued multiple times since.) In DevOps culture, security discussions must happen early and often throughout the software development lifecycle and beyond. If you’re using open source components, it’s your responsibility to be aware of the updates and to actually apply them yourselves.
Fortunately there are tools to help you evaluate and provide confidence around the security of the open source software you are using in your applications. Two tools that provide enterprise-ready end-to-end solutions for managing open source risk are Black Duck and Sonatype Nexus. Note that these solutions are not overnight fixes and will take time to integrate.
There are also free tools for assessing the risks in open source software and containers. Many open source software packages utilize free static analysis scanners and the results are available for everyone to inspect.
Coverity Scan provides free deep scans of open source software that include the Common Weakness Enumeration (CWE/SANS) Top 25 vulnerabilities. Many projects trust Coverity Scan, including the Linux kernel and Apache projects such as Hadoop. You can find them on the project page.
If you aren’t comfortable with the risks identified, you might consider using alternate software or versions. Similarly, if you are using Docker containers in your DevOps practice, you can take advantage of Docker Security Scanning results of official images hosted by Docker and use the same technology to scan your own private repository images.
New Content: Azure DP-100 Certification, Alibaba Cloud Certified Associate Prep, 13 Security Labs, and Much More
This past month our Content Team served up a heaping spoonful of new and updated content. Not only did our experts release the brand new Azure DP-100 Certification Learning Path, but they also created 18 new hands-on labs — and so much more! New content on Cloud Academy At any time, y...
Docker Image Security: Get it in Your Sights
For organizations and individuals alike, the adoption of Docker is increasing exponentially with no signs of slowing down. Why is this? Because Docker provides a whole host of features that make it easy to create, deploy, and manage your applications. This useful technology is especiall...
Constant Content: Cloud Academy’s Q3 2020 Roadmap
Hello — Andy Larkin here, VP of Content at Cloud Academy. I am pleased to release our roadmap for the next three months of 2020 — August through October. Let me walk you through the content we have planned for you and how this content can help you gain skills, get certified, and...
New Content: Alibaba, Azure AZ-303 and AZ-304, Site Reliability Engineering (SRE) Foundation, Python 3 Programming, 16 Hands-on Labs, and Much More
This month our Content Team did an amazing job at publishing and updating a ton of new content. Not only did our experts release the brand new AZ-303 and AZ-304 Certification Learning Paths, but they also created 16 new hands-on labs — and so much more! New content on Cloud Academy At...
New Content: AWS, Azure, Typescript, Java, Docker, 13 New Labs, and Much More
This month, our Content Team released a whopping 13 new labs in real cloud environments! If you haven't tried out our labs, you might not understand why we think that number is so impressive. Our labs are not “simulated” experiences — they are real cloud environments using accounts on A...
New Content: AZ-500 and AZ-400 Updates, 3 Google Professional Exam Preps, Practical ML Learning Path, C# Programming, and More
This month, our Content Team released tons of new content and labs in real cloud environments. Not only that, but we introduced our very first highly interactive "Office Hours" webinar. This webinar, Acing the AWS Solutions Architect Associate Certification, started with a quick overvie...
DevOps: Why Is It Important to Decouple Deployment From Release?
Deployment and release In enterprise organizations, releases are the final step of a long process that, historically, could take months — or even worse — years. Small companies and startups aren’t immune to this. Minimum viable product (MVP) over MVP and fast iterations could lead to t...
DevOps Principles: My Journey as a Software Engineer
I spent the last month reading The DevOps Handbook, a great book regarding DevOps principles, and how tech organizations evolved and succeeded in applying them. As a software engineer, you may think that DevOps is a bunch of people that deploy your code on production, and who are alw...
Linux and DevOps: The Most Suitable Distribution
Modern Linux and DevOps have much in common from a philosophy perspective. Both are focused on functionality, scalability, as well as on the constant possibility of growth and improvement. While Windows may still be the most widely used operating system, and by extension the most common...
How to Effectively Use Azure DevOps
Azure DevOps is a suite of services that collaborate on software development following DevOps principles. The services in Azure DevOps are: Azure Repos for hosting Git repositories for source control of your code Azure Boards for planning and tracking your work using proven agil...
Docker vs. Virtual Machines: Differences You Should Know
What are the differences between Docker and virtual machines? In this article, we'll compare the differences and provide our insights to help you decide between the two. Before we get started discussing Docker vs. Virtual Machines comparisons, let us first explain the basics. What is ...
DevOps: From Continuous Delivery to Continuous Experimentation
Imagine this scenario. Your team built a continuous delivery pipeline. Team members deploy multiple times a day. Telemetry warns the team about production issues before they become outages. Automated tests ensure known regressions don't enter production. Team velocity is consistent and ...